Erkenntnisse einer Klassenfahrt

In der vergangenen Woche war ich mit der dritten Klasse unserer „Großen“ auf Klassenfahrt. Ziel der 25 Kinder (die meisten 9 Jahre alt) und zwei Begleiter (die Klassenlehrerin und ich) war die nordfriesische Insel Amrum. Wir hatten traumhaftes Wetter, eine tolle Unterkunft (das Schullandheim „Honigparadies“ in Nebel kann ich sehr empfehlen) und konnten viel erleben. Für mich war es spannend zu sehen, welche Parallelen man zum Projektgeschäft ziehen kann. Weiterlesen

Veröffentlicht unter Agil | Verschlagwortet mit

Das tapfere Schneiderlein

Frohe Ostern allerseits!

Dieses Jahr gibts für alle Freunde der „Geschichten vom Scrum“ ein ganz besonderes Osterei: Eine Episode, die es nicht ins Buch geschafft hat. Warum nicht? Nun, den Reviewern war die Episode zu negativ. Tatsächlich kommen die Berater nicht allzu gut darin weg. Dabei wollte ich gar nicht den Nestbeschmutzer spielen, sondern vielmehr das gelegentliche Gehabe meine Zunft mit einem Augenzwinkern kommentieren. Nun bin ich gespannt auf die Reaktionen: Hatten die Reviewer recht, und diese Episode wäre besser nie veröffentlicht worden? Weiterlesen

Scrum: Ein Kreislauf der Verantwortung

In Scrum und anderen agilen Vorgehensweisen und Frameworks spielt die Verantwortung eine große Rolle. Der Begriff „Verantwortung“ ist eine mögliche Übersetzung des englischen Begriffs „commitment“. Die andere Übersetzung, die ich im Zusammenhang mit agilen Vorgehensweisen gerne verwende, ist „Verpflichtung“. Beide Begriffe meinen Ähnliches, aber eben nicht dasselbe. Die Verpflichtung zielt meinem Verständnis nach in der Hauptsache auf die termingerechte Lieferung des gemeinsam festgelegten Ergebnisses ab. Verantwortung ist für mich der weitaus stärkere Begriff, umfasst er doch neben der  konsequenten Ergebnisorientierung auch die Sorge für den Prozess und das Team – und noch einige andere Dinge, die ich zu einem „Scrum-Verantwortungskreis“ zusammengefasst habe:

Der Scrum-Verantwortungskreis

Weiterlesen

Geschichten vom Scrum

Geschichten vom Scrum - CoverIn der agilen Welt bedient man sich gerne der uralten Tradition des Geschichtenerzählens, um Wissen zu vermitteln und Inhalte erlebbar zu machen. Menschen lieben Geschichten, und Softwareentwickler bilden da keine Ausnahme.

Diese Idee greife ich mit den »Geschichten vom Scrum« auf. Anhand eines fiktiven Projekts illustriere ich die Werte, Konzepte und Praktiken, die agile Softwareentwicklung und agiles Projektmanagement ausmachen:

König Schærmæn der Weißnichtwievielte hat eine Vision: Er möchte die beste und flexibelste Drachenfalle aller Zeiten entwerfen und bauen lassen. Um diese Aufgabe zu meistern, lässt er eine geeignete Mannschaft zusammenstellen. Unter Anleitung eines Einhorns aus dem Lande Scrum macht sich eine Gruppe ganz normaler Märchengestalten ohne agile Vorkenntnisse an die Arbeit. Es gibt viel zu lernen: Das Handwerkszeug von Scrum und der Drachenfallenbau wollen beherrscht und zwischenmenschliche Probleme gemeistert werden. Am
Ende entsteht nicht nur die gewünschte Drachenfalle, sondern auch ein erfolgreiches Scrum-Team.

