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

[wpietri]

Yes, you've definitely got the theory. In a well-run Agile shop, dates are derived from the backlog and the team's observed pace.

I'll add that Agile teams should also have something releasable every iteration (which ideally is every week). When that's true, dates are less of a problem. Instead of managers sweating engineers over when it will be done, managers in an Agile context spend their time arguing with other managers about the business question of whether to release something small and soon or something bigger and later.

In a well-run Agile context, anyhow. If you're not seeing those behaviors, but instead see the traditional drama, a high-pressure single convergence on a fixed date with fixed feature goals, then it's the sort of faux Agile this article is talking about.

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

[jasallen]

> it's not agile's fault. It's your fault. It's your team's fault

That's what everyone has said about every dogma they've ever believed in, ever.

[bmm6o]

Sure, that's the easy answer. But some organizations have success with that methodology, so it's obviously not impossible to ship quality software with it. And many of those organizations used something else and switched to it, so they must think it's superior their previous methodology. Or really, I should be talking about their implementations of methodologies, since reality doesn't match the platonic ideal even in the best case; in the worst case it might be unrecognizable.

So do you disagree that there are a lot of ways to implement "agile", some of which will be more successful than others? Or do you think that there are some organizations for which agile (even well-implemented) will never be better than methodology X? (where X = ?)

Yes, it's easy to run into No True Scotsman and "ur doin it rong", but we're not going to advance the state by pointing out that it's hard to draw correct meaningful generalizations (we know that already).

[ebiester]

That Is Why You Don't Do Estimates In Hours.

Relative estimates are much more reliable than absolute estimates. That's what fibonnaci sizing, etc. is about -- you can gauge effort relative to other effort.

Once you have an actual consensus of the complexity of tasks broken down, you can then apply that to the team velocity and make estimates.

Better is Arlo Belshee's system of getting everything to roughly the same size block. http://arlobelshee.com/planning-with-any-hope-of-accuracy/

[romaniv]

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.

This sounds like bullshit. More often than not, bad estimates are a result of built-in bias in the overall estimation system that gets blamed on the people.

For example, I routinely see people underestimating larger tasks when the cost of splitting them is prohibitively high, while the cost of being late with a task is largely imaginary.