Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit.  Here are fours ways of dealing with that situation:

• Case1: Urgency!
  The new story has higher priority than work on the board.  Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again

• Case2: Pleasant "no"
  Bring the stakeholder to the board and ask them if they would like you to throw away for  the benefit of their request.

• Case3: Can’t say now for Legal reasons
  Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy  being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem)

• Case 4: Homework has been made
  Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog

Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?

Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit.  Here are fours ways of dealing with that situation:

• Case1: Urgency!
  The new story has higher priority than work on the board.  Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again

• Case2: Pleasant "no"
  Bring the stakeholder to the board and ask them if they would like you to throw away for  the benefit of their request.

• Case3: Can’t say now for Legal reasons
  Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy  being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem)

• Case 4: Homework has been made
  Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog

Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?

Last weeks have been busy!

• We ran the first Kanban training course i Stockholm with David Anderson. The training class got a 8.5 score average out of 10. I really enjoyed the skill and experience  of the participants as well as David’s many "off topic" discussions.

  

• The first Limited WIP Society meeting arranged in Stockholm brought 50 people(!). Besides sharing kanban stories (and a beer or two..:)  we managed to gather 20 people in playng the bottleneck game in the open space session. In the stories shared the simpleness of applying Kanban to an existing organisation was a common thread.

  

Talks I have held,

• NFI – Från krav till system, Var är mitt krav? Följ det med Kanban (slides in swedish)
• ScanAgile 2009 – Getting Agile in system administration and operations
  -> Great to meet some old finnish collegues!

Talks – upcoming

• Devopdays 2009, Belgium – Introducing Kanban in operations

Continuous improvement ( "kaizen") is a core process within Kanban and/or Scrum.

But what does it mean?

Here is an A3 I use to explain the concept

If you’re interested in Kanban I can recommend this course in Stockholm, there are still a few spots left. If you don’t know what Kanban is you might take a look at: http://www.limitedwipsociety.org/resources/ … or my article Kanban vs Scrum or (if you only have a minute) my cartoon One day in Kanban Land. My

Take a look at this chart and tell us how we are doing?

Sometimes it is hard to stop a running meeting. You might have someone so fond of talking he doesn’t realize time is up. Or the daily stand up has gone haywire. How do you break in, politely?

Teach everyone the timeout sign.

  "hey, let me get back to code"  🙂

Your team is coding along, sprints are passing by, your somewhere around sprint 15.. life is ok..  ..or?

As a famous test leader once said:
"Team are happily completing sprints but nothing gets’s done"

Here are a couple of  things to look out for in your Scrum organization..

On September 24-25:th in Stockholm, there is a chance to learn Kanban directly from the source!

Kanban is framework to help improve efficiency and continuous learning, but with a very light weight footprint. It works both in- and outside software environments.  Support is one example.

Hosting the training is David Anderson, one of the most experienced practitioner in the field. So it is a great opportunity to learn from the source.

http://www.crisp.se/kanbanjedi

