
Why do some developers consider Agile development to be nonsense? - RalfR
http://www.agileoverflow.com/t/why-do-some-developers-at-strong-companies-like-google-consider-agile-development-to-be-nonsense/107
======
outsidetheparty
This matches my experience.

We recently brought on a couple of PM consultants who are deep into Agile as a
methodology, and decided to give it a go -- it's been about six months now and
productivity has basically ground to a halt as we spend more and more meeting
time endlessly sorting tasks into different little arbitrary piles instead of
actually making forward progress. It's made communication with the non-
software part of the company much more difficult, because they keep getting
hung up on the jargon; we have to slice up tasks arbitrarily to get them to
fit into "sprints," which go out of date minutes after the morning standup
when the first non-planned bug report lands. Sizing is frequently an exercise
in post-facto book-cooking: 'How long will that bug take to fix?' is like
asking 'How long is it going to take to answer 23 across in next Sunday's
crossword puzzle?' It might be fifteen seconds, it might take all day; until I
have a chance to look at the puzzle I'm just pulling numbers out of my ass.
The short timeframes encourage everyone to twiddle around the edges of things
instead of doing real feature development; the arbitrary milestones serve
mostly to make everyone feel like they're constantly falling behind.

I've discussed this with a bunch of people. Everyone seems to agree that we're
doing Agile wrong, but even the strongest proponents of the methodology seem
to be in complete disagreement on what the "right" way to do it is, or how
that would be an improvement over the way we were doing things before.

So yeah. Not a fan.

~~~
progmanal
"'How long will that bug take to fix?' is like asking 'How long is it going to
take to answer 23 across in next Sunday's crossword puzzle?' It might be
fifteen seconds, it might take all day; until I have a chance to look at the
puzzle I'm just pulling numbers out of my ass." .

I find this attitude to be a little disingenuous. Obviously every bug cannot
be estimated perfectly, but the majority of the time there is some initial
data to make a reasonable estimate with a margin of error.

For instance to name a few:

\- Past experience with the module associated.

\- Whether or not it has been reproduced locally.

\- Similarity to other bugs that have come up in the past.

~~~
kabdib
Depends on the bug, sure.

It's my job [or used to be :-)] to give estimates of bug fix times to
management.

It usually broke down to:

\- trivial (about an hour)

\- nearly trivial (maybe half a day or a day)

\- "I have no earthly idea". The last one of these that I fixed involved about
twenty people, deep dives into our hypervisor and interprocessor communication
mechanisms, research into some hardware details and three 100+ hour weeks
about four weeks before we shipped. And we started out not having _any_ idea
where in the system the problem was (that took two of those weeks).

------
couchand
This article cements in my mind the issue: devs tend to take away from agile
what they expect to find, rather than taking the time to understand the
motivations and whole scope of activities.

Historically, most software development methodologies are excessively top-
down, so people somehow still expect that from agile. Most devs are the sort
that couldn't stand doing group projects in school, so the idea of organizing
with teammates to produce something bigger and better than I could on my own
is totally foreign.

If you don't explicitly name your development methodology, you still have one:
you're practicing something called ad-hoc development. Unless you and your
entire team are superheroes, there's an awful lot of knowledge being leaked
away.

Here's the secret: software development isn't really about making computers
work, it's about organizing knowledge. If your process focuses more on making
the computers work than your institutional knowledge you're making a critical
mistake.

Don't confuse some company's crappy engineering practices for agile just
because they call them that. Stand ups are short. Period. If it feels like a
"permanent PIP" your team could use some improvement. If it feels like a
surveillance state it's probably not a very good implementation of agile.

Agile development is about making connections to your team members:
_individuals and interactions over process and tools_. It sounds like the
author's experience (as well as many other devs') is unfortunately in an
organization that doesn't pay heed to that very first, most important agile
principle.

~~~
outsidetheparty
>Agile development is about making connections to your team members:
individuals and interactions over process and tools.

See, this kind of vague, fuzzy feel-good description is exactly why it seems
to me that the one thing everyone seems to agree on about Agile is that
everyone else is doing it incorrectly.

~~~
ddoolin
Agreed. I'd like to see some solid experiences that counter the author's
claims being used in the wild that fit where he says it doesn't work well
(anything other than small, short projects). Nearly everyone is taking the
"it's not us, it's you!" approach.

A lot of things work well in theory. That doesn't really make them good ideas
if they can almost-never be implemented properly.

~~~
Nizumzen
Yeah. Communism is great in theory as well. It doesn't work though.

------
davidgerard
The free e-meter at every desk is a valuable job perk! The Kool-Aid tasted a
bit funny, though.

Scrum-English Dictionary:

* "sprint": artificial crisis

* "end of sprint": abandonware

