Besprechen Sie Ihr Vorhaben mit uns:
Die ganze Business-Welt spricht von „agile“ – agile Projekte, agiles Management, agile Services, agile Produktentwicklung. Alles muss schneller, flexibler, günstiger, sinnstiftender, selbstorganisiert und natürlich kundenzentriert werden. Teams werden zu Squads, Meetings zu Stand-ups, Aufgaben zu User Stories, Meilensteine zu Minimum Viable Products, Off-Sites zu Hackathons, und jede Office-Wand wird mit Post-Its tapeziert.
Wer nicht agil ist, ist nicht modern. Genau deshalb werden Methodenkompetenzen erworben, Techniken trainiert, Frameworks eingeführt und Sprints initiiert. Doch warum erleben viele Organisationen, die sich aktuell mit dem Thema befassen, so große Herausforderungen, agile Arbeitsweisen zu etablieren? Offensichtlich haben doch alle verstanden, worum es geht und wie dringend Unternehmen agil werden müssen, um weiterhin vorne mitzuspielen. Doch der Reihe nach.
01 Definition & Bedeutung von Agilität
Agilität steht für die Fähigkeit, schnell und gleichzeitig angemessen auf eine komplexe und dynamische Umgebung, vielfach in Form von Kundenanforderungen, zu reagieren. Agilität bedeutet also Beweglichkeit, oder – ganz einfach: Lebendigkeit.
Agile Unternehmen haben verstanden, dass sie sich in einem zusehend komplexen Umfeld bewegen und somit in immer schnellerer Folge auf neue Rahmenbedingungen einstellen müssen. Als Antwort darauf spiegeln sie die Dynamik ihres Umfeldes in ihrer eigenen Organisation wider – und schaffen es darüber hinaus in Teilen sogar, den Markt selbst zu dynamisieren. Charakteristisch sind dabei häufig ein starker Kundenfokus, kurze, iterative Planungs- und Entwicklungszyklen, flache Hierarchien und ein hohes Maß an Selbstorganisation.
Warum ist Agilität wichtig?
Viele Unternehmen spüren aktuell den Druck eines immer dynamischeren Marktumfelds, in dem es gilt, wettbewerbsfähig zu bleiben:
- Digitalisierung ermöglicht Disruption, die bestehende Technologien, Produkte und Dienstleistungen in kürzester Zeit vom Markt verdrängt. Neue Player fordern etablierte Unternehmen heraus. Wenn gesammeltes Wissen und Unternehmensgröße keinen dauerhaften Wettbewerbsvorteil schaffen, gewinnen Innovation und Agilität enorm an Bedeutung.
- Die steigende Zahl an Unwägbarkeiten im Marktumfeld erhöht unweigerlich das Tempo, mit dem Unternehmen Entscheidungen treffen und sich auf ändernde Bedingungen einstellen müssen. Die Planbarkeit geht zurück: konnten früher Projekte wasserfallartig über mehrere Jahre geplant und ausgerollt werden, genügen mittlerweile kurze, iterative Zyklen – je kürzer, desto besser.
- Die Wahrnehmung des eigenen Beitrags zur Wertschöpfung des Unternehmens wird zusehends zu einem zentralen Motivationsfaktor für Mitarbeiter. Fremdsteuerung und fehlende Selbstwirksamkeit zerstören Motivation und reduzieren Agilität und Innovationskraft drastisch.
Besprechen Sie Ihr Vorhaben mit uns:
02 Agiles Manifest
Im Jahr 2001 veröffentlichten 17 renommierte Software-Entwickler das Agile Manifest (Manifesto for Agile Software Development, Agile Manifesto). Zu den Erstunterzeichnern zählten u.a. die beiden Scrum-Begründer Jeff Sutherland und Ken Schwaber. Bis heute sind Tausende weitere Unterzeichner hinzugekommen, die sich öffentlich den Prinzipien des Manifests verschreiben. Die Verfasser wollten die Kerngedanken moderner Software-Entwicklung auf einen kurzen, gemeinsamen Nenner bringen.
Das agile Manifest besteht aus vier Leitsätzen, die agile Werte traditionellen Vorgehensweisen gegenüberstellt. Es spiegelt den Spirit von Agilität wider und bildet das Fundament für agile Methoden wie Scrum:
- Individuen und Interaktionen sind wichtiger als Prozesse und Tools
- Funktionierendes Produkt ist wichtiger als umfassende Dokumentation
- Reagieren auf Veränderungen ist wichtiger als das Befolgen und Abarbeiten eines Plans
- Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung
Die vier Leitsätze werden durch insgesamt zwölf Prinzipien weiter konkretisiert. Sie erklären detaillierter die Werte und Prinzipien für agile Teams:
- Den Kunden durch frühzeitige und kontinuierliche Lieferung funktionierender und wertvoller Produkte zufriedenstellen.
- Veränderte Anforderungen begrüßen, auch in späten Entwicklungsphasen.
- Regelmäßige Arbeitsprodukte innerhalb weniger Wochen oder Monate liefern – je kürzer die Zeitspanne, desto besser
- Business und Entwickler arbeiten täglich eng zusammen
- Das Projekt um motivierte Personen herum aufbauen, die das benötigte Umfeld, die Unterstützung und das Vertrauen bekommen
- Übermittelung und Austausch von Informationen durch persönliche Kommunikation.
- Funktionierende Arbeitsprodukte sind das wichtigste Maß für den Fortschritt.
- Einhalten eines konstanten Tempos.
- Kontinuierlich auf technische Exzellenz achten.
- Einfachheit ist essenziell.
- Teams sind selbstorganisiert.
- Teams prüfen in regelmäßigen Abständen, wie sie besser werden können und passen ihr Verhalten entsprechend an.
Besprechen Sie Ihr Vorhaben mit uns:
03 Unsere agilen Beratungsprodukte
Eine agile Transformation umfasst im Kern das Etablieren einer neuen Organisationskultur basierend auf agilen Werten und Prinzipien, ohne die jede noch so bewährte Methode wirkungslos bleibt. Unser Beratungsangebot „Agile Transformation“ stellt den Link zwischen Methode, Werten und Prinzipien sowie der Kultur einer Organisation her. Den Wertschöpfungsauftrag im Fokus, werden hemmende Muster in der Zusammenarbeit erkannt, und gezielt durchbrochen. Hindernisse innerhalb der Organisation werden identifiziert und iterativ beseitigt, um gezielt jene Rahmenbedingungen zu schaffen, in der die neuen Werte gelebt, und nach agilen Prinzipien zusammengearbeitet werden kann.
Unsere Leistungen im Bereich „Agiles Projektmanagement“ richten sich an Unternehmen, deren Projekte komplex und in ein volatiles Umfeld eingebettet sind. Ziel ist es, auf Basis einer soliden Produktvision schnell und iterativ sogenannte Minimum Viable Products (MVP) zu erarbeiten, die direkt auf Mehrwert geprüft und bewertet werden. Somit kann frühzeitig Marktwirksamkeit erreicht, validiert und bei Bedarf adaptiert werden. Wir unterstützen Unternehmen, einen Rahmen für agiles Projektmanagement zu schaffen und begleiten sie dabei, ihre Projekte konsequent agiler zu machen.
Paradoxerweise kommt in ausnahmslos jeder agilen Transformation Führungskräften eine Schlüsselrolle zu. Klassische Management-Tätigkeiten werden überflüssig oder von nun an vom Team abgedeckt. Neue Aufgaben und Herausforderungen entstehen und werden zum Erfolgsfaktor für die Transformation. In unseren Angeboten rund um das Thema „Agile Führung“ begleiten wir Führungskräfte auf dem Weg vom „Manager“ zum „Organisationsentwickler“ mit Vorbildfunktion für die eigenen Mitarbeiter. Mit unserem Change Know-how und jahrelanger Erfahrung in der Führungskräfteentwicklung gestalten wir diesen Transformationsprozess sowohl auf persönlicher Ebene gemeinsam mit der jeweiligen Führungskraft, als auch mit dem gesamten Führungsteam der Organisation.
„OKR“ ist eine agile Führungsmethode, die Unternehmen dabei hilft, mit gut formulierter Objectives and Key Results die Ziele des Unternehmens mit den Zielen von Teams und einzelnen Mitarbeitern zu verbinden. Wir unterstützen Sie bei der schrittweisen oder unternehmensweiten Einführung der OKRs. Durch unsere Expertise im Change Management machen wir Erfolge messbar und transparent, ohne bei Ihren Mitarbeitern Druck aufzubauen.
04 Agile Transformation
Definition und Bedeutung von „Agile Transformationen“
Der Begriff „Agile Transformation“ beschreibt den Weg von einer klassischen Organisation in eine agile Organisation, d.h. eine Organisation, die bei der Produktentwicklung und Leistungserstellung eine ganze Reihe agiler Prinzipien befolgt, um in der VUCA-Welt zu bestehen. Die agile Transformation ist ein Change Prozess, den Unternehmen nicht von heute auf morgen durchlaufen. Denn um als Organisation wirklich agil zu arbeiten, braucht es weit mehr als nur Methodenkompetenz und kürzere Planungszyklen. Viel entscheidender sind die Rahmenbedingungen, unter denen Wertschöpfung im Unternehmen stattfindet. Sie bestimmen, welches Verhalten wann opportun ist, welche Ansprüche die Organisation an ihre Mitarbeiter hat und welche Grenzen nicht überschritten werden dürfen.
Warum scheitern agile Transformationen?
Häufig sind es eben jene Rahmenbedingungen, die zum kritischen Erfolgsfaktor werden und an denen viele agile Transformationen scheitern. Strukturelemente wie Reporting- und Freigabeprozesse, Steuerungs- und Planungsapparate oder interne Leistungsanreize und -bewertungen können agile Wertschöpfung entweder behindern oder erst wirklich möglich machen. Sie sind der größte Hebel, um die Verschmelzung aus der Wertschöpfung sowie den Werten und Prinzipien einer Organisation gezielt aufzubrechen und neu zu verknüpfen. Um zu verstehen, wie das gelingen kann, steht eine grundlegende Erkenntnis am Anfang:
Im Kern einer agilen Transformation stehen nicht etwa Methoden oder Frameworks sondern zu aller erst Werte und Prinzipien, die die Zusammenarbeit regeln.
Denn: jede einzelne der bekannten, vielbeworbenen agilen Methoden entstand durch die konsequente Anwendung dieser Werte und Prinzipien auf einen bestimmten Geschäftsfall – sei es SCRUM für die Projektarbeit, Kanban für den Servicebereich, Lean Startup zum Testen neuer Geschäftsideen. Visualisierungs- und Schätztechniken wie Burn-Down-Charts oder Planning-Poker folgten.
Leider fokussieren agile Transformationen zu häufig auf eben diese Methoden und Techniken statt bei den Werten und Prinzipien anzusetzen. Jede Methode – und sei sie noch so angesagt – kann jedoch nur dann erfolgreich von einer Organisation angewandt werden, wenn sie den gleichen agilen Werten und Prinzipien folgt, auf denen die Methode beruht. Tut sie das nicht, wird die Anwendung nicht nur wirkungslos bleiben, sondern im schlimmsten Fall Schaden anrichten.
Die handlungsleitenden Werte und Prinzipien einer Organisation wiederum sind festgeschrieben in ihrer Kultur, die mit unsichtbarer Hand das Verhalten bestimmt und Entscheidungen lenkt. Spricht man von nachhaltiger agiler Transformation, meint man somit automatisch immer auch eine kulturelle Transformation. Am Beginn von Agilität stehen also nicht Post-Its, Squads, Sprints, und Hackathons, sondern Werte und Prinzipien sowie ein kritischer Blick auf die eigene Kultur.
Schritt für Schritt zur agilen Organisation
Kultur ist das Gedächtnis der Organisation. Sie ist ihr Immunsystem, dass durch Replikation dessen, was in der Vergangenheit erfolgreich war, das Überleben der Organisation in der Zukunft zu sichern versucht. Kultur spiegelt sich in der Organisation wider: in Prozessen, Organigrammen und Regeln, die sich über Jahrzehnte als hilfreich herauskristallisiert haben. Für die nachhaltige Veränderung der Kultur einer Organisation hilft es nicht allein, neue Werte auszurufen und die Flure mit Postern zu tapezieren – genau wie es wenig hilft, in einem Konzert mit schlechter Stimmung per Teleprompter das Publikum zu authentischer Begeisterung zu bewegen. Selbst, wenn auch der letzte Mitarbeiter von der Wirksamkeit agiler Werte und Prinzipien überzeugt ist, wirken die Prozesse und Strukturen der Organisation oft wie eine Lehmschicht. Nur durch gezieltes Hinterfragen von Prozessen, Entscheidungsregeln, Organigrammen, etc. können die bisherigen Rahmenbedingungen für Zusammenarbeit in kleinen Iterationen analysiert, gezielt verändert, und die Beweglichkeit der Organisation erhöht werden. Jede Iteration ermöglicht so, neue Erfahrungen zu sammeln, die in das kulturelle Gedächtnis eingehen und zu einer nachhaltigen Veränderung führen.
1. Muster erkennen
Eine Iteration beginnt zunächst mit der Frage nach dem Wertschöpfungsauftrag und wo die aktuelle Organisation diesen behindert. Im ersten Schritt beobachten wir hierfür die Zusammenarbeit, um kritische Muster zu erkennen und so Ansatzpunkte zu identifizieren. Bildlich lässt sich das anhand einer Schaukel verdeutlichen: Um ein bereits schaukelndes Kind mit der gewünschten Wirkung zu beschleunigen oder zu verlangsamen, muss zunächst beobachtet werden, in welchem Muster die Schaukel schwingt. Erst dann kann der Schubser an der richtigen Stelle und zum richtigen Zeitpunkt erfolgen, um den Schwung wie gewünscht zu verstärken oder zu reduzieren. Auf die gleiche Weise beobachten und analysieren wir im ersten Schritt die bestehende Organisation und ihre Muster.
Beispiel: Die Personalabteilung eines Kunden hat zwei Wertschöpfungsaufträge. Zum einen ist sie für administrative Aufgaben wie Verträge, Zeugnisse, den Onboarding-Prozess, etc. zuständig. Zum anderen sollen individuelle Personalentwicklungsmaßnahmen konzipiert werden. Mit Letzterem sind die internen Kunden in der Vergangenheit immer wieder unzufrieden gewesen. Die Mitarbeiter der Abteilung sind es gewohnt, Entscheidungen ab einer entsprechenden Tragweite ihrer formalen Führungskraft zu überlassen. Bei unserer Beobachtung fällt auf, dass die Führungskraft auf Grund ihrer formalen Entscheidungshoheit neben dem eigentlichen Kunden zu einem starken zweiten Referenzpunkt in der täglichen Arbeit der Mitarbeiter geworden ist.
2. Hypothese bilden
Im nächsten Schritt setzen wir das erkannte Muster in Bezug zum Wertschöpfungsauftrag und stellen eine Hypothese darüber auf, welchen Einfluss die Organisation auf die Wertschöpfung hat. Wir suchen nach einem Grund, warum die Arbeit nicht wie vorgesehen gelingt.
In unserem Beispiel erkennen wir, dass die Mitarbeiter Personalentwicklungskonzepte entwickeln, die vor allem der Vorstellung der Führungskraft entsprechen. Der Kundenfokus tritt dadurch in den Hintergrund und die Wertschöpfung der Konzepte leidet. Wir stellen die Hypothese auf, dass dieser Teil der Wertschöpfung ohne formale Machtstrukturen kundenzentrierter stattfinden und so bessere Ergebnisse produzieren würde.
3. Muster brechen
Die Hypothese zu Grunde legend, suchen wir gemeinsam nach einem geeigneten Hebel, um das wiederkehrende Muster zu durchbrechen. Es geht um eine organisatorische Intervention, eine Art Experiment, mit dem für einen vorher definierten Zeitraum neues ausprobiert und andere Erfahrungen gesammelt werden. Nur so können sich Denkweisen und Überzeugungen ändern – mit direkten Auswirkungen auf die zu Grunde liegende Kultur. Es braucht gezielte Irritationen der bestehenden Organisation, um eine nachhaltige Veränderung zu ermöglichen.
In unserem Beispiel irritieren wir die bestehende Organisation der Abteilung, indem wir für den Zeitraum der nächsten Konzeption eines Personalentwicklungskonzepts – von der Auftragsklärung bis zur Fertigstellung – den Einfluss der Führungskraft nahezu vollständig eliminieren. Wir limitieren Reporting, übertragen dem Team die volle Budgetverantwortung und lassen sie jegliche Entscheidungenalleine treffen, ohne Interventionsmöglichkeiten der Führungskraft. Deren einzige Aufgabe ist es, den dafür nötigen Schutzraum zu schaffen. Sowohl Team wie auch die Führungskraft werden von uns entlang des Piloten begleitet, um Rückfälle in alte Verhaltensmuster zu vermeiden.
4. Ergebnisse bewerten
Nach Abschluss des Experiments wird überprüft, welche Veränderungen sich ergeben. Hatte der Hebel die gewünschte Wirkung? Was von dem Ausprobierten behalten wir, was muss noch einmal überdacht oder angepasst werden? Könnte das auch ein Hebel für andere Bereiche sein? Oder müssen wir doch etwas ganz anderes austesten?
In unserem Beispiel hat es funktioniert. Trotz anfänglicher Unsicherheiten berichtet das Team von einer wirkungsvollen und effektiven Zusammenarbeit, bei der sie sich eigenverantwortlich organisiert und ausschließlich auf die Wünsche und Bedürfnisse der Kunden fokussiert haben. Das Ergebnis ist ein Produkt, das die Kunden begeistert und einen echten Mehrwert liefert.
Wichtig: Es gibt keine Blaupausen und auch keine Best Practices für agile Transformationen. Das erfolgreiche Experiment zeigt nur, dass der identifizierte Hebel in diesem speziellen Umfeld mit diesem speziellen Team funktioniert hat. Die Übertragbarkeit auf andere Teams und Bereiche erfordert immer zunächst eine eigene Hypothese und ein neues Experiment – auch wenn bereits gesammelte Erfahrungen den Beobachtungsprozess beschleunigen und die Treffsicherheit in der Hypothesenbildung häufig entscheidend erhöhen.
Mit dem Transformation Loop zu einer agilen Organisation
Wie das Beispiel unseres Kunden zeigt, stellen Veränderungen Organisationen vor komplexe Herausforderungen und es benötigt ein durchdachtes Vorgehen, dieser Herausforderung zu begegnen. Eine Organisation auf eine agile Organisation umzustellen, bedeutet demnach Ungewissheit und muss ganzheitlich erfolgen, um die volle Wirkung zu erzeugen. Unser iteratives Vorgehen, basierend auf Experimenten, ermöglicht eine inkrementelle Verbesserung. Nichtsdestotrotz benötigen wir ein strukturiertes Vorgehen, um den Überblick zu behalten und Erfolge zu erkennen. Die folgende sowohl strukturierte als auch iterative Vorgehensweise ermöglicht genau dies und ist in der Lage, auf sich entwickelnde Transformationsbedingungen zu reagieren: Der Agile Transformation Loop.
Der Agile Transformation Loop beschreibt ein Vorgehen in Anlehnung an Scrum, angereichert mit Aspekten aus unserer langjährigen Change Management Erfahrung. Dieses Vorgehen setzt sich aus aufeinander aufbauenden Phasen zusammen und basiert auf einem kontinuierlichen Lern- und Entwicklungsprozess, die der Iteration „Muster erkennen – Hypothesen bilden – Muster brechen – Ergebnisse bewerten“ einen strukturierten Rahmen gibt.
Vorbereitung des agilen Transformationsvorgehens
Um die agile Transformation initial anzustoßen, benötigt es strukturelle Vorarbeit. Die Basis hierfür bilden zunächst die Schritte „Muster erkennen und Hypothesen bilden“, um die bestehende Organisation und ihre Muster zu analysieren. Diese Muster werden in Relation zum Wertschöpfungsauftrag gesetzt, sodass wir Hypothesen ableiten können, die wiederum den Grundstein für den sogenannten Transformation Backlog legen. Den Transformation Backlog kann man sich wie eine richtungsweisende Liste anzugehender Punkte auf dem Weg zu einer agilen Transformation vorstellen.
Darüber hinaus benötigt es natürlich ein Team, welches die agile Transformation im Unternehmen treibt. Wir setzen dabei auf ein Transformation Team, bestehend aus unterschiedlichen Rollen. Der Main Sponsor fungiert als der Transformation Owner, die Stimme des Kunden „Organisation“, und ist insgesamt verantwortlich für die Transformation. Unterstützt wird dieser insbesondere vom Transformation Master, der das Team und indirekt das Transformationsvorhaben prozessual begleitet. Gemeinsam stehen sie dem Transformation Core Team unterstützend bei der Umsetzung der verschiedenen Schritte auf dem Weg zu einer agilen Organisation zur Seite. Des Weiteren basiert das Transformationsvorgehen auf Sprints, dessen Dauer vorab geklärt werden muss. Erfahrungsgemäß macht eine Iteration von 4 Wochen Sinn.
Strukturelle Durchführung der agilen Transformation
Gerade in den letzten Jahren kristallisierte sich immer mehr heraus, dass ein agiles, iteratives Vorgehen bei richtiger Durchführung insbesondere bei groß angelegten Veränderungsprozessen sehr erfolgsversprechend ist. Diesen Ansatz haben wir uns zur Vorgehensweise bei Veränderungsprozessen zu Nutze gemacht und Scrum mit holokratischen Elementen und Elementen des Change Managements vereint.
Die den Ansatz leitende Frage lautet: „Wie müssen wir die agile Transformation wirksam gestalten, um Wertschöpfung erfolgreich und nachhaltig zu organisieren?“. Da wir, wie die Frage aufzeigt, noch nicht wissen wie der Zielzustand aussieht, treiben wir die Transformation in Sprints. So können wir bereits nach kurzen Zeitabständen gemeinsam Quick Wins generieren, die auf eine positive Veränderungsdynamik einzahlen: Durch das Ausprobieren in Form von Experimenten, auf die sich Organisationen und Mitarbeiter in der Regel viel schneller einlassen, ermöglichen wir die Erzeugung von kleinen (Teil-)Erfolgen in kurzen Zeitspannen. Und auch wenn eine anfänglich erfolgsversprechende Idee mal nicht funktioniert, erfahren wir dies zeitnah durch regelmäßige Feedbackschleifen und Überprüfungen der Hypothesen und Experimente sowie gemeinsam entwickelter Produkte und Konzepte.
Wie gestalten sich unsere Überlegungen nun konkret in der Durchführung? Der bereits vorgestellte, gemeinsam erarbeitete Transformation Backlog (1) dient als erster Anknüpfpunkt. Dieser enthält die zum aktuellen Stand ermittelten Hypothesen der Veränderungspotenziale, aber auch Interventionen, wie beispielsweise Workshops oder Enablings, die in der Arbeit mit den Menschen und an der Organisation sinnvoll erscheinen. Somit wird eine Übersicht über die anzugehenden Teilaufgaben nach dem heutigen Wissensstand erstellt. Der Transformation Backlog weist eine hohe Dynamik auf und wird stetig mit neuen Erkenntnissen aktualisiert und verbessert.
In einem weiteren Schritt werden die durch den Transformation Owner am höchsten priorisierten Hypothesen und Interventionen in den Transformation Sprint Backlog (2) aufgenommen. Die Anzahl der aufgenommenen Elemente hängt hierbei sowohl stark von der festgelegten Sprintdauer als auch der Kapazität des ernannten Transformation Core Teams ab.
Auf dieser Basis wird nun der Veränderungsprozess eingeleitet, beginnend beim Transformation Sprint Planning (3). In diesem Meeting klärt das Transformation Core Team die im Transformation Sprint Backlog enthaltenen Hypothesen, bricht diese in durchführbare Teilaufgaben herunter und priorisiert diese final. Das selbstorganisierte Team ist im Anschluss in der Lage, die Aufgaben gemäß des priorisierten Transformation Sprint Backlog (also der Liste der zu erledigenden Aufgaben im folgenden Sprint) herauszuziehen und zu bearbeiten. Wir befinden uns demzufolge in der Phase des Aufbrechens der analysierten Muster.
Während des Durchlaufens erachten wir weitere Transformationsevents, kombiniert aus den Ansätzen des Scrum Frameworks und der Holokratie, als sinnvoll und nutzstiftend, um kontinuierlich Transparenz über den Fortschritt des Projekts zu haben. Diese Events haben wir unterteilt in Abstimmungsmeetings „X-ly“ (4) während des laufenden Sprints sowie System Review (5), Progress Review (6), Retrospektive (7) und Refinement (8) jeweils am Ende eines jeden Sprints.
Die Abstimmungsmeetings, in unserer Darstellung „X-ly“ (4) genannt, finden in regelmäßigen Abständen statt, um kontinuierlich Transparenz während des Sprints zu gewährleisten: das Team synchronisiert Aktivitäten, teilt Erkenntnisse und Wissen und bekommt die Möglichkeit, Hindernisse frühzeitig aus dem Weg zu räumen, um etwaige Verzögerungen so gering wie möglich zu halten. Die Struktur des „X-lys“ folgt demzufolge dem „Daily“ in Scrum, kann jedoch auch beispielsweise in ein „Weekly“ abgewandelt werden: Die Häufigkeit dieser Meetings wird nach individuellem Bedarf vor Start des Agile Transformation Loops beschlossen.
Im System Review (5) fokussieren wir uns auf die Überprüfung der Wirkung der durchgeführten Experimente aus systemischer Perspektive, die auf Basis unserer aufgestellten Hypothesen durchgeführt wurden. Es verfolgt das Ziel konkrete Beobachtungen während des Sprints zu überprüfen und direktes Feedback einzuholen, das sich auf Veränderungen innerhalb des Systems (der Organisation) bezieht. So kristallisiert sich bereits kurzfristig heraus, welche Änderungen an Strukturelementen (nachhaltig) Wirkung erzeugen, welche Veränderungen wirklich helfen und welche aber auch Gegenteiliges bewirken. Dieses Vorgehen gewährleistet eine kontinuierliche Verbesserung auf dem Weg hin zu einer agilen Organisation, indem die im Sprint relevanten systemischen Elemente beleuchtet werden.
Der Progress Review (6) hingegen fokussiert sich auf die Produktentwicklungsperspektive eines jeden Sprints. Die konkret erarbeiteten Produkte, wie beispielsweise (Workshop-)Formate oder Konzepte werden in diesem Event vorgestellt. Greifbare Ergebnisse und auch Feedback zu Durchführungen werden präsentiert, um zu überprüfen, ob die konzipierten Produkte und eingesetzten Formate in der Organisation ankamen und die gewünschte Wirkung erzielen konnten.
Die darauffolgende Retrospektive (7) bietet die Gelegenheit die Zusammenarbeit im Team zu analysieren und weiterzuentwickeln, um diese während der gesamten Transformation kontinuierlich zu verbessern. Dabei überprüfen wir nicht nur die menschliche Zusammenarbeit, sondern auch die verwendeten Tools, Prozesse und Werkzeuge. Des Weiteren können auftretende (zwischenmenschliche) Hindernisse bei der Umsetzung der Aufgaben durch direktes Feedback aus dem Weg geräumt werden. Sich daraus ergebende Verbesserungspotenziale für die darauffolgenden Sprints stellt für uns das Endprodukt der Retrospektive dar.
Wir schließen unseren Sprint mit dem Refinement (8) ab, welches uns hilft, das nächste Sprint Planning vorzubereiten und somit einen nahtlosen Übergang zu gestalten. Unser Transformation Backlog wird auf den aktuellen Stand gebracht, bestehende Elemente werden aktualisiert und neue durch Erkenntnisse aus dem System und Progress Review ergänzt.
Sind alle Hypothesen aus dem Transformation Sprint Backlog bearbeitet und die gewünschte Wirkung wurde erzielt bzw. neue Schritte abgeleitet, kann der Sprint als abgeschlossen angesehen werden. Im Sinne eines erfolgreichen Change Gedanken ist es wichtig, die (kleinen) Erfolge nicht nur „im stillen Kämmerchen“ abzuhaken, sondern diese als positive Impulse in die Organisation zu tragen. Erfolgsgeschichten (9) tragen zur positiven Affirmation bei und machen Mitarbeitern und Stakeholdern den Fortschritt transparent. Ergänzend kann die Kommunikation „Wir sind auf einem guten Weg“ die Mitarbeiter zusätzlich motivieren und auch den positiven Nebeneffekt erzielen, (anfängliche) Kritiker mitzuziehen. Nach einem abgeschlossenen Sprint beginnt ein neuer Sprint: der nächste Agile Transformation Loop.
Mit jeder Iteration macht die Organisation einen weiteren entscheidenden Schritt in Richtung einer agilen Organisation. Die Transformation selbst wird jedoch nie abgeschlossen sein. Denn so lange die Umgebung der Organisation dynamisch bleibt und Überraschungen bereithält, wird sich auch die Organisation selbst immer wieder hinterfragen und neu erfinden müssen. Unser Ziel ist es daher, Keimzellen der agilen Organisation zu säen und unsere Kunden zu befähigen, die beschriebenen Iterationen schnellstmöglich eigenständig initiieren und durchführen zu können. Nur so kann Wertschöpfung nachhaltig und erfolgreich organisiert werden.
Die Transformation selbst wird jedoch nie abgeschlossen sein. Denn so lange die Umgebung der Organisation dynamisch bleibt und Überraschungen bereithält, wird sich auch die Organisation selbst immer wieder hinterfragen und neu erfinden müssen. Unser Ziel ist es daher, Keimzellen der agilen Organisation zu säen und unsere Kunden zu befähigen, die beschriebenen Iterationen schnellstmöglich eigenständig initiieren und durchführen zu können. Nur so kann Wertschöpfung nachhaltig und erfolgreich organisiert werden.
Unser Beratungsansatz: Mehr Agilität durch Vernetzung und Institutionalisierung
Typischerweise setzen unsere Beratungsprojekte in einem konkreten Bereich eines Unternehmens an. Beste Voraussetzungen, den Bereich agiler zu machen, sind dann gegeben, wenn die Beauftragung und die Motivation für die Veränderung von der bereichsverantwortlichen Führungskraft selbst kommen. Durch Coaching und operativen Support befähigen wir die Führungskräfte des Bereichs, eine agile Organisation wirksam von innen nach außen aufzubauen und Kulturveränderungen nachhaltig zu implementieren. Außerdem bringen wir umfassendes Know-how bei der Identifizierung von Wertschöpfungshebeln mit und befähigen Führungskräfte, die Veränderung der Kultur Schritt für Schritt selbständig weiter voranzutreiben.
Wie kann aus einer bereichsbezogenen, agilen Transformation – in unserem Beispiel in der Personalabteilung – eine flächendeckende Transformation entstehen, die dazu führt, dass das gesamte Unternehmen auch im Kern agil wird? Je mehr Keimzellen der agilen Organisation im Unternehmen gesät werden und miteinander vernetzt sind, desto mehr Erfahrungen können geteilt, Lessons Learned ausgetauscht, sowie gemeinsame Muster – gewünschte und unerwünschte – erkannt werden. Mit unserer langjährigen Erfahrung im nachhaltigen Change Management bringen wir die notwendige Kompetenz mit, entsprechende Dynamiken zu fördern und selbstverstärkend Wirkung zu entfalten.
Viele einzelne agile Transformationen und der offene Austausch darüber führen dazu, dass nach und nach die „Hidden Rules“ und „Organisational Patterns“ offengelegt werden und eine agile Organisation institutionalisiert wird. Die Kultur des Unternehmens wird dabei nicht auf den Kopf gestellt. Erfahrungsgemäß bleiben viele „Hidden Rules“ und „Organisational Patterns“ stabil, während zentrale Regeln und Organisationsstrukturen, die dem Wandel sowie der Wertschöpfung im Weg stehen, gezielt ersetzt werden.
Denn: Agile Transformation darf niemals zum Selbstzweck werden. Zu aller erst muss immer die Frage nach dem Wertschöpfungsauftrag stehen und welche Strukturen und Rahmenbedingungen diesen aktuell behindern. Echte Wertschöpfung hat für uns daher in jedem Projekt oberste Priorität. Denn am Ende zählt nicht, wie viele Post-Its an der Wand kleben und wie viele Sprints man gelaufen ist, sondern ob der Kunde für das Produkt oder den Service zahlt. Wir sind überzeugt, dass gut organisierte Wertschöpfung, die echte Kundenbedürfnisse befriedigt, nicht nur nachhaltigen wirtschaftlichen Erfolg bringt, sondern auch den Mitarbeitern ein Gefühl von Zufriedenheit gibt, sie stolz macht und inspiriert. Dafür stehen wir.
Genau aus diesem Grund haben wir keine Blaupause für „die agile Organisation“. Was wir Ihnen aber bieten können, ist ein erprobtes Vorgehen, wie eine agile Transformation erfolgreich angegangen werden kann. Unsere Erfahrungen sind äußerst positiv. Ob als Coach, Berater, Trainer, Mitdenker oder Co-Pilot: Wir finden gemeinsam heraus, was es braucht und haben dafür jede Menge Werkzeug im Gepäck.
Besprechen Sie Ihr Vorhaben mit uns:
05 Agiles Projektmanagement
Was ist Agiles Projektmanagement?
Agiles Projektmanagement ist der Oberbegriff für verschiedene agile Projektmanagement-Methoden, die auf den agilen Werten und Prinzipien des Agilen Manifest basieren. Typisch für agiles Projektmanagement ist ein iteratives, inkrementelles Vorgehen. Das Projekt wird in Iterationen unterteilt, und am Ende jeder Iteration steht ein Produktinkrement – das sogenannte MVP (Minimum Viable Product, minimal überlebensfähiges Produkt), das dem Auftraggeber zur Kontrolle vorgelegt wird. Anhand des internen Kundenfeedbacks wird dann am Produkt weitergearbeitet. Da der Projekt-Scope im Gegensatz zu traditionellen Projekten nicht vollständig geplant wird, ist eine Produktanpassung an neue Anforderungen auch während der Projektlaufzeit gut möglich oder sogar gewünscht.
| Klassische Projekte | Agile Projekte | |
|---|---|---|
| Anforderungen sind bekannt, nicht viele Änderungen erwartet, Änderungen müssen einem definierten Change Prozess folgen. | Anforderungen | Anforderungen entstehen allmählich oder ändern sich sehr schnell, konstante Feedback-Zyklen, Ansatz ermöglicht häufige Änderungen in jeder Iteration. |
| Experten, klare Rollen und Verantwortlichkeiten, strukturierte Entscheidungsmandate und Reporting-Strukturen | Team | Selbstorganisierte, befähigte Mitarbeiter, funktionsübergreifend, End-to-End-Verantwortung, kleine Teamgröße |
| Entwicklung in klar definierten und geplanten Phasen und mit Quality Gates | Entwicklung | Inkrementelle und iterative Entwicklung |
| Bereitstellung der Komplettlösung in einem vollständigen Release (oder wenigen, großen Releases) | Markteinführungszeit | Häufige, regelmäßige Releases, um den Funktionsumfang der Lösung von Iteration zu Iteration zu erhöhen. |
| Variiert je nach Projektphase, am Anfang und am Ende stark gefordert | Kundenverfügbarkeit | Hoch – kontinuierliche Teilnahme und Feedback ist erforderlich. |
Agiles Projektmanagement – Die Herausforderungen unserer Kunden
„Unsere Projekte dauern zu lange.“
„Wir wollen schneller Ergebnisse sehen.“
„Unsere Projekte sind viel zu administrativ. Wir beschäftigen uns mit uns selbst, wir schreiben Projektanträge, wir schreiben Statusberichte und konzentrieren uns viel zu wenig auf die Inhalte – nämlich etwas Neues zu schaffen, etwas zu entwickeln.“
Da sind typische Statements, mit denen Kunden auf uns zukommen. Gerade wenn Projekte aufgesetzt werden, basiert die Planung bestenfalls auf Konzepten, meistens auf Ideen und schlimmstenfalls auf heißer Luft. Nach bestem Wissen und Gewissen werden Annahmen getroffen, Projektumfänge beschrieben sowie Zeiten und Kosten geschätzt. Dabei weiß jeder ganz genau, dass die Schätzungen nicht valide sind. Denn Projekte werden immer größer und die Erwartungen an Projekte ändern sich immer schneller. Zudem ist man im klassischen Projektmanagement, auch wenn alle geforderten Dokumente gepflegt sind, nie wirklich transparent: Schafft man es tatsächlich, in der ersten Projektphase eine formal und inhaltliche perfekte Anforderungsspezifikation zu erstellen, ist das überhaupt kein Indiz für ein erfolgreiches Projekt, eine pünktliche Fertigstellung oder einen glücklichen Auftraggeber.
Viele unserer Kunden akzeptieren diese Unsicherheiten in Projekten nicht mehr und stellen sich der eigenen Herausforderung: „Das nächste Projekt soll agil aufgesetzt und durchgeführt werden.“ Doch was heißt das eigentlich? Wie geht man vor? Und was sind die Erfolgsfaktoren?
Beispiel: Wir bekommen den Auftrag, das Projektmanagement eines Logistikdienstleisters zu agilisieren. Die Zusammenarbeit zwischen dem Fachbereich und der IT soll dadurch verbessert werden. Der IT-Projektleiter, mit dem wir in den kommenden 12 Monaten zusammenarbeiten werden, erklärt uns, dass es ihm gar nicht unbedingt darum geht, schneller zu werden: „Ich brauche etwas Handfestes, damit mein Businesskunde zufrieden ist. Mein Kunde hat immer so unrealistische und schwammige Anforderungen und ist hinterher mit den Ergebnissen nie zufrieden.“
Das Verständnis unserer Kunden, was „agil“ leisten kann und was nicht, ist inzwischen sehr gut. Agile Projekte sind nicht unbedingt schneller. Aber sie liefern schneller erste Arbeitsergebnisse, mit denen man mit dem auftraggebenden Business in den Austausch gehen kann. Dadurch bekommt man eine schnelle Rückmeldung, ob die Richtung stimmt. Außerdem rücken im agilen Projektmanagement Business und Entwicklung näher zusammen und arbeiten regelmäßig und intensiv zusammen.
Einführung von agilem Projektmanagement – Wie gehen wir vor?
Wir arbeiten bei der Einführung von agilem Projektmanagement iterativ. Zuallererst vermitteln wir Basiswissen, was „agil“ im Idealfall bedeutet. Die Mitarbeiter lernen die agilen Werte und Prinzipien kennen, und wir erarbeiten mit den Teams und Verantwortlichen, wie sie diese in agilen Projekten leben wollen. Darauf aufbauend beschäftigen wir uns mit den agilen Methoden, beispielsweise SCRUM, und üben mit den Mitarbeitern die neuen Rollen ein. Wir erarbeiten gemeinsam eine Gesamtvision, die beschreibt, was die Beteiligten mit dem Produkt „Agiles Projektmanagement“ erreichen wollen:
- Wollen wir Kosten sparen?
- Wollen wir schneller werden?
- Wollen wir weniger Administration?
- Wollen wir die Zusammenarbeit verbessern?
Die Vision für die agile Transformation darf keine Vorgabe des Managements sein, sondern muss von den Mitarbeitern selbst bestimmt werden können. Sie beschreibt, wohin sich das Projektmanagement insgesamt entwickeln soll, was man beibehält, was man verbessert und was man abschafft.
Am besten gelingt die Einführung des agilen Projektmanagements, wenn es ein konkretes Projekt gibt, anhand dessen die neue Vorgehensweise verprobt werden kann. Typische Aufgaben, die wir in diesem Zusammenhang übernehmen, sind:
- Agile Coaching: sowohl Transformation als auch das konkrete Projekt im Sinne des „agile Mindset“ aktiv begleiten
- Retrospektiven leiten: sowohl für die Transformation als auch das konkrete Projekt analysieren, was gut und was schlecht läuft
- Übernahme der Scrum Master Rolle
- Support beim Aufbau der Tool Chain: Collaboration Tools (Slack, Teams, etc.), Ticket-Systeme (JIRA, etc.), Wiki Dokumentation (Confluence, etc.)
- Daily Support: Vorbereitung, Durchführung und Nachbereitung von Meetings
- Gemeinsame Erarbeitung und Dokumentation von Ideen und Konzepten: schnelle Evaluierung, Verprobung oder Umsetzung mit verschiedenen Werkzeugen wie Design Thinking, Fishbone-Diagram, etc.
Ganz ohne Projektmanagement kommen auch agile Projekte nicht aus – viele Dinge waren hilfreich und richtig für Projekte. Nur die Anwendung gestaltet sich anders. Hier einige Beispiele:
Das Scope Statement ist kein Dokument mehr, das fortlaufend durch Change Request angepasst wird. Dafür gibt es jetzt eine klare Product Vision, ein Product Backlog und eine Functional Map, aus der man Epics und User Stories ableitet, die dann im Sprint Backlog landen. Epics und User Stories werden immer nur dann detailliert beschrieben, wenn klar ist, dass sie als Nächstes umgesetzt werden sollen. Somit können Erfahrungen und Feedback fortlaufend berücksichtigt werden.
Das klassische Time Planning wird durch die Sprintplanung ersetzt, und jeder Sprint entspricht einem Meilenstein. Bei größeren Projekten benötigt man außerdem einen Abhängigkeitsplan, der die Reihenfolge der großen Blöcke, die man umsetzt – also Benefits und Functions – und deren Abhängigkeiten aufzeigt. Wichtig dabei ist, dass die Benefits, Functions und Features nicht im großen Umfang und auf lange Sicht geschätzt werden. Denn wenn Entwickler Aufgaben schätzen, können sie nicht entwickeln und regelmäßige Ergebnisse liefern. Der große zu vermittelnde Unterschied im Vergleich zu klassischen Projekten ist, dass es keinen detaillierten Zeitplan gibt, der Zusagen macht, wann ein Ergebnis geliefert wird.
Auch Cost Planning gibt es im agilen Projektmanagement, nur die Herangehensweise ist vollkommen andere: Das Budget gibt einerseits an, wieviel einem ein Produkt, bestehend aus verschiedenen Benefits, wert ist. Anderseits spiegelt das Budget die verschiedenen Rollen und Ressourcen wider, die man schätzt zu benötigen: ein Product Owner, ein Scrum Master, Entwickler, Tester, Architekten, etc. – und das Ganze beispielsweise für 18 Monate. Was man – wie beim klassischen Projektmanagement üblich – nicht mehr im Detail kalkuliert, sind die Aufwände für sämtliche Liefergegenstände und Aufgaben. Im agilen Projektmanagement kann man anhand des Entwicklungsfortschritts sehr früh erkennen, ob die Teamstärke ausreicht. Wenn man zu langsam ist und das Produkt es wert ist, erhöht man die Anzahl bestimmter Rollen und Ressourcen, zum Beispiel die Zahl der Entwickler-Teams – und damit auch das Budget.
Das Risk Management läuft ganz ähnlich wie im klassischen Projektmanagement: man identifiziert die größten Barrieren und schätzt Eintrittswahrscheinlichkeiten und Impact. Der Unterschied besteht darin, dass Gegenmaßnahmen nur dann eingeleitet und im nächsten Sprint eingeplant werden, wenn dem Risiko eine ausreichend hohe Priorität beigemessen wird. Gibt es wichtigere Aufgaben, dann verbleiben die Gegenmaßnahmen im Backlog. Werden beispielsweise in einem Projekt Security-Risiken identifiziert, die einen Live-Gang verhindern, ist klar, dass das Thema eine hohe Priorität hat und sich im nächsten Sprint jemand aus dem Team darum kümmern muss.
Erfolgsfaktoren bei der Einführung des agilen Projektmanagements
- Ein Steuerkreis, der die agilen Teams „machen lässt“: Wenn der Steuerkreis versucht, ein agiles Projekt klassisch zu steuern, ist der Aufwand möglicherweise sogar noch höher als in bisherigen Projekten. Fordert das Management altbekannte Reports ein, müssen diese aus der agilen Welt transferiert oder Schätzungen vorgenommen werden, die im agilen Projektmanagement gar nicht vorgesehen sind. Steuerungsprozesse und Reports gibt es auch in der agilen Welt, die Kunst besteht darin, die Steuerungsprozesse aufwandsarm zu gestalten und Reports auf Basis vorhandener Informationen aufzubauen.
- Ein Team, das kommuniziert und kollaboriert: Für die „alten Helden und Supercracks“, die genialen Lösungen entwickeln, indem sie sich einschließen, nicht kommunizieren und nicht interagieren, ist in der agilen Welt kein Platz mehr. Diese Experten müssen sich ändern. Sie müssen das, was sie entwickeln, für alle zugänglich dokumentieren, sich Verständnisfragen und kritischen Rückfragen stellen, mit anderen Teammitgliedern kommunizieren und sie im Idealfall befähigen. Das ist natürlich gerade beim Übergang von der klassischen in die agile Projektwelt herausfordernd. Der Austausch zwischen den Bereichen ist viel intensiver. Die frühere Vorgehensweise der Fachbereiche „Wir legen Euch ein Business Requirement Document vor die Tür, und Ihr setzt das dann um“, funktioniert nicht mehr. Die aktive Einbindung des Business in die Entwicklung durch zeitnahes Testen, die enge Zusammenarbeit und der regelmäßige Austausch (internes Kundenfeedback) sind absolut essentiell.
- Vertrauen in die Personen: Wenn ein Team sagt, “Wir schaffen das nicht“, gehen typischerweise die Diskussionen im Management los: „Warum nicht, ihr müsst das aber schaffen.“ Der Druck nimmt zu. Das ständige Hinterfragen funktioniert aber beim agilen Arbeiten nicht mehr. Das Vertrauen in das Team, seine Schätzungen, seine Wertschöpfung und vor allem seine Selbstorganisation ist eine der Grundvoraussetzungen agilen Arbeitens. Das Team schätzt, was es glaubt schaffen zu können – und dann startet der erste Sprint. Auf diese Sichtweise muss sich das Management einlassen.
- Top-Besetzung für die Kernrollen: Wenn in einem agilen Projekt beispielsweise nach der Scrum-Methode gearbeitet wird, müssen die Kernrollen „Product Owner“ und „Scrum Master“ sehr gut besetzt sein. Die Rollen an Mitarbeiter zu vergeben, die gerade verfügbar sind, wirkt sich negativ auf das Projekt aus. Der Product Owner muss jemand sein, der visionär denkt, sich nicht in Details verliert, kommunikationsstark ist und zwischen den beteiligten Stakeholdern vermitteln kann. Der Scrum Master muss organisationsstark sein, Mitarbeiter gut befähigen können und insgesamt dafür sorgen, dass es läuft. Der inhaltliche Anspruch an den Product Owner ist hoch. Früher konnte ein Projektleiter ein SAP Projekt verantworten, ohne tiefere SAP Kenntnisse zu besitzen. Heute muss der Product Owner viel tiefer in den Themen drinstecken. Er sollte beispielsweise lieber die Anatomie des Produkts und seiner Inkremente im Detail an der Wand zeichnen, weil das dem Projekt hilft und wertschöpfend ist, als seine Zeit in administrative und planerische Tätigkeiten zu stecken.
- Ein Team aus Full Time Equivalents: Die frühere Aufteilung, dass Mitarbeiter 50% in einem Projekt und 50% in einem anderen Projekt arbeiten, ist in agilen Projekten nur für wenige Rollen denkbar.
- Die agilen Werte und Prinzipien als Basis: Ohne agile Werte wie Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt funktioniert agiles Projektmanagement nicht. Die Werte und Prinzipien sind die Grundlage, auf der alle Methoden und Vorgehensweisen aufbauen.
Welche Resultate Sie erwarten dürfen
Unser Leitbild ist es, Organisationen zu unterstützen und Menschen zu befähigen, agile Projekte erfolgreich zu machen. Doch was genau macht den Erfolg aus und was verbessert sich?
- Das gegenseitige Verständnis zwischen Fachbereich und IT steigt, was der jeweilige Bereich braucht. Die beteiligten Bereiche rücken näher zusammen und es braucht keine Vermittler mehr – beispielsweise Business Consultants. Es entsteht im agilen Arbeiten viel eher ein gemeinsames Team. Kommunikation und Austausch verbessern sich und werden von Projekt zu Projekt besser.
- Der interne Kunde erhält schnelle Ergebnisse z.B. in Form von Minimum Viable Products (MVPs). Dadurch können die Beteiligten frühzeitig korrigieren, wenn das MVP in die falsche Richtung läuft.
- Durch das agile Arbeiten ergeben sich bereits vor dem ersten MVP viele Lerneffekte und Erkenntnisgewisse:
- Der interne Kunde (Fachbereich, Business) lernt, was er selbst eigentlich will. Außerdem lernt er, präziser und detaillierter zu beschreiben
- Die Entwickler lernen, was der interne Kunde von ihnen braucht. Außerdem lernen sie, was es bedeutet, „on Demand“ zu entwickeln
- Die Designer lernen, wie das Produkt ankommt
Durch die Interaktion der Beteiligten kann ein Design gefunden werden, das dem internen Kunden gefällt und das die Entwickler gut und schnell umsetzen können.
- Ändern sich die Anforderungen der internen und externen Kunden, sind agile Projekte viel eher dazu in der Lage, den eingeschlagenen Pfad zu verlassen und eine neue Richtung zu nehmen. Während in klassischen Projekten Produktanpassungen eine Qual für jeden Projektleiter waren, freuen sich agile Teams über fortlaufende Produktverbesserungen.
- Das gesamte Projektteam ist auf Wertschöpfung eingestellt. Im Gegensatz zu administrativen und planerischen Tätigkeiten präferieren die Teammitglieder Aufgaben, die das Projekt voranbringen.
Besprechen Sie Ihr Vorhaben mit uns:
06 Agile Führung
Unsere Managementwelt hat sich verändert. Seitdem es #facebook, #google und #spotify gibt, fürchten sich die DAX-Unternehmen vor der #disruption im Rahmen der #digitalisierung. Also fliegen sie ins #siliconvalley, um sich dort inspirieren zu lassen, von der #failureculture und dem #spirit.
Wieder in Deutschland, schmeißen sie ihre Krawatten weg, tragen Sneakers und duzen ihre Angestellten. Und die sollen jetzt bitte vor allem eins sein: #agile.
Seien wir ehrlich – viele können die Buzzwords nicht mehr hören. Die Veränderungsgeschwindigkeit am Markt übersteigt die der Unternehmen in den Augen vieler Mitarbeiter um ein Vielfaches. Seit der Einführung des iPhones 2008 wurden mehrere Millionen von Apps entwickelt. Alleine Pokémon Go hatte innerhalb von 15 Tagen 50 Millionen Nutzer – und das ist schon über zwei Jahre her. Wie alt mag da das Agile Manifest von 2001 erscheinen – das in etwa gleichzeitig mit dem iPod veröffentlicht wurde?
Was sollten Führungskräfte also angesichts dieser Entwicklungsgeschwindigkeit tun? Business as usual und hoffen, dass es vorübergeht? Oder sollten sie mit auf den Zug springen und sich möglichst schnell fit in digitalen Themen machen, um die Augenhöhe mit ihren Mitarbeitern nicht zu verlieren? Muss ich als Führungskraft erklären können, warum IOTA eigentlich keine Blockchain ist und wie viele Zustände ein Qubit einnehmen kann?
Die gute Nachricht: Das ist nicht notwendig. Führung im digitalen Zeitalter dreht sich vielmehr um Menschen als um Technologie.
Leadership 4.0 – Es geht um Menschen, nicht um Maschinen
Als disruptive Treiber der Digitalisierung werden immer wieder die technologischen Megatrends wie Künstliche Intelligenz, Blockchain oder das Internet der Dinge genannt. In seiner Late-Night-Show „Last Week Tonight“ brachte der Comedian John Oliver seine Verunsicherung von Bitcoin und Co. auf den Punkt: “Crypto currency: Everything you don’t understand about money combined with everything you don’t understand about computers.” (John Oliver, Last Week Tonight vom 12. März 2018)
Was also ist so disruptiv an einer Technologie, die nur wenige im Detail verstehen? Schauen wir uns die Menschen hinter Blockchain an. Der Erfinder von Bitcoin ist bis heute unbekannt, sehr wohl bekannt ist jedoch der Erfinder der zweitgrößten Blockchain, Ethereum, Vitalik Buterin. Der 24-jährige Kanadier mit russischen Wurzeln beschreibt auf seiner about.me-Seite, wie er zu Kryptowährungen fand: “I was born in 1994 in Russia and moved to Canada in 2000, where I went to school. I happily played World of Warcraft during 2007-2010, but one day Blizzard removed the damage component from my beloved warlock‘s Siphon Life spell. I cried myself to sleep, and on that day I realized what horrors centralized services can bring. I soon decided to quit. In 2011, searching for a new purpose in life, I discovered Bitcoin.” (https://about.me/vitalik_buterin)
Etwas spitz formuliert: Ein 17-jähriger Teenager, entwickelt in seinem Jugendzimmer eine bahnbrechende Technologie, die den Finanzsektor durcheinanderwirbelt, weil eine Funktion aus seinem Lieblings-Computer-Spiel entfernt wurde. Die Technologie, die es ermöglicht, dass eine einzige Idee ganze Märkte maßgeblich beeinflusst ist das Internet. Damit sind die über 3 Milliarden Internetnutzer potenzielle Wettbewerber der heutigen Unternehmen – Menschen, die keine Fabriken besitzen, die keine Anzüge tragen und die zum Teil nicht einmal einen Schulabschluss haben. Die einfach so sind, wie sie sind und die für eine Sache brennen und durch ihre Begeisterung Innovationen entwickeln – nicht erst in Zukunft, sondern schon heute.
Moderne Führungskräfte schaffen eine Umgebung, in der genau diese innovative Energie fließen kann – damit innovative Ideen innerhalb des eigenen Unternehmens entstehen können – durch Empowerment der Mitarbeiter, Förderung einer Ausprobier- und Lernkultur und aktiver Weiterentwicklung des eigenen Führungsteams.
Wie Führungskräfte Mitarbeiter am besten unterstützen
Schaut man sich moderne Organisationen an – seien es holokratisch organisierte oder die von Laloux in seinem Bestseller „Reinventing Organizations“ beschriebenen Unternehmen, kann man sich als Führungskraft durchaus die Frage stellen, wo in diesen Organisationen denn noch Platz für Führungskräfte ist.
Zunächst einmal möchten wir eine klare Empfehlung aussprechen, was Führungskräfte nicht tun sollten – und das ist, die Rolle des Product Owners oder des Scrum Masters zu übernehmen. Ein häufiger Fehler bei agilen Transformationen ist, die bestehende Hierarchie einfach 1:1 in die neue Organisationsform zu überführen. Der Product Owner ist weiterhin „der Chef“, der über Priorisierung und Inhalt der jeweiligen Sprints bestimmt. Das Scrum Team ist dann nur ausführende Kraft. So bekommen die Teams modernere Namen – sei es Scrum Team, Squad oder Tribe, nur an der Verantwortung ändert sich nichts. Ganz im Gegenteil. Häufig nimmt die fachliche Verantwortung der Führungskräfte dadurch zu, sie werden zum Flaschenhals und kommen nicht dazu, zusätzlich zu ihren bisherigen Management-Themen (die häufig nicht wegfallen) auch noch die notwendige Zeit für ihre fachlichen Themen aufzubringen. Statt der erhofften Produktivitätssteigerung wird die neue Organisation langsamer und das Thema Agilität ist für viele Menschen verbrannt. Was sollten Führungskräfte also stattdessen tun?
Es gibt sie noch, die Management-Aufgaben!
Eine große Aufgabe für Führungskräfte ist, gemeinsam mit ihren Mitarbeitern die Organisation neu zu gestalten und zu entscheiden, welche Aufgaben und Themengebiete überhaupt Agilität benötigen und bei welchen Aufgaben und Themengebieten Stabilität und Prozessexzellenz gefragt sind.
Diese Form der Organisation wird häufig als Organisationale Ambidextrie oder Duales Betriebssystem beschrieben. Tatsächlich ist das ganz logisch – nicht alle Mitarbeiter müssen den ganzen Tag hochinnovativ komplexe Aufgaben lösen. Manche Prozesse müssen auch einfach laufen, ohne dass man sie jeden Tag neu erfindet. Ganz im Gegenteil: Je eingespielter diese Prozesse laufen, umso stärker lässt sich die Effizienz steigern. Diese Prozesse lassen sich dann, wenn sinnvoll, schrittweise digitalisieren. Zunächst müssen sie aber standardisiert und optimiert werden – klassisches Management und eine wertvolle Aufgabe für Menschen, die gerne in stabilen Umfeldern arbeiten.
Befähigung zur Verantwortungsübernahme
Selbstorganisation bedeutet vor allem, Verantwortung für sich selbst, das Team, Entscheidungen und Ergebnisse zu übernehmen. Auch wenn man selbst entscheiden darf, verspüren viele Mitarbeiter das Bedürfnis, sich zusätzlich abzusichern.
Es ist eine zentrale Aufgabe eines Agile Leaders, sein Team zu befähigen, selbst Verantwortung zu übernehmen. Ein häufiger Fehler hierbei ist, von einem Tag auf den anderen die gesamte Verantwortung auf einmal abzugeben – das scheitert meistens, auch weil die Mitarbeiter gar nicht in der Lage sind, alle Entscheidungen selbst zu treffen. Meistens liegen ihnen gar nicht alle Informationen vor, da sie nicht in denselben Gremien sitzen, wie die Führungskräfte.
Eine gute Maßnahme besteht darin, Task für Task mit den jeweiligen Mitarbeitern zu besprechen, inwieweit die Führungskraft noch zu involvieren ist und dies schrittweise zu verändern.
- So kann die Führungskraft die Mitarbeiter zum Beispiel zuerst nach ihrer Meinung fragen, die Entscheidung am Ende aber selbst treffen.
- Im nächsten Schritt kann man das umkehren – die Führungskraft teilt den Mitarbeitern ihre Meinung mit, überlässt ihnen aber die Entscheidung.
- Ein weiterer Schritt ist, nur noch für Fragen der Mitarbeiter zur Verfügung zu stehen, bis diese sich die notwendige Entscheidungskompetenz selbst erarbeitet haben – inklusive der notwendigen Informationsquellen und die Entscheidung nun selbst komplett treffen können.
- Die Führungskraft ist im letzten Schritt nicht einmal mehr zu informieren – die Entscheidung ist komplett zur Sache der Mitarbeiter geworden.
Wie dieser Prozess von statten geht und wie lange es dauert, die letzte Stufe zu erreichen – und ob diese überhaupt erwünscht und sinnvoll ist – hängt ganz vom jeweiligen Task und den jeweiligen Mitarbeitern ab.
Eine Grundlage hierfür ist natürlich, den Mitarbeitern aktiv alle Informationen zur Verfügung zu stellen, die sie für eine effiziente Entscheidungsfindung benötigen – auch wenn Führungskräfte dadurch keinen Informationsvorsprung mehr gegenüber ihren Mitarbeitern haben. Das kann für diejenigen Führungskräfte hart sein, die bisher einen Teil ihrer Kompetenz daraus abgeleitet haben, einfach über mehr oder andere Informationen zu verfügen als ihre Mitarbeiter.
Schaffen einer angstfreien Umgebung, in der es sicher ist, Fehler zuzugeben
„Aus Fehlern lernt man“, „Fail Fast, Fail Cheap“ – Fehler sind scheinbar modern wie nie. Ist das wirklich so? Zählt am Ende nicht doch nur der Erfolg? Jemand, der jahrelang alles getan hat, damit die Zahlen stimmen oder das Projekt auf „grün“ ist und damit Erfolg hatte, wird nun Fehler nur schwer zugeben – und tatsächlich ist auch nicht jeder Fehler ein Grund zu feiern.
Vermeintliche Fehler helfen uns dann, wenn wir dadurch etwas Neues lernen und das Gelernte beim nächsten Mal erfolgreich anwenden. Das Ziel sollte also eher eine Ausprobierkultur sein, als eine Fehlerkultur. Darüber hinaus hilft es, offen zu den eigenen Schwächen zu stehen, damit man die eigene Energie am effizientesten einsetzen kann – und dabei noch mehr Spaß bei der Arbeit hat. Was heißt das nun konkret für Führungskräfte?
Zunächst einmal ist das Thema eine Fehler- oder Ausprobierkultur, bei dem die Führungskräfte den größten Impact haben, wenn sie als gutes Beispiel vorangehen. Stellen Sie sich bei der nächsten Fuck-up-Night auf die Bühne, geben Sie offen zu, welche Tätigkeiten ihnen schwerfallen und holen sie sich hierfür die entsprechende Unterstützung und sagen sie offen, wenn sie etwas nicht wissen. Wieso sollte sich ein Mitarbeiter als „nicht perfekt“ outen, wenn die eigene Führungskraft doch scheinbar alles immer richtigmacht? Mitarbeiter müssen erleben, dass ihnen bei einem Fehler nicht der Kopf abgerissen wird – am besten indem sie dies bei einer anderen Person beobachten.
Schaffen Sie darüber hinaus Strukturen, in denen Fehler angesprochen und aus ihnen gelernt werden darf. Bei Scrum sind das zum Beispiel die regelmäßigen Reviews und Retrospektiven. Oft fehlt scheinbar einfach nur der richtige Zeitpunkt, um etwas anzusprechen. Und je länger man einen Fehler verschweigt, umso schwerer fällt es, diesen zuzugeben. Man muss sich im Alltag aktiv Zeit hierfür nehmen!
Führungskräfte haben hierbei die zentrale Aufgabe, diese neu geschaffenen Strukturen gegenüber anderen Stakeholdern im Zweifel zu verteidigen – das heißt zum Beispiel den Mitarbeitern Zeit und Raum hierfür einzuräumen.
Führung ist Teamsport
Nicht zuletzt bedeutet eine agile Transformation für das Führungsteam, sich anders aufzustellen. Wenn auf Mitarbeiterebene Silos durchbrochen und bereichsübergreifend zusammengearbeitet werden soll, wirkt sich das auch auf die Führungsbeziehungen aus. Wer gibt wem Feedback und wer hat überhaupt Beobachtungspunkte zum jeweiligen Mitarbeiter?
Durch die bereichsübergreifende Zusammenarbeit werden auch Unterschiede im Führungsverhalten transparenter. Das ist per se nicht schlimm – schließlich sind Menschen und auch Führungskräfte nun einmal unterschiedlich. Verheerend ist es jedoch, wenn einzelne Führungskräfte in ihrem Verhalten gegen gemeinsam definierte Werte verstoßen oder sich selbst nicht an das halten, das sie einfordern.
Umso wichtiger ist es für das Führungsteam, sich nicht nur auf agile Methoden und Tools zu einigen, sondern sich ganz bewusst für Prinzipien und Werte zu entscheiden – inklusive eines gemeinsamen Verständnisses und dem aktiven Leben dieser Prinzipien und Werte. Hierfür eignen sich zum Beispiel die Scrum-Werte Commitment, Mut, Fokus, Offenheit und Respekt.
Diese Werte im Arbeitsalltag zu berücksichtigen ist wichtiger als Dailies und Kanban-Boards. Wie lernt man, nach diesen (oder selbst definierten) Werten zu leben und sie erfolgreich anzuwenden? Nun, am besten agil! Im Rahmen von Leadership-Sprints sollte sich das Führungsteam regelmäßig Maßnahmen vornehmen, diese umsetzen und im Anschluss Umsetzung und Zusammenarbeit im Rahmen von Reviews und Retrospektiven überprüfen – und daraus für den nächsten Sprint lernen. Die Mitarbeiter werden es zu schätzen wissen, dass auch ihre Führungskräfte offen dafür sind, dazuzulernen.
Vom Meister zum ewigen Anfänger – auch als Führungskraft
Zusätzlich zu den sehr konkreten Schritten hin zur agilen Führung, spielt insbesondere das Mindset der Führungskräfte eine zentrale Rolle.
Das Wort “Manager” hat denselben Ursprung wie das Wort “Manege” und das sagt schon eine Menge über das bisherige Führungsverständnis aus: Mit Zuckerbrot und Peitsche – je nach Führungsstil mehr von dem Einen oder dem Anderen – dressierte der Manager seine Mitarbeiter dazu, die Aufgaben optimal zu erledigen. Zum Glück haben viele moderne Unternehmen sich schon von diesem Führungsgedanken verabschiedet. Mittlerweile wurde „Management“ häufig durch Leadership ersetzt – der von sich aus motivierte Mitarbeiter soll befähigt werden, auf eigene Weise das Ziel zu erreichen. Der Leader gibt die Richtung vor und motiviert seine Mitarbeiter für das gemeinsame Ziel. Was ist nun also der Unterschied zu „Agile Leadership“ und wofür braucht man das?
Egal mit welchem Menschenbild man bisher seine Führungstätigkeit ausführte – in der Regel konnten sich Mitarbeiter auf eines verlassen: Die Führungskraft weiß, was richtig und was falsch ist. In unserer immer komplexer werdenden Welt, gilt diese Regel nicht mehr. Wer weiß schon, welcheEntscheidung in der VUCA-Welt die richtige ist und was ich unbedingt lernen muss, um auch morgen noch einen sicheren Arbeitsplatz zu haben? Einfache, sich häufig wiederholende Tätigkeiten werden immer mehr von Maschinen übernommen. Übrig bleiben die Tätigkeiten, bei denen man sich sehr schnell an sich ändernde Umstände anpassen muss – agil eben. Entweder, weil man gar nicht wissen kann, was richtig und was falsch ist und nur über Ausprobieren und Lernen erfolgreich zum Ziel kommt. Oder, weil die Tätigkeit an sich zwar nicht sehr komplex ist, der technische Fortschritt jedoch so schnell voranschreitet, dass sich zum Beispiel eine Software schnell verändert. Wer da ein halbes Jahr lang ein bestimmtes Programm nicht bedient hat, muss die Bedienung komplett neu erlernen. Kevin Kelly beschreibt das in seinem Bestseller „The Inevitable“ folgendermaßen:
„No matter how long you have been using a tool, endless upgrades make you into a newbie – the new user often seen as clueless. In this era of “becoming,” everyone becomes a newbie. Worse, we will be newbies forever. That should keep us humble.” (Kevin Kelly „The Inevitable“, 2016)
Nicht nur das ewige Lernen in einem Berufsfeld stellt Mitarbeiter und Führungskräfte vor eine Herausforderung. Laut Weltwirtschaftsforum werden je nach Industrie 50% der heutigen Berufe in acht Jahren nicht mehr existieren. Gleichzeitig werden 65% der Kinder, die heute zur Schule gehen, einen Beruf haben, den wir heute noch nicht kennen. (Weltwirtschaftsforum 2016) Re-Skilling, also das Erlernen von komplett neuen Fähigkeiten, das Sich-Erschließen komplett neuer Themengebiete wird zunehmend wichtiger als das reine „Upskilling“, auf das die meisten bisherigen Weiterbildungsmöglichkeiten bauen, mit dem Ziel, Menschen in ihrem aktuellen Job besser zu machen.
Lebenslanges Lernen und Flexibilität sind das Paradies für neugierige Menschen, die sich nicht am Anfang ihres Berufslebens festlegen möchten. Was ist aber mit denjenigen, die jahrelang in Systemen aufgewachsen sind, die es belohnt haben, wenn man feste Kompetenzlevel erfüllt? Die diejenigen befördert haben, die perfekt in eine Schablone gepasst haben? Oder zumindest diejenigen, die erfolgreich so getan haben, als ob? Woher nehme ich als Führungskraft meine Daseinsberechtigung, wenn ich nicht mehr weiß, als meine Mitarbeiter?
Die Veränderung hin zu einer agilen Unternehmensstruktur stellt insbesondere Führungskräfte vor große Herausforderungen – auch deshalb, weil agile Methoden meistens gar keine expliziten Führungsrollen vorsehen. Es erfordert ein starkes Selbstbewusstsein, sich auf diese Veränderung einzulassen – und entsprechendes Change Management. Deshalb ist es unverzichtbar, die Führungskräfte auch in diesen Themen zu fördern und nicht einfach zu versuchen, ihnen einen neuen Führungsstil „beizubringen“.
Der hohe Change Impact von agilen Transformationen
Häufig wird bei agilen Transformationen das Change Management außen vor gelassen. Zu klar scheint der Need for Change – wer will schon so führen wie die Großfabrikanten des 19. Jahrhunderts?
Zudem klingt agiles Arbeiten nach einer Menge Spaß – Planning Poker, Fuck-Up-Nights und Hackathons werden begleitet von moderner Bürogestaltung und flexiblem Arbeiten. Ist das nicht der Change, auf den wir alle jahrelang gewartet haben? Wozu braucht man da Change Management? Anders gefragt: Wenn es so einfach ist, warum scheitern dann so viele agile Transformationen?
Auch Führungskräfte durchlaufen die bekannte Change Kurve und reagieren mit Verunsicherung auf Veränderungen. Bringe ich die notwendigen Fähigkeiten mit? Was ist mit meinem Verantwortungsbereich, muss ich Kompetenzen abgeben? Wie sieht meine zukünftige Rolle als Führungskraft aus? Werden mich meine Mitarbeiter weiterhin respektieren? Führungskräfte reagieren auf Veränderungen genauso mit Schock und Trauer, wie andere Mitarbeiter auch.
Bisherige Skillprofile boten einen klaren Rahmen, welche Fähigkeiten man für welche Tätigkeiten mitbringen musste. Diese Sicherheit fällt nun weg, bietet aber auch die Chance, sich endlich auf die eigenen Stärken konzentrieren zu können, statt sich in fixe Schablonen zu pressen. Dazu muss man jedoch wissen, wer man ist, was man kann, aber auch wer man nicht ist und was man nicht kann. Zu den eigenen Stärken und Schwächen zu stehen, ist in vielen Organisationen eine komplett neue Verhaltensweise, die stark verunsichern kann. Wie viel Schwäche ist erlaubt, ab wann verstößt man gegen die Regeln des Systems, in dem man ja immer noch arbeitet?
Erst wenn Führungskräfte diesen Change für sich selbst gemeistert haben, können sie ihre Mitarbeiter durch die Veränderung begleiten und authentisch erklären, was mit vermeintlichen Buzzwords wie „fail fast“ gemeint ist. Um sich auf die Veränderung einzulassen, müssen sie ihren eigenen Führungskräften vertrauen können. Es reicht nicht, nur auf den unteren Managementebenen ein neues Führungsverständnis zu fordern und zu erlauben.
Hierfür ist es unter anderem notwendig, dass das Top Management eine gemeinsame Change Story vertritt – und wirklich hinter dieser steht. Lippenbekenntnisse werden schnell durchschaut. Jedes Mitglied des Top Managements muss glaubhaft erklären können, warum ein neuer Führungsstil notwendig ist, welche Vorteile dieser bringt, was das für die Organisation genau bedeutet und wie die Organisation zum Ziel gelangt.
- Was bedeutet „fail fast, fail cheap“ bei uns?
- Was verstehen wir unter Innovationen?
- Wie viel Zeit nehmen wir uns für Führung?
- Wie und wie oft geben wir uns Feedback?
- Wie gehen wir mit den individuellen Stärken-/ Schwächenprofilen von Mitarbeitern um?
- Wer darf was selbst entscheiden?
- Wer wird befördert und warum?
- Welche Karrierepfade bieten wir unseren Mitarbeitern an?
- Was ist das, dieses agile Führung?
Selbstverständlich reicht es nicht, nur ein gemeinsames Verständnis zu haben – die jeweilige Führungskraft – auch im oberen Management – muss als gutes Beispiel vorangehen, das neue Führungsverhalten aktiv anwenden und sich regelmäßig Feedback zu ihrem Führungsstil geben lassen.
Der Weg zu einer agilen Organisation wird so zu einer spannenden Reise für alle Beteiligten, die eine Menge Chancen bietet.
Besprechen Sie Ihr Vorhaben mit uns:
07 OKR als Beispiel für agile Methoden
Was ist OKR?
Der Begriff OKR steht für „Objectives and Key Results“. OKR ist eine agile Führungsmethode, die sich primär aus den drei Kernelementen Messbarkeit, Flexibilität und Transparenz zusammensetzt.
Messbarkeit
Die Objectives beschreiben die angestrebten Unternehmensziele. Die Key Results ermöglichen es, jedes Objective messbar zu machen. Sie beschreiben, wie ein Objective erreicht werden soll.
Flexibilität
Objectives und Key Results werden typischerweise quartalsweise formuliert. Dadurch legen Unternehmen mehrmals im Jahr ihren Fokus fest und können sich so in kürzeren Abständen an veränderte Rahmenbedingungen anpassen.
Transparenz
Die Objectives und Key Results des Unternehmens sind für alle Führungskräfte und Mitarbeiter einsehbar. Die OKRs von jedem Team und jedem einzelnen Mitarbeiter werden dann mit denen des Unternehmens verbunden. Zum Schluss herrscht Klarheit darüber wer mit seinen Zielen an welcher Stelle zum Erfolg des Unternehmens beiträgt.
Wer hat sich OKR ausgedacht?
Der Begriff OKR wird eng mit dem Silicon Valley und den Erfolgsgeschichten von Google, Facebook, LinkedIn und Dropbox in Verbindung gebracht. Der Ansatz ist jedoch älter als die meisten dieser Unternehmen. Ursprünglich wurde das Framework in den Siebziger Jahren bei Intel das erste Mal als erweitertes Management by Objectives (MbO) Konzept von Intel CEO Andy Grove angewendet. Grove wollte durch seine Weiterentwicklung von MbO sicherstellen, dass bei Intel der Fokus auf den wichtigsten Zielen liegt. John Doerr brachte das Framework von Intel dann 1999 in seiner Position als Investor zu Google. Die Google-Gründer Larry Page und Sergey Brin übernahmen das Framework nicht 1:1, sondern erweiterten es noch einmal um einen weiteren Grundstein: Die Messbarkeit des Fortschritts (Progress).
Warum sind OKRs wichtig?
Die Unternehmensvision ist typischerweise ein kurzer, prägnanter Satz, der beschreibt, wohin die Reise geht. Für viele Mitarbeiter – und selbst Führungskräfte – ist sie aber ziemlich vage. Das OKR-Framework bietet Unternehmen die Möglichkeit, die Vision zu konkretisieren und für alle Mitarbeiter verständlicher zu machen. Das schafft Transparenz, was sich hinter der Vision verbirgt und welche Ziele und Aufgaben sich daraus ergeben. Es beantwortet außerdem die Frage, wie jeder Mitarbeiter einen Mehrwert für das Unternehmen liefern kann.
Der Purpose beschreibt warum wir morgens aufstehen und tun was wir tun. Die Vision sagt uns, wohin wir wollen. Objectives beschreiben die qualitativen Ziele – also, was wir im Detail erreichen wollen. Die Key Results quantifizieren die jeweiligen Objectives. Sie sind Erfolgstreiber, machen den Fortschritt messbar und beschreiben, wie wir unsere Ziele erreichen wollen.
OKRs fördern das agile Mindset
Die Kultur jedes Unternehmens lässt sich durch drei Schichten beschreiben: Die oberste Schicht (Verhaltenskultur) beschreibt die nach außen sichtbaren Verhaltensweisen der Mitarbeiter. Die mittlere Schicht (Wertekultur) enthält die kollektiven Werte und Normen im Unternehmen, die zu den gelebten Verhaltensweisen führen. Die unterste Schicht (Organisationsstruktur) ergibt sich durch die vorhandenen Prozesse, Organigramme und Regeln im Unternehmen.
Veränderungen wirken von der unteren Schicht nach oben. Das bedeutet: Um die Wertekultur und letztendlich die Verhaltenskultur eines ganzen Unternehmens positiv zu beeinflussen, muss die Organisationsstruktur verändert werden. Das OKR-Framework zur Mitarbeiterführung hat hierbei einen großen Vorteil im Vergleich zu anderen agilen Methoden wie SCRUM oder Design Thinking: es setzt auf der Organisationsebene an und nimmt dadurch Einfluss auf das Werteverständnis aller Mitarbeiter. Durch die Veränderungen der Organisationsstruktur können agile Werte wie Vertrauen, Selbstorganisation, Transparenz und Ansätze wie Minimal Viable Product (MVP) in der Wertekultur des Unternehmens verankert werden. OKRs helfen dadurch, agile Arbeitsweisen wie SCRUM nachhaltig zu etablieren: SCRUM Teams können uneingeschränkt der Methode folgen und müssen ihr neues Werteverständnis nicht tagtäglich aufs Neue rechtfertigen. Denn die höheren Hierarchieebenen und benachbarten Abteilungen arbeiten nun nach den gleichen agilen Grundprinzipien.
Unsere OKR Leistungen: Wie wir Sie unterstützen
OKRs bilden das Fundament für die Etablierung agiler Werte in der gesamten Unternehmenskultur. Für die Einführung der OKRs wird folgendes benötigt:
- Eine gute Planung
- Ein auf die Unternehmensbedürfnisse angepasstes Framework
- Die Befähigung und Vorbereitung aller Mitarbeiter
OKRs verändern Werte des Unternehmens und die Denkweisen der Mitarbeiter, und diesen Change gilt es professionell zu begleiten. Wir unterstützen Unternehmen in allen strategischen und operativen Schritten bei der Implementierung des OKR-Frameworks – von der Analyse des Status Quo bis zur Begleitung der ersten OKR Zyklen. Unser Schwerpunkt liegt darauf, die Mitarbeiter mit dem OKR-Framework vertraut zu machen und dafür zu begeistern, damit agile Denkstrukturen nachhaltig in den Arbeitsalltag integriert werden können und Teil der Kultur werden. Durch unser Change Know-how stellen wir sicher, dass die OKR-Philosophie von den beteiligten Mitarbeitern positiv aufgenommen und gelebt wird.
1. Analyse des Status Quo
- Analyse der aktuellen Situation im Unternehmen, in den Abteilungen und in den Teams
- Abstimmung der mit der Einführung der OKRs angestrebten Ziele
2. Vision und OKRs definieren
- Erarbeitung der übergreifenden Vision und Nutzung von kreativen Workshop-Methoden
- Gemeinsame Erarbeitung der OKRs
3. Den OKR-Zyklus aufsetzen
- Aufsetzen eines vierteljährlichen Zyklus mit den notwendigen Prozessen, Rollen, Templates und Tools
4. Mitarbeiter für individuelle OKRs befähigen
- Heranführung der Mitarbeiter an das Thema OKR und Schaffung von Verständnis
- Methodische Befähigung und Training
- Persönliches Coaching on Demand
5. Mitarbeiter auf die OKRs fokussieren
- Schaffung regelmäßiger Ankerpunkte
- Begleitung der Mitarbeiter bei der OKR-Definition, damit individuelle Ziele, Teamziele und Unternehmensziele durchgängig miteinander verknüpft sind
6. Fortschritt messen, steuern und dokumentieren.
- Begleitung des OKR-Zyklus als OKR-Master und -Office
- Schaffung von Transparenz über Status und Fortschritt
- Moderation von Status-Updates und Retrospektiven
- Dokumentation
OKR-Vorteile, die wir gemeinsam mit unseren Kunden erzielen:
Transparenz: Mit Hilfe von OKRs sieht man, womit sich die Mitarbeiter im Unternehmen beschäftigen und welche Fortschritte sie erzielen. Durch die gewonnene Transparenz werden Kollaboration sowie Kommunikation über Erfolge und Probleme gefördert.
Fokussierung: Auch die Limitierung auf maximal 5 Objectives fördert den Austausch, worauf sich die Mitarbeiter in den nächsten Wochen konzentrieren und in welche Richtung sie ziehen möchten. Die Kommunikation findet nicht mehr nur auf der Führungsebene, sondern gemeinsam mit allen Mitarbeitern statt. Das stärkt das „WIR-Gefühl“.
Beitrag zum Unternehmensziel: Während traditionell Ziele Top-down heruntergebrochen und delegiert werden, lernen die Mitarbeiter mit Hilfe von OKRs, ihren Zielbeitrag eigenständig zu identifizieren. Jeder setzt sich damit auseinander, welchen Mehrwert er mit seiner Arbeit für das übergeordnete Ziel erzielen kann.
Eigene Stärken einbringen: Das OKR-Framework bietet Mitarbeitern die Möglichkeit dort zu unterstützen, wo ihre Stärken und Interessen liegen. Dadurch steigen die intrinsische Motivation und die Identifikation mit dem Unternehmen. Mitarbeiter folgen nicht mehr Befehlen, sondern mobilisieren ihre persönlichen Stärken.
Quartalsweise Anpassungen: Durch den kurzen Zyklus von 3 Monaten und die Offenheit für Anpassungen an den Key Results bleibt das Unternehmen flexibel. Zu Beginn jedes Quartals setzten sich alle Mitarbeiter erneut mit der Frage auseinander, welche Themen im nächsten Zyklus relevant sind. Die Mitarbeiter beschäftigen sich kontinuierlich mit den Erfolgen und Herausforderungen ihres Unternehmens.
Ambitionierte Ziele: Ziele werden im OKR-Framework ambitioniert und herausfordernd gesteckt – auf Unternehmens-, Team- und Mitarbeiterebene. Die Mitarbeiter lernen, mit ambitionierten Zielen umzugehen. Schon ein Erreichungsgrad von 60-70% gilt als Erfolg. Wenn Ziele nicht erreicht werden, setzen sich die Teams mit den Ursachen auseinander und lernen daraus für den nächsten Zyklus.
Besprechen Sie Ihr Vorhaben mit uns:
08 Scrum als Beispiel für agile Methoden
Scrum nach Scrum Guide™
Die folgenden Informationen basieren auf dem Scrum Guide™, angereichert mit praktischen Erfahrungen unserer Berater.
Das Scrum Framework besteht aus Scrum Teams und den zugehörigen Rollen, Events, Artefakten und Regeln. Jede Komponente innerhalb des Frameworks hat einen bestimmten Zweck und ist entscheidend für den Erfolg von Scrum und seine Nutzung.
Scrum ist
- leichtgewichtig
- einfach zu verstehen
- schwierig zu meistern
Rollen
- Product Owner – „Der Gestalter“
- Scrum Master – „Der Moderator“
- Development Team – „Die Schöpfer“
Artefakte
- Produkt Backlog – Alle Funktionen des Zielprodukts
- Sprint Backlog – Alle Produktmerkmale, die während des Sprints erstellt werden sollen.
- Inkrement – Potenziell releasefähiges Produktteil
- Definition of Done – Wenn das Produkt einsatzbereit ist.
Events
- Sprint Planning – Priorisieren und definieren von Features, die im Sprint erstellt werden sollen
- Daily Scrum – Kontinuierliches Informieren der Teammitglieder über die Fortschritte
- Sprint Review – Präsentieren der Arbeitsergebnisse des Sprints
- Sprint Retrospektive – Reflektieren des Arbeitsstils des Teams
Scrum Theorie
SCRUM ist eher ein Rahmenwerk als ein Prozess oder eine Technik und ist die populärste von vielen agilen Methoden. Menschen können komplexe adaptive Probleme angehen und gleichzeitig produktiv und kreativ Produkte mit dem größtmöglichen Wert liefern. Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und Risikokontrolle. Es basiert auf der empirischen Prozessteuerung oder kurz „Empirie“ – Wissen basiert auf Erfahrung und Entscheidungen werden auf der Grundlage des Bekannten getroffen.
SCRUM wird von drei Säulen getragen:TRANSPARENZ
Alles rund um das Projekt ist für jeden sichtbar. Alle Beteiligten sehen und verstehen wirklich, was während eines Sprints geschieht und können vorhersagen, was beim nächsten Sprint geschehen wird. Vermehrte Kommunikation und gegenseitiges Vertrauen helfen dem Team, gemeinschaftlich für das gemeinsame Ziel zu arbeiten.ÜBERPRÜFUNG
Das gesamte Scrum Team muss regelmäßig alle Projektvariablen wie Prozesse, Techniken, Produkte, Teameinstellungen usw. überprüfen, um unerwünschte Abweichungen vom Sprintziel zu erkennen.ANPASSUNG
Basierend auf den Ergebnissen der Inspektionen werden alle Projektvariablen zur kontinuierlichen Verbesserung angepasst. Eine Anpassung muss so schnell wie möglich vorgenommen werden, um weitere Abweichungen zu minimieren und letztlich den Geschäftswert des Produkts zu maximieren.
Scrum Werte
Mut ist eine Eigenschaft des Geistes, die es dir ermöglicht, Gefahren oder Schmerzen zu begegnen, ohne Angst zu zeigen. Es braucht Mut, Probleme aufzudecken, Hindernisse zu erkennen, um Hilfe zu bitten, Hilfe zu erhalten und Hilfe anzubieten.
Offenheit zeichnet sich durch eine Haltung der Zugänglichkeit aus, ohne zu verbergen oder geheim zu sein. Jeder sollte während einer Scrum-Implementierung alles über die Arbeit wissen.
Respekt bezeichnet sowohl eine positive Einstellung gegenüber einer Person oder einer anderen Entität als auch ein authentisches Verhalten gemäß dieser Wertschätzung. Ohne Respekt gäbe es ein hohes Potenzial an Fehlkommunikation, eine niedrige Kommunikationsfrequenz und verletzte Gefühle.
Fokus ist die Konzentration der Aufmerksamkeit. Menschen, die nicht fokussiert sind, schenken keine Aufmerksamkeit in irgendeiner sinnvollen Weise und können nicht bis zu einem sinnvollen Grad an Tiefe lernen.
Commitment bedeutet, sich an eine Handlungsweise zu binden. Wenn Menschen sich nicht festlegen können, werden sie sich im Schwebezustand des Nichtstun befinden, ein Zustand der Untätigkeit.
Scrum-Prozess
Scrum Rollen & Verantwortlichkeiten
Product Owner
… ist dafür verantwortlich, sich mit den verschiedenen Stakeholdern abzustimmen. Das gesamte Unternehmen muss seine Entscheidungen respektieren.
… sollte über volle Entscheidungsbefugnis verfügen, um das Risiko unnötiger Verzögerungen zu reduzieren.
… ist die einzige Person, die Anforderungen an das Development Team stellt.
… ist die einzige Person, die die Befugnis hat, den Sprint abzusagen.
… könnte das Management des Product Backlogs an das Development Team delegieren, bleibt jedoch immer rechenschaftspflichtig.
Product Backlog
- Erstellung, Pflege und Beschreibung des Product Backlogs
- Priorisierung der Product Backlog-Einträge
- Sicherstellen, dass der Product Backlog transparent und sichtbar ist.
- Sicherstellen, dass das Development Team das richtige Verständnis für den Product Backlog hat Items
Sprint Planning
- Besprechung des Ziels, die das Scrum-Team im Sprint erreichen soll
- Unterstützung bei dem Verständnis der ausgewählten Items aus dem Product Backlog und Herstellung von Kompromissen.
Sprint Review
- Einladung des Scrum-Teams zum Sprint Review-Meeting
- Erklärung, welche Product Backlog-Items fertig („Done“) sind und welche nicht („Not Done“)
- Vorstellung des aktuellen Backlog-Stands und Vorhersage des voraussichtlichen Ziel- und Liefertermins
Scrum Master
… ist ein Servant Leader für das Scrum-Team.
… ist verantwortlich für die Beseitigung von Hindernissen für den Fortschritt des Development Teams.
… sollte mit dem Scrum-Team und der Organisation zusammenarbeiten, um die Transparenz zu erhöhen.
Sprint Planning
↓
Daily Scrum
↓
Sprint Review
↓
Sprint Retrospective
- Unterstützung des Scrum-Prozesses
- Sicherstellen, dass die Scrum Events stattfinden und das Team den Zweck versteht
- Coaching des Scrum-Teams zur Einhaltung der Regeln
- Zusammenarbeit mit anderen Scrum-Teammitgliedern, um die Ausführung des Sprints zu verstehen und die Leistung und den Fortschritt des Sprints zu überprüfen
Product Owner
- Vermitteln von Techniken für das Management des Product Backlogs
- Vermitteln eines Verständnisses für die Notwendigkeit klarer und prägnanter Product Backlog-Items im Scrum-Team
- Schaffen eines Verständnisses für Produktplanung in einem empirischen Umfeld
- Sicherstellen, dass der Product Owner weiß, wie er den Product Backlog anordnet, um den Wert zu maximieren.
- Vermitteln eines Verständnisses von Agilität und deren praktische Anwendung
- Unterstützung bei Scrum Events bei Bedarf oder Anfrage
Development Team
- Coaching des Teams in Selbstorganisation und funktionsübergreifender Arbeit im Team
- Unterstützung des Teams bei der Entwicklung hochwertiger Produkte
- Beseitigung von Hindernissen, die den Fortschritt des Teams verhindern
- Moderation von Scrum-Ereignissen nach Anforderung oder Bedarf
- Coaching des Teams in einem organisationalen Umfeld, in dem Scrum noch nicht vollständig angenommen und verstanden wird
Organisation
- Leitung und Coaching der Organisation bei der Einführung von Scrum
- Planung von Scrum-Implementierungen innerhalb der Organisation
- Unterstützung von Mitarbeitern und Stakeholdern beim Verständnis und der Umsetzung von Scrum und empirischer Produktentwicklung.
- Auslösen von Veränderungen, die die Produktivität des Scrum-Teams erhöhen.
- Zusammenarbeit mit anderen Scrum Mastern, um die Effektivität der Implementierung von Scrum in der Organisation zu erhöhen.
Development Team
- Der Product Backlog ist die einzige Sammlung von Anforderungen zur Abarbeitung und Umsetzung.
- Es sollte selbstorganisiert und interdisziplinär funktionieren.
- Das Team entscheidet selbstständig über die Arbeitsaufgaben des nächsten Sprints und den geschätzten Aufwand für jede Aufgabe.
- Es gibt keinen Titel im Team und auch keine weitere Unterteilung innerhalb des Teams. Einzelne Teammitglieder können jedoch über spezialisierte Fähigkeiten verfügen.
- Die Anzahl der Teammitglieder sollte zwischen 3 und 9 Personen liegen.
Sprint Planning
- Definition der Aufgaben des Sprint Backlogs
- Entscheidungsfindung darüber, wie das Sprint-Ziel und der Sprint Backlog in ein fertiges („Done“) Produktinkrement umgesetzt werden können.
- Selbstorganisiert, um die Arbeit im Sprint Backlog zu erledigen.
Daily Scrum
- Verantwortlich für die Durchführung des Daily Scrum
- Überprüfung der Fortschritte auf dem Weg zum Sprint-Ziel
- Häufiges Meeting nach dem Daily Scrum: detaillierte Diskussionen, Anpassungen oder Umplanungen der Arbeit im Sprint
Sprint Review
- Demonstration der fertigen Arbeit vor Product Ownern und Stakeholdern und Beantwortung der Fragen zum Inkrement.
- Darstellung, was während des Sprints gut lief, identifizierten von Problemen und Problemlösungen
Stakeholders
(Nach dem Scrum Guide™ keine offizielle Scrum Rolle)
Durch den individuellen Charakter jedes Projekts können große Unterschiede in Bezug auf die Bedeutung und den Einfluss von Stakeholdern auftreten. Wahrscheinlich gibt es sogar noch mehr Stakeholder als die hier beschriebenen. Daher ist eine detaillierte Stakeholder-Analyse zu Beginn und während des Projekts entscheidend für den Erfolg.
Kunde
- Intern: Personen/Gruppen, die die Finanzierungsentscheidung für die Produktentwicklung treffen (typischerweise Geschäftsführer oder Budgetverantwortliche).
- Extern: Personen/Gruppen/Organisationen, die für die Nutzung des Produkts bezahlen (gilt nur für extern verkaufte Produkte).
Endbenutzer
- Ist die wichtigste Informationsquelle bei der Definition der Anforderungen.
- Ist der Protagonist in den meisten User Stories; überprüft die Inkremente (passiv, basierend auf User Stories).
- Verwendung des Endprodukts
Manager
- Bereitstellung von Ressourcen und Richtlinien innerhalb der Organisation
- Lösung von Problemen, die der Scrum Master eskaliert.
- Ist die letzte Instanz, die über Fragen entscheidet.
Scrum Artefakte
Produktvision
Die Produktvision ist ein kurzes Statement, das die Ziele und den Nutzen des Produkts beschreibt.
- Die Produktvision erklärt, wie das Produkt die Ziele und Strategien des Unternehmens oder der Organisation unterstützt.
- Die Produktvision bezieht sich auf die wichtigsten Produktziele, den Kunden, wie es seine Bedürfnisse erfüllen kann und sollte den einzigartigen Wert hervorheben.
- Die Produktvision sollte vor dem Product Backlog erstellt werden.
- Der Product Owner ist verantwortlich für die Produktvision und deren Aktualisierung.
Template zur Erstellung eines Vision Statements (nach Geoffrey A. Moore)
Es gibt eine Reihe von Aspekten, die immer in einem korrekten Vision Statement berücksichtigt werden sollten:
FÜR „Zielkunde“
DER/DIE „Bedürfnisse“
DAS „Produktname“
IST EIN „Produktkategorie“
DAS „Produktnutzen / Kaufgrund“
ANDERS ALS „Wettbewerber“
UNSER PRODUKT „Differenzierung / Leistungsversprechen“
Elevator Pitch
Der beste Weg, die Produktvision zu validieren, ist die Durchführung des Elevator Pitchs: „Kannst du dein Produkt in der Zeit beschreiben, die nötig ist, um in einem Aufzug hochzufahren?“ Das Absolvieren dieses Tests stellt sicher, dass Ihre Produktvision klar, ansprechend und kurz ist.
Produktinkrement
Die Ergebnisse aller Product Backlog-Items, die während eines Sprints und allen vorherigen, abgeschlossen wurden.
- Am Ende eines jeden Sprints muss das neue Inkrement fertig („Done“) sein, d.h. es muss sich in einem verwendbaren Zustand befinden und der Definition of Done des Scrum-Teams entsprechen.
- Wenn das Development Team gut geplant und geschätzt hat, enthält das Produktinkrement alle Items des Sprint Backlogs.
Product Backlog
Der Product Backlog ist eine priorisierte Liste mit kurzen Beschreibungen von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll.
- sollte immer genügend Anforderungen (oft in Form von User Stories) enthalten, um mindestens einen, besser zwei, Sprints abzudecken.
- ist ein lebendes Artefakt, es ist erlaubt, dass er wächst und sich verändert, wenn mehr über das Produkt und seine Kunden erfahren wird.
- ist dynamisch; er ändert sich ständig, wenn neue Gegebenheiten eintreten (z.B. neue Anforderungen, Änderungen von Markttrends).
- listet alle Features, Funktionen, Anforderungen, Erweiterungen und Korrekturen auf, die vorzunehmende Änderungen an dem Produkt in zukünftigen Releases darstellen.
Backlog-Priorisierung
User Stories werden vom Product Owner nach Wichtigkeit, Aufwand und Wert priorisiert.
User Stories
User Stories sind kurze, einfache Beschreibungen der gewünschten Funktionalität.
- User Stories werden aus der Perspektive der Person geschrieben, die von der Umsetzung der User Story profitiert.
- Die User Story wird im Format von: „Als [WER] will ich [WAS], damit [Grund].“
Charakteristika einer guten User Story
I ndependent (Unabhängig)
N egotiable (Übertragbar)
V aluable (Wertvoll)
E stimable (Abschätzbar)
S mall (Klein)
T estable (Überprüfbar)
Definition of Done
Abgestimmte Aktivitäten, die erforderlich sind, um ein fertiges („Done“) Produktinkrement am Ende eines Sprints zu liefern.
- Die Definition von Done (DoD) muss für das gesamte Scrum-Team eindeutig sein und wird verwendet, um zu entscheiden, wann eine User Story aus dem Sprint-Backlog abgeschlossen ist.
- Jedes Scrum-Team hat seine eigene DoD. Wichtig ist, dass jedes Team eine gemeinsame Definition hat, die jeder versteht.
Beispiel:
- Alle Aufgaben erledigt
- Alle Abnahmekriterien erfüllt
- Code vollständig
- Vollständig getestet
- Keine bekannten Mängel
- Dokumentation aktualisiert
Abnahmekriterien
Eine Liste von Anforderungen, die Erfüllt sein müssen, um die User Story als abgeschlossen zu betrachten.
- Die vom Product Owner erstellten Abnahmekriterien definieren die Grenzen einer User Story und legen fest, wann eine User Story implementiert wird.
- Während die DoD generisch ist und für alle User Stories gilt, sind die Abnahmekriterien für jede User Story unterschiedlich.
Beispiel:
- “ Der Home-Button ist auf allen Seiten sichtbar.“
- „Durch Anklicken des Home-Buttons kehrt der Benutzer zur Startseite zurück.“
- „Home-Button ist erkennbar.“
Story Points
Einheit zur Schätzung des gesamten Aufwands eines Product Backlog-Item.
- Das Scrum Team schätzt den Aufwand für die Implementierung der User Story einschließlich allem, was den Aufwand beeinflussen kann (Arbeitsaufwand / Komplexität der Arbeit / Risiko oder Unsicherheit bei der Durchführung der Arbeit).
- Anstelle von Story Points können User Stories auch in anderen Einheiten geschätzt werden, z.B. T-Shirtgrößen S/M/L/L/XL.
Planning Poker
Agile Schätz- und Planungsmethode, die verwendet wird, um den Aufwand oder die relative Größe von Backlog-Items zu schätzen.
Beim Planning Poker schätzen die Mitglieder der Gruppe, indem sie nummerierte Karten mit Werten ausspielen, die die Anzahl der Story Points darstellen (0, 1, 2, 3, 5, 8, 13, 20, 40 und 100).
Die folgenden Regeln gelten für das Spiel:
- Der Product Owner oder Kunde liest dem Team eine User Story vor oder beschreibt eine Funktion.
- Das Team diskutiert die Funktion und stellt Fragen, die der Product Owner beantworten muss.
- Nach der Diskussion legt jedes Teammitglied eine verdeckte Karte hin, die seinen Schätzwert für die Story darstellt.
- Alle Karten werden gleichzeitig aufgedeckt.
- Wenn alle Teammitglieder den gleichen Wert haben, wird dieser zur Schätzung für die User Story.
- Wenn nicht, erhalten Teammitglieder mit hohen und niedrigen Schätzungen die Möglichkeit, ihre Schätzung zu begründen.
- Der Schätzvorgang wird wiederholt, bis ein Konsens erreicht ist.
Sprint Backlog
Vom Development Team identifizierten Product Backlog-Items, die während des bevorstehenden Sprints erledigt werden sollen.
- Während des Sprint Planning Meetings wählt das Team eine Reihe von Product Backlog-Items (User Stories) aus.
- Die ausgewählten Product Backlog-Items werden im Sprint-Ziel zusammengefasst.
- Das Team identifiziert die Aufgaben, die notwendig sind, um jede User Story abzuschließen.
- Während des Scrum-Zyklus werden die vordefinierten Aufgaben erledigt.
- Das Team passt den Sprint Backlog während des gesamten Sprints an
Aufgaben
Die Aufteilung der Product Backlog-Items in Aufgaben hilft dem Development Team, die nächsten To Dos des Sprints zu planen.
- Im Idealfall ist eine Aufgabe so bemessen, dass sie bis zum nächsten Scrum-Meeting abgeschlossen werden kann.
- Für jede Aufgabe werden klare Verantwortlichkeiten definiert.
- Im Gegensatz zu User Stories werden die Aufgaben von den Personen definiert, die die Arbeit verrichten – dem Development Team.
- Die Aufgaben können bei Bedarf in kleinere Stücke zerlegt werden.
Task Board
Visualisierungstool für die Arbeit und den Workflow, das dem Team ermöglicht, den Arbeitsverlauf zu optimieren.
- Die Arbeitsaufgaben werden visualisiert, um den Teilnehmern einen Überblick über Fortschritt und Prozess zu geben, von der Aufgabendefinition (Sprint Backlog) bis zur Auslieferung an den Kunden („Done“).
- Die Teammitglieder „nehmen“ sich die Arbeit, wenn es die Kapazität erlaubt, anstatt sie auf Wunsch in den Prozess zu „schieben“.
- Das Aufgaben Board sollte in den Daily Scrums aktualisiert werden.
Sprint Down Burn Chart
Eine Möglichkeit, Scrum Sprints und den Implementierungsfortschritt agiler Projekte zu verfolgen.
- Die Stunden, die zur Erledigung jeder Aufgabe benötigt werden, schätzt das Team beim Sprint Planning-Meeting.
- Der Scrum Master kalkuliert die ausstehende Arbeit, stellt sie grafisch dar und vergleicht sie mit der Schätzung.
- Die ausstehende Arbeit (oder der Backlog) liegt oft auf der vertikalen Achse, die Zeit auf der horizontalen Achse.
- Das Chart dient neben der Planung und Verfolgung auch als Instrument zur Risikominimierung und Kommunikation.
Scrum Events
Sprint Planning
Ein Meeting, bei dem das Development Team die Arbeit für den nächsten Sprints plant. Während des Sprint Planning-Meetings:
- beschreibt der Product Owner das Ziel des Sprints und erklärt dem Team die Funktionen mit der höchsten Priorität (Arbeit für zwei Sprints).
- entscheidet das Development Team, wie viele Items aus dem Product Backlog im kommenden Sprint aufgrund ihrer Kapazitäten realisiert werden können.
- stellt das Development Team genügend Fragen, um eine hoch priorisierte User Story des Product Backlogs in die detaillierteren Aufgaben des Sprint Backlogs zu verwandeln.
Es gibt zwei Artefakte, die sich aus einem Sprint Planning-Meeting ergeben:
- Sprint-Ziel: eine kurze Beschreibung dessen, was das Scrum-Team während eines Sprints erreichen will.
- Sprint Backlog: Sammlung von Product Backlog-Items und entsprechende Aufgaben, die innerhalb des nächsten Sprints implementiert werden sollen.
Daily Scrum Meeting
Das Development Team trifft sich jeden Tag, um Aktivitäten zu koordinieren und die nächsten 24 Stunden zu planen.
- 15-minütige Time Box für das Development Team.
- Das Meeting sollte jeden Tag zur selben Zeit und an demselben Ort stattfinden, idealerweise am Morgen.
- Das Team überprüft den Fortschritt auf dem Weg zum Sprint-Ziel mit Hilfe der folgenden Fragen:
- „Was habe ich gestern getan, das dem Team geholfen hat, das Sprint-Ziel zu erreichen?“
- „Was werde ich heute tun, damit das Team das Sprint-Ziel erreicht?“
- „Sehe ich irgendwelche Hindernisse, die uns daran hindern, das Sprint-Ziel zu erreichen?“
Backlog Verfeinerung
Unterstützt bei der Vorbereitung und Aktualisierung des Product Backlogs für das nächste Sprint Planning-Meeting.
Die Backlog Verfeinerung sollte kontinuierlich während jedes Sprints stattfinden. Ziel ist es, den Product Backlog zu aktualisieren und die User Stories für das nächste Sprint Planning Meeting vorzubereiten:
- Hinzufügen oder Entfernen von User Stories
- Detaillierung von User Stories
- Definition von Akzeptanzkriterien und Story-Größe
- Priorisierung von User Stories aktualisieren
Die Backlog Verfeinerung hilft, die User Stories so aufzubereiten, dass das nächste Sprint Planning-Meeting sofort mit eindeutigen und gut definierten Items beginnt.
Sprint Review
Das Development Team demonstriert das Inkrement, das während des Sprints entwickelt wurde und dieses wird anhand des Sprint-Ziels beurteilt.
- Es werden nur die Ergebnisse präsentiert, die ein „potenziell auslieferbares Produktinkrement“ darstellen, z.B. eine codierte, getestete und verwendbare Software.
- Neben dem Scrum-Team sollten auch die Stakeholder an diesem informellen Treffen teilnehmen.
- Die Stakeholder können dem Development Team Feedback geben, welches dann als neue User Story in den Product Backlog aufgenommen wird.
Sprint Retrospective
Das Meeting ermöglicht es dem Scrum-Team, sich während der gesamten Projektlaufzeit kontinuierlich zu überprüfen und zu verbessern.
Jedes Mitglied des Scrum-Teams sollte die Möglichkeit haben, seine Meinung in einer offenen, ehrlichen und konstruktiven Atmosphäre zu äußern.
Das Scrum-Team sollte:
- überprüfen wie der vergangene Sprint auf die beteiligten Personen, Beziehungen, Prozesse und Tools verlaufen ist.
- die wichtigsten gut gelungenen Elemente identifizieren
- Verbesserungspotenziale aufzudecken und in eine Reihenfolge zu bringen sowie einen Plan für deren Umsetzung zu erstellen
Pitfalls
Die Funktion des Product Owner ist nicht gut definiert
oder wird nicht gelebt
Symptome
- Stories werden häufig nicht fertig („Done“)
- Der Product Owner steht nicht zur Verfügung, um Fragen des Teams zu beantworten.
- Das Team erhält unterschiedliche Nachrichten aus verschiedenen Quellen.
Vorgeschlagene Maßnahmen
- Jedes Team sollte einen eigenen Product Owner haben.
- Alle Backlog-Items und Aufgaben sollten dem Team nur über den Product Owner mitgeteilt werden.
- Der Product Owner sollte den Product Backlog und dessen Priorisierung durch regelmäßige Kommunikation mit den Stakeholdern anpassen
Das Team investiert nicht genug Zeit, um den Backlog zu verfeinern
Symptome
- Das Sprint Planning-Meeting dauert sehr lange.
- Stories sind schwer einzuschätzen.
- Stories sind nach Ablauf eines Sprints nicht fertig („Done“).
Vorgeschlagene Maßnahmen
- Der Scrum Master sollte regelmäßige Backlog Verfeinerungen organisieren, um über anstehende User Stories zu diskutieren.
- Der Product Owner sollte sich vorab mit den Stakeholdern abstimmen.
- Der Product Owner sollten an der Backlog Verfeinerung teilnehmen, um gemeinsam mit dem Team anstehenden Arbeiten zu besprechen.
Story sind nicht ausreichend heruntergebrochen oder nicht unabhängig
Symptome
- User Stories sind am Ende eines Sprints nicht fertig („Done“).
- Der tatsächliche Aufwand ist oft viel größer als geschätzt.
- Für das Team ist es schwierig, sofort auf Stories zu reagieren.
Vorgeschlagene Maßnahmen
- Faustregel, die beim Schreiben von User Stories anzuwenden ist: Eine User Story sollte nicht länger als 1/2 oder (idealerweise 1/3) der gesamten Sprintdauer dauern.
- User Stories sollten der Faustregel „INVEST” folgen (independent, negotiable, valuable, estimable, small, testable).
Das Team wird von jemand anderem gelenkt
Symptome
- Die Stories sind nicht fertig oder erst am Ende des Sprints gestartet.
- Das Team arbeitet ohne nachhaltiges Tempo, um jeden Sprint abzuschließen und steht unter großem Druck.
Vorgeschlagene Maßnahmen
- Das Team sollte beginnen, den Fortschritt zu verfolgen (z.B. wie viele Storypunkte in einem Sprint erreicht werden können), um eine Durchschnittsgeschwindigkeit zu ermitteln.
- Ausschließlich das Team schätzt die Arbeit und gibt an, wie viel Arbeit / wie viele Stories sie während eines Sprints erledigen können.
- Erwartungen an selbstorganisierte Teams mit dem Management und den Stakeholdern abgleichen.
Das Team arbeitet individuell am Backlog
Symptome
- Das Team ist der Meinung, dass jedes Backlog-Item nur von einer Person bearbeitet wird.
- Engpässe entstehen um ein einzelnes Teammitglied herum.
- Eine Person oder Gruppe leistet Überstunden, um mit der Nachfrage in der vorgegebenen Zeit Schritt zu halten.
Vorgeschlagene Maßnahmen
- Förderung der Zusammenarbeit an Stories, um die Qualität des Endprodukts zu steigern.
- Product Owner sollten Stories schreiben, die die Möglichkeit bieten, Paare zu bilden.
- Training des Teams zu Fähigkeiten, Fachexperten arbeiten mit einem oder zwei Teammitgliedern zusammen, um neue Fähigkeiten zu erwerben.
Zusätzliche Arbeit unterbricht den Sprint
Symptome
- Das Team erkennt erhebliche ungeplante Arbeiten oder erhält Anfragen von Stakeholdern, die sofort erledigt werden müssen.
- Geplante Stories werden nicht abgeschlossen.
- Das Team ist der Meinung, dass sich die Prioritäten ständig ändern.
Vorgeschlagene Maßnahmen
- Sprintpuffer für ‚zusätzliche/gefundene Arbeit‘ einbeziehen.
- Mit Retrospektiven Wege ermitteln, um zusätzliche Arbeiten besser zu antizipieren.
- Die Führung mit der Wirkung von Unterbrechungen konfrontieren.
- Den Product Owner in seiner Rolle ermutigen und das Team vor Unterbrechungen schützen.
Besprechen Sie Ihr Vorhaben mit uns:
09 Glossar
BURN-DOWN CHART
Ein Diagramm, das die Entwicklung des verbleibenden Aufwands in Bezug auf die Zeit darstellt. Burn-Down Charts sind eine optionale Anwendung in Scrum, um den Fortschritt transparent zu machen.
BURN-UP CHART
Ein Diagramm, das die Entwicklung des bereits erledigten Aufwands in Bezug auf die Zeit darstellt. Burn-Up Charts sind eine optionale Anwendung in Scrum, um den Fortschritt transparent zu machen.
DAILY SCRUM
Tägliche Time Box von maximal 15 Minuten für das Entwicklungsteam, um Aktivitäten zu koordinieren und die nächsten 24 Stunden zu planen. Updates werden im Sprint Backlog angezeigt.
DEFINITION OF DONE
Ein gemeinsames Verständnis von Erwartungen, denen Software gerecht werden muss, um in der Produktion freigegeben werden zu können. Unter der Leitung des Entwicklungsteams.
DEVELOPMENT TEAM
Die Rolle innerhalb eines Scrum-Teams, die für die Steuerung, Organisation und Durchführung aller Entwicklungsarbeiten verantwortlich ist, die erforderlich sind, um bei jedem Sprint ein auslieferbares Produktinkrement zu erstellen.
EMPIRIE
Empirische Prozesssteuerung (kurz: Empirie), bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz, Überprüfung und Anpassung.
INKREMENT
Eine funktionierende Software, die zu den zuvor erstellten Inkrementen hinzukommt, wobei die Summe aller Inkremente – als Ganzes – ein Produkt bildet.
PRODUCT BACKLOG
Eine geordnete Liste der Arbeiten, die bei der Erstellung, Wartung und Unterhaltung eines Produkts zu erledigen sind. Wird vom Product Owner verwaltet.
PRODUCT BACKLOG VERFEINERUNG
Die Aktivität in einem Sprint, durch die dem Product Backlog Details zu Tasks hinzufügt, Schätzungen erstellt, oder die Reihenfolge im Product Backlog bestimmt wird.
PRODUCT OWNER
Die Rolle in Scrum, die für die Maximierung des Wertes eines Produkts verantwortlich ist, vor allem durch die schrittweise Verwaltung und Darstellung der geschäftlichen und funktionalen Erwartungen an ein Produkt gegenüber dem/den Development Team.
SCRUM
Ein Framework zur Unterstützung von Teams bei der Entwicklung komplexer Produkte. Scrum besteht aus Scrum-Teams und den zugehörigen Rollen, Events, Artefakten und Regeln, wie sie in Scrum Guide™ definiert sind.
SCRUM BOARD (TASK BOARD)
Ein physisches Board zur Visualisierung von Informationen für und durch das Scrum-Team, das oft zur Verwaltung von Sprint Backlog verwendet wird. Scrum Boards sind eine optionale Implementierung innerhalb von Scrum, um Informationen sichtbar zu machen.
SCRUM GUIDE™
Die Definition von Scrum, geschrieben und bereitgestellt von Ken Schwaber und Jeff Sutherland, Mitschöpfer von Scrum. Diese Definition besteht aus den Rollen, Events, Artefakten und den Regeln, die sie miteinander verbinden.
SCRUM MASTER
Die Rolle innerhalb eines Scrum-Teams, die für das Führen, Coaching, Unterrichten und Unterstützen eines Scrum-Teams und seiner Umgebung beim richtigen Verständnis und Gebrauch von Scrum verantwortlich ist.
SCRUM-TEAM
Ein selbstorganisierendes Team, bestehend aus einem Product Owner, Development Team und Scrum Master.
SCRUM-WERTE
Eine Reihe von Grundwerten und -qualitäten, die die Grundlage bilden. den Scrum-Rahmen; Selbstverpflichtung, Fokus, Offenheit, Respekt und Mut.
SELBSTORGANISATION
Das Führungsprinzip, das Teams autonom ihre Arbeit organisieren. Selbstorganisation geschieht innerhalb von Grenzen und entgegen vorgegebener Ziele. Teams entscheiden, wie sie ihre Arbeit am besten verrichten, anstatt von anderen außerhalb des Teams geleitet zu werden.
SPRINT
Zeitlich begrenztes Ereignis von 30 Tagen oder weniger, das als Rahmen für die anderen Scrum-Ereignisse und -Aktivitäten dient. Die Sprints werden nacheinander und ohne Zwischenräume durchgeführt.
SPRINT BACKLOG
Überblick der Auswahl an Product Backlog-Items für den jeweiligen Sprint und einen Umsetzungsplan zur Realisierung des Sprint-Ziels. Unter der Leitung des Entwicklungsteams.
SPRINT PLANNING
Zeitlich begrenztes Ereignis von acht Stunden oder weniger, um einen Sprint zu starten. Es dient dem Scrum-Team, die Items aus dem Product Backlog zu inspizieren und die Arbeit für den nächsten Sprint zu planen.
SPRINT RETROPERSPECTIVE
Zeitlich begrenztes Ereignis von drei Stunden oder weniger, um einen Sprint zu beenden. Es dient dem Scrum-Team, den vergangenen Sprint zu reflektieren und zu planen, welche Verbesserungen während des nächsten Sprints umgesetzt werden sollen.
SPRINT REVIEW
Zeitlich begrenztes Ereignis von 4 Stunden oder weniger, um die Entwicklungsarbeit eines Sprints abzuschließen. Es dient dem Scrum-Team und den Stakeholdern, um den aus dem Sprint resultierenden Produktinkrement zu überprüfen, die Auswirkungen der durchgeführten Arbeiten auf den Gesamtfortschritt zu bewerten und den Product Backlog bei Bedarf anzupassen, um den Wert der nächsten Periode zu maximieren.
SPRINT-ZIEL
Ein kurzer Ausdruck des Zwecks eines Sprints, oft ein Geschäftsproblem, das angegangen wird. Die Funktionalität kann während des Sprints angepasst werden, um das Sprintziel zu erreichen.
STAKEHOLDER
Eine Person außerhalb des Scrum-Teams mit einem spezifischen Interesse an und Wissen über ein Produkt, das für die schrittweise Entwicklung erforderlich ist. Vertreten durch den Product Owner und aktiv im Scrum-Team beim Sprint Review.
WERTE
Wenn die Werte Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt vom Scrum-Team verkörpert und gelebt werden, werden die Säulen Transparenz, Überprüfung und Anpassung lebendig und schaffen Vertrauen für alle. Die Mitglieder des Scrum-Teams lernen und erforschen diese Werte, während sie mit den Scrum Events, Rollen und Artefakten arbeiten.
Besprechen Sie Ihr Vorhaben mit uns: