For a long time, I thought project management was a pretty worthless science. At worst, it was a line item on the invoice with no clear deliverables. At best, it seemed focussed on producing mountains of paper which no-one ever read; what little software it produced was bloated, overweight, over-budget and behind schedule. Good for big companies and huge projects, but over-dimensioned for the rest of us.
Okay, I’m being a bit global in my accusations, but let’s be honest: How many software development projects come in on-time, on-budget, and with functions that the users really want? (How much of, say, Microsoft Office do you know how to use? I rest my case.)
In the course of the last year I have been increasingly interested in so-called Agile methodologies: Scrum for project management and Extreme Programming (“XP”), the corresponding engineering discipline. For me, it clicked. These are methodologies that focus on producing working software, give the user what s/he wants, and produce a positive return on investment (ROI) for the company investing in the software.
How does it work? Simple. Define the product in terms the user understands: what s/he can do with the software and why. Together with the team, define the milestone (something that can be demonstrated) and implement it within one month (don’t change the goal at all during that month). Demo the result. Get feedback, adjust your plan if necessary, and repeat until ready to ship.
Why is this better? Under classical project management, the development team works like a taxi fleet. Although centralized planning tries to optimize utilization, each taxi is ordered and dispatched individually. If a taxi gets lost, runs late, or changes destinations, this has consequences. While these tend to be cumulative in their effect, aside from the overall project running late and over budget, it is hard to know exactly what went wrong.
Under Scrum, the development process is like a scheduled freight train. The train departs every hour and arrives 50 minutes later. One person (the Product Owner) decides what gets on the train. One person (the Scrummaster) is responsible for keeping the train on track. The team runs the train. If the train is delayed, everybody waits and everybody is aware of the problem. Once the train has departed, nothing else can get on and the train drives on to its planned destination.
After an hour, everybody knows where the train is. Since the schedule is important, no one is allowed to change the destination en route. Changes can be made, but only when the train is in the station (except in emergencies, of course), and only under the direction of the Product Owner.
Scrum operates through simple rules that can be applied to complex situations. It’s easily understandable. Progress is easily measurable (I graph progress and change in scope every iteration). Most important, the playing rules prevent the bad things which cause projects to go astray.
