
AgileFall – When Waterfall Sneaks Back into Agile - furkansahin
https://steveblank.com/2019/09/17/agilefall-when-waterfall-sneaks-back-into-agile/
======
roland35
AgileFall does sound like an unholy mess, taking the worst aspects of both
Agile and Waterfall!

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.

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!

~~~
InternetOfStuff
> 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.

I disagree, having taken part in agile embedded development.

Sure, it looked a bit different from pure-software, but the same underlying
principle of short iterations applied. Our definition of "short" was a bit
different, but still...

And yes, you may have some "very specific" requirements, but you may also have
some "pretty loose" ones -- just like software.

> 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

See, there you go.

The core idea behind Agile isn't to have sacrosanct two week sprints (or even
to have sprints in the first place), it is to close as many feedback loops as
you can as quickly as you can. Whatever that means in practice.

This has been good engineering practice for longer than software exists.

I read that the Mercury space project created their software in half-day
"sprints". Back in the '60s, on punch-card machines (I guess).

~~~
yitchelle
Maybe I am wrong in my understanding, but for agile to work, observations from
testing or using is fed back quite quickly so that fixes can be included in
the next sprint. For the hardware where the validation can be quite lengthy,
this is feedback loop is much, much longer. Especially true when the project
gets closer to start of mass production.

~~~
InternetOfStuff
> Maybe I am wrong in my understanding

No, not at all. Just maybe a little... narrow?

> observations from testing or using is fed back quite quickly so that fixes
> can be included in the next sprint.

Quite quickly, yes.

The next sprint...maybe? Not necessarily.

Sure, you'll stick it in the backlog. But whether you'll start working on this
improvement immediately is a separate matter. If that's the best course of
action, sure, do it. But maybe you have more pressing matters, and the present
implementation will do for now. Or... it's not possible to attack it in the
next sprint, because a new board needs to be spun, and that takes preparation.
Then it'll be slated for the appropriate time, by necessity. That doesn't mean
you forego an agile approach -- it just looks different, because the landscape
is different.

> Especially true when the project gets closer to start of mass production.

Sure. Which is why being able to make, and find, and correct your mistakes
early, when it's not so dramatic yet, is the goal of that whole Agile song and
dance.

As you're intimately familiar of course, surprises in engineering are usually
the bad kind, and the later they come, the worse they catch you. So, have as
much feedback as you can, as early as you can (and with as much fidelity as
you can).

~~~
yitchelle
What you are describing is common sense engineering, of which Agile also
incorporates those aspects of as well.

------
trentnix
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:

 _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._

That's not a problem with AgileFall or ScrumFall, that'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!

I'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'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't easily testable until some state of development "done" has been
achieved. And time and time again I find myself staggering their effort
slightly behind development so that test and development resources aren't
taking turns sitting on their asses waiting for the other side.

I'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'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 "right"
way, the only responses I received were vague platitudes and consultant sales
blurbs that I guess I wasn't smart enough to understand.

In the end, I don't think there'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.

~~~
Groxx
My Grand Unifying Theory of Explaining Agile Proselytizers™ is "if it's not
working, you're doing it wrong". True Agile always works.

Oh, and it has more-frequent check-ins/iterations than Waterfall (which is the
defining aspect of Waterfall: fewer check-ins/iterations than Agile). The
_actual frequency_ is undefined, it exists only in comparison to Waterfall.

\---

The problem is that that kind of stance does nothing but fluff up agile
consultant's resumes. It doesn't actually lead to improvements that last, or
even _discussion that might lead to improvements._ Agile is perfect because
it's Agile.

~~~
dragonwriter
> My Grand Unifying Theory of Explaining Agile Proselytizers™ is "if it's not
> working, you're doing it wrong".

If it's not working, but you keep trying to do it the same way (whether
because management tells you to or because a book or consultant does), you are
doing it wrong. Because Agile is very little except the team continuously
adapting process based on observation of what does and doesn't work for them.

(Waterfall can be Agile, but only if it is waterfall adopted because the team
views it as the best way to deliver working software in their particular
circumstance and is continuously open to reevaluating that conclusion based on
evidence. Agile isn't opposed to waterfall but to the way Waterfall was
imposed. Which is also the way Scrum and variants are now frequently imposed,
producing the same kinds of problems of process/problem fit.)

