Wie Agilität gelingt. Katharina Maehrlein
zu 32 Prozent an, ihr Betrieb arbeite schon agil, aber nur 14 Prozent der HR-Führungskräfte, 9 Prozent der Fach-Führungskräfte sowie 7 Prozent der Mitarbeiter hielten das für zutreffend. In der Mehrheit der befragten Unternehmen sind auch nur punktuelle Umsetzungen in Richtung agile Organisation zu finden, bevorzugt in der IT.3
Allerdings erhält das jahrzehntealte Konzept der Agilität aktuell durch die neuen Herausforderungen der VUKA-Arbeitswelt, insbesondere durch die zunehmende Digitalisierung, eine hohe Aktualität und größere Bedeutung als bisher. Neu ist, dass jetzt viele Unternehmen, die bisher noch nicht überzeugt waren und erst einmal abgewartet haben, nun die Notwendigkeit sehen, zu starten; zahlreiche andere haben schon Teile ihrer Organisation, wie Produktion, Entwicklung oder IT, »agilisiert« und streben aktuell eher die Transformation von größeren Unternehmensbereichen oder sogar ganzen Unternehmen an.
Nach vielen Jahren, in denen man dachte: »Wir leben auch ohne oder mit wenig Agilität gut, warum also etwas ändern?«, ist nun der Druck so groß geworden, dass das Konzept ernster genommen wird als jemals zuvor. Derzeit gilt Agilität als Wunderlösung für alle Probleme, mit denen Unternehmen konfrontiert werden.
Aber trotz aller Vorteile, die Agilität bietet, knirscht es gewaltig in deutschen Unternehmen: Bei den einen ist es zum »Bullshit-Bingo«-Wort verkommen und löst schlecht gelauntes Schulterzucken aus, bei anderen gestaltet sich die Umsetzung schwieriger als gedacht und es herrscht große Enttäuschung darüber, dass die erwarteten positiven Ergebnisse nicht eintreffen. Wieder andere sind schon gescheitert und haben es aufgegeben, sich den schier unüberwindlich scheinenden Herausforderungen zu stellen.
Scrum als Beispiel für die heute am häufigsten verwendete agile Arbeitsform
Damit Sie eine noch bessere Vorstellung davon bekommen, wie agiles Arbeiten heute funktioniert und was daran anders ist als bei den herkömmlichen Arbeitsweisen, möchte ich Ihnen im Folgenden einen Überblick über Scrum geben.
Scrum ist das in Unternehmen am häufigsten verwendete agile Rahmenwerk und dasjenige, mit dem ich – neben Design Thinking – selbst am liebsten arbeite. Selbst wenn es nicht in seiner kompletten Form verwendet wird, nutzen die meisten doch zumindest einzelne Elemente daraus.
Scrum ist als Rahmenwerk zur Entwicklung von Produkten unter komplexen Bedingungen konzipiert und definiert – neben weiteren Prinzipien und Regeln für erfolgreiches agiles Arbeiten – empirisches Arbeiten (regelmäßiges Überprüfen und Anpassen der Arbeitsergebnisse) als unverzichtbares Kernelement.
Scrum beruht im Wesentlichen auf vier Prinzipien, die auch für die Arbeitsweise anders arbeitender agiler Teams essenziell sind:
1.Ergebnisse werden in regelmäßigen und kurzen Abständen überprüft,
2.daraus werden kontinuierlich Verbesserungen abgeleitet, damit
3.schnell pragmatische (Zwischen-)Lösungen entwickelt und früh auf den Markt gebracht werden können, um sie im Laufe der Zeit zu verbessern.
4.Ziele werden auf Basis von Kundenfeedback im Laufe der Entwicklung angepasst.
Scrum im Überblick
Das Arbeiten im selbstorganisierten Scrum-Team stützt sich auf drei Rollen, die für den Arbeitsprozess verantwortlich sind: den Product Owner (PO), den Scrum Master (SM) und das Development Team (Devteam).
Der PO repräsentiert den Kunden und steht zu diesem und zu den Stakeholdern in engem Kontakt. Er ist für den wirtschaftlichen Erfolg verantwortlich und verfolgt die mit dem Kunden abgestimmte Ergebnisvision. Um diese umzusetzen, erstellt er das Product Backlog, eine nach Prioritäten sortierte Auflistung von Anforderungen des Kunden.
Der SM unterstützt das Devteam dabei, die Scrum-Prinzipien und -Regeln zu verstehen und so anzuwenden, dass die gemeinsame Arbeit im Team von den positiven Scrum-Effekten profitieren kann. Er hält dem Team den Rücken frei und sorgt dafür, dass sogenannte »Impediments« – wie beispielsweise hemmende Rahmenbedingungen – aus dem Weg geräumt werden, damit sich das Team auf die vereinbarten Ziele konzentrieren und pünktlich Ergebnisse in hoher Qualität abliefern kann.
Das Devteam ist ein crossfunktionales Team ohne hierarchische Strukturen mit drei bis neun Mitgliedern, das sich selbst organisiert. Es verpflichtet sich, eine bestimmte Anzahl der Aufgaben aus dem Product Backlog abzuarbeiten. Dabei entscheidet das Team selbst, wie viele Aufgaben es annehmen kann, damit diese bis zum Ende des nachfolgenden Sprints abgearbeitet werden können. Das Team entscheidet auch selbst, wie die vom PO »bestellten« Aufgaben bearbeitet werden. Die Arbeit ist durch Sprints von zwei bis maximal vier Wochen Länge getaktet, in denen die ausgewählten Aufgaben abgearbeitet werden. Jeder Sprint startet mit einem Sprint Planning, bei dem ein gemeinsames Verständnis über das Ziel des anstehenden Zyklus erarbeitet wird, die Vorgehensweise, wie die Aufgaben am besten zu lösen sind, zusammen festgelegt wird, die runtergebrochenen Einzeltasks für alle sichtbar im Sprint Backlog visualisiert werden und der Aufwand der Teilschritte abgeschätzt wird, um die Fortschritte zu messen. Anhand eines »Burndownchart« kann jeder jederzeit erkennen, wie der Stand der Arbeit ist und ob und wann das Ziel des Sprints erreicht sein wird. So kann auch frühzeitig erkannt werden, ob noch Platz für weitere Aufgaben ist, die dann zusätzlich aus dem Product Backlog gezogen werden.
Am Ende eines jeden Sprints wird dem PO ein »Inkrement«, ein Teilergebnis, geliefert und im Review gemeinsam mit den Stakeholdern begutachtet und Feedback eingeholt. In der ebenfalls am Ende eines jeden Sprints stattfindenden Retrospektive wird besprochen, wie die Zusammenarbeit noch effektiver werden kann, und aus diesem Meeting und dem Feedback aus dem Review mindestens eine Verbesserung identifiziert, die im nächsten Sprint umgesetzt werden soll.
Im Daily-Stand-up-Meeting werden täglich maximal 15 Minuten lang der Arbeitsfortschritt, die nächsten Aufgaben und gegebenenfalls Probleme besprochen.
All diese Meetings (Sprint Planning, Review, Retro, Daily) und der Sprint finden in sogenannten Time-Boxes statt, das heißt in vorgegebenen Zeiteinheiten, die nicht überschritten werden dürfen.
Scrum arbeitet in kurzen iterativen Intervallen, das heißt, am Ende eines Sprints beginnt sofort der nächste Sprint, in dem weitere Aufgaben aus dem Product Backlog abgearbeitet werden. So schließt sich der Kreis, bis die Ergebnisvision erreicht ist.
Im offiziellen »Scrum Guide« der beiden Scrum-Erfinder« Jeff Sutherland und Ken Schwaber – zwei derjenigen, die am agilen Manifest mitgearbeitet haben – finden Sie weitere Informationen. Es gibt ihn kostenlos und in viele Sprachen übersetzt unter www.scrumguides.org. Weitere konkrete Umsetzungsempfehlungen finden Sie auch im Buch »Die Scrum Revolution« von Jeff Sutherland. Zwar markig amerikanisch, aber plastisch und aufschlussreich.
2.Warum an Agilität kein Weg vorbeigeht
Neben denjenigen, die schon vom Nutzen der Agilität überzeugt sind und diese auch schon erfolgreich umsetzen, gibt es unter meinen Kunden auch noch viele, die sich und mich fragen: »Müssen wir denn wirklich agil werden oder können wir nicht bitte einfach so weitermachen wie bisher?«
Meine Antwort: »Wenn Sie sicher sind, dass Sie auch in fünf, zehn oder 15 Jahren noch ausreichend gute Ergebnisse erzielen und am Markt bestehen werden, lassen Sie gerne alles, wie es ist. Wenn Sie allerdings auch nur im Ansatz unsicher sind (und in vielen Fällen wäre dies begründet), sollten Sie JETZT anfangen, agiler zu werden.«
Denn mit Agilität wird nicht nur einmal mehr »eine neue Sau durchs Dorf getrieben«, und Agilität ist auch nicht einfach nur ein weiteres Changeprojekt, das man nur ausreichend lange aussitzen muss, damit es ganz von alleine wieder verschwindet, wie schon so vieles davor. Nein,