
Agile won the war but lost the peace - mpweiher
https://www.allankellyassociates.co.uk/archives/2762/agile-won-the-war-but-lost-the-peace/
======
brightball
Sprints are where all of the issues with agile really come from. Constant
arbitrary, meaningless deadlines that serve no purpose but create rushes, tech
debt, missed “commitments” that serve as a meaningless metric to use against
teams while made commitments give no benefit.

Everything around sprints to try to avoid the negatives results in huge wastes
of time in meetings attempting to plan better rather than actually getting
work done.

Sprint are the root cause. Just use Kanban and you eliminate most of your
problems.

~~~
umvi
In defense of sprints, not everyone is the same. Deadlines for me are a strong
motivation to get things done, whereas "no deadline, just do it at your own
pace until it's done" will cause me to procrastinate and get it done much more
slowly.

There is no silver bullet for software development process. It takes hard work
and flexibility to optimize your team's work flow.

~~~
yebyen
I've been reading "It Doesn't Have to be Crazy at Work" and they have a
chapter about this. Deadlines are great! Estimates are terrible, and humans
are terrible at estimating. Scope needs to be elastic to accommodate this fact
of life.

If the project is not done in the 6 weeks you set aside for it, just ship
something anyways and move on. It was only worth 6 weeks when you planned on
getting it done in 6 weeks, so why spend more? Go ahead and plan another
sprint if it turns out what you were able to build in the time allocated
wasn't enough, and you really need more. (Put it up against the other
opportunities you have, and give them all a fair chance at those finite
development resources, something else might also turn out to be more
important.)

Just don't spend forever and drag out the deadline, throwing off the timeline
for whatever you had planned to do next, because you needed more time for the
thing that underestimated how big it was, so it wasn't really possible to do
that whole thing in only 6 weeks.

The release that is reduced in scope might be totally insufficient, or, it
might be just what your users needed! The knife also cuts both ways – if
you're willing to accept that project scope can change in either direction,
you can occasionally deliver things early too.

I really like everything about this book.

~~~
TheOtherHobbes
If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are
you likely to ship a broken product, but you also have no way of making
intelligent business decisions about possible projects.

Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will
bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you
bet on the wrong horse, you've dented and/or sunk your cash flow for no
reason.

Saying "Humans suck at estimating" is nonsense. It's a skill that can easily
be improved - usually at the cost of some up front planning - and there are
plenty of resources to help you with that.

The real problem with Agile is that it gives management an excuse to do no
estimation at all. Some alpha-wannabe manager bangs their fist on a desk and
says "I want this in three weeks".

Instead of saying "You're insane" teams are pressured into trying to make up
for someone else's laziness and lack of contact with reality.

~~~
coldtea
> _Saying "Humans suck at estimating" is nonsense._

And yet it's the conclusion every major thinker (and practicer) in our field
has come to (plus there's historical evidence from tons of mis-estimated
projects, regardless of scope and budget).

So, whether does the idea that it's "a skill that can easily be improved" come
from? Wishful thinking? I don't think the universe works that way.

Sure, you can learn to be less widely off. But you can't never learn to be
regularly correct at estimating, or even close within a small margin.

At best, what happens is that quality get shitty and corners get cut, and you
get the product at the correct deadline, but it's not the same that you wanted
to ship before development started (even if the features are nominally there).

~~~
msla
> So, whether does the idea that it's "a skill that can easily be improved"
> come from? Wishful thinking? I don't think the universe works that way.

I've come up with two names for this kind of thinking, one a bit grumpier than
the other.

The less-grumpy one is the "Is From Ought Fallacy": It's well-known in
philsophical circles that going from "Is" to "Ought" is wrong; that is, saying
"something is this way, therefore, that's the way it ought to be" is a
terrible argument. Well, when you flip it, it gets even worse: "Things ought
to be this way, therefore, that's the way they are" isn't just a bad argument,
it isn't quite _sane_. Yet look around you, and see how often it's used.
(Hint: Abstinence-only sex ed. Hint: Drug prohibition.)

