code in short sharp bursts. Process definition and implementation do not cope well with big bang delivery strategies. Dumping a large process infrastructure onto a user base in a short period will result in delivery impacts, inefficiencies, mistakes and frustration. What takes time in most projects is a combination of sign-off and the subsequent implementation, the actual development of process is often very brief. An effective sprint strategy is to develop processes in sprints of two weeks, within this Sprint the Processes selected from the Backlog are defined, socialised and agreed so they are ready for adoption. This can then be followed by a two to four week adoption sprint. During this sprint the Requirements on the Backlog take the form of training exercises, coaching sessions, implementation tasks (such as a PM using the new risk log or story template). Running definition and implementation in sequence is especially effective as it allows the process definers to identify defects, changes and issues for inclusion back onto the Backlog.
By delivering targeted bursts of process you are able to de-risk the implementation and aid end user buy-in. The sprints make it easier to trial and refine iteratively, ensuring the processes meet the needs of the client. The end users find this approach much easier to cope with and it minimises the impact on their daily workload.
It can be difficult to know when a process improvement project has met its objectives. An advantage of Scrum is that the frequent iteration planning forces you to take stock more often, helping to ensure work stops at the most appropriate point. Project success is measured by the level of adoption of the processes and then by the impact of new processes on target organisation. From a Sprint perspective this translates to simple adoption measures. The refinement and benchmarking of the processes themselves is usually a separate body of work which may feedback changes into the Product Backlog. Because process is implemented frequently using Scrum, this allows more opportunity than traditionally available for these changes to be fed back to the project team.
The breakdown of roles and responsibilities, as defined in the Scrum framework, is a benefit. Ownership of the processes by the client is much easier to achieve in a Scrum team where you realise a self-organising and self-managing structure. The ability to focus on the requirements in a reactive way allows people to feel their changes are a sensible manifestation of the team's needs.
There is a common recognition that self-organising teams take work. They simply don't happen in the tight timeframes of a normal project without some leadership. This is not about managing the Scrum team, but providing mentoring, guidance and steering to help the team achieve its potential. However, this is comparable with the effort required for leading any form of process change team and should not put you off the task.
Finally, the fifth benefit of Scrum is that it does not dictate the engineering processes to deliver working software. This makes it adaptable to common process improvement approaches, frameworks and methodologies. It shouldn't matter whether you are using Six Sigma, Lean or some other variant as Scrum allows for the best-fit elements of definition and implementation to be catered for whilst still managing the requirements, change and planning in a reactive Agile manner.
When integrating your common toolset into Scrum for the first time it is a good idea to take guidance and advice from experienced 'Scrummers‘. Most of all ensure that you stick to the rules, they exist to minimise the risks.
Is Agile a Good Choice for