Always run a changing System! Speaking at Lean Kanban Southern Europe 2012

Kanban is designed for helping teams and organizations to change in an evolutionary way. If we can manage to establish a real Kaizen culture - a culture of continuous improvement - we‘ll always be one step ahead of our competitors.
But how do we establish such a culture? Kanban provides us with a set of simple, really useful principles and practices. Applying them will help us to improve.
Unfortunately a Kaizen culture is nothing that can be established over night. There are a lot of pitfalls and there is of whole bunch of things that need to be considered. Some of these things are closely related to Kanban and often heard of. But some aren‘t.
At the conference Lean Kanban Southern Europe 2012 which takes place in Madrid, May 9-10, I will talk about what I think are the main ingredients for a Kaizen culture, how they are related to Kanban and what else we need to take into consideration (abstract). I will tell a lot of nice little stories, and the whole talk will be held in a cartoon style:-)

So if you are interested, book your flight and meet me at a great conference in sunny Madrid!

Thoughts on Standup Meetings

I just came across this really useful blog post on standup meetings: It's Not Just Standing Up: Patterns for Daily Standup Meetings
This reminded me of the fact that I wanted to write about my own thoughts on stand ups and the results from the standup session held at the Limited WIP Society meet up in March.

Standup Meetings as an indicator

As a coach I often meet new teams. Often they start implementing Kanban and the one thing they already do is holding standup meetings. For me it‘s really useful to watch a standup, take notes and talk with some team members afterwards. I discovered that standup meetings are a great indicator for finding problems and improvement opportunities.
One pattern I often observe is that the standup is nothing more than a status report. The team members are reporting about their work - often looking at their boss or product owner. While this might have some value, it gives away much of the potential power of a standup (coordinating the team‘s work, improving, just-in-time planning, gaining and keeping focus). So this is definitely something to have a closer look at.
Another thing that makes me suspicious is when there is not a single problem raised during the standup, especially. This can point in the same direction as the previous pattern: The team is not using the standup as an improvement opportunity.
A third problem - and this is a really tricky one - is people not listening to each other, coming late or not attending at all, not showing interest in the meeting etc. In my experience this is not a problem with dumb people but with a systemic problem that causes the standup to not having value for the team members. Quite often the underlying problem is that the "team" its not really a team - they don't have a common goal and no shared context. Sometimes a manager just selects a couple of people and decides that from now they are a team, e.g. the maintenance team. They might all use the same board, but if everyone only has his own tickets and there is no opportunity to collaborate (specialization is often a problem as well), then it‘s a valid question to ask: "Why should I attend this meetings an listen to others while their work does not affect me at all?" When this situation keeps going, the team often decides to only meet every other day, once a week or they completely abandon the standup. Before re-starting the standup, you need to have a closer look at the real problem and solve it.
Another pattern that is worth observing is people preparing themselves for the standup meetings by writing down what they did since the last standup meeting. There might be an underlying problem that people do not work on the tickets visible on the board, or are not using the board as their main planning, coordination and tracking tool.

But...

...it‘s really dangerous to consider all these things as anti patterns that need to be fixed! Sometimes there is a whole different story behind this patterns. For example, people might gain a lot of focus by preparing themselves for the standup meetings. And by taking notes they feel much more comfortable with speaking in front of the whole team - you know, not everybody is a great speaker.
And there is another interesting story, a Limited WIP Society member shared: One team in his organization found out that they don‘t like stand ups and that for them they feel like a waste of time. But the reason for that was not that they weren't working as a team. The opposite was true! They communicate so much during the whole day that they don‘t feel the need for a separate standup meeting.
Standup meetings should be short and usually not longer than 15 or 20 minutes. But here, again, I would‘t stick to that rule religiously. Some teams combine "traditional" stand ups with other tasks and they are quite successful with that. So why should they change this? For example, a lot of operations teams combine their daily standup with a short planning meeting. Is it a problem if the whole meeting takes 25 or 30 minutes?
So in my view it‘s not only necessary to discover patterns like these but to investigate the reasons behind them as well.

Try something new

There are two main routines for running standup meetings: people-based and ticket-based (both are explained in this post). They both have their advantages and disadvantages. I think picking one of these routines is a good starting point. But over time you should change the routine and experiment with different kinds of modifications. Here‘re some examples:

• Don‘t ask: "What did I do since the last standup?" and try "What did I accomplish since last time?" instead. This is especially useful when people tell about every phone call and every line of code they were dealing with.
• Don‘t ask "What am I going to to today?" and try "What can we, as a team, do to accomplish our goals?"
• Let every team member answer the first question, then everybody answers the second question and then everybody answers the third question. This might help to keep the energy level high.
• Aks "Can I work at 100%?" If the answer is no, ask "What is preventing me from working at 100%?"
• Let everybody answer the question: "Do you think, we are on track to reach our next short-term goal (e.g. sprint goal in Scrum)?"
• Surprise the team and let them answer an additional question that might be completely out of scope, e.g. "What did I do after work yesterday?" 
• Have a closer look at your metrics, or one specific metric like the CFD, once a week during the standup meeting.
• Try running 2, 3 or even 4 standup meetings every day. You think it‘s crazy? Perhaps it is - but perhaps you will be surprised what will happen. And if it does not work, how big is the damage you did? (Thanks to Stefan Roock for this one).
• Perhaps the Two Hands Rule, described by Benjamin Mitchell is is something you want to try?
• ...

