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!

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.

  1. Es kann passieren, dass sich kein motivierendes Sprintziel mehr formulieren lässt.
  2. 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.
  3. 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.
  4. 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.

JAX-Vortrag über Scrum-But(t) online

Auf der diesjährigen JAX-Konferenz habe ich einen Vortrag über Scrum-But(t) gehalten:

Wie viel “Scrum by the Book” muss man in der Praxis wirklich machen? Nicht jede Anpassung führt direkt in die Hölle. Auf der anderen Seite sind viele in der Praxis anzutreffende Anpassungen Quick Fixes für organisatorische Defizite. Der Vortrag stellt dar, wann Anpassungen angebracht sind und wann man besser vorsichtig ist.

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.

Kanban: Definition of Lead Time and Cycle Time

Important: Cycle time as a concept can have multiple meanings. This blog post uses just one specific meaning. Alexei Zheglov has a more accurate discussion of the cycle time concept.

When doing Kanban for software development measuring cycle and lead times is important but often the terms are confused or defined in a fuzzy way. Here is a useful definition from the “Lean and Kanban” blog:

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team. Bugs are reported via tickets in a ticket system like Bugzilla, Jira or Mantis. When the bug is detected a ticket is created and when the bugfix is live, the ticket is closed. This whole period of time is the lead time. The lead time is the time and not the effort. You may have a lead time of 100 days and only have to work 1 hour to fix the bug. Sometime you start working on the bug. The cycle time is the time from the start of the work until the bugfix is live. Again the cycle time is not the effort. Lead time can’t be shorter than cycle time. Often lead time is a lot longer. In the context of maintenance there is often a SLA (Service Level Agreement) in place that defines in which time frame you have to fix a bug. Often the SLA defines a resolution time. That is the same as the lead time: Most SLAs also define a response time. That is the time available until the team has to respond to a new bug ticket: is it really a bug and what is the priority. With these definitions in place it is obvious that the lead time is what is relevant from the business perspective. The cycle time is what the team can influence by itself by changing its work process. To reduce lead times one can (and should) reduce cycle time. But often the time before the work starts is really long so this wait time should be reduced also.