
Why Agile and Scrum Are Terrible - enkiv2
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
======
mcv
I've seen this kind of strawman argument against Agile before, though this one
builds a bigger and more detailed strawman than I've seen before. The problem
here is not Agile, it's slapping the label "Agile" on something and then doing
something totally different.

The great thing about Agile is that it's _not_ business driven. I mean, of
course you the work for business reasons, and the business people who have
determined what they need, need to be available to the Agile team (for example
in the form of a Product Owner in the case of Scrum), but in the end, it's the
team of developers that makes the decisions about _how_ they do it.

Of all the claims that this article makes about Agile, I haven't spotted even
a single one that's correct. All of them are quite obviously false. The
article is a piece of junk.

~~~
jmccree
It seems like you are invoking the No true Scotsman fallacy. There's a lot of
companies that do "Agile" and "Scrum" that are exactly like he describes. When
Feature X has to be done this sprint because it's already been sold to
(Board|Client|Investors|Other Dept), there's not much time to think about
"How?", it's more like "If I'm going to be working Sat and Sun again?".

I'm sure there are organizations out there where Agile/Scrum is working
fantastic for them in practice, and developers are happy with their work and
career prospects. I just have yet to encounter one in the wild personally.

~~~
AnimalMuppet
Words have meanings, or they are useless. So, let's define "agile". It doesn't
mean "apply a label to any process that you already have". So, where do we
find a definition for agile? Probably the best candidate is the Agile
Manifesto. But there's not much concrete process there, so now what?

I worked in an agile (and, in fact, XP) environment for a while. The rule
there was that the product manager owned the decision of what stories went
into the project, but the technical team owned the estimates. That's kind of
agile-y (we're doing stories and estimates, yay for us!), but it's also just
good engineering management.

If you're in a situation where "Feature X has to be done this sprint because
it's already been sold to (Board|Client|Investors|Other Dept)", you're in
trouble whether or not you call your process "agile". The trouble you're in
doesn't have much to do with whether you're agile or not, either - it has to
do with management that doesn't listen to engineering reality. (However, it is
a violation of at least one of the principles from the agile manifesto -
sustainable pace.)

~~~
dragonwriter
> So, where do we find a definition for agile? Probably the best candidate is
> the Agile Manifesto. But there's not much concrete process there, so now
> what?

So, now we recognize that "agile" doesn't describe the elements of a software-
development process, it describes a set of priorities which are used for
determining what process is adopted, and how the processes adopted are
applied, in a particular organization (a set of priorities which specifically
calls for consideration of the particular people involved and how they
particularly interact.)

~~~
AnimalMuppet
Fair enough. But that means that the complaints about agile don't really have
much to do with agile, they have to do with bad processes that are trying to
implement agile. (Scrum is more concrete, though, and can be more validly
criticized or defended without as much confusion over the definition.)

~~~
dragonwriter
> But that means that the complaints about agile don't really have much to do
> with agile

Well, yeah, that's usually the problems with complaints about agile -- they
aren't about agile, they are about a specific set of processes (usually ones
developed, adopted, and applied by an organization _not_ applying the
principles in the Agile Manifesto) which that particular organization, or the
consultant selling them, called "agile" as a way to hook on to the popularity
of the buzzword.

> Scrum is more concrete, though, and can be more validly criticized or
> defended without as much confusion over the definition.

In principal, sure, Scrum is subject to process-based criticism, although lots
of criticism of Scrum are about "what I've seen organization X, that claims to
be using Scrum, do" rather than "the framework defined in the Scrum Guide".

------
dragonwriter
> It’s probably not a secret that I dislike the “Agile” fad that has infested
> programming. One of the worst varieties of it, Scrum, is a nightmare that
> I’ve seen actually kill companies.

Scrum is not a variety of Agile. Agile is, per the Agile Manifesto, an
approach to software development which prioritizes (among other things)
individuals and interactions over processes and tools.

Scrum is a tool (a process, arguably, though it describes itself as a
"framework" as opposed to a "process", since any complete process will need to
add to what is presented in the Scrum Guide) laid out in a "definitive guide"
providing the "rules of the game". An organization might be applying Agile
principles and use Scrum, but those are largely orthogonal concerns.