~~~
Jtsummers
I suspect one of the key things missing in most people's understanding is that
agile is part of the "continuous process improvement" camp. It is a set of
principles, values, and practices which should be examined, in addition to the
work being produced, and improved over time.

Sterman's book _Business Dynamics_ has a great diagram that I think is
relevant (I saw it there, but it's probably in other books on system dynamics
and related fields). I'll attempt to ascii art it here:

    
    
      Mental model -> Strategy/Structure/Decision Rules
                                |
                                v
                           Decisions
                           ^       \
                          /         \
                         /           v
               Information <-----  Real World
                Feedback
    

That is most people's and organization's view of the world. They have a model,
they develop strategies (practices, methods), then they implement them.
Feedback from the real world informs their next decision, but they don't go
back and reevaluate the initial model and strategy.

A learning organization, continuous improvement, agile, whatever you want adds
an additional loop. The information feedback gets pushed back into the mental
model:

    
    
      Mental model -> Strategy/Structure/Decision Rules
                ^               |
                |               v
                |          Decisions
                |          ^       \
                |         /         \
                |        /           v
               Information <------ Real World
                Feedback
    

The Agile Manifesto, in the twelfth principle, emphasizes this aspect:

    
    
      At regular intervals, the team reflects on how
      to become more effective, then tunes and adjusts
      its behavior accordingly.
    

This is not unique to agile, it is just emphasized in it. This is not a
superfluous detail, this is actually critical, and commonly missed.

------
gnud
The last full system I delivered was created using a sort of waterfall/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.

We were replacing an existing, legacy system, and even though we switched over
"piece by piece", each module of the old system was at least 10-12 sprints.
And the end-users couldn't do a meaningful test of their normal tasks until
most of each module was implemented.

How to teams who manage to work more "agile" do this sort of thing?

~~~
dtech
This seams a pretty reasonable approach to solve this problem. The only
improvement I could think of is to "mirror" the data or API calls to the new
system so it gets battle-tested earlier, but that only works for backend
systems.

~~~
beat
That only works with similar architectures. I've been involved with converting
mainframe batch systems to service-oriented architectures on distributed
systems, and that sort of mirroring does not work _at all_.

It's fine for prying microservices loose from monoliths for relatively modern
REST api systems, tho. Big problems I see there are that the problem often
isn't the code, but rather the api itself that's a mess, and evolving the api
breaks client code which you may or may not control.

~~~
dtech
> converting mainframe batch systems [...], and that sort of mirroring does
> not work at all.

Interesting, what are the problems you encounter if you try that?

~~~
beat
The problem is that you're building a new system to completely replace an
existing system, and the existing system is tightly integrated in a way that
makes piecemeal change difficult to impossible. And the new system isn't just
a refactoring for bad code - it's a redesign in the name of new functionality.

In this particular case, it was a banking system that worked largely by
nightly batch jobs. Data queued up during the day was processed at night. Job
A triggers Job B, which Triggers Job C; etc. What we wanted was to change
those batched transactions into individual transactions that could be
processed in synchronous quasi-realtime.

With reconciliation happening near the end of the batch processing, how do you
do that?

And mind you, this system moved more money every day than the GDP of many
countries. Failure was NOT an option. Not if you don't want to roast the
entire US economy. So the consequences of error were truly terrifying.

------
SamuelAdams
Based on this:

>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.

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 / project stakeholders do not change
their workflow, you get this "AgileFall" combo that just does not really work.

~~~
Ididntdothis
That’s exactly how agile got introduced at my company. The scrum training was
attended by most devs, only a few higher ranked architects, exactly one level
1 manager. Nobody from marketing, project management or upper management
attended and now years later they still don’t understand how Agile is supposed
to work. For them it’s something engineers do. So in the end nothing really
changed other than words.

------
crimsonalucard
Buzzwords like agile and agilefall and waterfall don't really mean anything.

One persons anecdotal experience about agilefall doesn't mean it doesn't work.
Don't fall for the trap of using analogies and anecdotal experiences as
evidence. To top it off this guy didn't even measure the outcome of agilefall,
all he did was declare that it violates some made up philosophical principles
and demand change.

