Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August

Triangle Model

Selecting and delivering the most important work is a critical success factor in Agile projects. But how do you know what is important? Unless you are psychic, some help would come in handy. Consider the diagram below to help make sense of the wide variety of strategies and tools.

We explain three different perspectives: Company, Customer, Team.

Team Perspective

The product backlog needs to be structured so that it informs the team of the vision and the work. Whenever the company or the customer priorities are not clear, the team will need to rely on general information and it’s common sense.

Theme Scoring & Screening - Relative or numerical weighting based on criteria (Mike Cohn)

• Video of Mike Cohn at Agile 2008 and Slides
• Agile Estimation and Planning (book)

Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)

• Jeff Patton’s blog
• Presentation

Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature

• Software By Numbers (book)

Customer Perspective

The product backlog prioritization is done from the customer’s perspective, from the perspective of whoever is paying for the product in the first place, whether this customer is internal or external to the company doesn’t really matter. What is most valuable to the customer will be on top. Techniques focussing of this view require strong product domain knowledge, and a good understanding of the impact of specific features on the business.

Kano Analysys - Structured Questionaire to determine feature relevance: Mandatory, Linear, Exciter

• See materials of Mike Cohn from Team Perspective: Theme Scoring & Screening

Innovation Games® - 12 Games to better understand your product and what’s important (Luke Hohmann)

• For Speedboat® and Buy A Feature® + more - innovationgames.com and Book

Company Perspective

Companies need to find a balance in distributing the effort over multiple customers and/or products. But they also need to take the company and product strategies into account, deprioritizing features that might be very valuable for customers but aren’t in line with the company’s vision. As well, this takes into account stakeholders other than customers and sales – support, professional services, etc.

Company and Stakeholder Strategy

• Aligning and Balancing Your Backlog
• Blog: Why Prioritizing Your Product Backlog for ROI Doesn’t Work

Business Value Game – Simulation to illustrate how organizations can define their own business value model.

• Game instructions

Allocation Model - helpful to balance priorities with divergent or competing interests

• See example by Alisson Vale: Slides 40-49

Where to go from here?

The most common questions we have gotten after presenting these techniques are “How do I decide where to start?” and “How do these work together?”

These are complementary techniques and are used to solve related problems. Our recommendation is to start with the area that is the biggest challenge for your project. Maybe this means talking to stakeholders you normally don’t talk to. Maybe it means putting a Story Map up on the wall. It depends.

Slides

A friend and fellow Agile coach – Jason Cheong-Kee-You – told me about this approach to get more out of books. It is one of those little nuggets that help make every day life go better. Thanks also to Allister McKinnell for starting the chain reaction.

The purpose of this post is to share my key learnings from the book: the goal of reading and how to skim. No effort to represent the whole book.

The Goal of Reading

Adler argues that the goal of reading is to learn and that there are 4 elements that need to be satisfied. Consider the diagram below.

In order to decide what parts of the book you believe, you need to understand what it is suggesting and how that information is supported. As I write, I think about confirmation bias and that we need to challenge ourselves to keep our minds open.

Perhaps the most intriguing part is to explicitly think about is: what impact does the book have one you? What are you going to do differently as a result of reading the book?

How to Scan a Book Quickly

It takes time and energy to read and learn from a book. Adler introduces an approach called inspectional reading (systematic skimming or pre-reading) to provide a mechanism to decide if the book is worth reading. The diagram below outlines which bits of a book to focus on.

In 20 or 30 minutes, you can get an idea of what the book is about and what its parts are. Even if you think you are going to read the whole book cover to cover, this is still very valuable in understand the book as a whole.

Happy reading!

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.

This post shows the A3 technique and how it is an effective management tool.

The contents of this post are my summary of THE BOOK on this subject: Managing to Learn: Using the A3 Management Process to solve problems, gain agreement, mentor and lead – by John Shook. Available via Lean Enterprise Institute and Ocapt (in Canada).

Why A3?

Over the last year, I have used A3 to solve serious problems myself as well as with clients that I am coaching. I am blown away by how effective it is. I think of it as the howitzer (big gun) of problem solving and use it for complex problems.

Root cause analysis tools are very helpful, however, do not provided a context for resolving problems. A3 is a complete process. If you are not familiar with root cause analysis, see my related blog post.

What is an A3 anyway?

