Agile Projektvorgehensweisen wie Scrum scheinen der Zeitgeist zu sein. Selbst eingefleischte Wasserfall-Traditionalisten wie Versicherer wollen so schnell und flexibel werden wie Insurtechs. Wichtigste Erkenntnis: Teams arbeiten nicht von heute auf morgen agil. Die Umstellung erzeugt zunächst jede Menge Hilferufe. Hier die Innensicht aus einem konkreten Transformationsprogramm.

Gerade auf Mitarbeiterebene fehlt oft das Verständnis, was agil überhaupt für den Einzelnen bedeutet. Im Projekt hatten wir Mitarbeiter, die regelrecht „heiß“ auf die Scrum-Umstellung waren. Der Grund: Sie hatten schlicht keine Ahnung, was da gerade auf sie zukommt. Als die Umstellung im vollen Gange war, kam die böse Überraschung. Viele Scrum-Fans von einst formierten sich zu einer echten Widerstandsbewegung.

Rückblickend hätte man viel früher mit einer Roadshow und Informationsveranstaltungen auf alle Mitarbeiter zugehen und erklären müssen, was da demnächst passieren wird. Den Programmmanagern sollte klar sein: Die Mitarbeiter stehen im Zentrum der Umstellung und müssen daher frühzeitig eingebunden werden.

„Agil funktioniert hier niemals“

Nun kann man Informations- und Beruhigungstermine so oft durchführen, wie man möchte. Trotzdem werden die Informationen nicht überall fruchten. Früher oder später werden gestandene Wasserfall-Anhänger aussprechen, was andere still denken: „Agil – das funktioniert hier niemals“. Falsch wäre, eine Meinungsänderung zu erzwingen. Damit wird man die Widerständler methodisch und moralisch verlieren.

Wir haben im Projekt verschiedene Ansätze probiert. Bei einigen reichte es, die Methodik und die Vorteile in Ruhe an Beispielen zu erklären. Andere Kollegen stellten sich dagegen quer. Für diese Härtefälle sind individuelle Überzeugungsmethoden gefragt. Das Ziel sollte bei allen das gleiche sein: verstehen, warum Scrum aus der persönlichen Sicht nicht funktionieren kann, die betreffende Person selbst Lösungen vorschlagen lassen und diese verproben. Für die meisten der harten Nüsse hat sich gezeigt, dass über die Zeit die Anpassungsfähigkeit an das Team gestiegen und die Kritik am Vorgehensmodell abgenommen hat.

„Hilfe, unsere Tools passen nicht mehr“

Genauso schwierig gestaltet sich der Kampf gegen die Trennungsangst von liebgewonnenen Tools und Prozessen. Sie wurden über Jahre gepflegt. Durch Umstellung auf agil wird nun plötzlich die gesamte Methodik geändert. Den Prozessen geht es recht schnell an den Kragen, gewohnte Tools halten sich länger, auch wenn sie nicht mehr zum agilen Arbeiten passen. Für mich hat sich gezeigt, dass der einfachste Weg der sofortige Wechsel in die analoge Welt ist. Klassische Stellwände, die man mit Post-its vollhängen kann, ersetzen die besten und teuersten elektronischen Helfer. Im Agilen zählt das Resultat, weniger der Weg dorthin.

Hat man einmal die alten digitalen Tools hinter sich gelassen, kristallisiert sich schnell heraus, welche Anforderungen ein neues Tool erfüllen müssen. Die Teams liefern hierfür den Input, allein durch die Art, wie sie ihr Sprintboard bedienen und welche Funktionen wirklich notwendig sind. Wichtig: Ein Tool soll unterstützen, nicht aufhalten.

„Ich habe keinen Team Lead mehr“

Ungewohnt ist zudem der Umgang mit der Verantwortung. Am Anfang klingt Scrum für die meisten spannend, wenn man ihnen sagt, dass sich die Teams selbst organisieren dürfen und es keine Führungskraft mehr gibt. Die Ernüchterung folgt recht schnell. Plötzlich werden Info-E-Mails über den kommenden Urlaub – früher von allen lächelnd akzeptiert – zum Problem. Das Team muss sich die Frage stellen, ob sie zum Beispiel ihr Skill Management richtig betrieben haben.

Nicht alle kommen mit der langen Leine der agilen Welt klar. Wir haben die Erfahrung gemacht, dass man gerade zu Beginn der Transformation auf mehreren Ebenen sehr genau zuhören muss, um Probleme vorauszusehen. Es empfiehlt sich, den harten Schnitt zwischen blindem Gehorsam und vollkommener Autonomie durch Coaching und personelle Verantwortung abzufedern. Lieber findet man noch jemanden, „der das gerade mal entscheidet“, als dass man Mitarbeiter im Regen stehen lässt, weil man ihnen aufzwingt, sich unbedingt sofort selbst zu organisieren.