I'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/being built using agile.

Note that I'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.

~~~
aeorgnoieang
Of course "anecdotal experiences" are _evidence_. Yes, they're messy, and may
not be applicable to other circumstances, but they're certainly informative.

I'm pretty sure airplanes and bridges aren't _designed_ using 'waterfall'. I'm
sure they're built, i.e. 'deployed', using a well-defined process. But,
ideally, the well-defined process by which they're built should itself
probably be designed or developed with 'short' iterations.

~~~
crimsonalucard
>Of course "anecdotal experiences" are evidence.

You're right. It is evidence. This is an obvious fact that I mis-represented
on accident. Let me rephrase for clarity:

"This persons anecdotal evidence is not good enough or unbiased enough to
qualify as evidence to be used to arrive at a conclusion"

>I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm
sure they're built, i.e. 'deployed', using a well-defined process.

Ok let me rephrase for more clarity in case people don't have the ability to
know that by "designing" a bridge I can mean "build" and "deploy" as well.

"Airplanes and bridges are designed and built using waterfall."

>But, ideally, the well-defined process by which they're built should itself
probably be designed or developed with 'short' iterations.

This was how the MAX part of the 737 MAX was designed. Using a short iteration
on top of an existing design. It leads to shorter turn around and cheaper
costs. With the small expense of 1 or 2 plane crashes.

If you can afford a plane crash go agile, if you want to build something
correctly go waterfall.

~~~
aeorgnoieang
> This was how the MAX part of the 737 MAX was designed. Using a short
> iteration on top of an existing design.

A lot of software (that's often written about) can be tested 'in production'
with fairly minor consequences in the event of 'failures'. That's an obvious
difference between developing or maintaining software versus something like
airplanes.

But testing or validating the changes made in short iterations is important
regardless. Agile stresses the utility of short iterations precisely so the
changes in each iteration can be tested and validated ASAP. Whereas in a
waterfall methodology, a larger set of changes, i.e. changes that would in
agile be split among a number of iterations, is tested or validated together.
And the more changes that end up being tested together, the larger the risk is
that those changes, and more of them, will need to be scrapped or redone.

The problem with the "MAX" changes of the 737 MAX seems more due to those
changes _not_ being tested or validated with the relevant users, i.e. pilots,
_at all_ before being 'released'.

Yes, the flawed (or incorrect) reasoning was that the changes were relatively
minor and thus didn't warrant the regulatory requirements for 'significant'
changes. But that doesn't seem to have anything to do with how the changes
were developed, whether their methodology was agile or waterfall (or anywhere
in between).

Obviously you're more likely 'to have a bad time' if you don't respond to, let
alone _seek_ , feedback from users about the changes you're making.

------
dragonwriter
“Agile” and “Waterfall” aren'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”.

I'd bet that these days it'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.

------
rhombocombus
I am currently leading a dev team on a project that I would describe as
waterfagile/agilefall. It'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.

For this kind of project it doesn'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.

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

~~~
crimsonalucard
Agile is often more bureaucratic overhead. More meetings, more checking in.

~~~
AnimalMuppet
At the risk of "no true Scotsman"...

If it's creating _more_ overhead, it's not agile. It may wear the label, but
it's not the real thing.

If the existing process was already the optimal one, the agile thing to do is
to _not change it_. If the "agile" changes are adding overhead, the actually
agile thing to do is to _go back to the previous process_.

~~~
crimsonalucard
So basically the definition of agile is:

"The perfect way to do project management"

With this definition in place the future is solid, no criticism can bring
agile down because agile can evolve into whatever you want it to be.

Literally, what is the difference between "agile" and "whatever works"?

~~~
AnimalMuppet
Agile is "adjust your process". Your process is one of the variables, not
something handed down from on high. If you aren't adjusting your process, you
aren't doing agile.

Many places say "We will be agile according to this rigidly defined process".
The contradiction is obvious.

~~~
crimsonalucard
Whatever works man, whatever works.

~~~
Jtsummers
"Whatever works man, whatever works." lacks deliberateness, and that's one of
the key differences between it and agile (little-a to keep separation from the
Big-A Agile sold by consultants).

Look at the difference between the principles of Theory of Constraints, and
what most organizations do. Most organizations want to remove constraints,
they know they're a problem (since, well, they're constraints). The difference
between ToC and what most people do is that ToC emphasizes a deliberate focus
on the _singular_ constraint in the process. I've seen teams and offices
optimize the hell out of areas that aren't the bottleneck. Meanwhile, they
still spend 3 months at the end of their projects running their massive,
manual test suite. Do the tests bring value? Yes, immense. Do they bring value
at the right time? No, because they take 3 months to run so they're delayed
until the end of the project, so the project schedule leaves 3-6 months of
buffer after that testing to conduct rework. A deliberate focus, then, should
be brought to the testing activities and identifying how they can be conducted
more rapidly, ideally automatically, and feedback brought in at an earlier
stage.

