Value Stream Mapping

Loading...

From the course by University of Minnesota

Lean Software Development

14 ratings

University of Minnesota

Lean Software Development

14 ratings

Course 3 of 4 in the Specialization Software Development Lifecycle

While scrum and XP were transforming the software development industry, there were another set of ideas (derived from lean manufacturing and Six Sigma) that started to influence software development methods. These ideas around Lean Software Development forms the foundation of number of agile methods. In this course, we will explore lean concepts and cover some of the common Lean methods and techniques like Kanban, Value Stream Mapping, etc. In this course, we will also learn techniques like Lean Startup and Design Thinking that can help team learn about user and market needs much faster and cheaper. As part of this course, you will also apply the knowledge gained in this course to fictional case studies. These projects will help you gain experience to confidently apply these techniques in real world. At the end of the course, you will be able to apply lean techniques / methods to software development. You will also be able to apply methods to learn about your users and market needs much faster and cheaper.

From the lesson

Kanban, Value Steam Mapping and Kaizen

In this module we will learn about Kanban and other Lean practices like Value Stream Mapping, Kaizen etc. You will gain the ability to participate effectively in using these tools and practices.

Value Stream Mapping14:37

Meet the Instructors

Praveen Mittal
Adjunct Professor
College of Science and Engineering

In this lecture, we're going to learn about how do you create a value stream map

for a software development process.

So to create a value stream map, it's basically to map out

all the activities of the process that you want to analyze.

And one of the tip is to go to the place where work is happening, rather than just

sitting in a room and just mapping out all the steps, because you will realize

that a lot of times you will miss a lot of steps that actually happens at the work.

So the recommendation is that you go to the place where the work is happening.

And as you're watching the work, you start noting down the activities and

how long does it take.

So you identify what of the steps are value added, which means

that they're adding value to the customer, and what of which of the activities

are not non value added, which means not adding value to the customer.

And you list or you identify who is involved, what kind of,

how long does it take, and what work is involved.

So you kind of list and identify all of those things.

And in terms of syntax and terminology, so

let's take an example, let's say the value stream involves four activities.

Activity A takes 5 minutes and it's a value added activity,

activity B takes 5 days and it's a non value added,

activity C is a gain of 1 hour and it's a value added activity, and

activity D is 1 day and it's a non value added work.

So let's say our unit that we are going to use to show the time is in minutes.

And we assume that 1 day is equal to 8 working hours.

So we are going to treat 1 day equal to 8 hours.

Of course, 1 hour is 60 minutes.

So, let's say if the activity B says that it is going to take 5 days,

then in minutes, it's going to be 5 days times 8 hours

per day times 60 minutes, so that's a total of 2,400 minutes.

So if you were to create a value stream map for this A,

B, C, D activity, it's going to look like something like that.

So all the activities that are value add, we're going to show on the bottom,

and then all the non value added activity, we show on the top.

So as you can see, the first activity A was 5 minutes, so

we are showing that the five minutes as the first point here,

and then the activity B was 5

days which is 2400 minutes, and then activity C is 1 hour, so

it's 60 minutes, and then activity D is 480 minutes.

So, 5 minutes, 2400 minutes, 60 minutes, and 480 minutes.

So, that'll be the value stream map for this small value stream.

Now, another key metrics that is used in value stream is called

process cycle efficiency, which defines the efficiency of your value stream.

So, it's equal to value added time, divided by the total of the cycle time.

So as I talked about, value added time is the time spent in doing things that add

value for the customer, and the non value added time is the time spent in doing

things that didn't add value for the customer.

And the cycle time is the total time taken for the value stream.

So in this case, the process cycle efficiency will look like this.

So we have the 5 as the value added, and

the 60 as value added, so we added 5 and 60.

And then, the total cycle time was 5 plus 2,400 plus 60 plus 480,

so that's right here.

So if you do this calculation,

it'll say that it's about 2.2% process cycle efficiency in this case.

So now let's take an example and see how we're going to calculate.

We're going to go through and create a value stream map, and

we're going to calculate the process cycle efficiency.

So let's say there was a company called ABC HealthCare Corporation.

It has about 15,000 employees.

The IT department for this company has about 2,000 employees.

There is a group called Database Support Group, DSG, that has about 30 employees,

and there are about 120 application development teams in this organization.

And each of these 120 application development teams,

if they require any database related activities, like creating a schema, or

creating a table, or adding a column, or any of that kind of activities is needed,

they interact with this database support group to do their database work.

And what we're going to do is we're going to create this value stream for

the work of Database Support Group.

So all the requests that are coming to the Database Support Group,

what are the steps, what are the process, how long does it take?

Because it was kind of a bottleneck for the organisation, and

they wanted to take a look at how long does it take and

if they can make that process a little bit more efficient.

So let's take a look at the value stream map.

So, let's assume we went to the place where the work was happening, and

we were following the activities that are happening on the ground.

So here is work that, let's say, we found out.

[COUGH] The developer submits a ticket to get a database work done, and

they'll specify what they want to get done.

Then ticket was waiting to be looked at, and prioritized, and that averages to

be of about 5 days, and then they are key managers from different departments,

who will attend this weekly prioritization meeting.

Because all of these application teams are submitting requests, so there is some kind

of prioritization required as to which one to do and not to do.

So, key managers from different teams were getting together,

doing this weekly prioritization meeting together for about an hour.

And then, the prioritized items wait for

being assigned to a database administrator, so that's about a day.

So after the prioritization has happened, within a day, the items were assigned to

the actual database administrator who is going to work on it.

So the prioritized item is finally assigned to the database administrator,

and that activity takes about 30 minutes.

So if you were to create the value stream map for this steps so

