Skip to main content


What do hitting a golf ball and software development have in common?

Well I'll tell you...consistency and quality.

Tad-da...I present to you, AGA..Agile Golf Analogy...that's right folks, you heard it here first. The next time you hear "We've just duffed the project into the rough" or "We're in a bunker with the workflow components" you know there it originated.

I've have a couple of conversations over the last few days about our experiences using SCRUM and as usual there was lots of interesting thoughts and theories to emerge. It wasn't until I was at a driving range with some other guys from work and one of them said "it's the same swing just a different club" that it hit me. The key to a great golf swing is absolute consistency in the rhythm, effort, control and technique you use. The golf club does the hard work for you.

  • Your shot is your Sprint.
  • Your swing is your project team.
  • Your club is your engineering practices.
  • Your ball is your softwares functionality.
  • The pin is the Sprint Backlog.
The objective is to get the ball from the tee to the target...easy right?

Want to hit the ball further? Use a bigger club.

DO NOT try to hit the ball harder with the same club.

Want to produce more software during a sprint? Use better engineering practices.

DO NOT push your team harder and make them work longer hours.

Want to hit the target? Make sure you are lined up with it.

DO NOT start implementation without knowing enough about what you are trying to build. [I'm not advocating complete upfront analysis, no sir! Just shifting it prior to Sprint start to gain a little more knowledge and increase utilisation consistency.]

It was about this point at the driving range my game took a complete nosedive!! BTW I can highly recommend the


computerised driving range we were at. It's like a cross between a bowling alley and a driving range. You have RFID enabled balls and lots of target holes - the nearer the hole the more points you score - there are lots of types of games you can play...I liked the "Snooker" variant - need to get a red (easy hole) followed by a colour (harder). If you are a seasoned golfer this really does highlight any problems with your accuracy!

Oh yes, were was I?

To focus on the consistency more I'd like to share our thoughts. We started a Sprint and our analyst and business domain experts got together to discuss the Sprint backlog. Meanwhile the developers, although not idle were largely waiting on some sort of output so we could start coding. Once we understood what we were building we got on with it and the analysts wound down with occasional bursts of clarification activity. The top left graph shows (exaggerated) a view on how this looked workload wise.

Sprint characteristics

Problem: Starting analysis at the beginning of the Sprint


  • Inconsistent utilisation across the team.
  • Delayed start to implementation whilst waiting for analysis to complete.
  • Inadequate analysis as pressure is on the get the development team productive.
  • Descoping of Sprint backlog items as the team is over committed because of a lack of knowledge about the actual requirements complexity.

The bottom left graph shows how this effects the Sprint - the team has insufficient understanding of the business functionality and based on their current (mis)understanding of the requirement they take onboard more work that they can complete. It is not until they are well into the Sprint and their understanding has increased do they realise the requirements are actually much more complex then envisaged and that they have overcommitted themselves.

Resolution: Shift the start of Sprint backlog selection and analysis into the previous Sprint.

  • The analysts have time to understand a better (not full) picture of the requirements complexity.
  • More time spent on analysis leads to a more granular, less monolithic understanding of each requirement. Is may be possible to acheive some of the functionality rather then dumping the whole requirement.
  • The team have more knowledge and can make a better guestimate of what they can actually acheive in the Sprint.
  • A clearer picture emerges earlier in the Sprint of what will be built - no awkward "Sorry, but we've had to descope that, and that...oh, yeh that went too" conversations a week before Sprint end. The product backlog also has a truer reflection on the state of play.
  • Team moral remains high, no feelings of inadequate performance as they cannot complete what they had originally stated they will deliver.

So ends part one of AGA...I'll flesh this out more on the engineering practices side of things very soon as I'm dying to get hooks, slices and especially shanking into this somehow!


Do this stuff actually work?
Deb said…
> Shift the start of Sprint backlog selection and analysis into the previous Sprint.

Exactly the solution we came up with, too. Otherwise the Sprints are unbearably stressful. Perhaps with a pure XP team (no designated "analysts") this is different, or perhaps they sacrifice someone in each sprint to prepare for the next?

(and, in answer to the previous comment: yes, absolutely, this stuff works! Check out !)

Certified ScrumMaster

Popular posts from this blog

Walk-Thru: Using Wolfpack to automatically deploy and smoke test your system

First, some history... The advent of NuGet has revolutionised many many aspects of the .Net ecosystem; MyGet, Chocolatey & OctopusDeploy to name a few solutions building upon its success bring even more features to the table.

I also spotted that NuGet could solve a problem I was having with my OSS System Monitoring software Wolfpack; essentially this is a core application framework that uses plugins for extension (Wolfpack Contrib) but how to unify, standardise and streamline how these plugins are made available? NuGet to the rescue again - I wrapped the NuGet infrastructure (I deem NuGet to be so ubiquitous and stable that is has transcended into the software "infrastrucuture" hall of fame) with a new OSS project called Sidewinder. Sidewinder allows me to wrap all my little extension and plugins in NuGet packages and deploy them directly from the Wolfpack application - it even allows me to issue a new version of Wolfpack and have Wolfpack update itself, sweet huh?


Geckoboard Countdown Widget v2

v2 is here, now with added colours! This time using the RAG Numbers widget to display your date countdown - as you get nearer the date the number will change from green to amber then red.

The new url is:!
Note 1: notice the new /rag/ path and the msg querystring param.
Note 2: the original v1 url still works

To use this on your Geckoboard add a new "Custom Widget/RAG Numbers" widget. By default the number will turn amber at 10 or less days to go and red at 3 or less days to go however you can change these with the querystring (see below).

Required querystring params
date: "yyyy-mm-dd" format, this is the target date to countdown totz: timezone offset in hours from GMT that you are in. Can be negative if you are behind GMT
Optional querystring params
msg: the label that appears next to the number of days (remember to encode spaces as +). The default is "Days Remaining" if you…

Resharper add-in idea - highlight IDisposable vars

[Update 18th July 2013]
@RobGibbens and Greg Hurlman picked up on this - Rob pointed out that there is an FxCop rule that can do this and Greg suggested a Visual Studio extension. I've had a quick look at the Visual Studio options and it looks like an "Editor Extension" is a good fit....hmmm, Project New, click...doh...dammit I really don't have time for this but it looks a fun little diversion! I'll update here if I get anything working.

[Original Post]
Had an interesting idea for a Visual Studio Resharper add-in the other day but don't have the time to implement it so thought I would put it out might already exist (and hopefully someone can point me in the right direction) or someone will build it (Darren Voisey where are you?!).

The idea is very simple really - when you have a variable for an object that implements IDisposable it gets highlighted or a tell-tale is displayed to let you know it should be disposed or should be wrapped in a using sta…