This post is about how I run a value stream mapping workshop as part of an Agile/Lean readiness assessment or as part of ongoing process improvements.

Value Stream Map’s are very useful for understanding how your current process works. My initial understanding came via Mary Poppendieck (books and training). Later I learned the details from the book Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA by Mike Rother and John Shook; it’s all about manufacturing but the principles hold.

Workshop is ~10 people x 3 hours

For this meeting, I ask for a cross-functional group that can define the steps involved with going from concept to cash. This group may be in the 5 to 15 person range depending on the organization. Depending on how many people you have you may want to split them into multiple groups. Groups can do the same or different processes. My rule is to get to as small a group as you can and still have enough knowledge of the process.

With regard to time – 2 hours may be enough for a small company while a large bank may require the full 3 hours.

Slides used to Introduce Value Stream Mapping

Below are the slides I use to introduce the workshop. Mostly you’ll just see pictures that I use to introduce the concepts, so you gotta know this stuff well. In addition to value stream mapping, I talk about Muri, Mura, Muda and have them think about the 7 types of waste.

View more presentations from Michael Sahota.

Explain how to create a Map

Before starting the exercise, I run through creating a value stream map with them so they get a feel for how it works and agree on conventions.

As people indicate what the steps in the value stream map are, I write up each step and create the legend shown on the left. It doesn’t really matter what process you use – the point of this part is to give them a feel for identifying each of the parts. Go through a few steps until you can see they are getting the hang of it. Remember to write the time on value added and waste stickies (missing in legend).

Size matters. Queue size, that is. It is important to show how much WIP (work-in-process) there is at each step. People often know things like: we have a product roadmap with 200 features in it or 9 features waiting for development.

Some teams may not feel comfortable identifying any activities as waste. That’s OK. They may not be ready for that yet.

Mapping Exercise

It helps to pick a concrete project that is typical for the organization. Something like an average feature, typical client request or urgent defect fix. This helps people move away from a conceptual process to talk about what actually happens in real life.

It is a good idea to warn people that they may be surprised with how things actually work. Taiichi Ohno, one of the founders of Toyota Production System, joked that it is good to have a poor starting place so there are easy opportunities to show process improvement.

During the exercise, I float between the groups to answer questions and make sure things are on track. After about 20 minutes the teams are usually cooking and can proceed on their own.

Once everyone is finished, each team presents it’s value stream map to the large group. Sometimes there are minor corrections, but these are usually fine details that don’t change the big picture.

Example Value Stream Map

Below is an example (click for a large image) of a completed value stream map for funded development at a 50 person product company. In this particular case, the company noticed that 5 days of planned work actually took 15 days (with rework) plus another 10 days of waste due to communication overhead.

Special enhancements:

• Along the top we have communication waste – this is the extra time needed to manage a project in a dysfunctional process that spans 9 months.
• Below the main flow we have rework arrows. Each arrow indicates the % chance that the work item needs to return to an earlier step. As can be seen, there are multiple return trips after reaching production.

Debrief with management

At the start, I explain the overall activity and its purpose. Together with some of the original authors of the map, we walk through the steps. I stick to explaining the Value Stream Map concepts and let others explain the content. Managers are usually surprised at how long it takes to complete work.

It is especially important to clarify that we are talking about the Lean concept of system efficiency - defined as time working on product/elapsed time. This will be unrelated to other measures of efficiency at the company.

The usual follow-up on this workshop is one to specify the desired future state. Of course, all of this is a great candidate for using the A3 technique.

Here is a very short (2 min)video where Selena Delesie and I reported back on a session at Agile Coach Camp Canada. This is what a group of 10+ of us came up with.

I’ll link to the writeup when it is posted.

Thanks to everyone who was there – it was a fun, intense and valuable session for me.

For years I have preferred Scrum as a starting place rather than XP since it is easier to adopt. One of the patterns of Fearless Change is to take small steps. Scrum is a much smaller step than XP. That’s old news. Lot’s of folks like to start with XP, that’s OK by me.

Probably a good thing to clarify at the start is that Kanban is part of the Agile family of processes.

Kanban is easier to adopt than Scrum

Way easier. Like almost trivial. Let’s see: no process change, no role change, no change in team structure. Just make the work visible. Wow! There is so much value in just making the work visible. Lot’s of little problems can be fixed and voila – productivity and cycle time gains.

Kanban uses Kaizen = Continuous Improvement

Kaizen is about continuous improvement. Define a standard process and then start improving. Take smalls steps. Get everyone involved. Kanban is a standardized process flow that starts with the existing process.

In the graph of performance vs time on the left, kaizen will result in improvements that will asymptotically approach the limit within that paradigm.

As teams mature, they may go beyond this into the place where Scrum/XP start…

Scrum/XP is Kaikaku = Radical Overhaul

Kaikaku is discontinuous improvement. It is about a revolution in the way things are done. It is also called Breakthrough Kaizen.

