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…

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.

Hamburger Scrumtisch, Sprint 2

Heute fand der zweite Scrumtisch bei bestem Hamburger Wetter (Sonne und eine frische Brise) statt. Das neue Format, eine Kombination aus vorbereitetem Vortrag und Open Space, fand die ungeteilte Zustimmung der ca. 23 Teilnehmenden.

Was habe ich gelernt bzw. bestätigt bekommen?

  • Agile Festpreisprojekte können funktionieren, wenn man das Festpreis-Spiel konsequent (und manchmal auch unnachgiebig) spielt. Ein anderer Erfolg versprechender Ansatz ist das Abschließen eines Rahmenvertrags, in dem für einzelne Gewerke (z.B. für jeden Sprint) eine Tranche abgerufen wird.
  • Es ist schwierig, den agilen Werkzeugkasten im Team zu etablieren. Es ist aber noch ungleich schwieriger, die agilen Werte zu vermitteln und eine Kultur zu prägen, die auf Vertrauen und Verantwortung aufbaut.
  • Für die Berücksichtigung nichtfunktionaler Anforderungen gibt es leider keinen Königsweg. Es ist wichtig, diese Klasse von Anforderungen frühzeitig zu formulieren und zu priorisieren. Erst dann kann man fundiert entscheiden, wann welche Anforderung aus fachlichen oder technischen Gründen benötigt wird.

Die offene und ehrliche Atmosphäre, in der diese Themen diskutiert wurden, macht den Reiz dieser Veranstaltung aus und steigert die Vorfreude auf den nächsten Stammtisch (für den übrigens noch ein geeigneter Raum gesucht wird).