Buchtipp: Unfolding the Napkin
Wir Menschen können Bilder sehr schnell und effizient verarbeiten. Wenn wir Lesen oder Zuhöhren, sind wir viel langsamer. Dazu passend besteht die Napkin-Idee darin, Probleme, Ideen und Konzepte per handgemalter Skizzen zu visualisieren. Ich arbeite ohnehin gerne an Whiteboards und Flipcharts. Der Napkin-Ansatz fügte sich da nahtlos ein und brachte mir viele neue Konzepte und Ideen für die Visualisierung.
Inzwischen habe ich auch viele Beispiele aus meiner beruflichen Praxis, die die Handskizzen-These des Napkin-Ansatzes unterstützen. Ich arbeite z.B. in meinen Schulungen gänzlich ohne Folien, sondern erstelle Visualisierungen während der Schulungen auf Flipcharts. Es gab bisher keinen einzigen Teilnehmer, der das bemängelt hätte. Es gab aber sehr viele, die das Vorgehen explizit gelobt haben. Ein anderes Beispiel ist eine Konzeptarbeit für ein großes deutsches Unternehmen. Ich habe die ganze Konzeption am Flipchart gemacht und auch die Management-Präsentation der Ergebnisse mit Flipcharts gehalten. Die Resonanz war außerordentlich positiv. Auf Wunsch des Kunden hin habe ich danach die Flipcharts 1:1 nach Powerpoint überführt, nur eben professionell mit den Zeichen- und Formentools von Powerpoint. Kommentar des Kunden: „Danke für die Powerpoint-Präsentation. Hm. Die Flipcharts waren irgendwie doch besser.“
Unfolding the Napkin
Beide Bücher widmen sich dem Thema der Visualisierung, um Probleme darzustellen und zu lösen. Der passende Untertitel zu „Unfolding the Napkin“ lautet entsprechend: „The hands-on method for Solving Complex Problems with Simple Pictures“. Während das erste Buch die Konzepte eher theoretisch erläutert, ist „Unfolding the Napkin“ ein Praxisbuch mit vielen Übungen, die man direkt für sich ausprobieren kann. Ich fand „The Back of the Napkin“ schon sehr schön, finde „Unfolding the Napkin“ aber noch besser. Ich vermute, dass man „Unfolding the Napkin“ auch dann sehr gut verstehen kann, wenn man „The Back of the Napkin“ vorher nicht gelesen hat.
Meiner Meinung nach ist das Buch extrem wertvoll für jeden, der Probleme oder Konzepte erstellen oder präsentieren will oder muss: Trainer, Berater, Entwickler, …
Add comment August 16, 2010
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:
- Limit work in progress to an upper limit with a preference for lower limits.
- Pull from upstream processes.
Therefore in Nabnak you would
- Ensure that work in progress never falls below a bottom limit with a preference for higher limits.
- 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:
- Developers are so expensive that a high utilization outperforms all other metrics.
- 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.
1 comment Juli 14, 2010
Wasteful Scrum Meetings
Sometimes the Scrum meetings (planning, review, retrospective, daily scrum) are considered to be wasteful overhead.
Sorry, but that is bullshit. If the Scrum meetings feel like wasteful overhead, it is almost always your own failure.
Focus is one of the Scrum values. If your Scrum meetings feel wasteful, they need better focus. Stop doing the things that don’t provide value.
Let’s look at the meetings one by one.
Estimation Meeting
During the estimation meeting two things should happen:
- The product backlog items are estimated by the team.
- More important: Knowledge is shared between Product Owner and Team and the Team participates in definition, splitting and refining product backlog items.
If the Product Owner doesn’t have to forecast a release date or development effort, he could simply skip point 1. An alternative could be to use a very rough estimate and simply use an estimation of 1 story point for every backlog item.
If the product backlog items are simple and clear point 2 may not be neccessary. In that case you could simply skip it.
If both points aren’t neccessary you can skip the whole meeting. There is a reason that the estimation meeting is not an official part of Scrum.
Sprint Planning
The goal of the sprint planning is of course to plan the Sprint. It is dependent on the team how it is done best and how much effort the team has to invest. I have seen teams doing a Sprint Planning in a few minutes.
Doing a task breakdown is a proven practice during the Sprint Planning but it is not a must. If the team can generate value with only considering the stories, the team doesn’t need to do a task breakdown during the Sprint Planning. The team could do an ad-hoc task breakdown when it begins working on the story. If the stories are really tiny the team may need no task breakdown at all.
Sprint Review
If the Product Owner is colocated with the development team he should have seen the implemented stories before the Sprint Review. Therefore there may be no need to present the stories again to the Product Owner during the Sprint Review. But there is much more to the Sprint Review. The Product Owner should invite the stakeholders to the Sprint Review meeting so that they can get a first-hand impression about status and progress of the development.
Sprint Retrospective
The Sprint Retrospective is the focus point where the teams tries to improve. If the retrospectives feel like waste, the facilitator is probably not doing his job effectivly.
Daily Scrum
The 15 minutes of the Daily Scrum should help the development team to focus on the next step within the Sprint. The team finds out where it stands and defines the plan for the day. A team may or may not use the full 15 minutes. But if there is a team the members simply have to coordinate. Within very small teams (e.g. 2 persons) there may be no need for a Daily Scrum. But even in these cases I have seen Daily Scrums to be very useful.
Similar to the retrospectives: If the Daily Scrum feels like waste, probably the ScrumMaster isn’t facilitating effectivly.
Assumptions
There are two assumptions underlying this blog post:
- You want to work with a team and not just a group of people.
- You want to work with timeboxed Sprints.
If one of these assumptions doesn’t hold true, one may come to other conclusions.
2 comments Juli 12, 2010
Buchempfehlungen zu lösungsorientiertem Coaching
In der letzten Zeit sind lösungsorientierte Ansätze (im Gegensatz zu problemorientierten Ansätzen wie Root-Cause-Analysis) etwas bekannter geworden. So haben wir auch beim Retrospektiven-Training am 25.08.2010 in Hamburg die lösungsorientierten Ansätze dabei. Die Grundzüge der Lösungsorientierung hatte ich bereits in einem vorigen Blogpost erklärt.
Nützliche Literatur zu dem Thema findet sich z.B. in den beiden Büchern „Coaching – erfrischend einfach“ von Daniel Meier und Peter Szabo sowie „Wege zur erfolgreichen Teamentwicklung“ von Daniel Meier.
Das erste Buch erklärt die Ideen und Techniken des lösungsorientierten Coachings auf individueller Ebene. Der Hintergrund ist allgemeines Coaching und nicht speziell IT. Die beschriebenen Techniken lassen sich aber leicht auf IT-Kontexte (z.B. für die Arbeit als ScrumMaster) übertragen. Das Buch ist angenehm kurz und leicht verständlich geschrieben.
Das zweite Buch beschreibt, wie man Lösungsorientierung für Teams einsetzt. Auch dieses Buch ist leicht verständlich geschrieben.
Wer sich näher mit dem Thema Lösungsorientierung beschäftigen möchte, dem lege ich diese beiden Bücher als Einstieg nahe (und natürlich das oben beschriebene Retrospektiven-Training 
Add comment Juli 8, 2010
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.
Add comment Juli 5, 2010
Code Katas with CodersDojo.com
Code Katas become more and more popular: little programming tasks, that programmers solve several times – every time a little better.
CodersDojo.org supports performing and improving Code Katas. Opening http://codersdojo.org with the internet browser of your choice shows the home page of CodersDojo.
By clicking „Enter the Dojo“ we enter the virtual Dojo, where we perform the Kata (until now only Ruby is supported).
In the right area a dummy test is displayed. We replace the dummy test with the first (test) step of our Kata (in this case the Fibonacci numbers). To make things simple we put production and test code in the same file.
With clicking „Run“ we run the test. The result is displayed in the left screen area.
Now we write only so much production code that the test succeeds.
This way we test drive the solution.
By clicking „Finish“ we get the analysis of the Kata.
There we see the overall duration of the Kata, the number of steps and a visualization of the TDD steps (red, green).
To improve the Kata we can give a collegue access to the Kata so that he can give feedback. We simply send him the link that is displayed at the bottom of the page. When the collegue opens the link he starts with the first step of the Kata. On the left side he can see the Code before and after the first „Run“. On the right side a text area waits for comments.
Our collegue can navigate forth and back through the Kata. When something strikes our collegue he adds his comment to the step.
Try it and give us feedback about CodersDojo!
Add comment Juni 23, 2010
Lösungs- vs. Problemorientierung
Klassischerweise geht man Probleme problemorientiert an. Man definiert das Problem und versucht dann, seiner Wurzelursache (Root-Cause) auf den Grund zu gehen. Beseitigt man die Wurzelursache, verschwindet das Problem dauerthaft. Dieser Ansatz findet sich sehr ausgereift bei Toyota, z.B. in Form des 5-Whys-Ansatz (5 mal “Warum?” fragen).
Als Alternative gibt es die sogenannte Lösungsorientierung. Diesen Ansatz gibt es auch schon lange, aber er wird erst jetzt populärer. Beim lösungsorientierten Ansatz versucht man nicht, die Ursachen für Probleme zu analysieren. Stattdessen sucht man direkt nach Lösungsansätzen. Das geschieht z.B. so, dass man fragt, ob es Situationen oder Zeiten gab, in denen das Problem nicht oder weniger stark aufgetreten ist. Die gibt es eigentlich immer. Und dann fragt man, was in diesen Situationen anders war. Und diese andere versucht man dann, wieder herzustellen bzw. zu verstärken.
Problemorientierte Ansätze funktionieren offensichtlich nur dann, wenn es eine stabile und nicht zu komplexe Problem-Ursache-Beziehung gibt. Das ist z.B. in Build-Systemen der Fall oder eben in der Produktion bei Toyota. Wenn am dem Problem Menschen beteiligt sind, ist das häufig nicht der Fall. Dann hat man fluktuierende Ursachen oder die Beziehungen zwischen Problem und Ursachen sind so komplex, dass wir sie nicht analytisch durchdringen können.
Ich habe solche Situationen in Retrospektiven schon mehrfach gesehen. Da war es so, dass bei der Root-Cause-Analysis letztlich nur ein schlappes “OK, wir geben uns mehr Mühe” als Maßnahme herauskam. Oder es kamen konkrete Maßnahmen raus, aber nach deren Umsetzung war das Problem immer noch unverändert da. Und wieder und wieder…
In diesen Fällen kommt man mit problemorientierten Ansätzen also nicht weiter. Wenn man weiterkommen will, sind lösungsorientierte Ansätze Erfolg versprechender. Dabei besteht natürlich das Risiki, dass man die eigentliche Ursache nicht beseitigt und die ganze Zeit nur Work-Arounds baut. Aber das ist immer noch besser, als mit Aufwand Ursachen zu analysieren, die auf jeden Fall sinnlose Maßnahmen hervorbringen.
Ein weiterer Vorteil lösungsorientierter Ansätze ist, dass sie häufig viel schneller sind. Um eine Root-Cause-Analysis vernünftig durchzuführen, brauche ich in einfachen Fällen mind. 30 Minuten. Mit lösungsorientierten Ansätzen ist man häufig schon nach 5 Minuten durch.
Ich gucke da nicht so drauf, dass lösungsorientierte Ansätze generell besser sind als problemorientierte. Es sind einfach zwei Werkzeuge, die ich in unterschiedlichen Situationen anwende.
Ich führe zusammen mit Josef Scherer am 25.08.2010 in Hamburg eine Retrospektiven-Schulung durch, in der sowohl problem- wie auch lösungsorientierte Ansätze durchgenommen werden. Näheres dazu findet sich bei it-agile.
3 comments Juni 19, 2010
Sprints – je kürzer, desto besser?
Vor kurzem war ich bei einer interessanten Diskussion um Sprintlängen dabei. Dabei wurde eine generelle Tendenz hin zu kürzeren Sprints festgestellt. Ich kenne neben wöchentlichen Sprints durch Ilja Preuss auch Fälle mit halbwöchigen Sprints und sogar zweitägigen Sprints. In allen diesen Fällen war das Team in der Lage, in der kurzen Sprintdauer ein Done-Done Produktinkrement zu liefern. Außerdem ist es gelungen, die Dauer der Sprintwechsel-Meetings (Planning, Review, Retrospektive) linear mit der Sprintdauer zu reduzieren.
Wir sind in der Diskussion dann darauf gekommen, dass bzgl. der Sprints kürzer nicht unbedingt besser bedeuten muss. Bei sehr kurzen Sprints können folgende Probleme auftreten.
- Es kann passieren, dass sich kein motivierendes Sprintziel mehr formulieren lässt.
- Der Zeitrahmen im Sprint kann so eng werden, dass im Sprint nicht mehr konzeptionell gearbeitet werden kann. Das kann zu einer sehr strikten (tayloristischen) Arbeitsteilung zwischen Product Owner und Team führen.
- Diese beiden Punkte zusammen können zu routinisierter langweiliger Arbeit führen. Und wenn das eintritt, wird es für das Team sehr schwer, innovative Verbesserungsvorschläge in Retrospektiven zu generieren.
- Bei Fehlern hat das Team keine Zeit mehr, um den Sprint trotzdem noch zu schaffen. Das kann zu Defensivverhalten führen und dazu, dass nicht mehr experimentiert wird.
Tatsächlich habe ich solche Fälle auch gesehen, z.B. bei einem Team, das in einem lang laufenden Projekt mit einwöchigen Sprints gearbeitet hat. Das Team hatte eine sehr verlässliche Geschwindigkeit und hat fast alle seine Commitments gehalten. In dem Projekt hätten wir aber einen deutlichen Produktivitätsschub gebraucht. Tatsächlich haben aber die in den Retrospektiven generierten Maßnahmen aber vor allem dazu geführt, dass die Geschwindigkeit noch stabiler wurde. Damals konnte ich mir keinen Reim darauf machen und war sehr verwirrt. Aus heutiger Sicht halte ich es für wahrscheinlich, dass die kurze Sprintlänge mit verantwortlich war. Heute würde ich dem Team empfehlen, mal längere Sprints auszuprobieren.
Wie gesagt: Das muss nicht so passieren. Ich habe auch sehr erfolgreiche und kreative Teams mit einwöchigen Sprints gesehen und Ilja hat mir glaubhaft versichert, dass auch die zweitägigen Sprints sehr erfolgreich waren.
P.S.: Das ändert alles nichts daran, dass die Teams in der Lage sein sollten, bei Bedarf sehr kurze Sprints umsetzen zu können – also in sehr kurzer Zeit ein Done-Done Produktinkrement zu erstellen.
2 comments Juni 17, 2010
Code-Katas in CodersDojo.com
Code-Katas erfreuen sich zunehmender Beliebtheit: kleine Programmieraufgaben, die man mehrfach löst und jede Lösung ein wenig verbessert.
CodersDojo.org unterstützt Code-Katas. Nach Aufruf von http://codersdojo.org erscheint die Start-Seite.
Mit „Enter the Dojo“ betreten wir das virtuelle Dojo, in dem wir die Kata durchführen (bisher nur in Ruby).
Im rechten Bereich wird ein Dummy-Test vorgeschlagen. Wir ersetzen den Dummy-Test durch den ersten (Test-)Schritt unserer Kata (in diesem Fall die Fibonacci-Reihe). Um die Angelegenheit möglichst einfach zu gestalten, schreiben wir Produktiv- und Testcode in dieselbe Datei.
Durch click auf „Run“ führen wir unseren Test aus. Links wird das Ergebnis der Testausführung angezeigt.
Jetzt schreiben wir soviel Produktivcode, dass der Test durchläuft.
So entwickeln wir schrittweise testgetrieben unsere Lösung.
Durch click auf „Finish“ gelangen wir zur Auswertung der Kata.
Dort sehen wir die Gesamtdauer der Kata, die Anzahl der Schritte und eine Visualisierung der TDD-Schritte (rot, grün).
Zur Verbesserung der eigenen Fähigkeiten können wir die Kata einem Kollegen zur Kommentierung zur Verfügung stellen. Dazu senden wir ihm den Link, der unten auf der Seite angegeben ist. Öffnet der Kollege den Link, sieht er den ersten Schritt der Kata. Links sieht er den Code vor und nach dem ersten „Run“. Rechts steht ein Feld für seine Kommentare zur Verfügung.
Der Kollege kann durch die Kata navigieren. Wo ihm etwas auffällt, schreibt er seinen Kommentar zu dem Schritt dazu.
Probiert es einfach mal aus und gebt uns Feedback zu CodersDojo.
Add comment Juni 2, 2010
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.
Add comment Mai 26, 2010