Als Leser begleiten Sie die Märchengestalten auf ihrem Weg zum Projekterfolg. Dabei unterstützen Sie die ergänzenden Erläuterungen
und Kommentare des Einhorns. Am Ende wissen Sie nicht nur, aus welchen Elementen Scrum besteht, sondern auch, wie man diese Elemente erfolgreich einsetzt.

Homepage zum Buch

Prinzen und Aschenputtel: Anatomie eines Scrum-Teams

Zum letzten Mal habe ich die Urfassung des agilen Märchens „Prinzen und Aschenputtel“ präsentiert. Jetzt gibt’s die „Geschichten vom Scrum“ als Buch. Auf den XP Days konnte ich das erste Exemplar in den Händen halten – immer wieder schön… Aber worum ging es in meinem Vortrag?

In der agilen Literatur ist es fast wie im Märchen: Da werden die besten Mitarbeiter einer Firma zusammengerufen, um gemeinsam das beste Produkt aller Zeiten in vielen kleinen Schritten herzustellen – bei ständiger Zufriedenheit des Kunden. Das Team arbeitet selbstbestimmt und zielorientiert, man hilft sich gegenseitig, und alles wird gut. In der Praxis kann man froh sein, wenn man zu Projektbeginn überhaupt ein Team hat. Die Besten darf man höchstens ab und zu als Experten zu Rate ziehen. Dafür findet man die gesamte Bandbreite an Charaktereigenschaften vor: Prinzen – heimliche Anführer unter Gleichen; Ritter in goldener Rüstung – ohne sie läuft nichts, sie schlagen den Weg frei; das tapfere Schneiderlein – mit ihm ist man gut (?) beraten; Aschenputtel – das tiefe stille Wasser. Und viele weitere sonderbare Gestalten.

Lassen Sie sich verzaubern und erleben Sie, wie mit Hilfe eines Einhorns aus dem wunderbaren Land Scrum aus diesen Individuen ein schlagkräftiges Team geformt werden kann.

Der Podcast zum Vortrag

Scrum – ein ehrliches Handwerk

…zumindest könnte man das annehmen, wenn der vierte Hamburger Scrumtisch in den Räumen der Hamburger Handwerkskammer stattfindet. Aufgrund der vielen Anmeldungen sahen sich die Organisatoren gezwungen, auf einen Veranstaltungsort auszuweichen, der mehr Raum bot als das kuschelige P.I.A. Kesselhaus in Ottensen, das bisher die Scrumtische beherbergte. Leider fanden gestern nur wenige Scrum-Interessierte den Weg zum Holstenwall. Diese „Mannschaft“, die sich aus alten Stammtisch-Hasen und Neulingen zusammensetzte, erlebte und gestaltete eine Veranstaltung, die ausschließlich das Open-Space-Format nutzte, um aus dem Gremium eingebrachte Themen in drei Runden an jeweils drei Tischen zu diskutieren. Das macht in Summe neun Diskussionsrunden. Vom „Gesetz der Füße“ wurde eher spärlich Gebrauch gemacht – vermutlich ein Indiz dafür, dass die Diskussionen zu fesseln vermochten. Ich musste früh aufbrechen und kam deshalb in den Genuss von nur zwei Open-Space-Runden.

