- Written by Lee Allison
Lately the Agile Community has been so headstrong on fitting Agile methodologies into any and every situation that I think that many times we miss asking the question, “SHOULD Agile go in there?”
Just because you can do a thing doesn’t mean you should. Ancient wisdom indeed, and it definitely applies to project management. A lot of Agile practitioners are true believers; their eyes burn with the fire of an apostle and they know in their bones that Agile is the answer. Who cares what the question is, they know the answer.
In my mind those poor folks are no better off than lazy, unimaginative Waterfall practitioners who follow the PMBOK chapter and verse only because they know no better. SDLC was good enough for their forefathers and dangit, its good enough for them. In each case the craftsman has settled on the tool before even assessing the job.
Wrong, wrong, WRONG!
But first understand that Agile, as a project management style, is no better or worse than Waterfall. Both have their pro’s and con’s. Both have situations where one works better than the other. The trick is to know when to pull out a hammer and when to pull out a drill. Neither one does the other’s job very well at all.
Let’s take a closer look at these tools. In each case we need to understand the difference between principle and practice. The two are very different, and very seperate.
Principles are the heart and soul of a management style. They are WHY this style works and take a lot of effort to really grasp. Here’s an easy way to tell if you are talking about a principle or a practice: Can the thing you are talking about be easily measured? Can metrics be applied? If so then its probably not a principle.
Practices on the other hand can submit to metrics. They are the meetings, artifacts, roles; the nuts and bolts of how the style is applied. Every style of management has entire bookshelves on how to apply that style’s practices, and this is good stuff! Regardless of your role on the project you need to spend time understanding the bits and pieces of how that style works.
In the Waterfall world the Principle is “Measure twice, cut once.” In other words Waterfall’s voodoo comes from tons of preparatory work done by the management team to define, measure, sequence and assign every little detail of the project. In many cases this work can consume hundreds or even thousands of people-hours; all of which get done before the first brick is laid or the first server is ordered.
And Waterfall Practices? We all know them, probably very well: Gant charts, timelines, PMBOK, EVM and all of the other parts and pieces. The fact is that these tools are very well polished from millions of people using them for over seventy years on hundreds of millions of projects. That bridge you crossed going to the store yesterday? Waterfall principles and practices were almost certainly at play when it was built.
Over in the Agile world things are very different though. The main guiding Principle is best summed up by the last line of the Agile Manifesto: Responding to change over following a plan. Certainly the whole manifesto is a work of literary art; short, concise, elegant. But the last line sums the whole thing up and counters the Waterfall principle beautifully. If you are implementing Agile principles then your project needs to have built in gearing that allows it to respond to change. Regardless of who or what generated that change you need to be able to respond without pulling your hair out. In Waterfall a major change results in major lost work, not so in Agile.
Agile Practices, you ask? Backlogs, stories and burndowns, Oh my! Yes, these tools have become quite polished from use in recent years, but lets face it: at just over a decade old they are still freshly paid for compared to the tried and true Waterfall tools. Why do I keep banging on about how long these practices have been in use? Well, I believe that you should generally only be employing Agile practices when and where the principles are in play too. If the principles are not being adopted then push back on your management and simply waterfall the project. Yes, even a software project. Let me explain…
- Next >>