Dienstag, 27. Dezember 2011

Kaizen and Snails

For me Kaizen is the core of Kanban. And as a model for Kaizen, I still find Deming‘s PDCA Cycle very useful. Many people out of the Kanban community find Boyd‘s OODA Loop more suitable. One reason for this is that PDCA comes from the production world and when dealing with Software Kanban, we often have the problem of justifying ourselves why we use models from the production, although we operate in the domain of knowledge work. The other argument for the OODA Loop is: PDCA focuses rather on the past while OODA is more focused on the future. I think the old saying applies here as well: "All models are wrong. But some are more useful than others." Depending on the context, one might find the one or the other model more useful. And in my opinion, it is crucial that we have at least an idea of how to achieve a culture of continuous improvement – and what obstacles we need to remove in order to get there. Whatever model helps us here, should be welcome!
One phenomenon that sometimes can be observed as an obstacle to such a Kaizen culture can be called the PD-Snail. And to show and discuss this phenomenon, the PDCA cycle is very useful.
The basic idea of PDCA is that we first agree upon the next small step for improvement (Plan). We then try this out (Do), check the results and reflect on them (Check). After this we decide in the Act step, whether we want to roll out and standardize the results (however this standardization may look like in detail), if we want to change something in our experiment, or whether we want to abort the whole expermient and try something completely different.


So far so good. In practice, however, we sometimes observe something different: We make a plan (P) and begin to implement it (D). But instead of checking the results seriously (C) and adapting to our new findings (A), we immediately start making a new plan (P ') and implementing it (D'). C
' and A' are again not taken too seriously (yes, it is not always very much fun to go through the whole cycle), so that even the next plan (P'') is formed, etc. The result is the PD Snail that looks like this:


The advantage of this visualisation is that you have a basis to discuss various aspects of improvement:
  • Does the PD-Snail look familiar to us?
  • If so, what does that says about our focus?
  • Is it a good thing to start more more and new improvements, without ever bringing them to the point that we can at least learn something from it? Or is this pure waste? (This is a rhetorical question)
  • Do we really have to deal with this snail? Should we perhaps limit the number of current improvements?
  • What else can we do to become better at improving?
  • ...

And there‘s another big problem with the PD-Snail (thanks to my colleague Markus Gärtner for pointing this out): According to the Satir Change Model, any change will lead to decreased performance and a state of chaos. If we (as indivicuals, teams, or organisations) are not capable of stabilizing, then we won’t improve, but instead we will harm ourselves. In order to stabilize, we often need a long breath (and probably a lot of small adjustments). But the PD-Snail does not have a long breath. It “jumps” (okay, snails cannot really jump) from change to change without ever completing something. So in the long run the PD-Snail might lead to poorer and poorer performance, although it was aimed to do the complete opposite!

Without a doubt, the PD-Snail is as a rather unpleasant fellow. But it gets even worse! May I introduce: The
P-Snail. Here, the C-aspect of the improvement is also omitted. Instead, a great plan after another is thrown into the room: "We have to do A." "Yeah. And we could also do B." "Good idea. And how about C?" This phenomenon is known as paralysis. And in another context we call it the students‘ imperative: "Someone really should clean up the kitchen " (general consent among all room mates before everyone gets himself another beer and disappears towards the television set).

Another relative is the D-Worm - also known as
blind activism. Here we act over and over again, without ever planning even the smallest bit. That wouldn‘t be bad in itself, because in some situations it may indeed be quite useful to try things just to see what happens (according to the Cynefin Framework, this would be be a reasonable approach for the chaotic domain). However, this activism seems to be of little help if there is no reflection on the outcome afterwards.

At the end we should briefly mention the
Retrospectives P-Snail: This means, we‘re only whining about lost chances: "We should have done A.", "Yes, exactly. And if we only had tried B!" Of course it is helpful to regularly look to the past and think about what opportunities we may have missed. But if it never results in ideas and actions for the future, then we should probably do something more useful instead.

For some teams, the idea of the PD-Snail will hopefully be useful. Others might find it silly. I think it's a useful little tool to discuss and reflect on improvements. And it's a good way to show that improvements cannot simply be established on the fly, but that often hard work and patience are needed.
Please leave a comment, tell me what you think and share your experiences with different types of snails!

Freitag, 23. Dezember 2011

Die Weihnachtsretrospektive

Zusammen mit meinem Freund, Kollegen und Chef Henning Wolf habe ich dieses Jahr wieder eine it-agile-Weihnachtsgeschichte geschrieben. Ich hoffe, Sie gefällt euch!



























Frederick, 8 Jahre
Heute haben wir was Lustiges gemacht: eine Retrospektive mit mir, Agathe, Papa, Mama und Oma. Papa hat gesagt, das hätte unsere Familie dringend nötig, weil unser Weihnachten immer so stressig ist. Das fing schon spannend an: Dort sollten nämlich Detektive gegen Agent A kämpfen. Klar, dass Papa sofort meine Aufmerksamkeit hatte. Nach einer langweiligen Einführung von Papa bekam jeder von uns einen ganzen Haufen von diesen Stinky Notes. Dort sollten wir raufschreiben, was wir an unserem letzten Weihnachtsfest blöd fanden und was gut war. Papa sagte, wir sollten keine Schuldigen suchen. Das fand ich gut. Außer bei Agathe, denn die war ja wirklich Schuld daran, dass ich kein Geschenk für Mama hatte.
Die Zettel klebten wir dann alle auf einen lange Bahn Geschenkpapier, die Papa an die Wand geklebt hatte. Das war unser kleines Teimlein. Komisch war, dass Papa meinte, für ihn würde Weihnachten erst im Dezember anfangen. Da hat Mama ihn schon ganz böse angesehen. Und für mich beginnt die Weihnachtszeit schon im September - wenn es die ersten Marzipanbrote gibt! Danach hat Papa die Zettel irgendwie in Gruppen sortiert und dabei so seltsame Sachen gemurmelt wie „Laster bilden“. Dann wollte er den Problemen so richtig auf den Grund gehen mit „Ruth, Klaus, Anna, Liese“, aber keiner von denen ist aufgetaucht. Dann wurde es irgendwie langweilig, und ich hab nicht mehr richtig zugehört. Zwischendurch gab es Ärger, weil ich da was falsch verstanden hatte. Von wegen „alles an die Wand schreiben, was uns stört“. Wenn Papa will, dass ich Sachen auf Zettel schreibe, anstatt direkt auf die Wand, dann soll er das auch so sagen! Ich musste dann noch irgendeine Version unterschreiben. Danach haben wir Maßnahmen beschlossen, wie das nächste Weihnachten noch besser wird. Ich habe vorgeschlagen, dem Weihnachtsmann die Rute wegzunehmen. Aber der Vorschlag wurde abgelehnt. Immerhin muss ich nicht wieder mit in die Kirche. Am Ende hat Papa einen Witz von Santa Claus erzählt, den ich nicht kapiert habe.
Nächstes Jahr kommt dann ein extremer Mode-Rater, um die Retrospektive durchzuführen. Und was das Ganze jetzt mit Agenten und Detektiven zu tun haben sollte, hab ich immer noch nicht kapiert.



Papa, 45 Jahre
Na bitte, wer sagt´s denn! Nachdem ich heute mit meiner Familie eine Retrospektive zu unserem letzten Weihnachtsfest durchgeführt habe, wird das in Zukunft deutlich besser laufen. Am Anfang habe ich erst mal erklärt, was eine Retrospektive ist und wozu man die durchführt. Nach der Agenda habe ich die Erste Direktive für Retrospektiven vorgestellt: Was auch immer wir feststellen: wir gehen davon aus, dass jede(r) sein/ihr Bestes gegeben hat, entsprechend den Möglichkeiten, dem Wissen und den Umständen zum jeweiligen Zeitpunkt.
Gestartet haben wir ganz klassisch mit einer Timeline, wo jeder positive und negative Ereignisse auf Sticky Notes (warum lacht Frederik immer, wenn er das Wort hört?) geschrieben hat und die an die Wand geklebt hat. Dann habe ich Cluster gebildet und zu unserem schlimmsten Problem (zu viel Stress zur Weihnachtszeit) eine Root-Cause-Analyse durchgeführt. Dabei ist dann herausgekommen, dass wir ganz unterschiedliche Erwartungen haben, wie ein schönes Weihnachtsfest aussieht und  was genau für uns der Wert von Weihnachten ist. Aus irgendeinem Grund hat Frederick dann mit einem Edding „ich will mehr Marzipan!“ an die  Wand geschmiert. Am Ende haben wir eine gemeinsame Vision für unser Weihnachten erstellt, die jedes Familienmitglied unterschrieben hat.  Und es sind 3 konkrete Maßnahmen herausgekommen, die wir nächstes Jahr durchführen wollen: Die Kinder bekommen nur jeweils drei Geschenke, die Christmesse ist freiwillig, und Oma übernimmt das Kochen.
Abgeschlossen habe ich die Retrospektive mit dem Witz, dass der Weihnachtsmann ja eigentlich Santa Cloud heißen müsste, weil er heutzutage so viele Gutscheine von iTunes und Amazon verschenkt.
Für die nächste Retrospektive organisiere ich dann einen externen Moderator.