* "Scrum master": resume credit for my planned escape to a new company

* "stakeholder": someone you can't get away with externalising your costs onto

* "simplified": doesn't implement any of the actual business requirements

* "lightweight": doesn't implement any of the actual business requirements, but does so much more elegantly than the version that works

* "easy": project was born circling the drain (and doesn't implement any of the actual business requirements)

* "legacy": the version that works and implements the actual business requirements, even if no sane human wants to touch it

* "velocity": a speed with a direction, so skittering about following marketing's random hairpin turns counts

* "retrospective": blamestorm incoming!

* "stand-up": getting the blamestorming in early

* "We'll put that on the backlog": hahaha fuck you

I do enjoy some of the jargon. "empowered": do your own fucking job. "Could
you just copy down these log files from these fifteen servers for me and put
them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to
do that yourself."﻿

Seriously: every good idea is turned into a bad one by the relentless
management quest to Taylorise clue.

~~~
depr
The first and last definitions I find are very accurate. Do more!
(Retrospective, velocity, stand-up.)

~~~
davidgerard
:-D Done, also "stakeholder". What's the proper Scrum jargon for "maybe bong
hits will fix my makefile"?

------
ctdonath
_Every_ methodology fails from pretty much the same reasoning.

The saving point of Agile is breaking tasks into reasonable sizes, long enough
to actually get something done and short enough to rearrange as needed sooner
rather than later, and _to delay interruptions_ until they can be evaluated
and other tasks completed. I can't get to what I need to do if the relentless
onslaught of self-important "do _this_ _now_!" interruptions are handled as
they occur; Agile provides a sane way to say "get in line" such that important
issues are addressed in a timely manner relative to other issues and without
compromising other stuff that also needs doing (those that never reach the top
of the interrupt stack, but without which long-term progress won't happen).

------
dccoolgai
The term has been hijacked. It is useless. There is merit in the idea that it
once encapsulated, but it has long since been co-opted to mean something
almost completely the opposite of its original intention.

~~~
kabdib
Yeah. Scrum doesn't make management disappear, it amplifies it.

I saw meetings with middle managers (people who hadn't shipped anything
significant in a decade) in daily meetings, going over burn-down rates of
individual engineers and "expressing concern" through channels that someone
was off their schedule by a couple of days. The daily scrums were just half-
hour status-in-a-ring and some public shaming if you couldn't say that you did
anything, so a lot of people made stuff up, or at least hedged by saying
they'd completed 50% of the work or that tests were "nearly passing" (code
for: my stuff is broked).

Oh, and in the mean time the build system we devs were using had been on fire
and broken for three weeks and it was nearly impossible to get a working
build. WTF?

I said, "We don't need Agile. We need an earthquake to collapse that wing of
the building" (where the managers were; they liked to cluster).

We had Ken. Ken was there at the beginning for maybe a week, and for the next
few weeks after that it was great. But we forgot that middle managers are
still gonna manage, and that you have to fire them or they're still going to
be there, you know, _managing_ stuff, because that's all they know how to do.

And with the right tools, Scrum can be turned into the perfect surveillance
state. (I stole that from another response in this thread, thanks).

~~~
cmdkeen
Intriguingly you've not mentioned 2/3rds of the people in a Scrum team - the
Product Owner and the Scrum Master - both of whom are supposed to be the ones
who handle many of the problems you list. Build servers being on fire feels
like a perfect example of an impediment. People who aren't actually developing
anything feel like the perfect example of people who shouldn't be at standups,
and certainly shouldn't be speaking at them.

Again Scrum relies on empowerment, with the Product Owner being the "single
wringable neck" whose career is tied to the project and who has the buyin from
management to get stuff done. The point being that it is in their interest to
have a happy and productive development team doing what they say.

Finally there's also a really good point about internal and external metrics.
I've always been a fan of management getting the stats they ask for, not being
provided with access to the team's internal metrics which should really be
short term to address perceived issues. If we count defects for a few sprints
to reduce our defect count that is good, providing them for evermore to
management is bad. Separating the two out lets your Scrum Master / line
managers have a good conversation about what management are concerned about
and how to effectively measure it.

As you said - bad managers won't do any of this, but then flagging up that you
have bad managers is A Good Thing (TM) overall.

~~~
kabdib
Well, 2/3rds of the people in a Scrum team were essentially dead weight, in my
experience. They made work.

In one org, the devs were excluded from the planning meetings, which is pretty
much all you need to know about how badly Scrum went off the rails.

"Okay, you're signed up for X, Y and Z, it'll take you two weeks, and tell us
every morning about your progress."

"This is day 15 of the build system being totally broken, and I haven't been
able to run my code in a week."

"So, you're late. Is that what you're saying?"

(sound of door slamming shut)

------
UK-AL
IF teams are using Agile like that there doing it wrong. It's meant to be
recipe for collaborative, relaxed, friendly environment. Not a pressured hot
house. If your goal is to use Agile to push developers to their limits, you've
already failed the Agile Test.

You can twist Agile, based on your vision of good team is. So you have to get
the right people to implement it. You have to approach it from the idea of it
being a collaborative, friendly, no blame etc for it to work.

I've only ever used estimates in story points to prioritize things(That's why
its so abstract), not to monitor and push developers. If I wanted that, i'd
use actual time.

