With relative inexperience in Scrum, the technology center's software practices manager started with the Agile Manifesto, and evaluated the candidate project based on its readiness to adopt these concepts. The evaluation was focused on delivery frequency, team interaction, co-location and team flexibility in responding to changes.
The candidate project for the pilot aimed to quickly introduce to clients a new concept in the production arena, via working code that would lead to further workflow discussions on what the clients would like to see in the product. This quick introduction and reaction pace would require frequent releases. With only a concept as the starting point, the project began with poorly-defined requirements, and was expected to accommodate frequent addition and changes in user stories as the concept matures. The team was relatively small in size, with team members working together previously, resulting in visible, positive team dynamics. Scrum methodology seemed suitable for the development of this project.
On the other hand, the Scrum team was located in Houston while the Product Owner was located in Europe, adding complexity to the interaction of the team. Coupled with the inexperience of the team members to Scrum methodology, a steep learning curve was a certainty.
However, the potential benefits were deemed by management to outweigh the risks, and the Scrum Pilot was approved. By end June 2008, the Scrum coach was in place, leading the team to better Scrum practices.
The Adoption Challenges
Once approved, the focus now turned to process support. A number of questions surfaced.
- How and when to reduce technical risks before extensive coding?
- How to address non-functional requirements such as architecture and usability designs?
- How to ensure that the quality of sprint deliverables, and thus the commercial product, reaches or surpasses the standard Quality Release Criteria?
After an extensive brainstorming session involving representatives from the project team, engineering and software practices management, and the Scrum coach, guidelines were created to address these concerns.
To reduce high technical risks encountered late in the development stage, users stories with high business values and high technical risks would be assigned to early sprints. Those with lower business values might eventually be removed from the product should the technical risks prove too high.
Architecture and usability should have high-level constraints providing overall guidelines. Architecture constraints might include having reusable components, open and modular architecture and the use of a certain framework, computer technology and language. Usability constraints might include having distinctive brand, adjustable and extendable layouts, minimal design patterns, automation and enhanced user interactivity such as maps, diagrams and plots. Without a thorough elaboration phase on architecture design, some refactoring cost is expected. However, it is considered a worthwhile risk in exchange for quicker time to market for the most valuable features.
Clear acceptance criteria for all user stories should be communicated during sprint planning to allow for early writing of test cases, and relevant testing during the sprint. Automated unit and regression testing are needed to ensure high-quality sprint deliverables.
Above are the guidelines used to evaluate the project implementation below.
Implementation of Adoption Guidelines
|Reducing Technical Risks
|Architecture and Usability
As of early December 2008, after 11 sprints, the team has acquired a number of good practices, while still on the learning curve for others. Simplistically, the implementation of the three major concerns was tracked via three colors: Green for well done, Yellow for partial implementation, or Red for needing attention. The project dashboard is shown on the right.
Due to the nature of the project, described earlier in the consideration for