One of the things that originally attracted me to the agile movement was its claim to focus on delivering business value. Indeed, one of the agile principles is "early and continuous delivery of valuable software." I'm sure we've all suffered from the problems of gold-plating, committee driven requirements, the boss insisting, "we must have this just in case someone wants it in the future" and the like. These are things that cause no end of problems in software development, lead to feature bloat and overly complicated applications that are incomprehensible to the average user. The problem is so bad that one industry survey [1] found that 64% of implemented features in applications were either very rarely used or never used at all. From those figures it doesn't take much of an IQ to work out that only one third of the finished product is actually providing any value. If only we could decide prior to development what the most valuable features were, we could save ourselves a lot of money or, alternatively, build a lot more products.

Much of my interest in delivering business value and streamlining processes stems from work I did years ago as part of a university's Logistics Research Group, so I was particularly impressed with the Poppendiecks' [2] application of Lean Thinking [3] to the world of software development. Their use of value stream mapping to differentiate between those areas of programming lifecycle that produce value and those areas that produce waste is a technique that I have adopted and successfully used many times. I find it a principle very easily grasped by most. It is simply a matter of drawing up a list of all the processes in the organisation that work has to go through before it is completed. After that, you merely have to decide which processes add value to the product and which ones don't. Finally, you need to inspect the process that do not add value and determine whether or not they are really necessary. It sounds very simple in theory and it is in practice too but major problems can arise if you are cavalier about telling people, especially managers, that their work is unnecessary. Especially if you tell them that they are a waste. Discretion is advised but we can talk more about this later.

A very simple example of a value stream is given here. In the description of Jim's bug-fix process, we can see that there are two wait periods of 28 days each for the Bug-Review Board. Meaning that, on average, each bug will spend 28 days waiting and 2 days being ratified, as shown in the accompanying diagram.

Is it really necessary to have a full-scale meeting to determine whether a bug will be fixed or not?

I would suggest not, so if we can appoint an individual to be responsible for making that decision in real time, as and when they are entered into the bug tracking system, we can remove the 28 day wait and the two ratifying.

This will reduce the time that bugs spend in the system from 86 to 56 days. There are other areas of waste in the system but this is obviously the greatest and is enough for the purposes of an example.

The big problem here, of course, will be persuading the members of the Bug-Review Board that an individual should in future, perform the work they have previously done.

The benefits might seem patently obvious to most people but there are all too often important people who will claim that any work they are involved is also important. It's not easy to win over individuals that use the proof by assertion strategy, i.e. "It's true because I say it is!" Again, we can come back to this later.

Another useful addition to the project manager's arsenal is the identification of a Minimum Marketable Feature (MMF) set. This is a technique propounded by the authors of the book Software By Numbers [4]. They propose that for every software project, there should be a subset (the MMF) of the complete requirements that provides sufficient value for the product to be deployed. This not a prototype but rather a bare-bones system that makes it possible to deploy early and begin earning a return while the rest of the feature set is developed. This relies on the software being developed incrementally and fits nicely with the agile principle of delivering working software frequently. Because the value from the software is increased as features are added, the authors refer to it as an incremental funding method (IFM) and it should work well with any incremental development process.

The decision as to which particular features should be included on the MMF is made using a cost benefit analysis. To get the product to market ASAP we need to choose features that are quick and easy to implement (cheap) but, at the same time, we also need to provide sufficient value for the user to benefit from using the product.

In the example shown here, the agile project follows the usual 80/20 rule and delivers 80% of its functionality with its first 20% of effort, including the MMF, in iteration three.

From then on we start to earn benefit from the system and, in fact, the project becomes self-funding halfway through iteration four. In contrast, the same project done in a traditional manner could not deliver any benefit until the end of the project and would not break-even until over three iterations after that. By that time, the agile project would have delivered over £200,000 of benefit. It actually delivered £150,000 of benefit before the traditional project had even finished.

