Comments on: Making Agile Stick http://www.techdarkside.com/making-agile-stick Struggles of a Self-Taught Coder Tue, 07 Feb 2012 02:07:00 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Brian Marick http://www.techdarkside.com/making-agile-stick/comment-page-1#comment-15764 Brian Marick Wed, 31 Dec 2008 02:43:36 +0000 http://www.techdarkside.com/?p=284#comment-15764 Shoot, I read the blog post when you sent it, had a thought, didn't write it down, and now I've forgotten it. Couldn't retrieve it, but here's a different one: value isn't enough, you also have to consider cost. People-who-pay-for-projects want to know how much the value will cost them vs. other projects or vs. putting the money in the bank. Waterfall provides them with a simple promise: You will spend X by date Y. You have another number, Z, which is the value of the project. You can plug those numbers in a formula, wave around words like "net present value", ignore the fact that your estimate of Z is a wild-ass-guess, and come up with a hard number that you can compare to other hard numbers, make a decision -- "We will fund Project A" -- and be done with it. Agile projects are more like extending someone (a product owner) a line of credit and letting them draw down on it until they say they've reached the point where further benefits aren't worth the cost OR you look down from on high and determine that product owner is no longer creditworthy. (In which case, you double their credit. Ha, ha, only serious.) Yes, you can draw graphs that show that you get more value sooner, and hence more value in the long run, if you release increments of value instead of waiting until the end to release everything. And in a perfectly rational world that'd be end of the story or pretty close. But in this world, Agile requires the Cxx people do more total work and more continuous work, have more *apparent* trust, and maybe have more nuts-and-bolts knowledge than waterfall does. And I think that's a barrier to adoption, though I may be being cynical. When it comes to large companies, I've only bumped up against C-level people once. Another thing: at that large company, the CTO asked me what evidence I had that Agile teams would be more productive. I said I had none, and that I wasn't even sure they would be. I said that what you're buying with Agility is flexibility and responsiveness: an organization and product portfolio that you can "drive" more easily. That worked pretty well, but I wonder how many organizations value -- really value -- flexibility and robustness over efficiency. Because Agile sure looks wasteful. It accepts rework! Toyota doesn't do rework. Rework is bad. Shoot, I read the blog post when you sent it, had a thought, didn't write it down, and now I've forgotten it.

Couldn't retrieve it, but here's a different one: value isn't enough, you also have to consider cost. People-who-pay-for-projects want to know how much the value will cost them vs. other projects or vs. putting the money in the bank. Waterfall provides them with a simple promise:

You will spend X by date Y.
You have another number, Z, which is the value of the project.

You can plug those numbers in a formula, wave around words like "net present value", ignore the fact that your estimate of Z is a wild-ass-guess, and come up with a hard number that you can compare to other hard numbers, make a decision — "We will fund Project A" — and be done with it.

Agile projects are more like extending someone (a product owner) a line of credit and letting them draw down on it until they say they've reached the point where further benefits aren't worth the cost OR you look down from on high and determine that product owner is no longer creditworthy. (In which case, you double their credit. Ha, ha, only serious.)

Yes, you can draw graphs that show that you get more value sooner, and hence more value in the long run, if you release increments of value instead of waiting until the end to release everything. And in a perfectly rational world that'd be end of the story or pretty close. But in this world, Agile requires the Cxx people do more total work and more continuous work, have more *apparent* trust, and maybe have more nuts-and-bolts knowledge than waterfall does. And I think that's a barrier to adoption, though I may be being cynical. When it comes to large companies, I've only bumped up against C-level people once.

Another thing: at that large company, the CTO asked me what evidence I had that Agile teams would be more productive. I said I had none, and that I wasn't even sure they would be. I said that what you're buying with Agility is flexibility and responsiveness: an organization and product portfolio that you can "drive" more easily. That worked pretty well, but I wonder how many organizations value — really value — flexibility and robustness over efficiency. Because Agile sure looks wasteful. It accepts rework! Toyota doesn't do rework. Rework is bad.

]]> By: Allen http://www.techdarkside.com/making-agile-stick/comment-page-1#comment-15749 Allen Thu, 18 Dec 2008 23:01:01 +0000 http://www.techdarkside.com/?p=284#comment-15749 Sorry that I only have a cursory knowledge of both Waterfall and Agile. But at what point does good planning begin to have enough value so that it makes it onto the Earned Value stack? "Weeks of coding can save you hours of planning" Sorry that I only have a cursory knowledge of both Waterfall and Agile. But at what point does good planning begin to have enough value so that it makes it onto the Earned Value stack?

“Weeks of coding can save you hours of planning”

]]>