Aller Anfang ist schwer. Das wissen wir alle. Du kommst als Scrum Master zum neuen Team. Auftragsklärung war gut, Mission ist klar. Beim ersten Planning üben sich die Teammembers in Zurückhaltung. Kaum jemand sagt was. Einizig der Lead-Architekt weiss ganz genau was zu tun ist.
Da fange ich als Scrum Master an etwas nervös zu werden. Haben wir hier im Team ein Hirn und der Rest sind Finger und Füsse? Warum hat niemand vom Team eine andere Meinung als der Architekt? Wenn alles klar ist, ja dann… könnten wir auch klassisch entwickeln. Der PO meinte im Vorfeld ganz klar: Es ist was komplexes, wir wissen noch nicht wie wir das machen werden.
Ok, es scheint an der Zeit zu sein als Scrum Master über eine Team-Intervention nachzudenken. Problem; es spricht nur einer. Alle andern sagen nichts, schauen weg, oder beantworten Mails auf dem Notebook. Ich sehe nicht alle Synapsen bei der Arbeit, mindstens nicht bei der gemeinsamen Arbeit.
Neues Team beim Planning
Hypothese als Coach: Die anderen sagen nichts weil keiner den anderen kennt und keiner weiss was die anderen Denken und wissen oder gar was sie können. Eine Vorstellungsrunde wird da nicht reichen. Wir müssen wissen wer hier welche Skills mit in das Team bringt.
Intervention: Ich unterbreche den Redefluss des Leadarchitekten mit der Frage ob sie schon einmal zusammen gearbeitet haben und sich daher als Fachleute schon kennen. Die Team-Members kennen sich als Menschen, aber haben noch nie zusammen gearbeitet. OK. Mein Vorschlag ist nun das wir uns alle 5 Minuten Zeit nehmen und jeder schreibt aus seiner Sicht auf, welche Skills in diesem Team notwendig sind um erfolgreich liefern zu können. Nachdem die Timebox abgelaufen ist tauschen sich immer 2 zu den Skills aus, welche sie für relevant halten. Doppelte Beiträge werden zusammengefasst. Ev kommt ja noch was anderes zum Vorschein. So ca nach Ablauf von 5 Minuten stellen nun diese Paare die „Soll Skills“ aus ihrer Sicht vor. Das Ergebnis: Wir haben einen aktuellen Stand was das Team denkt was es braucht um die Aufgabe zu stemmen.
Im zweiten Schritt legen wir alle Skill Karten in die Mitte des Tisches. Jeder zieht sich das Kärtchen wo das Teammember glaubt Fähigkeiten zu haben. Jedes Teammember legt die Karten offen vor sich auf den Tisch. (Transparenz der Skills)
Nun entsteht meistens ein anderes Problem. Es liegen noch Kärtchen auf dem Tisch. Ups. Im dritten Schritt schauen wir uns als Team an, wer sich um welches Skill Kärtchen kümmern möchte. Optionen sind; selber schlau machen oder jemanden suchen der diese „missing skills“ hat.
Ev ist die Zeit für das Planning nun schon rum. Kein Problem. Neuen Termin machen. Die Teammember bringen ihre Skill Karten zum Planning mit und legen diese vor sich hin. Wenn wir nun über das Produkt reden weiss jeder wozu seine Meinung gefragt ist und wo sogar erwartet wird das dieses Teammember was dazu sagt.
Das nächste Planning sollte nun viel lebhafter und intensiver sein.
Wenn nicht… dann war die Coaching Hypothese wohl nicht zutreffend. Dann schauen wir dem Team nochmal zu und stellen eine nächste These und planen die nächste Intervention. Das sehen wir dann in der nächsten Episode. Wenn es heisst; A Scrum Master’s Life!“
Hey sag mal bist du auch ein CSM oder ein CSPO? Ah – du bist ein PSM! Oh und du ein PSPO! Du, die da drüben sind alles SSM’s und ein paar SASM’s. Glaub ein ASPM, PAL und CSP ist auch dabei. Sag mal wo bleiben eigentlich die CLP’s??
Wenn das jetzt alles gibberish war für euch dann bloss keine Angst – wir wollen uns heute mal das Million Dollar Business der Zertifizierungsstellen ein bisschen näher anschauen und uns die Frage stellen – do we really need that?
Wurde schon irgendwann mal ein Unternehmen durch Zertifikate agil?
Wir haben sie alle – wir lieben oder hassen sie – aber mit grosser Wahrscheinlichkeit kaufen wir uns alle 2 Jahre ein neues. Ich spreche von den Zertifikaten der Stammorganisationen wie der Scrumalliance.org, Scrum.org, Scaledagile.com und der vielen kleineren Organisationen. Diese Zertifikate bescheinigen gegenüber dritten, dass wir was können (sollten). Sie helfen anderen Menschen zu identifizieren „was“ für ein Typ du bist und was du drauf hast. Nun wir kennen diesen Mechanismus ja schon seit Jahrhunderten. Auszeichnungen, Orden, Rangabzeichen und Statussymbole sind es. Sie kennzeichnen den Menschen gegenüber aussen und verliehen ihm eine zum Teil unabstreitbare Rolle in der Gesellschaft.
Ihr merkt schon – ich bin persönlich kein Riesen Fan von diesen „Plämpeln“. Und sind wir mal ehrlich – habt ihr schon jemals ein Unternehmen gesehen dass durch Zertifikate „agil“ wurde? Äh nein.
Also, warum braucht es diese und gibt es Alternativen dazu?
Ich glaube Zertifikate – und die damit einhergehende Erwartungshaltung an Wissen, Fähigkeiten und Erfahrung – können in grossen sozialen Systemen für rasche Orientierung sorgen. Ich kann also schnell jemanden finden welcher mir mit einem Problem rasch weiterhelfen kann, der mich coachen und entwickeln kann oder welcher einfach eine andere Perspektive mitbringt als ich selber. Also als „Sozio-Marker“ in der sozialen Matrix durchaus sinnvoll.
Was aber leider noch zu oft passiert ist, dass diese Marker zu „Status-Symbolen“ werden, da natürlich die vorher beschriebene Funktion auch als ein mögliches „soziales Gefälle“ gesehen werden kann oder auch häufig recht natürlich sich so anfühlt. Hier müssen wir sehr bewusst damit umgehen.
A million Dollar badge
Heute ist „Agile“ und die Zertifizierungs-Masche zu einer richtigen Goldgrube für die Organisationen geworden. Jedes Jahr durchlaufen Menschen die meist PowerPoint-getränkten Zertifizierungskurse und sind – schwupps! – nach ein paar multiple choice Fragen „Certified XYZ“. Ich glaube ich muss nicht weiter ausholen.
Gut, aller Anfang ist schwer und auch ein bisschen Druckbetankung am Anfang soll nicht schaden. Die Zertifikatskurse sind in den Jahren auch Praxisnaher gekommen und es gibt auch echt gute Coaches mittlerweile..
Jetzt stellt euch aber ein Unternehmen wie z.B. die Schweizerische Post, die SBB oder eine Volkswagen oder Deutsche Bahn vor. Und überlegt mal wie viele Menschen sich da jedes Jahr zertifizieren lassen wollen und auch re-zertifiziert werden müssen. Ein super Business für die einen – nicht so toll für die Unternehmen! Und für die Agilität so ziemlich ein Null-Summen-Spiel als solches. Kommt noch dazu, dass ja in den meisten grossen Unternehmen ein Mix von Frameworks und „Schulen“ existiert – oder man jedes zweite Jahr das Lager wechselt.. Re-zertify that!
Industrie Standard to the Rescue!
So haben sich im Jahr 2016 ca. 15 Vertreter aus Grossunternehmen aus der DACH-Region zusammengetroffen und haben angefangen an einem Mindeststandard für agiles Arbeiten zu tüfteln. Den aktuellen Stand dieses Mindeststandard könnt ihr hier sehen:
Das Problem mit den Zertifizierungen war nur eines von vielen. Ein viel grösseres war überhaupt eine gemeinsame Sprache für agiles Arbeiten zu finden. Wenn nun ein Unternehmen SAFe nutzte und ein anderes ein eigenes Skalierungsframework, diese beiden Unternehmen aber zusammenarbeiten, dann kann dies zu Problemen in der Kommunikation zwischen den Rollen führen. Ein anderes Problem ist der Wechsel von Mitarbeitern. Mitarbeiter welche z.B. von der Deutschen Telekom zu Daimler wechseln, müssen sich jeweils in neuen Rollen einarbeiten welche vielleicht einfach nur ein bisschen anders ausgestaltet sind. Ihre bisherige Leistung wird aber nicht oder zu wenig honoriert aufgrund von Missverständnissen bezüglich der Rollen und Befähigungsstufen.
Der Mindeststandard für agiles Arbeiten ermöglicht also ein Framework-unabhängiges Verständnis über die wesentliche Gewaltenteilung in der agilen Arbeit und die Rollen darin.
It’s just the beginning
Die Reise der CoP DACH30 Transition to Agile hat erst begonnen.. ich bin gespannt wo die Reise der Transformation der Grossunternehmen noch hingeht. Wer mehr erfahren möchte findet einige Informationen unter next-level-working.com oder meldet sich bei mir.
Der Begriff Zero Marginal Cost wurde von Jeremy Rifkin in seinem 2014 erschienen Buch „Zero Marginal Cost Society“ beschrieben. Erinnern wir uns an die letzte Betriebswirtschaftslehre Stunde an der Uni oder Hochschule: Grenzkosten (Marginal Cost) sind diejenigen Kosten, welche durch die Produktion einer zusätzlichen Mengeneinheit eines Produktes entstehen.
Rifkin hatte schon früh erkannt, dass insbesondere durch die Vernetzung, welche durch das Internet und jetzt immer mehr auch bei physischen Dingen durch das „Internet of Things“, die Digitalisierung erst ihre eigentliche wirtschaftliche Wirkung entfalten kann: immer schneller sinkende Grenzkosten.
Wo die Kosten lagen – wo sie heute sind
Doch was hat dies nun mit Agilität zu tun? Eigentlich so ziemlich alles. Erinnern wir uns an die Zeit als wir noch Software für grosse (relativ) und isolierte Systeme und Anwendungsfälle schrieben. Hier waren die Grenzkosten – also das Erstellen einer weiteren Routine oder einer zusätzlichen Instanz nahezu bei 1:1. Nicht nur die „Herstellung“ der Software war aufwendig, nein auch die Vervielfältigung, Verteilung, Installation und selbstverständlich die (jahrelange) Wartung. All diese „Kosten“ fallen in einer heutigen modernen Architektur praktisch weg. Aber nicht nur das. Die Kosten entstehen heute an „Orten“ wo man es sich das bisher nicht gewohnt war.
Ihr kennt es alle – der Kunde weiss selten was er will – geschweige denn warum eigentlich. Die Komplexität und die Unsicherheit in langfristigen Entscheidungen (Optionen) hat exponentiell zugenommen in den letzten 10 Jahre. Oder, man könnte auch sagen, die Illusion von Stabilität erreicht ganz einfach langsam den Punkt von Realität.. Durch die immer engmaschigere Vernetzung in der Kommunikation hat jeder einzelne von uns Menschen heute ein unglaubliches Wissen welches vor noch nicht mal 10 Jahren komplett unvorstellbar war. Dies ermöglicht eine unglaubliche wirtschaftliche Konkurrenzsituation welche Monopole favorisiert. Mehr dazu in einem zukünftigen Post…
Die Kosten entstehen heute in der Entdeckung der richtigen Lösung oder eben wie es im „Manifesto for Agile Software Development“ in Bezug auf die Software Entwicklung selbst steht:
We are uncovering better ways of developing software by doing it.
www.agilemanifesto.org
Uncover what you think you now
Uncovering ist hier das Schlüsselwort. Zwar geht es schon lange nicht mehr nur um die Software Entwicklung selbst, sondern um den Wert (siehe auch 1. Prinzip) welcher geschaffen werden soll. Und eben genau diese Entdeckungsreise wird heute noch viel zu wenig ernst genommen (OMG wurde Design Thinking in SAFe aufgenommen oder hab ich das geträumt..dafür fehlt jetzt der Kunden :facepalm:).
Hier entstehen heute die Kosten – oder die Quelle für zukünftige Verschwendungen. Daher versuche ich Führungskräften und Teams den Wert des „Upstreams“ und die erstarkte Wichtigkeit von strategischem Denken und Handelns (z.B. mit Wardleymaps) zu erklären. Und hier liegen heute die Grenzkosten sehr hoch da häufig noch keine oder wenige gute Prinzipien und Praktiken vorhanden sind. Gute Ansätze findet man in Praktiken wie Design Thinking, Design Sprints, Lean Startup, etc. Doch der Weg für ein Team, geschweige denn eine ganze Organisation, um diese Techniken auch in das tägliche Denken und Handeln einzubauen scheint aktuell noch sehr steinig zu sein.
In den letzten 10 Jahren haben sich agile Werte, Prinzipen und Praktiken klar von einer Nische zum Mainstream entwickelt. Trotzdem sehe ich noch viele „Agile Shops“ in welchen nicht nur keinen Wert schaffen sondern auch keine Auseinandersetzung mit dem Thema stattfindet. Viele dieser Teams befinden scheinen immer noch im „Delivery“ Level (Agile Fluency) stecken geblieben zu sein. Hey! Es ist bald 2020 – let’s get to the Next Level!
Was meint ihr dazu? Kennt ihr eure Grenzkosten in eurem Vorhaben oder Thema? Freue mich über eure Kommentare – bis bald, Hardy
Ich habe einen interessanten Beitrag zur Agilen Transition bei der Bank ING gefunden. Der Artikel ist eine Übersicht und Zusammenfassung zur Geschichte der Transformation der Bank.
Als Agile Coach, der durch die ganze Schweiz tinggelt, sehe ich viele Unternehmen welche die Verteilung ihrer Verantwortung klar geregelt haben. In der Hierarchie oben wird möglichst alles entschieden und die Teams, welche die operative Arbeit erledigen, dürfen umsetzen was „oben“ entschieden worden ist.
Dieses Verhaltensmuster mag in früheren Gesellschaftsformen gut und richtig gewesen sein. Es gab nicht so viele Mitarbeitende die eine gute Ausbildung genossen haben. Die Entscheidungen wurden oben getroffen und unten wurde umgesetzt.
Unsere Gesellschaft hat sich aber enorm weiterentwickelt. Ganz viele von uns sind sehr gut ausgebildet und bringen sehr viel Wissen und Erfahrung auch im Umgang mit komplexen Problemstellungen mit.
Hier eröffnet sich die Change und auch die Notwendigkeit die Verteilung der Verantortung in einer Organisation ganz neu zu denken.
Mein Denkmodell dazu ist:
Management gestaltet das WARUM (den Kontext) und hilft dem Produkt Owner das WAS zu gestalten. Der Produkt Owner verantwortet (und gestaltet somit auch) das WAS und WANN und Teile des WIE. Das Team übernimmt den grössten Teil der Verantwortung für das WIE.
Verteilung der Verantwortung
Dieses Denkmodell lässt sich sehr gut mit der Produktdekomposition vereinbaren, welche Ruedi von kurzem hier beschrieben hat.
Und dieses Denkmodell hilft, Struktur und Einfachheit bezüglich dem Verständnis der Verteilung der Verantwortung in eine Organisation zu bringen. Die Umsetzung davon ist sehr herausfordernd. Es ist oft nicht mal das Bewusstsein vorhanden, in welcher Ebene sich die Diskussion befindet, geschweige den, ob dies jetzt das richtige Gremium ist, um auf dieser Ebene Entscheide zu fällen.
Wir haben die Teams oft jahrzentelang dazu erzogen, möglichst keine Verantwortung übernehmen zu wollen. Und das Management fühlt sich sehr wohl dabei, im WIE Entscheide zu treffen und diese nach unten zu Delegieren.
Hier helfen agile Werkzeuge wie Retrospektiven diese Transparenz und Awarness über die aktuelle Verteilung der Verantwortung herzustellen und Veränderungen in der Organisation zu bewirken.
Zusätzlich zahlen die agilen Rollen wie Produkt Owner und Team genau auf diese neue Verantwortungsverteilung ein.
Auch der Deming-Cycle – Plan Do Check Act – erklärt einen iterativen Prozess, der kontinuierliches Lernen fördert. Um unseren Kollegen aus dem Fachbereich dem Scrum-Zyklus zu erklären, habe ich begonnen diesen als Unterstützung beizuziehen. Als Ergänzung habe ich noch die vier Sätze ergänzt:
P: Was tun wir als Nächstes?
D: Wir setzten um.
C: Was haben wir umgesetzt?
A: Wie können wir uns verbessern?
Die Scrum-Meetings und die klare Definition von Sprints helfen dabei den PDCA-Zyklus zu institutionalisieren.
Wer kennt es nicht? Wir arbeiten Sprint für Sprint als Scrum Master oder als Coach mit dem Team. Es stellen sich gute Erfolge ein. Die Kunden geben Feedback das ermuntert, wir gehen den Weg weiter. Der PO hat ein zufriedenes Lächeln an den Meetings.
Trotzdem beschleicht uns von Sprint zu Sprint ein Gefühl der Leere. Ist das überhaupt noch sinnvoll was ich hier mit dem Team tue? Bringte ich das Team als Scrum Master noch weiter? Jeden Tag gehen wir zum Daily oder zu einem anderen Meeting und haben das Gefühl Hauptdarsteller im Film „täglich grüsst das Murmeltier“ zu sein.
Ich nenne diesen Zustand „Die Einzelgänger Lethargie“. Duden definiert Lethargie folgendermassen: Zustand körperlicher und psychischer Trägheit, in dem das Interesse ermüdet ist. Dabei werden folgende Eigenschaften beschrieben: gleichgültig, träge, langweilig, schwerfällig, desinteressiert, schlapp, teilnahmslos und viele weitere Worte die nicht sehr inspirierend sind. Im Internet gibt es viele Definitionen oder Synonyme dazu.
Ich konnte diese Phänomene auch bei mir schon beobachten. Denn ich wusste von mir das diese Attribute eigentlich gar nicht so zu mir gehören oder passen. Trotzdem hat es mich enorme Mühen gekostet in der Arbeit gegen die Symptome anzukämpfen. Ich habe lange gebraucht um den Ursachen auf die Schliche zu kommen.
Ich habe angefangen acht zu geben, wann diese Trägheit auftritt und wann sie wieder weg ist. Auffallend oft hatte ich das Gefühl lethargisch zu sein, wenn ich lange und alleine in meiner Rolle oder Aufgabe unterwegs war. Ich konnte mich mit niemandem wirklich über die Herausforderungen und die Probleme meiner Mandate austauschen. Ich war völlig uninspiriert und habe den Team nicht das gegeben was ich als Scrum Master oder als Coach eigentlich geben möchte. Selbst Retrospektiven, etwas was ich eigentlich sehr gerne mache, waren plötzlich eine Last und ich habe den Weg des geringsten Widerstands gewählt und irgendwas genacht was mich wenig Energie gekostet hat.
Es gab aber auch andere Momente. Zum Beispiel wenn ich an einer Scrum User Group war. Da habe ich viele Menschen getroffen die ähnliche Aufgaben zu lösen hatten. Die neue Ideen schilderten und von Erfolgen in ihren Teams erzählten. Ich konnte da auch andere nach ihrer Meinung fragen. Oder wenn ich in einer Firma in der Agilen Gilde oder in der Gilde der Coaches oder Scrum Master besucht habe. Der Austausch hat inspiriert und Lust gemacht Neues auszuprobieren. Auch der Besuch von Konferenzen hat geholfen neue Ideen zu sammeln und Energie zu tanken um neue Aufgaben anzupacken.
Agilität lebt davon das man in einem Team arbeitet und sich austauscht. Aber die Arbeit in einem Team ist nur ein Aspekt von Agilität. Denn wir sind auch Teil einer Gruppe die sich für gewisse Fachthemen interessiert, ausserhalb meines Entwicklungs-Teams. Dort kann ich über meine spezielen Skills reden, lernen und reflektieren. Diese speziellen Skills bringe ich in in meiner Rolle als Coach oder Scrum Master wieder in mein Team. Aber wo kann ich diesen Tank meiner Skills wieder füllen? Wer hilft mir besser zu werden in meiner Rolle? Das Team, in dem ich normalerweise arbeite kann diese Aufghabe nicht unbedingt erfüllen. Die „verbrauchen“ ja meine Ideen und Fähigkeiten. Daher muss ich die Energiequelle anderswo finden.
Immer wenn ich fühle das die „Einzelgänger Lethargie“ sich langsam aufbaut überlege ich mir wo ich wieder Energie herkriege. Wo kann ich mich mit Menschen austauschen welche meine Interessen teilen? Mit diesem Ziel habe ich eine ganze Reihe von Möglichkeiten gefunden meine Inspiration wieder mit Energie zu versorgen. Ich gehe regelmässig zu Scrum User Groups um mich fachlich mit Kollegen zu unterhalten. Ich besuche regelmässig Konferenzen. Dort erhoffe ich mir immer neue Methoden und Ideen zu erlernen und neue, spannende Menschen kennen zu lernen. Dann gibt es noch eine Möglichkeit sich zu regenerieren. Ich treffe mich regelmässig mit Coaches und Scrum Mastern die in einer ähnlichen Arbeitssituation sind. Wir nennen das „Coach Treffen“ Da verbringen wir die Zeit mit „Kollegialer Fallberatung“ Es tut doch immer wieder gut zu sehen das man mit seinen Themen nicht alleine auf der Welt ist. Dieser Perspektivenwechsel bringt sehr viele neue Ansatzpunkte für die Arbeit.
Und sonst…. da gehe ich einfach mal mit anderen Kollegen einen Kaffi trinken und wir erzählen einander wie schwer wir es doch haben und welch grossartigen Heldentaten wir in der letzten Zeit vollbracht haben.
in aller Kürze: Verlasst euer eigenes Silo, geht raus und trefft und redet mit Kollegen und tauscht Ideen und auch mal Sorgen aus. Sucht euch einen Club der euch wieder Inspiration und Energie gibt. Ihr werdet sehen das die Schwere und Müdigkeit des Alltages plötzlich viel weiter weg ist und das Team wieder einen Coach oder Scrum Master hat der inspiriert und von innen heraus wieder leuchtet. das was wir uns doch alle so sehr wünschen… oder? 😉
Es war einmal ein Team, das hat den ganzen Sprint hindurch nur gemotzt und an allem rumkritisiert hat. Das war als Scrum Master jeden Tag eine Tortur mit diesem Team zu arbeiten. Doch die Quälerei hat ja auch was Gutes. Wir können am Tag der Retrospektive ganz viel besprechen.
Der Tag kommt…. und dem Team fällt überhaupt nichts ein, worüber man reden kann und wo es sich lohnen könnte zusammen besser zu werden.
Aus dieser Situation hinaus habe ich mir folgende Retrospektiven Merthode ausgedacht.
Die Methode beginnt am Ende der Retrospektive, wenn mal wieder nichts besprochen wurde. Ich verteile allen in Team einen Block Post-Its. Alle haben die selbe Farbe. In der Mitte des Raumes stelle ich einen Papierkorb oder ein anderes geeignetes Gefäss hin. Der Auftrag an das Team lautet folgendermassen: Jedes Mal, wenn ihr euch aufregt, oder über Dinge ärgert; schreibt es auf eines der Post-It’s, zerknüllt es und werft es in den Papierkorb.
Am Ende des Sprints wird der Papierkorb in die Mitte des Tisches entleert. Wir sortieren die Zettelchen und bilden Themengruppen. Danach bestimmen wir welche Themengruppe es wert ist näher besprochen zu werden und unterhalten uns darüber. Wenn das team dann einen Verbesserungsvorschlag dazu macht, super!
Alternativen in der Durchführung: Jeder sucht sich eine Farbe aus. Damit ist am Ende vom Sprint klar wer, welche Zettel geschrieben hat. Oder jeder macht ein Kürzel auf den Zettel. Es ist nicht anzunehmen das jeder ab dem ersten Tag des Sprints Zettelchen schreibt. Als Scrum Master nehme ich den Papierkorb mit zum Daily und frage aktiv nach ob es schon Zettelchen gibt.
Ich werde mich freuen wenn andere Scrum Master die Methode ausprobieren und in den Kommentaren Feedback geben würden.
Wer im Internet nach dem Begriff „Produkt Dekomposition“ sucht wird im Moment nicht sehr viele Treffer landen. Jedenfalls nicht im dem Zusammenhang wie er in der Agile Produktentwicklung verwendet wird.
Im wesentlichen geht es darum, das sich ein Product Owner (PO) sich damit auseinandersetzt wie er sein Produkt an den Markt bringen möchte. Natürlich gibt es dazu in den entsprechenden Foren und Medien sehr viele Praktiken und Prinzipien die helfen sollen das Produkt gut zu schneiden.
Schauen wir hier einmal die Produkt Dekomposition an. Ausgehend von der Definition zerlegen wir das Produkt in Teilfunktionen. Das ist schon mal sehr gut, da damit klar ist das wir uns überlegen sollten aus welchen Features das Produkt besteht. Damit geraten wir als PO weniger in die Versuchung das Produkt in Komponenten zu zerlegen.
In den Planning Sessions überlegen nun der PO und das Entwicklerteam wie sie das Produkt produzieren und ausliefern sollen. Dabei werden die Funktionen zerlegt und geschätzt. Die entstandenen Backlog Items (PBI) werden dann auch noch sauber im Product Backlog (PBL) nach Wert oder Komplexität eingeordnet. Wir sind bereit für den Sprint.
Je mehr Sprints vergehen kommt das Gefühl auf, das die Produktentwicklung wenig zielgerichtet ist. Was ist jetzt wichtig? Haben wir die richtigen Dinge priorisiert? Warum kriegen wir diese User Story (US) nicht fertig? Werden wir das Minimal Viable Product (MVP) auch wirklich hinkriegen? Das Team diskutiert und schätzt und ordnet. Das Gefühl von Unsicherheit wird nicht kleiner.
Diese Teamszenen kann man als Coach fast jeden Tag in einem Team erleben. Der PO hat den Top Stakeholder versprochen zu liefern, das Team will seine Zusagen einhalten. Die Dialoge in den Plannings und Refinements werden hitziger. PO und Team verlieren sich immer wieder in den Flughöhen bei den PBI Besprechungen. Einmal diskutiert man auf dem atomaren Niveau einer Funktion. Danach prägen Philosophische Exkurse den Dialog im Team. Das Meeting geht zu Ende und man einigt sich hurtig auf die Reihenfolge im PBL und die Schätzungen. Natürlich verläuft der nächste Sprint nicht besser. Natürlich müssen wir besser planen, schätzen und priorisieren. Die Definition of Done (DoD) war ja eigentlich auch nicht so klar. Hat jemand die Akzeptanzkriterien der Story gelesen?
Warum passieren diese Szenen in fast jedem Team? Ich vermute das der Fokus fehlt und sich das Team mit dem PO zu wenig um die Planungsaspekte der Agilen Produktentwicklung kümmert. Das Bewusstsein, wie sich das Produkt zusammensetzt, in welcher zeitlichen Abfolge Was geliefert werden sollte und die Grösse der Produktfunktionen ist oft nicht klar. Es ist möglich, das einzelne Teammitglieder dieses Produktbewusstsein erlangt haben. Es ist jedoch fraglich ob diese Produktinformation vom ganzen Team geteilt wird.
Hier kommt die Idee der Produkt Dekomposition in das Spiel. Das ganze Team muss verstehen was von dem Produkt zu welchem Zeitpunkt geliefert werden muss. Um diesen Dialog möglichst fokussiert und zielgerichtet führen zu können muss das ganze Team verstanden haben wie das Produkt zerlegt wird.
Übersicht Produkt Dekomposition
Dabei wird das Produkt auf verschiedenen Stufen zerlegt. Zuoberst stehen die „Investitions Themen“. Ich Nenne die so, da auf dieser Flughöhe vor allem Stakeholder miteinander sprechen die von der Technologie oder den Details nicht so viel wissen. Das müssen sie auch nicht. Es geht um eine langfristige Ausrichtung und um strategische Themen. Diese Gruppe beschäftigt sich sehr stark mit dem „WAS“ und dem Markt. Dabei ist der Fokus auch auf finanzielle Themen gerichtet. Folgende Fragen interessieren: Wie lange können wir am Markt mit dem MVP operieren? Wann muss mindestens 1000 Kunden auf dem Produkt gebucht sein? Wie messen wir den Erfolg? Wann geht uns das Geld aus? Wann müssen wir skalieren? Diese Themen werden in einem Startup natürlich auch vom Team geführt. Da passiert dieser Dialog von selber. In grösseren Unternehmen sind an diesem Themenbereich meistens Menschen beteiligt die mit der Umsetzung direkt nichts zu tun haben.
Jahresplanung mit Investitions Themen
Eine Ebene darunter befinden sich die Epics. Wenn das Team die Investition Themen gut geordnet hat ist nun der PO mit dem Entwicklungsteam dran. Aus was bestehen die Investition Themen. Wie liefern wir den versprochenen Wert? Aus der Investitionsplanung ist ersichtlich bis wann welches Produktelement geliefert werden sollte. Die Epics werden den Investition Themen zugeordnet und in die Reihenfolge gebracht welche das Team glaubt sei die richtige. Wenn wir uns die Grösse eines Epics anschauen sind das Arbeitselemente welche in 1 bis 3 Monaten geliefert sein sollten. Das Team erkenn, wenn mehrere Epics zu einem Investition Thema gehören und der gewünschte Release gefährdet wird. Das ist nun der richtige Zeitpunkt um mit dem PO zu reden und zu klären ob wirklich so viel geliefert werden soll. Der PO hat mit seinem Team zusammen gelernt und trägt die Informationen nun zu seinem Stakeholder und bearbeitet die neue Situation. Die Klärungen helfen dabei das PBL richtig zu priorisieren und gegebenenfalls die Grösse eines Investition Themas oder dessen Liefertermin anzupassen.
Quartalsplanung mit Epics
Die Ebene unter den Epics nenne ich die User Stories oder Product Backlog Items. Diese Arbeitsstücke sind einigermassen definiert. Das sind Elemente welche innerhalb eines Sprints geliefert werden sollen. Das heisst die maximale Aufwandschätzung sollte 4 Wochen nicht übersteigen. Sogar wenn das Team Kanban verwendet bin ich der Meinung das diese Produktelemente nicht grösser sein sollten. Ab hier macht eine Sprintplanung absolut Sinn. Hier muss auch Klarheit über das „WIE“ liefern wir diese Produktfunktion herrschen. Wenn der PO Epics zum Planning mitbringt sind die Basis-Philosophischen Dialoge schon ziemlich gut geführt. Das Team weiss WAS der PO den Stakeholdern verprochen hat. Der Fokus der Dialoge liegt aus dem WIE liefern wir dieses Produktinkrement? Wenn das Team mit dem PO diskutiert warum das gebaut werden soll, dann ist es vermutlich besser den Sprint nicht mit einem Produktinkrement zu planen von dem nicht sicher ist das der Wert vom Team verstanden wurde.
Sprintplanung mit Product BAcklog Items (User Stories)
Die unterste Ebene in der Produkt-Dekomposition wird durch die Tasks beschrieben. Das sind Arbeitselemente die zu einem Epic zählen und vom Aufwand 1 bis 3 Tage gross sein sollten. Diese Tasks sollte das Team unabhängig eines Stakeholder oder des PO beschreiben und umsetzen können.
Sprint Board
Mit verschiedenen Teams habe ich bereits versucht mit dieser Methode mehr Fokus in die Plannings und Refinements zu bringen. Bisher habe ich sehr gute Erfahrungen damit gemacht. Wenn ein Team diese Strukturen legt, wird oft klar, das die Dialoge mit den unterschiedlichen Stakeholdern nicht gut geführt wurden. Das Erwartungen an Information und Produkt nicht geklärt wurden. Für mich ist dies eines der wichtigsten Lernelemente eines Teams. Klärt die Kommunikations-Strukturen. Werdet euch bewusst mit wem ihr über was sprechen müsst. Speziell für Teams in grösseren Unternehmens Strukturen ist dies wichtig.
Ein sehr guter Nebeneffekt sind die Fragen welche das Team nach oben in das Portfolio richtet. Muss das Investitions Thema wirklich so gross sein? Was gehört wirklich dazu? Es werden Verzichtsdialoge geführt um den tatsächlichen Wert des Produkt-inkrements zu klären.
Probiert die Idee der Produkt Dekomposition mal in euren Teams aus. Über Feedback oder Erfahrungen würden wir uns sehr freuen!
In den vergangenen Wochen habe ich mich wieder mehr mit der Frage beschäftigt, wie merke ich überhaupt ob ich meinen Job als Scrum Master gut mache?
Dann wird es Zeit wieder mal den Scrum Guide zu bemühen und nachzulesen. (Sollte man sowiso ab und zu machen, oder? 😉
Da steht folgender Text:
Der Scrum Master ist dafür verantwortlich, Scrum entsprechend des Scrum Guides zu fördern und zu unterstützen. Scrum Master tun dies, indem sie allen Beteiligten helfen, die Scrum-Theorie, Praktiken, Regeln und Werte zu verstehen. Der Scrum Master ist ein „Servant Leader“ für das Scrum-Team. Der Scrum Master hilft denjenigen, die kein Teil des Scrum-Teams sind, zu verstehen, welche ihrer Interaktionen mit dem Team sich hilfreich auswirken und welche nicht. Der Scrum Master hilft dabei, die Zusammenarbeit so zu optimieren, dass der durch das Scrum-Team generierte Wert maximiert wird.
Der Scrum Master hat also den Auftrag das Team zu entwickeln, damit es Wert generieren kann. Es steht nicht das der Scrum Master damit irgendwann mal aufhören soll. Damit stellt sich dem SM latent die Frage: „Ist mein Team gut?“
Diese Frage ist nicht ganz einfach zu beantworten. Ich könnte mir überlegen an was ich ein gutes Team erkenne. Da gibt es aber sooooo viele Aspekte, da kann ich mich nie entschliessen was ich nun auswähle.
Ich kann mir auch überlegen woran ich ein schlechtes Team erkenne. Da bin ich schon viel schneller am Ziel und kann sagen woran ich eine Teamdysfunktion wahrnehme.
Dazu gibt es ein sehr hilfreiches Buch: Die 5 Dysfunktionen eines Teams von Patrick M. Lencioni .
Im wesentlichen macht er die Dysfunktionen an folgenden 5 Punkten fest:
Mangel an Vertrauen
Angst vor Konflikten
Fehlen von Verbindlichkeit
Mangel an Verantwortung
Nachlässigkeit gegenüber dem Ergebnis
Für mich sind die ersten zwei Elemente diejenigen welche ich am meisten beobachte. Wobei „Angst vor Konflikten“ für ein Scrumteam wirklich sehr übel ist. Denn wer in einem Umfeld von Komplexität und Unsicherheit arbeitet muss fähig sein, zusammen zu streiten.
Streiten geht aber nur wenn die Teammembers sich gegenseitig vertrauen und sicher sind, dass sie sich die Meinung sagen dürfen und es OK ist über These und Antithese zu neuen Erkentnissen zu gelangen.
Da merke ich dann als Coach oder SM das ich auch mit der Tatsache klarkommen muss das sich das Team ab und zu gegenseitig die Meinung sagen kann und muss.