The idea of everyone is junior is also bad implementation. It means even the
most junior person is capable of contributing using their solution over a
senior persons solution. The right idea wins, not the right person. I can
understand why this pisses of senior people though.

~~~
michaelt

      IF teams are using Agile like that there doing it 
      wrong. It's meant to be recipe for collaborative, 
      relaxed, friendly environment.
    

I'm at a place where (IMHO) scrum works reasonably well. But some of the scrum
language I hear people using kind of invites misunderstandings.

For example, "sprint" evokes runners running 100m at a pace they can't sustain
for minutes, let alone weeks or months. And "committing to stories for this
sprint" implies it's some sort of failure or emergency if the target is missed
- when in truth nobody should be skimping on testing or staying late to get
things done.

~~~
nissimk
Yeah, I feel like the language is one of the worst things. A "scrum" is a
bunch of sweaty men moving down a field in a pile. The idea of that makes me
want to get a different job. I'm attracted to programming because I love
sitting in chairs, not engaging in violent pile ups.

I agree with what you said about "sprint," as that is the second worst word in
the canon.

And user stories is trying to change the term "feature" so that developers
will be more user oriented in their thinking, but the term "story" is
disturbing.

~~~
nissimk
I forgot the other one: "epic." I can't put my finger on exactly what it is,
but it really disturbs me. It's just too serious sounding, like it's
presumptuous to declare any component of your program as "epic" before it is
done. I can think of very few software systems or components that I would
refer to as epic.

Are you writing the story of the flood? Is it the oddysey, the iliad, the
history of your people? No, it's just some crappy new feature that's going to
take your team a few months to complete. That is totally not epic.

------
someengineer
One thing about Agile that I don't see mentioned much is that it provides a
way for bad managers to marginalize the effects of low performers among their
groups, though at the expense of high performers.

Every company has "cowboy" programmers who break shit and ruin their
coworkers' lives with massive 1am check-ins, and a lot Agile seems designed
specifically to put up road blocks to prevent this from happening. Managers
love it because it provides an escape from dealing with problem employees
directly. Most of the vehemently anti-Agile people I've worked with were
grossly overconfident in their abilities and difficult to work with, which I
think supports this idea.

