The thoughts, opinions and sometimes the rants of Mark Evans

Value Driven Development

| Comments

Over the last few weeks I’ve been spending time looking at Agile best practices and reviewing some of the things I have been learning about implementing ‘Lean’. Often people look just at the standard things development teams do such as TDD (Test Driven Development) and BDD (Behavior-driven Development) but I think these are part of a wider aim which ties into the notion of delivering ‘Value’ called ‘Value Driven Development’.

I’ve talked about the Agile Manifesto before and I want to go back to it again here to review the following principle

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

While this is a noble aim I think that value is much more than just lines of code or software and to provide real ‘value’ you also need to consider what is not delivered along side what is delivered.

Avoiding building the wrong thing can provide as much value (sometimes more value) than rapidly delivering software that no-one uses. Using an ‘MVP’ approach you can hopefully avoid the trap of building software no-one uses. I’ll talk more about ‘MVP’ and ‘Build Measure Learn’ in future blogs posts.

In order to provide the most value I believe that the first thing you need to do is identify and eliminate ‘waste’.

Waste sounds like quite a harsh word but I am not sure there is a better one to descibe doing things which don’t provide value.

Waste can consist of many things, some of the more obvious ones are

  • Partially Work Done (Code sat on QA/Staging)
  • Waiting for tasks to be UAT’d / Inefficient QA Processes
  • Excessive documentation / Bureaucracy
  • Developing features which aren’t required to validate a hypothesis
  • Building things no-one wants
  • Waiting for Information
  • Task/Context switching
  • Bugs / Defects

In order to eliminate this product and development teams need to ensure that throughout the process they continuously look for anything which doesn’t bring value. One technique that can be used for this is known as Value Stream Mapping

I’d strongly suggest that teams take a good look into their own value stream map to see where they can identify anything which can be removed / eliminated allowing the teams to focus on delivering value.