Agile Entwicklung

Menschen statt Ressourcen [OOP 2009]

Manchmal reden Menschen von anderen Menschen als “Ressourcen”, so als ob sie Maschinen oder Möbel oder Gebäude wären. Das Wort Ressource kommt dann in so seltsamen Wendungen wie “Human Resource Management” oder “die HR-Abteilung” vor. Ein besonderes Beispiel findet sich in der Definition des Begriffes “Projekt” im CMMI-Glossar. Dort heißt es:

A project is a managed set of interrelated resources that delivers one or more products to a customer or end user. The set of resources has a definite beginning and end and operates according to a plan.

Ich kann nur sagen: Wenn ich in einem solchen Projekt arbeitete, käme ich mir als “verwaltete, in einer Wechselbeziehung stehende Ressource” ziemlich seltsam vor. Wann spricht es sich endlich herum? Software wird von Menschen gemacht, nicht von Ressourcen!

Lern-Comics zu Scrum: Erste Tests

Um mein Gehirn mal wieder mit etwas Neuem zu trainieren, habe ich ein Flash-Video zum Thema Scrum produziert. Es ist nicht ganz ernst zu nehmen – viel Spaß damit!

Die Toolkette, die ich benutzt habe:

  • die animierte Präsentation in PowerPoint erstellen
  • die Präsentation in einem Fenster abspielen
  • mit iShowU aufnehmen
  • mit ffmpeg und flvtool2 nach Flash konvertieren
  • in FLV media player abspielen (flv media player in Blog-Eintrag einbetten)

Die Kommandozeile zum Umwandeln nach Flash:

ffmpeg -i iShowU-Capture.mov -f flv - | flvtool2 -UP stdin new_product_owner.flv

Zweiter Sprint zu Ende

Das Scrum-Team meines aktuellen Kunden beendet gerade seinen zweiten Sprint. Die Warp-Signatur auf dem Burndown-Chart sieht deutlich besser aus als beim ersten Mal, die gesamte Kurve bewegt sich unterhalb der gestrichelten Linie. Und: Wir konnten zweimal im Sprint je drei Storypoints aus dem Backlog “nachladen” – anscheinend hatten wir zu konservativ geschätzt.

Wenn nur nicht heute am letzten Tag des Sprints einer den Build rot gemacht hätte… naja, das bekommen wir noch hin, denke ich. Übermorgen ist Planning-Meeting für den nächsten Sprint.

Übrigens: Diese Leute aus Dänemark hier erklären locker in 5 Minuten, was Scrum ist:

Scrum-Gerüche

Mike Cohn hat begonnen, eine Sammlung mit “Scrum Smells” anzulegen (analog zu den “Code Smells” von Martin Fowler). Scrum Smells sind “schlecht riechende” Muster, die man benutzen kann, um potenzielle Risiken durch falsche Anwendung der Scrum-Methodik frühzeitig zu bemerken. Schnuppern Sie mal.

Erster Sprint zu Ende, der zweite geht los

Mit dem Monatsende kam auch das Sprint-Ende mit Review und Retrospektive. Das Ergebnis sieht gut aus – das Team hat sich konzentriert und die Stories auch wirklich fertig (“done”) entwickelt. Wir mussten unterwegs etwas Federn lassen, weil wir unsere Geschwindigkeit überschätzt hatten. Der Product Owner konnte das durch Herausnehmen von Stories korrigieren, und so haben wir den Sprint mit einer Punktlandung sauber beenden können.

Der Rest der Organisation bekommt langsam mit, dass Scrum ein erfolgreiches, motivierendes Verfahren sein könnte. Ich wurde gebeten, einen Vortrag darüber zu halten, was ich natürlich gern getan habe.

Das zweite Sprint-Planning ging viel besser als das erste – Stories in Tasks zerlegen und schätzen, Over- und Undercommitments ausbalancieren, alles diesmal sehr einfach und interaktiv. Die hypnotische Wirkung des Projektors, der das Bild des Bugtrackers an die Wand wirft, konnten wir diesmal fast neutralisieren.

Die Daily Scrums im zweiten Sprint gehen wie der Blitz. Die Teammitglieder haben schon die Kärtchen verschoben, ehe ich als ScrumMaster noch richtig gucken kann. Bin gespannt, wie es weitergeht.

Fernbeziehung

Einige Mitglieder unseres Scrum-Teams arbeiten manchmal an einem anderen Ort. Wir binden sie neuerdings ins Daily Scrum ein, indem sie bis morgens 09:00 die drei Scrum-Fragen per Email an ein Teammitglied vor Ort beantworten. Dieses Teammitglied vertritt die entfernten Mitarbeiter und antwortet stellvertretend für sie im Daily Scrum, das um 09:30 startet.

Wir sollten nun noch einführen, dass wir JPEG-Fotos vom Taskboard jeden Tag per Email an die entfernten Teammitglieder schicken, damit sie wissen, wo das Team steht. Schon habe ich als ScrumMaster wieder eine neue Aufgabe!

;-)

Erstes Daily Scrum

Heute war das erste Daily Scrum dieses Teams. Die Mitglieder sind bereits an morgendliche Stand-Up Meetings gewöhnt, doch mit Scrum ist das doch noch ein bisschen anders.

