Scrum framework is very common in Agile environments and is an easy technique to mirror. It certainly appears to be a useful weapon in the emerging Agile process change arsenal. From a process improvement perspective Scrum gives five primary benefits, which are:
- responsiveness to project change
- support of customer intimacy through the Scrum teams
- frequent planning and delivery cycles through Sprints
- goal orientated roles and team structure
- flexible support of process improvement approaches.
The first benefit listed is the way Scrum supports project change. Ideally, process improvement is a journey not a destination. Scrum allows the introduction of change at any point making this journey easier to manage.
It is not uncommon for an important piece of tacit knowledge to emerge mid-project and affect the plan. In addition, a common and positive side effect of implementing improved processes is the identification of additional process refinement opportunities. Thanks to the flexible nature of Scrum these new items can easily be added to the product backlog and prioritised by the product owner.
Unmanaged change is never desirable, but by following the Scrum process diligently, change becomes a positive sign of process take up. Also, by providing a flexible 'pull‘ of requirements into the internal project planning we ensure that the project team reacts quickly, gives the process adopters what they need when needed and the project team does not lose any early stage opportunity to institutionalise process. This ‘pull' manifests through the iteration planning, in practice it is the reprioritisation of the Backlog by product owner to discoveries made in the previous sprint. For example, if a defined process had not accounted for a SOX compliance requirement then its rework can be reprioritised easily by the product owner and handled in the next sprint.
The second benefit is that Scrum teams are a powerful mechanism for building intimacy with customers, with the customers being the process adopters. Process change projects are notoriously difficult, not because process is difficult to define, but because in order to achieve traction you have to win the hearts and minds of the people implementing and using the processes developed by the project One of the simplest and most effective ways to affect change is to have the process-users own the processes they are implementing. Therefore, how you populate your Scrum teams is important. Ideally, it should be a good mix of subject matter experts from the target organisation supported by process specialists.
The role of the product owner is crucial to an effective project. The product owner for a process change project is usually a reasonably senior team manager, often a delivery manager or QA manager, who is responsible for some aspect of the organisation who will be using the defined processes. This role sits at the level of the adoption team with a view across the entire delivery domain, if multiple work streams exist the product owner will be responsible across the whole piece. This can be challenging and requires a strong individual who can balance conflicting priorities and politics. A good product owner needs to understand that a Scrum project is goal based, so they should focus on what is critical to success and prioritise accordingly. This is a difficult thing to achieve, as most organisations are cost based and focused on providing proof that resources are utilised per the plan. Achieving this goal based focus is important as it allows the process users to clearly see and engage with the project drivers making it easier to achieve process adoption.
Another benefit is the frequency of planning and delivery. Sprints are designed to deliver working