Over my career, I’ve seen and participated in a lot of Waterfall projects, and a lot of “agile” projects.
I have personally really soured on the Waterfall methodology after a really large project where we spent months designing a solution and documenting a specification.
During those months of “solutioning”, the business would regularly change some requirements/business processes in response to changes in the market and each change meant a new change-request, a new scope, and a ton of fixes and updates to this ever-expanding specification along with the associated library of UML diagrams (think thousands of them).
Suffice it to say, this is a rigor that is completely inappropriate for 99% of software projects out there. Sure, there’s that 1% of projects that require absolute details for a specification upfront, but, what most projects these days actually need is a continuous collaboration between the business and development teams and a much more responsive and agile approach.
Having said that though, I’ve also been on a variety of Agile projects that could be best classified as “barely” Agile.
I think a lot of companies and teams want to speak the same language as the cool kids, and so they start talking about 2-week sprints and they add a daily standup meeting (where everyone is actually sitting down) and call themselves Agile.
Sure, that’s a step in the right direction, however, I firmly believe that the maximum value of doing projects in Agile comes from implementing every last aspect of the Agile methodology.
In my mind, the best argument for adopting every last agile commandment and performing every last ceremony to the letter is that the “whole” is definitely more than just the sum of the parts.
I have a lot of thoughts on what this “whole” comprises, so check back soon for a full description of what I think is the agile promise land!
Update: done! Read part 2 here: The promise of Agile!
Till next time,
MJ