My grumpier version is "Arguing With Reality": You can argue with people,
whether you define "arguing" to be a screaming match or a logical defense of a
thesis. That works. It's sane behavior. Going out and arguing with the rain
that it needs to be sunny now... isn't. Rain's gonna rain, people are gonna be
bad at time estimates, and making logical arguments about why the real world
shouldn't be like that doesn't change the real world one iota.

Maybe they're just variants of the "Utopia Fallacy", or the perfect being the
enemy of the good: "If the world were perfect, it would be like this,
therefore, doing anything else, even if it gets good results, is imperfect and
compromising perfection is wrong." Yeah, pull the other one.

------
maxxxxx
This always happens with promising technologies or methodologies once big
companies get their hands on them. OOP was a great idea until it turned into a
strict religion, Agile was good until it turned into a micromanagement system,
the internet liberated people until it turned into a surveillance machine,
collaboration is good so we got a workplace with open offices that's so
distracting that it's hard to get work done. Watch the same happen with FP or
things like diversity.

Companies are basically dictatorships that want to control their employees
("resources") and everything else so it's pretty natural that they will
distort every new movement into a tool to extend that control.

~~~
spaceribs
I think it's easy to look at the short-term and miss the larger picture.

The printing press being the only other well documented time of this explosion
of knowledge/technology allows us to see that no matter how power expands and
then coalesces, it takes the good ideas, fragments away, and then repeats the
process as a sect of the greater power.

------
Aeolun
I think the problem with Agile as implemented by larger corporations is not
anything described in the article, but that it’s just fundamentally
antithetical for corporations to work agile.

There is just no way that some salesperson is going to be able to sell a
product that’s going to be developed in collaboration with a customer in 2
week increments (unless the customer is already specifically dealing with a
software consultancy).

They sell a package of ‘this is everything the product is going to do’ and
then somehow try to squash that waterfall list of features into ‘stories’, and
call it agile.

~~~
williamdclt
That's just factually false: to give a counter-example my company (~200
people) does exactly that (1 week sprints, though).

Except that we don't sell "a product", we sell time. We'll do everything we
can to help you getting a product out of this time, but if you can't, you were
doomed from the beginning.

It's just a different thing to sell for a salesperson, they have to adapt. But
it works.

~~~
Aeolun
E.g. the one exception I made in my message, a software consultancy.

------
lordnacho
I never saw agile as anything other than some useful observations about
project management. Get feedback fast, sync with team members often, don't try
to plan the whole thing in one go.

Any particular incarnation of it, say Scrum, is going to have issues when
applied to real world problems. Guidelines like "get quick feedback" are
useful, but decrees like "one week sprints" can get tyrannical.

Luckily a lot of people seem to understand that and I've never met anyone who
insists on doing exactly according to some specific scripture.

------
dberg
To me, I think everyone took the processes WAY too literally which caused the
whole big "A" Agile versus little "a" agile. I have seen many orgs get super
wrapped up in all the typical nonsense of stories "falling over", religion
about who owns the backlog which takes away autonomy of the team, religion
about the process for breaking a sprint as new discoveries are made, arguing
over product work versus addressing tech debt or working on automation, etc.
You end up focusing more on "being agile" than delivering new features.

I 100% agree with the other comment around "checkin" points so that work
doesn't linger forever, but the forced short delivery boundaries very likely
slow teams down overall especially when all the process overhead of points,
backlog grooming, standups, sprint planning, demo session, etc are all
factored in and mandatory every 2 weeks.

Commit to some scope, on some cadence/date, loosely check in on progress, and
adjust as needed as a team. Deliver as frequently as possible and demo your
work when you can/should.

~~~
MBCook
This sounds pretty accurate to what I’ve witnessed.

I’ve seen Agile done well, which I really liked. Mostly what I see is water
scrum.

It’s important to pack every single thing you can into a sprint based on your
estimate of points, otherwise you’re wasting precious resources. Of course
that means you never get everything done so huge chunk of the sprint always
rules over.

Everything is dictated from the top, there is no autonomy on the part of the
team (or almost none).

