
Cargo Cult Agile (2008) - ekzy
http://www.jamesshore.com/Blog/Cargo-Cult-Agile.html
======
struppi
I have been thinking about this a lot, ever since I first read this article,
some years ago.

Most of my freelance projects and technical coaching gigs in the last few
years where at companies that were in or after their "Agile transition". And
most got "Agile" horribly wrong.

I think cargo cult is an issue, but the problem goes deeper. I wrote a
conference talk titled "Your Company Will Never Be Agile" around that topic.
The gist is:

Many C-level executives want "true business agility" for their company: They
want to be able to react quickly when circumstances change. Many "workers in
the trenches" (developers, testers, ...) want to be able to do good work and
provide value to the customer.

But in established companies, the organizational structure, processes and
policies, annual budgets, KPI and bonus systems and middle management prevent
the company from becoming truly agile.

So, young, small companies are more agile, because (among other things) they
did not become a bureaucracy _yet_ , they are mostly run by engineers with not
much middle management, and because of survivor bias (they do not have a war
chest yet, so those that were not able to react quickly do not exist anymore).

Unfortunately, there is no English recording (but the slides are here:
[https://speakerdeck.com/dtanzer/your-company-will-never-
be-a...](https://speakerdeck.com/dtanzer/your-company-will-never-be-agile) ).

~~~
taneq
> Many C-level executives want "true business agility" for their company: They
> want to be able to react quickly when circumstances change.

True, and this isn't a bad goal in and of itself, but what they don't realise
is that these 'quick reactions' (aka fundamental low level changes in the
product) may require orders of magnitude more work than said executives expect
(and in fact, probably the work required is at least linear in the age of the
company).

> (they do not have a war chest yet, so those that were not able to react
> quickly do not exist anymore)

I'd argue that having a 'war chest' is actually detrimental to agility (if
you're thinking of agility as 'the ability to perform at our current level in
a different field'). Small new companies can pivot extremely fast because even
if it means throwing away their whole codebase, they've only lost a few
months' work.

~~~
stiva
> I'd argue that having a 'war chest' is actually detrimental to agility [...]

I believe that's what the parent is saying as well. I read it as saying that
larger companies with a 'war chest' are able to weather the problems caused by
reacting more slowly, and so agility is not as highly prioritized, while
smaller, newer companies have to react quickly or die.

------
tomelders
I could wax lyrical about Agile all day long. If you google 'Agile Bullshit',
a comment I wrote on HN a few years ago is usually in the top three results,
and because of that I get an email once a month from someone driven to despair
by said 'Agile Bullshit' who feels compelled to get in touch with me and vent
a little. I enjoy the emails, and I think they've given me a much broader
perspective on agile than my own experience alone could offer.

I've been writing an article about Agile for years now, that I can never
finish. But here's what I consider to the be the two biggest problems with
Agile.

1\. Agile can never work in an agency, where the client has control over
budgets, deadlines, and features. There is simply no incentive for the client
to compromise when your agency has made some pretty ridiculous promises and
put themselves on the hook to deliver.

2\. There are some teams that deliver well under agile (as per the metrics
that the business has defined), and some that don't. In my experience, the
ones that deliver well produce the worst work because they won't push back on
a design or a feature that's incomplete, nonsensical, or plain impossible.
They do what they're told and add no value to the overall output. This is
especially true of offshore development teams.

The teams that produce the better software do push back, but the Agile process
as implemented everywhere on earth does not support them. Instead, animosity
grows between the developers who push back, and the product-
owners|BA's|designers who can't or wont understand the problems with their own
work.

But! Some process is better than no process. And I've worked in some companies
that take Agile very seriously and are willing to put in the hard work to make
it work. And I suppose that' the secret sauce that's missing from most
organisations that are "Agile", they think it's a trick, a hack, a cheat, a
short cut.

It's not. Like everything else worth doing, it's hard work.

~~~
jaggederest
> Agile can never work in an agency, where the client has control over
> budgets, deadlines, and features. There is simply no incentive for the
> client to compromise when your agency has made some pretty ridiculous
> promises and put themselves on the hook to deliver.

There's an interesting triad that I've been talking to people about a lot
recently.

1\. Authority (the ability to make decisions of importance)

2\. Accountability (a way of telling if you are doing better or worse)

3\. Responsibility (pride and reward proportional to the results you deliver)

Essentially when you lack any of those three, you cannot operate effectively.

Without accountability, you have no way of knowing what success is. Without
authority, you have no power to recruit help or make the necessary changes to
be successful, and without responsibility, no amount of accountability or
authority matters.

This is especially true in asymmetrical relationships like customer-vendor and
employee-employer.

~~~
Chris2048
I'd change the labels a little, since I think those terms are overloaded:

I think 'authority' is 'agency', or 'self-determination',

'accountability' is 'direction'/'awareness'/'sensitivity'/'comprehension',

'Responsibility' is actually 'motivation': It also might matter if this is
'pride', or 'avoiding blame', and to what degree it is 'reactive' and
'proactive'. Obviously, knowing what you are responsible for, and having every
are have a point of responsibility is important too; 'accountability' seems
similar to this to me.

~~~
jaggederest
I wouldn't change those labels, actually, the responsibility-accountability-
authority triad is pretty well known if you google. It's just not familiar to
most folks in programming I guess.

------
danpalmer
Agile is the only word I know that inverts its meaning when you capitalise it.

The team I work in is fairly agile, in that we communicate well, react to
changing priorities very quickly, and ship things regularly. We're not perfect
by any means, but whenever we consider adding more of the typical "Agile"
process we always realise it would slow us down, and we see other companies
with more set "Agile" processes being much slower.

~~~
mpweiher
Yes. The funny thing is that at a company I worked for in the 90ies, we were
very agile, before that became a thing, and it was GREAT. Empowering, fun,
engineering-driven, effective, efficient. The things we did with our tiny team
were amazing.

When I read about XP, what I read very much resonated with what we were doing,
without ever having a name for it other than "what we do and like that works
well".

However, whenever I've seen Agile applied at other companies, it was horrible.
And yet they refer to the same words. Someone recently told me "Agile/XP/etc.
sound like slaves trying to figure out better ways to please their masters".
And when I take that frame of reference, yep, that is exactly what it sounds
like.

So something weird is going on with those words.

~~~
theprotocol
The issue is that "agile" was a descriptive word, used relatively loosely.
Then some people tried to capture its essence and artificially engineer it
into their process, and it became prescriptive.

Some things are better left to occur organically. If you want to be "agile,"
then reevaluate your corporate culture and create an environment where it
might occur. It needs to be _you_ , you can't fake it, much to the chagrin of
some of the more uncharismatic business types.

------
flukus
I'd argue stand up meetings are the opposite of agile, the insistence on them
is literally breaking the first rule of the agile manifesto:

> Individuals and interactions over processes and tools

Probably breaking the fourth too:

> Responding to change over following a plan

How many companies have done a retrospective on whether the daily recitation
of Kanban board movements​ is providing any value?

~~~
jwdunne
To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in
and overhauls your processes. That is, in effect, processes and tools straight
up, from the minute that scrum master goes on a course.

It wouldn't be much of a course if it didn't teach some process for
implementing SCRUM.

It wouldn't be much of a consultation if the consultant tells you to go speak
to your customers and find out what is really bothering them and how you can
deliver working software quickly to alleviate that.

So you have daily standup a, weekly retrospectives, a designated master,
product owner, a process for estimation, a n-week sprint. Those are must
haves. That's all process.

~~~
mikekchar
I think you have the same misconception about the first rule that many people
do (forgive me if I'm wrong).

> Individuals and interactions over processes and tools

This does not mean that you minimise process and tools. This means that
individuals and interactions trump processes and tools. So if you have a
process that doesn't fit the people on your team, then you change the process,
not the team. Similarly, you try to encourage interactions through as many
avenues as you can. You don't say, "You must use this tool and only this tool
to communicate".

But it's a mistake to think that you want to remove process. That's not
"agile". That's "ad hoc". There is nothing particularly wrong with ad hoc
processes if you are successful, but the "we'll just use common sense"
approach that many teams attempt is usually anything but successful.

Process is there to support individuals. When I am coaching a team, I never go
in with the idea of introducing any particular process. Of course, I am more
skilled with some processes than others, but imposing _my_ skill on a team I
am coaching is not going to be successful. Instead, I watch what people are
doing and write it down. _That_ is the process. At that point I start looking
at problems that we can solve. I look for places where the process is not
consistent, or where people are struggling because they don't know what to do.
Then I try to extend the existing processes so that it is consistent across
the team. Finally, I start introducing things that I'm skillful in where I am
sure it will make a difference. At this point the team is already delivering
with their process and we are just looking at ways to optimise.

There is a lot more to it that this, of course. However, for me this is the
minimum thing that you need to do to coach a team. I've tried other approaches
(when forced to by upper management), but I've never been successful.

~~~
flukus
> But it's a mistake to think that you want to remove process.

It's also a mistake to keep a process that isn't delivering any benefit
though. I've seen very few stand-ups that provided a benefit and zero where
there was no other way to get the same benefit.

~~~
LoSboccacc
especially as the team and code grow there's little reason for standups,
nobody cares about what most of the other people tells anyway unless they're
effected in their goals.

much better to have a team leader who knows the tasks for everyone and warn
people when they are operating an area where they can step on each other toes,
so that they know they need to coordinate.

the Nx(N-1) rigid reporting structure of stand up makes very little sense

------
9gunpi
Another kind of cult is religious adherence to methodology while ruining the
very value the methodology is supposed to enhance.

When you think something is stupid (like adopting only standups), frequently
it's because you don't understand the motivation behind it. Standups are one
of the first obvious changes any team, no matter how oldschool and rigid, can
adopt and see the results behind it quickly, to encourage further
transformation.

When you're changing something big (like a development process that is stable,
consistent and filled with people, resources, operational and deployment
plans, etc.), you want to change it either radically, or chunk by chunk.
Radical changes are easy to decide yet hard to pull off while preserving
business continuity, it's a bit of a gamble not everybody is willing to take.
So, many executives want the "transformation" to actually be "step by step
evolution". And one of the first steps are standups and enhancing the
planning.

All of the above doesn't debate the fact that there are companies which get
Agile terribly wrong, and companies which can't get Agile right due to
extremely rigid structure. However, not all companies who fail to visibly
transform into Agile in a few easy steps are like that: sometimes they're
stuck on early iterations, slowly working their ways further while preserving
continuity and market momentum, and there's nothing wrong with it.

~~~
douche
Standups are a complete waste of time. Whoever floated that idea and made it
popular should be ashamed of themselves.

I was sick of "circle time" and "show and tell" when I was in kindergarten. I
don't need to deal with that as an adult when I have work to do.

------
Nursie
To echo another comment on here -

Daily standups have been the most useful development I've seen in my 17 year
career so far, I'm not sure why there's the hate for them.

It's a small time allotment where everyone gets just a couple of minutes to
sum up where they were yesterday, where they're going today and what's holding
them up.

I've seen them go wrong, when managers decide that they need to attend and use
part of the meeting for "management announcements". I've seen it go wrong when
one team member cannot shut up and regularly took over the whole meeting (yes,
the scrum master was ineffectual). But in general I've found the daily rapid-
fire catchup a thing of beauty.

The rest I can take or leave. One of the worst projects I've ever observed had
a highly paid SCRUM Master/Consultant/Trainer and that team seemed to spend
several hours each day on process. They failed to deliver anything, ever, the
product was scrapped and everyone was laid off, including the development
manager.

~~~
dasmoth
_Daily standups have been the most useful development I 've seen in my 17 year
career so far, I'm not sure why there's the hate for them._

Two things that bother me:

1) You either have to hold them at the start of the working day (in which case
they become a synchronization point and everyone has to turn up at the same
time -- which will inevitable be a bad time for some people) or a bit later
(in which case you end up with an odd slot at the start of the day which
usually isn't long enough to start on anything substantive).

2) They mandate daily visibility, and (by design, I think) prevent people
going off for a week or two and solving something substantial on their own.

There are possible solution to (1) -- e.g. asynchronous stand ups in a chat
client (and it's probably not coincidental that the only times I've found
these things at all helpful, they've followed this model rather than the
actual stand-up-in-circle thing). But (2) is kind-of the whole premise of
"agile teams", so not sure what can be done about that.

~~~
humanrebar
> asynchronous stand ups in a chat client

I've been thinking this is _actually_ the perfect standup. People don't tend
to write novels in chat clients anyway (and to the extent they do, you can
move the text to a README or wiki and just link it).

Does anyone have any experience with this? Any pros and cons worth mentioning?

~~~
ashark
We do. Post in Slack. It's great because you can ignore anything that doesn't
mention you (which is what people do in napping-while-standing IRL standups
anyway) but you can always go back and see what someone's up to if it becomes
relevant.

Well, I wrote "great", but the latter case _should_ be handled by other tools
anyway. So really the whole thing could be replaced by just at-mentioning
someone who needs to know what you're doing, when they need to know it. Which
is just, you know, normal communication. But if you must do standups this is
the way to do it, I guess, since it does the least harm.

------
cvs268
Based on my personal experience, most projects are doomed from the start due
to these 2 MAJOR problems:

1\. Not prioritizing the task of gathering, decomposing and documenting use-
cases at the project kick-off.

2\. Chronically under-estimating effort required.

[1] [http://thecodeartist.blogspot.com/2015/04/use-case-is-
everyt...](http://thecodeartist.blogspot.com/2015/04/use-case-is-
everything.html)

[2] [http://thecodeartist.blogspot.com/2017/04/effort-
estimation....](http://thecodeartist.blogspot.com/2017/04/effort-
estimation.html)

~~~
fiftyacorn
I dont think its "under-estimating" as much as to get buy-in in a corporate
environment means promising to over-deliver

Architects/Developers can also be their own worst enemy - chosing a new stack
over the existing stack

~~~
cvs268
That too.

However most of us tend to be overtly optimistic about the possibility that
something will work as expected. Also we tend to forget the secondary tasks
involved[3].

Also the fact that there is usually an expected schedule/due-date that are
presented before being asked for estimates, people tend to invariably try to
fit the effort-estimate into the pre-determined schedule subconsciously
neglecting the secondary tasks.

Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks
do-able, i can try...". Completely forgetting the fact that i am being
expected to raise it from an egg, and take care of it for a few months first.

[3] Slide 8 - [https://www.slideshare.net/cvs26/effort-
estimation-73647698/...](https://www.slideshare.net/cvs26/effort-
estimation-73647698/8)

------
_pmf_
Also nice: the joke by Rich Hickey that Agile solving software development via
sprints is like someone revolutionizing the marathon by firing a starter
pistol every 100 meters.

~~~
joncampbelldev
Thats a good one, from his "Simple made easy" talk[0]

[0] [https://www.youtube.com/watch?v=zPT-
DuG0UjU](https://www.youtube.com/watch?v=zPT-DuG0UjU)

------
overgard
This is anecdotal, but I've found that the more "agile" a place is, the more
underworked I am. In most non-agile places, if im out of work its up to me to
find a way to make myself useful (agency!), but in agile environments I
usually am told not to take something on because "it wont fit in the sprint".
I generally think agiles main benefit is bringing the low performers up to
average, but at the cost of handcuffing your top performers.

~~~
pdelbarba
When I worked with a bigger agile group one of the things I liked was having a
task list put together and then divided up among everyone but also having an
'on-deck' group for stuff we didn't think we'd have time for. Anyone who got
things done faster would have their pick of the on deck work and was some
extra freedom and recognition for doing so.

~~~
overgard
Its a nice idea in theory, but generally ive found these reserve backlogs are
full of things nobody actually wants to do, they just think itd be vaguely
nice if someone else did it. Its either stuff with no direct business value
(refactor the flargenstock), or high-risk/low reward work

~~~
pdelbarba
Yea, I think you have to do it well. In general for us it was either fun extra
features that product management wasn't super excited about or stuff that was
just planned for later.

------
zer0tonin
I should explain that to my boss, we're literally doing waterfall but with
standup meetings...

~~~
adrianmsmith
Great stuff.

I asked one Agile coach about how and when one should do software architecture
decisions for a larger project, he said you can take an extra sprint/spike at
the start to do software architecture if necessary.

At another place, the testing members of the team always tested the previous
sprint's work (otherwise they'd be doing nothing for the first 80% of the
sprint, if they tested that sprint's software).

So if you had a requirements sprint, a software architecture sprint, a
development sprint, then that gets tested on the next sprint, what process
does that remind you of? :)

~~~
Sharlin
That is still iteration. Agile doesn't say you can't do things in phases, it
just says those phases need to be short enough that you can iterate on them.

~~~
valuearb
Yea but how done is your sprint if your work isn't tested?

It's the old, "done" vs. "done done" debates we had end of every sprint. I
wrote the code, it mostly works, it has bugs. Am I done? Should I move on?

Technical debt creeping higher and higher.

------
seanwilson
I don't see value in stand ups most of the time and usually they just get in
the way of your work e.g. "I'll start this feature in 30 mins because we've
got a standup in 10 mins". I already know what most people are doing from
either group chat or the planning board, and a lot of details won't have much
relevance to everyone so you end up zoning out just like you would in typical
bad meetings.

The "what did you do yesterday?" part can also encourage people to scramble to
justify they worked hard enough yesterday when it's tricky to condense why a
task isn't as trivial as it sounds.

What did you do yesterday? What are you doing today? What is getting in your
way? That's exactly what planning boards are for! Create a Slack bot which
automatically summarises and posts this for each team member every day if you
really must.

Planning boards are great though. They give you an overview of what everyone
is up to, what progress is being made and they're little effort to keep up-to-
date compared to having to reply to lots of emails about "what's going on?".

------
rhapsodic
I think the most critical factor in the success or failure of a software
development project is the skill and dedication of the developers. Yet I never
seem to hear or "Agile Coaches" mention that. I guess clients would not be
receptive if someone were to tell them that their best course of action was to
replace half of their team.

~~~
overgard
I think this is why agile is, frankly, so insulting. I went to a good
university for four years to learn computer science, a field that is
legitimately hard. I produce real business value daily. And yet this
methodology places about as much trust in me as a mcdonalds worker.

------
tempodox
I have yet to see an implementation of "Agile" that's not a cargo cult pretext
for micromanagement.

~~~
dasmoth
Some advocates are pretty open about this:

    
    
       https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging
    

Interesting question is -- why is micromanagement by "the team" more palatable
to some (many?) people?

~~~
overgard
It is an interesting question. I suspect its palatable because it evens the
playing field. The game changes from skills based to politics based, and that
suits some people better.

------
partycoder
I think the article is correct. Agile has valid motivations and solves
concrete problems.

But in practice, you will eventually see confirmation bias and cargo cult.

The motto of delivering customer value has been used as an excuse to emphasize
the surfaces exposed to the customer (e.g: features) and neglect non-features
(non-functional requirements, e.g: maintainability, security, performance,
scalability, configuration, testing).

------
codingmyway
Microservices seems to be the latest cargo cult technique being pushing
without really considering whether the benefits outweigh the costs. Some
consultants always need another thing to push that a particular company's
problems for them so therefore it must be applied everywhere.

------
RiffyRiffy
All managers not only engage in waterfall, but covet all of the privileges of
waterfall. The ability to tell lessers what to program down to the line of
code is the ultimate expression of power for people who will never, ever be
C-level. And to top it off, they use their powers to force you to compel you
to agree that their practices are agile.

Agile has never, and will never exist when micromanagement is a good enough
drug for those who will never reach actual influence.

~~~
9gunpi
This is very true, but Agile isn't the only un-achievable property in this
case. Even basic healthy atmosphere and efficiency barely have a chance in
these situations, so expecting someone in a wheelchair to run feels a bit
naive.