For those of you who wonder "why would anybody convert a Scrum team to Kanban" (see earlier blog) – it is important that you understand the true intent. (..yes there is one! 🙂    What expected output do you have from a process framework?

This important "why" question is often left out in the debate. The heated "Scrum vs Kanban" discussion is a good example. Try yourself  "why are you using Scrum"? (or Kanban). At what point would you throw the tool out for not delivering?

It is no wonder debates turns heated if we disagree on where we are heading. But if we instead start with clarifying intent ("why") – then the actual choice of tools becomes less important (more like a boring context summary 🙂

Why then? How do you know that the process tool works for you?

• First (obvious) – it helps you deliver running software.
• Second (less obvious) – it makes you do continuous improvement effectively

If you are getting results from continuous improvement – your tool is right. If it is not happening, it is probably wrong. (check yourself, what improvements have you benefited from lately?)

This was the main reason I chose to implement Kanban in the Scrum teams. It was not because the sprints where not delivering, it was because the improvements didn’t happen.

At a customers site, teams have been using Scrum for year or more (even the sales people run it 🙂 Developers are talented and motivated. In one team, increased visibility was needed, so I helped them convert to Kanban.

A second team took noticed on what went on, copied the Kanban board and started using it on their own.
 
So before, their sprint burndowns looked like this:
(atleast for the last three sprints)

  Now this is a picture of the same team after two weeks of Kanban

Isn’t it a bit cool? 🙂

Here’s a really short and simple kanban intro: Translations: Brazilian Portuguese Chinese Czech French German Japanese Korean Turkish

Here are the slides from my keynote at Integrating Agile 2009, Amsterdam. First three slides are below, the rest are in the PDF document. Take-away points: Know your goal Agile is a tool, not a goal Tools don’t fail or succeed. People do. There is no such thing as a good or bad tool. Only

Sometimes I work in projects where team uses sprints, but deliverables are compiled over multiple sprints. In these cases, I have found it handy to do simple Release / Project burndown tracking. It helps facilitate a discussion with client and project stakeholders.

So, here is a template I use. It has the feature of  "dropping" the baseline when additions to the projects are made, showing the net effect of things discovered along the road.

It can be used by a Kanban team, Scrum team, well – any team 🙂

Project and Release Burndown Template.xlxs
Project and Release Burndown Template.xls

Here are the slides for my presentation Kanban vs Scrum. I’m glad people enjoyed it! The participants were asked to rate how valuable the presentation was on a scale 1-3. The average rating was 3.0 at Deep Lean and 2.9 at Future of Agile :o) This presentation is based on my Kanban vs Scrum article,

Experience the humbleness and energy of so many people in one single place was a great experience. I would have liked to stay longer just do discuss and share experiences.

Takeaways:

• As Agile practitioners, we need to continue to evolve
• Kanban is a promising tool for sharing Lean benefits outside teams
• Pick the right tools for the job! Kanban and Scrum have their advantages, start with your problem and then pick the right tool
• David shared my experiences with Kanban teams demonstrating a "white box" behaviour instead of a "black box" (not your business) towards its stakeholders
• Classes of Service is a hot upcoming topic around Risk Management
• In Japan the "why" is the most important thing. Therefore rigorous effort is spent on understanding Values and Princinples, compared to our Western approach of staring with the Practices (therefore not being able to adopt when situation change)

Enough chat. Here are the slides:

• Future of Agile – David Anderson
  http://www.crisp.se/futureofagile/slides/davidanderson

• Kanban vs. Scrum – Henrik Kniberg
  http://www.crisp.se/futureofagile/slides/henrikkniberg
  
  
• Roots of Lean, visiting Toyota – Mattias Skarin
  http://www.crisp.se/futureofagile/slides/mattisskarin

I held a seminar at NFI today "Introduction to Lean Software Development".  Afterwards, I got the question "where is a good starting point to learn more?" – and realized that while there is new material, much is still "in work" (for example: Mary and David are both working in new books).  So updated information it is not easily found.

If you are completely new to the subject:

• Implementing Lean Software Development – Mary & Tom Poppendieck
  [comment] While there is newer material, this is a good starting point.

"I have the basic understanding and now want to move on to the software specific stuff"

• David Anderson Kanban for software presentation
  [comment] good visualization of concepts in practice

• Mary has a great essay page
  [comment] nice inspiration

• ..or grab my slides from today  "Introduction to Lean software development"
  [comment] ..note, at least half of the content was delivered verbally, but the stuff in here is up to date

Psst!: Two great opportunities exists in May to get the latest in Lean here in Sweden:

• Deep Lean 18-19 May –  with Mary Poppendieck and Jeff Sutherland
• Future of Agile – with David Anderson, Mattias Skarin and Henrik Kniberg

I attended the Lean & Kanban conference last week. The first of it’s kind, a big boost of energy and I certainly hope to see more on this subject.

It was striking how, in case after case, the simple introduction of visual management and matching work to capacity (Kanban) sent teams off on a journey exploring Queues, Pull, System Thinking and even Deming(!). 

Here are my biggest takeaways:

• Even highly performing senior teams get a boost by using Kanban (a bit of surprice to me)
• Classes of service enables teams to self organize around risk elimination. (David Anderson). If you have been thinking of  "is there any way around analysing full test suite/architecture up front – this is what you are looking for. Extremely interesting stuff.
• It was nice to hear the community has picked up that the primary model for software is Lean Product development first, then ideas from lean manufacturing
• How system thinking quickly was perceived as the primary constraint when scaling and how Deming holds many answers
• Talking to Dean Leffingwell an confirming my thoughts regarding the need for a cooperation model

I ‘ll probably come back more on this subject 🙂

I have updated the original quick reference originally created for system administration teams now to focus on introducing Kanban. A two page A4 visual of "what is it all about".

So here is Kanban in 5 min.

Back from Japan! It was a very learning week. Among other we met

• Manager for Toyota automotive  software
• CEO of Fujitsu Siemens Software
• Representatives from the Agile community in Japan
• Agile pioneers such as Eiwa and Azzuri
• Cheif engineer of Lexus and Supra program, Katyama-san
• Former IT manager of Toyota Kuriowa-san

And of course visited a Toyota plant 🙂

It was really interesting to see:

• Toyota’s response to the current crises, totally different from what I’d expect western companies to do
• How continuous improvement, Kaizen, is on top of the agenda. Especially CEO’s. "It is in our DNA"
• How Kanban is the center of the modern Japanese software shop
• How the Agile community of Japan is spearheading changes
• How new cars got developed and how people leading these efforts where picked (comparison: Product Owner in Scrum)

I am going to talk more about this in my session at Future of Agile.
Big thanks to Bent and Kenji who made this possible.

The schedule is taking shape for May 27:th,  we now announce two more sessions:

• Kanban vs. Scrum – Henrik Kniberg
• Roots of Lean and Agile  – direct report from Toyota visit

Also, meet the experts face2face in the afternoon open space session. Here is your chance to discuss in person with the father of Kanban, David Anderson and with Henrik Kniberg.

More is to come. Seats are limited. Don’t miss out.

http://www.crisp.se/futureofagile

There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does it compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some

When running Scrum (or Kanban), you will need management involvement. And it is actually better that you secure it from the start.

Don’t get me wrong – I am not advocating  detailed control and interference. No, what I am talking about is getting some punch behind dealing with impediments that your team will surface.

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt. My conclusion is, not very suprisingly, that  it depends on the situation.

In this entry I take the Scrum T-shirt on.

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt. My conclusion is, not very surprisingly, that  it depends on the situation.

In this entry I take the Kanban hat on.

Yesterday, in a post by David Andersson, he so accurately in few words managed to describe the fundaments any Lean implementation.

"In Lean operational decisions, value trumps flow, and flow trumps
waste reduction."

The value of waste reduction (over flow) is for me one of the great misunderstanding of Lean.

These are checklists I have compiled to help my Kanban teams stay focused

"Anytime" Iteration planning Daily standup

Download as pdf

Kanban pracitioner or a Scrum team thinking of adopting it?, don’t miss out on the "Future of Agile" conference 27:th of May.

An unique opportunity to learn from practitioners and experts about experiences and best practices for Kanban and Lean in our "Bring your kanban board" session. Joining us is David Anderson – father of Kanban.

Future of Agile, May 27, Stockholm