Hybridisierung klassisch vs. agil – Handlungsoptionen identifizieren

Agilität auf dem Prüfstand: Wenn agile Gehversuche scheitern
Keine Kommentare

Jahrelang bestimmte klassisches Projektmanagement den Alltag und das Denken in Unternehmen. Ganz plötzlich und fast wie von allein sollen agile Ansätze wie Scrum oder Kanban gleich einem Allheilmittel alles anders und am besten sofort erfolgreicher machen. Allerdings widerspricht das dem Grundprinzip von Agilität. Sie lebt von Inspect and Adapt und dem kontinuierlichen, iterativen Anpassen, ohne dabei das Bestehende aus den Augen zu verlieren. Es geht dabei nicht um einen faulen Kompromiss. Jedoch gilt es, auf dem Weg hin zu agilem Projektmanagement Hybridität zuzulassen, damit der für Ihre Firma passende Agilitätsgrad entwickelt werden kann, ohne sich dabei selber zu überholen.

In zahlreichen Workshops und Kundengesprächen oder grundsätzlichen Diskussionen zur Agilität kommt es oft zu folgenden Aussagen:

  • Bezüglich der Organisation: „Von komplett agil mit allen Meetings, Artefakten etc. bis hin zu durchgetaktet klassischen Unternehmensstrukturen mit Lenkungskreisen, Sitzungen etc. – alles Chaos!“
  • Bezüglich der Prozesse: „Wir haben wirklich schon viele Ansätze ausprobiert, aber wenn die Kollegen nicht mitziehen wollen oder ihr Handwerk nicht beherrschen, dann bleibt alles Theorie!“
  • Bezüglich der Methoden: „Ich habe über fünfundzwanzig Jahre Erfahrung im Projektmanagement und entsprechend viele Methoden kommen und gehen sehen – nichts funktioniert richtig!“

Solche Klagen finden sich in allen Branchen, nicht zuletzt sogar in der agilen Softwareentwicklung, der Geburtsstätte des Scrum-Gedankens. Dies erscheint umso erstaunlicher, da doch alle Regeln genau für die Akteure des IT-Umfelds mit der bei Entwicklungsprojekten charakteristischen Komplexität entworfen wurden.

Dazu wird an dieser Stelle das abstrahierte Beispiel eines fiktiven Unternehmens mit ca. hundert Mitarbeitern skizziert. Es entwickelt seit zwanzig Jahren Software und hat nach einer zunächst klassisch-hierarchischen Ausrichtung mit Geschäftsführern, Stabsstellen, Bereichsleitern und Teamleitern von Entwicklungsteams eine Reorganisation hin zu Scrum umgesetzt. Es gibt in etwa doppelt so viele Scrum-Teams wie Scrum Master. Ein Scrum Master kümmert sich folglich um zwei Scrum-Teams oder mehr. Dabei gibt es jedoch teilweise zwei oder mehrere Product Owner (PO) je Scrum-Team. Das bedeutet, dass diese weiteren Product Owner Experten für jeweils eines oder mehrere Produkte sind und den hauptverantwortlichen PO unterstützen.

Diese Strukturen sind über mehrere Jahre gewachsen und haben sich stark verfestigt, teils auch über die gesamte Zeit mit den gleichen Mitarbeitern. Warum performen die Teams jedoch nicht ausreichend und halten ihre Commitments nicht ein (= schwankende Velocity)? In dem oben beschriebenen, organisatorischen Gebilde gibt es diverse Probleme. Beispielsweise bearbeitet ein Team viele verschiedene Themen, Produkte oder Komponenten, und ein Scrum Master kann nicht durchgehend in beiden Teams anwesend sein. Daneben kann es vorkommen, dass Impediments nicht rechtzeitig oder gar nicht erkannt werden. Auch unterschiedliche Teamgrößen von unter fünf bis über zehn Personen sowie fehlende oder unzureichende Vertretungsregelungen können sich negativ auswirken. Ein weiteres Problem liegt darin, dass Teammitglieder Anforderungen der Kunden zurückweisen oder Meetings, ganz gleich ob Daily Stand-ups, Plannings oder Retrospektiven, oft ausfallen.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Wenn der agile Arbeitsprozess insofern nicht optimal funktioniert, ist dies insbesondere aus persönlicher Sicht der betroffenen Mitarbeiter Nährboden für zunehmende Frustrationen. Das Nichtfunktionieren ist dabei keinesfalls gleichbedeutend mit mangelndem Engagement. Ganz im Gegenteil versuchen Mitarbeiter, die sich stark mit ihrer Firma, ihrem Team und/oder ihrem Produkt identifizieren, zunächst die Defizite im Arbeitsprozess durch Mehrengagement auszugleichen. Denn häufig weiß jeder zumindest theoretisch, wie es laut Scrum Guide sein müsste und worin die Vorteile dieses agilen Ansatzes bestehen. Das findet sich allerdings oft in der eigenen Arbeitswelt und hier im fiktiven Firmenbeispiel nicht wieder, wodurch sich die Situation noch weiter verschlimmert. Geht niemand die Probleme in den Arbeitsabläufen an, führt das Mehrengagement etwa in Form von unzähligen Überstunden oder zähen Anforderungsklärungen direkt zu Spannungen im Team sowie höherem Krankenstand und kann sogar Kündigungen nach sich ziehen. Insgesamt hat sich die beschriebene Situation im Laufe der Zeit aufgrund der oben genannten Probleme festgefahren und wird sich in Kombination mit den aufkeimenden, persönlichen Problemen der Mitarbeiter weiter zuspitzen.