Oma, 81 Jahre
Der Paul hat wieder so einen neumodischen Kram von der Arbeit mit uns ausprobiert: eine Retrospektive. Weil die Anderen Weihnachten immer so anstrengend finden (warum eigentlich?), wollte er daran etwas verbessern. Zuerst hat Paul umständlich erklärt, was genau eine „Retrospektive“ ist, wie man die durchführt und was auf der „Agenda“ steht. In meinem Kegelverein nennen wir so was ja einfach „Versammlung mit einer Tagesordnung“. Aber Paul wollte uns wohl beeindrucken. Die Kekse, die auf dem Tisch standen, waren ganz schön trocken. Aber Renate hat es ja auch nicht so mit dem Backen. Nachdem wir aufgeschrieben hatten, was wir toll und nicht so toll am letzten Weihnachtsfest fanden, hat Paul dann diese viel zu kleinen Zettel umständlich an der Wand hin- und hergeschoben und eine lange Rede gehalten. Da hab ich dann heimlich ein kleines Nickerchen gemacht. Aufgewacht bin ich, weil es plötzlich ganz laut wurde, als Renate mit Frederick geschimpft hat. Der hatte wohl wieder irgendeinen Blödsinn gemacht.
Dann wurde es doch noch schön besinnlich, als wir gemeinsam eine Vision für unser nächstes Weihnachtsfest erstellt haben: Wir möchten gemeinsam ein entspanntes Fest in gemütlicher Atmosphäre verbringen, bei dem wir alle zusammen sind und gemeinsam etwas unternehmen, zum Beispiel singen oder spielen. Geschenke stehen dabei nicht an erster Stelle.
Schade finde ich, dass wir nicht mehr alle zusammen in die Kirche gehen. Aber wenigstens gibt es nächstes Jahr ein vernünftiges Weihnachtsessen, weil ich das Kochen übernehme.
Warum der Weihnachtsmann jetzt ein Dieb sein soll („Santa klaut“), habe ich nicht verstanden.

it-agile wünscht ein frohes Fest und Guten Rutsch!

Sonntag, 18. Dezember 2011

Von Kaizen und Schnecken

Kaizen ist für mich der Kern von Kanban. Als Modell für Kaizen finde ich nach wie vor den PDCA-Zyklus von Edwards Deming sehr nützlich. Allerdings halten viele Leute aus der Kanban-Community den OODA-Loop von Boyd inzwischen für besser geeignet. Ein Grund dafür liegt darin, dass PDCA aus der Produktion kommt und wir in Kanban oft das Problem haben, uns dafür zu rechtfertigen, warum wir Modelle aus der Produktion anwenden, obwohl wir doch Wissensarbeit betreiben. Das andere Argument für den OODA-Loop lautet: PDCA legt den Fokus stark auf die Vergangenheit, während OODA stärker auf die Zukunft fokussiert. Ich finde, auch hier gilt der Spruch: „Alle Modelle sind falsch. Aber einige sind nützlicher als andere.“ Je nach Kontext kann das eine oder andere Modell nützlicher sein. Und entscheidend ist meiner Meinung nach in erster Linie, dass wir uns überhaupt darüber klar werden, wie wir es schaffen wollen, eine Kultur der kontinuierlichen Verbesserung hinzubekommen.
Ein Phänomen, das sich manchmal als Hindernis für so eine Kaizen-Kultur beobachten lässt, nenne ich die PD-Schnecke. Und dies lässt sich sehr schön am PDCA-Zyklus zeigen und diskutieren.
Die Grundidee von PDCA lautet, dass wir uns den nächsten kleinen Verbesserungsschritt überlegen (Plan), diesen ausprobieren (Do), dann die Ergebnisse ansehen und darüber reflektieren (Check). Dann entscheiden wir im Schritt Act, ob wir die Ergebnisse ausrollen und standardisieren möchten (wie auch immer diese Standardisierung im Einzelnen aussehen mag), ob wir erst noch einmal in einem weiteren kleinen Experiment eine kleine Änderung ausprobieren möchten, oder ob wir diesen Plan für gescheitert erklären und etwas komplett Anderes ausprobieren.

So weit so gut. In der Praxis beobachtet man aber manchmal eine andere Variante: Man schmiedet einen Plan (P) und fängt an, ihn zu implementieren (D). Anstatt dann aber die Ergebnisse ernsthaft zu überprüfen (C) und ggf. nachzusteuern (A), wird schon wieder der nächste Plan ersonnen (P‘) und in die Tat umgesetzt (D‘). C‘ und A‘ werden wieder nicht so ernst genommen (es bringt ja auch nicht besonders viel Spaß, so lange am Ball zu bleiben), so dass schon der nächste Plan (P‘‘) entsteht usw. Das Ergebnis ist die PD-Schnecke, die folgendermaßen aussieht:

Das Schöne an dieser Darstellung ist, dass man eine Grundlage hat, um über verschiedene Aspekte von Verbesserung zu diskutieren:
  • Findet sich die PD-Schnecke auch bei uns?
  • Wenn ja: Was sagt das über unseren Fokus?
  • Ist es positiv zu bewerten, immer neue Verbesserungen anzufangen, ohne diese jemals so weit zu bringen, dass man wenigstens etwas daraus lernen kann? Oder ist das nicht die reinste Verschwendung? (Dies ist eine rhetorische Frage)
  • Warum haben wir es mit dieser Schneckenplage zu tun? Sollten wir vielleicht die Anzahl an aktuellen Verbesserungsmaßnahmen limitieren?
  • Was können wir sonst noch tun, um besser darin zu werden, uns zu verbessern?
  • ...

 Die PD-Schnecke ist als ein eher unangenehmer Zeitgenosse. Aber es geht noch schlimmer. Darf ich vorstellen: Die P-Schnecke. Hier wird auch der C-Aspekt der Verbesserung weggelassen. Stattdessen wird ein toller Plan nach dem anderen in den Raum geworfen: „Wir müssten mal A tun.“, „Stimmt. Und wir könnten auch B tun.“, „Gute Idee. Und wie wäre es mit C?“ Dieses Phänomen ist in anderem Kontext übrigens auch als der WG-Imperativ bekannt: „Jemand müsste mal die Küche aufräumen!“ (allgemeine Zustimmung aller WG-Mitbewohner, bevor sich jeder ein neues Bier holt und vor den Fernseher setzt).

Eine andere Verwandte ist die D-Schnecke - auch bekannt als "blinder Aktionismus". Hier wird immer wieder gehandelt, ohne vorher zu planen. Das wäre an sich noch gar nicht so schlimm, denn in einigen Situationen kann es ja durchaus sinnvoll sein, Dinge einfach auszuprobieren, um zu sehen, was daraus entsteht (nach dem Cynefin-Modell wäre das für die chaotische Domäne ein angemessenes Vorgehen). Allerdings scheint dieser Aktionismus wenig hilfreich, wenn danach keine Reflexion über das Ergebnis stattfindet.  

Am Ende noch zur Retrospektiven P-Schnecke: Hier wird nur noch über vergangene Chancen gejammert: „Wir hätten mal A machen sollen!“, „Ja, genau. Und hätten wir damals doch bloß B ausprobiert!“ Natürlich ist es hilfreich, regelmäßig in die Vergangenheit zu blicken und sich zu überlegen, welche Chancen man vielleicht verpasst hat. Aber wenn daraus niemals Ideen und Maßnahmen für die Zukunft resultieren, dann sollte man sich das wohl lieber schenken.

Für einige Teams wird die Idee der PD-Schnecken hoffentlich hilfreich sein. Andere können damit vielleicht nichts anfangen. Ich finde, es ist ein nützliches kleines Tool, um über Verbesserungen zu diskutieren und zu reflektieren. Und es ist eine gute Möglichkeit, um deutlich zu machen, dass man Verbesserungen nicht mal eben so nebenbei etabliert, sondern dass dafür oft harte Arbeit und ein langer Atem nötig sind.

Dienstag, 29. November 2011

What‘s the kanban in Kanban?

The original meaning of the word kanban is something like "signal card". David Anderson points out that this word was not invented by Toyota, but it is much older and was already used in medieval Japan. Here a craftsman or merchant had a wooden sign outside his shop so that every citizen walking by could see that the shop was open. Here the meaning of the sign was "Come in if you‘d like to buy my goods or services. They‘re available right now."
Of course the reason why we know the word "kanban" nowadays lies in the Toyota Production System. Here the kanban were paper cards (today E-kanban is used - an electronic system without physical cards). They were the key to Just In Time Production by enabling a pull system. Imagine a worker at the production line who is using a lot of screws. He could have two boxes with screws. As soon as the first box is empty, he sends a card (the kanban) back to someone upstream who gets new screws for him (transport kanban) or who even produces new screws (production kanban). The card contains all the information which is needed to replenish the screws: What kind of screws? How many? Where are they needed? And often the card is attached to the empty box (so the box could be a kanban itself). So in production kanban are used to control the inventory and to establish a pull system, where there‘s no big plan for ordering screws. Instead, the screws will be replenished according to the demand in the process.

