When I hear the expression “we need to change our Kanban board” - it happens quite often -, I think about the analogy between a mirror and a Kanban board: a mirror reflects what’s in front of it and a Kanban board reflects the process the organisation is following. We rarely put make-up on the mirror, or try to comb it. When we want to change the reflection, we change ourselves and check the result in the mirror. We should do the same with the Kanban board. Following the analogy, it doesn’t matter if we add a new lane or column to the board, or changing the WIP limit. Nothing will change, except the reflection won’t be clear any more: it is like looking into a dirty or an old mirror. So don’t start your change by redesigning your Kanban board. Do a value stream mapping to see the status quo, find the desired outcome, and update your process. If you do this right, your Kanban board will show your state.
I’ve finally uploaded the slides for my I broke the WIP limit TWICE, still on the team talk. I gave this talk at Lean Kanban France and at Make Better Decisions with Modern Management Methods (a.k.a. Lean Kanban the Netherlands 2013), and will give it at the same branded conference in London in a week (a.k.a. Lean Kanban UK 2013).
Also on slideshare.
Swim lanes on the Kanban board are really handy when different software versions have to walk through the same path or flow. However, they can be deceptive when instead of versions, different development phases have their own swim lanes. Let’s say that an imaginary team decides to upgrade its Kanban system and adds the design that precedes the development phase to the board. The team already has “plan”, “doing”, “review”, and “done” steps (columns) for development, and the design phase also has these steps, so they open a new swim lane for design:
If you are looking for a great tool to conduct a root cause analysis (RCA), or find a problem during a retrospective, try out the Fault Tree Analysis (FTA). It is used to identify causes of failures, weaknesses of a system, or the probability of a certain failure happening. I prefer this method over 5-whys and Ishikawa (fishbone) diagram because it has no limitations regarding the depth and width of the analysis, can find multiple root causes, is repeatable, and anybody can interpret the result.
The FTA is a deductive (top-down) technique. It starts with defining the problem (the top event), and finding those events that contribute to it. After all the child events have been found, the analysis continues with examining them individually similarly to top event in the previous iteration. This recursive technique ends when the events cannot be broken down (basic or undeveloped events) or it reaches the boundary of the system under analysis.
I was about to refactor one of my old ruby apps when I realized that I didn’t want to write more cucumber features and scenarios. I do bdd whenever I can (I even wrote a detailed post about it), but in ruby I don’t want to have test cases both under
./features for cucumber and
./spec for rspec any more. I know that it is possible to run both of them at once, but that is not simple: it makes automatic test case execution, getting test coverage, and maintenance complicated. Moreover, it is easy to forget to run one of them before commit, and that usually leads to a failed build. So, I decided that I would ditch cucumber and use only rspec and use
it "" do ... end methods as scenarios and write steps such as
when_i_enter_something, but then I found turnip, and I like it very much.