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.