What does that mean for Software Kanban, the method for incremental, evolutionary change? We all know that knowledge work is very different from production. But still many people and teams found out that some of the core principles like pull, limited work in progress, kaizen etc. are very useful in our domain as well - if we adjust them to our needs. When people explain Kanban to others, they often start with the Toyota Production System and then switch to Software Kanban. And now there‘s some kind of confusion coming in. Because kanban means "signal card" and many Kanban teams are using paper cards (index cards or sticky notes) on their boards, people think that both are the same. But they‘re not! The tickets on our boards are not signal cards in the original meaning of kanban. Why? Imagine they were. This would mean, that we would send our tickets back upstream every now and then to order new...New what? Now it becomes tricky. What would we order with these signal cards? New features? New ideas? And if the tickets really were signal cards, wouldn‘t that mean that they would never make it till the end of the value stream?  Instead they would circulate within a certain part of the value stream all the time.
No the tickets in Kanban are not kanban. They are token that represent tasks (features, user stories, bugs etc.) that are to be finished. Having tickets makes it easier to discuss and handle our tasks, because in knowledge work we usually cannot see them very well.
Does that mean that we do not have kanban when using Kanban? Yes, we do. But they are virtual. And they work differently than in production. Whenever we do not exceed our WIP limits, we have a kanban. Imagine, we have a limit of 3 in deployment and there´re only 2 tickets in progress. Then there‘s one space available, and that is the kanban - the signal for the people doing deployment to pull new work. The difference here is: They are allowed to pull new work from the upstream process (i.e. development), but they don‘t have to. The principle behind this is the same as in production: We want to control our work in progress and establish a pull system to avoid overload, decrease lead times, unhide problems, increase quality and discover improvement opportunities (in addition to this we want to create slack, which might be another difference to production). But the techniques for doing so are quite different.
When I said that the kanban are virtual, this was not entirely true. Even in Kanban you can have visual kanban. Some teams use physical spaces or clips for indication their WIP limits. Here you can see the kanban, whenever there‘s a free space or clip.

This is a nice visualisation, but the downside of it is that you cannot divide your columns in "doing" and "done", because you never know how the actual number of tickets is distributed between these sub-columns. In this case you have to use other techniques for indicating which tickets or done and which are not. For example you can rotate those tickets that are done 45 degrees so that you get "diamond shaped tickets" (see also chapter 6 in Anderson 2010).

Montag, 21. November 2011

The chocolate bar

This October, I gave a Pecha Kucha at the conference Lean Kanban Central Europe in Munich. The title oft he talk was Pimp my Board, and I described 10 different ways teams might want do try out to improve their card wall.
You can watch the Pecha Kucha here:




One of this tricks is called „make it fun“. Here I told a little story about the startup jimdo When I visited them for the first time in 2010, I was fascinated by their creativity and by the many cool ideas which evolve from the teams. At their office the walls are covered with all kinds of visualisations and plenty of different card walls. When walking around, I saw a chocolate bar attached to one of their boards. When I asked about the purpose of this chocolate bar, they told me: „It´s like a little game: The first one who finishes 5 tasks, gets the bar.“



Although I received quite good feedback for my talk, there was some criticism on Twitter. The argument was that the chocolate bar is a kind of extrinsic motivation, and extrinsic motivation is problematic because it would kill intrinsic motivation. Daniel Pink talks a lot about this in his book and in this short, beautiful animated video To put in a nutshell, Daniel Pink says: Whenever you try to motivate people (in knowledge work) by offering them rewards, they will start working only for getting the rewards, not for achieving goals - and their performance will decrease instead of increasing.

I was familiar with all this and I generally agree. But I was completely puzzled that the jimdo example could fit into this pattern. I had a lot of discussion about this and thought it through several times. Now the whole thing is a lot clearer to me and I´d like to share my thoughts about why I still do not think that the chocolate bar in my example should be considered harmful.
1) If I get it right, the purpose of the chocolate bar was not to motivate people but to have more fun at work by playing a little game.
2) Even if you consider the chocolate bar an extrinsic motivation, it probably wouldn´t do any harm, because the incentive is too low. A child might kill for a candy – a well off knowledge worker will not. It would be a completely different story if we would exchange the chocolate bar with a 500 EUR note.
3) It was not a manager who attached the chocolate bar to the board and said: „Listen, I want you do work smarter. That´s why I offer you this chocolate bar for good performance.“ This sounds like a Dilbert comic strip, and I´m sure the team would have laughed at their boss if he had done so. Instead, the game was invented by the team itself. And that´s a big difference to me!
4) I´m convinced that you cannot judge the effects of things like the chocolae bar game or anything else without taking into consideration in what context you are acting. In this case the company culture is very important. I´ve never seen a company like jimdo that has such a great company culture. And I think this culture works like a shield and protects the people from many of the negative effects that might have occured in other contexts.

Sonntag, 30. Oktober 2011

Zu viel Innovation?