Unfortunately, the only way for this non-management technique to be effective
is to do it dogmatically with no deviations (otherwise the cowboys will always
have some excuse for why it shouldn't apply to them), and this is where things
start pissing off the actual talent.

------
zimpenfish
The micromanagement - if management doesn't trust you to get on with work
without having to justify what you've done every single day, why did they
bother hiring you in the first place?

~~~
AndrewDucker
People aren't perfect. It's easy to get distracted, get off track, think that
you'd be able to get back on track if only you could get your head down for a
couple of days, and suddenly two weeks have passed, you're miles behind, and
the people waiting for your work are all thrown off track because it's not
there yet.

Spending 15 minutes per day making sure that everyone knows how the team is
doing strikes me as a very easy way to avoid that.

Heck, it can be significantly less than that, if you use a tool to keep your
tasks up to date and can just say "I got the frobulator finished, and moved on
to the doohickey. Dave's giving me a hand with a small holdup there, and it
should be finished on time." at the standup then the whole thing should take
less than five minutes total, except when there _are_ issues that need to be
dealt with.

~~~
mooreds
I think that standups are one of the best parts of Agile, if they are time
boxed and moderated well ('let's take this [larger issue] offline' should be
heard fairly often). Super easy to implement, and very helpful. I've only
worked with small teams (less than 8 folks), but I don't think it'd scale
well.

------
bitwize
Agile is like CrossFit: the techniques are sound, but the techniques really
aren't the point. The point is to create a revolution by wrapping sound
techniques in an us-vs.-the-world ideology that has strong emotional appeal.
This makes it easier to sell trainership certifications, which are where the
money is.

------
compbio
Agile done wrong destroys more than Agile done right can fix.

If you feel too good, or too senior for a programming methodology like Agile,
then you are bound to not like it. Is that a fault with Agile, or a fault with
your attitude?

A cowboy coder is not micro-managed, does not seem to need atomized tasks,
does not need a direct line with the customer and decides on the complexity of
the problem and the solution all on his own. They are also terrible to manage
and hit-and-miss when it comes to actually shipping something with business
value.

Bluntly spoken, Agile is there for the project managers, not the project
developers. Agile should be implemented for as long as productivity increases,
customer feedback loops create desirable features, and iteration cycles become
tighter and shorter. If you know a way to increase those stats without Agile,
then write your own methodology ([http://programming-
motherfucker.com/](http://programming-motherfucker.com/) is taken) and join
management. If you don't care about those stats, and feel too good/senior for
Agile, then start your own company and proof it to yourself. You don't start
to measure a project's success by first counting the number of developer
complaints. You could probably keep the complaints at zero, and never ship
anything of impact.

------
prostoalex
If you get stuck in an agile environment, here's a survival guide:

1) Attack the lowest-priority and easiest stories to shoot for quantity, not
for quality. This way you'll be closing stories in no time, pleasing the scrum
master and product owner during the daily standup. Leave the largest and most
complex problem for last - if nothing else, you can kick the can down the road
by claiming it's tougher than it seemed, requires more points and should be
moved into the next scrum.

2) Do not worry about the quality of your work. In fact, the lower it is, the
more stories you'll have to fill in the next scrum - "widget for feature X"
with some effort can become "fix bug Y with feature X", "improve widget
performance when more than 1 user uses the product", "improve logging and
monitoring of widget X" and tons of other, lower-priority, but higher-quantity
stories (see point 1 of this). You'll likely be closing a story a day, earning
points way ahead of the other suckers who choose to focus on long-term
critical design/architecture issues.

------
Delmania
Reading over his points make me think the OP is a PM who doesn't understand
Agile nor his role in it. The number of misconceptions he presents reads like
someone who has never bothered to research agile, but only knows what
consultants have taught him.

I think the number 1 misconception is the sprints. He seems focused on 2 weeks
as being the requirement, when it's on the recommendation. Some team have gone
as long as 4 weeks. The whole point to a sprint is that dedicated time to a
delivery with fast feedback from the customers. It's mainly so you can fail
early, ail often. It's much better to spend 2-4 weeks building the wrong
product than 6 months.

Second, his claims that product development, research and design, and
architecture don't belong in a sprint are also misinformed. The focus on user
stories to remind people that they need to focus on users, not gold plating.
In any technical project, there are a plethora to improve on the design.
People can (and have) sat down and refactored and "rearchitected" for days and
days. At the end, they build beautiful systems that don't offer any advantage
to the customers, or have implemented a number of features the customer didn't
want, or have fixed a series of concerns the customer wasn't concerned with.
There is give and take of course, as the engineers needs to give feedback to
help the customer understand the benefits of the feature or risks of not
fixing the issue, but those need to happen first before people go off and
construct digital masterpieces.

Third, micromanagement. If you have endless meetings in agile, you're
definitely not doing it right. The 3 big meetings, planning, retrospective,
and demo, are ones that take the most time. Standups take no more than 15
minutes. The other tasks, meaning, backlog grooming and prioritization should
not involved your sprint team. Those need to be done offline by the product
owner. Agile may be about teams, but you still need strong leadership.

The only point of his that has any relevance is the last one, where consultant
firms have made big bucks spinning out variations of agile because people just
can't understand how simple it is.

------
carsongross
Agile development is another tick in the long series of desperate attempts by
management to avoid The One Thing That Actually Usually Works™: Hire great
developers, pay them a ton of money and give them a lot of freedom and time.

~~~
tsotha
I don't see how this makes sense. If I hired a bunch of great developers at
great cost I would have even more incentive to maximize their output than I
would if I hired a bunch of mediocre people at a lower cost.

------
chillingeffect
An eager beaver at one of my client's is introducing Agile as a "Waterfall
silver bullet."

I see right away one Agile defect: It prefers near-term "user story success"
over long-term investments like creating debuggable architecture.

Why spend time now making things easier for the rest of the cycle if it's not
a priority in this iteration?

Why write "gdb" when "gcc with printfs" will work fine, even if it simply
requires more sprints?

~~~
dragonwriter
> I see right away one Agile defect: It prefers near-term "user story success"
> over long-term investments like creating debuggable architecture.

Neither the Agile Manifesto nor even the far more specific Scrum Guide even
_refers to_ user stories.

A particular _organization_ using Scrum may _decide_ that architecture-related
concerns are not important in the definition of "done" for items in their
product backlog, and focus only on "user story success", but, to the extent
that that's a problem, that's not a Scrum (and much less, Agile) problem, its
an organization problem.

Agile is about what _concerns_ you favor in figuring out how to get work done,
Scrum is about how a team gets work done and defines the work it is to do
within the framework provided by the wider organization, but the specific
definition of quality standards _for_ work is not directly addresses by
either.

> Why spend time now making things easier for the rest of the cycle if it's
> not a priority in this iteration?

Why wouldn't an organization have maintaining (or improving) the overall
architectural standards of the work a priority for every iteration -- in Scrum
terms, part of the Sprint Goal -- unless there is a conscious decision to take
on technical debt to meet some other goal? Agile, or even Scrum, doesn't tell
you what goals to set, and you shouldn't blame them for you choosing to set
the wrong goals.

------
fsloth
"Agile and Scrum, however, single out and humiliate anyone who works for 2
weeks and doesn't have something to show for it."

Holy crap, how wrong can some orgs go? The team should own the process. If
there is R&D that does not match with scrum then the team should have a) a r&d
framework or agreement in place b) the authority to say this is r&d.

