Introduction
A colleague from my team started playing golf lately. Totally unexpectedly for me, I found out that these days equipment is not expensive any more and you do not need to be a club member. Since playing golf alone is not as much fun as playing together and having some competition, my colleague persuaded me to give it a try. Surprise, surprise; hitting the ball wasn’t that easy as you could imagine. You take a stick a.k.a. club, take your position and hit the ball with it. Club, ball, swing and … missed. Why? Because you need to practice the basics first. And playing golf is not about hitting the ball. Playing golf is about perfecting your movements and hitting the ball is just a side effect. Isn’t it the same with practicing Scrum? It seems to be easy and the Scrum Guide has only little over twenty pages.
Still trying golf was a lot of fun and I liked getting out of my comfort zone, so I decided to take the basic training. What surprised me the most where the two remarks from one of the professional trainers. Let me share with you these two universal tips.
2 universal tips that you can use in Scrum
- Do not focus on the ball. Focus on the swing. The ball is only an indicator showing you how you have hit the ball.
- If you would not see and focus on the water obstacle, you would send the ball further than that.
#1 Do not focus on the ball
Playing golf is about hitting the ball and sending it to the hole. The ball is only an indicator or your techniques (swing, position, controlling force, grip) and understanding of the environment (wind, terrain). The less number of times you hit the ball to get to the hole, the better. In order to succeed you need to master your skills and be totally here and now. Focus on the hole, make the movement as perfect as possible and the ball will show you how well you are doing.
Using Scrum is about doing everything what is needed to deliver the minimal Product Increment at the end of the Iteration. Indicators of the process are the burndown charts: Issue Burndown Chart, Hours Burndown Chart, Product Backlog Burndown Chart, Release Burndown Chart. The higher Velocity you have, the better.
Do you see the similarities now?
The most common mistakes that the teams using Scrum make are:
- Teams focus on ideal Sprint Burndown,
- The Project Manager, or even worse Scrum Master, encourage to push the Team to lower the estimates to keep the Sprint Burndown or Product Burndown look good,
- New tasks defined during the Sprint and reported bugs do not have estimates because that would make Sprint Burndown look bad,
- The concept of Ideal Day is forgotten and it is expected from Developers to register eight hours daily. They need to work eight hours because we pay them for eight, one will say, and the effect is that Sprint capacity in hours is blown out. You plan for failure.
- The whole vision and purpose of doing Scrum is understood as getting as high Velocity as possible. In fact usually it is about getting the highest number as possible without looking at delivery.
What is the result of these practices? You can have ideal Sprint Burndown or Ideal Product Burndown, lines will meet, but … the Product Owner won’t be happy because there was no delivery or delivery was too low. Next Sprint will be a total disaster because it will be full of finishing off and bug-fixing. It’s possible that the burndown will go to zero at the end of the Sprint, but there will be a bunch of un-DONE tasks and unfinished User Stories.
Why is this happening? Because you focused on the wrong thing. The goal of the Sprint is to deliver a Product Increment – working software that can be shipped to the customer. Not to have nice burndowns nor better Velocity. The burndowns’ role is to indicate the progress and let you know when you need to adapt your work or techniques. Let the Team learn how to estimate correctly and how to do the work. When they will learn this (which takes time), the burndowns will fix themselves. Burndown is not a goal nor is it the problem itself, it’s the symptom, the indicator to inspect and adapt what really needs to be changed. Also, when the Team uses the Inspect – Adapt loop correctly the Velocity will grow naturally. Removing obstacles and optimizing the work is the way to have higher productivity not the other way around. Pay attention to what is a problem, and what is only a symptom of the problem. So dear golfer, watch your techniques, the ball will follow.
Was this post helpful?
More articles
from
31.3.2021 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.