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:
- Wer den Build bricht, der muss dieses T-Shirt tragen.
- 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.