As shown in the middle of the diagram below, A3 is the name for a large sheet of paper (17″ x 11″). With the A3 technique, it is filled up with useful information. Space is intentionally limited to make sure only the most relevant information is shared. At Toyota, the A3 report is used to drive company decisions from shop floor to senior management.

Let’s walk through the sections:

1. Problem – What is the problem that is causing problems? Also, give attention to the title as the summary.
2. Background – How did you decide to work on this problem? What is business problem?
3. Current Conditions – Describe the current conditions with visuals and numerical data that you have analyzed.
4. Goals/Targets – What is the desired target state? This is the place to use SMART goals.
5. Root Cause Analysis – What are the underlying causes? Use ask why five times and fishbone diagram.
6. Countermeasures – How will you reach goal state? What activities can be identified that will address root causes and how were the best ones selected?
7. Plan – What is the plan for getting there? When will the countermeasures be implemented?
8. Followup – What were the results of deploying the countermeasures? Now that there is new information, it is time to revisit the A3.

You may have noticed that this is an elaborated version of PDCA – Plan Do Check Act. This is the heartbeat of a learning organization.

It takes time and effort to complete an A3. Weeks not days. Use when appropriate.

Tips: Experts strongly recommend using real paper. Yes, you will need to re-write; editing is a good thing. A wiki is great for details, but not for thinking and summarizing.

A3 to gain agreement, mentor and lead

In this section, I want to share how the A3 technique is a powerful management tool.  Consider the following diagram:

A3 is about people working together to solve problems. The Japanese word Nemawashi is about going to the roots to reach consensus and alignment in a deep way. An A3 changes the way we work and communicate with each other. When meetings start by reviewing the parts of the A3 that have been completed, there is great focus on the remaining work. I have also seen new project participants brought up to speed very rapidly.

At Toyota, the A3 is used to do work. It is used to solve problems, make (set-based) decisions and execute plans.

Lean is famous for using pull to deliver the right part at the right time at the right place. With A3, the person driving the change effort can pull authority by working with other people and demonstrating leadership. It is chilling to see this work. I was coaching a junior analyst to put together an A3 on a production problem. When the issue escalated, the VP recognized the analyst as the expert and asked him to tell people what to do to fix the problem even though he had no formal or informal leadership role.

Finally, the A3 can be used to build a learning organization. One key aspect is to celebrate mistakes. This is also common with building an innovation culture through Improv or theatre techniques. At Toyota, it is used to develop people by helping them think for themselves to solve problems. A manager’s job is to build people and mentoring people on the A3 is a great way to do it. (Like a self-organizing team, but on an individual scale.)

I wish I had a real A3 to share, but the better ones I have are client confidential.

If you want to learn more, I urge you to buy the book or check out webinar on Managing to Learn.

One of the workshops I run is to help team members understand root cause analysis. I use it with operations teams as well as product development teams. My workshop goal is to have people leave with a basic understanding and some practice.

I created the diagram below to situate this workshop in a larger context of Kaizen (Continuous improvement).

One starting point is with a team using a Scrum board or Kanban to create BIG visible information. This supports teams in identifying problems or waste to stop the production line and investigate the problem using root cause analysis tools. I introduce two tools and have the participants practice with each:

• Ask Why five times – powerful technique for drilling down into problems.
• Fishbone (Ishikawa) Diagram – looks at the big picture around the problem.

Both of these improve quality to help teams go fast. 5S (sort, straighten, shine, standardize, sustain) is also totally applicable for software – it’s called clean code: coding standard, refactoring, etc.

Finally, the foundations for Kaizen and root cause analysis are:

• NO BLAME. Most problems are related to the system, not individuals.
• Team work and trust. If 100 people each help find 1% improvement, this will be sustainable.
• Genchi Genbustsu – Go and See.  When you work on a problem, go to the source and get the facts for yourself. Root cause is about investigation and problem solving – see and think for yourself.

If you want to learn more, check out Implementing Lean Software Development: From Concept to Cash or Toyota Production System: Beyond Large-Scale Production.

Workshop Slides

Here is a slide deck I have used in training. It’s from last year, and would benefit from a refresh to cut down on the text – still very usable. As usual, you are welcome to use this as well as the diagram under Creative Commons license.

As a trainer, I have become increasingly convinced that games and simulations provide an excellent platform for learning concepts and new behaviours. I am playing and training with more and more games than ever before. It was getting hard for me to remember all the games and decide which one to use in a particular situation. (Can someone please create a public website where we can list games, rate them and tag them by the problems they solve?)

Where Games Play

