Value Driven Development

This might be the next big thing, the new buzz word of the agile world.

In Test Driven Development (acronymed to TDD), the goal is to test everything. In Domain Driven Development (yup - DDD), we strive to make an excellent Domain Model - that's our goal. In eXtreme Programming, a.k.a. XP, the idea is to program without having to design anything, and in Scrum, the goal is to huddle together and come up with a short Gantt chart that states what we promise to deliver in about 3 weeks. Ideally, we'll have several iterations planned in advance, so that we can have a long-term view of things.

The problem, as management, will be quick to tell you, is that sometimes we have to forsake these noble goals, and focus on delivering value to the customer. So here's my idea: Let's propose a new agile methodology, Value Driven Development, where we use agile process to constantly create value for our customers? That, as we know, is always our goal, right? The business people will love this.

For those of you, who did not stare in shock and disbelief at the first paragraph, let me make something clear: Everything I wrote there was wrong! Everything I wrote is an unfortunately common misconception about the respective agile methodologies. The truth is that these so-called "goals" are the means to the end. What end? Value, of course. But read on, please. Explanations to come...

The question is why are these misconceptions popular? To answer this, I'd like to describe a rather common scenario I came across:

1. A development team is in trouble. The code base is horrendous, the schedules are ignored. Feature requests creep uncontrollably, and the bugs increase in polynomial proportion to the number of changes made to the system.
2. Someone, usually a veteran developer, perhaps a team leader, but often not, stumbles upon a book on agile development. Perhaps a blog.
3. The developer reads the book, cover to cover, constantly smacking his or her head, exclaiming things like "OMG! That is exactly what happens to us! This is exactly what we need!!!"
4. The developer runs to his manager - all the way up to the CTO, telling them how this or that agile development process will save their bacon.
5. A few days later, the idealistic developer makes his presentation to management. Describing the artifacts of DDD, or the Planning Poker session and Daily Scrum. Or perhaps touting the benefits of pair-programming ("We put two programmers together, and we'll have bug-free code, because the second programmer sees things that the first misses").
6. Management quickly assesses these things as Nice-To-Have (at best), and responds with something like: "I can't authorize putting twice the resources on a single task! It'll take you twice the time to write the code, in man-days!" or "This card game is silly. We won't do it." and of course, the inevitable "I don't care how you write your designs - write whatever Domain Model you need, just deliver bug-free and on time."
7. The room is empty. The developer picks up his laptop, and wonders how everything went wrong. "How come I'm the only one that understands this?"

The answer is simple. The presentation was simple, straight-forward, technical. It did not present the real value to the customer. The presentation was geared towards the people who will implement the methodology. The business people need the abstract. And they need to know the "return value" (i.e. what the actual, quantifiable value of a certain methodology is). The decision makers need to understand the interdependencies between a methodology's processes.

This is much like the Dependency Inversion Principle. To quote Robert C. Martin, "High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions". In other words, don't confuse them with details. Explain the idea, the essence. And make sure the process implements that essence.

They need to understand that XP promises robust code by combining group responsibility with rigid standards of coding. They need to know that this is done at no expense to delivery schedules, because the small increase to the initial coding phase will pay off in greatly reduced time to debug and change the same code.

They need to know that Scrum offers a highly visible management process, and increases the values of effort estimates by early exposure of risks, and a commitment to deliver the greatest value early on, and allow the customer to change his demands to adapt to the rest of the world.
There are more values in each methodology than I can put into a blog post, but the important thing to understand, and even more importantly, pass on: Is that every agile methodology is a Value Driven Development methodology.

So next time you try to sell Agile to management, focus above all else, on the actual value to the customer, to the business. Use graphs, quote from white papers. Leave the specifics for the implementers. Or, if the details are requested, make sure to highlight interdependencies, so as to discourage uninformed picking of artifacts from various methodologies in what seems to be an effort to reduce costs and increase value even more - that is the uncharted road to agile hell. But that is for another post.