Die meisten meiner Kunden arbeiten mit agilen Methoden (Scrum oder Kanban) oder stellen gerade darauf um. Dabei herrscht oft große Unsicherheit, was das für die bisherigen TeamleiterInnen, BereichsleiterInnen, AbteilungsleiterInnen, EntwicklungsleiterInnen etc. bedeutet. Welche Management-Rollen werden in agilen Organisationen noch benötigt? Was sind deren Aufgaben?
In der Praxis ist das oft nicht sauber gelöst. TeamleiterInnen teilen User Stories an die EntwicklerInnen in den „Scrum“ Teams zu. BereichsleiterInnen ziehen mitten im Sprint Leute aus den Scrum Teams für Spezialprojekte ab. EntwicklungsleiterInnen kümmern sich um die Verwaltung des Bug-Backlogs und weisen Bugs am Product-Backlog vorbei an die Teams zu. All das führt zu viel Chaos. Es stört die Entwicklung und erzeugt Frust und Verwirrung bei allen Beteiligten.
Doch wie soll man das lösen? Grundlage agiler Methoden ist das agile Manifest und die 12 Prinzipen agiler Software-Entwicklung1. Einige der Prinzipien beschreiben die Aufgaben von Management und selbstorganisierten Teams:
- „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“
- „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“
- „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“
Der erste Punkt spricht direkt eine/n ManagerIn an. Für das Errichten von Projekten, das Zusammensetzen von Individuen zu Teams, deren Motivation, das Gestalten des Umfelds, die Unterstützung und das Geben von Aufgaben[1] sind auch in agilen Organisationen nicht die Teams selbst, sondern ManagerInnen verantwortlich. In den anderen Punkten ist beschrieben, was das Team selbst entscheiden kann, nämlich Architektur, Anforderungen, Entwürfe und sein Verhalten, sprich die eingesetzten Methoden. Die Teams dürfen also sehr viel selbst gestalten, aber eben nicht alles. Man spricht deshalb auch von „Selbst-Organisation“ und nicht von „Selbst-Management“.
Im Überblick ergibt sich so folgende Aufgabenverteilung:
| Agiles Team | Management |
Projekte aufsetzen |
| x |
Teams zusammenstellen |
| x |
Motivation hochhalten |
| x |
Mission und Aufgabe geben |
| x |
Umfeld abstecken |
| x |
Unterstützung geben |
| x |
Architekturen entwerfen | x |
|
Anforderungen spezifizieren | x |
|
Entwürfe erstellen | x |
|
Verfahren und Methoden auswählen und laufend verbessern | x |
|
Sehr ähnlich beschreibt Jurgen Appelo in seinem Buch „Management 3.0“ [3] folgende 6 Kernaufgaben von Management:
- Menschen aktivieren und energetisieren
- Teams ermächtigen
- Ausrichten und Rahmenbedingungen setzen
- Kompetenzen entwickeln
- Struktur entwickeln
- Alles verbessern
Gerade im Bereich Agiles Management empfiehlt es sich, eine/n erfahrene/n BeraterIn ins Boot zu holen, der/die dabei hilft, ein klares Konzept von Management zu entwickeln und dieses in der Organisation zu verankern. Mit dem 2-tägigen Workshop „Agile Management & Leadership“ bietet Software Quality Lab einen Startpunkt, um ein vollständiges und konsistentes Bild von agilem Management in ihrem Unternehmen zu entwickeln. Es wird erarbeitet, wo ihr Management heute steht und Ideen entwickelt, mit welchen Maßnahmen ihr Management Team sich in Richtung agiles Management weiterentwickeln kann. Natürlich begleiten Sie unsere Agile Coaches, wenn gewünscht, dann auf dem folgenden Weg der Umsetzung.
Quellen und Literatur zur dem Thema
[1] http://agilemanifesto.org/iso/de/principles.html
[2] Appelo, „Management 3.0: Leading Agile Developers, Developing Agile Leaders“
[3] Mendinilla, „Agile Management: Leadership in an Agile Environment“
[4] Adkins, „Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition“
1 Unter „Aufgabe“ ist dabei nicht eine einzelne kleine Anweisung gemeint, sondern die „Aufgabe“ im großen, der „Job“ des Teams (im englischen heißt es „… get their job done …“). Ich finde hier wäre „Mission“ passender.