Here are some of the games that I am currently use or want to use in training.

What’s with the grid?

• People – games about people learning individual skills or learning about individuals
• System - games about the team or organization
• Concepts - games primarily about teaching concepts or ideas
• “Experiencing our reality” - games the help us understand ourselves and our context

Links – People/Concepts

• Multi-tasking (10 min)
• Collaborative Origami – collaboration & communication (15 min)
• Yellow Brick Road: Fresh Insights through peer coaching (90 min)
• Pair Draw (30 min)
• 99 Test Balloons – acceptance testing (30 min)
• Go! – Your brain on Scrum (10 min)

Links – System/Concept

• The Biggest Bang for the Buck – backlog organization and prioritization – (60 min). Game I created with Gino Marckx will be released around Agile2010.
• The Backlog is in the Eye of the Beholder – organizing backlog from stakeholder view (40 min). Game I co-created at Deep Agile.
• Business Value Game – helps understand differing sources of value. (90 min)
• Marshmallow Challenge – understand benefits of incremental design (45 min)
• XPGame – Scrum variant – basics of iterative development and acceptance testing (180 min)
• Penny Game – Flow of value, process improvement (40 min?)
• Bottleneck Game – understanding process and applying theory of constraints (90 min)
• Name Game – Limit concurrent projects (10 min)
• Movers and shapers – team dynamics (10 min)

Links – System/Reality

• Ball Point Game – process improvement, teamwork – simpler than penny game (40 min)
• Value Stream Mapping – hmmm. not a game really
• Leadership Game – self-organization and leadership styles (180 min)

Links – People/Reality

• Constellations – Share team perspectives (30 min)
• Improv Games and Hypontizing hypnotist – Get better at collaboration and innovation (10 min to ?)
• MarketPlace – share skills with team members (30+ min)

Other thoughts

Please draw your own maps and share them!

Other games

I did not include games that have are designed to achieve and outcome such as  retrospectives, planning poker or Innovation Games® since the primary purpose is not training/teaching. These are important too.

Happy to be finally attend InnovationGames in Chicago, July 15/16.

Cross-training charts (also skill training charts) are a standard part of the Lean toolkit. They are used to identify limited skill sets that can lead to bottlenecks and work stoppage.  See manufacturing example.

In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.

Technology and Domain skills

When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.

On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.

Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.

What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.

Lottery/Truck Factor – Are you managing your risks?

Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.

The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.

How to spread knowledge?

There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.

My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.

Footnotes

• I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
• See complementary practice of Timeline and Marketplace for understanding other team members.

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.

Alternate Title: Organize and prioritize your personal projects.

I keep my life sane use David Allen’s Getting Things Done (GTD) together with the Pomodoro Technique. GTD is great for managing the little stuff (like email) and Pomodoro is great for managing and prioritizing projects.

I use Index Cards for managing the Pomodoro Technique

For each activity, I use index cards (like story cards). The one in the photo has a title and two boxes – each represents a pomodoro which represents 25 minutes of uninterrupted work. In the example on the left, I am estimated that writing the blog post will take about an hour (two pomodoros).

You may be wondering what those blue and green squiggles are. Like on Agile projects, I annotate cards with themes to help with organizing them visually. On the left you can see the legend for my personal backlog. It ranges from Blue Sky (future oriented) work on my Agile Coaching Company to foundational work that has to get done or will improve my productivity.

I plan based on importance, urgency and balance

When I plan each day, I like to see some balance between themes to make sure I am looking after all my interests. Themes are an easy way to organize my backlog.

What about prioritization? Thanks to Gino Marckx for designing the Quadrants of Effectiveness Game, I use Stephen Covey’s quadrants and the Eisenhower method of prioritization. All you need to do is to scatter your cards according to Importance and Urgency. See photo below.

There is one pile of cards under CSC (hence the big box and the elastic band – like an epic). How did this work out for me? It was a good way to get started when I felt like I had too many choices. So, the next time you feel overwhelmed, perhaps, you may think of this post and take a step back to organize and prioritize your work.

What’s this business about 11?

I am using this to indicate that this is an add-on to get extra milage out of the Pomodoro Technique. See cultural reference for details on where this comes from.

Confessions

This is where I come clean on where I slack on Pomodoro Technique. I do allow interruptions since they usually have high value. I also don’t track them either. I have done so in the past, however, I don’t find it particularly critical for me. So there. So maybe my knob only goes to 1.1 …