Nabnak

Just a thought experiment: What do you get when reversing Kanban? Obviously the name of reversed Kanban would be Nabnak – at least it has a fancy name.

Kanban has two key properties:

  1. Limit work in progress to an upper limit with a preference for lower limits.
  2. Pull from upstream processes.

Therefore in Nabnak you would

  1. Ensure that work in progress never falls below a bottom limit with a preference for higher limits.
  2. Push work to downstream processes.

OK, that sounds completely ridiculous. But when would you possibly do such a thing. Perhaps when two conditions hold true:

  1. Developers are so expensive that a high utilization outperforms all other metrics.
  2. At the same time developers are too dumb to pull work. Somebody has to push the work to them.

These two conditions seem mutually exclusive. Therefore Nabnak is in fact complete nonesense. But guess what: I am not the inventor of Nabnak – I just gave it a fancy new name. Nabnak was formerly known as waterfall.

You may not like Kanban but it is not a new name for waterfall. If there is a new name for waterfall it is reversed Kanban: Nabnak.

P.S.: In fact there may be useful applications of a minimum work in progress limit for certain columns of a Kanban board. I may blog about that in another article.

Buchempfehlungen zu lösungsorientiertem Coaching

In der letzten Zeit sind lösungsorientierte Ansätze (im Gegensatz zu problemorientierten Ansätzen wie Root-Cause-Analysis) etwas bekannter geworden. So haben wir auch beim Retrospektiven-Training am 25.08.2010 in Hamburg die lösungsorientierten Ansätze dabei. Die Grundzüge der Lösungsorientierung hatte ich bereits in einem vorigen Blogpost erklärt.

Nützliche Literatur zu dem Thema findet sich z.B. in den beiden Büchern “Coaching – erfrischend einfach” von Daniel Meier und Peter Szabo sowie “Wege zur erfolgreichen Teamentwicklung” von Daniel Meier.

Das erste Buch erklärt die Ideen und Techniken des lösungsorientierten Coachings auf individueller Ebene. Der Hintergrund ist allgemeines Coaching und nicht speziell IT. Die beschriebenen Techniken lassen sich aber leicht auf IT-Kontexte (z.B. für die Arbeit als ScrumMaster) übertragen. Das Buch ist angenehm kurz und leicht verständlich geschrieben.

Das zweite Buch beschreibt, wie man Lösungsorientierung für Teams einsetzt. Auch dieses Buch ist leicht verständlich geschrieben.

