Golf and Scrum

31 October 2012

Introduction

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.

 

Conclusion

  • 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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Tom Mellor, CST,CSP,CSM,CSPO, 10/31/2012 2:05:08 PM
Scrum, like golf and martial arts, benefits from the concept of shu ha ri (http://scrum.jeffsutherland.com/2011/05/shu-ha-ri-what-makes-great-scrummaster.html and http://www.pmhut.com/the-shu-ha-ri-of-scrum.) Many organizations and their teams take up Scrum like many people take up Scrum - they go out and hack away. Some come to the realization that a good coach (sensei) would bring improvement, but they also must come to the realization that all of the old muscle memory from the "old ways" must be vanquished - the mind (and body) must be cleared of old ways.


I have played golf for over 40 years and have had many golf senseis help me with my game. It is necessary to revisit the masters from time to time to correct inconsistencies that have crept into the game. That is the notion of kaizen.

We also have an addage in golf: "It isn't how good your good shots are; it's how bad your bad shots are." Same with Scrum: it isn't how good your good Scrum is, but rather it is how bad your bad Scrum is (how bad its "Scrum, but" is.) Also, analytics in golf (http://www.golfdigest.com/golf-instruction/2008-05/challengestats) reveal that half or more of the shots are putts, so the more effective a person is at putting, the more improvement they will see in the game. Also, 65% to 70%of all shots are hit inside 30 yards of the hole (including putts, of course.) So, it not only behooves a person to putt well, but to also be able to chip well. The difference between a 90 and 75 is 15 shots and if a person can improve just the "short game" by 10 to 20% then they would take an average 5 to 11 shots off their 90. Considering that less than 10% of golfers break 85, it is worth the improvement investment if improvement is really the goal.

Code makes up the shots in Scrum. How quality the code is determines a lot about the quality of the product. Like golfers, not all coders are equal, but collectively they can be really good. That is the heart of scrum - community effort and responsibility.
Krystian Kaczor, CSP,CSM, 10/31/2012 5:00:31 PM
Great comment Tom. Thank you.
John Hill, CSP,CSM,CSPO, 11/1/2012 12:22:36 PM
Krystian (and Tom): Great stuff here! IΓÇÖve also used a couple of analogies between Scrum and Golf, including one for time-boxed ΓÇ£fixed dateΓÇ¥ releases (where schedule and quality must be preserved with scope being the variable). For these releases itΓÇÖs imperative that the highest-ordered backlog items be completed first (in case scope needs to be reduced to ensure schedule). Any time the Development Team asks if the date can slip in order to achieve 100% planned content, I remind them of legendary golfer Ben HoganΓÇÖs words: ΓÇ£The only thing a golfer needs is more daylightΓÇ¥. Because the sun sets on the release date we can no longer play in the dark! John H.
Krystian Kaczor, CSP,CSM, 11/1/2012 2:32:59 PM
Thanks John. I like the direction discussion is going. Who else can come up with golf metaphors and maybe is already using them to work with the team?

You must Login or Signup to comment.