Coconut Headphones: Why Agile Has Failed

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

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.)

It was your fault. You made a modification to a production database without understanding the full repercussions. You brag about how your refactoring made her software better, but you are ignoring the fact that you got into that mess because of a failure to follow best practices and common sense.

> 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.

Yeah; a lot of the solutions you see pushed here on HN don't really scale past a startup-sized company. A lot of times if you have a very large product, you have multiple engineering teams working on a layered architecture. For example, the product guys will hand off a requirement as a user story that describes "As a customer, I can push the green button and it orders a pizza sent directly to my desk." That user story involves the front-end team (UI mockups, interface implementation, etc.), the back-end team (now has to support storing and retrieving the user's pizza preferences), the billing systems team (now has to ensure the pizza billing process has the proper audit checks, etc. on it), the deployment team (who now has to ensure pizza-order messages are allowed through the firewall to the pizzeria), etc.

It's a bit of a contrived example, but you get the idea. Unless you have a centralized management function, all of this doesn't happen and your glorious pizza button either doesn't work or fails deployment. Usually the onus falls on the product manager to do this, but with so many teams involved it can be a nightmare.

> Has it really failed?

It works fine for us, but we have the ideal conditions for it to - business product owners who understand that their role is to provide a prioritised backlog and clarify stories in a timely manner - and nothing else. We have an organisation that accepts that the developers will drop features from a sprint to safeguard reliability and quality. We have teams that have stable core domains so that our estimations are, for the great majority, sufficiently accurate within that core domain.

Every time I see a "Agile is a scam / it's dead Jim / it's a myth" post, it usually involves into someone doing something dysfunctional and then trying to justify it with "But Agile!" in a game of Buzzword Bingo.

I went to help a local government IT department that was trying to implement Scrum to get some clarity on what the hell was going on in their dev teams, and I sat in on sprint retrospectives where all the talking was done by the 'product owner' - who was actually a rebranded business analyst who had no authority to prioritise backlogs. He wouldn't stop talking either, even when I explained to him that the retro was for the team, not him.

To that team, Scrum was a bunch of bullshit. To me, how they were doing it was obviously flawed. That said though, ultimately, that organisation has derived value from their half-assed implementation of it. It's shown them precisely who contributes in their IT team and who is cruising. They've got a few people who claim a monopoly on certain areas and jealously defend them because it makes them feel necessary and as such, safe from being laid off. Hence I had a GIS guy telling me that "You can't expect .NET developers to learn GIS!!" and an ABAP developer saying the exact same thing.

Now that organisation faces the challenge of managing the coasters out - unlike the US of A we don't have at-will employment.