As bad as all this is, a quickly falls apart whenever something doesn’t go
exactly the plan. In other words, constantly. So you just get further behind
and more things roll over into the next sprint.

They’re “agile”. They hold demos of the tiny bit that got done and
congratulate themselves. Because they don’t do waterfall anymore. They GET IT.

But none of the benefits. Because that would require actual change.

------
wgerard
The problem, obviously, is not Agile.

This will, naturally, cause hairs on necks to rise waiting to scream back
"What are you talking about? Of course Agile is the problem!" But really, the
problem is that any business trend/fad is inevitably doomed to become a hollow
shell of what it was intended to be.

Or more pointedly: Businesses don't really want to overhaul their development
process, and any new process integrated will inevitably become just an
extension of whatever they were doing before. This is basically what the
article's saying without directly saying it.

I mean, the very first phrase in the Agile manifesto is:

> Individuals and Interactions over processes and tools

And yet see how many anecdotes in this thread are about how the most annoying
part of Agile is the rigid adherence to certain processes. If 1 week sprints
are too short, change them to 4 week sprints. Figure out the cadence that
makes sense for your team. _That 's_ what Agile is supposed to be about.

Regardless of whatever Large Co wants to call their development process, let's
stop calling it Agile and start calling it what it really is: Waterfall with a
Kanban board and shorter deadlines.

~~~
ken
> The problem, obviously, is not Agile.

Sure, any true Scotsman can see that.

What reason do we have to believe that Agile is so great, if (as you point
out) most business aren't actually doing Agile?

~~~
coldtea
> _Sure, any true Scotsman can see that._

I call BS. Yes, the "any true Scotsman" fallacy can happen in a discussion.

But it's also true that some things are presented as X but are not X, and it's
not a fallacy to point this out.

Here the parent specifically called attributes of Agile that are there in the
original manifesto, but are not adhered.

That's not shifting the definition (which is what a no true Scotsman is
about), it's about pointing that a thing doesn't adhere to the original
definition it was supposed to hold.

> _What reason do we have to believe that Agile is so great, if (as you point
> out) most business aren 't actually doing Agile?_

That's an orthogonal question. Agile might be great or bad.

But we can't deduce from businesses doing something non-agile and calling it
Agile whether agile is good or bad.

At best we can deduce that Agile has a tendency to be wrongly applied.

------
marcus_holmes
So true. But then, Agile solved problems developers had, not project managers,
sales people, or accountants. In fact, it caused those people more problems.

It was only ever going to be actually implemented in developer-run
organisations, because only then are developer problems more important than
everyone else's problems.

Maybe that's the answer - more developer-run organisations.

~~~
geezerjay
> Maybe that's the answer - more developer-run organisations.

I don't agree. Once you put a developer in a project management role, he
starts to experience problems associated with managing projects and using
solutions to those problems.

When that happens, the developer ceases to be a developer and becomes quite
plainly a project manager.

------
ScottAS
Some Buddhist wisdom:

In life, we will always find “shining cities” to chase. The perfect house, the
perfect job, the perfect romantic partner, the perfect software team.

But, like a mirage, when we reach these goals it seems that the thing we
thought was perfect is actually riddled with flaws.

“The shining city” is purely a mental construct, one that gives us structure
and purpose, staving off “existential nausea” - the anxiety that comes from
living a directionless existence.

The way to everlasting peace is to be able to acknowledge: “we live in the
shining city right now. Everything is operating according to the laws of
physics, humans follow human nature and their genetics. Everything is exactly
how it should be.”

But this isn’t “giving up”. It’s ok for us to have “shining city goals”. It’s
human nature. It’s fun and allows us to experience a journey.

But at the end of the day when you see the mirage fade, smile about the
journey and the experiences you had along the way.

~~~
booleandilemma
_The way to everlasting peace is to be able to acknowledge: “we live in the
shining city right now. Everything is operating according to the laws of
physics, humans follow human nature and their genetics. Everything is exactly
how it should be.”_

This is not wisdom, it’s nonsense.

If we followed this advice 2000 years ago we would still be practicing open
defecation and dying at the age of 30.

