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

Prezi “Inkrementeller Entwurf” als PDF

Letztes Jahr habe ich auf dem Scrum-Gathering in München einen Vortrag über inkrementellen Entwurf gehalten. Ich habe damals Prezi benutzt, was einen Nachteil hatte: Man konnte die “Folien” nicht als PDF bereitstellen. Das hat sich jetzt geändert. Hier ist die Präsentation als PDF (dann natürlich ohne die animierten Übergänge): InkrementellerEntwurf_Roock_Okt2010

Vortrag auf dem Objekt-Forum-Nord: “Auf der Suche nach dem Qualitäter”

Am 14.09.2010 haben Roman Pichler und ich auf dem Objekt-Forum Nord in Hamburg über Qualität vorgetragen. Roman hatte sich die Product-Owner-Sicher vorgenommen und ich die Entwicklersicht unter dem Titel: “Auf der Suche nach dem Qualitäter”.

Die PDFs der Folien finden sich hier zum Download.

Ich hatte meinem Vortrag begonnen mit einem Beispiel für wirklich schlecht strukturierten Code (siehe Folien) und habe ein paar Fragen ans Publikum gestellt. Die Antworten finde ich ganz interessant (die Zahlen stimmen im Detail wohl nicht, weil ich sie aus der Erinnerung rekonstruiert habe – die Größenordung passt aber).

• Wer ist sich sicher, dass es so schlecht strukturierten Code bei ihm im Projekt/Unternehmen gibt? Meldungen: 40
• Wer ist sich sicher, dass es solchen Code bei ihm nicht gibt? Meldungen: 1
• Wer ist sich unsicher? Meldungen: 5
• Wer kennt TDD? Meldungen: 30
• Wer nutzt TDD? Meldungen: 20
• Wer kennt SOLID? Meldungen: 20
• Wer nutzt SOLID? Meldungen: 10

Das Ergebnis passte auf jeden Fall gut zur Argumentationslinie meines Vortrags. Obwohl zumindest ein Teil der Teilnehmer TDD und SOLID kennen und nutzen, scheint es nur geringe Auswirkungen auf die Code-Qualität zu haben. Nach meiner These nützt das beste Handwerkszeug nichts, wenn man es unter Druck nicht anwendet.

Daher mein Argument, wir müssten Berufsehre für unsere Branche etablieren: Wir sind stolz auf unseren Code und schreiben nichts, was unter diesem (subjektiven) Qualitätsstandard liegt. Nichts. Niemals. Und wenn wir dort angekommen sind, werden uns Vorgehensweisen wie TDD und Entwurfsprinzipien wie SOLID wirklich wichtige Dienste leisten.

Warum man das Manifesto for Software Craftsmanship unterzeichnen und sich ein Clean-Code-Armband besorgen sollte, steht in den Folien.

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!

Code-Katas in CodersDojo.com

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

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

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

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

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

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

So entwickeln wir schrittweise testgetrieben unsere Lösung.

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

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

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

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

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

XP-Days Germany 2010 in Hamburg

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

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

Buchtipp “Clean Code”

Das Buch “Clean Code” von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.

Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.

Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.

Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht “naja…”. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.

Fazit: Aus meiner Sicht ist “Clean Code” ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.

Flow, Pair Programming, Teams und das Unerwartete

Ich bin jetzt endlich dazu gekommen, einen Artikel zu lesen, der schon eine Weile bei mir rumlag: “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” (PDF).

Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.

Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran (“Beginners Mind”) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.

Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein “Naturgesetz” in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!

Artikel zu Low-Tech-Tools in JAXenter

Auf JAXenter ist ein Artikel von mir zu Low-Tech-Tools erschienen: http://it-republik.de/jaxenter/artikel/Low-Tech-Tools-2747.html