Can anyone say Scrum or eXtreme Programming? It changes work groups, job titles, roles, and project basics. For contexts where Scrum is a good fit, it is a high-value, high-cost game-changing move. James Shore has a great post on Kaizen and Kaikaku where he argues that this is a better starting place if you want a high-performance team.

What does this look like in terms of performance? See graph below. It looks like Virginia Satir’s Change Model.

In the Lean world, companies use both kaizen and kaikaku depending on circumstances as they are complementary approaches.

Why a gateway drug?

The gateway drug theory states that softer drugs (Kanban) can lead to harder drugs (Scrum, XP). This is a great metaphor because this theory has been proven as well as dis-proven. To quote David Anderson “we are only beginning to understand the differences between Scrum and Kanban”.

Do I believe in the the theory? I’m not sure that I care – as long as people are working to improve their work environments at a pace that works for them, that is good enough for me. For me, any Agile is good –  it does not need to be one particular style.

Let’s face it – lot’s of organizations are ready for a radical overhaul. For companies like these, Kanban is a great place to start. Getting off the sofa and going for a marathon may not be a good idea. For some it may be better to start by jogging around the block.

Other Perspectives

David Anderson has a contemporaneous post (go read it, it’s good) supporting the notion that Kanban is primarily focussed on continuous evolution until the organization has enough maturity for more radical changes.

Ken Schwaber is continuing the drum beat that Scrum is the one true path.

I first read Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising when it first came out many years ago as part of Scrum Toronto book reading club. It has been an important source of ideas that have allowed me to successfully adopt Agile at many companies. This is an essential part of any change agent’s toolkit.

Mihai Iancu has a wonderful mindmap to show the patterns in a visual an approachable manner. Thanks to Mihai for allowing me to share this with you.

Here are some of my favourite patterns:

• Do food – Create a relaxed setting and leverage cultural bonding that happens when people eat together
• Tailor made – Find the right solution for the people you are working with; every situation is unique
• Step by step – Take things one step at a time and build on successes

Please comment on yours.

Yves started the Agile Retroflection of the day project for 2010. Today’s question is “When would you choose to value process and tools over individuals and interactions?”

Strangely, I find myself in a situation where I need to place a very high value on process to provide shock therapy to a client that is in the whirlpool at the end of the waterfall.

It’s the usual software story of an over-full release with a fixed release date required by not one but two external customers. Add to this a chaotic process and broken telephone between functional groups. The interesting question posed by the client is this: “Is there anything you can do to help us?” (What would you say?)

Given the timelines and pressure, there is no way I know how to do Agile in a conventional way. So tomorrow, I am launching what Gerry Kirk and I called Guerrilla Agile – something light and tactical. To make this work, I will need to very directive in what needs to happen. The main goal of this phase is to get shippable software. A later phase is planned for a sustainable transition to Agile.

In terms of my training budget, I figure I have at most 3 hours. Here the emphasis will be on cross-functional teams and working together. So in this sense I am valuing people and interactions over process  - not the other way around. Perhaps the title of this post is backwards: maybe all the command and control around  process is just a smoke-screen so I can focus people on what’s important: teamwork.

P.S. Given all the passion and energy around Kanban and Scrum these days, I think it apropos to mention that we’ll get started with Kanban since even 1 week long sprints would be to big  a challenge in the current environment.

Yesterday, Gerry Kirk and I kicked off a 4 day Agile Assessment with a presentation aimed at taking some of the uncertainty out of Agile and providing context for the transition/assessment.  See slides below.

The values and agile project life cycle slides were not show; instead, Gerry did a live diagram construction (see photo below). This approach worked well and we got lot’s of great questions.

One of the questions was about Agile contracting.  There is a good presentation I commented on in a recent post.

Joseph Pelrine gave a really interesting session on “Coaching Self-Organizing Teams” at Agile 2009.  (Mark Levison wrote about the pre-cursor to this session last year.)

There were a number demonstrations:

1. The first was of self-assembly (orange) and illustrated through people getting into an elevator.  They have no common goal and there is no change in behaviour.
2. Another was of people who were given the simple instructions (brown) of don’t bump, stay at the same speed and converge to the centre.  This demonstrated the idea of the team as a complex adaptive system where simple rules can lead to emergent behaviour.
3. Another was to ask people to clap there hands and then see how long it takes before everyone synchronizes.

He then went on to share some interesting ideas such as Core Group Theory – where the purpose of a company is to satisfy a core group of people.  To influence and organization, you need to know who they are.

Then things got really interesting.  Joseph likened self-organizing teams like making vegetable soup – the trick is to get the temperature right.

Checkout the heat gauge below.  As you can see there is a green zone where things are really cooking.  But beware the danger of too much heat (burning) and the cooling down phase where bad things can happen.  Gelled state is stable but there is not much innovation.  It is stable, but heat is needed to get cooking again.

What are the ways we can apply heat?

