How to escape your Scrum prison
How to escape your Scrum prison
Make common sense prevail over bureaucracy
Here’s my favorite part of the Scrum Guide:
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. — Scrum Guide, Nov 2017
Unfortunately, most Scrum Teams lose this essence somewhere along the way. It becomes more important to follow a subjective, dogmatic interpretation of Scrum by the letter, rather than being flexible and adaptive. Blindly following the rules offers a sense of comfort the uncertainty of carving out your own way can’t provide.
The Sprint Backlog is treated as a contract. Meeting initial promises is more important than doing what’s best in the moment. Changes to the Sprint Backlog are actively discouraged. Bureaucracy prevails over common sense.
Every team lives in its own Sprint bubble, afraid of interacting with other teams, fearful of being asked to make changes to their Sprint. Keeping the Sprint bubble intact becomes a goal by itself.
When the Sprint Backlog is locked, teams get stuck in Scrum prison. Locked-up teams experience the limits and friction caused by self-imposed jail bars. Team members no longer enjoy the freedom necessary to do a good job. Development Team members get reduced to cogs, and often start hating their job as a result.
The job becomes to deliver Backlog Items by contract. Creativity, flexibility, and using the latest, freshest insights are discouraged. What was written down, initially planned and promised, is what matters most. Team members secretly start working on issues and fixing technical debt off the books to have some semblance of autonomy. This approach ensures the completed work is safely hidden away from burn-down charts, which are carefully scrutinized and monitored.
You can instantly identify teams where this has happened:
“Our team can’t help your team with your request, as our Sprint has already started. You should have reached out to us before the Sprint started.”
“You can only get something changed in our Sprint if you address our Scrum Master first.”
“We can’t drag work into the Sprint until we had a refinement session with the whole team.”
“We had too many changes during the Sprint. We definitely should reflect on this at the Sprint Retrospective as our burn-down chart looks off.”
“We must re-estimate the Sprint Backlog Item because the Acceptance Criteria have changed.”
“We cannot add work to the Sprint Backlog during the Sprint, because it will hurt our velocity.”
All of these teams are stuck in Scrum prison. The soul gets sucked out of these teams. Following the plan is more important than doing what is best for the company. Following “Scrum”, is more important than doing the right thing. The team is reduced to an assembly line where Backlog Items enter, and features come out. Adherence to initial plans and predictions is celebrated, so everybody on the team is inspired to put on their best bean-counting hats.
Here are some of the common symptoms your team is in Scrum prison:
Stable velocity is the holy grail of team performance.
The team spends many hours in Sprint Planning to come up with a perfect plan that never pans out.
The Sprint Backlog does not belong to the team, but to the Product Owner or Scrum Master who needs to give their blessing to all changes.
Technical debt or bugs are not added during the Sprint. We need to plan them for the next Sprint first. Even if we have time to fix some things now.
Changes to the Sprint Backlog are actively discouraged because we promised to deliver all items in the Sprint Backlog.
Definition of Ready acts as a gatekeeper to the Sprint Backlog. If it ain’t ready, it’s dead to us.
Having a pretty looking burn-down chart becomes a goal by itself.
The Sprint Backlog is fluid only during Sprint Planning. After that, it’s frozen.
Teams with these symptoms are impossible to collaborate with. When you ask for help, or even worse, ask if they can fix something, then the answer you always get is that they don’t have time for you. Please come back next Sprint.
What’s the alternative to living Scrum prison?
The alternative: living in freedom and carving your own path
The freedom to learn, experiment and make mistakes. The freedom to determine your own way of working. How does this work? Let me show you how I like to work with my teams as a Product Owner
Every Sprint, we craft a clear Sprint Goal we decide on together. That’s the only thing we commit to every Sprint. There is no commitment to individual Backlog Items or Acceptance Criteria. Flexibility, as we learn more is actively encouraged. Nothing we start working on is perfect from the beginning, and we add details and polish during the Sprint.
Nobody really cares about velocity. Did we accomplish the Sprint Goal? Then our velocity was stable enough, and we’ve reached the outcome we set out to achieve. The outcome is more important than the output. I’d rather do less but achieve more value.
The Sprint Goal relates somewhere in the range of 40 to 80% of the Sprint Backlog. We never commit 100% of our capacity to the Sprint Backlog, because you must leave room to deal with the unexpected. The more complicated, risky, and uncertain the Sprint Goal, the lower this percentage.
All Sprint Backlog Items relating to the Sprint Goal are completely flexible, as long as Sprint Goal is not at risk.
All Sprint Backlog Items not relating to the Sprint Goal are treated as Stretch Goals. No commitment is made to completing these. We work on these on a best effort basis.
Team members enjoy complete freedom to add, remove, or change Sprint Backlog Items as necessary. As a Product Owner, I trust them to make the right call. I’d prefer they make a mistake every now and then and learn from it, then that they always need me to prevent mistakes. Otherwise, my role stops being scaleable across multiple teams.
Sprint Planning takes 1 hour or less for a Sprint of 2 weeks. You need little planning if you grant the team the freedom to allow the Sprint Backlog to emerge during the Sprint and the Sprint Goal is the only commitment.
Sprint Backlog is owned by The Development Team, and they are allowed to add, remove, or change the Sprint Backlog as they see fit. If it affects value, and they have doubts, they are trusted to consult the Product Owner before making changes.
Technical debt or bugs are added at the discretion of the Development Team during the Sprint. You wouldn’t tell a cook how often they should clean their kitchen while cooking. Developers on our team are given the same courtesy to fix issues as they see fit, as long as the Sprint Goal is not at risk.
Refinement sessions are swift and fun. Everybody chimes in, and the Product Backlog Item is the work product of the whole team. It is more important to understand what we’re trying to achieve than to write it down perfectly in the form of a contract. Common understanding, trust, and buy-in beat enforcing the team to meet a fallible and incomplete contract.
Changes to the Sprint Backlog are actively encouraged during the whole Sprint. Changing the Sprint Backlog means we have learned something new we can benefit from, which is great!
Definition of Ready gets thrown out the door. Do we believe it fits in a Sprint? Great, let’s get going already!
Burn-down charts? Who cares really. If we meet the Sprint Goal, then all is good.
When members of other teams ask us for help, we make time for them and help them out. We have room to do this because we do not plan at full capacity. Sometimes we even accept not being able to meet the Sprint Goal, if what they are doing is more valuable to the company.
It is my job as a Product Owner to get everybody on the same page about how we deliver value to customers and the business. Scrum can only deliver products of the highest possible value when it becomes a team effort. That’s why I trust the team to make the right changes because my main job is to make sure everyone cares about building the right thing as much as me.
Working with Scrum should be fun, immersive, and liberating. Imagine you are playing football, and during the game, everybody continually talks about the rules. You will immediately stop enjoying the game. Scrum is there to serve the team. To help them to deliver products of the highest possible value. Scrum should not throw up roadblocks or add unnecessary bureaucracy that stands in the way from getting the job done.
At the core of Scrum are self-organizing, cross-functional teams that work towards a clear goal every single Sprint. How the team works, designs their working process and achieves the Sprint Goal is up to them. If Scrum feels like a weight dragging you down, take a close look at how you are doing Scrum. I hope you will remember my favorite sentence from the Scrum Guide:
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. — Scrum Guide, Nov 2017
If your team is not flexible and adaptive, you can forget about succeeding with Scrum in any shape or form. The rules of Scrum are there to serve and liberate the team, not to constrict and ring-fence you from doing what you actually want to do.
The point of Scrum is to help teams to figure out the best way of working to support delivering products of the highest possible value. When Scrum becomes the point, and following the rules becomes the goal, then Scrum prison is inevitable. Scrum becomes a hollow shell of what it could be. Instead of empowering people, it disempowers.
Scrum is never the point. Scrum doesn’t tell you what to do, it shows what is going on. Scrum always puts the ball in your court to do something about it, in a way that best fits your situation. Most people that complain about Scrum, are actually whining about the poor decisions their team or organisation made.
All Scrum prisons are self-invented. It’s up to you to break down the imaginary walls that have been thrown up.