Wir sind doch schon agil!

Der Job eines Scrum Master anhand des agile Fluency Models

In traditionellen Unternehmen gibt es den Projektmanager. Diese Person plant, steuert und kontrolliert den Projektfortlauf. Doch wer übernimmt diese Aufgabe in agilen Unternehmen? Ganz einfach: Hier übernimmt der Product Owner diesen Job.  Naja, so einfach ist es nicht. Der Product Owner ist dafür zuständig, den Wert eines Produktes zu maximieren. Die Verantwortlichkeit, dass zu einem gewissen Termin etwas geliefert wird, liegt beim Entwicklungs-Team. Neben dem Product Owner und dem Entwicklungsteam gibt es in agilen Projekten auch den Scrum Master. Doch was macht dieser genau? Wenn man den Scrum Master danach fragt, erhält man oft folgende Antworten: „Ich räume Impediments aus dem Weg“ oder „ich moderiere Events“. Das stimmt auch alles, aber der Scrum Master hat eine viel wichtigere Aufgabe. Er entwickelt das Team weiter! Wenn ein Scrum Master ein Team im Schnitt nur um 15 % besser macht, hat er seine Rolle mehr als kompensiert. Aber was heißt denn „besser“ sein? Dafür müssen wir verstehen, was es heißt „agil“ zu sein.

Agile Fluency Model

Diana Larsson (bekannt aus dem Standardwerk: Agile Retrospectives) und James Shore (XP-Guru) haben genau dazu ein Modell entwickelt, das sich damit befasst, wie „gut“ man etwas im agilen Kontext macht.  Das Modell besagt, dass Agilität in unterschiedlichen Entwicklungsphasen eines Teams eine andere Bedeutung hat. Und bei einem zugehörigen, agilen Skill ist es so, dass das Team diesen fließend, also „fluent“ beherrschen muss, damit es wirklich etwas bringt. Das heißt konkret: Wenn der Baum brennt, dann fallen wir nicht in alte Verhaltensmuster zurück, sondern arbeiten mit diesem erlernten Skillset weiter. Ein klassisches Beispiel hierfür ist trotz eines bevorstehenden Softwarefreezes und dem damit verbundenen Lieferdruck eine Retrospektive beizubehalten.

Focus on value

Viele Teams lernen schon innerhalb der ersten Monate, wie Scrum funktioniert. Aus einer Gruppe von Personen wird ein geschlossenes Team, das an einem Ort ungestört von äußeren Einflüssen zusammenarbeitet. Die direkte Kommunikation mit der Business-Seite (meistens in Form eines Product Owners) ermöglicht fokussiertes Arbeiten und weniger Übergaben. In dieser Phase kann das Team zielgerichtet arbeiten und das gesetzte Ziel schnell erreichen. So sieht das Management nach den ersten Wochen bereits eine deutliche Verbesserung (und lässt das Team in Ruhe).

Deliver value

Ungefähr nach dem ersten halben Jahr macht sich in den Retros immer häufiger bemerkbar, dass die Ideen zu Prozessverbesserungen immer weniger bringen und manche Elefanten leider einfach nicht gelöst werden können. Das Team ist enttäuscht und der Scrum Master fragt sich, wie es weiter gehen soll.  Die Antwort ist einfach: Wenn das Team sich nur auf die „Focus on Value“-Themen konzentriert, ist bald eine natürliche Grenze erreicht. Spätestens dann sollte der Scrum Master sich gemeinsam mit dem Team mit Extreme Programming Techniken wie zum Beispiel Pairing, Test-driven Development oder Evolutionary Design auseinandersetzen. Diese agilen Skills verbessern nicht zwingend die Geschwindigkeit, aber das Team erschafft eine Flexibilität, weil es jederzeit releasen und sich jeder Entwicklung von außen anpassen kann.

Optimize value

