The Five D Value Stream – Discover, Decide, Detail, Develop, and Deploy

January 13, 2017 — Posted by Ken Pugh

A software value stream shows how a software change flows from the discovery of an idea to it deployment.  We show how a simple model of a value stream can be used as the basis for more complicated models in larger systems and how doneness focused processes and agile at scale align with the model. 

The 5 D’s

Let’s start with the flow in a small organization.

Discover

In the discovery phase, changes to a system are elicited or explored.   The changes could come from a wide range of stakeholders - customers, marketing, business units, information technology, etc.   The changes could be new ideas, changes to existing applications, defect corrections, or other.

Decide

A decision needs to be made on what changes to deploy.   The decision can be made on business value, bang for the buck (estimated business value divided by estimated effort), weighted shortest job first, or other criteria.  The business doneness tests for each change are created.  A change should be minimized to what is the minimum amount that is releasable and still generates business value.  In some cases this might be large (e.g. an entirely new feature); in other cases very small (e.g. a user interface defect that hinders an operation from being performed).  The changes are prioritized as releasable items (also known as minimum business increments).

Detail

A releasable change usually does not contain enough detail for development.  In this phase, the details are elicited or created ending up as developable items (stories).  The process of detailing can result in a single change being broken into multiple changes.  It can also include creating customer/users doneness tests.  By creating these tests, the apparent ways to break the change down can be performed.  Some parts of the change may be presented back to the decision stage to determine whether they should be further pursued. 

Develop

The change is developed.    

Deploy

The change is deployed so that customers/users can utilize it.  

Feedback

The flow is not necessarily a single direction.   As noted above, there may be feedback among the steps.  For example, during detailing additional ideas may come out that need to have a decision made on whether to pursue them or not.  

 

Doneness Focused Processes

In a previous article, three doneness focused levels were introduced – Business Test-Driven Development (BTDD), Acceptance Test-Driven Development (ATDD), and Test- Driven Development (TDD). Here’s how they relate to the five steps:   

Larger Changes

In a larger organization, there are typically multiple levels to handle changes.  Typical agile at scale frameworks include Portfolio, Program, and Team.  

There are many ways that the 5 D’s could be spread across these levels.   Below is one way that it is done. There will be feedback among the stages which has not been shown to keep the diagram simple.

At each level, there is some decision making and detail creation.  Details may feedback into decisions as to whether to pursue them.    

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban