Software Engineering Blog

Vor ein paar Tagen habe ich ja schon einmal den Vortrag von Alan Atlas über die Einführung von Scrum bei Amazon berichtet, über die der bei ImmobilienScout24 gesprochen hat.

Marion Eickmann von agile42 hat Altas kurz danach zum Berliner Scrumtisch eingeladen und das auch in ihrem Blog mit Fotos dokumentiert. Aus dem Blog heraus kann man auch die Präsentation herunterladen.

Isabel Drost hat sich die Zeit genommen und Atlas' Vortrag in Ihren Blog ausführlich dokumentiert.

Wie gut ein Team kommuniziert und Lösungen findet, läßt sich sehr gut an seinem Whiteboard ablesen. Idealerweise gibt es mehr als ein Whiteboard, aber das nur am Rande. Werden an diesem Whiteboard gemeinsam Probleme diskutiert und Lösungen gefunden, dann ist das, was auf dem Whiteboard steht wertvoll. Doch wie gehen wir mit diesen Werten um?

Oft habe ich bis jetzt beobachtet, daß ein Whiteboard während einer langen Diskussion immer wieder beschrieben wird, um diese dann gleich wieder abzuwischen, da der Platz wieder benötigt wird. Kurz vorher wird noch gefragt: "Alles klar? Kann ich das wieder abwischen?" Dummerweise steckt die Information genau in diesem Moment noch in unserem Kurzzeitgedächtnis und die Wahrscheinlichkeit ist hoch, daß es über dieses nicht hinauskommt. Das heißt nichts anderes, als das es morgen vergessen sein wird.

Wir dokumentieren dieses Wissen nur in wenigen Fällen. Und wenn, dann auch meist falsch. In den meisten Fällen werden einfach Fotos gemacht und diese in irgendeinem Verzeichnis abgelegt. Leider versauern sie dann dort auch. Das ist nicht schade, denn meist sagen die Bilder anderen ohne irgendeinen Kommentar auch nichts.

Aus diesem Grund habe ich vor einiger Zeit eine PowerPoint-Vorlage erstellt, mit denen man sehr einfach Whiteboard-Diskussionen dokumentieren kann. Im Grunde bietet die Vorlage nicht mehr, als ein paar Layoutvorlagen für Bilder in Hoch- und Querformat mit einem Textfeld für Notizen. Hinzu kommt noch eine Titelfolie, auf der man Dinge wie Teilnehmer und Datum bei Bedarf eintragen kann und ein paar weitere Folien für ausführlichere Kommentare.

Die Anwendung

Was wird noch gebraucht? Eine Digitalkamera oder ein besseres Handy. Damit wird das Whiteboard während der Besprechung abfotografiert und die Bilder anschließend in die PowerPoint-Vorlage eingefügt und soweit wie notwendig kommentiert. Anschließend sollte die PowerPoint noch als PDF abgespeichert werden, denn für die Verteilung an Externe sind solche offenen Formate wesentlich besser geeignet.

So lassen sich Diskussionen und Entscheidungen effizient und effektiv dokumentieren und können auf professionell verteilt werden. Und das ohne viel Aufwand.

Beispiel

Auf den Bildern in diesem Artikel ist ein kleines Beispiel für den Einsatz der Powerpoint-Vorlage enthalten und ganz am Ende sind ein paar Download-Links für das Beispiel und die Vorlage selber enthalten.

Beispiel für die Titelseite einer Whiteboard-Dokumentation.

Folie für eine ausführlichere Dokumentation in Textform.

Beispiel für die Verwendung mit einem hochformatigen Bild.

Beispiel für die Verwendung mit einem querformatigen Bild.

Auf der letzten Folie können ein paar Schlußbemerkungen festgehalten werden.

Eine gute Alternative zu dieser Vorlage ist die Dokumentation in einem Blog. In meinem Artikel Tod den Statusmails, es lebe das Blog habe ich hierzu auch schon einmal etwas geschrieben.

Gestern bin ich auf dem Scrum-Symposium hier in Berlin von ImmobilienScout24 gewesen und hatte die Möglichkeit zwei Vorträge über Scrum in der Praxis zu hören. Der erste beschäftigte sich mit Scrum bei ImmobilienScout24. Leider habe ich dank der vereisten Berliner Straßen das meiste davon verpaßt. Der zweite wurde Vortrag an diesem Abend wurde von Alan Atlas gehalten, der bei Amazon die Webservices-Sparte (mit?) aufgebaut hat. Altas erzählte auf eine sehr unterhaltsame Art und Weise, wie er bei Amazon Scrum eingeführt hat. Eine kurze Zusammenfassung kann hier gefunden werden.

Was aber für mich wieder am interessantesten zu beobachten war, war daß in den Fragerunden, fast egal wo man ist, immer wieder die gleichen Fragen auftauchen. Wie gehe ich mit dem Testen um? Wie plane ich richtig und auch über längere Zeiträume? Wo bleibt der Architekt und was macht er? Wie tue ich dies oder jenes? Warum sagt und Scrum nicht, wie wir das zu tun haben? Einige Punkte hierzu werden von auch von Uncle Bob angesprochen oder auf XING in der Scrum-Gruppe diskutiert.

Der Kern von Scrum

Scrum hat kein Problem. Das was einige für ein Problem halten, ist die Grundeigentschaft von Scrum. Scrum ist wie viele agile Prozesse schlank aufgestellt und bringt nur wenige Regeln mit. Doch wir wollen an die Hand genommen werden und in Sicherheit sein, in dem wir die Regeln befolgen, die es gibt. Gibt es diese nicht, fühlen wir uns unsicher.

Bleibt also die Frage, was Scrum ist, wenn es uns doch keine Antwort auf alle Fragen in jeder Situation ist?

Scrum kann ganz einfach auf folgendes heruntergebrochen werden:

• Scrum ist Selbstorganisation. Wir sind angehalten uns selber die Regel zu geben, die wir für richtig halten.
• Scrum ist Kommunikation. Dadurch sollen wir anfangen uns auszutauschen, gemeinsam Probleme zu lösen und Wissen zu verteilen.
• Scrum ist kontinuierliche Verbesserung. Probleme sollen nicht auf die lange Bank geschoben werden, sondern aktiv gelöst.

Dafür gibt uns Scrum ein Rahmenwerk mit ein paar Regeln und Rollen. Umsetzen müssen wir es. Das ist schwer, aber auch sehr spannend.

Ein Freund meinte einmal zu mir, daß das doch alles "gesunder Menschenverstand" sei. Sicherlich ja, aber beherzigen wir den auch immer?

Seit letzter Woche bin ich Certified ScrumMaster und damit von der Scrum Alliance berechtigt, "to transform the world of work".

Gerade habe ich meinen Artikel zu Apache Hadoop bei heise Developer abgegeben. Sobald er durch die Redaktion durch ist, werde ich den Link zum Artikel hier posten.