The process does not own the team. The team owns the process.

------
phamilton
I always try to differentiate between Agile and agile. Agile (proper noun) is
the overly defined practice of scrums and points and backlog grooming etc.
agile is the practice of continuous iteration at all levels. Agile is a great
starting point, but if you aren't challenging the prescribed format and
iterating on your process itself then you are missing the point of agile.

We have found, for instance, that the 3 questions of standup are pretty
useless. They make each person feel like they are justifying their existence
at the company. By dropping those questions and framing it in terms of a
deliverable we found the meetings to be far more productive and better for
morale.

We've decided to give ourselves 1 day into the sprint to better guage progress
so we can define achievable sprint deliverables, as we don't often know enough
information during sprint planning.

Each of these is set up as an experiment, designed to solve an identified
problem with our workflow. And the results are great.

------
passive
I don't know how the author is doing Agile, but it doesn't match my
experience. I've implemented "Agile" processes on four different teams, and
while certain aspects were more successful than others in different contexts,
nothing was at all like what is described in the article.

For starters, a very significant part of the article relates to performance
anxiety over story points. Over 6 years of doing this, I've had two instances
where people were called out for not putting points on the board, both of
which came from outside managers not familiar with Agile.

Besides that, one of the core tenets of Agile is that you adjust the processes
to work for the people involved. Trying to enforce some arbitrary subset of
Agile processes on a team is a recipe for failure and frustration.

This reads to me like "bad managers are bad at managing Agile processes".

------
glenbo
Pretty spot on, I think.

The most problematic part of SCRUM (and the first thing to start killing
productivity) are the interminable meetings it facilitates. The SCRUM master
is constantly trying to gauge scope on this or that feature, and everyone
feels like they need to bring up what they've been working on during the
standup in order to feel like they're not appearing to be slacking off.

I've abandoned SCRUM in favor for a Kanban approach that puts the onus on the
Product Owner to manage and estimate scope and deadlines, thereby leaving us
developers alone to focus on our work.

I've written more about my approach here:
[https://medium.com/@glenelkins/agile-is-good-for-managers-
bu...](https://medium.com/@glenelkins/agile-is-good-for-managers-but-bad-for-
developers-73bcddac5fe)

~~~
cozuya
Its your prerogative of course but peppering your blog posts with stale meme
gif after gif is an easy way to get me to not read your content. I don't
understand this trend at all for talking about a professional concept. What
you did this weekend, sure, but this?

~~~
glenbo
Know your audience, I guess. I enjoy gifs, and enjoy getting a sense of the
author's personality when I read an article. I don't think I've ever bounced
from an interesting article because of a handful of cheerful gifs, but hey,
that's just me.

To each his/her own I say.

------
unwind
The title is completely mangled.

The original (rather long) title is "Why do some developers at strong
companies like Google consider Agile development to be nonsense?", and it
seems it was shortened. There's a spurious "at" left in there now which breaks
it.

~~~
jacquesm
This happens when people try to shorten their titles to fit 80 characters.

------
bbody
The thing that I don't understand about the way Agile development is treated
is that it is often treated like a silver bullet. As the article points out
agile has use cases where it is effective but many treat it as a "Waterfall
Killer".

------
dbg31415
So instead of Agile we should use, what?

Fully understand that process is a technology.

If Agile is so bad, what's better?

~~~
depr
I am interested in this as well. Who's using a different process?

~~~
kabdib
Why do you need a capital-P Process? Does it need to have a name?

Best teams I've been on have been self-organizing, with a few senior engineers
who did heavy-lifting and some less experienced engineers learning new stuff.
Management was minimal (the more we had, the more things sucked).

\- Minimize management. Minimize management. Minimize management. Management
exists to set very high level directions and to remove obstacles.

\- Make sure that different teams talk. A lot.

\- Get real. Don't blow smoke up people's asses. Making a schedule with a
granularity of a day on a six month project is fucking bullshit. Just stop it,
okay? You might be able to do this a week out, but not much more than that. If
that deadline is important, be clear on why. (I've been on projects that have
been absolutely killed because someone felt they had to ship on magic date X,
when shipping a few months later would have saved the product).

