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.