This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Are your projects succeeding by accident?
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
If you dance around in the morning, and that evening it starts raining, does that mean that you executed a perfect rain dance? Or do they have nothing to do with each other?
One of two things is certainly true: Either your dancing had some effect on the eventual outcome, or it did not. You may not know which, but if you did, wouldn't it help inform future behavior during a drought?
And so it goes with software projects. Overzealous managers hear about a big successful project, and then attempt to duplicate that success by imitating it.
"Ah", they say, "Project MegaCost used the new BURP (Big Unproven Reactionary Process) methodology and it was wildly successful! We have to use that also!"
And so imitation replaces coherent thought, and reason is stifled by restrictive rules.
"We must create an Analysis Breakdown Diagram that traces to the Object-oriented requirements Statechart," says the project lead.
"But why exactly do we need that?" you ask. Seconds later, an army of BURP consultants storms the room.
"You must be educated", they say. "You just don't understand, you're stuck in the traditional mindset of getting things done efficiently. BURP will free your mind, and let you predictably reach your goals, or at least appear to be doing so in each phase."
Needless to say, the project is months behind schedule, although a nice stack of documents is piling up, and each of them traces back nicely to the requirements. Except, of course, that the requirements have sort of changed since last year when you were capturing them. Time to update all of those documents and trace matrices!
The CIO blames the BURP consultants, who retort that the company isn't correctly implementing BURP, and are missing several essential Use Case Dependency Matrix Flowcharts. Hilarity ensues.
"But why didn't BURP work here?", complains the CIO. "It worked for Project MegaCost!" And then it dawns on him...maybe that project succeeded for other reasons. Maybe it was even the...gasp...choke...PEOPLE!
Software projects are all different, due to the nature of software itself. It's a little different for each context and application, even if the domain is similar. And this kind of variation needs a mindset of adaptation. Keep things simple, and be ready to adjust as you get new information.
Success breeds complacency, so a successful project team needs to be on the alert for the next danger lurking around the bend. Even if an approach worked wonderfully in a certain context, chances are a different circumstance may require adjustments to that approach, not blind adherence to a method.
So the next time you make it rain, ask yourself if it's the dance you did, or if you just live in Seattle.
Previous Topic