~~~
ScottAS
I bet if you measured contentment levels then and now you would not find much
of a difference! In fact you might find people are less content now than
shitting in a ditch 2000 years ago.

But I did not mean this as an excuse for “non-progress”. Humans will
“progress”, it’s their natural instinct and drive. It makes more sense to make
our lives easier than to make it harder.

But the shining city doesn’t exist, and there’s nothing that will
significantly increase our internal contentment but winning the internal
battle of acceptance.

------
XorNot
I've yet to see anyone actually do Agile where the tasks were broken up into
reasonable increments. All of my Agile experiences involve a project manager
throwing a sentence up on the board for what they want done and saying "yeah I
think it'll fit in this sprint" for something which no one has any idea how
long it'll take because the scope is unknown and no preliminary investigation
has been done (a process which would take maybe a week).

"Task estimation" for sprints never seems to involve any actual data on which
to base the estimates.

~~~
hippich
There is a concept of "spike" work. Basically, when you do not know what it
takes to implement something, you work on a "spike", the result of which will
be new stories better describing what needs to be done.

~~~
jasonlotito
What happens when the spike is done early in the sprint. Do you just hold off
a week or so until you can report back? And who works on those follow up
tickets? The person who did the research? They've had the most experience, so
that makes sense to me, but I've been told everyone should be able to pick and
choose, and if I don't grab the tickets fast enough, I'm sol.

~~~
MBCook
Part of the spike should be documenting the results so that anyone else can
use them if there are the person who picks up the next ticket.

If the person who does it just remembers it themselves and doesn’t do anything
to help the other developers then they haven’t completed the spike.

~~~
closeparen
There’s nothing worse than having to execute someone else’s minute breakdown
of work. People should be responsible for executing their own ideas. Then you
get feedback on what was and wasn’t correct, and have only yourself to blame.

Having that ownership stimulates a much greater level of craftsmanship and
skill growth. Documentation is great, but the idea that a spike author and
implementor should be different people is awful.

~~~
MBCook
The spike doesn’t define HOW the later work is done, only the information it
was supposed to research.

How to do something would be sorted out during grooming or perhaps when adding
the story to the sprint.

------
amai
Agile always fails, because bookkeeping and financial processing in companies
are not agile. Contracts with customers are also not written by sales with
agility in mind. So in case time/money runs out agile processes and rules
(like "never break a sprint" etc.) will always be ignored, because finance
needs the numbers and the customer was promised a fixed feature set at a
specific date for a specific price.

mandatory Dilbert Comic:
[https://www.flickr.com/photos/lucaminudel/6059269914/](https://www.flickr.com/photos/lucaminudel/6059269914/)

~~~
jdmichal
I don't think that's a real comic. Looks like the Dilbert site used to have a
feature to modify / make your own comics, but I can't find it anymore.

------
kylnew
Do devs really hate agile? I’ve really enjoyed it in workplaces despite it not
always being perfect. I’ve never felt micro managed either, just regularly
managed. I understand that maybe some want more free will to pursue problems
the way they feel is right, but it’s a job at the end of the day and you are a
human resource being paid to deliver results. Make sure you’re being
compensated enough, at least to not feel like you’re being exploited.

~~~
mathieuh
I hate it. Constantly being pressured to move some stupid card or add some
stupid tag so people’s graphs look nice. I just want to get work done, Scrum
just adds overhead.

~~~
cc81
How much overhead is it really? 15 minutes a day at most?

~~~
pjmlp
Not if you have the misfortune to be a single developer project or having a
lead role on a team.

Someone needs to convert those Jira/Trello/Wall/... items into nice Excel
sheets because upper management won't look at anything else.

While you are at it including some nice Powerpoints for the weekly/monthly
updates.

And on the remaining time do those development tasks, while coaching junior
devs at the same time.

~~~
mdorazio
If you have a lead role on a team the large majority of your time should be
_leading the team_ by doing all those non-development tasks. If you're trying
to also cram in mission critical development you're trying to do too much or
your company's leadership sucks. If it's a single developer project, 1) Agile
might not be the best approach, and 2) updates to management should take very
little time since you just need to sum up what you personally have
accomplished and are planning to accomplish vs. whatever deadlines exist.