Weg mit den Störern

Nach den ersten Sprints empfiehlt sich eine Rückschau auf das Produkt. Das für mich spannendste Resultat war, dass die Diskussion immer wieder dahin führte, dass Dinge deshalb nicht funktionieren, weil die alten und absolut hervorragenden Prozesse nicht mehr erlaubt sind. Im Grund wurde allerdings nur versucht, Gründe zu finden, um wieder nach Wasserfall arbeiten zu dürfen.

Mit Unterstützung in der Diskussion wurde schließlich festgestellt, dass die Stimmung deshalb gekippt war, weil es viel zu viele Störer gibt, die nicht konstruktiv mitarbeiten. Für mich bleibt die Erkenntnis, dass der Erfolg der Umstellung an der Mentalität und der Motivation hängt. Künftige Teambesetzungen und Neueinstellungen sollten die Eignung für agiles Arbeiten berücksichtigen.

Erfahrung allein macht keinen Scrum Master

An der Rolle Scrum Master und seiner Person hängt viel. Seine Aufgabe ist, die gerade zusammengesetzte Gruppe von Mitarbeitern zu einem leistungsfähigen Team zu entwickeln. Erfahrung und Zertifizierungen reichen dafür allein nicht aus. Ja, sie zeigen, dass die Theorie verstanden und auch schon angewandt wurde. Viel wichtiger sind allerdings Herzblut und dass der Scrum Master die agile Mentalität jede Sekunde des Tages lebt. Gerade in der Zeit nach der Umstellung auf agil, schauen die Teams auf ihn und erwarten, dass er aktiv coacht.

Scrum Master neu einzustellen oder von außen zu verpflichten, ist nicht immer das beste Mittel. Ihnen fehlt der Blick darauf, wo man herkommt. Personen aus dem internen Kreis können fundierteres Feedback geben, was besser oder schlechter funktionieren wird. Das Team vermeidet so Verbesserungszyklen, die bereits zu Beginn zum Scheitern verurteilt sind.

Der Nachteil einer internen Besetzung ist, dass diesen Scrum Mastern Weitblick und Unabhängigkeit fehlen. Im schlimmsten Fall heißt das Wasserfallvorgehen dann Scrum. Idealerweise bilden Scrum Master, die sowohl aus der Organisation kommen als auch von außen geholt werden, die perfekten Sparringspartner.

Verteilte Teams – muss das sein?

Üblicherweise werden Srcum Teams aus Mitarbeitern mit unterschiedlichen fachlichen und technischen Skills zusammengesetzt. Diese Mitarbeiter sitzen allerdings selten im selben Raum. Sie trennen in der Regel Etagen, Gebäude, Städte oder wie in unserem Fall ganze Kontinente.

Versuchen kann man es trotzdem mal, und so setzten wir die Teams aus den perfekten Kandidaten zusammen, egal, wo diese ihren Arbeitsplatz haben. Schnell zeigte sich, dass dies genau dazu führt, was wir nicht wollten: kleine Wasserfälle von einer Sprint-Länge, in der die Analysten ein Design entwickeln, die Programmierer den Code schreiben und die Tester das Ergebnis abnehmen.

Das lag vor allem daran, dass ein gemeinsames Bearbeiten der Aufgaben aufgrund der räumlichen Distanz extrem aufwendig ist. Selbst, wenn man es hinbekommt, dass alle gemeinsam die User Stories abarbeiten, sind zumindest die Zeremonien sehr anstrengend, wenn man nicht konsequent auf Videokonferenzsysteme setzen kann. Rein am Telefon mit geteiltem Bildschirm ist die Aufmerksamkeitsspanne der Teilnehmer begrenzt.

Wir haben deshalb recht schnell die Teams neu strukturiert, so dass die Mitglieder jeweils gemeinsam am selben Ort und im selben Raum sitzen. Erfahrene Scrum-Profis können sicher auch verteilt arbeiten, bei der Einführung sowie auf dem Weg zum Top-Team ist das jedoch sehr hinderlich.

Für wen machen wir das Ganze eigentlich?

Sobald sich Teams nach einigen Sprints gefunden haben, wollen sie Lösungen nicht mehr vorgekaut bekommen, sondern ihre Expertise aktiv einbringen. Wichtig ist in dieser Phase, sie in die Kommunikation mit den Stakeholdern, d.h. den Auftraggebern, einzubinden. Oft wird missverstanden, dass ausschließlich der Product Owner und das Management mit den Stakeholdern sprechen. Das führt dazu, dass beispielsweise Softwarebausteine nicht in der Form implementiert werden, wie es die Experten, das Entwickler-Team, gerne hätten, sondern wie es Stakeholder und Product Owner vereinbart haben.