> So what are Scrum and “Agile”? I could get into the different kinds of
> meetings (“retrospective” and “backlog grooming” and “planning”) or the
> theory, but the fundamental unifying trait is violent transparency, often
> one-sided. Programmers are, in many cases, expected to provide humiliating
> visibility into their time and work, meaning that they must play a side game
> of appearing productive in addition to their actual job duties.

This does describe the actual process in many places, but it has nothing to do
with "Agile" or "Scrum". It is a fairly common management failure that was
common among the canned one-size-fits-all processes many things that the Agile
Manifesto was a _reaction_ against; Scrum -- as defined in the Scrum Guide --
insofar as it incorporates what might be described as "violent transparency",
does not do so in a one-sided manner.

"Lots of things that are called 'Agile' have problems because continue to do
things -- which are also common without the 'Agile' label -- that the Agile
Manifesto was a direct response against" isn't a substantive criticism of
Agile, though its a good warning -- as is, after all, the Agile Manifesto
itself -- against buying a canned process or tool and applying it just because
the person selling it says the word "Agile".

------
bluejekyll
The comments on the main article are too long. This isn't a problem with
Agile/Scrum. This is a problem with poor management and not setting up teams
for success. The entire point of Agile is to enable teams to deliver on their
own schedule and by their own rules, with the team made up of all the people
who will enable that to happen.

~~~
JoeAltmaier
The OP makes real points about the failings of Agile. The Engineering team
ends up subject to the whim of the Product Owner, or worse yet the PO is
absent and things stall. Senior Engineers get marginalized, since they do
things that can take longer than a sprint or have to do with internals not
directly related to business needs. And Engineering is about a lot more than
features.

Agile works for some development groups. But it definitely does NOT work for
many others.

~~~
mcv
All the points it makes about Agile are utter nonsense.

In what way does the engineering team end up subject to the whim of the PO?
The PO needs to provide the details of what the business needs ( _someone_
needs to do that, after all), and what the priorities are, but he's in no way
in charge of the team.

If the team has no PO for a significant amount of time, that does mean that a
vital part of the team is missing, but I'd like to see any dev team build
something without any idea of the business needs. It's the PO's job to
communicate those needs, and the great thing about Scrum is that he does so as
part of the team, rather from some distant ivory tower.

I also don't see in what way Senior engineers get marginalized. If anything,
_everybody_ gets treated as senior, because everybody gets ownership,
responsibility and decision making power about the project (though in reality,
it's of course the seniors with the clearest ideas and tend to end up with
most of the control over the team).

And there's generally plenty of room to include stories (even very large ones
if they can't be cut up, though they usually can) about internals,
infrastructure and R&D on the backlog.

It's absolutely true that it's not for everybody, but your criticism and that
of the article don't hold much water.

~~~
AnimalMuppet
I think that the PO criticism is this: An incompetent or indecisive PO can
cripple an agile process. That's true, but (except possibly in the case of a
startup), there's _always_ a non-technical layer of management over you
somewhere, and if that layer is incompetent or indecisive, your project is
equally in trouble. Labeling that layer "PO" and the process "agile" changes
exactly nothing about the problem.

I've been in an agile process. It worked, mostly, but it broke down when the
PO didn't have the time to do the work. (It was huge for an agile team - 30
people - which put a huge amount of pressure on the PO position).

For the next project, the PO "didn't have time" to give us actual requirements
- just "improved reporting". In the most amazing display of agile that I've
ever seen, the development team lined up a series of customer conference calls
to expose their requirements for reporting, and proceeded to run the entire
development process without a PO. And that worked amazingly well...

... right up until three weeks before the scheduled end of the project. (We
were probably going to miss by a week, on a six-month project.) _Then_ product
management showed up and said "We like what you're doing. But we need these
additional things as well. Oh, and we can't change the end date." Predictably,
that was the end of agile, as well as the end of any management reality for
that project. (You think you can add three months of work without changing the
end date? The real world will demonstrate to you that you cannot in fact do
that.)

~~~
mcv
30 people in a single team? Yeah, that's way, way too big. I've been in some
teams that were technically too big, but those were still less than half that.

Still, good job making it work despite utterly dysfunctional management there.
Agile does require that management understands what you're doing and what
their role in that is. But again, that's true in any other situation too.

~~~
AnimalMuppet
Well, it worked _really_ well for the release before that. It took a really
strong proponent who was willing to hack process as we went along, but it
worked - for us, for a while.

