Eating our own dog food
**agilitrix.comYes, John and I eat our own dog food. We used Kanban to visualize the work we needed to do to prepare for the workshop. Below is a snapshot of our Kanban board we created in google docs. See Henrik Kniberg’s sample.
Thanks
John and I would like to thank everyone who shared material with us to prepare our slides – notablly Henrik Kniberg, Mary Poppendieck and Jon Stahl.I would also like to thank Russell Healy for discussions on rule variants of the Kanban Game.
What’s better than Kanban?
I was reading Freddy Balle’s book The Gold Mine: A Novel of Lean Turnaround and I read something that stopped me dead in my tracks. In the book, after months of transitioning a manufacturing plant to continuous flow using Kanban, the Lean sensei asks the innocent question:
What’s our goal? To increase throughput and reduce latency while minimizing operating expense. Reducing WIP is very helpful. Would be great if we could reduce our WIP as far as possible. How to do that? One-piece flow. So we reduce Kanban cards to zero.
If there is no Kanban and you are very Lean, then you have single-piece flow. The holy grail of Lean process. This is what Arlo Belshee and Jim Shore attempted to explained in their LSSC10 session Enough Kanban! Use XP for Single-piece flow. (Please check it out if you haven’t seen it before.) I say attempted because I didn’t get it – I needed to read the above question and answer for the pin to drop.
So what? If you are in an environment where you can do Scrum or XP, then go do so! If not, then Kanban is great place to start. Or finish – in the case of an elite Scrum/XP team that doesn’t need iterations as training wheels.
(Aside: I almost had a blog post without images or drawings. Then I decided I needed to do something – anything to make my point more vivid. Please excuse my primitive drawing skills.)
Question: What is better than Kanban?To answer this, one must think of the purpose of a Kanban card. In manufacturing, a Kanban card is a replenishment indicator for a particular part or assembly. In software, we use Kanban to represent a piece of work such as an MMF or user story. Either way, a Kanban card represents WIP (work in process). More Kanban cards means more WIP.
What’s our goal? To increase throughput and reduce latency while minimizing operating expense. Reducing WIP is very helpful. Would be great if we could reduce our WIP as far as possible. How to do that? One-piece flow. So we reduce Kanban cards to zero.
Answer: No Kanban!
If there is no Kanban and you are very Lean, then you have single-piece flow. The holy grail of Lean process. This is what Arlo Belshee and Jim Shore attempted to explained in their LSSC10 session Enough Kanban! Use XP for Single-piece flow. (Please check it out if you haven’t seen it before.) I say attempted because I didn’t get it – I needed to read the above question and answer for the pin to drop.
So what? If you are in an environment where you can do Scrum or XP, then go do so! If not, then Kanban is great place to start. Or finish – in the case of an elite Scrum/XP team that doesn’t need iterations as training wheels.
Kanban in Context
I love Kanban – it is a great tool. One thing that I keep in mind is that Kanban is only a small part of the Lean context in which it lives. Kenji Hiranabe has a great article on InfoQ on this - Kanban Applied to Software Development: from Agile to Lean Please check out Figure 11 TPS Concept Structure: it illustrates that Kanban is just one part of the Lean system of thinking. Of course, it is a great starting place for learning it.(Aside: I almost had a blog post without images or drawings. Then I decided I needed to do something – anything to make my point more vivid. Please excuse my primitive drawing skills.)
Use Value Stream Mapping for Current State Assessment
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.
With regard to time – 2 hours may be enough for a small company while a large bank may require the full 3 hours.
View more presentations from Michael Sahota.
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.
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.
Special enhancements:
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.
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.
Serious Problems? Use A3 Technique to Nail ‘em!
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).
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.
Let’s walk through the sections:
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 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.
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:
- Problem – What is the problem that is causing problems? Also, give attention to the title as the summary.
- Background – How did you decide to work on this problem? What is business problem?
- Current Conditions – Describe the current conditions with visuals and numerical data that you have analyzed.
- Goals/Targets – What is the desired target state? This is the place to use SMART goals.
- Root Cause Analysis – What are the underlying causes? Use ask why five times and fishbone diagram.
- Countermeasures – How will you reach goal state? What activities can be identified that will address root causes and how were the best ones selected?
- Plan – What is the plan for getting there? When will the countermeasures be implemented?
- Followup – What were the results of deploying the countermeasures? Now that there is new information, it is time to revisit the A3.
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.
Go Faster with Root Cause Analysis
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:
Finally, the foundations for Kaizen and root cause analysis are:
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.
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.
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.Root cause analysis apr 2010
View more presentations from Michael Sahota.
Accelerate Your Team with Cross-Training Charts
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.
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.
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.
My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.
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.
Kanban is a Gateway Drug
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.
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…
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.
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.
Ken Schwaber is continuing the drum beat that Scrum is the one true path.
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.
Scrum or Kanban? YES!
Alternate Title: A model for understanding Scrum and Kanban
(Cool diagram below – skip down if you are in a rush
Or check out the 3 minute video explaining why Scrum and Kanban are complementary.As I flew home after LSSC10, I wondered how Kanban-style software development would shape my world in the years to come. I self-identify as an Agile/Lean Coach and wondered what the road ahead looks like for me.
Someone at the conference commented that Kanban was going to dominate discourse in our community. Some people in the Kanban community say it is more widely applicable and is a more rigourous approach. Another commented that software processes historically have a 7 year run and so it is time for the age of Scrum to wane. The arguement goes that even if Kanban isn’t better, the community needs a new buzz to keep things going. All this made me wonder.
Is this true? If it is true, what does this mean for me? How can I reconcile this with what I know works? Before we delve deep, I need to share where I am coming from.
I use Agile
I have used Scrum for many years as a starting point for Agile transitions. It is compact, creates visibility, and builds a team culture. I also use XP practices.I use Lean/Kanban
I have been using Lean concepts for many years and very heavily in the last year. I have made extensive use of Kanban-style Scrumboards as well as pure Kanban boards for business and support groups. I have had great success with other tools as well: root cause analysis, the A3 technique, and value stream mapping. This winter, I implemented Kanban with a 18 person software group and shifted behaviour with a cumulative flow diagram.For me, Agile includes Kanban
When I read the Agile Manifesto and principles, I don’t see anything that excludes Kanban. All the XP technical practices still apply – perhaps even more so. Scrum notions of Product Owner, Product Backlog, and Retrospectives still hold value. Iterations may be gone, but they have left a trail of useful concepts of tools that the Kanban community enjoys. Maybe 80% is the same. Why am I making this point? Some proponents on Lean and Kanban highlight the differences rather than relationships: “Kanban is new!” “We are post-Agile” – as if that were cool. Our community is better served by focussing on the positive in every approach.What I learned at LSSC10 that shifted my thinking.
At LSSC10, I started noticing contexts – what environments and circumstances encourage Kanban-style Agile.Support Kanban What blew me away was a keynote case study on Kanban turned out to be about a couple of support groups who figured out that Scrum is not a good fit when there are lots of interrupts and emergencies. Ah, um, … not really news. This is the canonical case for Kanban.
Naked Planning or using XP for single-piece flow is about creativity and cross-functional teams swarming work (MMFs). The context here appears to be a team with a lot of focus working on innovations. This is much more similar to Scrum/traditional Agile rather than Kanban.
(Vanilla) Kanban Mike Fitterman and Rick Simmons of Constant Contact told the story of how Scrum wasn’t working out. Two development teams shared QA and product people and found there was too much planning and communication overhead. (Ooops, sounds like ScrumBut.) Anyway, the context in which they applied Kanban was with one with specialists and group that was too large to be a team.
Vale Kanban Alisson Vale described an environment with small work packages that come from a variety of demand channels. (See also video). It very much sounded like system evolution rather than discontinuous innovation. Interestingly, his model does not follow work decomposition by role but rather allows flexible routing and story swarming much like XP.
Production Line Kanban and (Vanilla) Scrum Most insightful of all for me to outline contexts was Clinton Keith’s session on video game development (go read it). He used a timebox for creative work both with takt-time in production-line style Kanban and with Scrum during design and problem solving phases. So, in this situation, they see Scrum for exploration and Kanban for cranking stuff out.
Scrum and Kanban fit different contexts
- Kanban can handle a lot of interrupts
- Kanban supports specialized roles with divergent skill sets
- Kanban excels at repeatable work such as a production line
- Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower
- Scrum excels at projects requiring deep collaboration and innovation
- Scrum works best with small cross-functional teams (7+/-2)
- Scrum is great for providing shared goals and work context
- Scrum encourages generalists
A model for thinking about Scrum and Kanban
I am a visual thinker so I need a picture to put it all together:- The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs.
- The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work that benefits from swarming.
Every process has a sweet spot
I have indicated where I see various process styles play best. (For example, Scrum is good when there is focus and exploration.) The dashed lines suggest that these are not hard boundaries. The regions and shapes are more illustrative than literal.
In this model, Kanban is at centre stage. I have repeatedly witnessed first hand that Kanban is very easy to implement and provides great benefits.
I also have seen the value in creating small, focussed teams using Scrum. For sure it is harder and yet very rewarding. On the downside: it doesn’t fit all contexts.
In truth, I am not 100% satisfied with the fidelity of this model, however, it helps me understand how to approach work with my clients
We need to know both Scrum/XP and Kanban
If all you have is a hammer, everything looks like a nail.What tools do you have in your belt?
Henrik Kniberg gives the metaphor of comparing a knife with a fork. Which one is better depends on the situation. We need need to know both Scrum and Kanban. XP, too, but that goes without saying.
As an Agile coach I need to understand a client’s situation to know whether to start with Kanban or Scrum or both. Miyamoto Musashi – a famous Japanese Samurai spoke regarding choice of tools – said “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough.”
Let’s build community
For my Scrum and XP friends, Kanban is here to stay and it is going to continue to grow; let’s embrace it and help mature it.
For my Kanban friends, let’s build bridges and create a strong inclusive community.
Hungry for More?
- Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin
- Kanban by David J Anderson (Just released)
- Scrumban – Essays on Kanban Systems for Lean Software Development by Corey Ladas
Thanks
Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.What do you think?
The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.LSSC10 Keynotes on Process Models, Assumptions and Risk
Sadly, I did not do as good a job capturing the the LSSC10 keynote sessions as I would have liked, but maybe I captured something you missed…
Don Reinertsen really turned me off at the start of his session (The Easy Road to FLOW Goes through a Town named LEAN) which started with what felt like Kanban bashing 101. Many of his comments seemed aimed at a literal implementation of a production-like Kanban system in software – something I have not seen in practice. Despite this misdirection, there were some very strong points that I would like to highlight. See video/slides on InfoQ.
Elimination of Variability is Toxic. Great Product Development requires creativity, taking risks and encouraging failure. No errors means no learning. This reminds me of Jared Spool’s Keynote on building great products and aligns with efforts such as Enough Kanban! Use XP for Single-piece flow.
Don also introduced the Internet (TCP/IP stack) as a very different model for work execution. Again, I was a little disappointed since a lot of teams are already implementing similar elements. e.g. Different quality of service through urgent tracks in Kanban boards. A number of people said the talk was a quick synopsis of his new book: The Principles of Product Development Flow: Second Generation Lean Product Development and contains ideas that will shape lean software for the next five years. These are smart people so I am going to have to get the book.
Profit = Exchange of Risk. There are three types of risk:
Don Reinertsen really turned me off at the start of his session (The Easy Road to FLOW Goes through a Town named LEAN) which started with what felt like Kanban bashing 101. Many of his comments seemed aimed at a literal implementation of a production-like Kanban system in software – something I have not seen in practice. Despite this misdirection, there were some very strong points that I would like to highlight. See video/slides on InfoQ.
Elimination of Variability is Toxic. Great Product Development requires creativity, taking risks and encouraging failure. No errors means no learning. This reminds me of Jared Spool’s Keynote on building great products and aligns with efforts such as Enough Kanban! Use XP for Single-piece flow.
Don also introduced the Internet (TCP/IP stack) as a very different model for work execution. Again, I was a little disappointed since a lot of teams are already implementing similar elements. e.g. Different quality of service through urgent tracks in Kanban boards. A number of people said the talk was a quick synopsis of his new book: The Principles of Product Development Flow: Second Generation Lean Product Development and contains ideas that will shape lean software for the next five years. These are smart people so I am going to have to get the book.
Risk, Lean Development and Profit
The second keynote was by Bob Charette. I love the quote he shared with us about assumptions and risk:“It’s not what you know that can hurt you; it’s what you know that ain’t so” – Will RogersI am reminded of the damage assumptions can bring every time I train people with my Scrum-friendly version of the XPGame. Bob points out that assumptions are risks we have accepted.
Profit = Exchange of Risk. There are three types of risk:
- Information
- Control
- Time
Related Posts
Check out blog post: Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of KnowledgeLean Influencer’s Mantra
Siraj Sirajuddin shared a deeply insightful reflection on the nature of Agile/Lean coaching. Lot’s of insights for me.
Below, I have a few notes that just scratch the surface.
A big take-away for me is that every day and every meeting I need to:
Another concept is Clean State Fridays where everyone goes home without emotional baggage so they can start fresh on the following Monday.
He also reminded me that we play a dance with courage and grace to achieve great outcomes.
Strongly suggest you check out the full presentation or find a way to see him in person.
Below, I have a few notes that just scratch the surface.
A big take-away for me is that every day and every meeting I need to:
- Learn
- Make a difference
- Have fun
Another concept is Clean State Fridays where everyone goes home without emotional baggage so they can start fresh on the following Monday.
He also reminded me that we play a dance with courage and grace to achieve great outcomes.
Strongly suggest you check out the full presentation or find a way to see him in person.
No comments:
Post a Comment