Saturday, May 02, 2009

Agile Project Management and Golf

I've just had two similar experiences: one working with a vendor on a software development project and another working with some of my wife's staff on setting up some hardware and software. In each case, what they considered "done" is not what I would call "done" and it's caused some problems.

In an agile approach, you bite off a piece of work for a given amount of time (a sprint), design it, build it, test it, make sure the user interface is complete, and that all the code is in a production environment. In other words, you deliver something that provides immediate business value. On the software development project referenced above, the vendor would come back with most of the code working, most of the user interface done, some system testing accomplished, and the code would still be in a development environment. They would take the approach that they had some "tweaks" to wrap some things up but "we get the idea...".

I tried to relate this to playing golf. Suppose you're on a 450 yard hole. The approach above would be analogous to hitting a 250 yard drive, then maybe a 185 yard shot from the fairway to put you within striking distance of the green, and then picking up your ball and walking to the next hole saying you got close enough. Looking at it from the distance perspective, 435 yards is obviously 97 percent of the way there. But depending upon how well you execute, those last 15 yards could take a chip onto the green and into the hole (if you are really good or really lucky), or multiple chips and multiple putts. From the number of strokes perspective, being 15 yards out could mean you're two-thirds of the way there at best or maybe even only one third of the way there if it takes you two more chips and two more putts.

The point is, you've got to do the detail work to get the ball into the hole before you move to the next hole. We don't play all the big driver and fairway woods shots for the whole course and then go back and do all of our short game work. I think project management works best when you play it the same way.

1 comment:

George Schoemaker said...

It is the 80/20 rule, meaning, that it takes 20% of the time to do the first 80% of the work, and the remaining 80% of the time to complete the remaining 20% of the work. It is usually the remaining 20% or the "tweaks" that require the testing, UI tweaks, error messages, and functionality completion, to call the project or the hole DONE!