Pretend you have a really great programming day. You only have to attend a few meetings, have only a few off-topic conversations, don't get distracted or interrupted much, don't have to do a bunch of status or time reporting, and you put in a good six hours of serious programming [note: this RARELY happens in an 8-10 hour day]. I want to review your work in the morning, so I print out a diff of your day's work before going home. Sadly, overnight the version control system crashes and they have to recover from the previous day's backup. You have lost an entire day's work. If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work? Programming is 11/12ths Thinking I've been touting this figure for some time now, and people keep asking me where the study is that produced such an odd number. Well, it's not pulled out of thin air and it's not the result of a thoro...
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.)