\- If you are working steady 60+ hour weeks, you are doing it wrong. If you
are doing regular 80+ hour weeks then you will burn out and leave.

\- It's done when it's done. Ship it, and iterate.

~~~
dbg31415
> It's done when it's done.

Ha. Ever have a client? "Dear Enterprise Customer, We'll get it done when it's
done. Cool? Can we have the gig?" Yeah no. That's not at all how the world
works.

We have process because we have deadlines, commitments, responsibilities...
and there needs to be an easy way for people to come and go inside of an
organization without having to invent the wheel each time.

------
ckrailo
Dave Thomas (one of the original agile signer peoples), gave this amazing talk
criticizing modern, commercialized agile instead of the developer-focused way
of "developing with agility".

Give it a watch: [http://www.thoughtworks.com/talks/the-death-of-
agile](http://www.thoughtworks.com/talks/the-death-of-agile)

Blog post version: [http://pragdave.me/blog/2014/03/04/time-to-kill-
agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

------
notacoward
I've seen many criticism of agile/scrum as they (don't) apply to long-term or
systems-software environments, but another disconnect I think people need to
know about is with open source. Here's the "upstream first" development model
typically used by Red Hat (my employer) and others.

(1) Company decides to devote resources to a feature.

(2) Developer writes code and submits patches _upstream_ (e.g. to the Linux
kernel).

(3) Upstream takes some indeterminate amount of time to get patches into a
release.

(4) Company defines a _downstream_ (i.e. commercial) release based on a
particular upstream release.

(5) The possibly-pristine but also possibly-unrecognizable code from (2) is
pulled from the upstream release into the downstream tree.

(6) More testing, debugging, tweaking, etc. on the downstream tree yields an
actual release.

Just in (3) we see one part of the problem: upstream quite likely isn't
agile/scrum themselves. Often they don't care about a particular vendors'
release schedules; if they do, then someone would argue they're "dump and run"
fake open source, and not a true independent upstream. They're almost
_certainly_ not going to give a crap about sprints or story points or anything
else about the local agile/scrum process. These methodologies pretty much
don't work unless everyone is completely committed, and with separate
upstream/downstream that's just not the case.

Even with everyone on board, the disconnect between (2) and (4) is a problem.
Pushing code upstream and pulling it downstream are two separate tasks, even
if they're done by the same person, and there's this big gap between them. At
best, this makes scheduling more complicated. More often, it makes agile/scrum
style fine-grain scheduling and tight coordination impossible. Measuring
"velocity" and all that isn't possible when there's so much externally imposed
variability.

For something that's long term _and_ systems-oriented _and_ open source, these
methodologies are practically useless. Actually they're worse than useless, as
they misdirect effort and interrupt useful work. YMMV.

~~~
davidgerard
And the hilarious (fsvo) thing there is that "agile" was an attempt to port
open source at its best to corporate development.

------
pan69
Any methodology in the wrong hands will be a terrible experience.

Let's face it. There is no methodology that will make all software development
projects around the world go smoothly and fun to work on. If you work with, or
for, a bunch of dicks, you won't enjoy what you will be doing all day. No
methodology is going to change that.

I would like to go as far to say that "any" methodology used by great people
will automatically result in great things.

------
chuckcode
Experienced engineers have seen a lot of "magic bullets" both on the process
side and the product side. Generally they turn out to not be a substitute for
hiring good people and getting good leaders to define a quality product and
focus the team on what is important both short and long term.

~~~
davidgerard
+1. Attempts to Taylorise clue shall forever be with us.

------
fsloth
If scrum metrics are used to identify low performers then that's so bad it's
not even wrong. The whole point of agile estimates is to teach the team to
estimate and pay attention to it. It's a learning tool for the team.

------
dragonwriter
First off, Agile isn't a software development methodology, its a set of
principles for an organization to apply in selecting/developing in its own
software development methodology (you could call it a software development
metamethodology.) Scrum is more of a methodology (and, while it may have
emerged from the people involved applying Agile principles in the context in
which Scrum was developed, and has features designed to support use in an
organization applying Agile principles, there is nothing _fundamentally_ Agile
about Scrum -- or any other development methodology; if some decisionmaker is
sold on Scrum by some consultants and adopts it as a top down practice, that
organization may be doing Scrum, but they aren't doing Agile -- in fact, they
are doing exactly the thing that Agile is a reaction _against_.) Almost any
time someone uses the phrase "Agile/Scrum" they either mean Scrum or something
that is neither Agile nor Scrum. In this case, the criticism seems to be of
something that is neither Agile nor Scrum, though it may be _related_ to the
latter (but not at all the former.)

As to the specific points:

1\. Here, the claim is: _There is no place for an actual senior engineer on a
Scrum team. The only way to move up is to become a "Scrum Master", a bullshit
management role that involves responsibility without power._

There are several errors in this description: First, "Scrum Master" isn't
management role, its a facilitation role focusing on expertise with making
Scrum work in the particular organization. The only quasi-management role on
(or related to) a Scrum team defined in the Scrum Guide [0] is the Product
Owner (which does have authority to go with that responsibility.) Either of
those is a role a team member could develop into; the idea that the SM role is
the only "way up" on a Scrum team is incorrect even within the narrow bounds
that are defined by Scrum.

OTOH, Scrum itself _intentionally_ \-- to support its use in organizations
using Agile practices -- defines only a narrow slice of practice,
particularly, a basic model for operation of individual development teams. It
does not prevent having different roles _outside of the defined interactions
within the Scrum guide_ for members of different seniorities or specialties,
it only requires that _for the purposes of the interactions it defines_ , only
a narrow set of roles ("Team Member", "Product Owner", "Scrum Master") matter.
So, consistent with Scrum, there can be room for moving up on a team. And real
organizations using Scrum on projects greater than a single 3-9 member team
use complementary practices like the Scrum of Scrums [1]; being a Scrum team's
representative on the Scrum of Scrums and thus playing a larger role in the
coordination of the overall work of the project is one way for a technical
contributor on a Scrum team to move into a role with broader scope and
exposure.

2\. Here, the claim is "It's aggressively short-term, by design" and "if you
carry this way of working on for months or years, you get a lot of technical
debt and you get low morale."

It is certainly the case that Scrum, specifically, largely addresses tactical-
level, short-term processes. This is because Scrum _isn 't_ a full-stack
methodology, its a narrow set of practices designed to adopted as part of a
larger set in an organization working in an Agile manner, and to be relatively
neutral to the other practices. Certainly, if you apply Scrum _alone_ with no
higher-level strategic processes that set standards that constrain the
definitions of "done" for work done in sprints to avoid technical debt, there
is a lot of potential for an organization applying _only_ what is in the Scrum
guide to lack long-term focus and development technical debt.

3\. The claim here is "It has no regard for the programmers' career needs or
desires."

 _Agile_ , as a set of principles, certainly does; Scrum, as a particular set
of practices, does not, for much the same reason addressed in the previous
point. Largely, though, this seems to be a restatement or alleged further
consequence of the first complaint about lack of a way to move up (it
essentially seems to be, "because of #1, Scrum leaves me nothing interesting
to put on my resume"), and so the response to the first complaint above
largely addresses it.

4\. There's a lot here that deserves separate responses, so I'm going to break
this one up.

> "It's micromanagement."

No, Scrum is the _opposite_ of micromanagement, since the "management" is done
almost entirely by the team.

> "User stories and backlog grooming are there to control what the engineer
> works on."

Sure, those things exist to define work, but they are done by the team, so can
hardly be viewed as micromanagement of the team.

> "The absurdly frequent meetings (and so many different kinds of status
> meetings!) are to intimidate him into not slacking."

Scrum defines four kinds of meetings: the Sprint Planning meeting, the Daily
Scrum, the Sprint Retrospective, and the Sprint Review. Of them, the Sprint
Review is the closest thing to a "status meeting", though even their the focus
is demonstrating the concrete deliverables for the Sprint rather than status
reporting. All of the rest are primarily _action /planning_ meetings. "Status"
of a sort plays a role in those meetings as an input to the planning aspect,
but if they become status-focused meetings rather than planning-focused,
you've definitely lost the defined purpose of the meetings in the Scrum guide.

> "The story points are there to track productivity (in some superficial,
> inaccurate way)."

Story points (in methodologies where they are used; they aren't part of Scrum)
exist as a planning tool for the team, not a productivity measure.

5\. The claim here is "At identifying low performers, it has an unacceptably
high false-positive rate."

Scrum (and, _a fortiori_ , Agile) is not a process for identifying low
performers, or for performance evaluation at all -- its completely out of
scope. Its not that it is good or bad at it, it doesn't even _address_ the
issue.

6\. The claim here is "It punishes R&D, and it hurts the best engineers the
most" because "Agile and Scrum [...] single out and humiliate anyone who works
for 2 weeks and doesn't have something to show for it."

Research is a separate domain than product development, and there is no reason
that the use of Scrum as a product development methodology should have any
impact on how research is done. Of course, Scrum is a generic enough process
that you _could_ use it to manage research efforts as well, but the backlog
items, associated definition of "done" for those items, sprint length, etc.,
would all likely be very different for a research effort than a product
development effort. You could mix research items into the backlog of a team
also doing product development, but then you probably have a problem defining
work items that are appropriate for the product development sprint length.
(This is less of a problem for non-Scrum methods that use a flow method for
backlog management rather than a timeboxed Sprint cycle, because then its
easier to mix items that have a longer-than-usual time involvement into the
same backlog; the sprints used in Scrum place an effective upper bound on the
size of work items.)

7\. The complaint here is "I have actually seen it kill companies" backed by a
single non-specific anecdote and the assertion that it generalizes. From the
description, this appears to be a top-down all-at-once conversion to a new
defined methodology. If one has processes in place, for the same reason one
adopts incremental change to a software system where you've got an existing,
functional system unless there is some reason you _can 't_ do incremenetal
change, the same thing should be done to a software development organization.
Failure of an organization (or many organizations) to manage a big-bang change
rather than incremental change doesn't invalidate the methodology they sought
to change _to_ any more than failure of an organization to manage a big-bang
software system replacement invalidates the technology they sought to change
to.

[0] [http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-
US...](http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf)

[1]
[https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrec...](https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrecting-
the-Much-Maligned-Scrum-of-Scrums)

------
cmdkeen
To go through some of the points I fundamentally disagree with: "There is no
place for an actual senior engineer on a Scrum team" \- There absolutely is,
who is peer reviewing the code, working with the BAs to design the
architecture, identifying the technical dependencies in the backlog? Scrum is
not a methodology for writing code, it is for getting a series of tasks done.
All the things a senior dev needs to do on top of code can be broken into
tasks, Scrum adds a weekly "is this still the most important set of things to
be doing?" meeting into the mix.

"It's aggressively short-term, by design" \- The whole post talks about 6 week
projects. Scrum is terrible for that as it imposes far too many meetings.
Scrum works for the complex space where you say "12-36 months" as your gut
feel estimate. It is a reaction to the waterfall world where you'd discover 2
years in you weren't building what the business wanted.

"It has no regard for the programmers' career needs or desires" \- Stories
make for excellent opportunities for juniors to "own" bits of work from
initiation to completion. Old school projects provided very little opportunity
for juniors to work on requirements gathering and thus a big chicken and egg
problem for promotion. It also offers plenty of opportunity to interact with
your customers, which is almost always a good way to get promoted.

"The story points are there to track productivity" \- Oh noes the people
paying you want to know how long the project is going to take to be done. The
talk of many status meetings seems decidedly anti-Scrum and is an excellent
example of the sort of thing that people should be screaming about in
retrospectives.

"It punishes R&D" \- Ironically it can be a really useful opportunity to
conduct R&D. Scrum makes you have something measurable and a time frame in
which to conduct it, which makes for an easier sell than an open ended
request. I think what annoys some is when they get shut down too quickly, or
are forced into taking a less technically interesting approach that delivers
enough business value. Scrum isn't there for pure research into the
theoretical, but then no-one is claiming it is.

Killing businesses - Much like every tabloid headline everything can kill you.
Value destroying mergers exist in abundance, and poor leadership/management is
a real killer. Plenty of companies do very well out of Scrum, especially when
they are in a cost centre environment.

I might sound rather "no true Scotsman" when it comes to Scrum but there are
only a few things you need to do to be "doing Scrum". What it does give you is
a powerful question to ask, and a regularly mechanism to raise it via the
retrospective - "why are we doing X when it isn't in Scrum?".

~~~
jackmaney
> Scrum is not a methodology for writing code, it is for getting a series of
> tasks done.

0_0 Y...you didn't just write that, right? I'll be unusually charitable and
give you a chance to think again about that sentence up there.

> "The story points are there to track productivity" \- Oh noes the people
> paying you want to know how long the project is going to take to be done.

And yet, points aren't supposed to be translated to time intervals.....
(Spoilers: in practice, they are.)

~~~
cmdkeen
What is wrong with that sentence? TFA focuses far too much on the coding
aspects of Scrum by asking "what does the senior dev do?", my point is all the
things a senior dev does are fit to be tasks or stories in Scrum. It's
outgrown being developer focused, and even more literally writing code is a
small subset of "software development".

Points don't have to track time intervals to give you a sense of progress.
Averages are a powerful thing, hopefully management is focused on long term
graphs not getting het up about the number of hours difference between your
tasks for two similarly pointed stories.

Oh and Scrum makes no requirement re using story points - it only requires
that backlog items be estimated. We estimate tasks in hours and stories in
points for instance, Scrum doesn't care. All our Product Owner shows to the
stakeholders is a burnup with just numbers on the x axis.

~~~
jackmaney
> What is wrong with that sentence?

So, writing code has nothing to do with getting a task (of ANY KIND, mind you)
done?

Again, do you want to take a moment and rethink that?

