All methods have inherent pitfalls that can readily derail even the simplest project.
Based on hard-earned experience, I explain why what happens outside of the Scrum team matters more than you think and what you can do to prepare for the inevitable. This is number 2 of a 3 part series, focusing on characteristics of Scrum that are essential to successfully using the technique.
Adopting Scrum for your project effectively means enclosing the team in a process bubble. This is not an explicit requirement; it is a result of the method. The bubble normally contains the necessary artifacts (i.e. product backlog, burn down charts, etc.) and behaviors (i.e. daily scrum, calculating story points, etc.) to develop a solution. As long as the team has control over the bubble, they can move at a self-determined pace. But what happens when the process is disrupted or altered by circumstances or events outside the bubble? It slows down or stops.
Since the Scrum method calls for a small-group, cross-functional team approach, any activity that can’t be satisfied by the immediate team is a candidate for bubble bursting. Here’s some common technology activities typically outside the Scrum bubble:
- subject matter expert availability
- infrastructure requirements
- security considerations
- access to critical apps or data
Likewise from a business perspective here are some items that can have similar effects:
- subject matter expert availability
- conflicting governance/approval processes
- capital planning and budgets
In fact, most if not all of the existing external factors that affect any project will affect a Scrum-managed effort, but with greater impact. This sensitivity to externalities is what makes the Scrum method fragile.
How susceptible is any project to outside impacts? The number of impacts is generally determined by the both the size and complexity of the finished result. Small, simple solutions have few external dependencies. Large, complex solutions have many opportunities for interconnections (and influences); exactly what you would expect in a typical risk scenario. But the risk can be exacerbated rather than mitigated if Scrum’s susceptibility to external issues is not addressed.
A 3 step process to reduce Scrum’s sensitivity to external forces:
- Work out potential cross-functional needs ahead of time. Develop and iterate through some likely scenarios to determine where needs outside the team will exist. For obvious reasons this is best done with the team.
- Understand and potentially renegotiate any organizational communication protocols. Depending on how Scrum has been implemented, existing communication protocols may not be conducive to the method. Identify where changes are necessary. To reduce confusion, codify and publish the protocols so everyone has the same reference.
- Map known service level expectations against the method. Using the scenarios from #1 and the communication protocols from #2, do the same analysis, but with an eye toward timing and the effect on Sprints. This exercise may affect the velocity at which the team can produce, but also the sequence in which user stories should or can be addressed.
The only way to protect the team’s bubble and defend against its bursting is to fully understand the risks. Risks not only to the project at large, but risks related to the method itself. For best results this needs to happen before the team actually starts. Skipping this activity hoping that the impacts will be small and manageable is not recommended. The good news is that over time and with practice, mitigating the risks associated with Scrum bubble bursting for your organization can become easier and easier.