~~~
pjmlp
That's the nice theory and then there are the actual real life projects, hence
why we reached the point discussed on the linked article.

~~~
mdorazio
Yes, that is the nice theory and also the nice real world. And yes, I've been
on and managed dozens of projects at 10+ companies over the last decade so I
feel confident saying that. Sounds to me like your company's leadership just
sucks. That's not a problem with the methodology.

------
ereyes01
A big insight for me about where Agile seems to work and where it doesn't was
learning about the Cynefin framework [1], which tries to characterize
different states to guide the style of organizational decision making.

When viewed through the lens of Cynefin, Agile seems to make sense when you've
narrowed down a problem space you want to tackle, but you still require rapid
iteration and experimentation to finish defining all the finer points of the
goal (the liminal state when moving from Complex to Complicated).

My impression and personal experience of Agile being a bad fit seems to be
associated with a misunderstanding of the decision domain, and the general
Agile "religion" that has arisen where it's applied uniformly to every
situation.

[1] [http://cognitive-edge.com/videos/cynefin-framework-
introduct...](http://cognitive-edge.com/videos/cynefin-framework-
introduction/)

------
bigbluedots
Usually the claim is that if Agile is not working for you, you're 'doing it
wrong'. This article is no different.

------
projektfu
People who work in sick environments will not be saved by Agile. These
techniques are meant for teams that already have members who trust each other,
in a company that trusts the team, to work with customers they know, who would
like a usable product that they can develop and extend the requirements for as
they learn more about how it will work.

It helps prevent the sicknesses that come from attempting to do all this up
front, where an eager team and an innovative customer try to specify
everything up front and nail down a price tag right away.

It should be sold to management as a form of risk management, not as a way to
extract more value from a fixed amount of dollars. If you have $4 million to
spend, and you spend that up front, you may waste $4 million. If you spend it
bit by bit, and have a functional system after every few weeks, that you can
migrate to if you like, then you have not wasted any money, even if you end up
throwing it away partway through.

I agree with anyone who says the problem with Agile is that it is watered
down. It was a least-common-denominator of all the various similar techniques,
and I think a lot was lost by encouraging people to adopt Scrum instead of
eXtreme Programming.

Nevertheless, I've consulted on a lot of projects and there are environments
in which I would not want to attempt to implement any new methodology. The
people already hate each other and the system is totally sick. They need
something more like Deming's management techniques where they get the top to
commit to empowering the bottom, retrain and move out people who are in the
wrong job, and get a remaining nucleus of players who trust each other to
implement a new method (or their own).

What ends up happening is programmers come into sick environments, run by
"Agile" managers, and say that Agile is the problem and if they could just go
back to their office and ignore everyone they could get it done. They're
probably half right, in that they also need the full support of the customer.
Since programmers are a noisy bunch, they complain far and wide about Agile,
saying that it's the cause of all the diseases in their world. But sick
systems often have names that are misleading. Deming once saw a poster on a
client's break-room wall (or something) touting "Total Quality Management" and
he said something to the effect of, "I hope that you aren't predisposed to
think I'm wrong because of this", meaning that someone had already set up a
sick system and claimed it was inspired by Deming.

------
tannhaeuser
Do you know any substantial software in wide use that was created using
"agile" methodologies?

------
vinceguidry
Meta-point: Nothing wins the peace, peace is just war that's managed to make
itself sustainable.

~~~
MaxBarraclough
Disagree. Peace means not swinging the axe. If you can't tell whether the axe
is swinging, you shouldn't be applying a war/peace metaphor.

Also, war can be sustainable, especially if it isn't total war. Look at Europe
a few centuries back.

------
yumraj
I'm my experience, the irony is that Agile is agile about everything except
itself. Companies adopt scrum, after reading a book or worse hiring
consultants, and try to follow it by the letter without applying any
intelligence or taking into account that one size rarely fits all.