Do you find this useful? Do you have other ideas for improving standup meetings? Please share your thought in the comments!

P.S. Thanks to everybody who attended the OpenSpace session at LWS DE and shared his ideas!

The Lean Kanban conference season starts...NOW!

The Lean Kanban conference season starts...NOW!

Do you want to learn more about Lean and Kanban? Did you hear people talking about Lean Kanban events you couldn’t attend? Do you like travelling? Do you want to meet all the experts you know from Twitter, Blogs, articles etc.?

Then I’ve good news for you: There are plenty of opportunities ahead this year!

For the first time ever, the conference Lean Kanban Southern Europe takes place, Madrid, May 09-10 The speaker line-up looks really awesome, and what a great opportunity to visit Madrid!

Only one week later, it’s party time in Boston (The Boston Lean Party)! This is the mother of all Lean and Kanban conferences – 6 days packed with the best speakers from all over the world! Lean Software & Systems Conference

In Autumn, the Kanban train goes through Switzerland, Scotland, Netherlands, Austria and France!

Lean, Agile & Scrum takes place in Zürich, Sep 12th. It’s a one-day event that will cover a couple of Kanban sessions as well as other Agile stuff.

Lean Agile Scotland takes place in Edinburg, Sep 21-22 - and they already announced a great set of speakers!

In October, there will be three events in a row – starting with

Lean Kanban France – for the first time ever. The date will most probably be Oct 18-19

Only one weekend to rest, since the second edition of Lean Kanban Central Europe takes place in Vienna, Oct 22-23 Because I‘m one of the organizers, I know that there are a couple of exciting news to announce soon!

Our friends from the Netherlands organize Lean Kanban Netherlands. This event will take place in Amsterdam, Oct 25-26

And Maarten, who organized Lean Kanban Benelux the past two years, is working on a whole new conference, called RE:THINK2012, that will take place in Brussels, Dec 14

So ask your boss, book your flights and pack your things...NOW!

„Wir verarbeiten aber keinen Müll.“ Oder: Müssen Tickets in Kanban immer die gleiche Größe haben?

Auf dem Treffen aller deutschsprachigen Limited WIP Societies vergangenen Freitag gab es eine spannende OpenSpace-Session zur Ticketgröße in Kanban. Dabei spielte sich folgender kleiner Dialog ab:

A: „Sollten die Aufgaben eigentlich immer die gleiche Größe haben?“

B: „Wenn wir uns mal eine Müllverarbeitsanlage ansehen: Das Erste, was sie tun, ist alles in gleich große Einheiten zu zerteilen, damit sie es besser verarbeiten können.“

A: „Wir verarbeiten aber keinen Müll.“

Die Frage nach gleich großen Tickets wird mir auch regelmäßig nach Vorträgen und in Schulungen gestellt. Und weil ich jetzt eine schöne Überschrift gefunden habe, dachte ich mir, ich poste meine Gedanken dazu einmal.

Vorteile gleich großer Aufgaben

In der Fertigung (z.B. Automobilproduktion) werden Aufgaben schon seit Langem so geschnitten, dass sie gleich groß sind bzw. ihre Bearbeitung immer gleich lange dauert. So lässt sich nicht nur eine maximal hohe Auslastung von Mitarbeitern und Maschinen erreichen, sondern es ergibt sich auch ein anderer, sehr großer Vorteil: Vorhersagbarkeit. Wenn jede Aufgabe gleich lange dauert, dann kann ich auch einen immer gleich langen Takt erreichen, mit dem fertige Produkte (z.B. Autos) vom Band rollen (Tact Time). Das macht es sehr einfach, die Produktion zu steuern und meinen Kunden und Partnern sehr zuverlässige Aussagen darüber zu geben, wann sie wie viele Produkte von mir bekommen können.

Also ist die Sache doch klar, oder?

So weit so gut. Also übertragen wir dieses Vorgehen einfach auf unsere Domäne (Wissensarbeit), und wir können endlich auch mal vernünftige Vorhersagen machen und alle unsere Pläne einhalten! Tatsächlich übernimmt Kanban ja einige Ideen vom Toyota Production System, so dass es nicht verwundert, dass im Zusammenhang mit Kanban immer wieder die Forderung nach gleich großen Aufgaben kommt. Leider gibt es da ein paar Probleme...

Wissensarbeit ist keine Fertigung

