By John Hill
Over the last few years, a number of practices from other agile disciplines have successfully found their way into Scrum. Examples include incorporating Test Driven Development as part of the sprint process, or utilizing User Stories from XP as part of defining requirements under Scrum. This article, however, deals with a variation on vanilla Scrum itself.
Vanilla scrum prescribes a two-part sprint planning session. During the first part of the session, the Product Owner is supposed to meet with the team to explain sprint backlog priorities, as well as to clarify any functional issues. The team is then supposed to retreat (without the Product Owner) to estimate tasks, as well as to “sign-up” for work. By the end of the second step of the planning session, all work is supposed to be estimated and assigned.
When I first began to practice Scrum, we followed this model. During the second part of the planning session, the team determined which team member was best suited for a task and reviewed each person’s capacity based on vacations and holidays. At that point, each individual estimated and signed-up for those tasks most suited to his skill set.
The result was a sprint plan with individuals fully booked on tasks through the sprint end date. We found that this, in effect, significantly diluted the notion of a team being in it together. If one person became a bottleneck and impeded another team member, we began to experience conflicts between specific individuals.
Share
Vanilla Scrum’s two-part planning session was not working for us—something needed to change. So, after several sprints failing in the manner described above, we tried a different approach to sprint planning. Instead of having individuals estimate their own tasks, we encouraged the team to estimate all sprint tasks upfront as a group. Then, team members were encouraged to sign-up for only one or two tasks at a time. This strategy enabled individuals to pull the highest-priority tasks from the backlog first. It also alleviated the pressure of having a bunch of specific tasks assigned to one individual for the entire sprint. If the team’s initial task estimate was not accurate, the individual performing the task could provide a new estimate at the time they selected the task.
This shift in task assignment not only alleviated bottlenecks and friction, it also enabled individuals to work in areas where they had little or no experience. For although vanilla Scrum encourages cross-functionality in that individuals play multiple roles (discussed below), it does not address the problem of individuals acquiring expertise outside their primary role. For example, we used to have individuals who felt as if they owned certain components, and would assign all of these components to themselves in order to ensure that only they worked those components. These individuals invariably became bottlenecks because they could not properly sequence the completion of various components, thus impeding the rest of the team.
By preventing team members from taking on too many tasks upfront, other individuals were able to work on those components formerly owned by a single source. This model was initially painful, in that team members would need to discuss system areas with the former owners of those areas (in order to learn those areas), causing initial friction and (falsely perceived) lack of job security.
Over time, however, the former owners of the components realized that they would be able to have days off, take vacations, and not need to become overloaded during every sprint. Simultaneously, more and more individuals were learning those modules and becoming cross-trained. The former component owners soon became comfortable with this model.
Sample
Although this was a move in a great direction, it didn’t do anything to help with the compartmentalized roles on the team. For example, although developers were learning how to code and unit test in a wider variety of modules, they still felt as though they were developers and therefore only should write code. By the same token, business analysts were there only to write specifications, QA analysts to write and execute test cases, etc. This mentality fostered the “mini-waterfall” most of us see when initially implementing Scrum. That is, business analysts would write specs for a developer, who would code from the specs, after which QA analysts wrote and executed test case, rejected code for re-work, and so on. This cycle repeated for so long that the sprint goal was not often realized. This model also resulted in much idle time for team members, as developers and testers had to wait while business analysts wrote specs, everyone else had to wait while developers wrote code, and so on.
Over time, we improved the model, based on vanilla Scrum’s encouragement for teams to become truly cross-functional. For example, at the beginning of a sprint I would suggest that business analysts work together with developers and QA analysts on specifications. It was amazing how much more effective this is compared to a business analyst working on her own, needing to ask the individuals questions as she plods through the specifications. I would then encourage the business analysts to write test cases while the developers wrote code and QA analysts unit tested that code, sometimes sitting side by side with the developers. Having QA analysts working directly with developers helped both parties to understand what the code should do. This was a much better situation than having the code rejected later when tested by a detached QA analyst.
This relationship also eliminated the natural barrier between developers and testers who had formerly sat in different areas, with little interaction. The biggest challenge is asking developers to write specifications, or convincing developers to write or execute test cases.
Blend
Given the proper opportunity, most developers can write great specifications (which are both lean and sufficient) and write effective test cases. I also have found that developers can also execute test cases very well (as long as it’s not their code being tested). Similarly, business analysts, QA analysts, technical writers, and the like can broaden their skills to include writing specifications, unit-testing newly developed code, writing test cases, executing test cases, and producing user documentation. The only exception to full cross-functionality, in my experience, is that only developers will write code. Following this model will enable the evolution of a truly cross-functional team to o]ccur.
ScrumMasters stirring-up the pot in this way will cause some initial discomfort among the team. However, once it’s “soup”, the team will feel great (as will the ScrumMaster, who is now perceived by the organization to be Saint Anthony)
