Scrum, Kanban and Naked Planning

Some teams start with Scrum, excel with it and then adapt Scrum to go even further. Some of these teams dismiss interations and claim to do Kanban.

Other teams start with Kanban, eliminate columns of their Kanban board, reduce WiP and increase teamwork.

The results are very similar: There is a short backlog of things that create customer value (sometimes called Minimal Marketable Features, MMFs). The team picks the item with the highest priority and splits it into smaller User Storys or Tasks. When an MMF is completed it will be delivered. That’s it. The would result in a 3 column board: ToDo, Doing, Done. This board design is similar to a Scrum taskboard but the “process” is different. Since there are no iterations there is no distinction between a product focused backlog and an iteration focused backlog.

The interesting thing here is that this is mainly what Arlo Belshee named “Naked Planning”. He did that already in 2007 (perhaps even earlier) but only few people recognized it! Nowadays Naked Planning is sometimes reframed to be simplified or small Kanban.

Perhaps both of the above teams should say they are doing Naked Planning (or trying to do) and try to improve even further by having a deeper look at Arlos work (like doing Single Piece Flow for MMFs and limiting the number of MMFs in ToDo zu seven).

As far es I know this video is Arlos first description of Naked Planning (2007): http://www.youtube.com/watch?v=6t4bZtnnQJA

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.

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

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

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.

Kanban: Wer will schon ein Bottleneck sein?

In einem Kanban-Projekt habe ich ein interessantes zwischenmenschliches Problem. In Kanban versuchen wir, sinnvoll mit den Bottlenecks umzugehen, um die Durchlaufzeiten zu reduzieren.

Im Rahmen der Theory of Constraints gibt es sogar ein standardisiertes Verfahren zum Umgang mit Bottlenecks:

1. Identify. Identify the bottleneck of the system.
2. Exploit. Exploit this bottleneck, making its throughput efficient by changing processes, equipment maintenance procedures, training, policies, etc.
3. Subordinate: Subordinate the throughput of all other work centers to this work center.
4. Elevate. Invest in this work center to increase its throughput – add equipment, manpower, etc.
5. Inertia. Start the process over on the line to determine the new bottleneck.

Das ganze kommt aus einer allgemeinen Systemtheorie und ist natürlich in der Produktion sehr wichtig und auch nützlich. Kanban für die Softwareentwicklung möchte die Theory of Constraints für die Softwareentwicklung auch anwenden. Und da lauert eine Fußangel, die ich auch nicht vorhergesehen habe.

Bei Kanban für die Softwareentwicklung bilden meistens Menschen das Bottleneck. Und wenn wir jetzt beginnen, diese als Bottleneck zu bezeichnen, fühlen sie sich häufig angegriffen. “Ich bin doch kein Bottleneck. Ich tue doch mein Möglichstes.” etc. Auch wenn niemand diese Menschen angreifen wollte, sind sie nun zunächst in einer Verteidigungshaltung. Und das ist die denkbar schlechteste Voraussetzung dafür, mit diesen Menschen Veränderungen im Prozess und in den Arbeitsweisen herbeizuführen.

Ich habe dafür bisher keine Patentlösung. Der erste wichtige Schritt ist sicherlich, sich dieses Problems bewusst zu sein.

Kanban ohne Stress?

Ich begleite jetzt schon eine Weile ein Kanban-Team bei einem Kunden und mache dort ganz interessante Erfahrungen.
Eine “Falle” bei Scrum ist das Commitment auf das Sprint-Ziel. Es kann so missverstanden werden, als wäre es eine Garantie des Teams. So passiert es leider immer wieder, dass Teams über einen längeren Zeitraum Überstunden ohne Ende schieben mit den bekannten Ergebnissen: miese Qualität, schlechte Arbeitsmoral, Burnout, etc.
Wenn das Commitment zu solchen Problemen führt, handelt es sich meiner Meinung nach um einen Fehler bei der Scrum-Implementierung. Aber trotzdem tritt dieser Fehler relativ häufig auf.

Kanban hat dieses Problem nicht. Es gibt keine Sprints/Iterationen und auch kein Commitment auf Sprint-Ziele.

Allerdings: Vor kurzem musste ich ein Teammitglied vertreten. Bei dem Kunden gibt es gleich zu Anfang auf dem Kanban-Board eine Spalte, in der die Tickets landen, wenn es einen technischen Lösungsvorschlag der Entwickler gibt. Wenn dieser akzeptiert wird, wird das Ticket in die nächste Spalte verschoben und die Entwicklung kann beginnen.
Ich war nun für die Freigabe der Tickets vorantwortlich und natürlich brauchte ich dafür viel länger als das Teammitglied, das ich vertreten habe. Ich wurde also zum Bottleneck im System. Und da war ich ganz plötzlich doch im Stress. Ich wusste, dass 10 Leute oder mehr ohne Arbeit dastehen, wenn ich nicht möglichst schnell die Tickets freigebe. Und ich würde auch bis spät in die Nacht arbeiten, um meine Teamkollegen mit ausreichend Arbeit zu versorgen.

Ähnlich wie bei den Scrum-Commitments handelt es sich hier um eine fehlerhafte Implementierung von Kanban. Tatsächlich ist die Existenz des Bottlenecks ein organisatorisches Problem. Dass meine Teamkollegen keine Arbeit mehr haben, ist gewollt. Es soll das eigentliche Problem deutlich zeigen und dann sollen wir als Team eine Lösung dafür finden und das Bottleneck beseitigen.

Hier scheint mir kein relevanter Unterschied zwischen Scrum und Kanban zu existieren: Beides kann missverstanden werden und so ein Missverständnis kann in Überlastung einzelner oder aller Teammitglieder enden.