
Acephalic Agile: Worse than Waterfall? - majke
https://tech.labs.oliverwyman.com/blog/2018/05/16/acephalic-agile/
======
maxxxxx
This is the same extreme reaction people had previously to waterfall. Any
methodology fails if it gets applied blindly and wrongly. You have to be
willing to adapt it to your specific environment until it works for you. It
would be a huge mistake to go back to waterfall just because people perverted
Agile into a micromanagement method. The same people who can't make Agile work
will also fail (and have failed for a long time) with waterfall or any other
method because they refuse to adapt to reality and instead want work
instructions they can follow without any thought.

The same thing goes on with OOP. It started out as a good addition to other
programming styles, got turned into a religion ("you can't do this. It's not
OOP.") and now into a pariah (FP is next to go through this cycle).

In the end stupid people will mess up anything they touch and good people will
adapt things until they work.

~~~
clairity
agile is a culture as much as it is a project management methodology, so it
only works when the culture is compatible.

one former employer purportedly did agile but it was a top-down autocracy,
which is completely incompatible with agile. (i was ostensibly a product
owner, but the CEO set our development priorities with only superficial
consideration for customer feedback.)

you cannot both dictate and empower at the same time, and empowerment (via
agile) is typically the loser in that fight.

that's how i see agile "failing" most often, before it even has a chance.

~~~
squiggleblaz
The perfect development system will be immune to failure before it's had a
chance.

There is no perfect, but one that is fragile to external business realities is
probably worse than one that is resilient to it.

(In my company, the problem with agile was that the sales people would insist
on always adding some extra tool for a fixed price. We had no choice but to
abandon agile.)

~~~
clairity
i don’t know what such a resilient methodology might be, because we’re talking
about human systems where the participants continuously adapt to emerging
conditions.

agile seeks to benefit from the intrinsic motivation of each team member to
create something beyond any single member’s capabilities in exchange for
empowerment.

when a manager doesn’t understand this principle, that leads to failure (as in
your case as well). i don’t know of any systems that can self-correct for this
kind of external mis-judgement.

~~~
maxxxxx
That's the holy grail of management: To create systems that are immune to
mismanagement. The Agile Manifesto tried to make clear that such systems don't
exist but instead it got made into another system that's supposed to be immune
from clueless people.

------
Robin_Message
I definitely agree with the author. Agile is increasingly being used to
justify having no plan and just getting devs to do whatever seems most
important to a "product owner" each sprint without the real customer feedback
that is an essential part of agile.

I blame scrum for commodotising and cargo-culting all the good stuff out of
agile. I'm writing a blog series on the problems with Scrum here:
[https://www.lambdacambridge.com/blog/2018-05-how-scrum-
destr...](https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-
agile)

Interestingly, DSDM, which the author uses, doesn't get much attention, but
was there from the beginning of the Agile movement.

~~~
madeofpalk
Don't you think the blame here on the methodology is misplaced? It just sounds
like a bad team/company, that'll perform just as poorly with "waterfall"

~~~
amiga-workbench
A bad team will always find a way to pay lip service to any process or
workflow you throw at them and still fall back on their old dysfunctional
habits.

Its never the process at fault, its the gaping disconnect between the
specification of that process and the implementation.

------
Nomentatus
I think the author left out something.

Agile involves getting the customer deeply involved from the start, so that
after one or two spins of cycle, they have a more sober view of what the
magicians are doing, and how little they, the customer, get to ask for in the
real world, if they want the project to be done this century (and they do.)
Done well, it's the equivalent of sticking your dog's nose into the mess they
made on your rug; where dog=client.

~~~
abritinthebay
It doesn't _have to_. It would be ideal of course.

The point is that there are always stakeholders and product owners - it just
makes that explicit. If the PO is acting as a proxy for the stakeholder
(customer in this case) that's ok.

Of course the PO might be wrong... but with small iterations that should be
found out _quickly_ and adjusted for.

~~~
Nomentatus
Principle 4 of twelve: "Business people and developers must work together
daily throughout the project."

[https://www.agilealliance.org/agile101/12-principles-
behind-...](https://www.agilealliance.org/agile101/12-principles-behind-the-
agile-manifesto/)

It would be odd if "business people" just meant the _developers '_ upper
management within their firm; supervising costs and parking spaces; but not
those without a stake in using the software that results, say.

~~~
abritinthebay
Business people doesn’t mean _customers_ however. Which was my point.

In fact the only time the customer is mentioned is in principle one: “Our
highest priority is to satisfy the customer through early and continuous
delivery of valuable software.”

Business people absolutely should be involved - product owners & stakeholders
(or a proxy for them).

That’s fundamental but again: business people != customers.

You seem to think stakeholders/product owners are devs direct managers too.
That’s rarely the case, if ever, on any functioning agile team I’ve seen.
They’re orthogonal to each other.

~~~
Nomentatus
I think I answered this possible objection, but you've ignored that. Also, I
made a distinction between stakeholders and devs direct managers, rather than
conflating them.

I don't believe I can be of further assistance to you.

~~~
abritinthebay
Your answer fell short and is contradicted by the agile principles. Your
distinction was practically meaningless given your later usage.

You were never any “assistance”. You had nothing of substance to add.

------
rvense
Agile is a religion:

Some smart, well-meaning people write down a couple of brief, broad
suggestions on how to do better, and a few years later it's been twisted into
an industry of people who want me to pay them for telling me that I'm living
my life wrong.

~~~
diminoten
Yes, and much like a religion, there are people who refuse to see any positive
elements to it, despite those elements being numerous and obvious.

Also, there are larger truths that live at its heart which make discussions
about the topic difficult because if you're seen as disagreeing with some of
it, you're seen as disagreeing with all of it, even if you don't.

What a good analogy!

~~~
rvense
Definitely agree! I often quote from the manifesto. Especially when dealing
with Jira.

I've been meaning to read the original Waterfall article as well, I've heard
it's good.

------
snarf21
One thing I've learned over the years about process is that a "bad" process
that is followed consistently and with buy-in from everyone involved will
always out perform the "good" process that is followed haphazardly or with
only lip service buy-in.

I liken this to diets. Paleo suggests not eating bread (among other things).
However, not eating bread doesn't mean you are doing Paleo. The benefits of
Paleo are intended to be realized via a systemic application.

So whether it is agile or diets, make rules that work for you (and yours).
Then stick to them. Periodically review if they are working. If they aren't
change the part that isn't into a new rule and then repeat. There is no one
size fits all in these things.

------
InclinedPlane
It's impossible to talk about Agile vs. alternatives today because the
fundamentals of Agile development are just the de facto way all software is
developed now. Continuous integration, regular builds, iterative development
cycles, etc. Even people who think they would be doing "Waterfall" today would
do so still using these techniques.

The reason why Agile techniques were created was due to a serious crisis in
software development. Projects were failing, lots of them, in ways and with a
severity that few software projects today fail. At its core Agile is very
simple, it's a system of hedges against failure:

Always have software that is in some sense in a usable state (builds, runs,
passes smoke/BVT tests). This makes it very difficult to complete a project
without anything to show for it.

Integrate early and often, don't wait until the last minute. Integrate
skeleton frameworks together and then iteratively add features. This helps
avoid having a huge amount of unknown risk due to integration failure at the
end of a project, mitigating that risk translates to more schedule reliability
and higher chances of project success.

Also, working iteratively helps ensure that progress is constantly being made
rather than potentially wasting lots of dev-cycles on work that may not be
ultimately viable.

Keep the "customers" in the loop. With a version of your software that
actually runs they can keep up to speed on the latest features and
capabilities as they are actually implemented. This makes it much more
difficult to ship something that is wholly different from what the customer
actually wants. This isn't a sure-fire recipe to avoid shipping the wrong
thing, but it is one of the most reliable, achievable, and cheapest ways of
doing so. It's certainly preferable to getting a room of lawyers and engineers
to hammer out a contract that embeds a precise specification for the software
to be built. Besides which, a lot of software today is not built on contract,
it's built for the market.

The cult of Agile is a serious problem, and people who think that any
management technique can actually protect them from not doing any management
work is an even bigger problem. Agile's core problem is that it can serve as a
conduit for micro-management and it can make it hard to sell doing research or
expensive (but valuable), long-term investments. But the solution isn't to
abandon the concept, the solution is to work better.

------
skybrian
The author of the article is missing a negotiation essential to XP, at least:
the customer can change his or her mind, but the scheduled tasks are based on
developer estimates on how long they will take.

You can't make these estimates with any accuracy without the customer and at
least some developers talking. Furthermore, customers aren't likely to pick
something that the developers have estimated will take a long time, unless it
really is that important to spend that much time on it.

Also, large tasks need to be broken down into smaller tasks to get decent
estimates, which means knowing roughly what needs to be done. If the job isn't
obvious, something quite like traditional planning needs to happen there.

The planning difference is really for smaller changes that don't have far-
reaching consequences.

------
simon_000666
Classic consultant move. Trash talk current status quo, rebrand old solution
and package it as the holy grail and make $$$ selling your services. What he
proposes will also always fail because it is a process dictated from the top
down - hire expensive consultants to tell management what to do then dictate
solution to rest of org. Unless the solution emerges bottom up it won’t make
jack of a difference.

~~~
Yhippa
I was on board with the article, head-nodding all the way, until I got to that
part.

------
dragonwriter
Current HN title is both not the source title and a misrepresentation of the
point of the article. Both the title and body criticize “acephalic Agile”,
which the author defines as the use of Agile tools without Agile governance.
This is not arguing that “Agile is worse than Waterfall”, but at most “a
particular mode of quasi-Agile is worse than Waterfall”.

(Given that the Agile Manifesto doesn't say anything directly about tools but
entirely lays out a philosophy addressing governance, I'd actually argue that
“Agile” tools without Agile governance aren't anything like Agile, and aren't
even really Agile tools; Agile tools are tools chosen for a particular tasks
_through_ Agile governance, at a level higher than the governance level this
price addresses, and applied within an Agile governance process at the level
this piece addresses, which is not to endorse the particular governance
approaches in this article or it'd horrendous strawmanning of Waterfall, which
inasmuch as it is a real model, is an iterative model of exactly the type this
piece is advocating.)

------
rossdavidh
"At least in Waterfall if you did a good job of designing the project, and if
you stuck to the spirit of the method, you were to some extent insulated from
management noise..."

I think it's an interesting article, with good points, but fundamentally I
have to disagree with this statement. Empirically, it just isn't true, in my
experience. It just means that all those changes by the customer to what they
wanted, that the devs object to and management (which has to meet the customer
face to face) always in the end agrees to, happen at the end, when they are
more difficult, because up until that point the project wasn't "real" to the
client, and they really couldn't tell you what they wanted until they saw that
what you built wasn't it.

~~~
vannevar
People constantly confuse agile _development_ with software _design_. Agile is
not, and was never intended to be, a way to design software. It is a way to
implement software. How you design it is up to you, though agile certainly
encourages you to involve all stakeholders from the beginning, and to make
design changes incrementally throughout development as circumstances warrant.
But it is not a design methodology.

~~~
vannevar
It might be useful for the anonymous downvoter to contribute to the
discussion. Why do you disagree?

------
jcelerier
More generally : for any given X and Y, there will be enough instances of X
being better than Y and Y being better than X to feed both sides of internet
debates

------
davidkhess
I'll never understand why the software development community as a whole seems
to have such an NIH attitude to software project management. Meaning, why
aren't our people studying what works in other industries and figuring out how
to apply it to our industry?

Is it some conceit that software development is somehow truly unique compared
to the problems and concerns faced by other industries? That's dumbfounding to
me if so.

Our industry is barely 70 years old and hardly anybody seems interested in
stealing the best ideas and practices from other industries that in some cases
have been around for thousands of years.

~~~
balfirevic
> Meaning, why aren't our people studying what works in other industries and
> figuring out how to apply it to our industry?

Some are: [http://alistair.cockburn.us/Characterizing+people+as+non-
lin...](http://alistair.cockburn.us/Characterizing+people+as+non-
linear,+first-order+components+in+software+development)

From the abstract: We methodologists and process designers have been designing
complex systems without characterizing the active components of our systems,
known to be highly non-linear and variable (people). This paper outlines
theories and projects I reviewed on the way to making this stupendously
obvious but notable discovery and four characteristics of people that most
affect methodology design and project outcome. I find these characteristics of
people to be better predictors of project behavior and methodology success
than other methodological factors.

~~~
davidkhess
Very nice. Thanks for the pointer!

------
wink
> but at least this way if the developers are working a late shift because of
> a rash promise they’ve made, they are the authors of their own misfortune,
> which is easier to bear. It’s a social contract: we give people control,
> they accept responsibility.

Congratulations, your lead developer is now a middle manager. I've never been
a fan of "committing to a certain amount of stuff done by the end of the week"
as in scrum sprints. It's a zero sum game. Sometimes you do 3 days' worth of
work in an afternoon and sometimes finding an extra semicolon takes 2 days...

~~~
accnumnplus1
To your first point, I had a very productive project where instead of as in
the article the devs become managers, our project manager was brought very
much into the dev team, almost as a tester, using the product daily. He became
attuned to the pace of development and never over-promised anything. To your
second point, I've had projects where I simply assigned a day to every task,
and it turned out remarkably accurate.

------
coldacid
Quite the editorialized headline compared to that of the actual article.

------
geebee
I always refer back to the original agile manifesto when I read about how
badly things have gone.

[http://agilemanifesto.org](http://agilemanifesto.org)

What a beautifully simple document, written in clear and plain language.

Now consider a paragraph like this one:

"How are matters improved by Agile? The benefit of Agile is that, by splitting
the project into sprints, we have more opportunities to tweak the project
vector, to exercise governance, altering the project’s course. Each sprint
offers new control points (during both planning and acceptance), at which we
can amend direction. Splitting the project as a whole into a series of such
sprints offers us a corresponding number of opportunities to reorientate. Each
iteration offers more chances to retune the project. We have much greater
granularity of control, and more opportunities to exercise that control."

This blog post is, frankly, full of this sort of language. "tweak the project
vector". "exercise governance". "control points to amend direction".
opportunities to "reorientate" (reorientate? yes, it is a word. it means,
according to the OED, reorient).

I'm kind of curious, this is HN, there are dev here. Does this sort of
language make you eager to sign onto a development team?

I understand that lots of things have gone wrong with "agile", but the
language we use to talk about it seems to have degraded badly, and in many
ways, this tells the story better than almost anything else.

------
sailfast
I liked this article until it got into the charts and didn't really outline
what the governance points actually entail in terms of work. I'm also missing
how the bottom part actually gets you closer to the goal at the end unless you
explicitly make setting that goal part of your governance / planning / project
start which wasn't really mentioned.

I gather from the article's initial paragraphs that these "Governance" point
is really the team getting input from all the normal stakeholders and creating
the backlog of work themselves? This makes all the sense in the world -
getting technical folks involved in discussions is key.

What I would like to see added are concrete steps / workflows that these
technical teams have found that help make these governance points effective
without eating up a lot of time, and what practices they used to ensure that
the project goal / direction / outcomes were decided upon up front.

I personally think Agile Roadmapping / Storymapping with the whole group can
go a long way toward ensuring whatever you build is going in the right
direction. From there, you'll want the team to work with the product owner
folks and keep a tighter grip on the backlog toward that direction and good
things can happen.

------
nartz
"In what follows I’m assuming that we’re talking about a project rather than
merely a production line for rolling out bug fixes and features. In the latter
case you can use Agile tools like Scrum to deliver code incrementally, and
come to no great harm. In talking of a ‘project’ however, I’m thinking of a
larger program of work in which an entire solution has to be designed and
delivered, (more or less) complete. Such projects have distinct beginning,
middle and end phases, all of which must complete successfully if the project
is to succeed."

This doesn't make any sense and is contradictory.

It seems you admit that Agile works for "Rolling out bug fixes and features"
and to "deliver code incrementally" without "coming to great harm".

Then you say that this is somehow different from "an entire solution [that has
to be] designed and delivered".

What precludes "an entire solution" from being developed in an Agile fashion?

Presumably, agile would be to build out the skeleton, and incrementally add
small working features over time in increments such that at the end, you had
working software that was what you wanted.

You'd put your skeleton it into beta use as soon as possible once it provides
any value, and get frequent feedback to iterate.

------
vannevar
You can maintain a waterfall-style project plan and use that to feed stories
into your agile sprints. If something needs to change, then you feed that back
up into your master plan, just like you would if you missed a milestone. The
difference is that, with agile, you get more continuous feedback and you
explicitly model iteration in your plan (since if you're doing it right,
you're delivering progressively more capable versions of the entire system and
not just components to be integrated at the end). Nothing in agile precludes
long-range planning, or taking deadlines into account.

------
billysielu
Shocker. Managing requirements well results in successful projects.

------
joker3
Still no silver bullet, huh? Who would've thought?

------
majke
Perhaps I'm not an expert, but I always felt there are things left out by the
more popular methodologies.

This article scrapes the surface:
[https://michaelochurch.wordpress.com/2015/06/06/why-agile-
an...](https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-
especially-scrum-are-terrible/)

> "The worst thing about estimates is that they push a company in the
> direction of doing work that’s estimable. This causes programmers to favor
> the low-yield, easy stuff that the business doesn’t actually need but that
> is 'safe'".

> "Good engineers want to work in engineer-driven firms where they will be
> calling shots regarding what gets worked on, without having to justify
> themselves to 'scrum masters' and 'product owners' and layers of non-
> technical management"

> "Scrum [is] tailored toward the body shops where client relationships are so
> mismanaged"

> "Open-plan offices are the most egregious example. They aren’t productive"

> "[Scrum is] Like a failed communist state that equalizes by spreading
> poverty"

There is more. In "pure scrum" it's not obvious how to account for
refactoring, developer experimentation, improving infrastructure (or creating
one from scratch!), making tests better. Product driven things - sure, can be
driven by scrum. But what to do when work is driven by engineering?

~~~
gaius
Right, Agile is for outsourced/offshore teams cranking out intranets or
shopping carts or adding another minor feature to an existing codebase written
by someone else. Like maintenance on a legacy app.

The kind of work that good engineers thrive on - a hard problem starting with
en empty Emacs buffer - is something that the methodology merchants have never
experienced themselves. The only product they ever shipped is the methodology
itself!

I say this as a one-time “certified scrum master”.

~~~
prepend
This is a pretty tough statement to defend. Take a look at the myriad of open
source projects, or just limit it to Apache’s
[http://apache.org/index.html#projects-
list](http://apache.org/index.html#projects-list) and you’ll see a bunch of
“empty emacs buffer” projects with a long audit trail of agile development.
Not necessarily scrum.

~~~
gaius
My only personal experience of agile is scrum, so I will concede your point
:-)

------
williamdclt
The article foundation is fair: "Agile tools provide a steering mechanism, not
a homing device". But I'm not sure what point it's trying to make after that?
"Use an Agile framework"? Just "be aware of it"?

------
dfischer
Developers should abandon agile:
[https://ronjeffries.com/articles/018-01ff/abandon-1/](https://ronjeffries.com/articles/018-01ff/abandon-1/)

------
dfee
We’ve entered the trough of disillusionment, for sure.

[https://en.m.wikipedia.org/wiki/Hype_cycle](https://en.m.wikipedia.org/wiki/Hype_cycle)

------
amriksohata
Agile has become a recruiters and highwr management's marketing term, look
we're agile join us. But they never have real buy in or understand what it
means.

------
spking
I think Zed Shaw proposed the best system:

[http://programming-motherfucker.com](http://programming-motherfucker.com)

~~~
baal232
What is that system? Dismissing other methodologies without proposing a
workable alternative? Reveling in vulgarities?

~~~
spking
It's a little humor that anyone who has dealt with any of these methodologies
would likely appreciate (if they don't wilt at the sight of profanity).

------
connorelsea
Not the real title at all. Hope mods change it

------
jiveturkey
HN title is clickbait. Article title is much better.

The article makes a very reasonable argument, however I wish he wouldn't try
to introduce some new term, Agile "governance". He's just describing what we
already know -- that Agile isn't Agile and care must be taken to institute it
correctly. via "governance" as he calls it but this isn't a new revelation.

~~~
greglindahl
The entire thing is a thought experiment; of course it's easy to think up
nightmare scenarios for Agile development. It would be much more interesting
to read about actual disasters.

~~~
amiga-workbench
Its a hypothetical that I have experienced on several projects now, project
managers can have a totally warped understanding of agile in that they think
they can change course at any point and it won't have any resulting costs in
either time or complexity.

~~~
greglindahl
Sounds like you could have written a much better article than this one, then!
Cautionary tales are much better when they're real and not imaginary.