Nachdem die Frage nach dem Wesen des User Story Mapping (Artikel|Video) in Ermangelung an Experten dieser Praktik nicht zufriedenstellend beantwortet werden konnte, vertagten wir dieses Thema auf den nächsten Stammtisch (glücklicherweise fand sich jemand, der das Thema mit dahin aufbereiten wollte) und widmeten uns stattdessen der Frage, wie man „gute“ Stories schreibt. Dem spontanen Schweigen nach zu urteilen, gibt es auf diese Frage keine schnelle Antwort. Wir versuchten deshalb, die Güte einer Story über deren Wert zu ermitteln. Natürlich schwirrte sofort der Begriff des Geschäftswerts im Raum. Als wir uns dann aber einigen konkreten Beispielen widmeten, mussten wir schnell feststellen, dass in bestimmten Projekten und allgemein in den ersten Sprints die Suche nach dem Geschäftswert recht schwierig ist. „Was spricht dagegen, den Geschäftswert in diesen Fällen durch einen anderen Nutzen zu ersetzen?“, fragten wir uns. Wie aber kann ein solcher Nutzen aussehen? Und wann entsteht dann der Geschäftswert? Nach einer „wert-vollen“ Diskussion mussten wir uns eingestehen, dass wir bei dem Begriff „Geschäftswert“ sofort an monetäre Größen denken. Es können aber tatsächlich ganz andere Aspekte eine Rolle spielen: Beispielsweise kann eine Story einen strategischen Wert besitzen, unter Umständen auch „nur“ einen ideellen Wert. Oder der Produktverantwortliche verbindet mit der hohen Priorisierung einer Anforderung einen zeitlichen Vorteil: Je früher das Feature verfügbar ist, umso länger hat man in diesem Bereich einen Vorsprung vor den Mitbewerbern. Ein Geschäftswert ist also mehr als nur Heller und Pfennig.

„Gute“ Stories sind immer überschaubar. Was aber, wenn der Kunde die Lösung mit dem Goldrand möchte, diese jedoch in einem Sprint nicht umsetzbar ist? Wie bricht man eine solche Story in kleinere Einheiten auf? Ein interessanter Vorschlag kam von Stefan Roock: Mittels Dimensional Planning. Darunter versteht man in der agilen Welt die Bewertung einer Story nach deren „Tiefe“, man könnte auch sagen: Komfort – vergleichbar dem System der Hotel-Sterne. Als Metapher für das Dimensional Planning nannte Stefan den Straßenbau. Um mit einem Fahrzeug von A nach B zu kommen, benötige ich eine Straße. Dabei kann es sich im einfachsten Fall um eine Schotterpiste handeln, über die ich mehr schlecht als recht mein Ziel erreiche. Eine mit Kopfsteinen gepflasterte Straße ist schon deutlich komfortabler, rüttelt mein Fahrzeug aber immer noch ordentlich durch. Das ist bei der asphaltierten Straße nicht mehr Fall. Trotzdem kann ich immer noch nicht so schnell fahren, wie ich eigentlich möchte. Das darf ich erst tun, wenn meine Straße zur Autobahn ausgebaut wurde. Ähnlich ist es beim Sterne-System im Hotelgewerbe: In einem Zwei-Sterne-Hotel kann man auch schlafen, weil der minimale Standard ein Bett umfasst. Im Fünf-Sterne-Grand-Hotel ist das Bett aber weicher, die Matratze nicht so durchgelegen, und der Service viel besser – das Frühstück wird mir direkt am Bett serviert. Kommen wir zurück zu den Stories: Diese lassen sich ebenfalls nach ihrem Komfort kategorisieren. Damit ist es möglich, in einem Sprint eine Story in der Drei-Sterne-Version umzusetzen, und zwei Sprints später dieses Feature mit Vier-Sterne-Komfort zu versehen.

Aber was genau macht denn nun eine „gute“ Story aus? Auf diese Frage haben wir leider keine allgemein gültige Antwort gefunden – vermutlich deshalb, weil es keine einfache Antwort auf diese Frage gibt.