Nach den ersten zwei Phasen kann das Team sehr schnell Features entwickeln und sich flexibel an neue Projektanforderungen anpassen. Das heißt aber noch nicht, dass das Team sich auch an Marktanforderungen anpassen kann, da es diese überhaupt nicht kennen kann.  Diese Aufgabe übernimmt normalerweise der Product Owner. Viele Märkte sind jedoch extrem komplex und durch die Sichtweise einer einzigen Person nur sehr schwer zu durchdringen. Hier hilft nur ein multifunktionaler und möglichst objektiver Blick, der in einer Teamverantwortung schlussendlich weitreichender und vielschichtiger ist. Für diese Phasen eignen sich Techniken wie Lean Service Creation, Lean Startup oder Design Thinking. Diese schaffen Potentialfelder, um die Nutzer besser verstehen zu können und somit neue Verwendungszwecke oder sogar komplett neue Märkte zu generieren.

Optimize for system

In der Regel optimieren Teams im System, aber was wäre denn, wenn sie über die Systemgrenzen hinaus gehen? Wie arbeiten denn die anderen Teams im Unternehmen? Ist das Unternehmen, für welches das Team arbeitet, der Mittelpunkt des Universums (oder zumindest im Wertstrom)? Muss „Wert“ zwangsläufig Geld sein oder tut das Team etwas Gutes für den Planeten? Diese Phase ist niemals flüssig, weil sie im Gegensatz zu den anderen Phasen keine Antworten, sondern nur Fragen liefert und vielleicht ist das auch gut so :).  Auch wenn viele Teams denken, dass sie schon „agil“ sind, haben sie noch einen weiten Weg vor sich. Genauer gesagt endet dieser Weg tatsächlich nie. Näherungsweise bedeutet „agil“ zu sein, zu akzeptieren und zu wertschätzen, dass man sich permanent weiterentwickelt. Die Antwort auf die Frage, welche Aufgabe der Scrum Master also hat, lautet: Er sollte eine Idee davon haben, wie sein Team diese Entwicklung meistern kann. Das Agile Fluency Model ist dabei eine Möglichkeit, welche diesen Weg strukturiert aufbereitet.  Die Reihenfolge der Phasen ist dabei insofern entscheidend, dass keine Phase wirklich flüssig beherrscht werden kann, wenn die vorherige nicht flüssig etabliert ist. Je nachdem wie viel Veränderung das Team verträgt, kann auch mit Teilen einer späteren Phase gestartet werden. In manchen Fällen ist es auch nicht sinnvoll, alle Phasen anzustreben. Manche Teams haben beispielsweise rein den Job, vorgegebene Anforderungen zu erfüllen und wollen auch keine Verantwortung für den Marktwert ihrer Tätigkeit übernehmen. Dann wären für diese Teams nur die ersten zwei Phasen relevant.  Es ist jedoch elementar, dass wir hier von Menschen reden, die oft auch schon seit Jahren Software entwickeln. Deren persönliche Befindlichkeiten und das tief menschliche Bedürfnis nach Stabilität stehen im Gegensatz zu der Idee, all diese Veränderungen parallel zu implementieren. Der Scrum Master sollte also wissen, welches Veränderungspotenzial in seinem Team steckt, wie er die Entwicklung vorantreibt, was die Skills kosten und wie diese einzusetzen sind.

Wie machen wir das im CodeCamp:N?

Als Scrum Master mache ich in meinen Teams nach den ersten paar Monaten eine Simulation über ca. 2,5 Jahre zu genau diesem Thema. Wir erarbeiten dabei gemeinsam eine Entwicklungsroadmap für das Team. Diese vergleichen wir mit den zu entwickelnden Features. So können wir einschätzen, wie wichtig uns diese Fähigkeitsentwicklung ist und was sie kostet. Dieses Vorgehen baut Unsicherheiten und innere Trotzreaktionen gegen Veränderungen ab. Wir können uns nur selbst ändern und maximal das Spielfeld, auf dem wir agieren. Andere können wir nicht verändern, das müssen sie schon selbst tun.

‍

‍

‍