Preconditions for Agility

Have you ever noticed recurring problems at the end of a sprint (i.e. fixed-length time box)? Many agile teams struggle at times to achieve meaningful results at the conclusion of a sprint. Their work may be:

• Unfinished: “We didn’t finish all of the work we’d planned for the sprint.” In the worst case, little gets done during sprints and work keeps moving from sprint to sprint to sprint. 
• Insufficient: “We’ve been burned by not finishing the work we planned for the sprint, so we’ll just do a lot less work per sprint and easily achieve our forecast.” This results in highly unproductive teams. 
• Inferior: “We’ll make sure to get everything done in the sprint, even if it means cutting corners on quality.” This is a slippery slope, especially when it becomes the norm. 

Hmmmm, okay, so clearly teams struggling at the end of a sprint with unfinished, insufficient or inferior work need to improve. What are some root causes for these problems? How about:

• Too many slow handoffs: The team can’t possibly finish their work during the sprint because they are waiting on too many different people from too many different areas outside of their team. Clearly, this team isn’t truly cross-functional, otherwise they’d have everyone needed to get the work done.
• Unforeseen complexity: The work was much harder than initially thought. The forecast was off because the team didn’t know how complex the work would be. The team needs to better understanding the nature of their work.
• Insufficient understanding of the work: The work isn’t necessarily complex yet it isn’t well understood. As a result, the team doesn’t finish the work because they don’t fully understand what needs to be done. This may mean they have insufficient access to domain experts or product management. Or it may mean that the people specifying the work aren’t clearly communicating the details.
• Unskilled workers: The team forecasts what they could get done during the sprint, but they fail to finish it because they lack the skills necessary to get the work done. The team needs training and/or a few more skilled workers.
• Too many interruptions: The team is constantly being interrupted by other work and this prevents them from completing the work they forecasted for the sprint. This often occurs when there are quality issues with an existing product/service and the team must constantly change course to attend to those issues.

When we look at root causes for problems associated with sprinting, we often find missing preconditions for agility. Like a mirror, sprinting reveals problems. If a team doesn’t inspect and adapt, those problems will recur or worsen.

Sprinting is easy and sprinting well is hard. This fits with what the Scrum Guide says about Scrum itself: it’s hard. One of the hardest parts of Scrum is inspecting and adapting. Few teams do it well. Most teams struggle to explore root causes or do anything about them. For example, when slow handoffs plague a team, is it even possible to recruit the missing players and form a truly cross-functional team? Many teams aren’t empowered to solve the issues that routinely lead to poor results, sprint after sprint. 

Sprinting well — regularly improving as a team and sustainably producing valuable results on a regular cadence — requires inspecting and adapting. If you don’t inspect and adapt, you ignore what is ugly or only make minor changes that don’t address root causes. Many teams begin their agile journey by learning to sprint and then end up doing it poorly. Few of them inspect and adapt effectively. To be fair, most teams that struggle with agility either dwell in a deeply un-agile ecosystem and/or fail to meet preconditions for agility (e.g. being a truly cross-functional team).

So if a sprint is like a mirror, does the team regularly look into that mirror, find what is ugly and make the changes necessary to succeed? 

Many teams struggle with this part. Some feel powerless to change the fundamental issues impeding their agility, some don’t want to be bothered doing the hard work necessary to fix major issues and some are content to only make minor improvements. This does not tend to yield excellent results.

In my experience, it’s better and less hazardous to address as many of the common impediments to agility before teams begin actively working rather than expecting them to do so at the end of sprints. That isn’t to say we don’t need to inspect and adapt along the way. We always need to improve. However, if we start by addressing the most common challenges to being agile, we have a far greater chance of being agile faster and producing better results sooner. 

Preconditions for agility include:

• Forming a genuinely cross-functional team: Ideally, you can do this at the start of an initiative, however, I’ve also seen teams slowly but surely recruit the right people necessary to succeed (and eliminate slow handoffs). 
• Chartering: A vital, ongoing practice to gain alignment and shared understanding of purpose, how people will work together and what success means. 
• Teamwork: Working as a team instead of working in silos is critical for genuine agility.
• Limiting work-in-process: When people or teams or the organization itself is trying to do too much at once, very little gets done. You have to make the tough decisions about what to do and what not to do.
• Learning lean/agile principles and practices: For example, before starting work, training a team in thin slicing and other evolutionary design skills goes a long way towards helping them work in small batches, experience flow, get feedback faster, and be more agile.

What if we began our agile journey by focusing more on how we start than rushing into sprints? Could we be less reactive to our problems and more proactive in setting up conditions for success? 

When I work with teams to produce conditions best suited for agility, there are fewer serious impediments, which makes inspecting and adapting easier. 

When preconditions for agility are in place, a team can focus on implementing lean/agile principles and practices like evolutionary design, continuous flow, experimenting and learning rapidly, building quality in and delivering value continuously. 

When preconditions for agility are in place, a team can work to evolve a product/service that makes end users awesome, seeking feedback and adjusting as they learn. 

Addressing preconditions for agility doesn’t mean you’ll have the perfect start, avoid all problems, sprint perfectly or not have to inspect and adapt. However, it does tend to give teams a far greater chance of being more productive and successful. And that tends to be a lot more fun. 

(Thanks to Maria D’Anzica, Perry Reid, Bill Wake, Tim Ottinger, Ashley Johnson, Mike Rieser, David Luzquinos and David Chilcott for feedback and suggestions on this blog).