4 ms·

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 wo

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.

romaniv 13y ago
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.
vonmoltke 13y ago
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 13y ago
  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.
jasallen 13y ago
> 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 13y ago
  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 13y ago
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/ http://arlobelshee.com/planning-with-any-hope-of-accuracy/

romaniv 13y ago

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.

vonmoltke 13y ago

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 13y ago
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.

jasallen 13y ago

> 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 13y ago
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 13y ago

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/ http://arlobelshee.com/planning-with-any-hope-of-accuracy/