Midway through 2006, members of a small software development group at an engineering center for an oil field services company began having informal conversations about the nature of their work. Among other things, they pondered whether software development is an engineering discipline or a craft; and where to focus improvement efforts. These discussions sparked the interest of many on the team. They searched and came across the Agile Manifesto, which was posted in their work area. The values outlined in the manifesto appealed to the team.
At the same time, the team leader felt a growing sense of discontent. His team, due to their group's charter, did not need to follow the established process of the organization - Rational Unified Process (RUP). In their relative freedom, they thought they were practicing Agile, but had no way of being certain they were practicing it correctly. They seemed to be grasping the spirit of Agile, but had no formal validation. Other groups were claiming to be Agile simply by virtue of not following a set process - an obvious pathway to chaos rather than enlightenment. Agile is not a single methodology and it is often customized and adapted, yet there is still a need to measure project health from the process perspective to satisfy requirements from other parts of the organization, such as the project office.
The Team Gains Allies
In late 2007, one of the project's top managers attended a software conference where he was exposed to the experiences of many other organizations implementing Agile methodologies. In addition, the engineering center software practices manager was looking for a candidate to pilot Scrum development methodology. Timing was such that the team's request to adopt Scrum received management ready consideration without hesitation.
The enthusiastic development team, now self-reinvented into the Scrum team, armed with little more guidance than a set of notes from a 3-day course on Agile Project Management, set out to implement Scrum. They attempted to apply their understanding of Scrum into their daily work, but, without adequate assistance misconceptions and mistakes arose. The group attempted to make corrections over the course of the following months but it became clear that more formal local assistance would be required to optimize the benefits from adopting Scrum. An external coach from a consulting company was engaged, providing guidance during his weekly sessions with the team.
Setting the Course
Having the coach in place proved to be very effective in getting both the development group to function properly within the Scrum methodology and helping the local leadership buy into the methodology. Having an outsider with the credentials ability to speak to the leadership's concerns was instrumental in fitting the pilot into the management processes. After observing the team and its interactions, both internal and external, the coach created a roadmap for improvement which focused our efforts for the next few months. Highlights from this plan included:
1. Improve the quality of the backlog and create the Release Plan2. Establish proper product owner behavior
3. Establish proper QA/Tester behavior
4. Establish objectives and technique for conducting functional retrospectives and sprint planning
5. Make daily meetings more useful and transactional
6. Track and publish team velocity and product burn-down chart
7. Adopt Acceptance Criteria to the point of Test-Driven Requirements (a.k.a. Acceptance Level TDD)
8. Adopt Test-Driven Development and Continuous Integration
After several months of working with assistance from the coach, the team had made major progress in most of these goals.
Two Weeks in the Life of a Sprint The way the team carries the sprints at present has evolved significantly since they took the first unguided steps. There is now a much improved understanding of the roles of each individual and how they work together within the process to produce the most value to the organization.
Focusing on the Big Picture - Keeping the Backlog Healthy
The health of the project backlog is a good indicator of the strategic focus of the project; it should always reflect the product owner's best knowledge of the stories to complete, and the development team's best assessment of their cost. The product owner regularly updates the Product Backlog, marking completed users stories, revising those that have changed and re-prioritizing the updated list as appropriate.
With the guidance of the coach and through trial-and-error, the product owner was able to evolve the backlog from its initial low-quality state into something that could be used effectively for release planning. Stories became less about functionality and more about workflows, stressing the value that the end user would receive. They were also refocused to cover vertical slices of the system. Through this process the product owner gained experience in arranging the stories. For example stories with similar focus were prioritized together so as to maximize synergy during the sprint and developers provided feedback on how the story sequence affected risk management.
One of the challenges experienced was the team's tendency to over-analyze. It was difficult to keep focus on the goal of the discussion as developers continually pushed for a higher level of understanding and comfort than was needed to answer the questions at hand. This tendency is probably not uncommon among strong engineering types. Meetings seemed to drag on forever with little production to show for them, and the grueling sessions wore everyone down. An experience with the coach showed how much of an issue this was. At the end of a day-long meeting there was one story left to estimate. The team was about to leave it for the next day when the coach suggested that they go ahead and flash the planning cards. Amazingly, with no clarification or discussion, everyone proposed the same number of points. They saved themselves an hour's worth of planning, and set a different tone for the following day. While not completely under control, the team is experimenting with time-boxing the discussions to address this tendency.
Planning to Succeed
In the team's experience, sprint planning has been the primary determinant of the successful outcome of the sprint. If the team, including the product owner, developers, testers, documenters, and other supporting roles, is clear on what the goal of the sprint is, there is a greater chance of identifying problems early and lesser chance of surprises towards the end. In the planning meeting the team first arrives at the set of stories to tackle using standard point and velocity estimates.
What follows is a specialization of the traditional Scrum methodology in that the team focuses the discussion on each story's acceptance criteria, which is a detailed walkthrough approved by the product owner of how the story will be verified in the end. The team attempts to pin down the product owner to determine how they know if a story has been completed. The product owner usually makes a first statement of the steps he will take while interacting with the product and the expected results. The team asks questions to clarify this statement, including what-if's, boundary conditions, impact on other stories, and non-functional requirements. Testers within the group bring up questions related to the testability of the statement, while developers begin thinking of implementation strategies, which can trigger additional queries for the product owner. In the end, the summary of this clarification is recorded as the acceptance criteria for the user story, which becomes its primary guiding objective. The acceptance criteria will drive the elaboration of test cases and end-user documentation becomes the goal of the design and coding tasks, and serves as the discussion point for usability and architectural constraints. It is the primary contract between the product owner and the rest of the team.
The final planning step is the task breakdown and estimation using standard techniques. The 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.
Assuring Quality
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 of the organization.2. During the planning sessions the testers push the product owner and developers to achieve testability of the acceptance criteria.
3. During the sprint, testers focus on translating the acceptance criteria into test cases, maintaining the test database, implementing test cases in a test automation tool and maintaining the defect system and statistics.
4. Defect statistics are kept only for issues found outside of the sprint cycle. In other words, if an issue is introduced, found and resolved within the sprint, it does not count as a defect. This encourages the team to produce high-quality deliverables each sprint and creates a standardized quality metrics.
5. The tester pushes the product owner to include defect resolution as stories in the project backlog and to prioritize them to prevent them from degrading quality in the long run.
6. Because they are generally more familiar with the deployment and commercialization, tasks testers help the team prepare for these activities by adding pertinent stories into the backlog.
The special role of the tester in team interactions is highlighted in the diagram below.{C}
A point of continued discussion has been the role of test automation. Our coach helped us focus on a common-sense, Agile-inspired approach. Instead of looking at automation for automation's sake, he recommended letting the value chain pull us into a position that demanded we tackle automation or risk losing productivity. To get to this point we would first make sure stories had good quality acceptance criteria and test cases. Then we would stipulate that all test cases should be run manually at the end of every sprint. Naturally, this set of regression tests would grow with each sprint, taking up more and more of the group's time. When this overhead became impractical to maintain the group was compelled to look at test automation.
Finishing the Race
The sprint ends with a review and retrospective. During the story review the product owner walks through each story and demonstrates that the acceptance criteria have been met. Deviations, if any, are highlighted and if any issues are noticed they are written down as defects. If the product owner is satisfied with the demonstration, the story is officially done.
The retrospective is the time when the development team takes a critical look at the sprint to find opportunities for improvement. The product owner and external stakeholders are usually not present. Various meeting techniques are used to elicit comments and arrive at a collective consensus on areas of improvement, which become the focus for action-item proposals to take on during the next sprint.
The Road Ahead
With coaching assistance the team has made remarkable advances in a number of areas. Individuals are generally comfortable with the fundamentals. There is rhythm and efficiency in their daily work and a foundation is laid for achieving consistent quality. Individual participation and ownership has risen dramatically. Results have been very encouraging, based on initial feedback from end-customers and recognition within the organization. While still on the learning curve, the team is confident the Scrum methodology will deliver the improvements the organization was aiming to achieve.
About the Author