(want to read this post in English? Paste the text into http://wordmonkey.info/ - it works amazingly well!) 

Ich wundere mich in letzter Zeit immer wieder darüber, wie viele Firmen damit werben, wie innovativ sie sind. Entweder tragen Sie "Innovation" (oder Bestandteile daraus) schon im Firmennamen, oder sie haben einen Slogan o.ä., der anpreist, wie innovativ sie sind.
Angenommen, ich möchte einer Frau imponieren. Ist es dann eine gute Idee zu behaupten: "Ich bin übrigens total witzig"? Oder sollte ich nicht lieber einfach witzig sein, und ihr so meinen Humor beweisen?
Ähnlich ist es mit der Innovation. Wenn eine Firma behauptet, sie sei innovativ, dann weckt das bei mir Misstrauen. Falls sie wirklich innovativ ist, warum muss sie es dann behaupten? Warum ist sie nicht einfach innovativ? In diesem Sinne wäre es meiner Meinung nach viel cleverer, mit dem Slogan zu werben: "Wir sind nicht innovativ!" In einer Zeit, in der jedes Unternehmen damit wirbt, wie innovativ es angeblich ist, wäre es tatsächlich innovativ, das Gegenteil zu behaupten.

Aber ich habe noch ein anderes Problem mit Innovation, denn Innovation bedeutet ja eine große, sprunghafte Verbesserung. Das hört sich erst einmal klasse an. Aber brauchen wir wirklich ständig Innovationen? Und erwarten das unsere Kunden von uns? Ich glaube nicht!

  • Von meiner Krankenkasse wünsche ich mir, dass sie etwas längere Öffnungszeiten hat;
  • Von meinem Telefon-Anbieten wünsche ich mir, dass er endlich seine Tarife vereinfacht, so dass man die Unterschiede als Normal-Sterblicher verstehen kann. 
  • Von vielen Herstellern von Web-Tools wünsche ich mir, dass die Tools stabiler laufen und intuitiver zu benutzen sind;
  • Und von Suchmaschinen wünsche ich mir, dass die bessere Suchresultate liefern und vielleicht noch etwas schneller sind. 
Ist davon irgendetwas besonders innovativ? Nein! Natürlich freue auch ich mich, wenn es einmal wirkliche Innovationen gibt (die mir persönlich dann auch noch zugute kommen). Und für viele Unternehmen sind Innovationen sicherlich die einzige Chance, auf einen Markt zu gelangen oder sich am Markt zu behaupten. Aber ich habe den Eindruck, wir stehen uns mit unserer Vorstellung, es müsste immer alles furchtbar innovativ sein, oft selbst im Wege. Vermutlich gibt es sehr viele Situationen, in denen viele kleine Verbesserungen sinnvoller (und auch einfacher) sind als die großen Innovationen.

Dasselbe gilt nicht nur für Produkte, sondern auch für Prozesse. Im Buch Kaizen von Masaaki Imai gibt es dazu einen interessante Abschnitt. Der Autor argumentiert, dass es einen fundamentalen Unterschied zwischen westlicher und Japanischer Auffassung davon gibt, wie Verbesserung vonstatten geht und wer dafür zuständig ist. In unserer westlichen Denke findet Verbesserung in Form von Innovationen statt - und zuständig für diese Innovation ist das obere Management.
In Japan (zumindest im Lean Manufacturing) hingehen gibt es neben Innovation auch Kaizen als Weg zur Verbesserung, also die Verbesserung in vielen kleinen Schritten. Jeder Mitarbeiter im Unternehmen ist dafür verantwortlich, dass Kaizen stattfindet. Interessanterweise ist ein Manager umso mehr mit Kaizen beschäftigt, je höher er in der Firmenhierarchie steht. Von Top-Managern wird Imai zufolge erwartet, dass sie bis zu 50% ihrer Anstrengungen in Kaizen investieren.

Ich will hier keine Unterscheidung aufmachen nach dem Motto "Innovation ist schlecht, Kaizen ist gut". Ich glaube aber, es lohnt, immer wieder darüber nachzudenken, wie viel Innovation wir wirklich brauchen und wann es sinnvoller ist, unsere Anstrengungen in viele, kleine Verbesserungen zu investieren. In diesem Zusammenhang finde ich insbesondere die Rolle des Managements spannend: Sehen Manager ihre Verbesserungs-Aufgaben in erster Linie darin, immer wieder geniale Innovationen zu ersinnen? Oder sollte es nicht auch einen großen Teil ihres Jobs ausmachen, selbst Möglichkeiten für Kaizen zu erkennen, vor allem aber eine Umgebung zu schaffen, in der Verbesserung in Form von Kaizen von allen Mitarbeitern herbeigeführt werden können?

Mittwoch, 10. August 2011

Do we need a Product Owner in Kanban?

(Eine Deutsche Version dieses Posts findet sich hier)


The question of the necessary / appropriate roles in Kanban is certainly among the most frequently asked. Since Kanban is neither a development process nor a project management methodology, but a change method, there is no role model specified. So the simple answer to the question above is: "Start with what you have and retain the existing roles until you find out that you should do something about it."
Kanban has, however, the "unpleasant" property to uncover existing problems in an organization very quickly. And in my experience the most virulent problems can often be found upstream in product management. As soon as it becomes clear that an insufficient or missing product management is the root cause of your problems, you have to seriously think about the proper role for this - even in Kanban.

Let us first have a look at product development, for example an organization that publishes an online newspaper or delivers an accounting software to their customers. If there is no working product management, this leads directly to chaos (no matter if you do or do not use Kanban). Once that developers or testers start to prioritize requirements on their own, focus will be lost very soon and and the product starts to "fray". Moreover, in such a situation, there´s a strong tendency for all kind of stakeholders (customers, salespeople, marketing, etc.) to submit "their" requirements directly to the team - and of course they always have the priority "A ***". This leads to high pressure on those implementing the requirements. In this situation they will most likely try to satisfy those first who shout the loudest. But of course this does not mean that their requirements are also the most important ones! Moreover, it can often be observed that more and more new tasks are started to satisfy the "squallers", but this does not mean that these tasks will be completed quie sonn as well (in a reasonable quality) - exactly the opposite of which we want to achieve with Kanban! And finally, it is extremely unlikely in a situation like this that tasks that are important but not urgent (in Kanban they are called Intangibles) will ever get a high priority. Sooner or later this leads to certain destruction.

So we need someone who takes care of the following:

     Collect tasks from various people, teams and departments and prioritize them;
      Stay in contact with the stakeholders, understand their needs and keep them up to date;
      Shield the implementation team;
      Create a product vision (in collaboration with the team) that should be as clear and simple as possible;
      Ensure that new product increments are built as often as possible in order to get feedback from customers and other stakeholders. This in turn has certain effects on the slicing of the requirements .

This sounds somehow familiar, right? Yes, it is exactly what the Product Owner is supposed to do in Scrum! So if you have problems regarding the product management, it is quite useful to implement the role of the Scrum Product Owner as a starting point - even in Kanban.

Now there are not only product houses, but also service organizations such as maintenance teams, web agencies and other service providers. They do not develop a product continuously, but have to deal with multi-project management (even if the projects might be very small). They carry out projects for several external or internal "customers". In precisely such contexts Kanban has eveolved (maintenance teams at Microsoft and Corbis, see Anderson 2011, Chapter 4 and 5). Again, I think it is important that the prioritization is not done by the developers, testers etc., but by "someone else". This could be a Product Owner, in which case the name no longer fits properly (some organizations speak of the "Request Manager" or "Service Owner"). As David Anderson describes, this role could also be divided and performed by several different managers (whereas a distribution of the Product Owner role in Scrum is not recommended). In this context it is necessary to have an accepted and transparent process to prioritize the tasks (for example, in a round-robin procedure, see Anderson 2011, Chapter 9.6). And because service organization have to deal with intangibles as well, it must be ensured that these tasks won´t be ignored constantly. The use of Gold Cards could be a way to deal with intangibles here, so for instance developers are allowed to pull tasks like improving their infrastructure into the system from time to time.
The function of shielding is particularly important in service organizations because here we are dealing with many small tasks that occur very irregularly.
Since service organizations usually do not develop a certain product, it is not necessary to craft and maintain a product vision. At the same time, however, I have learned from experience that it can be extremely helpful for service teams to have a team vision. Such a vision will give guidance for prioritization, might improve the teamwork and can help other teams within the organization to better understand what kind of work the service team is dealing with. Therefore, the role of the Service Owner must not be underestimated.

References
David Anderson (2010): Kanban. Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

Montag, 8. August 2011

Brauchen wir in Kanban einen Product Owner?

(You can find an English version of this blog post post here

Die Frage nach den nötigen/richtigen Rollen in Kanban gehört sicherlich zu den am häufigsten gestellten. Da Kanban keinen Entwicklungsprozess und auch keine Projektmanagement-Methode darstellt, sondern eine Change-Methode, ist hier kein Rollenmodell vorgegeben. Die einfache Antwort lautet daher: "Startet mit dem, was ihr habt und behaltet die existierenden Rollen so lange bei, bis ihr herausfindet, dass ihr sie ändern solltet."
Kanban hat allerdings die "unangenehme" Eigenschaft, existierende Probleme in einer Organisation schnell aufzudecken. Und meiner Erfahrung nach liegen die größten Probleme häufig upstream im Produktmanagement. Wenn sich aber herausstellt, dass ein unzureichendes oder gar fehlendes Produktmanagement die Ursache von Problemen ist, dann muss man sich ernsthaft Gedanken über die passende Rolle hierfür machen - auch in Kanban.
Betrachten wir zunächst Produktentwicklung, beispielsweise eine Organisation, die eine Online-Zeitung herausgibt oder eine Buchhaltungs-Software an ihre Kunden ausliefert. Wenn es hier kein funktionierendes Produktmanagement gibt, führt dies direkt ins Chaos. Sobald nämlich Entwickler oder Tester anfangen, Anforderungen selbstständig zu priorisieren, geht bald jeglicher Fokus verloren und das Produkt "franst aus". Darüber hinaus besteht in so einer Situation die Tendenz, dass alle möglichen Stakeholder (Kunden, Vertriebler,  Marketing usw.) "ihre" Anforderungen direkt an das Team herantragen - und natürlich haben sie immer die Prio "A***". Hierdurch entsteht zum einen ein hoher Druck auf diejenigen, die die Anforderungen umsetzen, so dass sie in der Regel zuerst zuerst den berücksichtigen, der am lautesten schreit. Das bedeutet aber noch lange nicht, dass dies auch die wichtigste Anforderung für das Produkt ist! Darüber hinaus lässt sich oft beobachten, dass immer wieder neue Aufgaben begonnen werden, um die "Schreihälse" zufrieden zu stellen, was aber noch lange nicht heißt, dass diese Aufgaben auch (in vernünftiger Qualität) abgeschlossen werden - genau das Gegenteil also von dem, was wir mit Kanban erreichen wollen. Und schließlich ist es in so einer Situation extrem unwahrscheinlich, dass Aufgaben, die wichtig aber nicht dringend sind (in Kanban heißen sie Intangibles) jemals nach oben priorisiert werden. Und dies führt früher oder später zum sicheren Untergang.

Wir brauchen also jemanden, der die folgenden Aufgaben wahrnimmt:
  • Anforderungen von verschiedenen Seiten einsammeln und priorisieren;
  • Mit den Stakeholdern in Kontakt bleiben, ihre Bedürfnisse abfragen und sie auf dem Laufenden halten;
  • Das Realisierungsteam abschirmen;
  • Zusammen mit dem Team eine möglichst klare Produktvision erstellen;
  • Dafür sorgen, dass möglichst häufig neue Produktinkremente erstellt werden, zu denen Kunden und andere Stakeholder ihr Feedback geben können. Das wiederum hat bestimmte Auswirkungen auf den Zuschnitt von Anforderungen.
Das kommt uns doch irgendwie bekannt vor, oder? Richtig, dies sind genau die Aufgaben, wie sie der Product Owner in Scrum wahrnehmen sollte! Für Produkthäuser, die Probleme mit dem Produktmanagement haben, ist es deshalb durchaus sinnvoll, die Rolle des Product Owners nach Scrum zu besetzen - auch in Kanban.

Nun gibt es aber nicht nur Produkthäuser, sondern auch Service-Organisationen wie beispielsweise Wartungsteams, Webagenturen oder andere Dienstleister. Sie entwickeln nicht kontinuierlich an einem Produkt, sondern betreiben im weitesten Sinne Multiprojekt-Management (wobei die Projekte auch sehr klein sein können) für mehrere externe oder interne "Kunden". In genau solchen Kontexten ist Kanban ja entstanden (Wartungsteams bei Microsoft und Corbis, vgl. Anderson 2011, Kapitel 4 und 5). Auch hier halte ich es für wichtig, dass die Priorisierung nicht von den Entwicklern, Testern usw. durchgeführt wird, sondern von "jemand anders". Das kann ein Product Owner sein, wobei dann der Name nicht mehr richtig passt (einige Organisationen sprechen vom "Anforderungsmanager" oder "Service Owner"). Wie David Anderson beschreibt, kann diese Rolle jedoch auch aufgeteilt und z.B. von mehreren Managern gemeinsam wahrgenommen werden (wohingegen eine Aufteilung der Product-Owner-Rolle bei Scrum ja vermieden werden soll). Dafür ist es notwenig, dass es ein akzeptiertes und transparentes Verfahren gibt, wie diese Priorisierung vonstatten geht (beispielsweise in einem Round-Robin-Verfahren, vgl. Anderson 2011, Kap. 9.6). Und weil ja auch in Service-Organisation Intangibles anfallen, muss gewährleistet werden, dass diese nicht ständig hinten runterfallen. Denkbar sind hier beispielsweise Gold Cards, die die Entwickler in regelmäßigen Abständen in das System geben dürfen, um beispielsweise Verbesserungen an ihrer Infrastruktur vorzunehmen.
Die Funktion des Abschirmens halte ich in Service-Organisationen auch deshalb besonders wichtig, weil wir es hier häufig mit vielen kleinen Aufgaben zu tun haben, die sehr unregelmäßig anfallen.
Da Service-Organisationen in der Regel kein einheitliches Produkt entwickeln, fällt hier erst einmal die Erstellung und Pflege einer Produkt-Vision weg. Gleichzeitig habe ich jedoch die Erfahrung gemacht, dass es extrem hilfreich sein kann, dass sich das Team eine Vision gibt. So eine Team-Vision hilft dann bei der Priorisierung der Aufgaben, kann die Zusammenarbeit im Team verbessern und trägt dazu bei, dass andere Teams innerhalb der Organisation besser verstehen, was die Aufgaben des Service-Teams sind (und was nicht). Die Aufgabe des Service Owners sollte also keinesfalls unterschätzt werden.

Literatur
David Anderson (2011): Kanban. Evolutionäres Change Management für IT-Organisationen. dpunkt Verlag.

Donnerstag, 21. Juli 2011

Warum ist Kanban evolutionär?

(want to read this post in English? Paste the text into http://wordmonkey.info/ - it works amazingly well!)

Neulich habe ich zusammen mit meinem Freund, Kollegen und Chef Henning Wolf auf einer Konferenz ein kleines Schauspiel aufgeführt. Darin tu ich so, als sei ich ein schlauer Kanban-Berater, während Henning einen Projektleiter mimt (etwas schwer von Begriff), der seinen Entwicklungsprozess mit Hilfe von Kanban verbessern will. Die beiden treffen sich seit Jahren zufällig auf der Straße wieder und diskutieren über Kanban (zum Glück hängt da gerade ein Whiteboard mit Haftnotizen an einer Häuserwand hinter ihnen). In meiner Rolle als Berater bin ich dann etwas abgeschweift und habe etwas von Giraffen, Schildkröten und Eisbären erzählt. Irgendwann merkte ich, dass Henning mich ziemlich ungläubig anblickte und schnell das Thema wechselte. Also muss ich das wohl noch mal in aller Ruhe erzählen. Hier kommen sie also: Giraffen, Schildkröten und Eisbären...

Kanban wird häufig als evolutionäre Change-Management-Methode bezeichnet. Der Grund dafür liegt darin, dass Änderungen in Kanban meist in sehr kleinen Schritten durchgeführt werden. Dasselbe gilt für die Evolution (hier gibt es zwar gelegentlich so genannte Makro-Mutationen, diese setzen sich aber nur sehr selten durch). Und neben diesen kleinen Veränderungs-Schritten gibt es noch eine zweite Parallele zwischen Kanben und der Evolution:  Richard Dawkins – einer der bekanntesten Evolutionsbiologen überhaupt – hat einmal gesagt: „Die Evolution bewegt sich ganz, ganz langsam nirgendwo hin.“ Gemeint ist, dass es keinen Zielzustand gibt, auf den sich die Evolution zubewegt. Vielmehr verändern sich die verschiedenen Spezies immer weiter – und zwar so, wie es am Günstigsten für ihre jeweilige Umwelt ist. In diesem Sinne sollten auch Kanban-Systeme betrachtet werden: Sie sind niemals „fertig“, sondern entwickeln sich stets weiter, es gibt keinen vorher definierten oder auch nur bekannten Endzustand. Natürlich verfolgt man mit der Einführung von Kanban bestimmte Ziele. Aber man verschenkt große Teile des Potenzials von Kanban, wenn man Halt macht, sobald diese Ziele erreicht sind.
Und die Analogie mit der Evolution macht noch einen weiteren Punkt deutlich: Die Evolution hat Arten hervorgebracht, die (nahezu) perfekt an ihre speziellen Lebensbedingungen angepasst sind. Nehmen wir die Giraffen: Auf den ersten Blick sind das ziemlich merkwürdige Tiere: Unglaublich lange Hälse, merkwürdige Flecken und dann diese "Antennen" auf dem Kopf. Natürlich hat das aber alles seinen Zweck: Die Hälse ermöglichen ihnen, Blätter aus großen Höhen zu fressen; die Flecken könnten nützlich sein, wenn es darum geht, vor Raubtieren zu flüchten, denn Giraffen sind Herdentiere, und hier wirken solche Flecken Konturen-auflösend; und die "Antennen" sind in wirklichkeit verkümmerte Geweihe, die nützlich sind, sich stachelige Akazien vom Kopf fern zu halten. (Es gibt im Internet übrigens Verschwörungstheorien, die behaupten, es seien in Wirklichkeit doch Antennen, und die Hälse seiein so lang, weil der Empfang in der Savanne so schlecht ist).
Ebenso wie Giraffen sollte auch jedes Kanban-System so gut wie möglich an seine jeweilige "Lebensbedingung" angepasst sein - und sich immer weiter anpassen. Aus diesem Grund wird jedes lebendige Kanban-System nach einer Weile individuell aussehen. Für einen Eisbären wäre es wahrscheinlich eher kontraproduktiv, einen langen Hals zu haben. Und für Schildkröten ist es schon ganz gut, dass sie einen harten Panzer und Schwimmflossen haben anstatt Hufe und kurze Geweihe.
Zurück zu Kanban: Wer einfach nur eine bestehende Kanban-Implementierung kopiert, wird damit wahrscheinlich keinen Erfolg haben. Die Kanban-Mechaniken allein sind noch keine Erfolgsgarantie - man muss sie auch auf den eigenen Kontext anwenden und regelmäßig anpassen.

Bei allen Ähnlichkeiten gibt es natürlich auch etliche Unterschiede zwischen der Evolution und Kanban. Hier ist insbesondere die "Willkür" zu nennen, mit der die Evolution funktioniert. Nach dem Darwin-Algorythmus gibt es in der Natur immer wieder Variationen bei einzelnen Individuen, die ihre Überlebensfähigkeit beeinflussen. Wenn diese Veränderungen vorteilhaft sind (und nur dann), wird sich das Individuum erfolgreich fortpflanzen und damit die Veränderungen langfristig weitergeben. In Kanban wäre es hingegen grob fahrlässig, wenn wir einfach irgendwelche Veränderungen durchführen würden und dann zu hoffen, dass sich dadurch unser System verbessern würde. Stattdessen stellen wir anhand unserer Erfahrung und unserer Daten Hypothesen darüber auf, welche kleinen Veränderungsschritte als Nächstes sinnvoll sein könnten und überprüfen diese Hypothesen dann regelmäßig.
So kann es dann sein, dass dabei das Kanban-Schnabeltier entsteht:-)


Literatur
Richard Dawkins (1998): Das egoistische Gen. Springer-Verlag.

Dienstag, 31. Mai 2011

Low Tech bei der Krankenkasse

Neulich schaute ich bei einer Filiale meiner Krankenkasse vorbei, weil ich auf die Schnelle eine Auslandskrankenversicherung abschließen wollte. Die Filiale ist ziemlich groß, und am Anfang muss man sich erst einmal an einem zentralen Schalter melden, an dem dann vorsortiert wird, ob man überhaupt an der richtigen Adresse ist, die nötigen Unterlagen dabei hat usw. So weit so normal. Aber dann wurde es plötzlich sehr spannend (naja, die meisten Menschen würden das wohl als sehr unspannend abtun, aber für mich war es spannend): Der nette Herr am Schalter fragte nach meinem Namen und nach dem Grund für meinen Besuch. Beides schrieb er - und jetzt kommt es (Trommelwirbel) - auf eine gelbe Haftnotiz. Diese klebte er auf den Schrank hinter sich - unter eine Reihe anderer Haftnotizen. Das sah dann ungefähr so aus:

Und es wird noch besser. Als ich fragte, wie lange es in etwa dauern wird, bis ein Berater Zeit für mich hat, blickte er kurz auf seine Zettelwand und antwortete: etwa 30 Minuten. Das musste ich erst mal verdauen. Als ich dann eine Weile im Wartebereich saß und über die Zettel nachdachte, kam ein Berater mit einer gelben Haftnotiz in der Hand und fragte, wer denn Herr Roock sei. Er begrüßte mich dann mit Handschlag und begleitete mich zu seinem Arbeitsplatz. Dort hatte er bereits einen kleinen Stapel mit anderen gelben Zetteln  auf seine Schreibtischunterlage geklebt von Kunden, mit denen er vorher bereits gesprochen hatte.

Beim Rausgehen hatte ich leider wenig Zeit, um mich noch einmal genauer nach dem Zettelsystem zu erkunigen. Aber das Ganze ließ mich nicht mehr los, so dass ich aus meinem Kanada-Urlaub über Skype in der Filiale anrief und mich bis zur richtigen Ansprechpartnerin durchstellen ließ (wegen der Zeitverschiebung ein ziemlich absurdes Telefonat, weil in Deutschland der Arbeitstag gerade begann und ich um Mitternacht schon meinen zweiten Whisky intus hatte....)

Die sehr nette Dame von der Kundenbetreuung hat mir dann noch etwas mehr über das System erzählt. Ausgangspunkt war, dass es immer wieder zu Streitereien unter den Besuchern kam, weil die Reihenfolge unklar war. Zuerst wurde über ein System wie beim Arbeitsamt nachgedacht, bei dem jeder eine Nummer zieht, aber das war den Mitarbeitern zu bürokratisch! Also haben Sie sich die Low-Tech-Lösung mit den Haftnotizen ausgedacht. Und sie wissen tatsächlich ziemlich genau, wie lang die Durchlaufzeit für ein einzelnes Ticket ist, so dass sie den warteneden Besuchern eine ganz gute voraussichtliche Wartezeit mitteilen können.
Der Grund für den Besuch steht auf den Zetteln, damit der jeweilige Berater sich schon etwas auf das nächste Gespräch einstellen kann (und hat nichts mit Spezialisierung zu tun, wie ich zuerst vermutete).

Ich hatte noch befürchtet, dass die erledigten Zettel dazu dienten, irgendeine Form der Leistungsbeurteilung vorzunehmen. Dem ist aber zum Glück nicht so. Vielmehr ist das wohl etwas, zu dem sich "mein" Berater entschieden hat, weil es ihn motiviert - ein Effekt, der uns von Kanban und Scrum ja nicht ganz unbekannt ist.

Ich habe dann noch zwei Vorschläge gemacht, wie sich das System evtl. weiter verbessern ließe:
  1. Ich fände es netter, wenn jedem Besucher immer gleich seine voraussichtliche Wartezeit mitgeteilt würde - nicht nur auf eine konkrete Nachfrage hin.
  2. Ich hab (natürlich) vorgeschlagen, die Anzahl der Besucher im Gebäude zu limitieren. Tatsächlich war es bei mir so, dass die Stühle knapp wurden und sogar jemand stehen musste. Darunter leidet dann ja tatsächlich irgendwann auch die Qualität.
Über den ersten Vorschlag wollen sie jetzt mal näher nachdenken; die Limitierung können sie sich hingegen gar nicht vorstellen, weil sie (vielleicht nicht zu Unrecht) befürchten, das würde ihnen als Kunden-Unfreundlichkeit ausgelegt werden, wenn während der Besuchszeiten die Tür verschlossen ist.

Ich nehme aus dem Besuch und dem Telefonat mit:
  • Oft sind die einfachsten Lösungen die besten.
  • Der haptische Effet und die höhere Motivation beim Umgang mit physikalischen Boards sind nicht zu unterschätzen.
  • Auch wenn wir in der IT glauben, wir wüssten ziemlich gut, wie man seine Arbeit organisieren sollte, kann dies in anderen Domänen deutlich anders sein.
  • Es gibt auch außerhalb der IT clevere Leute;-)
  • Meine Krankenkasse scheint die richtige Wahl für mich zu sein.

Donnerstag, 21. April 2011

Wichtige Termine in 2011

Schon Anfang des Jahres hat David Anderson getwittert "The Kanban Train is accelerating".  Wenn man sich ansieht, welche Events allein dieses Jahr noch anstehen, dann scheint er Recht zu behalten.

Ich habe hier mal zusammengestellt, welche hochkarätigen Ereignisse allein 2011 noch stattfinden:
  • Lean Software & systems Conference, 03.-06.05. in Long Beach (Kalifornien): DIE Lean/Kanban-Konferenz überhaupt! Wer es irgendwie einrichten kann, sollte da unbedingt hin (ich kann es leider nicht einrichten). Konferenz bei Twitter folgen
  • Kanban-Track auf der GOTO, 13.05. in Kopenhagen: David Anderson hostet einen eigenen Track zu Kanban. Markus Andrezak, Bernd Schiffer und ich werden eine Einführungs-Session als kleines Schauspiel halten. Konferenz bei Twitter folgen
  • Lean Kanban Benelux, 03.-04.10.2011 in Antwerpen: Diese Konferenz ist - zusammen mit den beiden folgenden - die offizielle europäische Lean/Kanban-Konferenz des LSSC. Die Seite befindet sich im Aufbau, im Moment läuft der Call for Papers. Ich war letztes Jahr dort und kann nur sagen: Das war (zusammen mit den letzten beiden XP Days Germany) die beste Konferenz, auf der ich jemals war! Konferenz bei Twitter folgen
  • Lean Kanban Central Europe, 17.-18.10.2011 in München: Bernd Schiffer und ich organisieren dieses Event, und man kann jetzt schon sagen, dass es sich lohnen wird! Also haltet euch diesen Termin frei! Der Call for Paper folgt in den nächsten Tagen. Konferenz bei Twitter folgen
  • LESS Conference, 31.10.-01.11.2011 in Stockholm: Diese Konferenz hat - im Gegensatz zu Benelux und Central Europe einen akademischen Einschlag.
  • XP Days Germany, 17.-19.11. in Karlsruhe: Diese Konferenz ist Legion! Bei keiner anderen Konferenz habe ich so viele innovative Session-Formate gesehen, und nirgendwo habe ich die Atmosphäre als so angenehm erlebt wie hier! Das Programm steht noch nicht fest, aber ich bin mir sicher, es wird auch dieses Jahr wieder etliche Sessions zu Lean und Kanban geben! Konferenz bei Twitter folgen
  • Lean Agile Scrum Konferenz, 14.09. in Zürch. Eine eintägige Konferenz, die von der Fachgruppe Lean, Agile und Scrum der SwissICT organisiert wird. Auch hier läuft im Moment der Call for Paper.
Wir sehen uns im Kanban-ICE - egal in welchem Abteil:-)

    Sonntag, 3. April 2011

    Kein Board ohne Verb!


    Viele von uns kennen aus der Schule vielleicht den (Nicht-)Satz: „Kein Satz ohne Verb!“  Nicht nur im Deutschunterricht gelten zu viele Nominalisierungen als schlechter Stil („der Hund nahm eine Bellung vor“). Etwas Ähnliches lässt sich auch für Kanban-Boards feststellen: „Kein Board ohne Verb!“
    Was ist damit gemeint? Wenn es beim Neu-Design von Kanban-Systemen darum geht, die relevanten Prozessschritte des Workflows ausfindig zu machen und als Spaltenüberschriften auf das Board zu bringen, kommt dabei häufig so etwas heraus wie „Angebot  erforderlich“ oder „in Quality Gate“. Zuerst dachte ich, nur mir als Externem wäre nicht ganz klar, was genau damit gemeint ist. Aber beim Nachfragen stellt sich häufig heraus, dass auch das Team nur schwammige Vorstellungen davon hat, was hier genau geschieht: Hat der Kunde nach einem Angebot gefragt und nun wartet die Aufgabe darauf, begonnen zu werden? Oder ist gerade jemand damit beschäftigt das Angebot tatsächlich zu erstellen? Wartet ein Ticket darauf, das Quality Gate zu passieren?  Oder wird im Quality Gate gerade aktiv an dem Ticket gearbeitet? Und wenn ja: Was geschieht da eigentlich?
    Einmal mehr scheint sich hier mein Germanistik-Studium bezahlt zu machen;-)  Wenn man nämlich darauf beharrt, dass überall dort, wo aktiv an Aufgaben gearbeitet wird, Verben für die Spaltenüberschriften verwendet werden (wobei „warten“ hier nicht als Verb gezählt wird!), werden die Dinge oft sofort klarer: Spalten wie „Angebot erstellen“, „Akzeptanztests durchführen“ oder „Prüfen durch Geschäftsleitung“ sind dann die deutlich besseren Formulierungen. Manchmal zeigt es sich aber auch, dass es gar nicht ohne Weiteres möglich ist, Verben zu finden oder dass es unterschiedliche Auffassungen davon gibt, wer hier genau was tut. Dann hat man mitunter mit einem einfachen Trick eine wertvolle Diskussion angestoßen. 
    Die Spaltenüberschriften sollten deutlich machen, was genau hier im Workflow geschieht
    Gleichzeitig gibt es natürlich Spalten, die man nicht sinnvoll mit Verben benennen kann: Das sind dann Queues oder Puffer. „Bereit für Release“ wäre so ein Beispiel. (Auch gängige Spalten wie „Backlog „ und „Ready for Release“ stellen sich dann als das heraus, was sie sind: Puffer – aber dazu in einem späteren Post mehr).
    Wenn man dann einmal geklärt hat, in welchen Spalten Aktivitäten durchgeführt werden, werden viele Dinge einfacher:



    • Man kann eine sachliche Diskussion darüber führen, wer diese Aktivitäten momentan normalerweise durchführt (und ob dies sinnvoll ist).
    • Häufig stellt sich ein AHA-Effekt ein, weil man sieht, wie viele Stellen es im Workflow gibt, an denen Aufgaben potenziell warten.
    • Dieser Eindruck bestätigt und verstärkt sich häufig noch im Cumulative Flow Diagram, weil man hier den Anteil der Queues und Puffer über die Zeit deutlich sehen kann und sich auch die Auswirkungen auf die durchschnittliche Durchlaufzeit erkennen lassen.


    Tatsächlich kann ich mir keinen Workflow vorstellen, in dem keine Aktivitäten durchgeführt werden. Aber es kann durchaus Boards geben, auf denen nur sehr wenige (oder vielleicht sogar gar keine) Aktivitäten dargestellt werden. Der Grund dafür ist, dass die Aktivitäten so schnell zu erledigen sind, dass es sich nicht lohnt, die Tickets überhaupt in die entsprechende Spalte zu verschieben. Wenn aber einige Spalten  permanent leer sind, dann kann es sinnvoll sein, sie wieder abzuschaffen (es sei denn, man möchte auf dem Board deutlich machen, dass diese Spalten leer sind, z.B. für vorbeikommende Kollegen und Vorgesetzte). In unserer Firma sammeln wir gerade Erfahrungen mit einem Kanban-System für unsere Vertriebs- und Angebotsprozesse. Hier ist es tatsächlich so, dass die eigentlichen Aktivitäten oft schnell erledigt sind („Bestätigungsmail an Kunden schicken), während man immer wieder länger auf Antwort oder Zuarbeit warten muss. Wenn das Board zu einem Großteil aus Queues und Puffern besteht, macht dies ja auch etwas deutlich: Wenn wir die Durchlaufzeiten verkürzen möchten, dann ist es nicht besonders zielführend, die Aktivitäten effizienter zu gestalten. Stattdessen müssen wir uns Gedanken darüber machen, wie wir die Wartezeiten verkürzen können. Das scheint in vielen Fällen erst einmal unmöglich, ist es aber so gut wie nie!

    P.S. Vielen Dank an Henning Wolf für die Inspiration und die tollen gemeinsamen Kanban-Schulungen und -Coachings in letzter Zeit! 

    Mittwoch, 23. März 2011

    Kanban – die eierlegende Wollmilch-Methode?


    In letzter Zeit war ich viel unterwegs und habe eine Reihe Vorträge und Workshops zu Kanban gehalten. Danach gibt es (zum Glück) eigentlich immer so viele Fragen, dass man bis spät in die Nacht weiterdiskutieren könnte. Die Fragen drehen sich meist um die Unterschiede zwischen Scrum und Kanban (wobei ich immer mehr Wert auf die Gemeinsamkeiten anstatt die Unterschiede lege) und um Detailfragen und die Mechaniken von Kanban: „Dürfen und sollen Karten auf dem Board wieder zurück geschickt werden (z.B. wenn die Tester einen Fehler finden)?“, „Wer sorgt dafür, dass die WIP-Limits eingehalten werden?“, „Wie geht man mit Prio-1-Bugs um?“ Usw. Und dann gibt es noch eine andere Sorte von Fragen, auf die ich bisher schlecht vorbereitet war, weil sie für mich völlig unerwartet kamen: „Wie kann ich mit Kanban meine Schätzungen verbessern?“, „Wie führe ich erfolgreiche Festpreis-Projekte mit Kanban durch?“ oder „Wie kann ich meine Teams mit Kanban skalieren?“ Ich muss dann immer kurz nachdenken, was darauf wohl die beste Antwort ist. Inzwischen bin ich mir aber sicher, dass die Antwort immer gleich lauten muss, und zwar: „Gar nicht!“
    In den aufgeführten Beispielen geht es um Probleme, die nichts mit Kanban zu tun haben und die sich auch nicht durch Kanban lösen lassen. Kanban gibt uns die Chance, schnell Transparenz über unseren Prozess und die Verteilung der Arbeit zu bekommen, die Durchlaufzeit zu verkürzen und zur richtigen Zeit die richtigen Diskussionen zu führen – z.B. weil wir plötzlich durch die WIP-Limits Leerlaufzeiten haben.  In diesem Sinne hilft uns Kanban als Change-Management-Methode, Probleme wie ungenaue Schätzungen schnell zu erkennen (wenn sie uns nicht eh schon bekannt sind) und immer wieder den Finger in die Wunde zu legen, bis es uns irgendwann gelingt, diese Probleme zu lösen. Was wir aber genau tun müssen, um diese Probleme zu lösen, darüber schweigt sich Kanban zu Recht aus.
    Was mich erstaunt, ist die Erwartung, eine Methode wie Kanban würde alle unsere Probleme lösen. Schlimmer noch: Ich habe den Eindruck, einige Leute suchen eigentlich nur „Argumente“, warum Kanban für sie nicht geeignet ist, nach dem Motto: „Wenn Kanban mir nicht sagt, wie ich mein Team von 10 auf 100 Personen skalieren kann, dann ist es eine schwache Methode.“ Wenn Skalierung gerade mein größtes Problem ist, dann würde ich tatsächlich nicht als nächstes Kanban einführen, sondern mich umsehen, welche Methoden konkrete Lösung für Skalierungsprobleme bieten. Aber ich würde deshalb Kanban nicht schlecht machen. Es würde ja auch niemand auf die Idee kommen, auf einen Vorschlaghammer zu schimpfen, weil man damit schlecht Parkett abschleifen kann!
    Gleichzeitig können wir, die wie versuchen, Kanban populärer zu machen, uns offensichtlich noch deutlich verbessern in unseren Erklärungen. Wenn Kanban als eierlegende Wollmilch-Methode wahrgenommen, dann sind wir wahrscheinlich mit für diese hohen Erwartungen verantwortlich und sollten in Zukunft klarer machen, wo die Chancen und die Grenzen von Kanban liegen.

    Samstag, 19. Februar 2011

    Kanban=Wasserfall?

    Einer der häufigsten Kritikpunkte an Kanban von Leuten, die schon lange (und meist auch sehr erfolgreich) agil vorgehen und Scrum oder XP einsetzen, lautet: "Was auf den meisten Kanban-Boards zu sehen ist, sieht aus wie Wasserfall vom Feinsten!" Und das stimmt auf den ersten Blick auch, denn häufig sind auf den Boards die Prozessschritte in der Reihenfolge Backlog, Analyse, Entwicklung, Test, Deployment o.ä. abgebildet. Wie Johannes Link, Agilist der erste Stunde, in diesem Chat mit Henning Wolf und mir vollkommen richtig angemerkt hat, ist es in der Regel keine besonders gute Idee, die Aufgabe mit dem größten Risiko, also die Tests, erst so spät durchzuführen. Das stimmt! Im Idealfall sollten die Tests möglichst weit am Anfang der Wertschöpfungskete stehen und vielleicht sogar in Form von testgetriebener Entwicklung nicht nur vor Fehlern schützen, sondern auch das Design der Software leiten. Aber so sieht die Realität im größten Teil der Software-Industrie leider nicht aus. Die wenigsten Teams könnten wohl von sich behaupten, sie würden wirklich konsequent nach TDD (oder ATTD) vorgehen. Stattdessen wird faktisch in vielen größeren Organisationen nach einem Wasserfall-ähnlichen Prozeß vorgegangen - ob es einem nun gefällt oder nicht.
    Wenn Kanban-Boards nach Wasserfall aussehen, dann also nicht, weil Kanban Wasserfall nahelegen oder sogar vorschreiben würde. Vielmehr macht Kanban transparent, wie der Prozess momentan aussieht.
    In einer Kanban-Schulung mit David Anderson sollten die Teilnehmer den Entwicklungsprozess ihres aktuellen Projektes auf einer Moderationswand modellieren und dann kurz der Gruppe vorstellen. Ein Teilnehmer präsentierte sein Ergebnis mit den Worten "Wir entwickeln
    nach Scrum". Nach einigen Rückfragen aus der Gruppe wurde jedoch schnell klar, dass das Ganze nicht viel mit Scrum zu tun hat, sondern starke Ähnlichkeit mit Wasserfall aufwies. Kanban kann also Wasserfall sichtbar machen - auch dann, wenn es sich als Scrum tarnt. 
    Was die Beteiligten dann mit dieser Transparenz anfangen, bleibt ihnen überlassen. Vielleicht sind sie mit ihrem Prozess ja zufrieden, und er funktioniert für sie. Warum sollten sie ihn dann verändern? In der Regel ist dies aber nicht der Fall, und Organisationen möchten (oder müssen) sich verändern. Hierfür liefert Kanban einen guten Startpunkt (aber keine Komplettlösung mit Erfolgsgarantie). Fatal wird es dann, wenn Teams/Organisationen nach dem reinen Visualisieren ihres Prozesses Halt machen - was leider regelmäßig vorkommt. Richtig verstandenes Kanban enthält immer kontinuierliche Verbesserung als eine Kerneigenschaft, so dass das Team zu Verbesserungen getrieben wird - auch wenn diese in sehr kleinen Schritten vor sich gehen mögen. Im Wasserfall-Beispiel wird man wahrscheinlich nicht gleich am Anfang die Reihenfolge der Prozessschritte verändern und die Tests nach vorne ziehen. Aber allein durch die Betrachtung der Durchlaufzeit, die ja in Kanban die Haupt-Messgröße darstellt, in Kombination mit Little's Law wird das Team vermutlich ziemlich schnell überlegen, dass es eine gute Idee ist, nicht alle Anforderungen gleichzeitig zu bearbeiten (was eine maximale Losgröße (Batch Size) für die Anforderungen bedeutet). Wenn dann statt der maximalen 30 Anforderungen ein WIP-Limit von 15 eimgeführt wird, dann stellt dies schon einen erheblichen Fortschritt dar, weil die Durchlaufzeit sich damit deutlich verkürzt haben sollte und man viel früher Feedback über Fehler, Design, Erfüllen von Kundenbedürfnissen usw. erhält. 
    Diese kontinuierliche Verbesserung stellt aber zweifellos eine große Herausforderung an Teams/Organisationen dar, insbesondere, weil es in Kanban keine klaren Vorschriften gibt, wohin genau die Reise gehen soll. Hier sind eigene Überlegungen und kleine, kontrollierte Experimente nötig, um den besten individuellen Weg herauszufinden.

    Samstag, 12. Februar 2011

    Erstes deutschsprachiges Kanban-Buch

    Es ist vollbracht! Seit zwei Wochen ist die deutsche Übersetzung des Kanban-Buches von David Anderson erhältlich!



    Ich habe das Buch zusammen mit meinem Kollegen Henning Wolf ins Deutsche übersetzt. Das war deutlich mehr Arbeit, als ich erwartet hatte. Aber es hat sich definitiv gelohnt, denn so wurde ich "gezwungen", mich mal wieder richtig intensiv mit einem Buch auseinanderzusetzen und es mehrmals zu lesen. (Das letzte Mal befand ich mich in einer ähnlichen Situation, als ich im Frühjahr das Fachlektorat für die deutsche Version des neuen Buches von Mike Cohn übernommen habe - ebenfalls sehr zu empfehlen!)

    Natürlich gehen bei einer Übersetzung immer einige Nuancen des Originaltextes verloren. Aber wir haben nicht nur sehr großen Wert darauf gelegt, möglichst idiomatisches Deutsch zu verwenden und bei den Fachausdrucken einen guten Mittelweg zwischen deutschen Übersetzungen und Originalausdrücken zu finden, sondern konnten auch inhaltlich und drucktechnisch einen echten Mehrwert erzeugen. Die Deutsche Version...
    • ...ist auf dem absolut neuesten Stand, was die Definition von Kanban betrifft. Die letzten "Aktualisierungen", die David Anderson z.B. in diesem Blog Post veröffentlicht hat, konnten wir in letzter Sekunde noch in die deutsche Version aufnehmen. In der englichen Neuauflage werden sie voraussichtlich erst 2012 enthalten sein.
    • ...enthält ein zusätzliches Kapitel. Markus Andrezak, einer der Kanban-Pioniere in Deutschland, hat einen ausführlichen Erfahrungsbericht zu Portfolio-Kanban bei mobile.international beigesteuert.
    • ...ist drucktechnisch dehr gut. (David hat "Beschwerden" bekommen, wie es sein kann, dass die deutsche Ausgabe besser sei als das Original:-)
    Weil das Original-Cover nicht zum deutschen Layout passte, haben wir es in den Text der deutschen Ausgabe mit aufgenommen und einen Erklärungstext zum Cartoon geschrieben.


    Wer immer noch nicht überzeugt ist, kann sich ja verschiedene Reviews zum Buch ansehen - z.B. hier oder hier.

    Man munkelt übrigens, David schreibt schon an einem weiterführenden Kanban-Buch, das 2012 erscheinen soll...

    P.S. An dieser Stelle noch einmal vielen Dank an den dpunkt-verlag für die tolle und professionelle Zusammenarbeit!

      Donnerstag, 13. Januar 2011

      Visualisierung, Teil 3: Regeln und Sonstige Elemente

      Visualisierung spielt eine wesentliche Rolle in Kanban. Was sollte neben dem Workflow (in Form des Kanban-Boards) und den einzelnen Aufgaben (in Form von Tickets) noch visualisiert werden? Alles, was das Team braucht, um möglichst effektiv eigenverantwortlich arbeiten zu können! Der größte Block hierbei sind Regeln, die in jeder Organisation immer vorhanden sind - nur häufig implizit. Diese Regeln sollten in einem Kanban-System explizit gemacht und visualisiert werden - z.B. indem sie gut sichtbar auf ein Flipchart neben das Board geschrieben werden. Auch hier gilt wieder: Die Regeln sollten möglichst einfach gehalten und in ihrer Anzahl übersichtlich bleiben. Typische Regeln, die in expliziter Form das Team bei der Arbeit unterstützen, können sein:
      • Rhythmen und Zeiten für Standup Meetings, Releases, Retrospektiven usw.
      • Umgang mit Bugs und Blockaden
      • Definitions of Done für die einzelnen Prozessschritte (also welche Bedingungen müssen erfüllt sein, damit eine Aufgabe in die jeweilige Erledigt-Spalte verschoben werden darf?)
      • Regeln für den Umgang mit verschiedenen Aufgabentypen und Serviceklassen: Was passiert beispielsweise, wenn ein Hotfix in das System gelangt? Wird das entsprechende Ticket dann als nächstes gezogen? Oder werden dann alle anderen Aufgaben unterbrochen?
      • Kapazitätszuteilungen: Wie hoch soll der Anteil der jeweiligen Aufgabentypen sein, die sich jeweils im System befinden (z.B. 70% Features, 20% Infrastruktur, 10% Bugs).
      • Service Level Agreements: Welche Durchlaufzeiten garantieren wir unseren Kunden und Stakeholdern mit welcher Termintreue (z.B. "Bugs werden in 95% aller Fälle innerhalb von 3 Tagen behoben").
      • Eskalationsregeln: In welchen Fällen werden Probleme an das Management eskaliert?
      • ...

      In dieser expliziten Form unterstützen die Regeln die Teammitglieder nicht nur dabei, eigenständig gute Entscheidungen zu treffen. Sie helfen darüber hinaus auch dabei, sachliche Diskussionen zu führen.
      Dabei ist es wichtig, dass die Regeln nicht von oben herab diktiert werden, sondern dass die Teammitglieder sich darauf committen können, mit diesen Regeln zu arbeiten (auch wenn sie nicht jede Regel lieben werden). Natürlich können (und sollten) die Regeln mit der Zeit angepasst werden - wiederum gemeinsam im Team.
      Zusätzlich zu den Regeln gibt es eine Reihe weiterer Elemente, die gut sichtbar platziert werden sollten, um sich so einen Informative Workspace im XP-Sinne zu schaffen:
      • Eine Legende, was die verschiedenen Ticketfarben bedeuten.
      • Tracking-Diagramme
      • Abwesenheiten, Urlaube, Krankheiten usw.

      Links