
Why “Agile” and especially Scrum are terrible - amberes
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
======
vannevar
Like so many rants against Agile, this one assumes that it's intended to
provide everything you need to take software from a drawing on a napkin to a
fully functional, deployed product. The author goes even further and assumes
that Agile is also supposed to provide a system of professional development,
and all your R&D to boot. Why not blame it for not offering a guide to
retirement investing while you're at it?

Agile is a process for managing software implementation. Period. You have to
bring your own software design process, and if your company's is terrible (or
nonexistent), don't blame Agile. You also have to manage your own software
R&D, though you could certainly use the process to manage projects within R&D.
But the idea that Agile somehow precludes R&D itself is ludicrous, no more
sensible than saying it precluded your company from spending enough on
marketing. Even sillier is the idea that it should provide some kind of career
advancement plan. Agile is a software development process, not a personal
development process. It doesn't (and shouldn't) offer a career roadmap any
more than your build system does.

~~~
beckler
So I don't really agree with your opinion, but I don't think you're entirely
wrong.

I've been doing scrum for about a year, and while I think agile is excellent
because of the feedback look, I also think scrum is the worst agile method.
Mainly because non-technical management will turn it from managing software
implementation, into managing employees. But it's worse because you have to
tell everyone your progress, and god forbid you actually have a problem and
fuck up that sprints velocity. I was almost fired once because my velocity was
half of what it normally was one sprint, due to basically dropping development
work and doing devops for a week.

I've been on a project where we had marketers join our sprints, and we're even
assigned stories. Timeboxing genuinely difficult problems into two weeks is
extremely stressful, and most product owners don't care about complexity, only
results. I've had to make some super nasty hacks just to help get a "win" to
make a client happy. True scrum is just too rigid for applications with
complex problems, which is why you'll have a hard time finding two places that
do scrum the same way, or keep processes consistent sprint after sprint. In my
opinion, I find kanban to be a much more effective way in managing
development, as it allows your engineers to actually solve problems. So I
agree that agile is effective, but I don't think scrum is always the answer.

Sorry about the word vomit.

~~~
vannevar
These are really good observations. If there's a common thread, I would say
it's the intolerance for failure exhibited by managers who don't understand
software development. I'm not sure that intolerance would be lessened by
another system, whether it be waterfall or kanban, or ad hoc. Prior to agile,
when failure happened, it tended to happen in a big way near the end of the
project. But if a project were two or three years long, as is common in
software, everyone could move on to other jobs after having spent two or three
years without having to report progress every day or demo features every two
weeks. A couple years in one job is pretty typical nowadays. So in some ways
it was a more comfortable environment for engineers.

Agile was introduced so that failure could be amortized and tracked. It makes
the development process more transparent so that mid-course management
corrections can be made and the corporate ship can be steered around the
icebergs instead of running blindly dead into them. But in order for it to
work, management must be tolerant of small failures. If it's not, then scrum
will become theater with failure swept under the rug, and you'll be right back
where we were, with failure becoming apparent only near product launch, when
the iceberg suddenly appears out of the fog too late to avoid it.

Now, it may be a valid criticism that agile expects too much from management,
that most software company managers aren't competent enough to use it. But
that pretty much says we're all doomed anyway, regardless of what system (if
any) is employed.

I'd be interested in your thoughts on why you feel kanban is better, since my
impression is that it is essentially the same process but without sprint
intervals.

~~~
beckler
So kanban and scrum are fairly similar, but the difference is that with
kanban, you don't have to estimate a point value to it, as time isn't the
priority.

I view this as an advantage for two reasons:

\- 1. Most non-technical clients view point estimates as absolute
expectations. They can't comprehend an estimation in any other way. So if I
can do 5 points a day, and I give a story 13 points, it's expected to be
accomplished in ~2.5 days. If I exceed that amount of time, I've missed their
expectations, and now I have a client who considers that work behind schedule.

\- 2. Large complex problems can be solved without the pressure of
accomplishing it within a finite deadline. I think this leads to more robust
implementations, and helps prevent large amounts of technical debt. To
compare, I have never seen a scrum project that didn't have a runaway amount
of technical debt that lead to some insane scope creep in stories later on.

