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 Plan
2. 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