Value Stream Management Explained
Key Points
- Value stream management (VSM) is a holistic approach that treats every step from a business idea to the customer—development, testing, analysis, and delivery—as a single, continuously managed flow.
- A typical value stream includes idea intake, prioritization, development (often with design and build phases), and extensive testing, while also handling bugs and unplanned incidents alongside planned work.
- By visualizing this flow, teams can spot where work piles up—commonly in testing—allowing them to balance capacity, limit work‑in‑progress, and add buffers as needed.
- Development and delivery managers use VSM insights to assign tasks realistically (e.g., one task per developer), prioritize fixes, and optimize the overall throughput of the software delivery pipeline.
Full Transcript
# Value Stream Management Explained **Source:** [https://www.youtube.com/watch?v=Yto8nUeki-s](https://www.youtube.com/watch?v=Yto8nUeki-s) **Duration:** 00:09:14 ## Summary - Value stream management (VSM) is a holistic approach that treats every step from a business idea to the customer—development, testing, analysis, and delivery—as a single, continuously managed flow. - A typical value stream includes idea intake, prioritization, development (often with design and build phases), and extensive testing, while also handling bugs and unplanned incidents alongside planned work. - By visualizing this flow, teams can spot where work piles up—commonly in testing—allowing them to balance capacity, limit work‑in‑progress, and add buffers as needed. - Development and delivery managers use VSM insights to assign tasks realistically (e.g., one task per developer), prioritize fixes, and optimize the overall throughput of the software delivery pipeline. ## Sections - [00:00:00](https://www.youtube.com/watch?v=Yto8nUeki-s&t=0s) **Value Stream Management Primer** - Eric Minich outlines a holistic approach to managing the entire software delivery flow—from idea prioritization through development, build, and testing—to optimize the end‑to‑end value stream. ## Full Transcript
hi I'm Eric Minich with IBM cloud and is
good idea going around the DevOps
community right now
value stream management it's a big topic
I want to explain it get you that primer
so you understand what everyone's
talking about fundamentally we know that
in software delivery we're trying to get
good new ideas from the business out to
our customers the value stream
management is focused on the idea that
everything that happens from idea to
customer is important it needs to be
managed in a holistic manner so rather
than managing our developers separately
from our testers and our business
analysts etc we want to optimize the
flow across all of those groups so let's
start by putting it together an example
flow an example value stream and then
we'll see how this works so if we have
an idea that's coming in we might need
to prioritize that against other work
right and then once work we has been
decided to be dealt with we're gonna
develop it alright we're gonna hand it
to our developers will code it up maybe
there's a design cycle in here then you
know maybe we've got a process where we
do Bilt's right and we'll build it then
maybe we've got some test environments
so we run a whole bunch of tests against
it I'm just gonna group all of that
together here as test right so we've got
ideas most groups I talked to you have
more ideas waiting to be prioritized
then they've got time to do maybe we've
got some handful of developers and so
we've got some number that are coming in
hopefully we don't have too many waiting
to be built almost always we have a lot
of things under test right now
so there's a lot of things being tested
I've been on the happy path
of ideas probably also have bugs coming
into so you know we've got a prioritize
which bugs to fix which incidents to
deal with we've got some of those in
here we've got fixes being tested as
well so we've got some mix of planned
and unplanned work and we could draw a
flowchart here to say that work kind of
flows like this for us in this really
simple example okay so this is my value
stream I have two sets of inputs one
straight path grossly oversimplified but
now I can see some things right I can
see things tend to not pile up and build
they do pile up in tests this is about
as much capacity as I have for
development now I want to start
optimizing this and there's a lot of
places we go our attentions likely to go
to testing if I'm a developer a
development manager right now
and I'm looking at this and I see oh
we've got seven things we're working on
that might be great but if I only have
four developers on this squad I might
say well that's more than one each that
seems a little odd I probably only want
to be assigning one task at a time to
people and then maybe I've got you know
some buffer here of work that's ready to
be worked on am i assigning too early
and I need to add that buffer or what so
this was an example that a team I worked
with had and they looked at this and the
reason was they actually had developers
were only working on one thing at a time
but they were also including things here
that were waiting on code review and so
their real process was actually come
down to code review and then do a merge
into build right so it wasn't that right
it's like this and when they did that
you know couple issues would come off if
we had five developers you
they'd be pending down here now where
this got more interesting is you also
want a time how long everything sits
here all right so maybe on average it
takes eight weeks for something from
when it's an idea stage until it gets
worked on it's in development for one
week it might be you know one day to get
built testing might be six weeks and in
this group this code review they looked
at it and it was a week and the moment
they surfaced that the whole development
team started yelling at each other
because the senior developers were like
look I I get a lot of code reviews I
need to do it takes a while to get to
them all the junior developers like
you're always ignoring us you're not
getting this done so this is like
tension within the development team that
was surfaced when we said hey it's not
just the senior developers hate one
junior developer it's not just you
everybody's waiting and what they ended
up doing is they found ways to have all
the developers to code reviews for each
other and they were able to eliminate
this from one week to under 24 hours
right so maybe one day and that's nice
because right there in that moment you
were able to alleviate a lot of strain
on the development team and speed
overall time to market by about a week
right from a week to a day that's pretty
good now at a more macro level you're
probably focusing on the six weeks of
testing right because you've written
code you have something useful it's
getting bogged down here you're gonna
look under the covers here to see what
the issues are is it setting up test
environments is it a lot of manual
testing is it a change review process
that's hanging off after testing similar
to how code review is after development
that that's not captured here you want
to get under the covers understand that
and really zoom in on these big
slow areas the eight weeks that things
are on average waiting before
development starts that might be that we
don't have enough developers all right
and then if we open that up we'd be able
to handle more but we'd also need to
take a hard look at the test team to
make sure that they could keep up with
more changes coming in it looks like
they probably can't so we've got a team
that's delivering relatively slowly so
from when they say yes I'm gonna start
working on this it was basically six
seven weeks to deliver it a lot of that
time in testing so we'd focus here we
would look at you know if the business
wanted more maybe we need to add some
developers but it's not going to be free
and then only once all that was dealt
with do we come back and say okay a
prioritization the things are waiting in
the queue a long time before they work
with kind of work out how does that look
for really high priority items are they
also taking eight weeks or the high
priority items able to be seen triage
and gotten to development really quickly
and so that you know they're they're
getting out the door to our customer
this is the idea of value stream
management that we want to look at this
as holistically as possible understand
our flow so that we can improve we're
gonna do some key metrics here we're
going to be looking at the overall
throughput the volume of change that's
going out the door
ideally we understand the value of that
we're also going to be looking at the
probably the cycle time so from when we
start development until it gets to our
client alright the seven weeks as well
as the overall average lead time from
when we have the idea out to it getting
to our customer so the seven weeks plus
eight weeks 15 weeks to do that so
that's the key idea of value stream
management let's look at this let's
measure it let's understand it
and if we need to move people around to
relieve our big bottleneck let's go do
that so I hope this was a good
introduction to value stream management
thank you if you have questions please
drop us a line and if you want to see
more videos like this in the future be
sure to LIKE and subscribe