Erkennst du dein Unternehmen in einem der Punkte wieder?
Dann können wir helfen!
Wir bringen deine Scrum Master, Product Owner, Teams und die übergreifende Strukturen ins Lot, damit wieder mehr Wert als Kosten entstehen und die Organisation es mittelfristig alleine schafft, ihre Probleme in den Griff zu bekommen. Die agile Skalierung deiner Teams spielt natürlich immer eine Rolle.
Dabei setzen wir auf eine Mischung aus verschiedenen Methoden, die jeweils individuell auf die konkrete Situation bei unseren Kunden zugeschnitten sind. Möglich sind Bestandteile aus:
Training
Übernahme konkreter Rollen
(interimsweise)
Coaching
Mentoring
Beratung
Möchtest du ein paar Impulse für deine Situation mitnehmen?
Dann vereinbare einfach ein kostenloses und unverbindliches Beratungsgespräch mit uns. Da sind auf jeden Fall Ideen für dich dabei!
Beispiele von Kunden, deren Herausforderungen wir gelöst haben
Das Problem
- Review und Retro nur sporadisch durchgeführt
- Sprintergebnisse nicht am Kunden orientiert
- Mehrere Produkte und mehrere Ziele pro Sprint
- Gefühl von wertloser Meetingzeit
Die Lösung
- Erarbeitung von gemeinsamen Leitlinien über eine Vision, eine Mission und ein gemeinsames Produktziel
- Einführung eines Sprint Reviews, das die Kollaboration mit Stakeholdern in den Mittelpunkt stellt
- kontinuierliche Verbesserung durch Inspektion und Adaption der Teamtätigkeiten
- Entwicklung der Verbesserungen durch die Betroffenen
Die Situation
Ein Software-Entwicklungsteam unseres Kunden hatte begonnen, sich an Scrum zu orientieren. Allerdings waren die Ergebnisse des Teams bescheiden und die Teamstimmung miserabel. Die Entwickler des Teams hatten den Eindruck, unglaublich viel Zeit in wertfreien Meetings zu verbringen statt Lines of Code zu produzieren. Sie arbeiteten außerdem stets an vielen Tätigkeiten gleichzeitig, die auf unterschiedliche Produkte einzahlten und spürten kaum Verbindungen ihrer Tätigkeiten. Zwar arbeitete das Team in Sprints, allerdings wurden Sprint Reviews regelmäßig ausgelassen. Dadurch wurden Wünsche und Anmerkungen von Stakeholdern (z.B. Kunden und Führungskräfte) nicht berücksichtigt. Das Ergebnis war, dass das Produkt kaum den Anforderungen der Kunden entsprach und entsprechend viel Änderungsbedarf entstand.
Auch Retrospektiven ließ das Team aus. Es nahm sich kaum Zeit, Verbesserungspotentiale in der Zusammenarbeit zu entdecken und andere Arbeitsweisen auszuprobieren. Es stagnierte in seiner Entwicklung.
Die Lösung
Wir gaben diesem Team eine Scrum Masterin an die Hand. Ihr Ziel war es, das Team dazu zu befähigen, eigenständig und produktiv zu arbeiten und dabei Wert für die Firma zu stiften. Eine der ersten Maßnahmen war es, eine Vision und Mission mit dem Team zu erarbeiten. Diese gaben dem Team Orientierung und erleichterten es, in eine gemeinsame Richtung zu arbeiten. Dadurch wurde es für das Team leichter, sich Ziele zu setzen, zu denen mehrere Teammitglieder beitragen konnten. Gleichzeitig gab es nun regelmäßig Arbeitsstände, zu denen es leicht fiel, mit Stakeholdern zu sprechen. Die Einführung eines Sprint Reviews, in dem gemeinsam mit Stakeholdern der Stand des Produktes diskutiert und die nächsten Schritte adaptiert wurden, war somit einfach. Nicht nur in Retrospektiven, sondern auch in der täglichen Arbeit wurden außerdem Angewohnheiten des Teams sichtbar, die das Team bremsten oder zu Missstimmungen führten. Diese wurden aufgegriffen und Stück für Stück verändert, indem immer wieder andere Dinge (wie z.B. eine kürzere Iterationsdauer oder gemeinsames Schätzen der Backlog Items) ausprobiert wurden.
Der Nutzen
Unsere Begleitung hat dazu beigetragen, dass das Team die Benefits von Scrum erleben konnte. Es arbeitete zielgerichtet, nah am Kunden und mit einer klaren Vision, wo es hingehen soll. Das Team gewann an Eigenständigkeit und verinnerlichte ein Streben nach kontinuierlicher Verbesserung schon nach wenigen Monaten. Die Transparenz der Teamarbeit stieg ebenso wie deren Beitrag zum Kundenmehrwert und damit zum Unternehmenserfolg.
Tipps & Take-Aways
- Nutze die Scrum Events zu ihren vorgesehen Zwecken. Im Zweifel heißt das vor allem beim Sprint Review dafür zu sorgen, dass die richtigen Menschen anwesend sind.
- Erarbeite mit dem Team gemeinsam eine Orientierung. Es muss klar sein, wozu das Team existiert und wo es hin möchte.
- Erarbeite eine Kultur stetiger Verbesserung, sowohl des Produkts als auch der Teamprozesse.
Wir helfen dir gerne, herauszufinden, welche Hebel in Bewegung gesetzt werden können, um dein Team weiterzubringen. Ruf gerne Laura an und diskutiere deinen Fall.
Das Problem
- 35 Teams waren in mehreren ARTs organisiert
- Die meiste Zeit verbrachten die Mitarbeiter in Meetings
- Aufgaben und Verantwortlichkeiten waren unklar
Die Lösung
- Differenzierung zwischen Rollen und Köpfen
- Zusammenlegung von Verantwortlichkeiten
- Klarstellung von Aufgaben und Verantwortlichkeiten in Workshops
- Streichung von überflüssigen Meetings
- Qualifizierung der Rolleninhaber
Die Situation
Bei einem Unternehmen der Versicherungsindustrie arbeiteten 35 Teams in mehreren „Agile Release Trains“ (ART) nach den Vorgaben des „Scaled Agile Frameworks“ (SAFe). Es gab dort eine Vielzahl von Problemen, die schon beim Schnitt der Teams und ARTs verursacht wurden. Zwar hatte dort jeder Mitarbeiter mindestens eine, oft sogar mehrere, SAFe-Schulungen erhalten, jedoch war die Implementierung in der Praxis verbesserungsfähig. Die Hauptprobleme aus Sicht der beteiligten Personen waren einerseits die vollen Kalender, so dass „keine Zeit zum Arbeiten“ blieb und andererseits ständige Auseinandersetzungen zwischen den Inhabern bestimmter Rollen, da diese sich uneinig darüber waren, wer denn nun welche Aufgabe und Verantwortlichkeit wahrnehmen musste. Das führte stellenweise sogar dazu, dass Aufgaben gar nicht gemacht wurden, da niemand sich verantwortlich fühlte.
Betroffen waren vor allem die Kombination Release Train Engineer – Scrum Master – Agile Coach sowie die Zusammenarbeit Business Analyst – Product Owner – Product Manager – Business Owner. Zwar sind alle diese Rollen in SAFe genau definiert, jedoch waren sie durch die Rolleninhaber nicht verstanden. Das führte dazu, dass die betroffenen Personen ständig Termine miteinander benötigten, um sich abzustimmen und zu Entscheidungen zu gelangen. Oft mit dem Ergebnis, dennoch zu keiner Entscheidung zu gelangen, sondern sie auf einen zukünftigen Termin zu vertagen.
Die Lösung
Es war uns nicht möglich, die „Geburtsfehler“, also den Team- und ART-Schnitt, zu korrigieren, da die Organisation hierzu nicht bereit war. Daher fokussierten wir uns darauf, die Organisation in den vorhandenen Strukturen arbeitsfähig zu bekommen. Hierzu führten wir zunächst Workshops durch, in denen möglichst viele der Betroffenen, also zum Beispiel Release Train Engineers, Scrum Master und Agile Coaches, teilnahmen. In diesen Workshops wurden zunächst die Aufgaben aus Sicht der Betroffenen aufgeschrieben. Danach ergänzten wir die Aspekte, die noch nicht genannt waren, die aber in Scrum bzw. SAFe dokumentiert sind. Hier fielen erste Diskrepanzen (z.B. wer für das Schreiben von Epics oder Sprintzielen verantwortlich sein sollte) auf, die wir ausdiskutierten. Zum Schluss definierten wir die Zielbilder der Rollen aus Sicht der Teilnehmenden. Abweichungen von Scrum und SAFe wurden dabei erlaubt und unterstützt, sofern am Ende alle Aufgaben verteilt waren. Auch stellten einige Personen fest, dass sie die Rolle, so wie definiert, gar nicht ausfüllen konnten oder wollten. Hier wurden individuelle Maßnahmen gefunden.
Die danach folgende wesentliche Erkenntnis für die Teilnehmenden war, dass SAFe zwar Rollen beschreibt, aber nicht fordert, dass jede Rolle durch eine eigene Person ausgefüllt wird. Es ist völlig in Ordnung, wenn beispielsweise ein Product Owner gleichzeitig die Rolle des Product Managers ausübt. Ebenso ist es möglich, dass die Summe der Product Owner eines ARTs die Product Manager Rolle abdecken. Gleiches gilt natürlich für die Rollen Scrum Master, Agile Coach und Release Train Engineer.
Nun konnten die Rollen gefüllt und teilweise auch neu besetzt werden. In einigen ARTs wurden verschiedene Rollen durch die gleiche Person ausgeübt, beispielsweise übernahmen RTEs eigene Teams als Scrum Master und einzelne Product Manager übernahmen zusätzlich die Rolle des Product Owners. Ein ART verzichtete komplett auf die Product Manager Rolle und übernahm die Aufgaben als Gruppe der Product Owner. Dies war ursprünglich aus der Not heraus geboren, da eine Product Manager Stelle unbesetzt blieb, stellte sich im Laufe der Zeit aber als eine sehr gute Lösung heraus.
Das Leben der gemeinsam geschärften Rollen wurde anschließend durch drei Maßnahmen begleitet:
- Ausbildung in Form von Trainings (scrum.org) für alle Interessierten.
- Ausbildung in Form von Workshops zu spezifischen Themen, die von den Teilnehmenden selbst definiert wurden.
- Coaching für Personen, die dieses nutzen wollten.
Im Rahmen des Coachings halfen wir den Teilnehmenden auch regelmäßig dabei, durch ihre Kalender zu gehen und unnötige Termine zu streichen oder zu verkürzen.
Der Nutzen
Nach Abschluss der Maßnahmen war die Organisation erheblich stärker dazu befähigt, ihren Auftrag wahrzunehmen, als davor. Der Großteil der Mitarbeiter wusste, was von ihnen erwartet wurde und bemühte sich, diesem Anspruch gerecht zu werden. Je nach individuellen Stärken und Neigungen funktionierte diesmal besser oder schlechter. Durch die ungelösten „Geburtsfehler“ lief die Entwicklung leider nicht so effizient, wie es mit den Menschen im Unternehmen möglich gewesen wäre. Trotzdem stieg der Output der Entwicklungsorganisation erheblich, ebenso die Performance der einzelnen Teams. Ein wesentlicher positiver Effekt war auch, dass die Mitarbeiter nun begannen, Unzulänglichkeiten ihrer Organisation zu erkennen, anzusprechen und zu korrigieren.
Tipps & Take-Aways
Bei der Arbeit mit SAFe ist es immer vorteilhaft zu prüfen, ob SAFe überhaupt benötigt wird und wenn ja, in welcher Ausbaustufe. Ist der Ansatz zwar eigentlich zu groß (Sprichwort: Mit Kanonen auf Spatzen schießen), aber es gibt dennoch Gründe, auf SAFe zu beharren, so ist es hilfreich, eine Zusammenlegung von Rollen zu prüfen (z.B. PM und PO). Zusätzlich empfehlen wir dringend, die Betroffenen nicht nur theoretisch in Trainings auszubilden, sondern auch „on the job“ zu begleiten, um eine gewisse Grundbefähigung sicherzustellen. Idealerweise bis zu dem Punkt, an dem sie anfangen, sich selbst zu optimieren und den Prozess so nachhaltig zu machen.
Stehst du vor einer ähnlichen Skalierungs-Herausforderung?
Scheint SAFe bei euch mehr Probleme zu verursachen, als zu lösen? Dann vereinbare einfach ein kostenloses und unverbindliches Beratungsgespräch mit uns. Wir setzen auf den GMV als primäre Skalierungsmethode und sind uns sicher, dass wir gemeinsam auf gute Ideen kommen werden!
Das Problem
- Ein Projektteam, das unzufrieden mit dem bisherigen Arbeitsmodus ist
- Der Fortschritt unterschiedlicher Projektteams ist intransparent
- Die Integration unterschiedlicher Arbeit misslingt zu häufig
- Ein gemeinsamer Fortschritt ist schwer erkennbar
Die Lösung
- Gemeinsame Reflexion der Schmerzpunkte des aktuellen Arbeitsmodus
- Auflösung eines fähigkeitsbezogenen Teamschnitts
- Zusammenlegung der Teilpläne zu einem gemeinsamen Projekt-Backlog
- Einführung weniger, klarer Strukturen, um das Backlog aktuell zu halten und Abhängigkeiten zu managen
Die Situation
Unser Kunde, ein führendes Unternehmen im Bereich der Fertigung, dessen Produkte sowohl Hard- als auch Softwarekomponenten beinhalten, stand vor großen Herausforderungen. Ein Projektteam mit 25 Personen hatte das Gefühl, dass die bisherige Arbeitsweise nicht den gewünschten Erfolg brachte. Die Zusammenarbeit zwischen dem Hardwareteam, das als Anforderer für das Softwareteam fungierte, und dem Softwareteam, das neben dem Hardwareteam auch noch weitere Anforderungen umsetzen musste, gestaltete sich als schwierig. Die Tester, deren Aufgabe es war, das Zusammenspiel beider Komponenten zu prüfen, standen vor erheblichen Problemen, weil sie häufig nicht wussten, welche Ergebnisse zufriedenstellend waren und welche nicht. Diese Intransparenz zwischen den Bereichen führte dazu, dass die Ergebnisse oft nachbearbeitet werden mussten. Der Projektfortschritt war aus Sicht aller Beteiligten unbefriedigend. Das Ziel des Teams war es daher, einen neuen Modus der Zusammenarbeit zu finden, der die Kommunikation verbessert und die Integrationen erleichtert. Der Lösungsansatz des Unternehmens war es, agile Methoden einzuführen.
Die Lösung
Es gibt eine Vielzahl agiler Methoden, welche kontextabhängig nützlich oder weniger nützlich sind. Um herauszufinden, welche Kombinationen agiler Ansätze für das Projektteam des Kunden hilfreich sein konnten, führten wir gemeinsame Workshoptage mit allen Beteiligten durch. Diese Workshoptage hatten das Ziel, aktuelle Missstände transparent zu machen, agile Methoden zu reflektieren und mit ihrer Hilfe ein verbessertes Arbeitsmodell zu entwickeln.
Dazu führten wir zunächst eine Retrospektive durch, um die größten „Painpoints“ (Schmerzpunkte) zu identifizieren. Mit Hilfe der Stacey-Matrix ordneten wir anschließend die Tätigkeiten der Teams ein und schufen in der Diskussion ein gemeinsames Bild der Komplexität des Projekts. Dies führte uns dazu, tiefer in die zwei wichtigsten in Frage kommenden Methoden einzusteigen: Scrum und Kanban. Gemeinsam wurde reflektiert, inwieweit diese Methoden oder einzelne Bestandteile dazu beitragen könnten, die identifizierten Schmerzpunkte zu lösen.
In mehreren Kleingruppen wurden schließlich Vorschläge für einen neuen Arbeitsmodus sowie einen neuen Teamschnitt entwickelt. Im Ergebnis wurde die strikte Trennung von Software, Hardware und Testing aufgegeben. Die bisher existierenden Projektpläne wurden in ein gemeinsames Backlog überführt, das allen Teammitgliedern stets transparent und zugänglich war. Testing Anforderungen leiteten die Entwicklung von Hard- und Softwarekomponenten, wobei die gelingende Integration in kurzen Intervallen im Fokus stand. Jetzt konnte das Team mit der neuen Arbeitsweise starten.
Es ist sehr selten, dass die zu Beginn definierte Arbeitsweise mittelfristig alle Probleme löst. Daher ist es notwendig, diese regelmäßig zu überprüfen. Um die kontinuierliche Reflexion und Verbesserung der Arbeitsweise zu gewährleisten, wurden daher regelmäßige Retrospektiven eingeführt. Diese sorgten dafür, dass nach dem Prinzip Transparenz, Inspektion und Anpassung eine stetige Weiterentwicklung geschah.
Der Nutzen
Der Nutzen des Prozesses lag darin, dass das Projektteam eine neue Arbeitsweise, gespickt mit agilen Ansätzen, gefunden hatte und damit loslegen konnte. Dadurch, dass die Betroffenen ihre eigene Lösung definiert hatten, gab es keinen Widerstand bei der Umsetzung. Die von Anfang an mitgedachte kontinuierliche Verbesserung sorgte außerdem dafür, dass sich keine große Unzufriedenheit aufbauen konnte.
Die in den Workshoptagen erarbeitete Lösung erhöhte die Transparenz innerhalb des Projektteams deutlich. Dem Projektteam gelang eine Ausrichtung auf gemeinsame Ziele, bei denen eine erfolgreiche Integration der Komponenten im Vordergrund stand. Die Abhängigkeiten zwischen den Teams konnten in wenigen, strukturierten Meetings visualisiert und effektiv gemanagt werden. Außerdem erfolgte eine gemeinsame Priorisierung der nächsten Projektschritte, was die Effektivität des Teams deutlich steigerte.
Tipps & Take-Aways
- Macht euch euren Kontext bewusst: Jeder Kontext ist anders. Das gilt besonders für den Start mit agilen Arbeitsweisen. Es ist nicht sinnvoll, eine bestimmte agile Methode dogmatisch über ein Projekt zu stülpen. Stattdessen solltet ihr die spezifischen Herausforderungen eures Kontexts reflektieren und dann überlegen, welche Methode bzw. Methodenbausteine euch helfen. Nutzt dazu euren GMV (Gesunder Menschenverstand).
- Nutzt Modelle, um Diskussionen anzuregen: Modelle wie das Stacey Chart helfen dabei, ein gemeinsames Verständnis der existierenden Herausforderungen zu entwickeln und daraus die richtige Startkonfiguration abzuleiten.
- Lösungen gemeinsam im Team entwickeln: Die besten Lösungen entstehen durch die aktive Beteiligung des gesamten Teams. Nutzt die Perspektivenvielfalt und unterschiedlichen Skills eures Teams. Das erhöht außerdem das Commitment des Teams bei der Umsetzung.
- Inspect & Adapt: Startet mit der vermeintlich besten Idee und entwickelt euch dann Schritt für Schritt weiter. So passt ihr eure Vorgehensweise stets an die neuesten Entwicklungen eures Kontextes an.
Hast du eine ähnliche Situation in deinem Unternehmen?
Möchtest du deine Arbeitsweise reflektieren oder herausfinden, was für dich in agilen Vorgehensweisen steckt? Dann vereinbare einfach ein kostenloses und unverbindliches Beratungsgespräch mit uns. Da sind auf jeden Fall Ideen für dich dabei!
Das Problem
- Management was denkt besser zu wissen, wie man erfolgreich skaliert, als die Menschen, die die Arbeit machen
- Definition von harten Rahmenbedingungen die erfolgreiche Skalierung verhindert
- Fehlendes Vertrauen in handelnde Personen (trotz positiver Erfahrungen und Ergebnisse)
- Skalierung um der Skalierung willen
- Fehlende Erfahrung bei der Gestaltung des Skalierungs- bzw. Veränderungsprozesses
Die Lösung
- Die Frage nach dem Mehrwert für das Produkt in den Vordergrund stellen
- Skalierung als agilen Veränderungsprozess verstehen
- Vertrauen in den Prozess schaffen
- Rahmenbedingungen und Regeln definieren, die einfach und verständlich sind
- Experten beteiligen und gestalten lassen
- Erfahrungswerte nutzen
Die Situation
Ein Scrum Team bei einem unserer Kunden war über die Zeit stetig gewachsen, bis es die typische Teamgröße deutlich überschritten hatte. Gleichzeitig waren die zu bearbeitenden Anforderungen des Teams sehr divers geworden, kamen von unterschiedlichen Fachbereichen und stellten das Team vor vielschichtige Priorisierungskonflikte. Insgesamt erschwerte dies die Möglichkeit, konstant auf gleich hohem Niveau Mehrwert am Produkt zu liefern. Das Gefühl innerhalb des Teams war entstanden, mehr Mehrwert für das Produkt schaffen zu können, wenn es kleiner wäre. Das Team hatte bereits einen hohen Reifegrad erreicht, sich ständig weiter verbessert und positive Ergebnisse erzielt. In der Konsequenz entstand aus dem Team heraus die Idee, sich in mehrere kleineren Teams aufzusplittern. So weit so gut, zumal parallel auch im Management die Ansicht wuchs, dieses große Team aufteilen zu müssen. Man war sich also einig, eine Skalierung muss her und dabei sollte es klare Zuordnungen geben, wie Applikations- und Aufgabenbereiche zu verteilen sind.
Bevor ein strukturierter Skalierungs- und damit verbunden Veränderungsprozess gestartet werden konnte, entstand allerdings ein Konflikt zwischen dem Team und dem Management. Dabei ging es um die Frage, wie die Teamskalierung durchzuführen sei. Die Perspektive des Teams war, beteiligt sein zu wollen und die Frage, wie eine sinnvolle Aufteilung von statten gehen kann, maßgeblich mitzubestimmen. Die Perspektive des Managements war, dass diese Entscheidung bei bestimmten Personen, dem Management selbst liege und nicht beim Team.
Man war sich darüber einig, dass es eine Auftrennung geben musste, nur nicht über den Weg bzw. das Wie. Das Team wollte sich die Selbstbestimmtheit in der Zusammenarbeit bewahren mit Blick auf den Mehrwert des Produkts. Das Management wollte sich mit der eigenen Perspektive auf den richtigen Weg durchsetzen, die Oberhand behalten qua der Hierarchie. Alle hatten gleichermaßen wenig bis keine Erfahrung bei der Gestaltung des Prozesses. Das Verständnis fehlte, dass der Mehrwert des Produktes den wir steigern wollten und die Beteiligung der Menschen mit ihren Erfahrungen den Rahmen setzt, wann, ob und wie eine Skalierung sinnvoll ist und im Folgenden erfolgreich sein kann.
Die Lösung
Über individuelle Gespräche und gemeinsame Termine mit Fachbereichen haben wir transparent gemacht, was die aktuellen und zukünftigen fachlichen Anforderungen zur Weiterentwicklung des Produkts sind und erarbeitet, was den Mehrwert für die Kunden weiter steigern wird. Im Rahmen einer Retrospektive haben wir die bisherige Erfolgsfaktoren der Teamzusammenarbeit herausgearbeitet. Wir haben uns auf einen gemeinsamen Termin verständigt, während dem das Team sich auf 2 oder 3 Teams aufteilen sollte. Es wurde eine grobe fachliche Abgrenzung zwischen den Teams gefunden, die immer noch durchlässig genug war, um zu skalieren, sich also auch gegenseitig aushelfen zu können.
Um dies zu erreichen, haben wir klare Regeln definiert, die unsere Teams erfüllen sollten, um erfolgreich zu sein:
- Mindestanzahl an Entwicklern im Team
- Mindestanzahl an Entwicklern im Team mit fortgeschrittenem, fachlichem Knowhow
- Mindestanzahl an Entwicklern im Team mit Skill Testing
- Mindestanzahl an Entwicklern im Team mit Skill Betrieb
- Mindestanzahl an Entwicklern im Team mit Skill UX-Design
- Jedes Team hat einen Product Owner
- Jedes Team besitzt alle Skills, um die gegebenen Aufgaben eigenständig fertig zu stellen
- Alle Teams können sich gegenseitig unterstützen
- Jedes Team kann jede Aufgabe übernehmen
- Jeder ist beteiligt und kann Einfluss nehmen, in welchem Team man mitarbeiten will
Oberste Direktive war, dass im Rahmen der Skalierung jedes Team in der Lage sein würde, jedes Feature zu bearbeiten und die entsprechenden Anforderungen abschließen zu können in der eigenen Geschwindigkeit. Dazu teilten sich während des Termins alle Experten so auf, dass die Regeln erfüllt wurden. Wir haben dabei immer wieder hinterfragt, ob sich die Teams in der Lage sehen, insbesondere die oberste Direktive erfüllen zu können. Das Ergebnis waren 3 Teams, die sich eigenständig gefunden hatten und die mit Beginn des nächsten Sprints starten konnten. Operativ wurden neue Events etabliert, um die Komplexität zu reduzieren. Die Product Owner trafen sich regelmäßig, um über fachliche Anforderungen zu sprechen und das gemeinsame Product Backlog zu priorisieren. Die Teams trafen sich täglich neben ihren eigenen Dailies zur übergreifenden Abstimmung, um am Ende des Sprints ein integriertes Produkt liefern zu können. Auch die Planung erfolgte in übergreifender Abstimmung, um mit Abhängigkeiten bewusst umgehen und die Fertigstellung im Sprint sicherstellen zu können.
Der Nutzen
Es entstanden 3 Teams, die aus Überzeugung miteinander teamübergreifend zusammenarbeiten wollten, um weiter mit maximaler Motivation den Mehrwert des Produkts zu steigern. Dies konnte nach anfänglicher Auseinandersetzung über das „Wie“ des Prozesses schlank und schnell erreicht werden. Dabei wurde auch das Vertrauen in den Prozess und in die Menschen hergestellt. Nach einer Übergangsphase der Veränderung waren die Teams wieder voll produktiv und kamen in den Zustand, kontinuierlich die Anforderungen abzuschließen, die man sich vornahm und noch mehr.
Tipps & Take-Aways
Wenn der Gedanke aufkommt, skalieren zu wollen, stelle dir immer die Frage, wozu und welchen Grad an Professionalität dein Team bereits erreicht hat. Skaliert ihr des Skalierens willens, weil das Management das als erforderlich ansieht, dann skaliert ihr womöglich die Probleme, die ihr zuvor schon hattet, ohne einen Hauch von Verbesserung für das Produkt. Der zentrale Gedanke bei der Skalierung muss sein, dass eine Aufteilung auf mehr Teams es weiterhin und/oder besser ermöglicht, Mehrwert für die Kunden zu schaffen und das trotz steigender Abhängigkeiten und höherem Kommunikations- und Interaktionsaufwands. Lasse die Beteiligten das richtige Setup gestalten, indem du den Rahmen gestaltest, der das ermöglicht.