Personal anecdote from working at the largest ISV, which went gung-ho on scrum
such that careers called scrum evangelists were created, engineers and
engineering managers became scrum masters and the program managers, jobs that
should have become obsolete to an extent as scrum mastersv take in lots of
those responsibilities, started doing who knows what. But of course anyone
saying anything against the scrum was a dinosaur.

------
gfs78
Just history repeating itself.

They are rediscovering the PMI ad-hoc.

Not because the Agile ideas weren't better but because human and hence
organisational dynamics still are and will be the same.

No surprise then, that as Agilists are gaining traction and power they are
making their Agility more rigid and dreaming of Chief Agile Officers and roles
like that.

Organisations have power structures and position there determines progress and
survival.

They have to de-agilize agility to survive. If not they will have nowhere to
go, nothing to latch onto when things go wrong

------
vannevar
The title is a nice turn of phrase, but there's no real content in the
article, just a series of unsupported assertions painted over with a sense of
wistfulness. It reads like a nice proposal for an article that has yet to be
written.

------
menzoic
Was hoping the author would explain what people get wrong about agile.

------
Animats
Good point, bad article. He never gets to the "why".

------
luord
"Agile" hasn't even looked like a word to me in years. It's become nearly
meaningless.

------
tychomaz
Yeah it doesn’t mean “agile deadlines”

------
cjblomqvist
From my understanding, Agile was developed by developers sick of the rigid and
static waterfall model and the problems caused by such a model. In discussions
on Agile I often see a lot of complaints about managers not doing it right,
wrongfully expecting developers to commit to certain things and then actually
deliver on that. As a manager, I must say I feel a little bit offended. Not
only did the developers specifically ask for Agile in order to fix the issues
with late projects that doesn't fulfill their purposes, they are then telling
us in threads like these it's our fault. What I read from these comments is a
lack of understanding and ownership of the problem, and capability to solve
it.

To sum it up: Problem: Missed deadlines/cost overruns and lack of success in
fulfilling the actual problem. Solution in theory: The theoretical,
engineering/developer, solution to the problem: Less commitment and more
flexibility. Basically set the right expectations that we'll drive in the
wrong direction and then need to correct it rather than continue because
that's what's originally agreed. The "solution" in reality: Less commitment
and less responsibility and ownership of the business situation (which hasn't
gone away and never will). What happens: Less focus on the original problem.
Developers thinking that deadlines and not fulfilling the purpose is even more
something that is the problem of managers, and not developers. When shit still
goes south because developers are still often not any good at tackling the
original problem (although the promise was made by them it'll be better if
they run the show), they (as obvious from the comments here) still put the
blame on management.

In other words. Developers thought they were better at solving a problem than
a person in a role dedicated to solving those types of problems (compared to
developers where it's not in focus at all), still blames management when their
proposed solution failed. Ironically (but very logically) the least capable
are the ones complaining the most and owning the problem the least.

What I believe has caused the situation: An immature industry (due to young
age), a complex problem and a lot of demand for developers making
companies/managers not having enough leverage to be able to pressure devs into
focusing on the right thing/development (the rockstar mentality). Plus of
course inexperienced managers that doesn't dare to take control over the
situation.

The worst part of it all is that it takes away focus from the actual problem,
and hides a lot of incompetence (both on the manager and the developer side)
which I find is often a root cause (and my understanding is that science agree
with me - which and how correctly you use a specific methodology/process is
not strongly correlated with overall success.

PS. I still believe Agile is good in many cases and there a lot of smart
developers doing Agile with great results, but there are equally a lot of
people who believe they at better at solving problems they are perhaps the
least capable of. What's really sad is that many of those people are actually
quite good developers.

------
lowry
«Хотели как лучше, а получилось как всегда» is better translated as "We tried
our best — you know the rest".

------
draw_down
Is anyone else tired of this story by this point? Agile was wonderful and
beautiful, the problem is all the people who didn’t do it right. We get it.

There used to be a joke, “this job would be great if it weren’t for all the
users”. It was supposed to be a joke.

------
marsrover
Agile is like communism. Looks good on paper but you end up in Soviet Russia.