far, we're going to look something like this.

So as you can see, 5 minutes to submit the ticket,

5 days to wait in the queue, 60 minutes, which is an hour, to prioritize.

And then, again, another day for it to be in the queue for to be assigned.

And then, 30 minutes to actually assign the item for

a database administrator to work on.

So let's continue.

So after that, once that is assigned, the database administrator looks at

the request and sends an email to request additional information

in a template specifically designed for that type of request.

So, the database administrator has looked at the request and

said, I need, this is this type of request, so

I need this additional information from the application developer.

Then the application developer provides the information requested,

that takes another 5 minutes.

And then, request again, wait in the queue to be picked up again for 3 days.

And then, database administrator picks request and

set up meeting with the developer for additional information, again 5 minutes.

So, so far, let's see what the additional story value stream map would look like.

So in this case, we started with 5 minutes to send the template,

another 5 minutes for developer to provide the information.

Now, this could be treated as a value added work,

but I treated that as a non value added.

But you can put both of these together, add a value, add an activity, and

then, again, you're waiting for 3 days again so that's 1,440 minutes.

And then, the last is the 5 minutes for administrator to again pick up the request

and setting up the meeting with the developer.

Then continuing, so now the developer waits for the meeting, so

that's again average of 2 days.

And then, developer and database administrator

meets to finalize the exact requirement, and then, the database administrator

puts the request back into the queue to be worked upon.

Because he is currently working on some other request that he or

she is going to finish, and then come back to this request.

And then, the database administrator works on this request and

informs the developer once done.

So again, if you continue our value stream map,

it's going to be developer waits, so that's about 960 minutes,

and then 15 minutes for them to meet and finalize the requirements.

Then again, waiting for another day, which is 480 minutes, and then finally,

the 30 minutes to finish the request.

So as you can see, we went through the whole process on the ground, and

we created the value stream map for this whole process.

So now, let's calculate the efficiency of this model.

So process cycle efficiency is value added time divided by total cycle time.

So as you can see, the value added time was 5 minutes,

60 minutes, 30 minutes, 5, 5, 15 and 30.

So we add those 5, 60, 30, 5, 5, 15 and 30.

So that totals up to 150 minutes.

And then, the total cycle time is all of this plus 2,400,

480, 5, 1,440, 960, and 480.

So if you add all of them, it comes out to be 5,915.

And that means the process cycle efficiency is 150

divided by 5915, that comes out to be 2.5%.

So then, the next question is how can we get better?

Can we improve?

And so, just without making any major change,

I think we can improve the performance of this team.

So what can we do?

So I think one thing we can do is,

as you saw that first the developer was submitting a request.

And then, later on when the database administrator was finding what kind of

request it is, the developer was sending another template for

the developer to fill.

If you can merge these two together, so that when

a developer is submitting the ticket, it says what type of request are you filling.

And then, shows these additional fields for the developer to fill in, so

that we can get the whole information in one request.

So, instead of 5 minutes, maybe it will take 10 minutes, so

we added the 10 minutes here.

So no major change, just merging the two requests into one.

And then, it'll stay the same ticket waiting to be looked at and

prioritized for 5 days.

But then, all the key managers are getting together.

Now, in this meeting, not only should we do the prioritization,

but we can also assign the database administrator right there.

And so instead of 1 hour, maybe it will take 2 hours, but

at least we'll get the whole work done in that one meeting.

So, if you look at the value stream map for this process, the improved process,

It takes 10 minutes, then it takes, again, the 5 days, which is 2,400 minutes.

And then, it's going to take 120 minutes, which is 2 hours to prioritize and

to assign it to the database administrator.

Then, we don't need to do these two steps, the database administrator sends an email,

so I cut those two steps.

And then, the request is going to, again,

wait in the queue to be picked up again at the same time, 3 days.

Because we don't want to make any major change,

just simple change without impacting anything.

And then, the database administrator picks up the request and sets up the meeting

with the developer for additional information, so that's another 5 minutes.

So again, what's adding here is this 3 days, which is 4,400 minutes, and

then, the 5 minutes for the database administrator to set up the meeting.

Then, developer waits for the meeting, again 2 days, we're not making any change.

But then, after that, why don't we merge finalizing the requirements and

doing the actual work right there in that meeting?

So that if they have any additional question,

it could be resolved right there, and they can be just done with it.

So developer and database administrator meets to finalize the exact requirements

and works on the request in the meeting itself.

So in 45 minutes, instead of 30 minutes and 15 minutes,

they just finish the whole thing together.

So again, then you don't have to do these two steps separately.

So the value stream map will look something like this.

2 days to wait for the meeting, and then 45 minutes to get the work done.

So as you can see, we significantly simplified

the value stream mapping, or value stream map, or the process.

So let's see if it really helps in the process cycle efficiency.

So process cycle efficiency, again,

it's the value added time divided by total cycle time.

So in this case, the value added time is 10,

120, 5, and 45, so that totals up to 180.

And the total cycle time is all of these numbers and 2,400,

1,440 and 960, so that totals up to 4,980.

So the process cycle efficiency would be 180,

divided by 4,980, so that comes out to be 3.6%.

So as you can see, without making any major change,

without changing the wait time of 5 days or 3 days,

we were able to improve the process cycle efficiency by at least 1%,

so it's 3.6%, but can we improve any further?

I think we can.

So some of the things we can look at to improve this further

is why does it take this 5 days?

Can we reduce that time?

Can we reduce these 3 days wait time?

And can we reduce these 2 days of wait time?

So I think the next step could be to work on these three items, and

see if we can reduce those times, even by a day in each,

can significantly improve the process cycle efficiency.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play