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…
I recently encountered a pair of senior, experienced PMs who had performed a Scrum implementation that produced a piece of software with hundreds of thousands of lines of code in less than 8 months. They had over a dozen teams, one of which had over 100 builders on it! Wow. First off, let me give both them and their builder teams major props for being able to pull this off, I don’t care if they used sticks and rocks, that was some amazing work.
During their presentation they talked about spending the majority of the first month engaging the PO’s, architects and tech leads. These people spent most of that month working hard on writing stories, sizing, prioritizing and grooming in general. By the time the builder teams got to see the backlogs they were pretty well set in stone with sprint breakdowns and release dates built in. Any of that sound familiar? These PM’s were literally implementing Waterfall principles, but with Agile practices. I refer to this as (W/A) where the first letter is the principle and the second is the practice. "W" is Waterfall and "A" is Agile, natch.
And in this case it made sense because the environment (the company they were working for) wholly defined the acceptance criteria with little to no agility required. In fact in this situation, where no agility was needed and the project was huge, that much pre-planning was certainly necessary in order to not waste company resources.
And therein lies the trick. When do you say no to Agile? At what point in the workup to tackle a project do you decide to take a Waterfall approach vs Agile? Simply look at the project and ask if agility is a requirement for the thing. Will ‘Done’ significantly change during the course of the project?
If the answer is ‘Yes’ or ‘Oh, heck yes!’ then implement both Agile principles and practices. Make sure that your organization is truly embracing agility at every level and understands how important both parts are to a successful project and happy customer.
If the response to your question is ‘No’, then implement a strict Waterfall principle and practice. This is the easy case because its so well known and everyone is pretty comfortable with it. Even in the case where you are working a software project but there is little call for agility you can (and I think should) Waterfall that baby. Am I second guessing the two PM’s above? On a massive, massively successful project? Are you nuts? I wasn’t there when the call to implement Waterfall/Agile (principles/practice) was made and cannot, will not speak to that.
I am, however, advocating that the craftsmen and craftswomen need to do a better job assessing our jobs before we reach into our tool bags. We need to understand that each tool has pro’s and con’s and when to use which. Without this I question anyone’s ability to say they are a master of their craft.