Value Stream Mapping
While preparing for the PMI-ACP exam, I was introduced to Value Stream Mapping in Mike Griffith’s PMI-ACP Exam Prep book. Determined to give it an immediate try, I enlisted the help of my colleague, Piya Mewa, a business analyst on my team. Together we visualized the value stream for a feature our team was working on at the time. (See the photo above. Yes, that’s my sloppy handwriting.) Recently, reading the section on Value Stream Mapping in the book Lean Softwared Development by Mary and Tom Poppendieck has prompted me to revisit what Piya and I learned.
Now before I can describe what value stream mapping is and why it is useful, I have to answer the question, What is a value stream? Before I can answer that question, I have to answer the more basic question, What do I mean by value?
What Is Value?
The question, what is value, is answered by the first principle in the Agile Manifesto:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Value is satisfying the customer by delivering the outcome they need. In the quote above, the focus is on delivering software. But a customer’s outcome could be a product, service, or result (see the PMBOK Guide, 6th Edition, Chapter 1).
So value is what the customer perceives as the outcome needed satisfy their need. Whether or not the customer’s perception is right is a topic for a different discussion. For this discussion, let’s assume the customer knows what they need and it is the best solution to their problem.
What Is A Value Stream?
A value stream the process by which a deliverable develops from concept on through to realization. A deliverable may pass through many work tasks to reach the goal of being something of value to a customer.
Picture yourself in a boat on a river. Your goal is to reach your destination. This is what will bring you satisfaction. This is what you value. The stream you are traveling may carry you speedily on rapid currents. At other points it might slow down, meandering through broad pleasant valleys, delaying your arrival. Someone may have built a dam that blocks your progress, or God forbid, you might go careening over an unexpected waterfall and break your neck. (It’s probably happened to most of us on a project or two.) You will want to navigate that stream as efficiently as possible in order to reach your destination quickly – and safely.
In this analogy, your boat and its cargo are the product you are delivering. The meandering progress, damns, and waterfalls are comparable to the “seven wastes” of software development which the Poppendieks elicit in their book:
- Partially Done Work
- Extra Processes
- Extra Features
- Task Switching
- Waiting (Delays)
- Motion (Handoffs)
Value stream mapping charts the course your boat follows in traveling to your destination. In your work, value stream mapping helps you visualize the process by which your deliverables are produced and the various phases (cycles) through which that production passes. It is an effective tool for seeing the areas of waste and the areas of true value-add within your process. (Primarily, value-add activities in software development are analysis and coding. See Poppendieck.)
Our Value Stream Mapping Exercise
Now let me return the the image of our very elementary value stream. This time I’ve added numbers to indicate the different steps through which this particular feature development passed. The days noted are business days. The whole process from concept to production took 33 business days! (This overall time is known as “lead time.”) What is missing in the image is another line indicating the parts of the stream that added real value and the parts that did not.
Let’s see where the map reveals areas of waste.
Right off the bat, I can see that there was A LOT of MOTION in the process. The ball was passed between a lot of players. At least 12 different people were involved from start to finish. Every handoff is a point of risk for dropping the ball. Example: There were 6 handoffs in the requirements gathering phase before development actually started.
How could that be made better? Why not consolidate steps 1 – 6 into one step involving business owner, BA, and developers? Seven days could have been shrunk to a half-day session. The Agile principles “Business people and developers must work together daily throughout the project,” and “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” would apply here.
Another element of waste that is glaring in our value stream is WAITING.
For example, after the business analyst emailed the developers in step 3, why did it take 2 days for the developers to respond? That’s 6% of the lead time. Next, why did development take 20 days? That’s 60% of the lead time! There was also waiting for UAT signoff, a global release approval meeting, business owner production release approval, and the actual release day.
How could that be made better? Well, much analysis could be done on the many factors that influenced the development situation. But since I was there, I will tell you that a few of the factors included more interaction with the business owner for requirements clarification. That’s fine when working in an Agile way. However, I think more face-to-face interaction between developers and the business owner without relying on the business analyst to be the middleman could draw out more details sooner in the process. There is another waste going on behind the scenes here. But I’m going to save that for the end.
Back to the value stream map… Another waste I see in the flow is EXTRA PROCESSES. I’m reading between the lines here to describe this. The extra processes include the requirements being formally approved via email; UAT testing being done by different business users than the initial business owner; formal email approvals required for release to UAT, UAT testing signoff, production release (approvals by multiple people); and manual production release by a separate team.
I am not questioning the validity of some of these processes. Some of them are used for audit purposes. But I am saying that there are too many processes that DO NOT ADD VALUE TO THE PRODUCT. Thought should be given to how these processes can be reduced.
There’s one last thing. I said that there was another waste behind the scenes. It was something that affected every step along the way. That waste was TASK SWITCHING. Why did development take 60% of the lead time? Mainly because developers were pulled in too many directions, all of us working on more than one project, providing production support, and doing various non-project related tasks. This is WASTE. It is well known that task switching carries a productivity penalty. I have read in more than one book that that penalty is as high as 20%. Every time a developer has to switch between different projects, or switch from project work to production support, or gets interrupted to spend time on non-value producing tasks, he/she will lose up to 20% of their productivity. See the Poppendieck book for more on this.
Task switching is one of the most frequent problems I hear about from members of scrum teams. “I didn’t get any sprint work done today because I had to work on a production problem.” “I get interrupted constantly by people needing my help.” “I’m working on three different projects at the same time.”
What can be done about the problem?
The answers to that question warrant a fuller discussion. For now, I will say that scrum teams work best when they are allowed to focus more fully on a small batch of work in an incremental fashion. As managers grow in their understanding of Agile methodologies, they can better prevent the team members being pulled in too many directions. Additionally, each of us can learn better concentration skills and take practical steps to minimize interruptions. For example, I disabled my Outlook email notifications. Just seeing those frequent alerts distracted my attention.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” – the 12th principle in the Manifesto for Agile Software Development
To become more effective we must first see the waste in our team’s processes. Value Stream Mapping is a powerful tool to identify such waste. The technique can be learned quickly and put into immediate practice.
However, identifying waste is one thing. Eliminating it is another. Old habits die hard. Redesigning processes is not always easy. Changing company culture is even harder. But we can take small steps. As we become more agile in our thinking, we can make incremental changes to our processes and become more effective in delivering value.
If you give it a try, I would love to hear how our Value Stream Mapping exercise goes!