Vorträge “Innovation – das wahre Bottleneck?!” auf der OOP 2012

Auf der OOP 2012 habe ich einen regulären Vortrag sowie ein Pecha-Kucha zum Thema “Innovation – das wahre Bottleneck?!” gehalten.

Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

Buchtipp: The Lean Startup

Wie können wir schneller lernen, ob Produktideen erfolgreich sein können oder nicht? Dieser Frage geht Eric Ries in seinem Buch “The Lean Startup” nach. Er fordert sogenanntes “Validated Learning”: Man formuliert seine Annahmen in der sogenannten Customer-Problem-Solution-Hypothese (welche Anwendergruppe hat welches Problem und wie gedenken wir es zu lösen) und definiert ein “Minimal Viable Product” (MVP, Minimal Brauchbares Produkt), mit dem man seine Hypothese überprüft. Das Ziel des MVP besteht darin, Annahmen zu überprüfen und lernen und das möglichst schnell. Man erstellt also ein MVP, dass so rudimentär ist, dass es fast nicht funktionieren kann – fast. Wenn wir (nach vielen Fehlschlägen) dann Hypothesen gefunden haben, die sich bestätigen, baut man das MVP schrittweise in Richtung eines richtigen Produktes aus.

Eine Besonderheit sind dabei die extrem kurzen Zyklen, die man anstrebt. Wir haben erst vor wenigen Tagen an einem halben Tag eine Customer-Problem-Solution-Hypothese definiert und ein MVP entwickelt.

Offensichtlich ist dieser Ansatz nicht nur dann sinnvoll, wenn man ein Startup gründet. Passend dazu definiert Eric Ries Startup als Produktentwicklung unter großer Unsicherheit. Das Buch adressiert als das Startup in der Garage genauso wie eine Produktneuentwicklung in einem Konzern.

Ich finde, das Buch ist sehr gut geschrieben und es stellt einen wichtigen Meilenstein in der Entwicklung unserer Branche dar. Allerdings fokussiert das Buch darauf, den Leser vom grundsätzlichen Ansatz zu überzeugen. Es bleibt manchmal etwas schwammig, was man konkret machen soll/kann. Außerdem handeln die meisten Beispiele von Internet-Anwendungen. Für andere Produkttypen ist etwas mehr Transferleistung notwendig. Bestimmt kommt demnächst ein Nachfolgebuch “Implementing the Lean Startup” heraus, in dem konkret beschrieben wird, wie man es denn nun macht. Trotzdem ist auch dieses Buch absolut empfehlenswert.

G Forces, Release Cadence and Feedback Cycles

When I saw the G Forces presentation by Kent Beck at the Lean Kanban Central Europe conference  had an insights that wasn’t that clear to me before.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

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.