Agil und das Missverständnis mit der Führung

Als Podcast:

Was ist agil?

Agile Software-Entwicklung ist inzwischen das Standard-Entwicklungsvorgehen in den Projekten geworden und damit in aller Munde. Da „agile Softwareentwicklung“ eher eine Sammlung abstrakter Konzepte ist, statt eines klar definierten Prozesses, ist es schwierig agil genau zu definieren. Statt dies zu versuchen, will ich lieber die Konzepte besprechen, die in das Feld der Agilität fallen.


Hypothese, Test, Feedback, Repeat

In der agilen Software-Entwicklung wird versucht die Richtung eines Entwicklungsprozesses schnell änderbar zu machen. Das ist das oberste Ziel. Das ist so, weil gerade in der Software-Entwicklung zwischen Auftraggeber und Auftragnehmer aneinander vorbeigeredet wird. Das Maß an Abstraktion und Unbekanntem ist zu hoch. Mit Agilität ist gemeint, dass sich durch die Entwicklung von einem Software-Inkrement (also eines kleinen Teils der Software), schnell etwas Testbares ergibt. Diese neu entstandene Version kann dann den Kunden (und deren Respräsentanten) vorgeführt werden. Diese haben dann schnell die Möglichkeit Feedback zu geben, sodass sich basierend auf diesem Feedback die Richtung ändern kann.

Die agile Entwicklung folgt damit einem Ablauf, welcher sich immer häufiger in modernen Unternehmen finden lässt. Es wird eine Hypothese erstellt und diese getestet und damit Feedback eingeholt. Dieses Feedback soll dazu dienen die Hypothese zu validieren, oder zu negieren. In jedem Fall werden Details angepasst und neue Hypothesen aufgestellt, sodass sich dieser Prozess wiederholen kann. Früher war das anders – es wurde sehr lange eine Software entworfen und viel zu oft am Ende festgestellt, dass das Produkt am Markt nicht funktioniert.


Braucht es Führung in agilen Projekten?

In jedem selbstorganisiertem Team kommt es darauf an, wer wofür genau Verantwortung übernimmt. Nur wenn der Einzelne Verantwortung für eine Aufgabe übernimmt, fühlt er sich so als könnte (und müsste) er etwas tun. Wenn Arbeit liegen bleibt, dann liegt das in den allermeisten Fällen daran, dass sich niemand dafür verantwortlich fühlt – und nicht etwa, dass das Team inkompetent oder unmotiviert wäre. Das kann an sehr unterschiedlichen Dingen liegen.


Kommunikationsprobleme

Es kann sein, dass jeder das Gefühl oder die Erwartung hat, jemand anderes würde die Verantwortung für eine bestimmte Aufgabe übernehmen – denken das alle, so ist niemand verantwortlich. Es handelt sich hierbei um ein Kommunikationsproblem innerhalb des Teams. Scrum bietet verschiedene Möglichkeiten in Dailies und der Retrospektive solche Unklarheiten aufzuklären. Es sollte bei jedem Task und jedem Action Item klar sein, wer die Verantwortung übernimmt.


Micro-Management

Ein weiterer Aspekt welcher zu fehlender Übernahme von Verantwortung führt ist, dass das Projekt keinen Raum für die Übernahme von Verantwortung lässt. Das passiert meist dann, wenn es Einzelpersonen gibt, die sehr stark oder dominant auftreten und möglichst jeden Task selbst erledigen oder kontrollieren möchten. Im schlimmsten Fall äußert sich dies in der Rolle des Micro-Managers. Micro-Management bezeichnet das Phänomen, wenn jemand (meist eine Führungsperson) versucht nicht nur die Aufgaben zu definieren (sozusagen das Makro), sondern auch wie diese im Detail erledigt werden sollen. Akte von Micromanagement wären beispielsweise:

  • die Kontrolle von Anwesenheiten & Arbeitszeiten, anstatt von Resultaten

  • das Schreiben von Implementierungsdetails in Stories, statt von Anforderungen aus Sicht des Users

  • viele Meetings und Besprechungen

  • emotional geführter Sprachstil, statt rationalen Argumenten

  • keine Delegation von Entscheidungen

Lösung

Micro-Management sollte generell vermieden werden. Wenn man intelligente und fähige Mitarbeiter sucht und einstellt, dann muss man diesen auch Vertrauen entgegenbringen, da Intelligenz und Kompetenz sich erst zeigen kann, wenn das eigenständige Denken und Handeln auch erlaubt ist.

Kontrolle sollte nicht über das wie, sondern über Resultate ausgeübt werden. Die Erfolgsmessung in Scrum findet in der Demonstration des Software-Inkrements vor Stakeholdern und Kunden statt. Stakeholer und Kunden entscheiden, ob es sich um einen Erfolg handelt, nicht das Management oder stark auftretende Personen des Teams. Wenn Kunden und Stakeholder das demonstrierte für gut befinden bedeutet das, dass der Markt es für gut befindet – also das Ziel jedes marktwirtschaftlichen Unternehmens.

Der Sprint ist also ein Erfolg, wenn die zugesicherten Aufgaben erledigt werden können und vom Kunden abgenommen werden. Ob das mittlere Management ein Problem damit hat, dass ein Entwickler lieber nachts arbeitet ist dafür irrelevant. Auch zahlreiche Kontrolltermine zum aktuellen Stand sind unnötig. Stattdessen sollten dieser Aufwand lieber für die Lösung der angesprochenen Probleme in Retrospektiven und Dailies aufgewand werden. So wird das Potenzial des Teams für das Unternehmen ausgenutzt.

