Unsere Leistungsfelder auf verschiedenen Ebenen:
Ob für Dich individuell, Dein Team oder Deine Organisation – wir lassen uns ganz auf Dich ein, machen uns zusammen mit Dir ein Bild der Situation und leiten gemeinsam die für Dich und deine Situation geeigneten Ziele sowie Maßnahmen ab. Die folgende Übersicht soll Dir ein Bild davon vermitteln, in welche Richtung das gehen kann.
Teams oder andere Organisationseinheiten stecken fest, erreichen ihre Ziele nicht und stoßen wiederholt auf organisatorische oder individuelle Hindernisse. Unzufriedenheit breitet sich im Team und unter den Führungskräften aus.
Die Ursachen für diese Probleme liegen oft in unzureichender Kommunikation sowie Transparenz, fehlendem Vertrauen, falschen Erwartungen, komplexen Anforderungen, unzureichender Priorisierung und Zielkonflikten.
Unsere Agile Coaching- und Consulting-Aktivitäten zielen darauf ab, die Leistungsfähigkeit sicherzustellen. Je nach Bedarf konzentrieren wir uns auf Einzelpersonen, einzelne Teams oder die gesamte Organisation. Wir verstehen uns in diesem Zusammenhang als eine Mischung aus Trainer:in, Berater:in und Coach, je nachdem wovon es gerade mehr braucht.
Häufig werden Mitarbeitende zu Führungskräften befördert, ohne angemessene Vorbereitung auf die Herausforderungen der Führung. Dies führt dazu, dass sich die Mitarbeitenden schlecht geführt fühlen und möglicherweise die Organisation verlassen.
Selbstkenntnis ist entscheidend, um andere effektiv zu führen. Führungskräfteentwicklung umfasst die Verbesserung des eigenen Denkens und Handelns sowie die Klärung der eigenen Rolle. Neben fachlichen Kompetenzen ist es wichtig, Mitarbeitende zu motivieren, ihr Potenzial zu entfalten und die richtigen Werte zu vermitteln.
Wir bieten individuelle Coaching-, Beratungs- und Mentoring-Maßnahmen für Führungskräfte an. Diese können über einen längeren Zeitraum erfolgen, um die Entwicklung der Führungskräfte dialogisch zu begleiten und ihre Entwicklungsziele zu erreichen. Zusätzlich entwickeln wir maßgeschneiderte Lernprogramme und führen sie für spezifische Zielgruppen durch.
In Veränderungsprozessen wird die Kulturentwicklung manchmal vernachlässigt und alte Traditionen sowie Gewohnheiten bleiben oft erhalten. Zum Beispiel in hierarchisch geprägten Kulturen kann es üblich sein, dass jede Entscheidung zuerst vom Chef abgesegnet werden muss. Dies kann Prozesse verlangsamen und die Autonomie der Mitarbeitenden einschränken.
Kultur ist oft schwer greifbar und Veränderungen in der Kultur brauchen Zeit. Rituale ändern sich nicht von heute auf morgen und die Betroffenen müssen auf diesem Veränderungsweg begleitet werden, um Rückfälle in alte kulturelle Praktiken abzufedern. Häufig werden nur Verhaltensänderungen angestrebt, ohne die zugrunde liegenden Überzeugungen anzugehen. Diese Vorgehensweise ermöglicht keine nachhaltigen Veränderungen.
Die Umsetzung in die Praxis erfordert ein angepasstes Vorgehen. Durch Interventionen und die Einführung neuer Methoden können Organisations- und Teamkulturen gezielt verändert werden. Hierbei werden Veränderungsprozesse auf verschiedenen Ebenen der Kultur durchgeführt, um die gewünschte Entwicklung zu fördern. Wir nutzen die Dimensionen „System“, „Verhalten“ und „Glaubenssätze“, um Kultur sichtbar zu machen, und setzen unseren Ansatz des „Micro Change Cycle“ ein, um die gewünschten Veränderungen herbeizuführen. Weitere Infos dazu beinhaltet unsere Website PatternBreakers.
TIn vielen Organisationen finden Feedback-Gespräche nur halbjährlich oder jährlich statt. Doch allein das reicht oft nicht aus, um Mitarbeitenden dabei zu helfen, ihr volles Potential auszuschöpfen. Ineffizienzen und Demotivation sind oft die Folge einer nicht ausreichend stärkenorientierten Personalentwicklung.
Coaching ist eine wirksame Unterstützung für Mitarbeitende, die sich häufig an sich verändernde Umgebungen anpassen müssen, um ihre Energie, Innovationskraft und ihr Engagement voll entfalten zu können. Im Unterschied zum Feedback, welches Informationen über vergangenes Verhalten und Leistung liefert sowie mögliche Anpassungen vorschlägt, hat Coaching einen vorbereitenden Ansatz zur Lösung von Herausforderungen. Darüber hinaus bezieht systemisches Coaching auch das System und seine Wirkungsfelder in die Reflexion mit ein.
Das systemische Coaching ist eine problem- und lösungsorientierte Methode, um Menschen bei einem selbstbestimmten Anliegen zu begleiten und aus der defizitären Situation in einen ressourcenvollen Zielzustand zu bringen. Von unseren erfahrenen Coaches werden die Mitarbeitenden mit ausgewählten Methoden in vertraulichen 1:1 Coaching-Sitzungen oder als Team betreut.
In Teams können unterschiedliche Herausforderungen auftreten, die Unzufriedenheit und Leistungsminderung verursachen. Ein Team strebt beispielsweise eine schnelle und disruptive Entwicklung eines neuen Produkts an, während ein anderes Team darauf abzielt, Kosten zu senken und neue Standardisierungsanforderungen zu setzen. Dies führt zu Unsicherheiten bei der Priorisierung und beeinträchtigt die Zusammenarbeit zwischen den Teams.
Ursachen für diese Symptome sind häufig Zielkonflikte, starre Prozesse, fehlendes Vertrauen, falsche Erwartungen sowie mangelnde Kommunikation und Transparenz.
Anfangs sensibilisieren wir die Personen, die diese unterschiedlichen Ziele verfolgen, für den Konflikt und bieten ihnen Beratung zu möglichen Lösungen an. Im Rahmen der Teamentwicklung streben wir gleichzeitig an, die Zusammenarbeit innerhalb und zwischen den Teams zu verbessern. Durch regelmäßige Reflexion der Zusammenarbeit mit den Teams können wir Herausforderungen angehen, geeignete Maßnahmen ableiten und zukünftige Probleme vorausschauend angehen. Zudem fördern wir die Kommunikation und Transparenz sowie die Festlegung gemeinsamer Ziele durch verschiedene Formate wie Workshops oder Retrospektiven.
In deiner Organisation gibt es keine klare Aufgabenverteilungen bei der Entwicklung von Produkten. Entscheidungswege sind lang, die Kommunikation zwischen den Bereichen ist begrenzt und Produktveränderungen erfolgen langsam. Innovationsentwicklung ist eine Herausforderung. Die Konkurrenz kann dagegen schnell reagieren und innovative Produkte auf den Markt bringen. Diese internen Herausforderungen führen zu Demotivation bei den Mitarbeitenden, höherer Fluktuation und Umsatzeinbußen.
Ursachen für diese Symptome sind oft starre Prozesse und Hierarchien, komplexe Problemstellungen und Anforderungen sowie unzureichende Priorisierung und Zielkonflikte zwischen den verschiedenen Organisationseinheiten.
Adaptives Organisationsdesign ist ein Zusammenspiel verschiedener Leistungsfelder. Unser Ziel ist es, eine Organisationsstruktur und Arbeitsweisen zu schaffen, die es ermöglichen, sich schnell an Veränderungen anzupassen und nachhaltige Wettbewerbsvorteile zu erzielen. Durch die Identifikation von Wertströmen und den Einsatz agiler Methoden unterstützen wir unsere Kunden bei der organisatorischen Abbildung dieser Wertströme, der Etablierung dezentraler Entscheidungsprozesse und dem Aufbrechen von Hierarchien. Dadurch können sie besser mit der Komplexität eines Themas umgehen und dabei den Fokus und die Transparenz behalten.
Bei agilen Transformationen sehen wir oft, dass Mitarbeitende und Führungskräfte in alte Verhaltensmuster zurückfallen. Zum Beispiel haben sie Schwierigkeiten bei der Priorisierung, dem Fokussieren oder dem Delegieren von Aufgaben. Dadurch bleiben die Vorteile agilen Arbeitens ungenutzt und es entstehen Probleme wie Ignoranz, Konfrontation oder Frustration.
Häufig wird bei Veränderungen der Hebel vor allem beim Verhalten angesetzt und der systemische Blick auf die Organisation sowie die bestehenden Überzeugungen werden vernachlässigt. Ohne die richtige Hebelposition verliert die angestrebte Wirkung an Kraft und Mitarbeitende sowie Führungskräfte verfallen in alte Muster.
Im ersten Schritt stellen wir Transparenz her und versuchen Kultur über die Dimensionen „System“, „Verhalten“ und „Glaubenssätze“ sichtbar zu machen. Im zweiten Schritt identifizieren wir die richtigen Hebel, um Veränderungen herbeizuführen und nachhaltig mithilfe unseres „Micro Change Cycle“ Ansatzes zu implementieren. Unsere Erfahrungen dazu teilen wir auf unserer Website PatternBreakers. Wir stellen dort Inspirationen zu Verhaltensmustern, Glaubenssätzen und Interventionen bereit, die du direkt in deinem Umfeld testen kannst.
In der Organisation werden neue Strategien, Strukturen, Prozesse, Arbeitsweisen, IT-Systeme, oder auch Führungsprinzipien eingeführt bzw. angepasst. Vorangegangene Veränderungsprojekte sind unter Umständen bereits gescheitert. Das aktuelle Veränderungsvorhaben stößt auf Widerstand und Frustration macht sich breit.
Häufig werden Mitarbeitende und Führungskräfte bei anstehenden Veränderungen nicht ausreichend informiert und involviert. Sie verstehen die Notwendigkeit für die Veränderung nicht. Das Zielbild ist unbekannt, sodass es ihnen schwerfällt, ihren individuellen Wertbeitrag zu erkennen. Zudem entsprechen umgesetzte Maßnahmen häufig nicht den tatsächlichen Bedürfnissen der Mitarbeitenden.
Der Erfolg der Veränderung hängt maßgeblich von der Akzeptanz und Entwicklung der Mitarbeitenden ab. Mit Hilfe unseres Change Management Ansatzes und niedrigschwelligen “Micro Changes” , begleiten wir organisationale Veränderungen bedarfsgerecht und adaptiv. Für die einzelnen Engagement- und Enablement-Maßnahmen werden vorab Hypothesen und die erwünschten Wirkungen in der Organisation definiert und anschließend gemessen. Aufgrund der Messung wird für den nächsten Zyklus (Micro Change) gelernt und adaptiert.
Mitarbeitenden oder Teams ist nicht bewusst, warum sie ihre Aufgaben in der Organisation ausführen und worauf ihre Arbeitsergebnisse einzahlen. Ihnen fehlt der Sinn und die Zielrichtung ihrer Arbeit, was sich in Unzufriedenheit, Demotivation oder einer hohen Fluktuation ausdrückt.
Schlechte Kommunikation, fehlende Transparenz und mangelnde Stärkenorientierung sind oftmals Ursachen für Unklarheiten und ein unverständliches Zielbild.
Um Abhilfe zu schaffen, entwickeln wir zusammen mit unseren Kunden einen übergeordneten Zweck und ein leicht verständliches Zielbild für die Mitarbeitenden. So wird die Frage nach dem „Warum“ für alle klar und einfach verständlich beantwortet. Um sicherzustellen, dass der Purpose (Zweck) langfristig erfolgreich ist, überprüfen wir nach der Einführung, ob er wirklich zur organisationalen Struktur passt und nehmen bei Bedarf Änderungen vor.
Die Kundenzufriedenheit ist niedrig, das Zusammenspiel zwischen Teams oder Organisationseinheiten funktioniert nicht oder nur mangelhaft, Mitarbeitende beschweren sich über hohe Wartezeiten und Verzögerungen oder Abhängigkeiten sind unklar.
Ursachen für diese Symptome sind häufig eine mangelnde Produkt- oder Service-Orientierung und Transparenz über den Aktivitäts-, Informations- und Materialfluss von der Kundenanforderung bis hin zum fertigen Produkt oder Service. Mitarbeitende fühlen sich nicht Ende-zu-Ende verantwortlich.
Mit einer Wertstromanalyse (Value Stream Mapping) verfolgen wir das Ziel, sämtliche Arbeiten und Aktivitäten transparent zu machen, die notwendig sind, um einen Auftrag zu erfüllen. Der Wertstrom beginnt und endet beim Kunden – intern oder extern. Diese Methode ist leistungsstark bei der Identifizierung von Verschwendung oder Verzögerungen im Prozess. Unsere Erfahrung zeigt, dass die Stärke der Wertstromanalyse in der Ableitung und Umsetzung inkrementeller Verbesserungspotenziale liegt, wie zum Beispiel bei der Veränderung der Teamschnitte oder Anpassung der Schnittstellen.
79 Projekte seit Bestehen des AMPlifier Teams in unterschiedlichen Branchen
12 verschiedene Zertifizierungen in den Bereichen Agile und Change
12.847 verbaute Lego-Steine während Kunden-Workshops
3 Kooperationen mit strategischen Partnern
70% unserer Kunden sind Wiederholungskäufer
Durchschnittlich 5,1 Jahre Erfahrung in den Bereichen Agile und Change
• Wertstromanalyse • Adaptives Organisationsdesign • Agile Consulting
• Führungskräfteentwicklung • Teamentwicklung • Agile Coaching
• Führungskräfteentwicklung • Glaubenssätze und Muster • Kulturentwicklung
• Adaptives Organisationsdesign • Wertstromanalyse • Agile Consulting
• Kulturentwicklung • Glaubenssätze und Muster • Change Management
• Change Management • Kulturentwicklung
Du hast ein Problem zu lösen? Wir sind der richtige Ansprechpartner für Dich bei Problemen wie:
PURPOSE-DRIVEN WORK & TEAMENTWICKLUNG
Problemfeld 1:
„Wofür machen wir das alles überhaupt?“
Du hast Fragen zu Purpose-driven Work & Teamentwicklung?
WERSTROMANALYSE & ADAPTIVES ORGANISATIONSDESIGN
Problemfeld 2:
„Zielkonflikte“
Die Zusammenarbeit zwischen Teams wird durch starre Prozesse und Zielkonflikte behindert. Team 1 verfolgt bspw. das Ziel, disruptiv ein neues Produkt zu entwickeln. Team 2 möchte Kosten sparen und stellt dafür neue Anforderungen.
Du hast Fragen zu Wertstromanalyse & adaptivem Organisationsdesign?
FÜHRUNGSENTWICKLUNG
Problemfeld 3:
„Entscheidungs-Scheu“
Mitarbeitende treffen Entscheidungen zu selten selbst. Denn Fehler seien Karriere-Killer. Zudem werden ständig neue Themen angestoßen ohne dass bisherige beendet werden. Wenn priorisiert wird, hat „alles Prio 1“.
Du hast Fragen zu Führungsentwicklung?
GLAUBENSSÄTZE & MUSTER
Problemfeld 4:
„Wie schaffe ich es alte Verhaltensmuster zu durchbrechen?“
Du hast Fragen zu Glaubenssätzen und Mustern?
Wir freuen uns, Dich und Deine Situation kennenzulernen!
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 aus unserer Sicht wichtig?
Viele Unternehmen spüren aktuell den Druck eines immer dynamischeren Marktumfelds, in dem es gilt, wettbewerbsfähig zu bleiben:
01. 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.
02. 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.
03. 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.
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:
1. Individuen und Interaktionen sind wichtiger als Prozesse und Tools
2. Funktionierendes Produkt ist wichtiger als umfassende Dokumentation
3. Reagieren auf Veränderungen ist wichtiger als das Befolgen und Abarbeiten eines Plans
4. Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung
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.
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.
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 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.
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.
1. So kann die Führungskraft die Mitarbeiter zum Beispiel zuerst nach ihrer Meinung fragen, die Entscheidung am Ende aber selbst treffen.
2. Im nächsten Schritt kann man das umkehren – die Führungskraft teilt den Mitarbeitern ihre Meinung mit, überlässt ihnen aber die Entscheidung.
3. 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.
04. 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
Nichts geht ohne Mindset
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“.
Was verändert sich für die Führungskraft und wie holt sie die Mitarbeitenden richtig ab?
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.
1. Was bedeutet „fail fast, fail cheap“ bei uns?
2. Was verstehen wir unter Innovationen?
3. Wie viel Zeit nehmen wir uns für Führung?
4. Wie und wie oft geben wir uns Feedback?
5. Wie gehen wir mit den individuellen Stärken-/ Schwächenprofilen von Mitarbeitern um?
6. Wer darf was selbst entscheiden? Wer wird befördert und warum?
8. Welche Karrierepfade bieten wir unseren Mitarbeitern an?
9. 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.
Der Begriff OKR steht für „Objectives and Key Results“. OKR ist eine Methode, die eine Verbindung zwischen Strategie und day-to-day Business herstellt. Sie setzt sich primär aus den drei Kernelementen Messbarkeit, Flexibilität und Transparenz zusammen. OKRs sind jedoch keine Führungsmethode.
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.
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
1.1 Analyse der aktuellen Situation im Unternehmen, in den Abteilungen und in den Teams
1.2 Abstimmung der mit der Einführung der OKRs angestrebten Ziele
2. Vision und OKRs definieren
2.1 Erarbeitung der übergreifenden Vision und Nutzung von kreativen Workshop-Methoden
2.2 Gemeinsame Erarbeitung der OKRs
3. Den OKR-Zyklus aufsetzen
3.1 Aufsetzen eines vierteljährlichen Zyklus mit den notwendigen Prozessen, Rollen, Templates und Tools
4. Mitarbeiter für individuelle OKRs befähigen
4.1 Heranführung der Mitarbeiter an das Thema OKR und Schaffung von Verständnis
4.2 Methodische Befähigung und Training
4.3 Persönliches Coaching on Demand
5. Mitarbeiter auf die OKRs fokussieren
5.1 Schaffung regelmäßiger Ankerpunkte
5.2 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.
6.1 Begleitung des OKR-Zyklus als OKR-Master und -Office
6.2 Schaffung von Transparenz über Status und Fortschritt
6.3 Moderation von Status-Updates und Retrospektiven
6.4 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.
Die folgenden Informationen basieren auf dem Scrum GuideTM, 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
1. leichtgewichtig
2. einfach zu verstehen
3. schwierig zu meistern
Rollen
1. Product Owner – „Der Gestalter“
2. Scrum Master – „Der Moderator“
3. Development Team – „Die Schöpfer“
Artefakte
1. Produkt Backlog – Alle Funktionen des Zielprodukts
2. Sprint Backlog – Alle Produktmerkmale, die während des Sprints erstellt werden sollen.
3. Inkrement – Potenziell releasefähiges Produktteil
4. Definition of Done – Wenn das Produkt einsatzbereit ist.
Events
1. Sprint Planning – Priorisieren und definieren von Features, die im Sprint erstellt werden sollen
2. Daily Scrum – Kontinuierliches Informieren der Teammitglieder über die Fortschritte
3. Sprint Review – Präsentieren der Arbeitsergebnisse des Sprints
4. 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-Prozess
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 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
1. Erstellung, Pflege und Beschreibung des Product Backlogs
2. Priorisierung der Product Backlog-Einträge 3. Sicherstellen, dass der Product Backlog transparent und sichtbar ist.
4. Sicherstellen, dass das Development Team das richtige Verständnis für den Product Backlog hat Items
Sprint Planning
1. Besprechung des Ziels, die das Scrum-Team im Sprint erreichen soll
2. Unterstützung bei dem Verständnis der ausgewählten Items aus dem Product Backlog und Herstellung von Kompromissen.
Sprint Review
1. Einladung des Scrum-Teams zum Sprint Review-Meeting
2. Erklärung, welche Product Backlog-Items fertig („Done“) sind und welche nicht („Not Done“)
3. 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
1. Unterstützung des Scrum-Prozesses
2. Sicherstellen, dass die Scrum Events stattfinden und das Team den Zweck versteht
3. Coaching des Scrum-Teams zur Einhaltung der Regeln
4. 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
1. Vermitteln von Techniken für das Management des Product Backlogs
2. Vermitteln eines Verständnisses für die Notwendigkeit klarer und prägnanter Product Backlog-Items im Scrum-Team
3. Schaffen eines Verständnisses für Produktplanung in einem empirischen Umfeld
4. Sicherstellen, dass der Product Owner weiß, wie er den Product Backlog anordnet, um den Wert zu maximieren.
5. Vermitteln eines Verständnisses von Agilität und deren praktische Anwendung
6. Unterstützung bei Scrum Events bei Bedarf oder Anfrage
Development Team
1. Coaching des Teams in Selbstorganisation und funktionsübergreifender Arbeit im Team
2. Unterstützung des Teams bei der Entwicklung hochwertiger Produkte
3. Beseitigung von Hindernissen, die den Fortschritt des Teams verhindern
4. Moderation von Scrum-Ereignissen nach Anforderung oder Bedarf
5. Coaching des Teams in einem organisationalen Umfeld, in dem Scrum noch nicht vollständig angenommen und verstanden wird
Organisation
1. Leitung und Coaching der Organisation bei der Einführung von Scrum
2. Planung von Scrum-Implementierungen innerhalb der Organisation
3. Unterstützung von Mitarbeitern und Stakeholdern beim Verständnis und der Umsetzung von Scrum und empirischer Produktentwicklung.
4. Auslösen von Veränderungen, die die Produktivität des Scrum-Teams erhöhen.
5. Zusammenarbeit mit anderen Scrum Mastern, um die Effektivität der Implementierung von Scrum in der Organisation zu erhöhen.
Development Team
1. Der Product Backlog ist die einzige Sammlung von Anforderungen zur Abarbeitung und Umsetzung.
2. Es sollte selbstorganisiert und interdisziplinär funktionieren.
3. Das Team entscheidet selbstständig über die Arbeitsaufgaben des nächsten Sprints und den geschätzten Aufwand für jede Aufgabe.
4. 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.
5. Die Anzahl der Teammitglieder sollte zwischen 3 und 9 Personen liegen.
Sprint Planning
1. Definition der Aufgaben des Sprint Backlogs
2. Entscheidungsfindung darüber, wie das Sprint-Ziel und der Sprint Backlog in ein fertiges („Done“) Produktinkrement umgesetzt werden können.
3. Selbstorganisiert, um die Arbeit im Sprint Backlog zu erledigen.
Daily Scrum
1. Verantwortlich für die Durchführung des Daily Scrum
2. Überprüfung der Fortschritte auf dem Weg zum Sprint-Ziel
3. Häufiges Meeting nach dem Daily Scrum: detaillierte Diskussionen, Anpassungen oder Umplanungen der Arbeit im Sprint
Sprint Review
1. Demonstration der fertigen Arbeit vor Product Ownern und Stakeholdern und Beantwortung der Fragen zum Inkrement.
2. Darstellung, was während des Sprints gut lief, identifizierten von Problemen und Problemlösungen
Stakeholders
(Nach dem Scrum GuideTM 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
1. Intern: Personen/Gruppen, die die Finanzierungsentscheidung für die Produktentwicklung treffen (typischerweise Geschäftsführer oder Budgetverantwortliche).
2. Extern: Personen/Gruppen/Organisationen, die für die Nutzung des Produkts bezahlen (gilt nur für extern verkaufte Produkte).
Endbenutzer
1. Ist die wichtigste Informationsquelle bei der Definition der Anforderungen.
2. Ist der Protagonist in den meisten User Stories; überprüft die Inkremente (passiv, basierend auf User Stories).
3. Verwendung des Endprodukts
Manager
1. Bereitstellung von Ressourcen und Richtlinien innerhalb der Organisation
2. Lösung von Problemen, die der Scrum Master eskaliert.
3. 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.
1. Die Produktvision erklärt, wie das Produkt die Ziele und Strategien des Unternehmens oder der Organisation unterstützt.
2. Die Produktvision bezieht sich auf die wichtigsten Produktziele, den Kunden, wie es seine Bedürfnisse erfüllen kann und sollte den einzigartigen Wert hervorheben.
3. Die Produktvision sollte vor dem Product Backlog erstellt werden.
4. 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.
1. 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.
2. 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.
1. sollte immer genügend Anforderungen (oft in Form von User Stories) enthalten, um mindestens einen, besser zwei, Sprints abzudecken.
2. 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.
3. ist dynamisch; er ändert sich ständig, wenn neue Gegebenheiten eintreten (z.B. neue Anforderungen, Änderungen von Markttrends). 4. 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.
1. User Stories werden aus der Perspektive der Person geschrieben, die von der Umsetzung der User Story profitiert.
2. 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.
1. 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.
2. Jedes Scrum-Team hat seine eigene DoD. Wichtig ist, dass jedes Team eine gemeinsame Definition hat, die jeder versteht.
Beispiel:
1. Alle Aufgaben erledigt
2. Alle Abnahmekriterien erfüllt
3. Code vollständig
4. Vollständig getestet
5. Keine bekannten Mängel
6. Dokumentation aktualisiert
Abnahmekriterien
Eine Liste von Anforderungen, die Erfüllt sein müssen, um die User Story als abgeschlossen zu betrachten.
1. Die vom Product Owner erstellten Abnahmekriterien definieren die Grenzen einer User Story und legen fest, wann eine User Story implementiert wird.
2. Während die DoD generisch ist und für alle User Stories gilt, sind die Abnahmekriterien für jede User Story unterschiedlich.
Beispiel:
1. “ Der Home-Button ist auf allen Seiten sichtbar.“
2. „Durch Anklicken des Home-Buttons kehrt der Benutzer zur Startseite zurück.“
3. „Home-Button ist erkennbar.“
Story Points
Einheit zur Schätzung des gesamten Aufwands eines Product Backlog-Item.
1. 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).
2. 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:
1. Der Product Owner oder Kunde liest dem Team eine User Story vor oder beschreibt eine Funktion.
2. Das Team diskutiert die Funktion und stellt Fragen, die der Product Owner beantworten muss.
3. Nach der Diskussion legt jedes Teammitglied eine verdeckte Karte hin, die seinen Schätzwert für die Story darstellt.
4. Alle Karten werden gleichzeitig aufgedeckt.
5. Wenn alle Teammitglieder den gleichen Wert haben, wird dieser zur Schätzung für die User Story.
6. Wenn nicht, erhalten Teammitglieder mit hohen und niedrigen Schätzungen die Möglichkeit, ihre Schätzung zu begründen.
7. 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.
1. Während des Sprint Planning Meetings wählt das Team eine Reihe von Product Backlog-Items (User Stories) aus.
2. Die ausgewählten Product Backlog-Items werden im Sprint-Ziel zusammengefasst.
3. Das Team identifiziert die Aufgaben, die notwendig sind, um jede User Story abzuschließen.
4. Während des Scrum-Zyklus werden die vordefinierten Aufgaben erledigt.
5. 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.
1. Im Idealfall ist eine Aufgabe so bemessen, dass sie bis zum nächsten Scrum-Meeting abgeschlossen werden kann.
2. Für jede Aufgabe werden klare Verantwortlichkeiten definiert.
3. Im Gegensatz zu User Stories werden die Aufgaben von den Personen definiert, die die Arbeit verrichten – dem Development Team.
4. 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.
1. 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“).
2. Die Teammitglieder „nehmen“ sich die Arbeit, wenn es die Kapazität erlaubt, anstatt sie auf Wunsch in den Prozess zu „schieben“.
3. 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.
1. Die Stunden, die zur Erledigung jeder Aufgabe benötigt werden, schätzt das Team beim Sprint Planning-Meeting.
2. Der Scrum Master kalkuliert die ausstehende Arbeit, stellt sie grafisch dar und vergleicht sie mit der Schätzung.
3. Die ausstehende Arbeit (oder der Backlog) liegt oft auf der vertikalen Achse, die Zeit auf der horizontalen Achse.
4. 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:
1. 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).
2. entscheidet das Development Team, wie viele Items aus dem Product Backlog im kommenden Sprint aufgrund ihrer Kapazitäten realisiert werden können.
3. 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:
1. Sprint-Ziel: eine kurze Beschreibung dessen, was das Scrum-Team während eines Sprints erreichen will.
2. 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.
1. 15-minütige Time Box für das Development Team.
2. Das Meeting sollte jeden Tag zur selben Zeit und an demselben Ort stattfinden, idealerweise am Morgen.
3. Das Team überprüft den Fortschritt auf dem Weg zum Sprint-Ziel mit Hilfe der folgenden Fragen:
4. „Was habe ich gestern getan, das dem Team geholfen hat, das Sprint-Ziel zu erreichen?“
5. „Was werde ich heute tun, damit das Team das Sprint-Ziel erreicht?“
6. „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:
1. Hinzufügen oder Entfernen von User Stories
2. Detaillierung von User Stories
3. Definition von Akzeptanzkriterien und Story-Größe
4. 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.
1. Es werden nur die Ergebnisse präsentiert, die ein „potenziell auslieferbares Produktinkrement“ darstellen, z.B. eine codierte, getestete und verwendbare Software.
2. Neben dem Scrum-Team sollten auch die Stakeholder an diesem informellen Treffen teilnehmen.
3. 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:
1. überprüfen wie der vergangene Sprint auf die beteiligten Personen, Beziehungen, Prozesse und Tools verlaufen ist.
2. die wichtigsten gut gelungenen Elemente identifizieren
3. 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
1. Stories werden häufig nicht fertig („Done“)
2. Der Product Owner steht nicht zur Verfügung, um Fragen des Teams zu beantworten.
3. Das Team erhält unterschiedliche Nachrichten aus verschiedenen Quellen.
Vorgeschlagene Maßnahmen
1. Jedes Team sollte einen eigenen Product Owner haben.
2. Alle Backlog-Items und Aufgaben sollten dem Team nur über den Product Owner mitgeteilt werden.
3. 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
1. Das Sprint Planning-Meeting dauert sehr lange.
2. Stories sind schwer einzuschätzen.
3. Stories sind nach Ablauf eines Sprints nicht fertig („Done“).
Vorgeschlagene Maßnahmen
1. Der Scrum Master sollte regelmäßige Backlog Verfeinerungen organisieren, um über anstehende User Stories zu diskutieren.
2. Der Product Owner sollte sich vorab mit den Stakeholdern abstimmen.
3. 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
1. User Stories sind am Ende eines Sprints nicht fertig („Done“).
2. Der tatsächliche Aufwand ist oft viel größer als geschätzt.
3. Für das Team ist es schwierig, sofort auf Stories zu reagieren.
Vorgeschlagene Maßnahmen
1. 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.
2. User Stories sollten der Faustregel „INVEST” folgen (independent, negotiable, valuable, estimable, small, testable).
Das Team wird von jemand anderem gelenkt
Symptome
1. Die Stories sind nicht fertig oder erst am Ende des Sprints gestartet.
2. Das Team arbeitet ohne nachhaltiges Tempo, um jeden Sprint abzuschließen und steht unter großem Druck.
Vorgeschlagene Maßnahmen
1. 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.
2. 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.
3. Erwartungen an selbstorganisierte Teams mit dem Management und den Stakeholdern abgleichen.
Das Team arbeitet individuell am Backlog
Symptome
1. Das Team ist der Meinung, dass jedes Backlog-Item nur von einer Person bearbeitet wird.
2. Engpässe entstehen um ein einzelnes Teammitglied herum.
3. Eine Person oder Gruppe leistet Überstunden, um mit der Nachfrage in der vorgegebenen Zeit Schritt zu halten.
Vorgeschlagene Maßnahmen
1. Förderung der Zusammenarbeit an Stories, um die Qualität des Endprodukts zu steigern.
2. Product Owner sollten Stories schreiben, die die Möglichkeit bieten, Paare zu bilden.
3. 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
1. Das Team erkennt erhebliche ungeplante Arbeiten oder erhält Anfragen von Stakeholdern, die sofort erledigt werden müssen.
2. Geplante Stories werden nicht abgeschlossen.
3. Das Team ist der Meinung, dass sich die Prioritäten ständig ändern.
Vorgeschlagene Maßnahmen
1. Sprintpuffer für ‚zusätzliche/gefundene Arbeit‘ einbeziehen.
2. Mit Retrospektiven Wege ermitteln, um zusätzliche Arbeiten besser zu antizipieren.
3. Die Führung mit der Wirkung von Unterbrechungen konfrontieren.
4. Den Product Owner in seiner Rolle ermutigen und das Team vor Unterbrechungen schützen.
Unser Change-Prozess und -Wissen – passend für jedes Veränderungsvorhaben und bewährt in über 2.500 erfolgreichen Projekten:
Unser Change-Prozess
Veränderungen scheitern oft an Widerständen und fehlender Unterstützung. Wir begleiten Unternehmen mit praxiserprobtem Change Management, um Mitarbeitende mitzunehmen und eine Kultur zu schaffen, die den Wandel aktiv vorantreibt.
Change Basiswissen
Effektive Transformation braucht Klarheit. Hier finden Sie Definitionen, Gründe, Ziele, die bekanntesten Modelle, Phasen, Herausforderungen, Erfolgsfaktoren und konkrete Lösungen für ein erfolgreiches Change Management.
Die neue Change-Formel
Menschen werfen Altbewährtes nicht einfach über Bord. Unsere „Neue Formel für Change“ zeigt, welche Faktoren entscheidend sind, damit Mitarbeitende Widerstände überwinden, bewährte Muster ändern und den Wandel erfolgreich mitgestalten.
Unsere Change-Speziallösungen für technologische Änderungen, bedingt durch Digitalisierung und Systemeinführungen:
SAP S/4HANA
Eine Umfrage unter SAP-Kunden zeigt: 62 % der Herausforderungen bei S/4HANA-Transformationen betreffen menschliche Faktoren. Wir stellen sicher, dass Unternehmen neben Prozessen und Systemen auch alle Change-Aspekte berücksichtigen.
KI Consulting
Unternehmen fehlt oft die Balance, KI-Chancen zu nutzen und Risiken zu minimieren. Unsere Beratung schafft einen Compliance-konformen Rahmen, integriert technische sowie rechtliche Aspekte und stellt den Menschen in den Mittelpunkt.
Verwaltungsdigitalisierung
Trotz Milliardeninvestitionen in die Digitalisierung bleiben kommunale Ziele unerreicht. Unsere Beratung modernisiert zügig Organisationen und Prozesse und sorgt für eine effiziente, digitale, kunden- und serviceorientierte Verwaltung.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen