
Coconut Headphones: Why Agile Has Failed - jackhammer2022
http://mikehadlow.blogspot.co.uk/2014/03/coconut-headphones-why-agile-has-failed.html
======
hpaavola
All these late "agile has failed" posts are out of touch with reality. They
assume that it is always possible to get the best developers and best managers
to work with the problem on hand.

I'm a consultant. Officially my title is Senior Test Engineer and usually my
job is to go to a company where shit has already hit the fan or will hit in a
short time.

The reality is that the company has a bunch of developers who are mediocre at
best (and maybe one or two good ones) and managers who do not understand the
situation. And of course the budget is already been eaten.

They want to ship their product and make some money with that so they can
continue to live their life. If I go there and say hey, you need better
developers, more rapid prototyping and managers who are technical enough,
nothing will change. Nothing will change because there aren't "rock star"
developers avaialble, there isn't time to find new managers and definetly no
motivation to change everything right now.

Sure in some sense I might be correct to say so, but my goal is not to show my
superiority, but to improve the situation.

But if I teach them a little Scrum, help them setup some CI and so on, they
almost always perform better.

And then this statement "Because creating good software is so much about
technical decisions and so little about management process, I believe that
there is very little place for non-technical managers in any software
development organisation."

No. Good software comes from understanding the needs of your customers and
meetings those needs. Shitty developers have and will create awesome products
just because they know what the users want and need. "Agile" helps even the
shitties companies to meet the needs of their customers.

~~~
mattmanser
I've read your comments a couple of times and still can't really see what
you've added.

You're talking about very abnormal situations. Companies that are so
technically incompetent they have to hire you.

And then saying that we should listen because in your abnormal experience of
dealing with teams so dysfunctional they can't even ship _bad_ software that
agile at least gets them going a little bit.

I suspect almost any change would get them going a little bit as the change
itself is the trigger.

EDIT: The more I think about it, the more your comment reminds me of the
people defending the other fads of years gone past. Workflow diagrams, OOP-
design (as a be-all-and-end-all process), UML, Worflow Engines, RAD tools.
Your comment reminds me of the defences of them. These things worked because
those desperate teams need a light to guide them, not because of the tool
itself.

And with each of those tools, it turned out the tool itself is mainly counter-
productive to functional teams. I think we're realising Agile is another of
those false prophets.

~~~
hpaavola
The thing is that following situation is really common:

Company has an average team, maybe even bit worse + 1 good person. The
managers are not that great either. Everything is average.

The team has been doing something, nobody really knows what, nobody really
knows at what pace. Nobody knows what they should be doing.

Occasionally the company releases something which sells a bit and customers
give some feedback. Mostly not that great.

When you tech them a bit of Scrum, help them get builds every night and help
managers to try out the product once in a while (remeber, not all software is
a website, some are airport weather observation systems). And help the company
to get some of their customers to try out the software once in a while even
though it is not "ready".

Suddenly the results of the team is visible to interest groups and interest
groups needs are visible to developers, managers can get some idea of the
velocity and everybody can have a better idea where we are, where we should go
and when we might get there. Then iterate and improve.

What we have done here is that we improved the quality of the company with
really little cost with our existing talent pool.

Yes, this is really common.

~~~
ahomescu1
> Company has an average team, maybe even bit worse + 1 good person. The
> managers are not that great either. Everything is average.

I think the application of the OP here is "fire the bad/mediocre managers, put
that 1 good tech person in charge". Couldn't they do that?

------
wpietri
As somebody who has been involved in the Agile movement since before the term
existed (I was using Extreme Programming in 2000 or 2001), I agree 100% with
this.

I definitely think the consultants get a good chunk of the blame. But as I
explain in detail elsewhere [1], I think that happened because executives, the
consultants' customers, were mainly interested in buying BS. Not consciously,
but when they were offered a choice between hard Agile and easy Agile, they
bought easy Agile.

It's sad, because in the 2001-2005 timeframe, there were a lot of great people
doing a lot of great stuff. There are still some doing great stuff today. But
yeah, among most of the people I talk to that are "doing Agile" (as if there
were such a thing), Agile is just putting new labels on the same old power
dynamics.

And it's those power dynamics that are the problem, and no matter what methods
you supposedly adopt, unless you change those, the system will return to
making powerful executives and managers feel safe and in control. At the
expense of productivity, quality, value delivery, and a whole lot else.

[1] [http://agilefocus.com/2011/02/21/agiles-second-chasm-and-
how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-
in/)

~~~
jdlshore
This. So much this.

I got involved with Extreme Programming in 2000. Loved it. Best thing since
sliced bread, yadda yadda. I was completely spoiled for other kinds of work.

So when that contract ended, I went looking for other opportunities to do XP.
But guess what? In 2001, there weren't any. So I started teaching people how
to do it. Bam! I'm a consultant.

Several lean years later (I don't mean Lean, I mean ramen), I'm figuring out
this consulting thing. I've got a network, I've got a business entity, people
actually call me, and oh, oh, and I make a real damn difference.

Then Agile starts getting really popular. Certification starts picking up.
Scrum's the new hotness, XP's too "unrealistic." I start noticing some of my
friends in the biz are dropping out, going back to start companies or lead
teams or something _real_. But I stick with it. I'm thinking, "Sure, there's
some bottom feeders creeping in, but Agile's still based on a core of people
who really care about doing good work. Besides, if we all leave, what will
keep Agile on track?"

It gets worse. Now I'm noticing that there are certain clients that simply
won't be successful. I can tell in a phone screen. And it's not Scrum's fault,
or certification, or anything. It's the clients. They want easy. I start
getting picky, turning them down, refusing to do lucrative but ineffective
short-term training.

Beck writes _XP Explained 2nd edition_. People talk about Agile "crossing the
chasm." I start working on the 2nd edition _XP Pocket Guide_ with chromatic
and it turns into _The Art of Agile Development_. We try to write it for the
early majority—the pragmatics, not the innovators and early adopters that were
originally attracted to Agile and are now moving on to other things. It's a
big success, still is.

It gets worse. The slapdash implementations of Agile now outnumber the good
ones by a huge margin. You can find two-day Scrum training everywhere.
Everybody wants to get in on the certification money train. Why? Clients won't
send people to anything else. The remaining idealists are either fleeing,
founding new brands ("Software Craftsmanship"), or becoming Certified Scrum
Trainers.

I write "The Decline and Fall of Agile" [1]. Martin Fowler writes "Flaccid
Scrum" [2]. I write "Stumbling through Mediocrity" [3]. At conferences, we
early adopters console each other by saying, "The name 'Agile' will go away,
but that's just because practices like TDD will just be 'the way you do
software.'" I start looking very seriously for other opportunities.

That was six years ago.

...

Believe it or not, things haven't really gotten worse since then. Actually,
they've gotten a bit better. See, 2-5 years is about how long a not-really-
Agile Agile team can survive before before things shudder to a complete halt.
But not-quite-Agile was Actually. So. Much. Better. (I know! Who could believe
it?) than what these terribly dysfunctional organizations were doing before
that they're interested in making Agile work. So they're _finally_ investing
in learning how to do Agile well. Those shallow training sessions and
certifications I decried? They opened the door.

And so here we are, 2014. I see these "Agile is dying" threads as a good
thing. Because they mean that the word is getting out about Agile-in-name-
only. Because every time this comes up, you have a horde of people saying
"Yeah! Agile sucks!" But... BUT... there's also a few people who say, "No, you
don't understand, I've seen Agile work, and it was _glorious_." That's
amazing. Truly. I've come to believe that no movement survives contact with
the masses. After 20 years, to still have people who _get it_? Who are
benefiting? Whose lives are being changed?

That means we have a shot.

And as for me... I found that opportunity, so I get to be even more picky
about where I consult. But I continue to fight the good fight. Diana Larsen
and I have produced Agile Fluency [4], a way of understanding and talking
about the investments needed. We've released it, permissive license, for
everyone to use. Use it.

Because Agile has no definition, just a manifesto. It is what the community
says it is. It always has been. Speak up.

[1] [http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-
Agile...](http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html)

[2]
[http://martinfowler.com/bliki/FlaccidScrum.html](http://martinfowler.com/bliki/FlaccidScrum.html)

[3] [http://www.jamesshore.com/Blog/Stumbling-Through-
Mediocrity....](http://www.jamesshore.com/Blog/Stumbling-Through-
Mediocrity.html)

[4] [http://www.agilefluency.com](http://www.agilefluency.com)

~~~
mikevm
So for someone that wants to study the non-watered down management version of
"Agile", which books would you recommend?

And just out of curiosity, are there any popular Agile books that you would
not recommend?

~~~
jdlshore
I'm fond of, um, mine. :-D [http://www.jamesshore.com/Agile-
Book/](http://www.jamesshore.com/Agile-Book/)

It has a section in the front that describes which pieces to read depending on
which role you're in.

~~~
joshyeager
I second this. My team is about 18 months into our transition to agile, and it
is a tough road. This book has been an _excellent_ resource.

The one gap is that it mostly focuses on greenfield projects. It does a good
job of highlighting the parts where legacy systems will make agile more
difficult, and I understand that spending more time on that would have made
the book harder to understand. But we've had to do a lot of learning on our
own to try to fill in those gaps for ourselves. With that said, this book does
the best job of addressing legacy projects of any that I've read.

If anyone has any recommendations for resources on using agile in legacy
systems, I'd love to hear them.

~~~
jdlshore
I'll repeat bcobb's recommendation for _Working Effectively with Legacy Code_.
It's the bible.

In my Let's Code JavaScript screencast, I've recently started a three-part
special on legacy JavaScript code. It follows my efforts to "do it live" with
actual legacy code someone else wrote. You might find it useful. (Full
disclosure: subscription required, and parts II and III don't come out until
April 4th and May 2nd.)
[http://www.letscodejavascript.com/v3/episodes/lab/6](http://www.letscodejavascript.com/v3/episodes/lab/6)

 _Edit:_ I just realized that you already said you're using Feathers' book,
and that the challenge isn't technical, it's planning and communication. Let
me try again:

Part of that is just "the way it is." At the risk of sounding snarky, I
imagine you _could_ plan fairly effectively ("we have huge error bars because
our velocity is unpredictable, so given backlog X, we're confident we'll be
done sometime within 3-12 months"). See the "Risk Management" and "Slack"
sections of AoAD for that.

I also imagine you could communicate that fairly easily ("given our three
month estimate, we think we have a 50/50 shot of being done in six months and
we're almost certain of being done in less than 12").

For many teams I work with, the problem isn't planning or communication, the
problem is that reality isn't conforming to stakeholders' wishes. _And there
's no way to make it conform._ (Short of kicking the problem down the road by
accumulating more debt while you search for a new job.)

So how do you break the news?

One way is to, um, not. At this point, stakeholders are used to delays and
bugs. The status quo ("we'll pretend to follow your schedule, and you'll
pretend to believe us") can be comforting. It might be useful to stick with
that.

Another way is to ramp up the frequency of delivery so much that the error
bars are less noticeable. An estimate to deliver in 3-12 business days is less
painful than an estimate of 3-12 months.

A third option is to negotiate for scope rather than schedule. "We'll
absolutely deliver in three months. It might be tiny. That's because of
technical debt." (I'm less fond of this approach than I used to be.
Negotiating scope makes stakeholders profoundly uncomfortable in a way that
slipping dates doesn't, for some reason. Perhaps because they see it as an
attempt to weasel out of producing anything.)

Another approach is to stop estimating entirely. "We're working on Feature X
and we'll tell you when it's done."

There's also simply explaining the situation: the cynical approach ("we have a
ton of technical debt because of the decisions _your predecessor_ made, isn't
it great you're here now") or the enlightened approach ("we've got a technical
debt problem, it has effects W, T, and F; we're addressing it with P, D, and
Q; you can expect consequences O, M, G; we're preventing it from happening
again with techniques S, L, A, C, and K.").

I'll typically use some combination of the above depending on the audience.

(I'm in a weird mood. Sorry if this came across as uncaring. The ideas are
serious even if the tone is not.)

~~~
joshyeager
Thanks for the detailed reply! I understood your intent, don't worry about the
tone.

We're a small enough team that we all understand the business drivers. The
main goal of our agile transition is to improve predictability and clarity.
Month-wide error bars on a three-month release don't help those goals much.

Right now we're working to shorten our release cycle and learn how to
communicate clearly even when it hurts, on the assumption that shining light
on the difficulties will help us find and solve the problems as quickly as
possible. But it's definitely a painful transition.

One more point: I agree that negotiating scope with a fixed schedule is
difficult. We have done that occasionally. But sales and business people are
definitely more willing to accept schedule slippage than scope reduction.

------
datawander
The demotivation poster (we'll ask for estimates, but then treat them as
deadlines) really strikes a chord because that is one of my major 'gripes'
with the agile planning process. Particularly when a manager is heavily
involved in that process. It may be no coincidence that the best projects I
have been on are the ones where the manager deliberately stepped out of the
room or was not a part of those phases of the planning process.

Agile is part of a more disturbing trend I've noticed [0] of companies
striving very hard to turn software into a literal sausage-making factory [1]
and to make software engineers just another cog in the machine or a
replaceable part to fatten the bottom line with a lower salary. This is
provably the aim of some of the top companies given news on no-hire
agreements. [10].

[0] with Java being the favored "currency" of programming languages being the
other disturbing trend-- it's much easier to replace a Java programmer than
any other for a reason

[1] you know what they say about how sausages are made

[10] [http://gizmodo.com/apple-guilty-of-price-
fixing-730018979](http://gizmodo.com/apple-guilty-of-price-fixing-730018979)

~~~
wpietri
Yeah. 100% agreed.

In some ways I don't blame people. Industrial approaches to organizing people
provided a major leap forward for humankind. And they work well with primate
power dynamics; modern corporate structures are basically feudalism in suits.
It's natural that people would just want to take the top-down, command-and-
control structures and replicate them in the new thing they're doing.

But they just don't work well. They don't even work well for industry anymore;
there's a reason that Toyota, which has a very different management
philosophy, wiped the floor with the US auto companies, which stayed stuck in
the early 20th century.

To be fair, Agile started out to be 100% the opposite of that sausage-factory
approach. I know a lot of the early players, and they sincerely had a very
different vision. It makes me sad to see their work used as just another stick
to beat developers. Meet the new boss, same as the old boss.

------
programminggeek
This recent meme about agile is so dumb that I feel like I shouldn't say
anything at all, but here goes anyway. I'll keep this as short as possible...

Agile works fine for teams that embrace it. It's going to work totally
different from team to team. The real point is to find the process that works
best for your team to deliver software that meets the customer requirements
and budget. Agile for a team of 1 or 3 is not the same as agile for a team of
10 or 100.

Agile tends to fail in two places and they are both communication related.
First, developers give terrible estimates because of pride. They don't think
through the problem, they don't consider complexity, and they want to look
awesome so they ALWAYS over promise and under deliver. That makes them look
bad and destroys confidence in the project because it's dishonest.

Second, managers will take estimates and turn them into deadlines because that
is kind of their job and they are doing the best they can with the bad
information that developers give them (see bad estimates above). A good PM
needs to really push their team for real esteems. Poor estimates lead to poor
communication because when things go badly, nobody wants to send up the signal
flare for help or tell the boss that the project is not going to hit the
deadline. This is often compounded when the client decides to firedrill a
feature or bug fix mid sprint, and the manager doesn't push back and say that
it is going to push everything else back.

The best estimates are the ones that are the most honest, not the shortest.

Between the bad estimates and the poor communication that comes out of it,
there are plenty of times that "Agile" goes wrong, but it's not agile's fault.
It's your fault. It's your team's fault. It doesn't work if you aren't willing
to continuously tweak and reevaluate the process until it fits your situation.
That means doing retrospectives and making improvements based on them.

Continuous improvement makes agile work. A stagnant process is doomed to
failure as requirements and resources change over time.

~~~
vonmoltke
I think you are missing a couple, somewhat related failure modes.

First, if the software project is part of a larger integrated
hardware/software project, people above the project manager may be making
promises of deliverables without consulting the program manager at all, thus
creating externally-imposed deadlines that cannot be changed without rippling
through to other teams, who may or may not be in your own company. Of course,
the same upper management that pulled deadlines out of their asses is
reassuring the customer and other teams that they are Agile, so this won't be
a problem.

Second, you have a stubborn customer who wants deliverable deadlines, holds
you to them, and views your Agile-based explanations as "excuses". The US
federal government is notorious for this.

~~~
bunderbunder
Disclaimer: I've only recently decided to Stop Worrying and Love the Scrum, so
my perspective on the subject may still be heretical.

That said: I think these are not failure modes that can be laid at Agile's
feet. They represent a situation that Agile quite explicitly does not even
attempt to fix. A key part of the (for lack of a better word) Zen of Agile is
that on anything above the smallest of scales, it's impossible to promise both
a feature set and a due date.

To an approximation, that's what the whole sprinting thing is all about. It's
breaking things down into bite-size pieces that are small and simple enough
that you can hit milestones on deadlines with something approaching
regularity. But on top of that you've got the overall development arc, and on
that scale there are (or should be) no promises made about what's going to be
happening on any sprint past the current one. The point of this is to buy the
product team flexibility: Either the flexibility to adjust the requirements in
response to new information that's discovered during the product lifecycle, or
the flexibility to adjust the number of sprints that will be needed to achieve
a given feature set in response to new information that's discovered during
the product lifecycle.

In short, this is a feature of Agile not a bug. It's nothing more than being
realistic about an immutable law of the universe: The more rigid you need to
be about deadlines the less rigid you can be about requirements, and vice
versa. Product teams have a professional responsibility to be honest about
this fact. Customers and managers who aren't comfortable with it are free to
restore their sense of certainty by building ample buffer space into the
schedule.

~~~
vonmoltke
If that is the case, then Agile just does not work for large, integrated
engineering projects. You must make attempts at locking both feature sets and
due dates because the progress of teams is interdependent and the flexibility
each team has is highly variable. At some level of granularity there must be
an established schedule that other teams can plan to. Its a basic part of
systems engineering.

This is not to say these structures should be inflexible. There needs to be
some flexibility in requirements and dates, and it is the responsibility of
the program manager and systems engineer to make sure the project can bend
without breaking. There must be limits on it, though, or the project will tear
itself apart.

~~~
bunderbunder
Right. . . hence the sentence on the end about needing to use buffer space to
handle the things that Agile never promised it could handle in the first
place.

I'd point out that the same problem exists for every other software
development methodology I've ever tried. The difference is that when they do
slip deadlines, it tends to be a whole lot more surprising (and therefore
damaging to the schedules of other teams) because their feedback mechanisms
tend to result in poorer-quality progress tracking.

~~~
vonmoltke
> Right. . . hence the sentence on the end about needing to use buffer space
> to handle the things that Agile never promised it could handle in the first
> place.

A schedule can only have so much pad. My assertion is that Agile is useless to
these projects because it can't handle these things.

> I'd point out that the same problem exists for every other software
> development methodology I've ever tried. The difference is that when they do
> slip deadlines, it tends to be a whole lot more surprising (and therefore
> damaging to the schedules of other teams) because their feedback mechanisms
> tend to result in poorer-quality progress tracking.

Every project management methodology has these problems, because at some level
these problems are political. No methodology is going to overcome that, though
some are better than others at dealing with it. The poster I first replied to
said, _Agile works fine for teams that embrace it._ I'm saying such is not the
case if you are working in an integrated or "team of teams" environment or if
you have an unreasonable customer. Those may not be very common in the pure
commercial software world, but they are in the rest of the world that software
is trying to eat.

------
eliasdelatorre
I'm stuck trying to finish a project as a vendor. The original team in charge
of selling the project has put a guy as Project Manager that takes pride
everytime he says: "As you know, I'm not a technical guy" just before
explaining something completely wrong from the technical standpoint, or
agreeing into something that can't be delivered as explained. I can't agree
more on the quote that says "Please don’t put non-technical managers in charge
of software developers." I just hope finishing this without a lose, and
getting a better position for the following projects.

~~~
wpietri
I think the problem isn't with who you put in charge. I think the problem is
the notion of "in charge".

One of the best things for me about teams that were working well is that
everybody was in charge. Everybody felt responsible for the outcome. Everybody
cared. Everybody knew they could make things happen, and that differences of
view were resolved through collaboration and experimentation, not power.

You can see that explicitly in the structure of Extreme Programming, a major
Agile process. There were developers and there was a product manager (called
"customer"), and neither controlled the other. Indeed, people created an XP
bill of rights that described the balance of powers:

[http://agile.dzone.com/articles/worth-repeating-xp-
bills](http://agile.dzone.com/articles/worth-repeating-xp-bills)

You can see that working in the large at places like Spotify, where teams are
cross-functional. People do have managers, but they aren't on the same team,
and technical people report to technical managers, not generic businesspeople.
Those managers aren't "in charge" in the typical sense. They mentor and
support the people working directly on teams. They only really manage when
things go wrong.

And I think that's what the Agile community was going for early on. It's a
shame that fell by the wayside.

~~~
watwut
I had very bad experience with "everybody in charge". We oscillated between
nobody makes decisions and war for power and decision making. The project was
simultaneously pulled in multiple directions and there was no such thing as
shared priorities. Every team member had his own.

It got hell when the company hired very smart and capable guy who turned out
to be very lazy. Nobody is in charge in that case means also that it takes too
long time until someone in charge finds out about the situation.

~~~
wpietri
Sure. You can fail either way, and neither is fun.

For a team-oriented approach to work, you really need a team. A team is a
group of people that has different skills but the same goal. They're a group
of people that win or lose together. They have to have the same purpose, or it
won't hold together. If every team member had different priorities, then
something was badly screwed up about how the team was managed.

In the case of the smart but lazy guy, that's where external-to-the-team
management structures come into play. E.g., if you're using a management
structure like spotify, the lazy guy's manager should have noticed issues
during their weekly one-on-ones. If not, other team members would be talking
to managers about the deadweight.

------
abalone
He just vaguely blames everything on "non-technical management" without really
offering a cogent argument why.

When he does get to concrete points, one of them is "Short feedback loops to
measurable outcomes create good software." And yet "two week iterations" he
calls "agile nonsense".

The overal tone is kind of "technical macho" to me.. like, Real Developers
don't need management and if you slipped then it's because your programmers
suck and you should just hire better ones.

~~~
SixSigma
It would also suggest that someone who isn't a qualified doctor couldn't run a
hospital. I continually run up against this attitude that programmers are
somehow special and the rules of management somehow don't work with them.

The sentence should read "The core problem is that bad managers will usually
fail, or at best be counter productive, whatever the methodology".

------
asdkl234890
I worked for a large corporation which used a hard core water fall method to
produce software. And yet it called it Agile. Why? Because why not.

~~~
collyw
I have noticed this. Every one claims to be doing agile, even though they pick
and choose the parts they decide are "agile".

I just continue to write software the way I always have. Kind of disciplined
version of cowboy coding I would say. Sometimes I have design documents - when
I feel it helps. Other times the problem might be less clear, built a
prototype, and iterate from there. It really depends on the problem you are
trying to solve and the time frame you need to do it in.

I get software working, usually in a decent time frame. Is that not what agile
is supposed to be about?

------
carsongross
To the extent that I've seen development methodologies work, they appear to
mostly fix organizational barriers that get in the way of The One Thing That
Actually Works[1]: hire a small group of extremely talented developers and
product designers and then let them work.

[1] Assuming your codebase isn't already a monstrosity. If it is... well, then
nothing works.

~~~
joshyeager
How big is a "small group", in your opinion?

~~~
carsongross
10 or fewer people.

------
adorton
A "people manager" should never be put in charge of project or schedule
management. It creates a conflict of interest between the realities of the
project, and the outside pressure the manager may receive from other teams.

That's why, at least with Scrum, the agile manager, if he or she is part of
the same team, reports to the same manager as the development team. The agile
manager's job is to keep the agile process running smoothly, removing
impediments, etc.

------
jayvanguard
Has it really failed? It seems like at least some of the principles of agile
are just a given now. 10-15 years ago that wasn't the case. People actually
believed in waterfall.

Of course many individual teams fail at agile but those teams would probably
fail no matter what approach they were using.

~~~
wpietri
It's a good question. But personally, I think that people would have stopped
believing in waterfall approaches anyhow. Anybody sticking with 18-month
release cycles today would seem like an idiot whether or not anybody had heard
of Agile. And really, what a lot of supposed Agile teams are doing is really
mini-waterfall: all the ceremony, shorter cycles, but just as much horseshit
and self-delusion.

~~~
collyw
I got taught waterfall at university. Nowhere did it specify 18 month release
cycles, just iterations, and going "back up the waterfall" if need be (critics
of waterfall never seem to acknowledge that you can go back the way). To be
honest I don't see how it actually differs from agile that much. Just less
emphasis on documents up front.

~~~
zb
The process you're describing is the Spiral Model, not the Waterfall. The
major innovation of the Spiral Model was that you acknowledged that you would
need to iterate - in the Waterfall days that was considered something to be
embarrassed about.

The major innovation of Agile was that you acknowledged that the various steps
of the Waterfall/Spiral happen _at the same time_ \- in the Spiral days, that
was considered something to be embarrassed about.

I don't doubt, by the way, that you were taught that the Spiral Model was
called Waterfall. But you should be aware that this was a case of historical
revisionism on the part of whomever taught you.

~~~
collyw
It was a while ago, but I remember spiral being taught with a big spiral
diagram - looked kind of like a snail shell. And waterfall had arrows that
could go back up the way if needed.

I also remember being taught that errors caught after the software had been
implemented was 100% more costly to fix than errors at the design stage - I
think that was the idea behind big(ger) design up front.

[https://sites.google.com/site/ucscsadg12/system-
domain](https://sites.google.com/site/ucscsadg12/system-domain)

~~~
wpietri
That "errors are more costly later" notion is true for waterfall, but not for,
say, Extreme Programming.

It is basically true for waterfall because the feedback loops are broken.
Think cooking, for example: if I cook all my meals for a year at once and put
them in the freezer, I'll have to do a lot of research and planning.
Otherwise, a single mistake could lead to me throwing out up to 1000 meals.

But if I just cook every meal as I go, I can tinker quite a bit, because the
cost of failure is limited to one meal. Which is no problem; if I really screw
up, I just pull the frozen pizza out of the fridge.

Extreme Programming in particular can be looked at as a set of methods to
flatten the cost of change curve. Then if you add the Lean Startup approach on
top of that, you end up testing your core hypotheses early on, so even major
shifts in business direction end up being pretty inexpensive.

------
crag
No... agile has failed cause most of the "enterprise" apps written in the
"agile way" (and many claim to be) are crap.

This isn't the fault of the agile manifesto. It's the fault of consultants who
used Agile as a buzzword. The same consultants who never understood agile or
cared to; producing apps riddled with bugs.

Agile was heading to the abyss the day it was co-opted into a marketing
buzzword.

------
McP
I found that in my team that agile worked brilliantly for us at first - we
were working together to create features that customers loved.

Then support queries came in for the features we developed previously. At
first a couple of team members would split off and work on the existing
features while the rest of us carried on working on the new hotness. As we
increased the number of (quite diverse) features, the more diverse the support
queries got.

Now we're basically no longer a team, but a group of individuals working in
different areas, who happen to be in the same stand-up each morning.

I am actively looking to fix this problem. I'm sure this must have been
discussed already but I can't find it! Any suggestions?

~~~
joshyeager
We have a similar support load, but have been able to avoid that problem. I
attribute this to two things: \- We have a highly skilled support team that
can handle pretty much everything except actually writing bug fixes \- Every
iteration we pull the whole team back to swarm on feature development
together. They may get pulled into different historical features for support,
but new development is always done as a team.

Support is still very costly for us, because the distraction of working on old
features slows down new development. To combat that we're putting a lot of
effort into fixing the root causes of our support issues and training our
support team to handle more and more technical problems.

------
briantakita
IMO, the worst meeting you can have is the "agile inception". Do not allow a
consultant who has no skin in the game to lead an inception. Do not allow them
to have a louder voice than the engineers in the project. They can set a tone
which is not coherent with the engineering team, which is bad, bad, bad.

I've been involved with a few inception meetings. Two of them had terrible
consequences for the life of the project. I got into a disagreement with a
high level company executive in one and an "inception master" consultant in
the other. They had no accountability for their "guidance" and they nearly
killed the projects from the start.

------
allochthon
> Because creating good software is so much about technical decisions and so
> little about management process, I believe that there is very little place
> for non-technical managers in any software development organisation.

Well said.

~~~
nnq
Yep. Good _software companies_ tend to get this. But the zillions on _creative
digital-media agencies_ that popped up recently, and realized that yes, what
they are doing is _software development_ and nothing else, and that their
"creative secret sauce" only contributes 10% max to the business _fail to get
his big time!_

------
bowlofpetunias
Once again, this is about mismanagement rather than Agile or software
development.

Besides the objections concerning throwing out the baby with the bathwater
when it comes to Agile, I also object to the notion that non-technical
managers cannot manage a software project.

True, 90% of all non-technical managers do not have the knowledge necessary to
manage software development, but very little of that actually includes hard
technical knowledge. As a tech manager with 25+ years of development
experience, most of my work involves _management_ skills, not technical
skills. The technical insight needed can be taught to any smart non-technical
manager.

Also, managing a software project is not about being "in charge" and
micromanaging, but mostly about serving, protecting and coaching a team.
People in the "no management" camp mistake management for hierarchy. Being the
manager is a team role, just like being a back-end developer, and interaction
designer etcetera.

None of this is about Agile or management, it's about two sides, old school
hierarchical "programmers-are-codemonkeys" management and tunnel vision "we-
don't-need-no-stinking-suits" developers, trying very hard _not_ to understand
each other.

And using Agile as a stick to beat each other with.

If Agile is dead, it's because it's been brutally murdered by two factions
unwilling to face their own shortcomings.

------
bitwize
Those who can, do. Those who can't, become methodology consultants. It's as
true of agile as it was of six sigma...

------
MRSallee
I'm only superficially familiar with Agile. I feel this piece isn't very
specific -- specifically, what benefits of Agile are being missed and why?

I like the Cargo Cult analogy, and the author paints a fairly clear picture of
what misapplied Agile tends to look like. Just not clear on what it should
look like.

------
keeptrying
Has anyone actually seen a product manager cut features to make product better
and to make sure the product gets shipped asap?

Well now you know why agile was just iterated waterfall in most
organisations...

------
hibikir
The issue is not really having a manager that is technical or not: I have met
great managers that were not technical, and terrible ones that were technical.

Success comes from trusting your people, having a clear goal the team believes
in, and a team of the right size to accomplish said goal. Every successful
team I've been a part of had all three. When even one is missing, there is
much dysfunction.

The agile rituals are there to try to make those things easier, but they are
just a way in: If you meet the important principles, you do not need them.
Just look at the Valve method: No management, no ritual, but a hiring process
that attempts to just get the kind of people that focus on those principles
like a laser.

------
MartinCron
The article closes with this idea:

 _@sbellware we should bury agile, mourn the dead, and get on with
establishing something that is designed to be resistant to being so easily
undermined_

[https://twitter.com/sbellware/status/443397344436817920](https://twitter.com/sbellware/status/443397344436817920)

Which makes me wonder, is it even possible to create a "thing" (idea,
movement, methodology, system, whatever) that is resistant to being
undermined? I don't think so. It seems like a natural cost to attaching a name
to something.

This is why I try not to talk about "Agile" these days, but rather just to try
to discuss the specific principles that have proven valuable for me.

~~~
wpietri
The one big mistake I think the Agile people made is not trademarking the term
Agile and then enforcing some standards. There was discussion early on, but
for some reason it never happened. For Agile it would have been hard, because
Agile isn't a methodology on its own; it's an umbrella for a bunch.

Enforcing standards doesn't make it proof against being undermined, but it
does make it harder. There's still a tradeoff between being popular and being
great that's hard to resolve. Especially since a popular, non-great thing is
more likely to get lots of money and attention.

~~~
MartinCron
That's an interesting idea, but my first instinct is that the cynical
developer response to "Agile(tm)" would be even more harsh than to just
"Agile".

------
Toenex
This comment on the OP site pretty much sums up a lot of these kinds of posts:

 _Learn about all good and important methodologies, and take what fits your
character and team. Any religious treatment of any method is not natural._

------
alien3d
I don't believe in agile. Agile come from inexperience project manager who
tough programmer is cheap .The most problem this type of manager is,wanted to
prove,if not from him company will gain zero income and income come from his
negotiation and paperwork . Security,quality code all is abandon.It's about if
the customer love it do it by hook or crook and wanted 110% quality .. In the
end,customer is tired because changing of idea and implementation delay
because didn't take counter measurement analysis on each request agile and
time. both loose.

------
wavefunction
Scrum Agile works great. Keep it light and loose and watch the code fly. I
don't know much about the other flavors or taking it too far into process but
I've seen the amazing things Agile as a philosophy can do.

~~~
mcv
Different teams handle Scrum in totally different ways. On my previous
project, it actually felt quick and light and agile. From one sprint to the
next, we could switch to an entirely different sub-project, planning poker was
quick, we never got around to backlog grooming, but somehow that wasn't a
problem. We got lots of stuff done.

My current project feels more sluggish. Long planning meetings where just one
or two people decide on the story points. Somehow we never really get all our
stories done in our sprints. This isn't a big problem, but it makes you wonder
how we plan this, and why we plan this.

The main differences I can tell between the two: this project we have a lot
more documentation. All on wiki, but on the previous project, be barely had
anything, and just asked people what the idea was and then did it. But my
current project is at a bank, so it makes sense they want more planning and
documentation, and less just figuring it out as we go.

At another job, our Scrum wasn't really Scrum. We had standups, but that was
it. No sprints, no poker, no scrum board, no burn down charts. But what this
article makes me realize is that that project may actually have been more
agile. Very few formal planning meetings, lots of informal communication and
programmers just doing what they're good at and calling the shots.

~~~
EdwardDiego
> My current project feels more sluggish. Long planning meetings where just
> one or two people decide on the story points. Somehow we never really get
> all our stories done in our sprints. This isn't a big problem, but it makes
> you wonder how we plan this, and why we plan this.

When you raise this at retros, what sort of response do you get? I believe you
can measure the health of a Scrum team by a) what issues get raised in a retro
and b) do they get addressed?

The iterative aspect of Scrum is also very much about iteratively improving
process.

~~~
mcv
Good point. I have to admit I never actually raised this point in a retro.
Also because it's pretty subtle, and the planning meeting is always after the
retro, so I forget about it by the time we get to the next retro. I focus on
the content of the sprint itself, not the meetings around it.

I hope to address this next time. Or maybe I should just point it out before
then.

------
oinksoft
I had a comment I made into a post:
[http://www.oinksoft.com/blog/view/7/](http://www.oinksoft.com/blog/view/7/)

------
seivan
The problem with agile was never engineering, it was non-engineerial
management bs.

------
seivan
Agile become this another layer of unecessary job creation for non-engineers

------
davidgerard
tl;dr you still can't Taylorise clue, but that'll never stop the Mgt. from
trying.

------
mankypro
...

