Übersicht
Die Herausforderung in der Umstellung der Arbeitsweise auf Scrum
Typische Ausgangslage
In den Organisationen, in denen ich bei der Einführung von Scrum unterstützt habe, fand ich typischerweise Situationen vor, wie:
- Es wurde versucht, die Umsetzung effizient zu gestalten, indem man exzessiv durch Analyse, Exploration, Planung und Ausdefinition versucht hat, möglichst alle Unwägbarkeiten zu aus dem wegzuräumen.
- Es wurde versucht, durch eine hohe Arbeitsteilung und Spezialisierung versucht Experten in ihrem Bereich möglichst fokussiert und entkoppelt voneinander einzusetzen, um so die Effizienz zu steigern.
- Es wurde durch zentrale Treiber und Wissensträge die weiteren Mitarbeiter ausgesteuert und so versucht, die Arbeit zu skalieren.
Alle diese Herangehensweisen stoßen bei einer gewissen Komplexität des Produktes an ihre Grenzen und führt zu der Suche nach neuen Herangehensweisen, die uns dabei helfen, hier wieder effektiver zu arbeiten.
Gemeinsam aus Ergebnissen lernen!
Gemeinsam Verantwortung übernehmen!
Um dieser steigenden Komplexität gerecht zu werden, sucht man nach neuen Herangehensweisen, um wieder effektiver zu guten Ergebnissen zu kommen.
- In Scrum stellen wir uns zu komplexeren Problemstellungen auf, indem wir in enger Zusammenarbeit Ergebnisse liefern und aus ihnen Lernen.
Scrum ist dabei ein minimaler Rahmen, den wir aus dem prinzipiellen Verständnis des Vorgehens für unsere Zwecke ausgestalten. - Durch die Fokussierungen auf die Lieferung eines minimalen Sets an Funktionalitäten schaffen wir die Möglichkeit, dass sich die Entwickler zusammenraufen und Ergebnisse liefern.
- Den Eindruck des Sprints nutzen wir, um im Sprint Review für das Produkt und in der Sprint Retrospektive für unserer Arbeitsweise zu lernen und zu optimieren.
Dieses Vorgehen unterscheidet sich in Hinblick auf das gemeinsame Lernen aus Ergebnissen der gemeinsamen kontinuierlich fortgeführten Ausgestaltung der Arbeitsumgebung und der hohen Eigenverantwortung bei den Entwicklern fundamental von den obigen Arbeitsweisen.
Neues bringt Unsicherheit, aber Unsicherheit ist nicht förderlich für das neue Vorgehen mit Scrum
Anstelle viel zu mutmaßen, wollen wir in Scrum froh anfangen und aus Ergebnissen Lernen. Dadurch das Scrum sich aber so grundlegend von der bisherigen Arbeitsweise unterscheidet, entsteht Unsicherheit bei allen Beteiligten.
- Diese Unsicherheit stellt uns vor weitere Herausforderungen
aus der Unsicherheit will man keine Fehler machen und sperrt sich dadurch mutig neues auszuprobieren, früh zu scheitern und so schneller zu lernen. - Man versucht möglichst klare Regeln, Abläufe und Verantwortlichkeiten festzulegen, dass jedoch in der Regel durch die bisherige Arbeitsweise geprägt ist. Dabei ist Scrum doch ein minimales Rahmenwerk, was wir passend zu dem Kontext aus eigenen Erfahrungen ausgestalten wollen.
- Die Unsicherheit treibt uns auf die Suche nach Kochrezepten von anderen, die wir dann blind übernehmen. Dabei ist es in Scrum doch so wichtig, die Intention der eingesetzten Werkzeuge und Praktiken zu verstehen, damit wir diese für unsere Bedürfnisse ausgestalten können.
Kurzum, wir versuchen Scrum zu etwas gewohnten auszudefinieren und nehmen in diesem minimalen Rahmenwerk dem Kern seiner Stärke uns bei unseren Herausforderungen helfen zu können.
Welcher Scrum Master Typ bist du?
Worauf kommt es beim Start mit Scrum an, damit wir es zügig effektiv nutzen?
Ansatzpunkt 1: Warum Scrum?
Warum ist es so wichtig zu klären, warum wir Scrum nutzen
Scrum ist heute ein Hype. Das führt oft dazu, dass Scrum zum Selbstzweck wird. In erstaunlich vielen Umgebungen steht die Frage im Raum, ob wir es “richtig” machen. Dabei sollte die Frage weniger sein, ob wir Scrum “richtig machen”, sondern worauf wir achten müssen, das Scrum uns bei unseren Herausforderungen hilft.
Die zentrale Intention herauszuarbeiten “Warum wir ein neues Vorgehen nutzen?”, schafft eine Orientierung für die Frage “Wie müssen wir es einsetzen, damit es uns hilft?”.
Was ist heute anders zu früher?
Oft hilft es herauszuarbeiten, was heute anders ist im Vergleich zu früher.
- Was hat uns früher erfolgreich gemacht?
- Was hat sich geändert? Was ist heute anders?
- Wo stoßen wir mit unserer bisherigen Arbeitsweise an unsere Grenzen?
In den meisten Fällen findet man über diesen Weg kritische Veränderungen in der Umgebung, die einen Wechsel der Arbeitsweise logisch erscheinen lassen.
Oft hat sich
- die Anzahl von Mitarbeitern, Schnittstellen, Modulen und/oder Kunden signifikant verändert
- ist das Produkt deutlich komplexer im Vergleich zu früher
- sind Kunden und/oder Belegschaft deutlich anspruchsvoller geworden
woraus sich dann die Notwendigkeit des Wandels und einer neuen Aufstellung zu dieser Situation motivieren lässt.
Typische Ziele hinter der Einführung von Scrum
Typische Beweggründe für die Einführung von Scrum sind
- dass wir in der Lage sind, komplexere Vorhaben angehen zu können
- dass wir schneller Ergebnisse liefern wollen, nicht zuletzt, um belastbar aus diesen zu lernen
- dass wir besser auf die Kundenbedürfnisse eingehen wollen
- dass wir eine attraktive, motivierende Umgebung für unsere Mitarbeiter schaffen
- dass wir in der Lage sind, Innovation zu schaffen
- dass wir Probleme früher erkennen können und so noch Gestaltungsspielraum haben, diese zu adressieren
Wenn wir ein klares Verständnis haben, was wir mit Scrum erreichen wollen und wie Scrum uns dabei hilft, dann können wir daraus eine konsequente Nutzung von Scrum motivieren.
Versucht früh herauszuarbeiten, was ihr mit Scrum erreichen wollt!
Wenn wir verstehen, was man in der Umgebung erreichen will, dann können wir daraus eine konsequente Nutzung von Scrum als Enabler für diese Ambitionen motivieren.
Gerade das offene informelle Gespräch mit Stakeholdern ist für mich oft ein Schlüssel. Wobei der Schwerpunkt in diesem Gespräch für mich auf dem Zuhören und Verstehen liegt. Hier in diesem Gespräch die Führungskräfte zu belehren ist oft ein typischer Fehler und kontraproduktiv. Mein Ziel ist es hier ihre Bedürfnisse zu verstehen und ihnen aufbauend darzustellen, wie Scrum dabei helfen kann, diese Herausforderungen zu meistern. So gewinnt man diese Führungskräfte aus ihrem eigenen Bedürfnis als wichtige Unterstützer.
Stell dir dazu folgendes Szenario vor
1. Wir haben ein gemeinsames Verständnis
Alle Beteiligten haben die gemeinsame Klarheit, dass wir mit Scrum unseren Time-to-Market deutlich verkürzen wollen.
2. Teammitglied drängt auf inkonsistentes Vorgehen
Ein Teammitglied drängt darauf, dass wir uns wie gewohnt drei Monate für den Aufbau einer soliden Infrastruktur als Grundlage nehmen sollten.
Jetzt könnt diesen Vorschlag relativ leicht mit der Ambition relativ schnell lieferbare Ergebnisse zu liefern und daraus belastbarer zu lernen, konfrontieren.
Ihr weit also in der Lage, die konsequente Nutzung von Scrum, in diesem Fall das Lernen aus minimalen Inkrementen zu motivieren, ohne dogmatisch irgend welche Scrum-Regeln anzuführen.
Ansatzpunkt 2: Das Produkt als Orientierung für eine gute Aufstellung
In vielen Umgebung kommt es zu Beginn zu fragen, wie:
- Wer gehört ins Scrum Team?
- Wie organisieren wir mehrere Teams zueinander?
- Wie müssen wir uns als Scrum Team aufstellen, um gemeinsam ein großartiges Ergebnis zu schaffen?
Oft wird dazu dann nach allgemeinen Antworten gesucht, statt aus mit Produkt-Ziel und erstem minimalem Product Backlog für dem eigenen Kontext die passende Antwort abzuleiten.
Wer gehört ins Scrum Team?
Hier können wir aus typischen Product-Backlog-Items herausarbeiten, welche Fähigkeiten für die Erarbeitung einer Lösung benötigt werden und wer welche Fähigkeiten mitbringt. So haben wir eine klare Orientierung, wie wir ein passendes Scrum Team aufbauen.
Wie stellen wir mehrere Teams bei einem größeren Vorhaben auf?
Letztlich können wir hier analog zu dem Vorgehen bei der ersten Frage die passende Personengruppe identifizieren. Daraus lässt sich dann passend die verschiedenen Aufstellungen von mehreren Teams zu diesen größeren Vorhaben abwägen.
Wie arbeite ich den Umgang mit Abhängigkeiten zu anderen Teams heraus?
Wenn wir in dieser Konstellation in dem Product Backlog des Scrum Teams früh Abhängigkeiten zu anderen Teams und Einheiten herausarbeiten, dann können wir auf Basis den Umgang mit den jeweiligen Partnern klären.
Wie motiviere ich die Entwickler, sich auf die Arbeit mit leichtgewichtigen Anforderungen einzulassen?
In vielen Umgebung lebt auch in Scrum die Trennung zwischen Fach-Seite und IT fort. Sei es, weil die Entwickler den Traum von klaren, gut vorbereiteten Anforderungen noch träumen und überzogene Ansprüche an die Vorbereitung im Vorweg auf ihre Arbeit haben oder sei es, weil der Product Owner, UX und Lead Entwickler sich in der Rolle dies gut vorzubereiten besonder gut gefallen.
Das Problem ist nur, dass in dieser Arbeitsform sich die meisten angestrebten Ziele mit Scrum nicht gut erreichen lassen und der Product Owner fast immer zum Bottleneck wird.
Um hier beim Start sich gemeinsam und übergreifend als Scrum Team in enger Zusammenarbeit zusammenzuraufen, hat es sich für mich bewährt, über ein minimales erstes Produkt-Ziel und Product Backlog in den Austausch zu gehen. Hier ist der Product Owner gefragt, vor allem die Übersicht und den Kontext gut vorzubereiten. Dabei sind die größeren gröberen User Stories in der Regel wichtiger als einzelne Kleine. Mit dieser Vorbereitung können wir dann im Scrum Team in den Austausch gehen, wie wir uns bestmöglich zu diesem Vorhaben aufstellen. Daraus lässt sich dann leicht motivieren, dass wir lieber übergreifend & eng Zusammenarbeit, statt unsere Arbeitsbereiche voneinander abzugrenzen. So haben es zumindest die besten Scrum Teams gemacht, die ich kenne 😉
Ihr seht also, wie gut man aus der Orientierung am Produkt eine gute Aufstellung motivieren lässt.
Möchtest du mehr zum Product Owner erfahren?
Auf dieser Seite haben wir alle unsere Informationen zum Product Owner gebündelt. Hier findest du Antworten zu wichtigen Fragen, vertiefende Podcast-Folgen und aufbauende Artikeln.
Ansatzpunkt 3: Aus dem minimalen Start das Lernen aus dem ersten Sprint forcieren
Wenn die Herangehensweise von Scrum ungewohnt ist, dann reichen die ersten beiden Ansatzpunkte alleine für sich oft nicht aus. Zu Stark sind die alten Gewohnheiten und die Unsicherheit mit dem neuen Vorgehen macht es nicht trivialer …
Für mich hat sich hier der bewusst minimale Start mit Scrum bewährt.
- Aus einer minimalen Vorbereitung sehen alle Beteiligten die Notwendigkeit, sich im Kick-off zusammenraufen und erleben den Start des ersten Sprints als einen ersten gemeinsamen Erfolg, der sie zusammenschweißt.
- Aus den vielen noch offenen Themen motiviert sich ein klarer Fokus für den Sprint und das Sprint-Ziel.
- Durch den minimalen Start weiß jeder, dass die Umgebung noch nicht der Weisheit letzter Schluss ist und damit ist allen klar, dass wir aus den Erfahrungen des ersten Sprints die Umgebung weiter Ausgestalten müssen. Dies setzt den richtigen Ton für die Inspect & Adapt Events Sprint Review (zum Produkt) und Sprint Retrospektive (zur Arbeitsweise).
Kurzum, der minimale Start forciert die andere Herangehensweise vom ersten Sprint an zu leben und man setzt so den Ton für die weiteren Sprints. Das habe ich in einer umfassenden Vorbereitung vor dem ersten Sprint so noch nicht gesehen. Hier wurde deutlich stärker an alten Mustern festgehalten. Es dauerte längere, sich zu dem eigentlichen Ansatz hinter Scrum zu entwickeln oder hat es nie geschafft, sich von alten konträren Mustern lösen.
Wie bereitet man diesen minimalen Start vor?
Zum Einen das durch die Motivation der neuen Arbeitsweise aus dem Grund, warum wir Scrum einführen und der Orientierung am Produkt. Zum anderen, indem man den beteiligten Personen hilft, die neue Arbeitsweise in einer sicheren Umgebung zu simulieren und aus erster Hand zu erleben.
Ich setze hier Start mit Scrum bewusst zwei Simulationen ein. Eine kleine Simulation, in der alle Beteiligten ein erstes Gefühl für die neue grundsätzliche Arbeitsweise bekommen und eine umfassendere Simulation, die ich bewusst nach an den angestrebten Start-Szenario orientiere und so den Gap zu dem, was wir im Kick-off erarbeiten, zu reduzieren.
Erlebe den Kern von Scrum
Nutze unser kostenloses Webinar, um aus erster Hand zu erleben, worauf es in Scrum wirklich ankommt!
Montag
15.05.
18:15-20:00
Fazit
Die Arbeitsweise in Scrum unterscheidet sich in der Regel fundamental von der vorherigen Arbeitsweise. Das ist auch logisch, weil wie sollten wir fundamental bessere Ergebnisse erreichen, wenn wir einfach nur ein wenig nachjustieren 🙂
Um früh einen Zugang zu der Arbeitsweise in Scrum zu bekommen:
- Motiviere ich die neue Arbeitsweise zu dem, was die Umgebung erreichen will
- Orientiere die Ausgestaltung der Umgebung am Produkt
- Forziere das Lernen aus Ergebnissen in enger Zusammenarbeit aus dem minimalen Start
