The value stream is the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support.
Value streams are what they are, you don’t specify them. There are several ways to change them, however, including changing:
what goes into them
how people collaborate
the order of the work (e.g., test-first)
how teams are organized, the size of the work done
the amount of work being done by the people in the value stream
The idea is to remove handoffs, delays and handbacks in the value stream. Doing so will lower cycle times and increase process cycle efficiency resulting in quicker time to market and realization of value.
Back in 2006, I would always incorporate value stream mapping into the training or engagement. Over the years, however, as Scrum teams have become predominant, I have found doing to to be of less value. Not because value stream mapping isn’t important – it is, but because people don’t seem to be able to do it well.
To be clear, I am referring to Lean’s (not SAFe’s) definition of the value stream – the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams and on through final delivery and support. You can’t define value streams – they are what is. You can, however, map them, define a “to be” value stream and you can improve them.
An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):
Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
I’ve been having a very interesting two weeks. I would like to say that whenever I go into a client, I am always on, and always get my clients to see new opportunities. But I’d be lying.
However, for the last two weeks, that’s been what’s been happening… with five clients. While I feel I’ve been “on” and empathetic, that only explains half of it. Something else has been going on.
Here is what I think has been happening. In all of the cases, I started out with:
Depicting a value stream representing what they’d like to happen
Adding their team names, relating this to what people were doing now (making it less theoretical)
Identifying the client’s problems in this ideal flow
At this point, they started asking how to solve their problems. Often, they are stumped about how to work with non-Agile teams or how to create predictability. They would ask, “How can you do this in Agile?” “What do you think about LeSS?” Essentially they were taking solutions they knew, or had heard of, and were trying them on.
It’s like shopping for clothes. Every company is shaped differently. There may be lots of clothes (solutions) out there that don’t always fit. That’s when you want to learn to be a tailor.
This is the first of a series on the implications of these insights.
The reason I am not a fan of frameworks is that they mostly have us focus on activities that are proxies to what we need to do to achieve what we really want to do – realize value quickly, predictably, sustainably and with high quality. Lean provides us insights on what to directly work on. Consider these 5 aspects of product development:
Focus on what’s of value to the company. Much of this will be providing better value to the customer some will be on how the organization builds them. This must be quantified for it to be relevant since everyone in the organization must see these driving factors. Use OKRs (objectives and key results) as a basis with strategies and initiatives being spawned by them.
Understand your value stream network details the steps and who does them that it takes to actually create the value.
Focus on lowering the cost of delay which is the time lost to delays in value realization. Organizational structure, development method, size of the work to be done and how people collaborate are significant factors.
Manage the flow of work and the ecosystem through which all of this flows. This includes when work is started and how decisions are made for how people work together.
2) you can’t predict if attempts to improve things will work
But this doesn’t mean there aren’t best practices in complex systems. In fact, it means in complex systems you must look for the few best practices there are.
By a “practice” I mean something that:
1) takes little energy to do
2) simple enough that everyone can do them
3) provides value enough of the time to make them worthwhile
Here are some Agile Best Practices:
when given a requirement ask “how will I know I’ve done that?”
before starting a new task see if there’s a task you can finish or help someone else finish
have explicit work policies (i.e., have team members know what each other is doing)
While there are others, let’s consider the value of these. The first helps avoid misunderstandings. The second shortens development time. The third helps avoid misunderstandings.
All of these are clearly valuable. All too often we worry about managing big things, and overlook the little things that can make a big difference. While we can’t control complex systems, we should do what we can to avoid chaotic events.