AgileFall – When Waterfall Sneaks Back into Agile

AgileFall does sound like an unholy mess, taking the worst aspects of both Agile and Waterfall!<p>However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive.<p>But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept. Within each phase of the design more experiments can be done. But ultimately the project is probably more waterfall than 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.

The last full system I delivered was created using a sort of waterfall&#x2F;agile hybrid. We worked from a backlog, in short-ish sprints, but nothing was put into production until a certain milestone was reached, after multiple sprints.<p>We were replacing an existing, legacy system, and even though we switched over &quot;piece by piece&quot;, each module of the old system was at least 10-12 sprints. And the end-users couldn&#x27;t do a meaningful test of their normal tasks until most of each module was implemented.<p>How to teams who manage to work more &quot;agile&quot; do this sort of thing?

Based on this:<p>&gt;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.<p>In my experience, embracing agile is an organizational change, not just an IT team change. Product owners and subject matter experts need to be more engaged with their development teams. Not all business folks want to do this: they have their own day-jobs to get to. So when the IT team starts iterating faster, but the appropriate business &#x2F; project stakeholders do not change their workflow, you get this &quot;AgileFall&quot; combo that just does not really work.

Buzzwords like agile and agilefall and waterfall don&#x27;t really mean anything.<p>One persons anecdotal experience about agilefall doesn&#x27;t mean it doesn&#x27;t work. Don&#x27;t fall for the trap of using analogies and anecdotal experiences as evidence. To top it off this guy didn&#x27;t even measure the outcome of agilefall, all he did was declare that it violates some made up philosophical principles and demand change.<p>I&#x27;ve seen a project manager literally catch himself from doing something waterfall like it was the plague. Do people not realize that waterfall is the only technique used to build airplanes and bridges? I would not get on a plane built&#x2F;being built using agile.<p>Note that I&#x27;m not criticizing agile. Agile works, waterfall works and no logic or evidence provided by that article says that combining what works for both is not good.

“Agile” and “Waterfall” aren&#x27;t opposed, or even necessarily incompatible; “Agile” is opposed to “Process not dynamically adapted to the needs of the particular team in developing working software”.<p>I&#x27;d bet that these days it&#x27;s a lot more common for a process imposed in the way Agile is a reaction against to be some variant of Scrum with which management is enamored, rather than waterfall.

I am currently leading a dev team on a project that I would describe as waterfagile&#x2F;agilefall. It&#x27;s a highly regulated industry and the product is for a state level client that has rigorous specifications. We operate iteratively, but there is a discrete golive and many specifications of the project were defined contractually before we pushed a single line of code.<p>For this kind of project it doesn&#x27;t make sense to operate in a pure agile fashion, but we also have broad license to operate how we please in some aspects of the project (i.e. the UI), and those more closely resemble an agile method project.

None of it even matters. Both agile and waterfall can succeed. Mostly in spite of the chosen methodology, not because of it.

Here&#x27;s an example of why I still can&#x27;t take writing about Agile seriously. I&#x27;m not saying there aren&#x27;t a lot of process improvements under the banner of Agile (and plenty more that Agile is retroactively claiming credit for), but writing like this turns me off:<p>&gt;Henrich still had a process where success was measured by reports, not outcomes. It was the same reporting process used to measure projects that used linear, step-by-step Waterfall.<p>What are reports, if not documentation of outcomes? What are outcomes without evidence that those outcomes happened?<p>I can see what he&#x27;s saying, but the more accurate description of the problem &quot;the reports included unnecessary and distracting information.&quot; But that doesn&#x27;t make as good of a blog post as casting it as &quot;paperwork vs understanding outcomes.&quot;<p>The whole thing feels like it needs to invent a &quot;paperwork = evil&quot; boogieman just to allow a process change that throws away useless paperwork and allow a team to focus on the paperwork that you just don&#x27;t call paperwork anymore.<p>Email is paperwork. Version control is paperwork. Change management is paperwork. It doesn&#x27;t matter if it&#x27;s software updating a database instead of a secretary updating 3-ring binders. Most of development is paperwork. In fact, online databases mean we do way more paperwork. If we were bottlenecked by that sea of file cabinets in the basement containing all our the legacy projects, we would have way less paperwork just out of necessity.<p>Standups are paperwork that just happen to not use paper.

IME the most common cause for waterfall sneaking back into agile is when agile experiences some kind of failure - like the project delivered late and over budget. The response to this is often to revert to waterfall methods and means. This frequently makes things worse.<p>There&#x27;s a common misperception in the industry that agile is &#x27;fast&#x27; but waterfall is better at handling risky situations.

When feeling troublesome I like to endorse Agile enthusiasts with the skill &#x27;Waterfall&#x27; on LinkedIn

This article conflates the reporting and engineering aspects of the two processes, then it goes on to focus purely on the reporting. There was also no discussion of engineering discipline and how that fits into their process, despite the waterfall graphics showing requirements and design.

At Cisco there was a big organizational push to become &quot;an Agile organization&quot;. What we ended up with was waterfall with Scrum. But regardless of people&#x27;s complaints, and the lack of integration throughout the org, we still got products out the door when we said we would, worked on solutions iteratively, added value, etc. If all you focus on is the <i>name of your process</i>, rather than just getting work done, you&#x27;re not gonna get far. I find a lack of a vision, strategy, roadmap, etc to be way worse than just doing something in a less-than-Agile way.

Been in agile team for about a year now, the only good thing I feel is the stand-up meetings, that reminds everyone to stay on track, and update the status each morning(also press you ahead, can not be too lazy due to this daily update thing, especially for old lazy engineers like me), also, a quick exchange of ideas in the standup can make a day more productive once a while. This is the major if not the only thing I&#x27;m going to keep for the future.

We&#x27;re struggling, IMHO, with adopting agile in a highly regulated environment where there are a multitude of tollgates to get to production. Roughly 20 different stakeholders that need to be accommodated while leveraging many internal services that do not support automation.<p>Slipping back into waterfall can happen because many of these issues have sequential dependencies and are one time request driven processes. It&#x27;s a bit of a nightmare.

Waterfall isn&#x27;t an engineering methodology, it&#x27;s an investment methodology. Engineering will mirror the interests of the capital. And sometimes capital wants to build the same thing again for a &quot;safe&quot; return, rather than building something new for a transformative return.<p>IMHO it&#x27;s not actually a safe investment strategy, but I understand where it comes from.

Obviously not every detail is included here but I did find it odd that, although he mentions a focus on outcomes, the change he talks about is entirely about shifting from one process to another, both of which by themselves might be pretty arbitrary.<p>&gt; reviews would be about frequent delivery, incremental development and how leadership could remove obstacle<p>I would think that in a Lean process that outcomes and therefore reports would be focused on performance of North Star Metrics, KPIs, comparing those against goals, analytics&#x2F;research to help understand that performance, and hypotheses&#x2F;strategies for how to improve.<p>I&#x27;m a big fan of Lean&#x2F;BML approach and I&#x27;m assuming this is what is happening but the article doesn&#x27;t really send that message. Because of that omission, after reading but before seeing the author my first thought was this was consultant blather.

Waterscrumban is my favorite method.

Coming from the other side we have Scaled Agile Framework (SAFe) [0]. Which introduces some waterfall to Agile instead of the other way around. 3 month planning events, commitments, etc. Not bad perse if you work in an environment where not everybody is agile or every process can be agile.<p>[0] <a href="https:&#x2F;&#x2F;www.scaledagileframework.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.scaledagileframework.com&#x2F;</a>

I&#x27;ve heard -- and much prefer -- the term &quot;Waterfragile&quot;. It&#x27;s funnier, and IMO more descriptive of what&#x27;s going on.

I&#x27;ve never seen an Agile implementation in the wild that wasn&#x27;t a game of Mornington Crescent, whose stated goal was closer adherence to Agile principles but whose actual goal was to reinforce existing power structures and undermine developer autonomy.

&quot;Sneaks&quot;? There are projects where the agile coaches, scrum masters, and consultants proudly declare regularly that the project embraces the best of both agile and waterfall. Nothing resembling sneakiness.

Maybe for certain projects where failure is high risk waterfall is better. Or at least more up front planning is a “good thing” when fail fast = lives lost

I hate when buzzword sneaks into buzzword.

AgileFall is coming!