Genuine change is complex, unpredictable, time consuming and very difficult to achieve. Sprints (an element of Scrum) are an approach that embraces the characteristics of complex change and can be very valuable tool in your armoury, and one that can really speed up the changes.
Sprints are about applying key principles
The concept of sprinting comes from the software industry and is part of the Agile movement. They were born out of the inability of project management methodologies to cope with the complexities of software development and ensure timely quality software to be delivered. The approach is based on a number of key principles designed to reduce development time and cost, and produce better software. In developing sprints for use in the public sector environment, we have adapted the key Agile Manifesto principles to:
Individuals and interactions over processes and tools
Working solutions over comprehensive documentation
Stakeholder collaboration over contract negotiation
Responding to change over following a plan.
Some parts of the software industry has sadly taken the sprint concept and embedded it within detailed processes and methodologies, which for us, is counter to the 'embracing complexity' approach that saw its birth. Indeed, experience in using this approach demonstrates that the ability to improvise within the constraints of the key principles is required and is part of its appeal. Wrapping sprints into a methodology is restrictive, contravenes the principles and leads to changing the environment to match the methodology rather than embracing and working with the complexity and uncertainty within the environment.
What is a Sprint?
A sprint can be described as an exercise that brings together a group of people (sprint team) with the right capabilities to undertake the delivery and testing of outputs in iterations, within a defined period of time, usually 1 or 2 weeks. The key features of sprints are:
no one is in charge, people involved are there because of skills or knowledge not their position,
a co-ordinator organises and helps the sprint team (Scrum calls this role Scrum Master),
everyone on the sprint team has committed time to the work during the sprint,
there is no pre planning, all planning is undertaken in a 'just in time' manner,
planning is undertaken on a wall using post-it notes (so it is accessible all the time) or alternatively Trello is a useful app if everyone isn't working from the same building,
regular (usually daily) very short meetings, stood up, are held to review barriers and adapt plans,
reviews (or retrospectives) are held in each sprint, aiding the learning and adaption of the approach to the specific environment and sprint team,
early versions of outputs are generated to allow wider testing, input and adaption.
The success we've had from some sprints has been astounding. In one case a high priority complex set of outputs had failed to deliver for over 12 months. Pulling together a small sprint team from different disciplines for two weeks achieved 75% of the outputs, and a later sprint completed them all. Another of our sprints stopped half way through, having identified a previously unknown but significant barrier, although seen as a failure by some, the identification of the barrier allowed focus to shift and has ultimately accelerated change.
So why are they successful? It's simple, in a complex world, the interactions people have are more important than the process. Having early visible outputs that people can see, produces significantly better quality outputs, and finally, adapting to a situation through flexible just in time planning is more effective than detail design something up front and being a slave to a plan.
Sprint examples from the public sector
The message is clear, to accelerate change, bring people together to collaborate and develop outputs, enabling them to adapt their approach as they go. Sprints are a simple and effective way to do this. The following illustrates sprints we've run in public sector organisations:
focused on the development of an integrated care model a sprint group encountered an information governance blocker that couldn't immediately be overcome. The sprint was halted part way through. The group acknowledged the sprint as a success, despite its premature end. It would have taken months to find and understand the information governance blocker had the sprint not occured.
seeking to develop a multi organisation partnership OD Strategy with a group of people with limited time, the sprint was split into two shorter sprints (perhaps dashes!), with a gap of around 3 weeks between them. This was the only way we could secure the right people and capabilities to be part of the sprint. Successful outcome, a multi organisation OD Strategy developed within 4 weeks with five days of active work.
using a series of sprints, end to end (a bit like Scrum), a small team was able to build a large complex business case in iterations. For each iteration, different people/capabilities were added to the team from different functions. This allowed 8 iterations of the case to be developed, aided the socialisation of the case with senior leaders, and more effectively and predictably used scarce capabilities.
for a piece of work to develop a strategic plan, based on a series of high level Models of Care, a sprint approach was established. In this case, the large team running this highly complex work, generated a rolling sprint that lasted for around 3 months. Within a framework of milestones, the team generated objectives for the week and setout the activities to achieve these, rolling any outstanding activities into the following week. This approach achieved an incredible level of pace and achieved what many had thought impossible in the available time. One senior leader commented that although the overall programme was behind schedule, this process had caught up 3 months within 3 months (i.e. 6 months work in 3 months). Additionally, the positivity and shared commitment from the team around this adaption and the sense of achievement has been greater than they had seen before.
The most successful sprint we've been part of to date, sought to resolve a long standing inability to deal with a backlog of 50+ clincial guidelines that had been a problem for 12 months or so. By drawing the right people into a sprint, the key guidelines were resolved within a week and the remainder in a following sprint.
another sprint from one of our team sought to tackle a two year plus technology issue in a busy A&E department This was causing unnecessary clinical risk and inefficiencies in one part of the department. The sprint brought together the key people from different departments and by day three had developed a solution and implemented it by the end of the week.
From the examples above, there's no single way right way to run sprints. Whilst we have learnt a lot through trial and error, we're still learning. Many people we've worked with have adopted the approach, and although initially skeptical, have really started to embrace and adapt with amazing results.
Sprints work
It is clear from the sprints we've undertaken and seen that they really do accelerate change in a complex world, however they do need to be adapted to meet specific circumstances whilst staying true to the four key underpinning principles.
If you want to know more about how you can use sprints to accelerate your change contact us at steve@getrealchange.co.uk