Just like in the value stream example, it's a simple matter of assessing each feature on their cost and value before choosing the most appropriate to include in the MMF. The problem remains, though. How do we decide the value of a feature? In some cases, where the benefits are purely financial, this is easy to decide but in others the benefits may be of a somewhat less tangible and more subjective nature. What appears to be valuable to me may have little or no value to another. We spoke earlier of individuals in the organisation insisting their choices were valuable just because they were in a position to do so. There are often many stakeholders in a project: users, managers, developers, etc. How can we come to a common understanding as to what constitutes value for the project with so many diverse interests to cater for? Of course in XP [5], they have a role called the Customer who has the responsibility for making the business value decision but again, there is little written on how the Customer makes that decision. To overcome this problem, I use a combination of personas and mission statements to create value scorecards.

Personas come from the world of interaction design [6] and are also used by Mike Cohn in his user stories book [7]. A persona is an imaginary representation of a real person. First, we identify the roles of all the stakeholders in a project and for each role; we create and name a persona. For example, for the user role, we might create a persona called Jim who is a typical user. Jim is not a power-user; he is just the standard type of person that might use our system. For Jim's persona, we need to determine the type of person Jim is and his likes and dislikes. We might say that Jim is a financial analyst, around forty years old and married with two children. He is degree educated in a non-technical subject so doesn't like technology. Jim even gets his kids to program the video for him. He likes spending time with his family, plays golf on a Saturday and drives a popular type of saloon car.

This is a condensed example and I would usually hold a workshop to really drive out the detail of Jim's persona. From the detailed description we have of him, it isn't usually difficult to get a very good idea of Jim's values. A picture that we've drawn or maybe found on the Internet can be kept with Jim's profile to allow us to relate to him even closer.

Following the same process, we go on to develop personas for as many of the other key stakeholders in the project as is practical. There might be one for a typical administrator, a systems integrator and so on. They should encompass all the people who either use the system or are affected in any way by the choices made. Don't forget that the company we work for is also a stakeholder in the project and has values. This is where the mission statement comes in, as this is where the company's values are espoused. From each persona, we are able to extract a list of values and it's probable that some values will be common to more than one persona. Scoring the values by how many personas hold them allows us to rank them in order of importance and we need to do this as it is difficult, if not impossible, to incorporate every value into one project. We also need to resolve conflicts between values and again, the scoring should help us there. About five values should be sufficient, some of them being purely financial and others more qualitative. Any more and the process becomes too cumbersome. We should end up with a list of values something like the one below.

Once we have our values and relative weights for them, we can go on to create our value scorecards. We simply list our stories and rate them out of ten for each value, using the value weight to create a subtotal. In the following example the total column contains the sum of the subtotals created by multiplying each value's rating by the value weight:

Interestingly, in the above example, the project team had originally rated the data entry story (S2) as the most important because they imagined that it would be impossible to produce reports without having first entered the data. After performing the scorecard exercise, however, they realised that the operators were already keying the data into spreadsheets and they could be used as the basis for the analysis reports. The key customers, the analysts (personified by Jim) could feasibly use, and gain benefit from, the system without the data entry story even being implemented.

A similar process can be performed to determine the value of step in your organisation's processes. Identify all stakeholders for the process in question, create personas for them and determine their values. Don't forget to include your organisation's mission statement and its stated values. It's easy then to determine whether any stage in the process is adding value or not. The use of value scorecards allows us to ensure that we are at all times acting according to our declared values and, without wishing to encourage the use of the "Golden Hammer" anti-pattern [8], it is remarkable how effective they are in many different situations. Even the most senior of opposition must either accept the incontrovertible evidence of the value scorecard or seek to change the organisations values.

Bibliography:
1. Survey by The Standish Group, http://www.standishgroup.com, 2002
2. Lean Software Development, M & T Poppendieck, Addison-Wesley, 2003
3. Lean Thinking, Womack & Jones, Simon & Schuster, 1996
4. Software By Numbers, Denne & Cleland-Huang, PTR, 2004
5. XP Explained, Kent Beck, Addison-Wesley, 1999
6. The Inmates Are Running the Asylum, Alan Cooper, Sams,1999
7. User Stories Applied, Mike Cohn, Addison-Wesley,2004
8. AntiPatterns, Brown, et al, Wiley, 1998