Posts tagged ‘it-agile-blog-planet’

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.

September 21, 2010 at 11:43 am 1 comment

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:

  1. The product backlog items are estimated by the team.
  2. 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.

July 12, 2010 at 12:28 pm 2 comments

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

July 5, 2010 at 7:48 pm Leave a comment

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!

June 23, 2010 at 6:46 pm Leave a comment

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.

June 17, 2010 at 8:15 pm 2 comments

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.

May 18, 2010 at 10:02 am 1 comment

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.

March 4, 2010 at 9:08 pm 5 comments

Older Posts Newer Posts