Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Making Agile Stick

December 17th, 2008 · 2 Comments

Yesterday Brian Marick tweeted that he had “Realized one reason I’m suspicious of current trend toward visionary leaders guiding Agile adoption: it’s a single point of failure.” This was the one reason my attempt to introduce Agile at my previous job ultimately failed in spite of being really quite successful at quickly and cheaply delivering working software: the visionary leader (CIO) was removed from the company. The new CIO pretended to want to accommodate the agilists in the organization, but quickly and quietly made moves to squash it.

Now, it’s interesting to note that my agile experience was a bottom-up implementation in the sense that it wasn’t part of an organization-wide agile implementation. Our CIO simply mentioned Agile in a large meeting, and I took that as implicit permission to mess around with the ideas behind the Agile Manifesto. The fact that he had mentioned it meant that when I was finally open about what I was doing people in my management chain were hesitant to try to stop me because they didn’t want to look stupid to the boss.

This experience made me believe that there is really only one way to make agile stick in corporate IT: to ingrain it into the culture of an entire company (not just IT) so deeply that no single person can root it out. The only way to do that is to make it a fundamental part of the operating model of the company. In other words, the business has to demand it. Not request it, not gradually migrate toward it, not make it an optional approach for the interested, but demand it.

The funny thing is, the business doesn’t really need to know that what they’re demanding is Agile. In fact, demanding Agile explicitly is probably a bad idea because smart CIO’s will immediately bombard them with the common agile-doesn’t-scale or agilists-are-cowboys or some other compelling argument that the business will find hard to ignore.

No, what the business needs to demand must be far more fundamental than that. The demand needs to simultaneously make the agile values imperative AND reject all processes/methodologies that conflict with the agile values. You see, I think it’s not enough to put Agile and Waterfall on equal footing. Waterfall, for software development, must be destroyed.

So… what demand do they make?

I believe it’s simple, and it’s something the business understands. It’s earned value. Earned value is usually calculated as a fraction of the total value of the project, based on progress toward completion. It is the fundamental premise behind Waterfall, and if you can change the way earned value is determined you can put Waterfall behind you and clear the way for Agile and other methodologies like it.

Only working software has value. All of the artifacts leading up to working software have zero value. They are worthless. This is the thing, that above all the other ideas that came out of the Agile Manifesto, matters the most. It’s the driving force behind short iterations, face to face interaction, etc. It’s the thing that started it all.

If the business accepts this, believes it, and establishes it as a guiding principle of the business’s operating model, IT will do what they’ve always done: what the business tells them to.

Better yet, the funding model for IT projects will change dramatically. Instead of stage gates that force the high-risk, unwieldy, and wasteful project phases of waterfall on IT project managers, funding stage gates will be built around the agile concept of earned value. Instead of giving project teams a month to come up with an enterprise design proposal that will be used to award the next round of funding, IT teams will be given a month to implement some portion of the business capabilities needed.

But… we don’t even use earned value in our waterfall projects now. What difference will it make if the definition of earned value changes?

You might not report on earned value, but you still use it. You can’t do waterfall without fundamentally buying into the concept that intermediate artifacts (I refuse to call them deliverables) such as requirements documents have value. If they didn’t have any value, then the risk management portion of the waterfall approach would force you to abandon them. It’s the philosophy behind the earned value formula that matters, and whether you actively calculate EV or not doesn’t really matter.

Earned value is the key to making agile stick. If the business recognizes only working software as having value, IT processes will follow suit.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Agile

2 responses so far ↓

  • 1 Allen // Dec 18, 2008 at 7:01 pm

    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”

  • 2 Brian Marick // Dec 31, 2008 at 2:43 am

    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.

Leave a Comment