It has a downside of potentially hiding some problems, but I think it helps
with individual responsibility when it comes to tasks. Every time I've used
kanban, it's usually been for pretty short periods, but those periods were
extremely productive and way less stressful.

I mean, this is just all my opinion, so take it with a grain of salt, but this
is what my agile experience has been so far.

~~~
vannevar
Thanks, interesting perspective. The advantage of sprints is that you're
demoing progress on a regular basis. I can see the possibility of people
focusing more on the demo than the ultimate purpose of the code, in which case
as you say you'd accumulate technical debt in the form of hacks. But if you
don't demo regularly, you run the risk of hidden problems where everyone
assumes something works when in fact it doesn't. Either way, competent
management is needed to avoid the pitfall.

~~~
spronkey
The 'hack a demo' problem highlights one of the rationales behind having a
Definition of Done in Scrum. Unfortunately Scrum doesn't put hard and fast
rules behind what should be in it, but most good Scrum teams take principles
from XP such as all code should be tested. This helps reduce the 'hack' factor
at the expense of getting it out the door faster.

------
icedchai
This is all true. I worked in a medium size (400+) fully "agile" organization
There was constant short term thinking and seemingly nothing was properly
designed or actually engineered.

External facing APIs changed regularly, affecting other teams and leading to
slow and painful integration. By regularly, I mean just about every sprint.
How about thinking more than 2 weeks ahead?

It didn't help that there were lots of inexperienced guys just out of college
(who probably thought this was normal.) Along with a "manager" with extremely
poor communication skills (not uncommon in development) this was basically a
disaster.

We did, however, have lots and lots of unit tests. We spent about half of each
"iteration" rewriting them due to the API problems.

I gotta laugh.

~~~
spronkey
Sounds like a problem with the organisation and engineers. Unless of course
the externally facing APIs had to change regularly because of requirements
changing, in which case welcome to software development, you were probably
lucky that those external APIs weren't an opaque box for six months like they
may have been without an agile methodology.

------
icebraining
I don't disagree with the digs at Scrum and similar implementations of Agile,
and I certainly agree with the spirit of criticizing (in the 'art critic'
sense) the processes we use, instead of blindingly accepting whatever gets
thrown at us.

That said, I think this post falls short at acknowledging the difference
between the general Agile concept and Scrum as a particular implementation (of
which there are many), and I have a few further disagreements:

 _Instead of working on actual, long-term projects that a person could get
excited about, they’re relegated to working on atomized, feature-level “user
stories”_

Translation: instead of working the way I enjoy working, programmers have to
work in a way I dislike, therefore Agile is terrible.

As a programmer, I _like_ working on small features and projects, and the
variety that comes from taking on different types of work.

Long-term stuff is nice too, but despite what you might think, not everyone
gets excited about the same things you do.

 _often disallowed to work on improvements that can’t be related to short-
term, immediate business needs (often delivered from on-high)._

People being disallowed to work on core improvements happens in any kind of
organization system.

Around here, we use "processes [that] promote sustainable development" and
which allow us to "maintain a constant pace indefinitely." That means
occasionally allocating people to refactor and improve the codebase, when the
programmers feel that need and point it out.

 _Atomized user stories aren’t good for engineers’ careers._

Well, then it shouldn't be hard to show that engineers with Agile-based work
experience have more difficulty getting hired. Is there evidence on that?

 _5\. Its purpose is to identify low performers, but it has an unacceptably
false positive rate._

Absolutely no argument here. The constant tracking is demeaning and often
counter-productive.

That said, I don't think Agile requires it, just specific implementations of
it (like the aforementioned Scrum).

~~~
spronkey
Agreed with many of your points - although I don't think that the purpose is
to identify low performers, per se.

It's more about breaking down development into small chunks at a time, so that
if there are performance (or specification, or other) issues, they can be
dealt with quickly.

------
nvarsj
The best thing about this article is the linked book in the comments: "Agile:
The Good, The Hype, and the Ugly". I suggest checking that out for a more
nuanced view.

I think also the OP doesn't give agile/XP enough credit for the good things it
has mainstreamed. For example:

