Originally published on SDTimes.com
There is a lot of talk these days about value stream management. Much of the hype is about getting the right VSM Platform. It’s about the tooling. I try to cut through the hype in my post What Value Stream Management Isn’t. In that post I make the point that value streams exist whether you are aware of them or not. You don’t have to understand what value stream management is to have them. A thought I want to explore here is that it’s difficult to manage your value streams effectively if you can’t see them, can’t comprehend them, or aren’t aware of them.
What helps?
- Value stream mapping
- Make work visible
- The Kanban Method
- Someone tasked with the duty to manage the value stream
In every organization, there is someone who understands how work gets done in that org, in part if not in whole: the flow of materials or product, or the flow of information and work orders. The CIO is likely to understand the big picture, but is less likely to understand the details of how one particular team is using scrum or kanban. One person might understand intake from sales prospects. Another might understand intake from support. Another might understand the process of ideation, solutioning, hypothesis development, and prioritization through product management. Another, the release/sprint planning and development processes. And so on.
Therefore, the value stream is in the eye of the beholder. Value streams, being abstractions, can overlap or be composed of other value streams. For example, there is a high-level abstraction of the value stream for an entire product or product line that is composed of (usually) more detailed abstractions of values streams at lower levels in the org. Examples of the lower level abstractions might be the product ideation process and the engineering process.
Given that different people have different views of the value streams, and potentially conflicting improvement objectives, it is good to put some effort into a shared vision of these streams and alignment on improvement goals. Alignment on goals will be in a future article. For this, I’m going to focus on getting a shared understanding of the streams in the first place.
Value stream mapping
A lot has been written about value stream mapping, including this blog post: The Value in Value Stream Mapping. It’s great if you can get a few people, who care, in the room to do the mapping. Some orgs don’t have many people with the interest or the time to do such a thing. If that’s the case, do it yourself. Ask questions. Show your map to other people along the way. When I’ve had to do it this way, I’ve found that purposefully putting in something that I know is wrong (when I don’t yet know what the truth is) is a sure-fire way to get someone to chime in about how it really works.
Value stream mapping is not value stream management, but it enables it.
After you create your map, or as you do so, it’s helpful to test it. There are a couple ways to do that, both kind of similar. One is to take one work order, one completed piece of work, and walk it through the map. Ask if it actually followed that process as mapped. There might be some detail that’s abstracted away in the map. That’s ok. And there might be exception cases that you feel you don’t need to map. That might be okay, depending on how rare and how disruptive that exception is.
Make work visible
Another way to test the map is to make all the work visible. I’ve seen organizations where each team tracked their work in a different way. I’ve also seen cases where each individual tracked their work in their own way, and in some cases where work wasn’t tracked at all. I’m not saying that all teams in an org should track work the same way, though that can be helpful. But people on a team probably should use the same approach. If they don’t need to, then they probably aren’t really a team, but more of a work group or loosely grouped set of people in which the whole is not greater sum of the parts.
Suppose you have a team where some work is “kinda sorta” tracked in email, pieces of paper on their desk, phone calls with no record, personal Excel documents or OneNote pages, etc. (I.E., not in a ticketing tool or physical kanban.)
One way to make such work visible is to have each team put all their work on big sticky notes on a wall, organize them from left to right by time/state/stage, then talk about what those stages are and how many stages you need to model in your kanban. You can keep this work visible on that physical kanban, or move it into an app. It’s great to work with a physical kanban if you can, but there are many applications out there for electronic kanbans. This process creates great discussions about what the process actually is, and should be, or what we desire it to be.
That process in itself is an aspect of managing your value stream: Understanding it; Thinking about it; Reasoning about improvements and future state.
The Kanban Method
Many organizations use a kanban to make work visible, but they stop there (at making work visible) and they don’t implement the rest of the Kanban Method (Anderson) which is all about improvement. As good and important as making work visible is, it’s only 10% of the job.
Too many organizations think of things like Scrum, kanban, and SAFe as a magic bullet. They do cargo-cult. They don’t really understand the reasoning behind the method, the pre-conditions in which such a process or framework or approach would be applicable (or wouldn’t), and what makes it work. That would lead to a mismanagement of a value stream.
To really manage your value stream with the Kanban Method, you have to do the rest of the method. This article isn’t to cover the whole thing; after all, there are several whole books on the method. But here are some highlights.
Now that you’ve mapped out the value stream and made your work visible, have conversations with your upstream and downstream neighbors to make process policies explicit. What I mean by this is to talk with those who feed work into your value stream and who accept work output from your value stream. Talk about what success looks like, what quality looks like, what good communication and collaboration looks like. Discuss SLAs. Agree how exceptions, expedites and errors should be handled. Get agreement when everything is going well, and you’ll get better cooperation when some exception happens. That is value stream management.
Limit the amount of work you have in process at any one time, and measure and manage the flow of work. You want work to flow smoothly and quickly. Limiting WIP is a way to achieve that. That is value stream management. It’s about having policies about WIP limits. It’s about understanding and improving the lead time through your value stream.
Someone to make all this happen
Every organization needs to identify someone with the explicit duty to manage each value stream. Call it a value stream manger, an agile coach, a Director of Something, a Process Improvement Czar, or anything you want. Give the role any name, as long as the responsibility is clear.
Now, I do believe in the importance of “Leadership at all levels” as explained in the Kanban Method. Leadership at all levels means that everyone needs to take responsibility for the value stream, to identify and implement improvements. “All levels” really means all levels, from top to bottom. “At all levels” includes the value stream manager. Organizations need to be careful that people don’t feel as though the value stream manager is the only one responsible for value stream management. Nevertheless, such a role is necessary to encourage others to be involved and to drive improvement.
Conclusion
Value stream mapping and the Kanban Method are excellent tools to help you see your value streams and to gain a shared understanding about them in your organization. You need both leadership at all levels and someone identified to be responsible for improvement in each value stream. If an organization isn’t doing these things, it’s hard to believe that they are managing their value streams. Yes, even if they are using a value stream management platform. Value stream management is human.
Andrew Fuqua is the ConnectALL SVP of Products. He joined ConnectALL after a long-standing career as an Enterprise Transformation Consultant. Andrew has an extensive career of 30 plus years of varied experience — held positions in consulting, management, product management, and development. Andrew is an active contributor to the Agile community, an established speaker, influencer and a published author.
