AgileFall – When Waterfall Sneaks Back into Agile
It seems every time I read an article where some Agile consultant extols the evils of waterfall the author commits a Just In Case Fallacy or the lede is buried. This article is no different:<p><i>Teams only checked in – wait for it – every three months in a formal schedule review. I listened as Henrich mentioned that the teams complained about the volume of  paperwork he makes them fill out for these quarterly reviews. And he was unhappy with the quality of the reports because he felt most teams wrote the reports the night before the review.</i><p>That&#x27;s not a problem with AgileFall or ScrumFall, that&#x27;s ineffective management irrespective of how the sausage is made. But nobody has to wear the Scarlet Letter of Project Failure if we assign blame to the process!<p>I&#x27;ve also never found that pure (like the wind-driven snow capital-A) Agile matches reality. After spending more than a decade wrestling with it - I still haven&#x27;t figured out how quality assurance and test fits into the same iteration in Agile. Most teams I inherit have non-technical QA resources. Most projects I inherit have complex business logic and integration needs that aren&#x27;t easily testable until some state of development &quot;done&quot; has been achieved. And time and time again I find myself staggering their effort slightly behind development so that test and development resources aren&#x27;t taking turns sitting on their asses waiting for the other side.<p>I&#x27;ve written about this before as was even been publicly admonished by an Agile Manifesto signatory (hallowed be their names) that I was doing it WRONG WRONG WRONG! But I was never able to figure out how to contort reality to satisfy their criticism. Believing in iterations and backlogs and prioritization and shortened feedback loops wasn&#x27;t enough. Thinking QA - any QA! - occurred AFTER any development was done was altogether impure. And despite asking repeatedly for concrete examples of how its done the &quot;right&quot; way, the only responses I received were vague platitudes and consultant sales blurbs that I guess I wasn&#x27;t smart enough to understand.<p>In the end, I don&#x27;t think there&#x27;s any escaping that work has to be done in a sequence: identify a need, identify a solution, implement the solution, validate the solution. And so every software project has at least a little bit of waterfall mixed in.