Dieser unnötige Informationsfilter hat Einfluss auf den gelieferten Mehrwert. Kann das Entwickler-Team keinen Einfluss auf die mögliche Umsetzung nehmen, werden Lösungen teurer als geplant. Der Nutzen einer Umstellung auf agil verpufft. Daher sollte das Entwickler-Team die Umsetzung mit den relevanten Stakeholdern direkt besprechen können, sowohl im Rahmen der Sprint-Demo als auch in Backlog Refinements.

Dojo – wir lernen aus dem Budosport

Strikte Rollen wie Entwickler, Tester und Architekten gibt es in einem Scrum Team nicht. In der Theorie ist das ideal, gerade zu Beginn einer Transformation wird das jedoch nicht gelebt. Teams neigen dazu, Entwicklern das Coding zu überlassen und den Analysten das Prozessdesign. Ob alles funktioniert, darf dann der Tester herausfinden.

Zur Skill-Entwicklung und um Verständnis für die die Tätigkeit der Kollegen zu entwickeln, eignen sich regelmäßige Dojos. Dojos sind die Trainingsstätten von Budosportarten wie Judo, Karate und Aikido. Eine Trainingsmethode ist Kata, bei der eine genau festgeschriebene Abfolge von Übungen trainiert wird.

In unserem Team adaptieren wir diese Trainingsmethode für das Ziel des gemeinsamen Lernens. Kleinere Themen, beispielsweise die Definition von Testfällen, die Bearbeitung von Tickets und das Beheben von Bugs, wird gemeinsam und interaktiv gelöst. Jedes Teammitglied muss in einer 120-Minuten-Einheit für eine Timebox von fünf Minuten aktiv am Rechner unter Anleitung der Kollegen arbeiten. Die Person erhält so die Möglichkeit, neue Themen zu bearbeiten. Im Anschluss wird die Tastatur an den nächsten Kollegen übergeben, und es geht nahtlos weiter.

Diese kurzen Einheiten empfinden wir für unser Team als Bereicherung. Wir stärken unsere Kommunikation und lösen gemeinsam unterschiedliche Probleme. Führt man diese Trainingseinheiten frühzeitig durch, löst sich die starre Spezialisierung innerhalb der Teams auf, und alle können unabhängig ihrer Steckenpferde an allen Tasks mitarbeiten. Diese Methode wird oft auch als Mob-Programming bezeichnet.

„Huch, wir haben weniger geliefert als erwartet“

Doch egal wie gut und schnell Unternehmen agiles Arbeiten einführen: Gehen sie es konsequent an, werden sie dennoch Zeit verlieren, bis die Teams sich gefunden haben. Als wir im Programm umstellten, waren Lieferversprechen für die nächsten zwölf Monate bereits gegeben und kommuniziert. Man kann sich vorstellen, dass die Überraschung des Managements groß war, als nach dem ersten Sprint keine einzige User Story geliefert fertig war.

Es hilft nicht, die Teams darauf hinzuweisen, versäumte Arbeiten im nächsten Sprint aufzuholen. Das demotiviert und führt nicht dazu, dass Teams ihr Sprint Goal mit ruhigem Gewissen festlegen. Plant man die Transformation von Beginn an so, dass das Lieferversprechen verschoben oder geändert wird, hat man frühzeitig die Stakeholder besänftigt und schafft ausreichend Raum für eine erfolgreiche Umstellung.

Zusammengefasst: Der Wasserfall hält sich hartnäckig

Tradierten Branchen wie Versicherern fällt der Umstieg auf ein agiles Projektvorgehen schwer. Das über Jahre erprobte und verfeinerte Vorgehen im Wasserfall ist fest in den Köpfen verankert und Teil der Unternehmenskultur.

Die Entscheidung für ein agiles Arbeiten bedeutet einen radikalen Aufbruch von Hierarchien und klassischen Rollenmodellen. Insbesondere ändern sich die Verantwortlichkeiten in einem Projekt. Das erzeugt Angst, da wichtige Leitplanken plötzlich fehlen und klassische Projektleiter nicht mehr benötigt werden.

Wichtig ist, diesen Change Prozess durch Coaching und Training zu unterstützen, um diesen Wandel hinzubekommen. Genauso wichtig ist es, die Erwartungen des Managements zu dämpfen. Denn das Ziel der Agilität – sprich mehr Tempo und Flexibilität – wird sich erst nach einer ganzen Reihe an Sprints einstellen. Dennoch ist der Wandel wichtig, und am Ende werden die Projektteams Scrum und seine agilen Varianten genauso verinnerlichen wie einst die Wasserfallmethodik.

Danke an Jasmin Schirmer, die an diesem Blogpost einen maßgebenden Anteil hat.