Bei unserem Meetup „Wie kann ich mein Team agilisieren?“ am 12.03.2021 gab es aus dem Publikum viele interessante Fragen, die wir euch hier nochmal ausführlich beantworten möchten.
Q1: Welche Rahmenbedingungen müssen eurer Meinung nach stimmen, damit man überhaupt mit der „Agilisierung“ starten kann?
A1: Das Team, welches agile Methoden einführen möchte, sollte das wollen und auch (gute) Gründe dafür angeben können, warum sie das wollen. Wir haben schlechte Erfahrungen mit „von oben verordneter“ Agilisierung von Teams gemacht. Wille und Anlass sind dann aber auch schon genug. Alles Weitere ergibt sich dann auf dem Weg in die Agilität.
Q2: Was waren die größten Herausforderungen bei der Einführung der agilen Arbeitsweise?
A2: Die Herausforderungen sind immer sehr unterschiedlich. Zwei Beispiele:
- Ein Softwareentwicklungsteam, das ich begleitet habe, hatte schon vor meiner Involvierung angefangen, mit Scrum zu arbeiten und war über die Zeit immer größer geworden. Hier war die größte Herausforderung, Strukturen bzw. Methoden zu entwickeln, die zu der großen Teamzusammenstellung (ca. 15 Personen) passte. Standard-Skalierungsverfahren (LeSS, Nexus etc.) eigneten sich hier nicht, d. h. wir mussten uns genauer anschauen, an welchen Stellen die Teamgröße eigentlich Probleme bereitete (z. B. im Sprint Planning) und dann gezielte Lösungen dafür erarbeiten.
- Das zweite Team kam nicht aus der IT (Geolog:innen und Geophysiker:innen). Hier war es eine große Herausforderung, die in der Software- bzw. Produktentwicklung naheliegenden Ideen, wie Inkrement oder „Potentially Shippable Product“, auf die Domäne des Teams (Exploration) zu mappen.
Q3: Warum habt ihr die Teams „agilisiert“? Also wo gab es Schmerzen?
A3: Mit Bezug auf beide Beispiele aus Frage 2: Bei dem Softwareentwicklungsteam war es zum einen die Größe (s. o.)und zum anderen auch das Gefühl, dass bestimmt noch einiges besser/effektiver laufen könnte als der Scrum-Ansatz, den sie bisher für sich (“autodidaktisch“ nach eigener Aussage des Teams) festgelegt hatten. Das durchgeführte initiale Training war hier sehr hilfreich, da dort nicht nur ein einheitliches Verständnis der Kernkonzepte und -begriffe hergestellt wurde, sondern gleich schon etliche Ideen zur Verbesserung des aktuellen Vorgehens entstanden („Ach so ist das eigentlich gedacht?! Das sollten wir auch mal bei uns probieren“).
Bei dem Explorationsteam war der Antrieb tatsächlich Neugier. Es war ein komplett neues Team für ein neues Projekt und da in dem Unternehmen andere Teams und Projekte schon positive Erfahrungen mit Scrum gemacht hatten, wollte es dieses Team auch mal ausprobieren.
Q4: Welche Rolle spielt Freiwilligkeit? Prüft ihr vorher, ob das Team zu agilem Arbeiten bereit ist, um zu verhindern, dass ein System einfach „übergestülpt“ wird?
A4: Im Prinzip schon. Unser Auftraggeber ist in der Regel nicht das Team selbst, sondern ein:e Teamleiter:in oder jemand anders mit „Budgetverantwortung“ im Unternehmen. Wenn wir dann bei der Arbeit mit dem Team feststellen, dass es gar nicht agil arbeiten will, thematisieren wir das auf jeden Fall (im Team und mit dem Auftraggeber). Ich kann mich tatsächlich aber nur an einen Fall erinnern, bei dem so etwas passiert ist und wir die Beratung dann auch abgebrochen haben. Es ist also – zumindest in unserem Umfeld – ziemlich selten.
Q5: Habt Ihr Tipps fürs Agilisieren von Teams, die nicht an einem Projekt arbeiten, sondern auch unterschiedliche Linientätigkeiten haben?
A5: Da das ziemlich häufig vorkommt, gibt es tatsächlich einen Tipp, der sich schon bei vielen Teams/Unternehmen bewährt hat:
Nehmen wir an, ein Teammitglied hat zu 30 % noch andere Aufgaben (Linienaufgaben oder ein zweites Projekt). Das Team sollte diese:n Kolleg:in dann behandeln wie jemanden, der eine Teilzeitstelle mit 70 % hat. Wie bei normalen Teilzeitstellen sollte sich der/die Kolleg:in gemeinsam mit dem Team überlegen, wie man die Arbeitszeit am besten gestalten kann (jeden Tag um 15:00 Uhr „Feierabend“, einen Tag in der Woche „frei“ etc.). In den meisten Fällen findet sich so eine Lösung, die allen passt.
Q6: Ohne kompletten detaillierten Projektplan bekomme ich von der übergeordneten Organisation gar nicht erst das Budget. Was nun?
A6: In so einem Fall weiß die übergeordnete Organisation entweder nicht, was agiles Arbeiten bedeutet oder sie lehnt es ab. In beiden Fällen ist der erste Schritt „Aufklärung“ – z. B. ein Training oder ein Workshop mit dem Projekt Management Office, Führungskräften oder der Geschäftsleitung als Einleitung in agiles Arbeiten. Wird das Thema weiterhin skeptisch gesehen, kann man versuchen, eine Ausnahmeregelung zu finden und es als „Pilotprojekt“ laufen zu lassen. So wird das wahrgenommene Risiko gedeckelt und man kann nach dem erfolgten Pilotprojekt auf Basis der gemachten Erfahrungen gemeinsam entscheiden, ob bzw. wie man mit der Agilisierung weitermachen möchte.
Q7: Wie geht ihr mit Menschen um, denen die Transparenz unangenehm ist oder die die Vorgehensweise blockieren?
A7: Wenn jemandem Transparenz (z. B. gegenüber den Teamkolleg:innen) unangenehm ist, ist das oft ein Anzeichen für mangelndes Vertrauen. Man hat dann Angst, dass die Kolleg:innen mit der Transparenz nicht verantwortungsvoll umgehen. Mangelndes Vertrauen im Team ist etwas, das man aktiv adressieren sollte, um effektiver zu arbeiten – unabhängig davon, ob man agil arbeitet oder nicht. An dieser Stelle könnte man als erstes ansetzen, wenn Bedenken in Bezug auf die Transparenz aufkommen.
Q8: Wie stark arbeiten die Teams (intern) zusammen? Sind StandUps noch notwendig? Hat sich durch die Pandemie etwas daran geändert?
A8: Unserer Erfahrung im letzten Jahr war, dass gerade das Daily StandUp im Lockdown noch wichtiger geworden ist. Neben der (bei Scrum) typischen Fragestellung „Glauben wir noch an unseren Plan für den aktuellen Sprint“ kam in den vergangenen Monaten bei vielen Teams noch das Thema „Socializing“ auf die Agenda, was ja durch die weggefallenen Kaffeeküchen-Begegnungen oder gemeinsamen Grillabende deutlich zu kurz kommt. Das hat sich je nach Team unterschiedlich ausgeprägt: manche Teams haben einen expliziten „Smalltalk“-Block in ihrem Daily etabliert. Andere haben sich einfach etwas mehr Zeit genommen und – bewusst ineffizient – ausführlicher erzählt, an was sie am Vortag gearbeitet haben.
Q9: Was passiert mit den Projektmanager:innen, die es vorher gab? Was passiert generell mit den Rollen, die es jetzt „nicht mehr braucht“?
A9: Nehmen wir als konkretes Beispiel den Wechsel eines Teams von PMI Projektmanagement zu Scrum. In Scrum gibt es die Rolle des Projektmanagers nicht. Die Aufgaben, die ein:e Projektmanager:in innehat, fallen dadurch jedoch nicht weg. Sie werden stattdessen auf die Scrum-Rollen verteilt (Stakeholder Management: Product Owner, Work Breakdown: Entwickler:in, Hindernisse beseitigen: Scrum Master etc.).
Für jemanden, der in der Vergangenheit die Rolle der Projektmanager:in eingenommen hat, stellt sich jetzt die Frage, welche der drei Rollen am besten passt. Das muss individuell entschieden werden, da es viel vom vorhandenen Wissen und den vorhanden Fähigkeiten der Person anhängt.
In der Praxis habe ich erlebt, dass alle drei Möglichkeiten funktionieren können: Ein Projektmanager der in die Rolle des Product Owners gewechselt ist, da er genügend Domänenwissen über das zu entwickelnde Produkt hatte; ein Projektmanager, dem immer schon der Coaching-Aspekt seiner Rolle lag und der deshalb über die Zeit in die Scrum Master Rolle hineingewachsen ist und ein Projektmanager, der sich auf seinen Informatikhintergrund besann und (sehr gerne) wieder die Entwicklerrolle einnahm.
Q10: Was sind eure Empfehlungen, gerade bei kleinen Teams mit weniger als 4 Entwickler:innen? Welche Artefakte sind hier sinnvoll und welche sind overhead?
A10: Kurze Antwort: Herausfinden! Auch bei kleinen Teams kann man mit einem „vollständigen“ Scrum beginnen (vorausgesetzt Scrum ist die richtige Methode für die Domäne). Wenn das Team dann zwei bis drei Sprints damit gearbeitet und Erfahrungen gesammelt hat, bekommt man sehr leicht mit, welche Aspekte bei der kleinen Teamgröße „overhead“ sind und kann diese dann durch leichtgewichtigere Alternativen ersetzen.
Mit diesem Vorgehen stellt man sicher, dass man nicht Dinge über Bord wirft, die vielleicht erstmal zu schwergewichtig klingen, sich in der Praxis dann aber doch als ganz nützlich herausstellen.
Q11: Wie geht ihr mit – nach Scrum – zu großen Teams um, ohne gleich die Nexuskeule zu schwingen?
A11: Bevor wir einem Kunden raten, eines der Scrum-Skalierungsframeworks einzuführen (LeSS, Nexus, SAFe), versuchen wir immer erst zu klären, ob es nicht auch ganz ohne Skalierungsframework funktioniert. Denn egal welches Framework man verwendet: die Skalierung ist nie linear. Der Output von fünf Teams, die gemeinsam arbeiten, wird geringer sein als der Output von fünf Teams, die unabhängig voneinander arbeiten können, – einfach auf Grund des Kommunikations-Overheads. Es sollte also zuerst versucht werden, das zu entwickelnde Produkt so zu schneiden, dass daraus mehrere Produkte werden, die unabhängig voneinander entwickelt werden können. Erst wenn das nicht möglich ist (und man es auch tatsächlich ernsthaft versucht hat), sollte man zu einem der Skalierungsframeworks greifen.
Q12: Ist aus eurer Sicht der Scrum Master eine Person oder eher eine Aufgabe, die jeder im Team übernehmen kann?
A12: Der Scrum Master ist schon eine feste Rolle im Scrum Team. Bei kleineren Teams kann es sein, dass man als Scrum Master auch noch Zeit hat, parallel die Rolle eine:r Entwickler:in einzunehmen. Dann sollte man aber auch explizit zwei parallele Rollen haben und damit entsprechend umgehen (siehe auch Frage 5). Typischerweise sind die Skills, die man benötigt, um guter Scrum Master zu sein, auch andere als die, um ein:e gute:r Entwickler:in zu sein. D. h. erst wenn jede:r im Entwicklungsteam diese Skills hat, kann auch jede:r diese Rolle übernehmen. Das ist aber ziemlich selten der Fall.
Q13: Sollte ein Scrum Master das Ziel verfolgen, irgendwann das Team verlassen zu können?
A13: Das kommt ein bisschen darauf an, wie man genau die Rolle des Scrum Master für das Team (oder das Unternehmen) definiert. Wenn man die Hauptaufgabe darin sieht, das Team bei der Selbstorganisation zu unterstützen, kann es ein hehres Ziel sein, sich selbst irgendwann überflüssig zu machen. Wobei selbst hier die Frage ist, ob die Perspektive von außen, die ein Scrum Master dem Team liefern kann, überhaupt durch eine reine Innenperspektive zu ersetzen ist.
In den meisten Fällen kommen für den Scrum Master aber ja neben der Förderung der Selbstorganisation noch weitere Aufgaben hinzu: Beseitigung von Hindernissen, Ausbildung/Training von Personen außerhalb des Scrum Teams, Werbung für die agile Arbeitsweise im Unternehmen etc. Das sind typischerweise Dinge, die das Entwicklungsteam gar nicht übernehmen möchte. 😉
Q14: Nutzt ihr für Inspect & Adapt ein festes Format, z. B. ein Assessment mit festen Metriken?
A14: Für das alltägliche Inspect & Adapt in den Retrospektiven (und den anderen Scrum Meetings) nicht. Das muss immer auf das jeweilige Team, die Domäne und die Situation (z. B. den aktuellen Produktlebenszyklus) angepasst sein.
Wir haben mal einen sogenannten „Agile Audit“ entwickelt, der den Grad der Agilität eines Teams oder Bereichs anhand von Kennzahlen misst und dann entsprechende Verbesserungspotentiale aufzeigt. Welche Kennzahlen das sind und wie diese gemessen werden, ist hier dann standardisiert.
„Q“15: Naja eigentlich kommen die agilen Methoden nicht aus der Software-Entwicklung …
A15: Ohne gleich einen Historiker-Streit vom Zaun brechen zu wollen: Das erste Scrum Paper wurde 1995 auf der „Object-Oriented Programming, Systems, Languages, and Applications“ Konferenz (OOPSLA) vorgestellt und beschreibt Scrum als neue Methode zur Systementwicklung. Das „agile Manifest“, welches den Begriff “Agile“ für diese Art des Arbeitens 2001 eingeführt hat, trägt den Titel „Manifesto for Agile Software Development“. 🙂