Wie lässt sich mit dieser Situation angemessen umgehen, sodass produktiveres Arbeiten wieder möglich ist? In den meisten Fällen wird gerade das Offensichtliche nicht mehr wahrgenommen. Denn die angesprochenen Punkte setzen mehr oder weniger entweder die Werte, Prinzipien oder Regeln von Scrum außer Kraft. Kurz gesagt ist man abgekommen von dem, was Scrum eigentlich auszeichnet: die intensive gemeinsame Kommunikation zur Bearbeitung von Aufgaben fehlt ebenso wie das Commitment zur verbindlichen Lieferung des Produktinkrements. Es gibt verschiedene Ansätze mit entsprechenden fachlichen Blickwinkeln zur Analyse und der darauf aufbauenden Verbesserung solcher Situationen.

Sogenannte Reifegradmodelle untersuchen Scrum, indem sie den Grad an Agilität messen, Scrum in Unternehmen aus der Sicht der Geschäftsführung bewerten oder auch die Teamperformance beurteilen, die gesteigert werden soll, z. B.: Messung von Agilität [1], agile Führung [2], Erfolgsmessung agil arbeitender Teams. Um die obige Situation umfassend zu untersuchen, bedarf es der Reflektion entlang der Scrum-Grundlagen (v. a. Rollen, Meetings, Artefakte etc.). Es muss systematisch hinterfragt werden, inwieweit agiles Vorgehen, Prinzipien und Werte tatsächlich praktisch zur Anwendung kommen. Übergeordnetes Ziel dabei ist es, zu reflektieren, was Scrum wirklich auszeichnet: nämlich insbesondere Commitment, Fokus, Offenheit, Respekt und Mut, um einen zur jeweiligen Unternehmenssituation passenden Agilitätsgrad zu ermitteln.

Agile Readiness Check: Ansatz zur Ermittlung agiler Handlungsbedarfe

Der Agile Readiness Check kann bei der Situationsaufnahme herangezogen werden, um langfristige Handlungsfelder (z. B. Teamentwicklung) zu ermitteln und kurzfristige Quickwins (z. B. Regelanwendung in Meetings) zu identifizieren (Abb. 1).

Abb. 1: Aufbau des Agile Readiness Checks

Abb. 1: Aufbau des Agile Readiness Checks

Der Agile Readiness Check schlägt mithilfe seiner Prüfsystematik eine Verständnisbrücke zwischen klassischem Organisationsdenken und agilem Kontext. Da heutzutage die klassische Betrachtungsweise noch dominiert, muss erst einmal aus dieser Perspektive der Status quo im Unternehmen erfasst werden. Aus dieser Sicht findet dann eine Übersetzung in die agile Welt statt. Das folgende Beispiel soll der Verdeutlichung dienen. Am Anfang steht die Frage an den Bereichsleiter/Seniorprojektleiter: „Wie werden die Anforderungen an das Arbeitsergebnis formuliert? (Medium/Format)“. Die Antwortmöglichkeiten hierzu: ausführliches Fachkonzept (null Prozent), nicht formalisierte Anforderungsaufnahme und Dokumentation (fünfzig Prozent), User Stories (hundert Prozent). Anschließend gilt es, den Handlungsbedarf zur Steigerung von Agilität auf Basis der gegebenen Antworten zu bewerten. Hier gibt es z. B. „null Prozent“, dann besteht akuter Handlungsbedarf. Schließlich werden Maßnahmen zur Erreichung eines passenden Agilitätsgrads (Ableitung Agile Agenda) nach Antwort auf die Fragen des Gesamtfragenkatalogs aufgestellt.