\- Sustainable pace (don't work > 40 hours week). Agile companies, in my
experience, tend to have good work/life balance.

\- Continuous integration. Release and integrate often.

------
robotkilla
Having read ken schwaber's "agile Project management with scrum" something
like 8 years ago and hearing him speak, and working with agile teams during my
most junior development I couldn't fucking agree more. I loved scrum when I
first started using it, and I was a horrible developer back then. I pity
anyone who had to work with me.

This article was strangely heartwarming.

~~~
ChristianGeek
Interesting...my experience has been the opposite, largely due to the fact
that the description of Agile/Scrum in this article is nothing like the way it
was implemented in my last company. (We built our processes and goals based on
the original Agile Manifesto.)

~~~
tome
I would be very interested to hear you say more about your experience with
Agile!

------
LethalDuck
To save repeating myself: [http://blog.binarymist.net/2014/01/25/essentials-
for-creatin...](http://blog.binarymist.net/2014/01/25/essentials-for-creating-
and-maintaining-a-high-performance-development-team/)

------
spronkey
This is a poor article on many levels. Even basic facts don't check out.

Agile didn't "grow up in web consulting", and it wasn't about dealing with
finicky clients who couldn't be "managed". It came from enterprise both large
and small, mostly not involved in web or consulting. In fact, it arguably
started before _software development_ did - see Kanban at Toyota.

Agile _software development methodologies_ came from a real need to reduce the
failure rate of software projects that was, even 10 years ago, closer to 50%
than 0%. It attempted to provide ways to stop the _average_ software project
from running nearly 50% over budget. It waged war on the "big design up front"
methodology handed to us by other engineering fields and acknowledged that in
the real world, software development is often a wicked problem
([http://en.wikipedia.org/wiki/Wicked_problem](http://en.wikipedia.org/wiki/Wicked_problem))
that cannot be solved until it is solved. It acknowledged that requirements
change, and software takes such a long time to build, often by the time a
large design is built it already doesn't do what it needs to.

Almost all the statements the author makes are misleading, or misguided.

Violent transparency? It's a good thing that helps software projects succeed.

Atomic little user stories? They embody the divide and conquer philosophy to
break down the author's ambiguous "long-term projects" into small chunks that
can be understood, tested, and estimated. And delivered _quickly_.

Shared ownership? Promotes respect of the team, organisation, and customer.
Helps get rid of bat-cave developers who can't acknowledge genius other than
their own. Helps diffuse any blame for failure.

Social organisation? Has little to do with agile methodologies and a lot to do
with the enterprises that implement them. Some do it well, some don't. Scrum
doesn't dictate that a product owner or Scrum Master is more important than
the engineer. Contoso Shiny Widgets Inc. does that. Just like they dictate
whether experience and skill are valuable in their teams, and whether they
listen to their engineers about technical issues that cause the kind of
technical debt that is hard to solve with "good design".

Exit strategy? Short term? What? Use an agile process when it makes sense.
Stop using it when it makes sense. Of course the process is designed to be
there forever - they're tools to be used by people trying to solve real
problems. The nature of those problems changes over time.

Lack of R&D? Software development is prima facie the D. The R? It's entirely
possible to do that in iterations. Agile processes certainly don't remove R&D
- spikes are there almost exclusively for R, and they're a first class citizen
in the process unlike pre-agile. Perhaps the author refers to those 'long-
term' projects that more often than not end up nowhere?

Technical debt? The author doesn't understand agile at all. Agile has two main
tools to help manage technical debt - fast feedback loops, and encouraging
development in small vertical slices. The best agile has even more - XP
promotes TDD, not prematurely optimising, refactor mercilessly among other
things. Basically universally accepted ways to improve the quality of
software.

Crunch time? No! Agile promotes sustainable pace. To help avoid death marches.
Heard of those? They've derailed careers for good.

I'm no big supporter of Scrum - it lacks the software design guidelines of
e.g. XP, and it's been abused by some companies for their own purposes
(probably those the author has worked for). But it has some fundamentally good
ideas, and since Agile methods have been around enterprises small and large
have improved on many measurable metrics. It's the best we currently have -
come up with something better.

~~~
wirrbel
Well summarized. Especially appaling is that the author does identify agile
concepts wrong. The sprint impediment is taken as a measure for weeding out
low-performers. I am not really in the mood to look up an exact citation, but
I have always understood the "impediments" to be external impediments, not
team-internal ones. Its pretty lousy as a argumentation strategy to compare
apple with pears. If this was the interpretation of scrum in that guys
company, I feel really sorry for him.