Langfristig haben Unternehmen die Micromanagement zulassen keine Chance am Markt, da die Mitarbeiter in andere Unternehmen wechseln. Jeder Mitarbeiter will gut und effizient arbeiten und wird deshalb langfristig bei Micro-Management davonlaufen – das trifft besonders auf sehr intelligente und fähige Personen zu.


Fehlende Führung

Gerade bei Projekten, bei denen es einen hohen Anspruch an die Konzepte der Agilität gibt, kann es sein, dass es eine regelrechte Angst davor gibt, klare Ansagen zu machen. Dabei kann ich als Entwickler sagen, dass es nichts Besseres gibt, als Stories mit klaren Anforderungen. Auch möchte ich nicht an Diskussionen teilnehmen, die mit meinem Fachgebiet und meiner Expertise nichts zu tun haben. Wenn ich nichts beitragen kann, dann möchte ich auch nicht in einem Scheinentscheidungsprozess eingebunden werden. Ich sage Scheinentscheidungsprozess, weil alle Teilnehmer, denen es genauso geht, sich ohnehin auf die starken Meinungen, derjenigen verlassen, die Expertise in diesem Gebiet haben. Wenn ich keine Verantwortung übernehmen kann, dann benötige ich klare Entscheidungen. Ich brauche Führung.

Insbesondere bei Entscheidungen, die den technischen Aufbau der ganzen Anwendung betreffen, sollte möglichst schnell eine einzige Person, oder eine kleine Gruppe gefunden werden, die sich des Themas annimmt. Beispielsweise wenn es darum geht, ob in einem Projekt eine Abstraktionsschicht zwischen Datenquelle und der eigenen Domäne eingebaut werden soll. Solche grundsätzlichen Entscheidungen sollten möglichst früh von Kernpersonen im Team getroffen werden und dann sowohl festgehalten als auch durchgezogen werden. Diese Kernpersonen fühlen sich dann auch verantwortlich dafür, dass dies durchgezogen wird.

Obwohl dies offensichtlich und einleuchtend ist, ist das Missverständnis der Führung in agilen Teams oft, dass niemand das „einfach ent scheiden kann“, gerade wenn es eine „große“ Entscheidung ist. Deshalb werden diese Entscheidungen dann gar nicht getroffen. Stattdessen werden dann architekturielle Entscheidungen in viel zu vielen, viel zu langen Meetings mit viel zu vielen Teilnehmern besprochen, bis die Entwicklung zu weit vorangeschritten ist, um die Entscheidung kostengünstig und effizient durchzusetzen.


Lösung

Es muss ein Umdenken stattfinden. Modern und agil heißt nicht, dass jeder bei jeder Entscheidung mitentscheiden (und besprechen) sollte. Gerade bei kleinen Teams und kleinen Zeiträumen (wie Sprints), sowie dem Einsatz von Proof-of-Concept Implementationen darf es Einzelpersonen geben, welche schnell Entscheidungen treffen. Gerade bei Entscheidungen zwischen Alternativen, die sich ohnehin kaum untereinander unterscheiden (und damit besonders schwierige Entscheidungen sind) kostet der Entscheidungsfindungsprozess am meisten Zeit, Energie und Motivation. Im schlimmsten Fall werden wichtige (meist technische) Entscheidungen dann nicht getroffen.


Im Konzept von agiler Entwicklung ist eingewoben, dass es Irrtum und Experimente geben darf. Dem Kunden darf (und soll) etwas präsentiert werden, was eine Richtungsänderung zur Folge hat. Es bedarf also Mut von jedem Einzelnen die Verantwortung bezogen auf einen Task wahrzunehmen, sowie die Größe von Anderen diese auch abzugeben. Eine ganz besondere Rolle nimmt dabei der Product Owner ein, welcher die User Stories basierend auf den Wünschen des Kunden und den Einflüssen aus dem Team schreibt und das Backlog priorisiert.


Zusammenfassung

  • Agil bedeutet, die Richtung eines Entwicklungsprozesses schnell ändern zu können. Das wird erreicht durch

  • keine lange Entwurfsphasen, sondern kurze Inkremente, die schnell zu ausführbarer Software führen

  • Demos welche zu Feedback vom Kunden führen, auf welches agil reagiert werden kann

  • Rücksicht auf Individuen und Interaktionen

  • Das agile Vorgehen basiert auf dem Prinzip eine Hypothese zu erstellen, diese zu testen und mit dem damit eingeholten Feedback die Hypothese zu bestätigen oder zu verwerfen

  • Das Team sollte Verantwortung für die Aufgaben übernehmen, welche dem Unternehmen dienlich sind

  • Geschieht dies nicht, liegt das an folgenden Gründen:

  1. Kommunikation: Es ist unklar, wer die Verantwortung übernimmt – deswegen übernimmt sie niemand.

  2. Micro-Management: Einzelpersonen übernehmen zu viel Verantwortung und üben Kontrolle über das „Wie“ anstatt über Resultate aus.

  3. Fehlende Führung: Personen welche Verantwortung übernehmen können und sollten, tun dies nicht, aus sozialen Gründen oder ihrer Einstellung.




29 Ansichten0 Kommentare

Aktuelle Beiträge

Alle ansehen