How much agile methodology was really implemented?
September 28, 2010
How much agile methodology was really implemented?
When the project first started, the development team attempted to adopt some (though not all) of the concepts of the Scrum framework, an agile process based on empirical process control theory that focuses on transparency, inspection, and adaptation. The team implemented daily stand-up meetings and burndown charts, but chose not to adopt components to enable inspection, such as sprint planning, sprint review, and retrospective meetings.
As the project moved into the waterfall qualify phase — in which the development team needed to handle a constant stream of testing defects — the team’s scrum process ended. They would have to pick it back up when the next release started its development phase. This failure of the initial Scrum attempt was ultimately a consequence of not having adopted the processes of inspection; this lesson learned helped the team in their follow-on Scrum efforts.
In the development phase of a more recent release, the development team decided to start fresh and introduce the complete agile process based on the Scrum concepts and hallmarks. The team established a commitment to sprint planning, sprint review, and retrospective meetings. More importantly, they committed to process inspection and self-governance.
- Roles
To fully adopt the Scrum way of doing things, the team needed to identify who on the scrum team would assume the three required roles of Product Owner, ScrumMaster, and Team. Initially, the development project manager was positioned as the primary Product Owner. The Team consisted of the existing development team members. A ScrumMaster was selected who established a sprint calendar of three- to four-week cycles, with start and end dates that didn’t necessarily line up with the waterfall process milestones; the team learned that sprint meetings scheduled close to waterfall milestones result in the team focus being shifted to one of these events, but not both, leaving an unfavorable result for the one that became neglected.
- Backlog
For the sprint planning meeting, the development team started with the product backlog of candidates that the client had identified (in the concept and plan phases) for future release of the application. The Product Owner selected a subset of these items, which constituted the possible product backlog to be considered for the sprint. During the sprint planning meeting, the development team committed to the product backlog items they believed they could complete during the sprint, and from that built the sprint backlog, which was the tasks, task estimates, and assignments that the team would actually work on during the sprint.
- Reviews
At the end of each sprint, the development team held a sprint review meeting. The purpose of this meeting was to demonstrate to the stakeholders what had been completed in the sprint, and provide a timely opportunity for the stakeholders to comment and ask questions, possibly resulting in a list of desired changes. Such changes and any missing or incorrect functionality were added to the product backlog for the next sprint.
- Retrospective
At the end of each sprint, the development team also held a sprint retrospective meeting to review what went well during the sprint and what could be improved upon. Based on this feedback, they changed their processes as appropriate and added non-functional action items to the product backlog.
- Schedule
The typical schedule was to hold the sprint review and sprint retrospective meetings on the same day at the end of the sprint, followed by the sprint planning meeting for the next sprint on the following day. These meetings were conducted within the Scrum time-boxing guidelines.
- Participants
Client representatives (solution leaders) attended the sprint planning and sprint review meetings. Initially, the client’s interests were represented by the development project manager, but in later sprints, the development team was able to pull in the solution leaders and get direct client input and feedback through these key participants. This approach was purposeful; the team wanted to understand the processes and methodology well before expanding the circle of participants to include the solution leaders.
- User stories
The development team also incorporated user stories into their planning. Although the client representatives (solution leaders) should be responsible for creating user stories, the development team did this instead, based on existing requirements, because the greater project was not yet committed to agile processes. The team then engaged the solution leaders in validating the user stories, collaborated to refine them and gain a greater understanding of the requirements. This practice has greatly improved the understanding and accuracy of the requirements, and greatly reduced rework after the fact.
- Quality assurance
While the development team has long used continuous integration, they recently incorporated automated testing into the development process. Work items were not considered complete until an automated test was available and merged into the testing tool. Daily builds and automated testing ensured that the code base was not broken as code was checked in. This resulted in higher quality code and fewer defects being found in the qualify phase. Coding items were not considered complete until the functionality could be demonstrated on a live server. Non-coding items, such as new processes or documentation, were published on the development team’s internal wiki and distributed to the team for review prior to being presented as complete at a sprint review meeting.
For more info visit http://www.ibm.com/developerworks/websphere/techjournal/0907_hines/0907_hines.html
praveenmatanam