Als abgeleitete Einzelmaßnahme kann die Durchführung regelmäßiger Anforderungsworkshops des klassischen Projektteams mit Kunden zur wiederholten Überprüfung der im Fachkonzept formulierten Anforderungen bereits sinnvoll sein. Das Fachkonzept bleibt zunächst erhalten. In den Workshops können die Teilnehmer dann sukzessive und kapitelweise die relevanten Anforderungen in den Fokus nehmen und nochmals das gemeinsame Verständnis dazu im Diskurs schärfen. Auf diese Weise wird vermieden, dass aufgrund des Time Gaps zwischen Fachkonzepterstellung und Anforderungsumsetzung Verständnisdifferenzen auftreten. Damit ist noch kein Scrum oder dergleichen eingeführt. Auf einfache Weise kommt hier Transparenz als zentrale agile Arbeitsweise zum Tragen, um klassische Prozesse und Strukturen in Teilen agiler zu gestalten.

Zum Entwicklungshintergrund des Agile Readiness Checks:

Ansatzpunkte aus der agilen Theorie sind verschiedenen Verständnisclustern (z. B. Rollen, Prinzipien, Werten) zugeordnet. Folgende Aussage, analog zu obigem Beispiel, stammt sinngemäß aus dem Scrum Guide: „Der Product Owner kümmert sich um klar formulierte Product-Backlog-Einträge (User Storys)“. Aus Scrum-Sicht ist damit eine der zentralen Rollen mit einer ihrer Aufgaben angesprochen worden. Im klassischen Managementdenken ist eine Rolle dem Verständniscluster Organisation zuzuordnen. Der Agile Readiness Check setzt bei diesen Dimensionen des klassischen Managements an, die in einem allgemeinen Verständnis eine Klammer um alles legen, was funktionierende Unternehmen für die Überprüfung ihres eigenen Handelns in den Blick nehmen sollten: neben dem Beispiel Organisation sind dies Prozesse und Methoden.

Agile Agenda: Agilität individuell gestalten

Ist der Agile Readiness Check durchgeführt, liegt je nach betrachtetem Ausschnitt (d. h. Team, Abteilung, Firma) zunächst eine Übersicht mit den verschiedenen Ansatzmöglichkeiten auf organisationaler, prozessualer und methodischer Ebene vor (z. B. oben angeführtes Beispiel bzgl. Formulierung/Umgang mit Anforderungen an das Arbeitsergebnis). Es gilt nun, passend zu den identifizierten Handlungsbedarfen das richtige Setting an Antworten in Form von agilitätssteigernden bzw. -mindernden Maßnahmen abzuleiten. Bei der Auslotung der agilen Gestaltungsmaßnahmen lässt sich als Denkmuster das Agile Manifest heranziehen. Handlungsbedarfsabhängig lassen sich vom klassischem Projektmanagement (rechts) bis hin zum agilen Arbeiten (nach Scrum) die Gestaltungsoptionen ableiten (Abb. 2).

Abb. 2: Werte des Agilen Manifests und Gestaltungsoptionen in Anlehnung an [5]

Abb. 2: Werte des Agilen Manifests und Gestaltungsoptionen

Bei Durchführung des Agile Readiness Checks würde man die oben genannten Probleme aus dem abstrahierten Beispiel einer fiktiven Softwareentwicklungsfirma über die Interviewfragen identifizieren und im Hinblick auf Handlungsbedarf zur Agilitätsoptimierung weiter betrachten. Das oben beschriebene organisatorische Problem der fiktiven Firma, dass viele verschiedene Themen, Produkte und Komponenten durch ein Team bearbeitet werden, würde bei folgender Frage in den Fokus geraten: „Wie empfinden Sie den Umgang mit den zu erfüllenden Anforderungen in Projekten?“ Entsprechend dem agilen Prinzip „Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell“ geht es darum, Aufgaben zu priorisieren und dadurch fokussiert zu agieren.

Im Rahmen des Agile Readiness Checks würde das wahrheitsgemäße Eingeständnis des Problems zu folgender Antwort führen: „Wir machen alles möglichst sofort und gleichzeitig.“ Das ist im agilen Arbeiten nicht vorgesehen bzw. ist als nicht agil zu bewerten und offenbart Handlungsbedarf zur Agilitätsanpassung. Ein erster Schritt wäre es in diesem Fall, die Themen, Produkte oder Komponenten des Teams zu hinterfragen, gegebenenfalls zu clustern oder auch, wenn möglich, komplett aus der Verantwortung des Teams herauszunehmen, um sich konzentrieren zu können und wieder produktive Arbeitsergebnisse zu liefern.

