We do Scrum but…
“We don’t try out new things - what if it fails?”
Are you serious? — episode 31
The Sprint Retrospective is a pivotal Scrum event:
“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. “ — SG
A plan for improvement. How do you know something is an improvement? And when you can’t answer this question, should you plan to work on it?
Does this question appear far-fetched to you? Then read this discussion that truly happened:
Scrum Master: “We agree upon the thing that bothers us most. We can’t seem to finish the Sprint Backlog Items within the Sprint. Let’s discuss what we can do to improve this.”
Development Team member 1: “I’ve heard about limiting Work In Progress. It’s working on fewer items at the same time. This allows us to have more focus. We would work faster this way.”
Product Owner: “Yes. I like it! We could even take it further: let’s all work on 1 item as a team and when that is ‘done’ move to the next item together.”
Development Team member 2: “No no no! We can’t afford to postpone the other items on the backlog. Everything we take in the Sprint is so important that we need to finish it”.
Scrum Master: “Well, I am happy that this topic of limiting WIP is being considered. Studies show that you will not only finish the most important items faster. You most probably will finish EVERYTHING faster!”
Development Team member 3: “ Hmmmm. I don’t know. Every item we pick up takes more than a Sprint to finish. We have no other option than to work on them from the start to have a remote chance to finish all of them in time.”
Product Owner: “But if you would work on 1 item as a team to get it ‘done’. You’d have focus and you will see that it will be considerably faster.”
Development Team member 4: “Come on! Let’s stop this nonsense! We have 4 developers within the team. They can’t possibly all touch the same code at the same time! That’s just plain stupid. Should people sit on their hands? This idea is stupid.”
Scrum Master: “There are many things you can do to take away this issue. You could Pair Program. You could also do Mob Programming. Plus there are other things you could do instead of coding. The Definition of Done doesn’t only include coding. I see that some of us find it a good idea but others doubt it will work. I suggest to try it. Shall we identify 1 item to experiment with this?”
Development Team member 3: “I hate the idea of staring at the screen with one or more of my colleagues. Only one of us will be effective, the one with the keyboard. The others will only sit there. I highly doubt it will work. I think we should not waste our time on such nonsense. We have important features to build. We can’t afford to try things that might fail. Our time is precious.”
Development Team member 4: “I agree with 3. Our time is too precious to experiment because we risk to fail.”
Scrum Master: “We work with Scrum. Scrum is a framework that allows you to experiment and to learn from this experiment. It’s founded on empiricism. I still suggest to allow us some space to try this”.
Development Team member 4: “Let’s improve on our Daily Scrum instead. Let’s have more focus how we progress with the items and make better agreements when we see we are running behind schedule.”
The discussion continued for another 15 minutes. In the end the Scrum Team decided to take the easy way out. They decided to not try something new because of the risk of failure. So they choose a half-hearted improvement attempt (more focus during Daily Scrum) that proved to be doing virtually nothing to resolve the issues.
Failure is fine
I asked myself why it is that many Scrum Teams don’t take the opportunity to experiment. Why wouldn’t it be OK if something doesn’t work? I firmly believe that it is important to step out of the comfort zone and try new things. In the end that will make you a better and more effective team. I have seen teams experiment and take giant steps while teams that avoid this are standing still. There’s a Dutch expression that translates like:
To stand still is to go backwards.
It means that you have to improve to not fall behind. Improvement is necessary. This is exactly what Scrum is enabling you to do.
Why do some people avoid being out of the comfort zone?
There are several reasons why people wish to avoid risks. Here are a few.
Company culture doesn’t promote thinking out of the box — people are expected stay within the lines. The established practices are correct and should not be questioned.
Company culture doesn’t allow room for change — people are expected to work on stuff that adds direct value. Process improvements don’t add direct value, so it’s not allowed.
Fear of change — change can be scary. You are entering uncharted territory. Think of all the bad things that can happen!
Fear of responsibility — people might fear to take responsibility of the change. The fear to be responsible for failure is higher than the anticipation of success.
If you are so risk averse: how are you doing Scrum?
Scrum is intended to constantly reflect on what you did and learn from this (inspection and adaptation). Scrum has short feedback loops. A Sprint takes a month at most and between 1 and 2 weeks for the most of us. So you will find out quickly if an experiment is worthwhile to continue. You can control risk.
The Scrum Master should encourage this behaviour:
“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
Bottom line
Continuous improvement is very important within Scrum. You will not be efficient in your improvements if you only go for the safe bets. Try things out. Step out of your comfort zone from time to time.
“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.” — Samuel Beckett
If this is scary: gain more knowledge on the topics that hurt your team. There’s plenty of information to find on almost everything you wish to know. This can help to lower the bar, to make it less scary. I can tell you that once you take the first step experimenting becomes addictive. It’s fun. And it is a fast way to giant improvements!
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!
We run a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts.