Stove #1 is about performance planning for individuals where challenge needs to be balanced against skill.  For a given skill level there is a range of challenge that can lead to a state of flow. With this model, there are two ways to climb in proficiency:

1. People can surf the top line and take on challenges beyond our capability.  Think of a snowboarder pushing boundaries of what they can do.
2. People can follow the bottom line and develop skills before taking on new challenges. This reminds me very much of Deliberate Practice – a key to Craftsmanship.

The next simulation was to have a group of people sit in a circle and pretend they are a development team.  The people on the outside interrupted them to ask questions.  Even when the team resisted, they felt pressured.

Stove #2 is to use the ABIDE model by David Snowden. (The pre-requisite is the have a context and a container.)  We need to think about how to stimulate the social network.  Here are some hooks:

• Attractor – Pride, money, quality, charisma
• Boundaries – Team boundaries e.g. traditional Dev/QA
• Identities – Role, responsibility
• Diversity – Gender, age, skills, personality
• Environment – Team room, desks, computers

We can make changes to any of these to get a shift in team dynamics.

Like this?  Joseph has some online talks on InfoQ:

• Coaching Self-Organizing Teams speaks to self-organization and the cooking metaphor.
• Dealing With the Organizational Challenges of Agile Adoption is about models for understanding conflict when adopting Agile.

I wrote this to help explain to the different types of approaches companies adopt when getting started with Agile: books, training or coaching. This is based on my experiences, so I’d like to hear from you. Permanent page is here.

1) Do it yourself

It’s possible to get started with Agile the way many people did after the Agile Manifesto was published in 2001: buy some books and start reading them. Today, there’s a lot more to choose from. As well, there is a lot free online learning material: articles, videos, blogs. I have provided links and bibliography under Agile Learning Resources.

2) Train the team and kick start the project

A good way to get started with Agile is to find an Agile coach to train and launch you project. It’ll take 2-3 days to get a couple of teams trained on-site. (This will be a lot cheaper than public training). Depending on the size and state of the project, it may take 3+ days to launch or restart the project using Agile techniques.

3) Hire a coach to transition to Agile

The best way to get started is work with an Agile coach to get your team operational and self-sufficient. You’ll want start by training your people and kick start your project (as above). It will take a while before your team is able to fully internalize the values and principles. Depending on how much attention you pay to technical practices, these can take a while to put in place. This approach involves having a full-time coach (or even a pair) work with your teams to accelerate learning and avoid pitfalls. Your coach will work with you to set transition objectives, so you’ll know how things are going and know where they are adding value.

Comparison of Alternatives

Other perspectives

1. CIO Magazine’s 7 Agile Leadership Lessons for the Suits
2. George Schlitz has an excellent post that explains why Professional Teams Need Coaches
3. Scrum Alliance article on Top Ten Organizational Impediments to adopting Agile
4. Presentation on Agile Adoption Patterns And Antipatterns

Below are the slides from my first presentation at AgileTourToronto. This is a new one I prepared to communicate Agile to C-Level Management.

Agile Executive Briefing – Situational Assessment and 50,000ft view of Agile

The first part of this presentation is a situational assessment of typical challenges in IT project delivery using the SCRAP (Situation, Complication, Resolution, Action, Proof) model. This is essentially a business case for Agile. So if you are looking for ways to get buy-in for Agile, then this is a good place to start.

The second part of the presentation shows you what Agile is from 50,000 ft. From this high up, we’ll be covering the essential elements from a business and management perspective. We’ll cover what Agile is, what it does, how it works and what it achieves.

Each of the parts can be used independently so you may use the first part to get buy-in or the second part as a high-level introduction.

Slides on Slideshare

David Hussman gave a great session on coaching called “Coaching and Producing Value” at Agile 2009.  (Link to short description).

The first part of the workshop was an exercise for us to describe how we see ourselves as coaches.  My vision (top left in black below) at the time was “Change Agent … by the numbers”.  I know flexibility and adapting is good … and my favourite place to go in an Agile transition is Scrum.  Scrum is pretty structured.  For those new to Agile, this is a good thing.  On the other hand it can make adoption more difficult and increase resistance.  But it puts in the basic engine of change that can go a long way.  The advantage of clear rules and names is that it makes it difficult for organizations to water down Agile so that it becomes the same old process with a different name.

I loved this session since it comes at  adoption in a totally different direction… using the metaphor of producing music.

Most of the session was about Pre-Production. Check out the photo below.  David stresses the importance of understanding out clients’s world so that you understand how to lead them to a better place.  One key element of this is not being prescriptive - tell them about something that worked in another context and see if it resonates with them.

The second phase is Finding a Groove.  This is about helping the team find out what works and what doesn’t.  Again David, talked about story telling as an indirect way of sharing knowledge and suggesting ideas.

The final phase is Keeping the Band Together.  This is all about keeping things fresh through questioning.

All in all, this was a great session for me.