We do Scrum but…
“Scrum wears us down, we don’t get any respite”
Are you serious? — episode 13
I know people that favor the pace of good old ‘Waterfall’ projects. It’s not that they believe that this is the right way to build software, but at least you didn’t always feel pressured.
Generally Waterfall projects started relaxed. Then you’d come in a certain sustainable mode and at the end it was crunch time: a lot of overtime and stress right before launching the product and just after launching. Then, all of a sudden, the pressure was off. The project was done. You’d start working on a new project, starting with an easy pace. You’d have time to breathe before fully diving into a new adventure.
Compare that to the constant routine of Sprints without any respite, getting completely drained at the end of the Sprint because the next Sprint starts immediately.
I believe this doesn’t have to be the case. What’s more: it shouldn’t be the case.
What could be reasons behind this problem?
Here are issues that I have personally observed that fuelled this fire for my teams:
- During Sprint Planning more items were put on the Sprint Backlog than the average of the finished items in recent Sprints.
- The Sprint Backlog was seen as commitment, signed with blood. Items needed to be finalized at any cost, ignoring new insights that came to light during the Sprint.
- The Scrum Team got objectives to establish a growth of the velocity of 20% per year. While the idea of the objectives might have lied in encouraging effectiveness it often simply meant that more items were put on the Sprint Backlog, regardless if this was deemed feasible.
- The Product Owner decided what would be picked up for the next Sprint. The Development Team hardly had any voice in this.
- Items were added mid-Sprint without considering the impact on the items that already were on the Sprint Backlog.
Is it any wonder that it felt like being trapped in a time loop?
All of the points mentioned are Scrum anti-patterns. They ignore one or more important aspects of Scrum, starting with how items are planned:
“The input to this meeting (The Sprint Planning, WJA) is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — SG
This is essential: the Development Team alone can tell what is possible, no one else. Here’s more food for thought on that:
“Development Teams are structured and empowered by the organization to organize and manage their own work.” — SG
Then there’s the topic of being under constant pressure to deliver more:
“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.” — SG
There’s a balance here. A Scrum Team seeks to improve effectiveness. But it should also be an enjoyable working environment.
Enjoyable: this single word in the Scrum Guide that makes all the difference. The development process should be enjoyable!
On the topic of adding items mid-Sprint:
“ As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.” — SG
This is completely in line with the earlier statement that the Development Team organizes and manages their own work.
Then there’s the topic of stress levels going up near the end of the Sprint:
“The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.” — SG
The Sprint Backlog is a forecast, not a commitment of the planned functionality and the work needed to deliver this. The Scrum Team however does commit to the Sprint Goal, not to individual Backlog Items.
Commitment means doing your best to succeed within reason AND inform involved parties when important insights emerge.
Scrum is a framework based on empiricism: to be transparent, inspect and adapt. You will receive information during the Sprint that you didn’t have at the time of the Sprint Planning which will have an impact on your Sprint Backlog. That is the whole point. And that is why it’s an anti-pattern you ignore all of this when it comes to what you can deliver at the end of the Sprint.
Obviously there’s an important role for the Scrum Master here:
“Coaching the Development Team in self-organization and cross-functionality” — SG
My own case
I had teams struggle with this topic. So I challenged them to experiment with how they approach a Sprint. Below are some things we tried (note that what worked for us might not work for you. Environments can differ, individuals certainly differ):
- During Sprint Planning we filled the Sprint Backlog with a percentage of the capacity (we’ve tried several percentages between 50 and 80% of the capacity) and everything we could do on top of this was considered a bonus.
- During Sprint Planning we put all items on the backlog that we thought we could complete. We defined 1 or 2 items as ‘we will be successful when we complete these’ and the remaining items as ‘nice if these also can be completed’.
- We swarmed. Which meant that the whole team worked on 1 item until it was finished and then moved to the next item instead of working on 4 or more items at the same time.
- We planned time for experiments in all sorts of areas (way of working, way of communicating, coding standards, etc …) with the aim to improve.
We found that the team could complete items faster if they focused on fewer issues, limiting Work in Progress (which is no eye-opener for you I’m sure). It brought us focus, a feeling of ownership, enhanced team spirit and it brought faster delivery. And on top of that: stress levels went down. The team was happier.
You could argue that when you work on fewer items that you either start gold-plating or that you’d procrastinate (you have plenty of time after all). And as a result get less done. I have not seen this happen with my teams. Perhaps this is because we have a very clear Definition of Done and with that a clear understanding on what to do (and what not to do).
Does the way you Scrum wear you down? That should not happen! It doesn’t need to happen! Make sure that:
- The Development Team determines what it can take in for the next Sprint.
- The Development Team owns the Sprint Backlog. Hence they determine what goes on the Sprint Backlog and -if applicable- how the Sprint Backlog is changed.
- The Development Team organizes and manages their own work.
- The team treats the Sprint Backlog as a forecast, not as a contract signed with blood.
- The team uses empiricism (transparency, inspection, adaptation).
- The Scrum Team seeks for ways to be more effective AND make the Sprints enjoyable.
- The Team uses the Sprint Retrospective effectively. Reflect on how the Sprint went and create a plan for improvements for the next Sprint.
- The Scrum Master coaches the Development Team in self-organization.
And remember: the Development Team determines what they put on the Sprint Backlog, they have a vital say in what the Sprint Goal is (as part of the Scrum Team) and on top of that they organize and manage their own work! The Development Team has all this power. Now use that power and don’t let yourself get drained.
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling
Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!