Tuesday, March 2, 2010

Early Client Value is more than just something that works

I'm currently teaching agile development in two very different contexts. One is a course for mid-level managers, most with no software experience. I'm also coaching a team of computer science and business students, doing a project in a course on innovation and entrepreneurship. In both courses, I talk about the need to deliver early client value via slices (my shorthand image for minimal marketable release).

Or, as I usually put it: How soon will you be able to say "Even if they cancel us, we delivered value?"

I contrast developing slices with a "foundation up" approach that works on infrastructure first, rather than some end-to-end deliverable.

Both groups got the idea of getting something working that the client can use, but both made the same mistake in their release and iteration planning. Their first releases were systems that supported basic operations like adding, deleting and displaying items. For a hypothetical system to manage software purchases, users could add records of things purchased and query along various parameters. For a social network site project, users could upload pictures for sharing.

These are end-to-end, and they do make sure things are working, but they are not valuable. These things can be done with existing freely available tools. If the project died tomorrow, the client would not have anything they didn't have already. These are minimal releases, but they are not marketable releases.

Every system has a reason for being, a need that's currently not met. Early value means something that makes some visible progress towards meeting that need. The software purchasing system was originally envisioned as a way to reduce costs by seeing the best prices that divisions in a company had managed to get recently. Therefore, an initial release and early iterations should focus on displaying data, not entering it, and demonstrating possible savings. The social network site first release should show something about sharing pictures or other media not currently possible or easy in existing sites.

Note that in both cases, it may turn out that the original vision is infeasible or much harder than thought. Better to know that early. And, in the purchasing project, the initial release might not need to have any user interface for adding purchase records at all. A table from an existing purchasing database generated by a manual query may provide enough real historical data for the system to fulfill its original mission well enough for a marketable release.


  1. I think this is a quandry. soemtimes the thing that will provide differentiatned value in a product is the piece that requires the non-differentiated value in order to work. especially on the web and in mobile today; the good news is there are lots of good building blocks for that "base" stuff that's undifferentiated. You need registered users? use facebook connect--or go registration-less to start so there is some user value. You need photo sharing? use flicker. You need realtimme broadcast? use twitter. You need customer schema; use salesforce.com Especially focusing on the visualiation in datamining rather than data adapters to start is worthwhile. the next big sound guys did that which was workable and let them live to another round of funding.

  2. Those chickens and their eggs are indeed annoying. But I think the more effort that is spent before getting to something with added value, the greater the risk. So it still seems best to either use off-the-shelf solutions (easier and easier these days) as you say, or come up with creative end-runs around the base stuff.