This is the place for you to regale me with stories of backslides . I am interested in how it happened as well as your guesses as to why. Is agile too counterintuitive? Does the method underdeliver? Are managers too addicted to practices made impossible in agile? Was it too hard?
I'm hoping to learn and adjust my perceptions. You can help.
Biggest reason I've seen (at 3 firms) has been "failure to engage customers in the process." Now, in 2/3 of the cases, you couldn't have engaged the customers in the Agile process with a gun to the head.
ReplyDeleteFrom what I've seen, business still things agile is just another bullshit attempt by programmers to play instead of work.
They neither understand nor want to understand how development does what it does, and they CERTAINLY don't want to be involved. They just want the work done.
So they play along a little while with the (erroneous) understanding that they're "just helping things get going." And that's where it seems like things are going well.
But two months go by and the customer is asking questions like "how much longer am I going to have to come to these meetings?" That when you know.
Your mileage may vary of course ;-)
A friend said to me (condition of anonymity?) that
ReplyDeleteI think that agile requires a level of integrity and accountability that is inimical to corporate organizational behavior.
Doesn't that require buy-in to the "corporations are fundamentally dishonest" supposition?
ReplyDeleteI would personally have replaced "corporate organizational behavior" with "unhealthy organization's behavior."
ReplyDeleteA company I know dropped agile when they got in a hurry. I suppose that shows that they didn't think that tdd, pairing, reliance on testing, MMF, etc were giving them the boost they need, and that everyone working long hours gave them better results.
ReplyDeleteMind you, they were working with legacy code, so the transition to agile is going to bring initial slowdown as the old code is brought under test and cleaned up. I don't think they got past that stage before impatience took over.
As a footnote, their mad one-month non-agile rush project took many months, just as it would have with agile. But with a more waterfall process they didn't have reliable progress data along the way. Besides, they found it comforting when programmers who were there at 7am were still there at 9pm. It felt like managers were getting things done, because programmers were killing themselves to do the work. If you think management is all about motivating people, I guess that is good management. Personally, I see management as something different, but there you go.
I think that the real problem might be that their agile attempt didn't demonstrate that they could get code to market faster. Maybe the number of bugs cleared wasn't helping build a strong case, and the orderly work flow seemed leisurely to the untrained eye. Clearly the "sustainable pace" bit was not making points up the hierarchy.
I also note that the Customer was not a single point of decision, but a lot of people competing against each other to get their own customers' features released first.
Maybe in such an org, it doesn't make sense to try agile. After all, anything you drop into a shark tank is going to get killed in short order.
"After all, anything you drop into a shark tank is going to get killed in short order."
ReplyDeleteExcept a much bigger, hungrier, shark.
;)
(Sorry, I guess I am just in a sardonic mood this evening.)