Das oben aufgeführte prozessuale Problem der unterschiedlichen Teamgrößen von unter fünf bis über zehn Personen würde bei der Frage „Aus welchen Kompetenzen sind Ihre (Entwickler-)Teams zusammengesetzt?“ zu Tage gefördert. Das Entwicklerteam ist eine weitere zentrale Rolle nach Scrum: „Dev-Team bestehend aus mindestens drei und maximal neun Entwicklern und Testern. Dev-Team erstellt gemeinsam, interdisziplinär das sog. Produktinkrement.“

Lesen Sie auch: Agile Transformation: Starre Strukturen aufbrechen – mit Scrum!

Bezogen auf die Kompetenzen der Teammitglieder ist eine heterogene Zusammensetzung mit verschiedenen Know-how-Trägern entscheidend, die ihren Wissensbeitrag leisten. Daher sollte ein Team nicht zu klein sein. Ab etwa zehn Personen wird allerdings unter anderem die Koordination für den Scrum Master oder die Selbstorganisation untereinander schwer beherrschbar. Angenommen, das zu große Team besteht ausschließlich aus Entwicklern mit wenigen Kompetenzunterschieden, bleibt vereinfacht die Frage, wie die Qualitätssicherung des Codes stattfindet? Die Integration eines Testers, ob dauerhaft oder bis dahin zunächst als temporäre Ausleihe innerhalb der Firma, sollte geprüft werden.

Das beschriebene methodische Problem, dass Meetings oft ausfallen, läuft der besonderen Relevanz von enger Kommunikation im agilen Zusammenarbeiten zuwider. Bei der Agile-Readiness-Check-Frage „In welcher Häufigkeit treffen sich Ihre Teams zur Abstimmung über anstehende Projektaufgaben/Stand des Projekts?“ würde man dies identifizieren. Am Beispiel Daily Stand-up ist die sinnvolle Meetingfrequenz bereits in der Bezeichnung als täglich angelegt. Es mag auch Meetings geben, bei denen das anders handhabbar ist, wenn es sich begründen lässt. Retrospektiven dienen am Ende eines Sprints der ständigen, iterativen Verbesserung der Arbeitseffizienz, bringen aber selbst beim engagiertesten Scrum-Team langfristig wiederholt eher ähnliche Themen hervor, die sich beispielsweise auf die nicht erreichte Velocity, einen immer wieder nörgelnden Kollegen oder bestimmten Kunden o. ä. beziehen. Die Analyse darf nicht rein in der Retrospektive stattfinden, sondern muss eigentlich ständig mit dem Scrum Master als Prozessverantwortlichem betrachtet werden. Er hat die Aufgabe, auf Commitments hinzuwirken und auch im Konfliktfall zu vermitteln – das ist Tagesgeschäft. Daher könnte in Bezug auf Retrospektiven auch jeder zweite oder dritte Sprint als Meetingfrequenz ausreichen, um dann gegebenenfalls neue Themen zu identifizieren.

Fazit und Ausblick

Gegenüber der Kernfrage „Agilität steigern – aber wie?“ muss eingeräumt werden, dass man bei allem Streben nach einem passenden, gegebenenfalls höheren Agilitätsgrad niemals das Entwicklungstempo außer Acht lassen darf. Agile Veränderungen setzen umfassend an allen relevanten Ebenen wie Organisation, Prozesse und Methoden an. Das hat einen grundlegenden Eingriff in die Unternehmenssituation zur Konsequenz. Abhängig vom ermittelten firmenindividuellen Handlungsbedarf sollte also stets eine vorsichtige, langfristige Gestaltung und Einführung bzw. Agilitätssteigerung mit Augenmaß erfolgen. Das kann von mehreren Monaten bis hin zu Jahren dauern und ist zum Erhalt von stabilen Prozessen und für eine weiterhin leistungsstarke und produktive Organisation unerlässlich.

Das Setting an Maßnahmen ist hochgradig individuell und muss mit Bedacht, wohldosiert und ebenso iterativ wie der agile Entwicklungsprozess selbst immer wieder hinterfragt und, wenn erforderlich, angepasst werden. Nicht jedes Unternehmen hat den gleichen Handlungsbedarf bzw. Reifegrad, um agil(er) zu agieren bzw. sich agil(er) aufzustellen. Nach dem Lesen dieses Artikels sollte es idealerweise erst richtig losgehen mit der Frage: Und was bedeutet das für mich und mein Unternehmen? Warum und in welchem Maß wollen wir uns eigentlich agil aufstellen? Oder setzen wir vielleicht einfach auf agil, um agil zu sein?

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -