Stop treating your Sprints like Fort Knox
Most companies don’t need a scaling framework to succeed with multi-team Scrum
Unfortunately, you work at a company where all teams operate in silos. Whenever you unexpectedly need to ask another team for help because you depend on them — you’re screwed. It’s the equivalent of a Sprint game-over.
When asking for help you’ll often get a reply along the lines of:
“Why are you bothering us with this now? You could have known about this before. Our Sprint has already started, you’re too late. Our Sprint is full, and we have an important project we need to deliver. Please don’t bother us, and we don’t expect to be able to help you in the next couple of Sprints.”
With that, your frustration shoots through the roof. Why don’t we just try to help each other out, is it really that difficult to extend a helping hand? The other team has their own commitments to meet and are unwilling to put this at risk by helping anyone.
A common phenomenon in Scrum happens after the Sprint has started — teams lock their Sprints tighter than Fort Knox. Changing your Sprint, or worse, asking another team for help means losing face. You are admitting you’ve failed to take everything into account. It could also mean punishment, as everything present in the Sprint is the goal. Anything less than everything is disappointing.
A team member proposes to solve these collaboration issues by introducing a scaling framework. We’re suffering from scaling problems because we’re operating many teams working on the same product. If we just pick the right framework out of the many scaling options — Scrum@Scale, SAFe, LeSS, Nexus, or Scrum of Scrums — then we’re golden.
This belief is misguided. A scaling framework will never resolve inflexibility within and between teams.
You can’t coordinate what you don’t know
Humans are fallible creatures, and product development is highly complex and uncertain. Eternal planning, analysis, design, and coordination won’t prevent all mistakes. And even if you could do a perfect job, there is always stuff you can’t know before you start doing the work. The problems caused by unknowns that reveal themselves are what throws sand in your gears.
When teams do not have time to help each other, this is often incorrectly perceived as a coordination problem. Most teams attempt to solve the problem of collaboration and communication by introducing a scaling framework. Let’s do Scrum of Scrums, Nexus, or LeSS, to improve how our teams collaborate and communicate with each other.
But how do you collaborate and coordinate on something you don’t know yet? At best, you’ll just communicate the same thing as before, but instead it will be at a predefined and orchestrated moment. The underlying inflexibility will not be resolved by the scaling framework.
Scrum Teams should be flexible, also towards each other. Here’s the relevant passage from the Scrum Guide:
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive
How flexible and adaptive is it if you need a scaling framework to formalize interactions that make coordination and collaboration possible? You don’t need a scaling framework to make teams flexible towards each other. Scrum done right provides flexibility by default.
Scrum has a flexible and adaptive foundation of empiricism by design. More is unknown than known in a complex environment, and you should make decisions based on what is known. Making decisions on the spot means (re)acting based on the latest information.
To be able to act with the latest and best information as it is discovered, you need flexibility. You need to make room for emergence in your plans as more is learned.
Four ingredients of flexibility
For teams to be flexible towards each other, you need four elements:
Sprint Goal. A mandatory, overarching objective that does not utilize the full capacity of the Scrum Team. The Scrum Team only plans at a maximum of 70% capacity to optimize flow and to be able to deal with the unexpected. Fully occupied Scrum Teams will never have room to handle the unexpected or help each other.
Sprint Backlog flexibility. The Sprint Backlog emerges during the Sprint, and the team tries to come up with the least complex way to meet the Sprint Goal. It’s okay if Sprint Backlog items carry-over to next Sprint that do not relate to the Sprint Goal.
Inter-team flexibility. When another team asks for help, you make time to help them out. The default stance should be to collaborate, instead of to negotiate. Of course, if the request puts the Sprint Goal at risk, then it’s a different story. You can still help to the extent that you don’t put the Sprint Goal at risk. You could also make the joint decision to make one Sprint Goal more important than the other, if that results in more value to the company. Of course, this is something for the Scrum Teams (including Product Owners) to decide.
Psychological safety. If teams get punished for taking initiative and making decisions, then you will destroy all initiative. Sticking to the original plan becomes the default option even if it doesn’t make sense.
Even when you have these four elements in place, how you deal with failure to meet Sprint Goals plays a key role in how flexible your teams will be.
Not meeting the Sprint Goal shouldn’t be necessarily seen as a failure, if the team gave it their all. Not meeting the Sprint Goal is often a failure of expectations: the Sprint Goal was more complicated than expected. It may be that the team made the most progress it could, given the circumstances. That’s still a win and not something to be bitter about.
It could also be that one team doesn’t meet their Sprint Goal because they helped another team with a more valuable Sprint Goal. How can this be perceived as something bad? More value was delivered at the expense of a Sprint Goal of lesser value. Teamwork should extend further than a single Scrum Team. Teamwork should spread across different Scrum Teams working on the same product.
If the Sprint Goal isn’t met because the team isn’t working effectively or other problems that need to be resolved, this is a valuable insight— something to reflect upon and try to learn from, rather than punish.
What scaling problem are you trying to solve?
Think about what problem you’re trying to solve the next time somebody says: ”Let’s use a scaling framework. Scaling frameworks won’t magically make teams flexible towards each other. Orchestrated communication and coordination does not magically produce flexibility, when the unforeseen happens. Scaling frameworks can just add unnecessary layers of Bureaucracy, while the underlying problems remain.
If flexibility is your biggest problem you should fix this first. Afterwards evaluate whether you still need a scaling framework. A Fort Knox approach is excellent if you wanna keep people out — there is a reason James Bond is the only person to have attempted to break in Fort Knox — but it doesn’t work if you need to have a lively collaboration between many teams.