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