TL; DR: Agiles Mikromanagement
Bei Scrum gibt es jede Menge Möglichkeiten des Scheiterns. Angesichts der Tatsache, dass Scrum ein Framework mit einem angemessenen, aber kurzen „Handbuch“ ist, sollte dieser Effekt niemanden überraschen. Der Scrum Guide weist zum Beispiel deutlich auf die Bedeutung des Selbstmanagements auf der Ebene des Scrum-Teams hin. Dennoch ist die häufigste Ursache für viele misslungene Versuche, Scrum anzuwenden, etwas, das ich als agiles Mikromanagement bezeichne: eine Pseudo-Verpflichtung zu agilen Prinzipien, die immer dann außer Kraft gesetzt wird, wenn es aus der Sicht eines Stakeholders oder Managers vorteilhaft erscheint.
Erfahren Sie in weniger als zwei Minuten, wie wichtig es ist, dass Scrum-Teams sich selbst managen.
🗳 Update: Join the poll and its lively discussion on LinkedIn.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
🖥 💯 🇬🇧 Advanced Professional Scrum Master Online Training w/ PSM II Certificate — September 6-9, 2022
📈 🔬 Join 460-plus peers and contribute to the anonymous poll for the upcoming Free ‘Product Owner and Product Manager Salary Report 2022!’
Das Scrum-Team und der Zweck des Selbstmanagements gemäß dem Scrum Guide
Laut dem Scrum Guide managt sich das Scrum-Team selbst:
“The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.”
Quelle: Scrum Guide 2020.
Neben diesen direkten Verweisen auf die Natur des Scrum-Teams gibt es im Scrum Guide auch viele andere Hinweise auf dieses erste Prinzip von Scrum — das Selbstmanagement:
- Page 4: Adaptation becomes more difficult when the people involved are not empowered or self-managing.
- Page 5: Within a Scrum Team, there are no sub-teams or hierarchies.
- Page 5: They are also self-managing, meaning they internally decide who does what, when, and how.
- Page 5: They are structured and empowered by the organization to manage their own work.
- Page 6: The Scrum Master serves the Scrum Team in several ways, including coaching the team members in self-management and cross-functionality.
- Page 8: [Sprint Planning: How will the chosen work get done?] How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
- Page 9: The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Quelle: The aggregation of quotes is taken from the Scrum Guide Reordered.
Gestatten Sie mir, auf das Offensichtliche hinzuweisen: Selbstorganisation bedeutet nicht die Abwesenheit von Management: Warum sollte ein Scrum-Team z. B. die Verantwortung für die Gehaltsabrechnung übernehmen? Würde das bei der Wertschöpfung für den Kunden helfen? Wahrscheinlich eher nicht. Ein selbstorganisierendes Team zu sein, bedeutet also nicht, dass es kein Management gibt. Es bedeutet jedoch auch, dass ein Mikromanagement, das mit den Praktiken in einem Montagewerk von General Motors im Jahr 1926 vergleichbar ist, nicht erforderlich ist.
Die Gründe für Agiles Mikromanagement
Meiner Erfahrung nach verwandelt sich Agilität in Mikromanagement, weil sich das mittlere Management gegen Veränderungen sträubt. Trotz besseren Wissens ist es nicht in jedermanns Interesse, eine Organisation in eine lernende Organisation zu verwandeln, die Experimente und Fehlschläge zulässt. Darüber hinaus stehen selbstorganisierende, eigenverantwortliche Teams oft im Konflikt mit dem Bestreben des mittleren Managements, persönliche Ziele zu verwirklichen, wie z. B. die Bewahrung der eigenen Existenz. Ich habe drei Hauptgründe beobachtet, warum Organisationen statt auf agilen Prinzipien – wie z. B. Scrums Betonung der Selbstorganisation von Teams – auf agiles Mikromanagement zurückgreifen:
- Empfundener Kontrollverlust: Da sie als Ansprechpartner für alle Probleme in ihren Abteilungen ausgebildet wurden, fällt es Managern schwer zu akzeptieren, dass die Teams sich jetzt selbst organisieren und eigenständig Lösungen finden müssen. Wenn ihre Untergebenen sie nicht mehr brauchen, werden sie dann nicht früher oder später überflüssig?
- Begegnung mit einem ernsten Problem: Das Management gibt die Selbstorganisation in dem Moment auf, in dem ein kritisches Problem auftaucht und bildet ‚Task Forces‘, anstatt die bestehenden Scrum-Teams bei der Lösung des Problems zu unterstützen.
- Zuweisung von Aufgaben: Manager weisen Entwicklern bestimmte Aufgaben direkt zu und umgehen so den Product Owner und ignorieren das Vorrecht des Entwicklers auf Selbstorganisation. Oder der Manager nimmt einen Entwickler aus einem Team heraus, damit dieser an einer solchen Aufgabe arbeitet.
Die Konsequenzen: Wenn man vorgibt, sich an agile Prinzipien zu halten, hat das nur eine kurze Lebensdauer, denn viele Praktiker in den Scrum-Teams werden das sehr schnell herausfinden. Der Verlust von Vertrauen kann verheerend sein, denn Vertrauen ist der Anfang von allem. Ohne Vertrauen gibt es keine Transparenz, ohne Transparenz gibt es keine Inspektion, und ohne Inspektion gibt es keine Adaption. Damit sind wir wieder da, wo wir angefangen haben: Eine „Wasserfall“-artige Planung, welche die Hoffnung verschleiert, dass eine Vermutung aufgehen und dem Initiator einen Karriereschub geben könnte. Gleichzeitig versuchen die Praktiker aus den Teams, sich aus den unvermeidlichen Schuldzuweisungen herauszuhalten, am Ende des Monats ihren Gehaltsscheck kassierend: „Sie geben vor, dass wir agil sind und wir geben vor, dass uns das Ergebnis wichtig ist.“
Die Lösung: Akzeptieren Sie, dass es in einem komplexen Umfeld keine Experten mehr gibt, die jedes Problem lösen können, das sich ihnen stellt. Folglich muss sich der Führungsstil anpassen: Statt den Mitarbeitern vorzuschreiben, was sie wann und wie zu tun haben, müssen Sie das kollektive Lernen, das Ausloten von Optionen und die Identifizierung von Lösungen, die sich aus der Teamarbeit ergeben, fördern. Es ist die Aufgabe des Managements, ein Umfeld zu schaffen, das dies ermöglicht, indem es jeden einbezieht und jedem eine Stimme in einem psychologisch sicheren Umfeld gibt. Für das Management ist es daher an der Zeit, den Taylorismus zugunsten von Servant Leadership aufzugeben. Agiles Mikromanagement passt nicht in unsere Zeit.
Fazit
Aus der Sicht des konservativen mittleren Managers gibt es viele Gründe, warum das Festhalten an einem Kommando- und Kontrollmanagementstil persönlich vorteilhaft erscheint. Daher besteht die Versuchung, jede agile Transformation den Erfordernissen der persönlichen Karriereplanung anzupassen, was oftmals agiles Mikromanagement einschließt. Und das widerspricht letztlich dem Zweck, selbstmanagende Teams auf organisatorischer Ebene überhaupt erst zu ermöglichen.
Das Problem ist nicht, dass diese Leute versuchen, Herausforderungen für ihre persönliche Agenda durch Pseudo-Verpflichtungen zu agilen Prinzipien zu überwinden, nur um sie dann außer Kraft zu setzen, wenn es ihnen nützlich erscheint. Das Problem ist vielmehr, dass Change Agents, die agile Transformationen unterstützen, sich kaum auf dieses Szenario vorbereiten. Sind die vier Werte des Manifests für agile Softwareentwicklung nicht selbstverständlich? Wer würde sie also ablehnen?
Haben Sie schon einmal erlebt, dass Unternehmen agiles Mikromanagement trotz aller Anstrengungen doch wieder nutzen? Bitte teilen Sie uns Ihre Erfahrungen in den Kommentaren mit.
📖 Agiles Mikromanagement — Weitere Lektüre
Agile Failure Patterns in Organizations 2.0
Three Essential Agile Failure Patterns in 7:31 Minutes—Making Your Scrum Work #12
20 Sprint Planning Anti-Patterns
24+2 Daily Scrum Anti-Patterns
15 Sprint Review Anti-Patterns
21 Sprint Retrospektive Anti-Patterns
Download the Scrum Anti-Patterns Guide for free.
✋ Nicht versäumen: Lernen Sie mehr über Agiles Mikromanagement im 12.000-köpfigen „Hands-on Agile Slack Team“
Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.
Der Artikel Agiles Mikromanagement — im Ernst? Making Your Scrum Work #27 wurde zunächst auf Berlin-Product-People.com veröffentlicht.