Nun wird nämlich der Unterschied zwischen Fertigung und Wissensarbeit extrem wichtig: Während in der Fertigung immer wieder dieselben Aufgaben erledigt (=produziert) werden, ist das in der Regel in der Wissensarbeit nicht der Fall. Entwicklungsteams entwickeln zwar ein Fetaure nach dem anderen; und Wartungsteams fixen einen Bug nach dem anderen. Aber kein Feature ist wie das andere. Und kein Bug ist genau wie der andere. In allen diesen Aufgaben steckt ein (meist recht hohes) Maß an Ungewissheit. Und um diese Aufgaben zu erledigen, ist meistens auch ein hohes Maß an Kreativität erforderlich. Das muss auch so sein. Stellen wir uns einmal vor, es gäbe keinen grundlegenden Unterschied zwischen Fertigung und Softwareentwicklung: Dann würden wir immer wieder haargenau dieselben Systeme entwickeln. Dann bräuchte man keine gut ausgebildeten und hochbezahlten IT-Spezialisten mehr, weil man den Großteil dieser Systeme einfach per Copy&Paste erstellen könnte. Also sollten wir dankbar sein!

Ungewissheit

Na gut, genau gleich groß können wir unsere Features also nicht schneiden. Aber wir könnten die Größen doch wenigstens so weit wie möglich aneinander angleich, um eine bessere Vorhersagbarkeit zu erhalten, oder?

Meine Erfahrung zeigt, dass es tatsächlich oft sinnvoll, und auch ohne größere Probleme möglich ist, Anforderungen in kleinere Häppchen aufzuteilen, als es im Moment der Fall ist. Entscheidend ist dabei nur, dass ich hinterher immer noch fachlich geschnittene Aufgaben haben, die jede für sich einen Mehrwert bringt (der auch darin bestehen kann, mir wertvolles Feedback zu liefern). Wenn wir unsere Anforderungen kleiner schneiden, werden sich die Größen evtl. annähern, aber eine Garantie gibt es noch nicht. Will ich mir sicherer sein, müsste ich vorher ziemlich viel Aufwand in Schätzungen und Analysen stecken. Es mag Situationen geben, in denen diese Aufwände gerechtfertigt sind, meistens sind sie es jedoch nicht. Und selbst, wenn ich diesen Aufwand investieren möchte: Es bleiben Schätzungen, und wir wissen immer erst hinterher, wie gut sie waren.

Oft ist der Mittelweg erfolgversprechend: Anforderungen werden sehr groß klassifiziert, z.B. mit T-Shirt-Größen wie S, M, L und XL. Solche „Schätzungen" kann das Team in der Regel innerhalb weniger Minuten abgeben - und für viele Zwecke sind sie gut genug.

Ticketgrößen und Durchlaufzeiten

Wenn man genauer darüber nachdenkt, interessieren uns die Größen der Aufgaben gar nicht so sehr. Viel wichtiger sind die Durchlaufzeiten (Lead Times), also die Zeit, die wir benötigen, um eine Aufgabe zu erledigen. In unserem Kopf erstellen wir automatisch einen linearen (oder sogar exponentiellen) Zusammenhang zwischen beiden Größen: Wenn Aufgabe A doppelt so groß ist wie Aufgabe B, dann wird die Durchlaufzeit auch (mindestens) doppelt so lang sein. Wenn ich also irgendeine Art der Planung machen möchte, muss ich doch die unterschiedlichen Ticketgrößen berücksichtigen und ins Verhältnis setzen, oder? Erstaunlicherweise lautet die Antwort fast immer: Nein!

Dieses scheinbare Paradox erklärt sich dadurch, dass die Ticketgrößen zwar Einfluss auf die reine Bearbeitungszeit (Touch Time) haben, aber nicht (oder nur sehr wenig) Einfluss auf die Wartezeiten. In fast allen Organisationen, die Kanban einführen, wird der Löwenanteil der Durchlaufzeiten durch die Wartezeiten aufgefressen – zumindest wenn man über die reine Entwicklung hinausgeht und auch Prozesse wie das Deployment mit betrachtet. Die Bearbeitungszeit spielt nur eine untergeordnete Rolle. Wer ein elektronisches Kanban-Tool verwendet, kann sich dies in so genannten Flow Efficiency Diagrams ansehen. Oft beträgt der Anteil der Wartezeiten 80% oder mehr!

So lange wir also große Warteschlangen in unserem Prozess haben, brauchen wir uns um unterschiedliche Ticketgrößen keine großen Gedanken machen, sondern sollten stattdessen darüber nachdenken, wie wir diese Warteschlangen verkleinern können. Wer sicher gehen möchte, kann eine grobe Klassifizierung der Tickets nach T-Shirt-Größen vornehmen und hinterher kontrollieren, wie lang die einzelnen Durchlaufzeiten waren. Oft gibt es keinen beobachtbaren Effekt. Ein Teilnehmer der genannten OpenSpace-Session hat sogar berichtet, dass in seinem Team die S-Tickets längere Durchlaufzeiten haben als die M-Tickets!