Agile, as described in the manifesto, brings in a set of values that are
intended to provide focus on what's important for both the team and the
customer. To a large extent, it means "whatever works", but with focus on the
values you share with your team and customers, and the tradeoffs that will be
incurred based on the choices made.

~~~
crimsonalucard
If deliberateness works then it works man. Whatever works.

------
forgottenpass
Here's an example of why I still can't take writing about Agile seriously. I'm
not saying there aren'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:

>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.

What are reports, if not documentation of outcomes? What are outcomes without
evidence that those outcomes happened?

I can see what he's saying, but the more accurate description of the problem
"the reports included unnecessary and distracting information." But that
doesn't make as good of a blog post as casting it as "paperwork vs
understanding outcomes."

The whole thing feels like it needs to invent a "paperwork = evil" 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't call paperwork anymore.

Email is paperwork. Version control is paperwork. Change management is
paperwork. It doesn't matter if it'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.

Standups are paperwork that just happen to not use paper.

~~~
igouy
> Standups are paperwork that just happen to not use paper.

If it isn't written down, it didn't happen!

(Memory is not an infallible record.)

------
pytester
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.

There's a common misperception in the industry that agile is 'fast' but
waterfall is better at handling risky situations.

~~~
zaphar
That's ironic, because in many cases the reverse is true. Agile can be slower
when you are exploring the solution space. It's safer though in that scenario
since you are more likely to identify and fix issues as you enter them.

~~~
beat
There's this thing I say a lot... in large organizations, it's more important
do appear safe (even if it's risky) than to appear risky (even if it's safe).

------
codeulike
When feeling troublesome I like to endorse Agile enthusiasts with the skill
'Waterfall' on LinkedIn

------
netfl0
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.

------
peterwwillis
At Cisco there was a big organizational push to become "an Agile
organization". What we ended up with was waterfall with Scrum. But regardless
of people'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 _name of your
process_ , rather than just getting work done, you'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.

~~~
himynameisdom
Agreed. Vision and strategy set the table for why and how the work moves
towards an intended outcome. Every company I've worked with that does
scrumfall tends to value outputs over outcomes of the outputs.

The process name doesn't matter, the results of the process should be the
focus of every product company.

------
ausjke
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'm going to keep for the future.