Die Runde lief ganz fein, jeder erklärte, was er gestern gemacht hat, was er heute macht und welche Hindernisse im Weg stehen. Mehr oder weniger alle reden mich (den ScrumMaster) an, obwohl ich am Anfang des Meetings extra gesagt habe, dass das Mitteilungen für die Peers sind, kein Statusbericht an mich. Ich bin jetzt im Moment kein Manager!

Das Taskboard enthielt bereits zwei Tasks, die unter “done” einsortiert waren. Also konnten wir den Restaufwand auf dem Burndown-Chart bereits etwas verkleinern.

Mehrere Pigs berichten, dass sie nicht richtig fokussieren können, weil zu viele Chickens von außen Support brauchen. Klar, in den anderen Abteilungen draußen wird u.a. gegen unsere APIs, die wir herausbringen, programmiert. Kein Wunder, dass das legitime Fragen nach sich zieht. Mal schauen, wie viel Fokusfaktor uns das kosten wird.

Ich muss noch eine Wikiseite für die Impediment List anlegen und allen mitteilen, dass sie da ist.

Die Neuigkeit “die im Soundso-Team machen jetzt was Neues, es heißt Scrum” verbreitet sich in den anderen Teams. Einige fragen mich, ob sie auch eine Kopie des Büchleins von Henrik Kniberg bekommen könnten, das ich für die Pigs beschaffen ließ. Natürlich, im Moment sind genug Exemplare vorhanden.

Bin gespannt, wie es weitergeht und wann die erste ganze Story (nicht Task) auf “done” gesetzt wird.

Papier schlägt Elektronik

Im heutigen Sprint-Planning-Meeting zeigte sich ganz deutlich: elektronische Medien wie Excel-Tabellen oder Bugtracker sind Gift für ein hochinteraktives Meeting! Liest jemand die Exceltabelle von der Beamer-Leinwand ab und fragt nach Schätzungen für ein Feature — allgemeines Gähnen ist die Folge. Schnappt sich das Team jedoch die Karteikarten an der Metaplanwand, wachen alle auf und fangen an, mitzumachen.

Dieses Video auf YouTube zeigt, wie ein anderes Team (nicht unseres!) Papier sehr kreativ nutzt, um dem Product Owner eine Software vorzuführen, die es noch gar nicht gibt. Viel Spaß beim Anschauen!

Sprint-Start hat wunderbar funktioniert

Das Team hat den Sprint sauber gestartet, und das obwohl sie noch nie vorher Scrum gemacht haben! Das macht Freude.

Product Backlog, Sprint Backlog, Product Owner, Taskboard, testbare Features, Aufwandsschätzungen, Velocity-Ermittlung, alles da in zwei halben Tagen à vier Stunden! Einen Moment, ich muss zugeben, das Product Backlog haben wir mit dem Product Owner und dem Team schon vorher erstellt und dann in den letzten Tagen des alten Vorgehens ganz penibel sauber gemacht, bevor wir in dieses Planning Meeting gingen – das hat uns lange Diskussionen erspart!

Jetzt bin ich gespannt, was im Daily Scrum passiert…

Retrospektive vor der Scrum-Einführung

In meinem aktuellen Projekt führe ich gerade Scrum ein. Warum? Ein Teammitglied brachte es auf den Punkt: Wenn Dir die Viecher auskommen, kannst Du sie jedesmal einzeln einfangen oder Dich entscheiden, einen Zaun zu bauen. Wir führen Scrum ein, um den Zaun zu schließen.

Nächste Woche geht es los mit dem ersten Sprint für dieses Projekt. Das Projekt hat bisher schon einiges entwickelt, deshalb hatten wir die Idee, diese zurückliegende Zeit als einen gigantischen Sprint aufzufassen, den wir nun offiziell und regulär beenden, bevor wir nächste Woche einen neuen starten.

Wir haben also diese Woche ein Sprint Review Meeting gemacht mit einer Demo des aktuell lauffähigen Standes der Software. Heute habe ich dann mit dem Team eine Sprint-Retrospektive gehalten, eine wirklich tolle Sache.

Eine Metaplan-Wand hatte ich unterteilt in die Bereiche “Start doing”, “stop doing”, “continue doing” und “change”. Dort hefteten die Teammitglieder Karteikarten mit Themen an, die wir entweder neu starten, mit denen wir aufhören oder mit denen wir weitermachen wollen.

Interessant war, dass unter “start doing” bei weitem die meisten Karten angeheftet wurden. Unter “stop doing” tauchten auch einige auf und unter “continue” bzw. “change” ebenfalls einige. Also ist dieses Team der Meinung, dass wir noch vieles neu einführen müssen.

Wir haben die Metaplan-Wand fotografiert und uploaden das Foto ins Wiki. Unter das Foto kommt noch einmal die Liste der Vorschläge, die auf den Karten stehen, um eine Online-Diskussion zu ermöglichen und die Maßnahmen tatsächlich umsetzbar zu machen.

Nebenbei bemerkt: Die Kategorien “start doing”, etc. stellen sich als viel konkreter und motivierender heraus als die an sich äquivalenten, doch viel mehr nach Wertung klingenden Kategorien “good”, “needs improvement” und “bad”.

Ich bin gespannt, wie viele Maßnahmen wir bis zum Ende des Sprints tatsächlich umgesetzt bekommen.