The key to Agile and Lean methodologies is “the rapid delivery of customer value”. Anything that does not add value is considered waste. In Agile, value is often defined as “working code” but this is too narrow a definition. It assumes that the only stakeholders that matter are the end users of the software and that the only product the team needs to produce is the software.

In reality, the team is unlikely to be producing just software. At the very least there will be documentation and other end user collateral. There will also be artifacts that are not valuable to the end user but may be of immense value to other stakeholders. It could be argued then that pretty much anything turned out by the team has value to someone. So what is waste? Working code is too narrow. Absolutely anything the team does is too wide.

In Lean, the definition of “customer” becomes –

"Anyone who pays for, uses, supports or derives value from the system being created"

Leading Lean Software Development — Mary & Tom Poppendieck

The team needs to work out, from the perspective of each of those customers, just what they will value. The customers who use the system are fairly obvious – they are the ones who want working code. The ones who pay for the system will more than likely also value the working code but will also have some other things in mind. Things like reliability and total cost of ownership. Those that support the product will be interested in things like reliability and how easy the product is to support. The fourth category is more nebulous – those that derive value from the system. So who are they?

They can be many people – the company that is developing the system is probably hoping to gain some value from it. They will probably be looking for things like marketability and high cost-to-earnings ratios. There will probably be more. A typical project has dozens of stakeholders identified, internal and external and all of these will have something that they need from the team. Something that they value.

The team needs to work out what each stakeholder values and how best to deliver that value. The best way to work this out is in consultation with the stakeholder in question. Don’t try to guess. Ask the question - “What do you want and how can we best give it to you?” It may well throw up some surprises.

Be careful though. When dealing with stakeholders, the traditional way to deliver value is via documents. This is OK if the document really does add value. A statement of compliance to a standard adds value if the system must adhere to that standard. A user guide adds value if the users need documentation to operate the system. Documents though are often symptoms of other problems. A document is OK as a starting point but there may be a better way.

A user guide only adds value if the users can’t use the system without it. The real value here is a usable system, not a user guide. No one needs a user guide to use Google. Development teams often write large documents for support teams to improve the “supportability” of the system. Is this the best way of delivering value to the support team? Would they be better served by well structured code, fully covered by automated tests? Is your comprehensive installation guide a sign that your system is hard to install? Is the real need a system that is easy to install?

They key to delivering value is to determine what the real need is. Once you have the need, work out how to fulfill it. If the need is a document or other artifact, this may be an indication that you have not uncovered the real need yet.

Cheers

Dave