Wer sich näher mit dem Thema Lösungsorientierung beschäftigen möchte, dem lege ich diese beiden Bücher als Einstieg nahe (und natürlich das oben beschriebene Retrospektiven-Training 🙂

Retrospektiven-Training am 25.08.2010 in Hamburg

Retrospektiven sind das Mittel in agilen Projekten, um die Entwicklung kontinuierlich zu verbessern. Mit der Qualität der Retrospektiven steigt und fällt das Potenzial zu Verbesserung. Es ist also extrem wichtig, dass Retrospektiven qualifiziert vorbereitet und moderiert werden.

it-agile bietet am 25.08.2010 ein eintägiges Training zur Vorbereitung und Durchführung bon Retrospektiven an. Es eignet sich für alle, die Retrospektiven durchführen wollen, z.B. für ScrumMaster.

Ich werde das Training mit Josef Scherer durchführen, der wie ich langjährige Erfahrungen in agilen Projekten mitbringt.

Die Anmeldung und mehr Infos zum Retrospektiven Training findet Ihr hier:http://www.it-agile.de/retrospektiven-schulung.html

Lösungs- vs. Problemorientierung

Klassischerweise geht man Probleme problemorientiert an. Man definiert das Problem und versucht dann, seiner Wurzelursache (Root-Cause) auf den Grund zu gehen. Beseitigt man die Wurzelursache, verschwindet das Problem dauerthaft. Dieser Ansatz findet sich sehr ausgereift bei Toyota, z.B. in Form des 5-Whys-Ansatz (5 mal “Warum?” fragen).

Als Alternative gibt es die sogenannte Lösungsorientierung. Diesen Ansatz gibt es auch schon lange, aber er wird erst jetzt populärer. Beim lösungsorientierten Ansatz versucht man nicht, die Ursachen für Probleme zu analysieren. Stattdessen sucht man direkt nach Lösungsansätzen. Das geschieht z.B. so, dass man fragt, ob es Situationen oder Zeiten gab, in denen das Problem nicht oder weniger stark aufgetreten ist. Die gibt es eigentlich immer. Und dann fragt man, was in diesen Situationen anders war. Und diese andere versucht man dann, wieder herzustellen bzw. zu verstärken.

Problemorientierte Ansätze funktionieren offensichtlich nur dann, wenn es eine stabile und nicht zu komplexe Problem-Ursache-Beziehung gibt. Das ist z.B. in Build-Systemen der Fall oder eben in der Produktion bei Toyota. Wenn am dem Problem Menschen beteiligt sind, ist das häufig nicht der Fall. Dann hat man fluktuierende Ursachen oder die Beziehungen zwischen Problem und Ursachen sind so komplex, dass wir sie nicht analytisch durchdringen können.

Ich habe solche Situationen in Retrospektiven schon mehrfach gesehen. Da war es so, dass bei der Root-Cause-Analysis letztlich nur ein schlappes “OK, wir geben uns mehr Mühe” als Maßnahme herauskam. Oder es kamen konkrete Maßnahmen raus, aber nach deren Umsetzung war das Problem immer noch unverändert da. Und wieder und wieder…

In diesen Fällen kommt man mit problemorientierten Ansätzen also nicht weiter. Wenn man weiterkommen will, sind lösungsorientierte Ansätze Erfolg versprechender. Dabei besteht natürlich das Risiki, dass man die eigentliche Ursache nicht beseitigt und die ganze Zeit nur Work-Arounds baut. Aber das ist immer noch besser, als mit Aufwand Ursachen zu analysieren, die auf jeden Fall sinnlose Maßnahmen hervorbringen.

Ein weiterer Vorteil lösungsorientierter Ansätze ist, dass sie häufig viel schneller sind. Um eine Root-Cause-Analysis vernünftig durchzuführen, brauche ich in einfachen Fällen mind. 30 Minuten. Mit lösungsorientierten Ansätzen ist man häufig schon nach 5 Minuten durch.

Ich gucke da nicht so drauf, dass lösungsorientierte Ansätze generell besser sind als problemorientierte. Es sind einfach zwei Werkzeuge, die ich in unterschiedlichen Situationen anwende.

Ich führe zusammen mit Josef Scherer am 25.08.2010 in Hamburg eine Retrospektiven-Schulung durch, in der sowohl problem- wie auch lösungsorientierte Ansätze durchgenommen werden. Näheres dazu findet sich bei it-agile.

Code-Katas in CodersDojo.com

Code-Katas erfreuen sich zunehmender Beliebtheit: kleine Programmieraufgaben, die man mehrfach löst und jede Lösung ein wenig verbessert.

CodersDojo.org unterstützt Code-Katas. Nach Aufruf von http://codersdojo.org erscheint die Start-Seite.

Mit “Enter the Dojo” betreten wir das virtuelle Dojo, in dem wir die Kata durchführen (bisher nur in Ruby).

Im rechten Bereich wird ein Dummy-Test vorgeschlagen. Wir ersetzen den Dummy-Test durch den ersten (Test-)Schritt unserer Kata (in diesem Fall die Fibonacci-Reihe). Um die Angelegenheit möglichst einfach zu gestalten, schreiben wir Produktiv- und Testcode in dieselbe Datei.

Durch click auf “Run” führen wir unseren Test aus. Links wird das Ergebnis der Testausführung angezeigt.

Jetzt schreiben wir soviel Produktivcode, dass der Test durchläuft.

So entwickeln wir schrittweise testgetrieben unsere Lösung.

Durch click auf “Finish” gelangen wir zur Auswertung der Kata.

Dort sehen wir die Gesamtdauer der Kata, die Anzahl der Schritte und eine Visualisierung der TDD-Schritte (rot, grün).

Zur Verbesserung der eigenen Fähigkeiten können wir die Kata einem Kollegen zur Kommentierung zur Verfügung stellen. Dazu senden wir ihm den Link, der unten auf der Seite angegeben ist. Öffnet der Kollege den Link, sieht er den ersten Schritt der Kata. Links sieht er den Code vor und nach dem ersten “Run”. Rechts steht ein Feld für seine Kommentare zur Verfügung.

Der Kollege kann durch die Kata navigieren. Wo ihm etwas auffällt, schreibt er seinen Kommentar zu dem Schritt dazu.

Probiert es einfach mal aus und gebt uns Feedback zu CodersDojo.

XP-Days Germany 2010 in Hamburg

Die XP-Days Germany finden dieses Jahr vom 25.-27.11.2010 in Hamburg statt. Der Call for Sessions ist raus: http://www.xpdays.de/twiki/bin/view/XPDays2010/CallforSession

Wie schon in den letzten Jahren gibt es einen offenen Review-Prozess für die Einreichungen. In diesem kann jeder Feedback zu den Einreichungen geben und die Einreicher können auf Basis des Feedbacks ihre Einreichungen verbessern. Es lohnt sich also, seine Vorschläge sehr früh einzureichen. Iterativ können sie dann während des Review-Prozesses verbessert werden.

Zombie Kanban, or: Don’t forget the soul!

Please get me right. This is not a rage against Kanban. It is for fun and I think there is some truth in it.

from danhollisterduck (flickr)

Kanban installs a continuous improvement process. It does not predefine the direction of the improvement, since it does not define a value system. Therefore Kanban itself is not agile and it is not anti-agile. It just doesn’t care.

To define a proper value system is up to the companies using Kanban. Do they value Scrum-like teamwork over silos or vice versa? Do they value face-to-face communication over written documents or vice versa? And so on …

I suspect the definition of an underlying value system is often not done. And then you get Zombie Kanban, something without a soul. Zombies have an impetus to eat others brains but what is their real (long term) goal? Zombie Kanban has the impetus to shorten cycle times but without having a purpose. (Of course it’s better to shorten cycle times than eating other peoples brains. But that is simply not enough 🙂 )

Just installing an improvement process is not sufficient. You have to define a value system or purpose. (See also tip #2 of this blog post from LSS Academy).

Otherwise you can order some of these for your company:

from Shiny Things (flickr)

Lernen im 1. Quartal 2010

Damit habe ich mich im 1. Quartal 2010 beschäftigt und das habe ich dabei gelernt:

  • Ich habe deutlich mehr Erfahrungen mit Kanban in echten Projekten gesammelt und hatte einige Aha-Erlebnisse. Wenn ich mal dazu komme, werde ich darüber bloggen.
  • Ebenfalls zum Thema Kanban habe ich den Kanban-Coaching-Workshop in Stockholm bei David Anderson besucht. Interessanterweise haben die Kanban-Projekte und der Workshop auch dazu geführt, dass ich Scrum noch besser verstanden habe.
  • Ich habe “Clean Code” von Robert Martin gelesen. Mein Blogartikel dazu findet sich hier.
  • Ich habe eine ganze Menge Rails programmiert, um mich selbst bei Laune zu halten. Im selben Projekt habe ich als Product-Owner gearbeitet, was auch wieder interessante Erkenntnisse mit sich gebracht hat. Das zugehörige Projekt wird in Kürze veröffentlicht.
  • Auf den XP-Days habe ich an einer Open-Space-Session zum lösungsorientierten Coaching bei Josef Scherer teilgenommen. Das fand ich sehr interessant und habe mich danach weiter in dem Thema vertieft. Dazu werde ich ebenfalls mal einen Blog-Eintrag schreiben, wenn ich mal wieder Zeit dazu habe.
  • Und ich habe brav weiter schwimmen geübt. Brustschwimmen ist jetzt OK. Jetzt muss ich mich dem Kraulen stärker widmen.

Verglichen mit den vorhergehenden Quartalen ist das eine eher dürftige Ausbeute. Ich glaube, das liegt an dem Winter. Ich mag’ den Winter nicht. Der demotiviert mich. Aber jetzt wird es sicher besser 🙂

Scrum vs. Kanban: Ziel und Weg

Letztes Wochenende hatte ich eine interessante Diskussion mit Markus Andrezak, Bernd Schiffer und Henning Wolf über Unterschiede und Gemeinsamkeiten von Scrum und Kanban. Tatsächlich finde ich, dass die Unterschiede zwischen Scrum und Kanban verwischen, wenn ein fähiger Coach am Werk ist. Warum sollte man in Scrum nicht auch während eines Sprints releasen? Und warum sollte man in Kanban nicht auch Aufwände schätzen, wenn man so bessere Terminaussagen treffen kann? Und warum sollte man in Scrum kein Kanban-Board haben dürfen? Und häufig legen organisatorische Randbedingungen auch bei Kanban ein Iterationskonzept sehr nah.

Bei der Diskussion haben wir einen Punkt herausgearbeitet, den ich besonders hilfreich für die Differenzierung finde: Scrum hat ein bestimmtes Ideal vor Augen. (Wenn man das erreicht hat, sollte man sich natürlich noch weiterentwickeln.) Aber erstmal hat das Ziel eine klare Form.

Kanban hingegen installiert einen Verbesserungsprozess und lässt offen, wohin genau die Reise geht.

Dadurch ist es sehr einfach, Kanban zu machen. Setzt man auf Scrum, hat man erstmal eine Transitionsphase vor sich – die kann sehr lange dauern und durchaus schwierig sein. (Und so lange macht man eigentlich noch nicht richtig Scrum.) Natürlich kann man während der Transition auch in sehr kleinen Schritten vorgehen und damit eine behutsame Einführung von Scrum erreichen – ähnlich wie bei Kanban.

Auf der anderen Seite kann man mit Scrum etwas tun, was man mit Kanban nicht so gut tun kann: Man kann es als Revolution einführen. Und das kann tatsächlich sinnvoll sein. Ich habe immer wieder mit Unternehmen zu tun, die mit dem Rücken zur Wand stehen. Die brauchen einen schnellen und radikalen Wandel, wenn sie überleben wollen. Mit Kanban ist denen nicht geholfen. Die brauchen keinen Prozess, der sie schrittweise und risikoarm etwas besser macht. Die brauchen etwas, dass sie schnell viel besser macht. Und dafür sind sie bereit, auch die entsprechenden Risiken einzugehen.

Kanban: Definition of Lead Time and Cycle Time

Important: Cycle time as a concept can have multiple meanings. This blog post uses just one specific meaning. Alexei Zheglov has a more accurate discussion of the cycle time concept.

When doing Kanban for software development measuring cycle and lead times is important but often the terms are confused or defined in a fuzzy way. Here is a useful definition from the “Lean and Kanban” blog:

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team. Bugs are reported via tickets in a ticket system like Bugzilla, Jira or Mantis. When the bug is detected a ticket is created and when the bugfix is live, the ticket is closed. This whole period of time is the lead time. The lead time is the time and not the effort. You may have a lead time of 100 days and only have to work 1 hour to fix the bug. Sometime you start working on the bug. The cycle time is the time from the start of the work until the bugfix is live. Again the cycle time is not the effort. Lead time can’t be shorter than cycle time. Often lead time is a lot longer. In the context of maintenance there is often a SLA (Service Level Agreement) in place that defines in which time frame you have to fix a bug. Often the SLA defines a resolution time. That is the same as the lead time: Most SLAs also define a response time. That is the time available until the team has to respond to a new bug ticket: is it really a bug and what is the priority. With these definitions in place it is obvious that the lead time is what is relevant from the business perspective. The cycle time is what the team can influence by itself by changing its work process. To reduce lead times one can (and should) reduce cycle time. But often the time before the work starts is really long so this wait time should be reduced also.