Henning Wolf stellte in der zweiten Diskussionsrunde eine interessante These in den Raum: Mit Blick auf das agile Schätzen hinterfragte er den Sinn der Fokussierung auf die Größe einer Story. Seiner Meinung nach sollte man auch die Komplexität einer Story berücksichtigen. Eine saubere Definition des Begriffs „Komplexität“ bildete sich in der nachfolgenden Diskussion zwar nicht heraus (ist aber auch ganz schön kompliziert), aber die Idee, die hinter dem Schätzen von Komplexität steht, wurde dennoch deutlich. So sollte die Anzeige von Kundendaten in der Benutzungsoberfläche aus fachlicher Sicht genauso groß (d.h. aufwendig zu implementieren) sein wie die Anzeige von Lieferantendaten. Wenn letztere jedoch aus verschiedenen Datenquellen zusammengestellt werden müssen, dann dürfte die Komplexität dieser Aufgabe (im Sinne von miteinander in Beziehung zu setzenden Komponenten) höher sein als im Falle der Kundendaten, die aus einer einzigen Datenbank bezogen werden. Gleiche Aufgabe (Anzeige von Daten), aber unterschiedliche Komplexität (Datenzugriff): Wenn man das dem Kunden bewusst machen kann, dann besteht die Hoffnung, dass auf diese Weise die Erklärungen (bzw. Rechtfertigungen) agiler Teams ihrer vermeintlich zu hohen Größenschätzungen in Zulunft entfallen oder zumindest deutlich seltener vorkommen werden.

Die Komplexität kann aber multidimensional sein. Im genannten Beispiel hat der Zugriff auf Daten für verschiedene Domänen (Kunden, Lieferanten) eine unterschiedlich hohe Komplexität. Der Mechanismus für die Anzeige von Daten und den damit verbundenen Datenzugriff quer durch alle Systemschichten hat eine eigene Komplexität. Erst die Kombination dieser beiden Komplexitätswerte liefert für die Stories „Anzeige von Kundendaten“ und „Anzeige von Lieferantendaten“ eine realistische Gesamtkomplexität.

Ein weiterer Vorteil der „Komplexitätsorientierung“ wurde nur kurz andiskutiert und müsste meiner Meinung nach noch vertieft werden: Wie wirken sich Refactorings auf Größe und Komplexität einer Story aus? Ich hege die Hoffnung, dass es mit der kombinierten Bewertung von Größe und Komplexität möglich ist, unseren Kunden den Wert eines Refactorings nachzuweisen. Damit gehört dann hoffentlich eine weitere Diskussionskategorie („Was soll dieses teuere Refactoring? Ich sehen doch gar keine Veränderung!“) der Vergangenheit an. Unrealistisch? Vielleicht. Aber man wird doch wohl mal träumen dürfen…

Prinzen und Aschenputtel: Anatomie eines Scrum-Teams

In der agilen Literatur ist es fast wie im Märchen: Da werden die besten Mitarbeiter einer Firma zusammengerufen, um gemeinsam das beste Produkt aller Zeiten in vielen kleinen Schritten herzustellen – bei ständiger Zufriedenheit des Kunden. Das Team arbeitet selbstbestimmt und zielorientiert, man hilft sich gegenseitig, und alles wird gut. In der Praxis kann man froh sein, wenn man zu Projektbeginn überhaupt ein Team hat. Die Besten darf man höchstens ab und zu als Experten zu Rate ziehen. Dafür findet man die gesamte Bandbreite an Charaktereigenschaften vor: Prinzen – heimliche Anführer unter Gleichen; Ritter in goldener Rüstung – ohne sie läuft nichts, sie schlagen den Weg frei; das tapfere Schneiderlein – mit ihm ist man gut (?) beraten; Aschenputtel – das tiefe stille Wasser. Und viele weitere sonderbare Gestalten.

Lassen Sie sich verzaubern und erleben Sie, wie mit Hilfe eines Einhorns aus dem wunderbaren Land Scrum aus diesen Individuen ein schlagkräftiges Team geformt werden kann.

Scrumtisch Hamburg: Aller guten Dinge sind drei

