Suitability
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
|
| Quality Assurance
|
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 Scrum adoption suitability, the requirements were poorly defined at the start. This lead to an incomplete product backlog, hindering the prioritization of the user stories with highest business values. In turn, not all relevant technical risks were addressed in earlier sprints.
High-level constraints for Architecture were provided, though without the hands-on interaction with the project team to ensure that the constraints are fully understood and respected for each user story. Usability constraints were meticulously documented, and good interaction happened at the product owner level, though not translated fully into the user stories that can be properly prioritized.
Quality Assurance remained a concern due to lack of automated regression testing, and to ad-hoc unit testing. The concern was due to the expectation that sprint-end deliveries are shippable code. The lack of formal automated regression testing reduced that confidence level. This situation was expected to improve since new resources had been added to the team, including an expert on automation.
The dashboard is expected to improve quickly due to the project team's increased experience, guided by the Scrum coach, and to the recent Quality Assurance strategy pursued at the technology center's level.
Quick Gains
It was obvious to management that the Scrum Pilot had delivered. If traditional RUP methodology had been chosen for the project, the team would have still been in the elaboration phase, trying to complete the requirements document and to reduce technical risks for all major features. By adopting Scrum, the project was able to deliver the first release, as promised, at the end of September 2008.
Even though the product backlog was still not complete, the project team was always working on the user stories with the next highest business value, as they were known.
Scrum ensured frequent inspection systematically, from daily standup meetings, to ad-hoc peer reviews, to regular sprint retrospectives and sprint planning events.
Not least, there was a strong sense of team ownership and accomplishment from the team members. This was essential for promoting team learning and increasing the team velocity.
Potential Losses from Scrum Benefits
There were certain fundamental concepts in Scrum methodology aiming to achieve clear benefits. With the project team still on the learning curve for certain practices, some potential benefits were at risk until the team matures. Without full automation for unit and regression testing, to be executed multiple times during a sprint, the confidence in sprint deliverables was reduced. The lack of co-location between the Product Owner and the project team decreased the team efficiency that would have come from close collaboration and quick reaction as a team.
Process Support
As Scrum made its way into the technology center, the focus needed to include process support. The question was how to formally adopt Scrum as an engineering methodology within a strong existing Product Lifecycle Management Process framework that supports both engineering and business tasks. To address this question, a Scrum project type was added to the Product Development Database (PDD) software tool. The list of engineering artifacts was drastically reduced, and adapted to the readily available Scrum artifacts, thus reducing overhead and facilitating the adoption of Scrum practices by the engineering team. Business artifacts were updated, with the ownership given to the Product Owner, decoupling engineering tasks from business tasks and removing the joint ownership at checkpoint meetings. Beta and commercialization phases were maintained, ensuring the necessary preparation for commercialization of the product.
The Way Forward
Learning from the Scrum Pilot experience and results, a technology center-wide Scrum Adoption Strategy was proposed for 2009, aiming to slowly introduce Scrum methodology to more projects. Five key success criteria are used for candidate selection. These are:
1. Buy-in from both engineering and business partners. Increased flexibility on requirements management must be coupled with ready, hands-on participation between the two teams.2. A dedicated Product Owner. This role must be filled by a knowledgeable domain expert, able to dedicate the time needed to consolidate requirements from various stakeholders in order to arrive at a comprehensive, prioritized product backlog.
3. Commitment to automated unit testing and regression testing. The Scrum team, including both developers and testers, must commit to automation strategy to ensure high quality standards for sprint deliverables.
4. Team co-location. This is the strong preference, though it could be relaxed to require co-location between the Product Owner and most of the team members.
5. Small team size. It is judged that the team size often reflects the complexity of the project, and a team size of 10 or less is strongly recommended.
In preparation for the future projects' adoption of Scrum methodology, training is provided, specifically for Agile and Scrum Methodology, and Developer Testing Fundamentals. A Scrum coach should be engaged to lead the new project teams through the adoption, with participation decreasing as the team matures.
We aim to slowly broaden the Scrum experience at the Technology Center with carefully selected projects. This growth will be tended with appropriate process and training support to ensure successful adoption of a more agile software development methodology.
About the Author
Anh Kuhn de Chizelle is the Software Metier Manager for Schlumberger Information Solutions, Houston Technology Center. She has been with Schlumberger for over 14 years, and has had assignments in engineering, research and operations in the USA, England, France, United Arab Emirates and Russia. She is currently focusing on software practices, and plans to adopt Scrum to a number of projects at the Houston Technology Center.