~~~
jrochkind1
I have seen managers thinking the best thing about "agile" is enforcing staff
discipline and maximal productivity ("stay on track", "press you ahead", "can
not be too lazy"). It usually leads to a process that it really is still
waterfall, but with, like, total surveillance and constant stress and
developers being treated as interchangeable widgets.

It is sad to me to see a non-manager saying this is somehow the part they
_like_.

The best experience I've had with agile processes was also one of the least
stressful and most relaxing workplaces I've been in. I knew what I had to work
on, I could trust that it was the _right_ thing to work on that wouldn't be a
waste of time, and I had no pressure to "push myself", what could get done in
work hours was what could get done in work hours, and sometimes you had to
schedule some R&D/exploration time too. (The analogy of "sprint" is actually
alarming when you think about how it's used -- you can only "sprint" for a
short distance, you can't do back-to-back springs for 20 miles, the human body
doesn't work that way!)

I think that may actually be one of the fundamental divides in "agile",
whether someone is trying to use it as a productivity tool to "press ahead"
developers who would otherwise be "lazy", to squeeze out the maximum possible
work out of them, being unconcerned if you burn them out cause you can just
replace them with another commoditized developer slotted into the "scrum".

~~~
himynameisdom
I would agree the word "sprint" can conjure up a bad picture, but the agile
manifesto clearly states the team should work at a sustainable pace. Nowhere
in the Scrum Guide does it say you must work at a breakneck speed.

Inputs for sprint planning include the relevant empirical data (velocity, burn
down/up etc.) to help with planning. In my experience, these data points are
used to measure productivity, which is dangerous. Companies end up measuring
success by outputs, rather than outcomes.

Business units need to stop weaponizing Agile and realize they too need to
change in order to inspect and adapt towards building things people want.

~~~
jrochkind1
I agree that it is not inherent to Agile. (I'm more suspicious of "scrum", but
I'll believe you that it's not either).

Like I said, I've had GREAT experiences with agile practices, my _favorite_
workplaces have been using agile practices. Also terrible ones. Knowing that
the terrible ones were "doing agile wrong" didn't make them less terrible.

I even said very explicitly "It turns into a process that is more like
waterfall, but..." So I'm a bit perturbed by your response insisting that this
is not inherent to agile. When I was pretty explicit in saying that too.

LOTS of companies _saying_ their doing agile result in misery, even worse than
before they pretended to do agile. On the other hand, doing agile well can be
wonderful. In order to figure out how to make more of the wonderful than the
terrible, we have to get _beyond_ just pointing out that "the agile manifesto
clearly states". Cause it's clearly stated that already, and it hasn't stopped
the terrible.

------
jcims
We'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.

Slipping back into waterfall can happen because many of these issues have
sequential dependencies and are one time request driven processes. It's a bit
of a nightmare.

------
patsplat
Waterfall isn't an engineering methodology, it's an investment methodology.
Engineering will mirror the interests of the capital. And sometimes capital
wants to build the same thing again for a "safe" return, rather than building
something new for a transformative return.

IMHO it's not actually a safe investment strategy, but I understand where it
comes from.

------
eagsalazar2
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.

> reviews would be about frequent delivery, incremental development and how
> leadership could remove obstacle

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/research to help understand that performance, and
hypotheses/strategies for how to improve.

I'm a big fan of Lean/BML approach and I'm assuming this is what is happening
but the article doesn't really send that message. Because of that omission,
after reading but before seeing the author my first thought was this was
consultant blather.

------
megiddo
Waterscrumban is my favorite method.

~~~
beat
Yeah, we did Waterscrumban. We're in our third sprint. The first sprint, we
moved "requirements" from backlog to doing. Second spring, we moved
"requirements" to done, and moved "design" to doing. Third sprint, we moved
"design" to done, and "implementation" to doing. Verification and maintenance
are still in the backlog.

It works great! Just three more iterations, and we'll be done with
maintenance!

------
bastijn
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.

[0]
[https://www.scaledagileframework.com/](https://www.scaledagileframework.com/)

------
kelnos
I've heard -- and much prefer -- the term "Waterfragile". It's funnier, and
IMO more descriptive of what's going on.

~~~
NateEag
Agreed. I was quite disappointed the day it came to me, I searched for it, and
discovered I was not the coiner.

------
bitwize
I've never seen an Agile implementation in the wild that wasn'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.

------
rezeroed
"Sneaks"? 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.

------
softwaredoug
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

~~~
Ididntdothis
I think upfront planning is almost always a good thing. The problem starts
when people think that the plan doesn’t need to be revisited. You need to be
willing to change the plan as new facts develop.

In the end no matter what you do software and hardware development is
unpredictable. No methodology will ever change that.

~~~
brightball
This is the problem in a nutshell. Revisiting plans when you get new
information.

This is especially true with estimates. New work, new problems, unexpected
difficulties, etc.

Over-planning can lead to a lot of rigidity in the process if it tries to plan
too far ahead.

~~~
Ididntdothis
“Over-planning can lead to a lot of rigidity in the process if it tries to
plan too far ahead.”

Or they try to compensate for technical problems by doing endless replanning
meetings instead of spending the time on solving the problem.

But a good long term road map is really helpful when you have to make a
decision to go one way or the other. Just accept that it’s a rough guideline
and not an exact plan that’s set in stone.

------
api
I hate when buzzword sneaks into buzzword.

------
baxtr
AgileFall is coming!