Es heißt ja, dass ein Scrum-Projekt nach drei Iterationen die Phase der Eingewöhnung überwunden hat und so richtig durchstartet. Vielleicht liegt es an der Scrum-Affinität der Teilnehmer, dass sich der dritte Hamburger Scrumtisch so anfühlte, als wäre dies eine im positiven Sinne alteingesessene Institution. Die Organisation klappte wieder reibungslos (dafür mein besonderer Dank an die Organisatoren). Die kurze Vorstellungsrunde zu Beginn bestätigte die hohe Zahl an Stammgästen. Es hatten aber auch einige Erstbesucher den Weg ins P.I.A.-Kesselhaus in Ottensen gefunden. Überraschend hoch war die Zahl derer, die offen bekannten, derzeit auf Jobsuche zu sein. Eine Auswirkung der Finanzkrise? Oder Zeichen dafür, dass agil Infizierte sich nicht einfach über ihr Arbeitsumfeld beschweren, sondern tatsächlich die Konsequenzen ziehen, wenn sie feststellen, dass sie die agilen Ideen in diesem Umfeld nicht verwirklichen können?

Der inhaltliche Teil begann mit zwei Vorträgen. Zunächst stellte Markus Wittwer (oose) kurz die Ergebnisse der Studie „Einfluss klassischer und agiler Techniken auf den Projekterfolg“ vor. Anschließend präsentierte Sebastian Neus (itemis) ein Konzept, wie man Product Backlogs noch besser (im Sinne der Maximierung des Geschäftswertes) machen kann. Da beide Vorträge intensiv diskutiert wurden, machte es auch nichts, dass sie für meinen Geschmack etwas zu lang waren.

Persönliches Schmunzel-Highlight war die von Sebastian vorgestellte Idee des „Build-Breaker-T-Shirts“. Diese Idee war in einem seiner Projekte von der Entwicklungsmannschaft eingeführt worden und bestand aus nur zwei Regeln:

  1. Wer den Build bricht, der muss dieses T-Shirt tragen.
  2. Das T-Shirt wird nie gewaschen.

Eine einfache Methode, um schlechte Entwicklungsdisziplin förmlich zu riechen…

Frisch gestärkt ging’s anschließend in bewährter Weise mit Open Spaces weiter. Ich nahm an zwei spannenden Diskussionen teil. In der ersten ging es um die Frage, ob man „messen“ kann, wie geeignet eine Person für die Arbeit in einem agilen Team ist. Die Transparenz und die Ergebnisorientierung agiler Projekte decken fachliche und soziale Defizite schonungslos auf, und nicht jeder kann und mag sich darauf einstellen. Im Team wird man fast immer ein fachliches Leistungsgefälle vorfinden. Das lässt sich mit Praktiken wie Pair Programming und Coaching/Mentoring einigermaßen nivellieren – vorausgesetzt, die „Lehrer“ besitzen die nötige Sozialkompetenz, um ihr Wissen vermitteln zu können (und zu wollen), und die „Schüler“ sind stark genug, diese Hilfe vor den Augen des restlichen Teams anzunehmen. Was aber tun mit Teammitgliedern, sie sich überhaupt nicht integrieren können? Immer wieder hört man den Rat. „Nehmt diese Menschen aus dem Team heraus.“ Leichter gesagt als getan. Oft sind die organisatorischen Voraussetzungen für eine flexible Jobrotation nicht gegeben. Außerdem wechseln sich in der IT Personal- und Geldknappheit in schöner Regelmäßigkeit ab, und beide Restriktionen sind nicht gerade förderlich für die Entwicklung „idealer“ Teams. Das weitaus größere Problem ist allerdings das (typisch deutsche?) Ideal der gradlinigen Karriere. Wer im Laufe seiner beruflichen Entwicklung in fachfremde Bereiche wechselt oder vermeintlich einen Schritt zurück macht, der gilt auch heute noch als schwach und wird fortan Probleme haben, auf der Karriereleiter unbeschwert nach oben zu klettern. Damit ist die These, dass es sich um ein Generationsproblem handelt, vom Tisch, denn auch die heutigen Berufsanfänger werden (zumindest in den konservativ strukturierten großen und mittelständischen Unternehmen) an demselben Maß gemessen wie die Generationen vor ihnen.

