tasks represent all known work to be done in the sprint. Finishing up the task estimates is a pivotal point in the sprint. Until then the team had been building up energy and knowledge to maximize its efficiency in the implementation of the sprint stories, and the end of the planning steps is like the start of a race: all members spring into action simultaneously with eyes on the goal.
The Daily Grind
One of the key concepts in Agile development is that of rhythm, which was emphasized regularly by the coach. Rhythm is marked by the completion of each task; therefore it is crucial for this to be a very visible, deliberate, and regular event. The daily standup is the occasion where this pulse of the project can be felt by all team members. When the team first started Scrum adoption the daily meetings were disorganized and low-value; each person talked for several minutes about what they had done the day before, what they planned to do today and what problems, if any, they were facing. These meetings have shifted to be entirely focused on task completions. Each member gets to mention two things: what tasks they completed since yesterday, and what tasks they expect to complete today. The tactile nature of Agile encourages each member to physically handle the task cards and move them to the completed region of the board.
A common theme in the adoption strategy is to have clear expectations. What does it mean to complete a task? Is it just code checked-in? Does it include testing? How about validation against external constraints? Focusing on completions produces two results: everyone in the group can hear the rhythm of tasks being finished, and there is a subtle pressure on all members to deliver a completed task every day. The results of the daily meeting included an updated burn-down chart posted prominently in the work area.
Developers have great freedom in choosing the tasks they work on. This fosters a sense of ownership and lets them manage the level of difficulty that they want to deal with throughout the sprint. The only guidelines we try to follow are that we should minimize the number of stories being worked on simultaneously and that developers should only work on one task at a time. The former encourages regular completion of stories so they can be reviewed early, and the latter helps avoid multitasking by developers, which can cause bottlenecks.
Pair programming is encouraged but not mandated. Developers spontaneously choose this mode of work when tackling difficult or interrelated tasks, or for the purpose of knowledge transfer. We found this practice particularly useful in helping new members of the team negotiate the technical learning curve. As soon as a story is complete, the product owner is asked to review it so that any feedback can be analyzed and acted on before the sprint completes.
In a mature organization there typically are well-established procedures for governing quality processes. The role of testers, the type and level of testing, the kinds of metrics to collect and the criteria used to qualify a product for release are some of the regulated aspects. Piloting a process like Scrum includes a fair amount of process engineering and negotiation to assure the organization that quality will not be adversely affected. Since Scrum does not directly address these concerns, some retooling was needed. Some of the specialized practices that have been put in place include:
1. Even though they function as an integral part of the team, testers report to the quality assurance branch