Get certified - Transform your world of work today

Golf and Scrum

10/31/2012 by Krystian Kaczor


A colleague from my team started playing golf lately. 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. To my surprise, I found out that these days equipment is not expensive, and you don't need to be a club member to play.

Also to my surprise, I learned that hitting the ball wasn't as easy as you might imagine. You take the club, take your position, and hit the ball with it. Club, ball, swing, and . . . miss. 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.

Still, trying golf was a lot of fun and I like getting out of my comfort zone, so I decided to take some basic training. What surprised me most were two remarks from one of the professional trainers. Let me share with you these two tips, as applicable to Scrum as to golf:

  • Don't focus on the ball, focus on the swing. The ball is only an indicator, showing you how well you've hit the ball.
  • If you don't see and focus on the water obstacle, you're more likely to send the ball over it.


Tip #1: Don't focus on the ball.

Playing golf is about hitting the ball and sending it to the hole. The fewer number of times you hit the ball to get to the hole, the better. But the ball is only an indicator of your techniques (swing, position, controlling force, grip) and understanding of the environment (wind, terrain). In order to succeed, you need to master your skills and be completely in the here and now. Focus on the hole, make the movement as perfect as possible, and the ball will show you how well you're doing.

Using Scrum is about doing everything needed to deliver the minimal product increment at the end of the iteration. Indicators of the process are the burn-down charts: issue burn-down chart, hours burn-down chart, product backlog burn-down chart, release burn-down chart. The higher your velocity, the better.

Do you see the similarities? The most common mistakes that teams using Scrum make are these:

  • Teams focus on ideal sprint burn-down.
  • The project manager or, even worse, the ScrumMaster, encourage the team to lower its estimates to keep the sprint burn-down or product burn-down looking good.
  • New tasks defined during the sprint, and reported bugs, don't get estimates because that would make the sprint burn-down look bad.
  • The concept of the "ideal day" is forgotten, and developers expect the team to register eight hours daily. "They need to work eight hours because we pay them for eight," they'll say. 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 a velocity as possible. In fact, usually it's about getting the highest number possible, without looking at delivery.

What is the result of these practices? You can have ideal sprint burn-down or ideal product burn-down, but the product owner won't be happy because there was no delivery, or delivery was too low. The next sprint will be a total disaster, because it will be full of finishing up and bug fixing. It's possible that the burn-down will go to zero at the end of the sprint, but there will be a bunch of incompleted tasks and unfinished user stories.

Why is this happening? Simply because the focus was 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 burn-downs or better velocity. The role of the burn-down is to indicate progress and let you know when you need to adapt your work or technique. Let the team learn how to estimate correctly and how to do the work. When they learn this (which takes time), the burn-downs will fix themselves. Burn-down is not a goal, nor is it the problem itself; it's the symptom, the indicator we can use to inspect what really needs to be changed, so that we can adapt.

Also, when the team uses the inspect-and-adapt loop correctly, velocity will grow naturally. Removing obstacles and optimizing 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 technique, and the ball will follow.


Tip #2: Focus on the goal instead of on the obstacles.

Probably you have seen that on a golf course there are obstacles, like water, bushes, or sand. You need to avoid or conquer them on the way to the hole. And quite often, the player focuses so much on not aiming at the obstacle that ultimately he sends the ball exactly where it shouldn't go.

The root cause of this lies in the following principle: The brain does not interpret the word no. If you read this: Do not imagine a big green ogre, I'm quite sure that an image of an ogre just flashed into your mind. You need to create a representation of what not to do, and then you need to cross it with some kind of red line and make it disappear.

The fact is that even beginners in golf can send a ball for at least eighty meters with ease. The water obstacle is fifty meters away, so he or she has at least thirty meters of error margin. The only thing you need to do is to focus on the hole, make that perfect move you practiced so many times, and the ball will go over the obstacle. But what really happens is that the player focuses on the water, and the ball tends to land right in it.

Let's look at how this principle plays out in Scrum. Scrum teams focus on:

  • Not having any bugs
  • Automating all the test cases
  • Getting 100 percent test coverage
  • Having as flexible an architecture as possible
  • Gold-plating and looking for the perfect solution
  • Spending days on changing graphic design and building "prototypes"

And the end result is a failed Sprint. What was the Sprint goal? Whatever it was, it was none of the above.

Writing unit tests does not prevent bugs, it only validates the programmer's way of thinking. TDD is a way of organizing architecture and code, not a testing technique, and that is often misunderstood. When you focus on testing all possible cases without looking at the risk analysis, you take the risk of having only a partially tested sprint, which can be rejected by the product owner or will jeopardize the next sprint. When you look for the perfect solution, you'll spend too much time on one task and won't have that time for the others. Remember that the most important goal is to deliver the product increment. It doesn't need to be fully featured and beautiful, but it does need to be done.

You see now that same good practice rules apply to many different areas of life. This they were presented by comparing playing golf and using the Scrum framework. Both seem to be simple — and in some ways they are — but they require a lot of practice, and they require mastery of technique.



  • Keep your eyes and mind fixed on the goal.
  • Don't try to make figures, charts, and other indicators look good. The indicators should indicate the actual state; they'll look good when you adapt the practice.
  • Do difficult things first and prioritize correctly. Try different tools and approaches until you find them easy.
  • Avoiding obstacles and solving issues is part of the game, and that will become natural when you keep in mind the sprint goal and the product delivery that you want to complete.


People say that you play golf to relax, and that to play golf you need to be relaxed. To be Agile you need to be professional, and to be professional you need be Agile.