Der Change Agent für agile Teams ist der Scrum Master – aber ist er überhaupt dazu in der Lage? Und wer kann das beurteilen? Das war das Thema einer weiteren Open-Space-Diskussion (an der ich leider nicht teilnehmen konnte). Hier wurde der Frage nachgegangen, ob man eine Supervision für Scrum Master etablieren sollte. Dieses Konzept ist in anderen Bereichen etabliert, insbesondere bei Lehrern und Sozialarbeitern, und verfolgt das Ziel, über Selbst- und Fremdreflexion zu lernen und das eigene Verhalten zu verbessern. Klingt nach einer persönlichen Retrospektive, oder? Liegt es da nahe, auch für Scrum Master eine Supervision zu fordern? Ein spannendes Thema…

Ich habe mich dann in der zweiten Open-Space-Runde des Abends der Frage gewidmet, was man gegen „Ermüdung“ im Scrum-Team unternehmen kann. Die konkrete Situation: Das Team befindet sich im zwanzigsten Sprint, alles läuft wie geschmiert, fühlt sich aber mehr nach täglichem Trott als nach dem sagenumwobenen „Flow“ an. Wo aber hört der Flow auf und fängt die Ermüdung an? Sobald die agilen Werte vernachlässigt werden? Wenn das Team keine Lust mehr hat? Und wer empfindet die Situation als ermüdend? In unserer Diskussionsrunde war es der Scrum Master, der aber zugeben musste, dass das Team durchaus zufrieden mit der neuen Gemütlichkeit war. Damit steckte er in der Zwickmühle: Wissend, dass aus dem Team mehr Leistung herauszuholen wäre, andererseits fühlend, dass er seinem Team diese Ruhe durchaus gönnen sollte. Die Ideen, die wir aus dieser Situationsbeschreibung entwickelten, hatten letztendlich alle dasselbe Ziel: Etwas Überraschendes zu tun bzw. zu fordern. So könnte man die Sprint-Dauer verkürzen, um den Trott zu durchbrechen und das Team neu zu stimulieren. So geschehen in einem konkreten Projekt – mit dem erstaunlichen Ergebnis, dass das Team im verkürzten Sprint genauso viel erledigt hatte wie im längeren Sprint. Eine andere (tatsächlich praktizierte) Möglichkeit ist die Ausschreibung eines „Hackathlon“-Wettbewerbs. Drei Tage lang wurden die Entwickler aller Scrum-Teams von ihren Aufgaben befreit und bekamen stattdessen das Ziel formuliert, innovative technische Lösungen zu ersinnen und prototypisch zu entwickeln. Die Ergebnisse wurden gegeneinander bewertet, und den Siegern winkte ein Preis. Ähnliches kann man erreichen, indem man den Sprint nicht verkürzt, aber nur vier Tage pro Woche auf das Sprint-Ziel verwendet. Den fünften Tag nutzt man dann für die Evaluierung neuer Technologien, konsequentes Refactoring und andere innovative und die Qualität verbessernde Maßnahmen. Dieses „4+1“-Prinzip hat den Vorteil, dass es ohne nach außen sichtbare Prozessveränderung auskommt – die Projektcontroller wird das freuen… Um die Kundenorientierung zu verbessern, kann man regelmäßige Hospitationen bei den Nutzern des Softwareprodukts durchführen (deren Einverständnis vorausgesetzt). Nichts hilft besser, als den Endanwendern bei deren Arbeit über die Schulter zu schauen und Fragen zu stellen.

Der Hamburger Scrumtisch wurde abschließend von allen Teilnehmern für seine offene Atmosphäre gelobt. Das nächste Treffen soll in drei Monaten stattfinden und wird wie üblich in der XING-Gruppe „Scrum User Group Hamburg“ angekündigt.