Produkt Dekomposition: Warum ein Product Owner das Thema beherrschen sollte.

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.

Gemäss Wikipedia ist der Begriff in der Informatik folgendermassen definiert:„Sequentielle Zerlegung eines Systems in seine Teilfunktionen.“

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!

Wie merke ich als Scrum Master ob mein Team gut ist?

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.

Wir starten jetzt einfach mal; Unbewusste Inkompetenz

Täglich grüsst das Murmeltier. Als Scrum Master oder als Coach kommen wir immer wieder zu Teams welche mit Scrum gestartet sind.  Irgendwo nach Sprint 7 realisieren das sie ihren Zielen nicht näher kommen. Das sich statt Freude immer mehr Frust aufbaut.

Wo steht das Team? Was können sie schon und was lernen sie gerade? Das sind so die ersten Fragen die ich mir stelle wenn ich zu einem neuen Team stosse. Mit fast 100% iger Sicherheit wird mir gezeigt, wie gut sie schon Scrum verstanden haben und wie toll sie das alles schon machen. Auch die Erklärung, warum sie die Retro nicht machen, doch, doch das macht schon sinn. (nicht)

Dieses Verhalten schien mir ein grösseres Pattern zu sein, das mir in fast allen Firmen und in den Teams begegnet. Warum glauben Teams oder auch Führungskräfte, das sie in dem Thema Agilität nach minimalem Invest schon kompetent sind? Ich habe Jahre gebraucht um die agilen Grundzüge zu verstehen und richtig anwenden zu können, bin ich denn doof?

Auf der Suche nach einer Erklärung bin ich über das Kompetenzstufen Modell gestolpert.

Die erste Stufe des lernens wird „unbewusste inkompetenz“ genannt:

Unbewusste Inkompetenz: Mangels Anreize versteht das Individuum nicht, worum es geht, oder weiß nicht, wie etwas bewirkt werden soll; ebenso erkennt es seine eigenen Defizite nicht oder hat ein Problem, sie zu erkennen. Für die Tendenz, sich trotz Unkenntnis als kompetent einzuschätzen, hat sich populärwissenschaftlich der Begriff Dunning-Kruger-Effekt eingebürgert. Personen mit unbewusster Inkompetenz handeln auch intuitiv falsch.

(Quelle Wikipedia)

Wenn es nun eine gegebene Tatsache ist, das Menschen und damit auch die Teams in der Entwicklung zuerst in der Stufe der Unbewussten Inkompetenz bewegen, dann müssen wir uns als Scrum Master und Coaches dieser Situation bewusst sein. Wir sollten Methoden und Werkzeuge erlernen um diese Entwicklungsphase der Teams zu überwinden.

Aus meiner Erfahrung ist es massiv einfacher mit Menschen zu arbeiten, welche sich zur nächsten Stufe entwickelt haben; die Bewusste Inkompetenz.

Eventuell sollte ich mir überlegen eine Ausbildung in Entwicklungspsychologie zu starten, damit ich meine erste Phase in diesem Thema hinter mich bringen kann. Denn auch ich schreibe diesen Artikel zu diesem Thema im Wissen über meine Inkompetenz zu dem Thema…. bin ich nun schon eine Stufe weiter?

Du bekommst was du verlangst, du ermutigst, was du tolerierst.

Diesen Satz habe ich kürzlich gelesen. Er soll von einem Coach im American Football stammen.

Mit dem ersten Teil konnte ich mit sehr schnell anfreunden. Als Coach überlege ich mir dauernd was das Team nun braucht und wie und was ich tun kann um die nächsten Verbesserungsschritte zu schaffen. Das können viele Scrum Master und Coaches. Vorbildfunktion sein und streben nach Verbesserung.

Der zweite Teil hat mich hingegen länger beschäftigt. Ermutigen wir als Coaches oder Scrum Master was wir tolerieren?

Ich glaube das Zitat ist auch hier richtig. Was erleben wir an den Daily Standups? Team-Members kommen zu spät und keiner sagt was. Früher oder später beklagen sich die Scrum Master das ihr täglicher Event zu einem Open Space verkommen ist; Es startet wenn es startet…

Ein anderses Beispiel. Wie viele Scrum Master oder auch Team Mitglieder beschweren sich über Notebooks oder Smartphones an Meetings? Fast in jeder Firma höre ich die Klagen. Doch was passiert an den Meetings? Wir tolerieren die Verwendung der Geräte. Wir gehen nicht aus der Komfortzone und sprechen das Thema an. Wir tolerieren ein Verhalten.

Hier sollten wir uns als Coaches und Scrum Master öfter an die Werte erinneren. Mut, Fokus und Respekt. Wir sollen, nein, wir dürfen Verhalten welches unsere Zielen nicht unterstützt, nicht tolerieren. Sonst ermutigen wir die Menschen zu diesem Verhalten.

Lasst uns in unserer Arbeit achtsam sein was wir tolerieren und wir sollten weniger Toleranz zeigen gegenüber Verhalten welches dem Lernen und der Verbesserung im Team und Produkt entgegenwirkt.

 

Was ist das nächste „Grosse Ding“ im Postagilen Zeitalter?

Als Coach wurden mir in der letzten Zeit öfter die Aufgabe gestellt, nicht die Maturität der Teams in Sachen Scrum zu verbessern, sondern ich soll den Teams helfen endlich den Schritt in die Selbstorganisation zu wagen.

Mir ist ein Blog von Guido Bosbach zu diesem Thema auf Linkedin.com aufgefallen. (Link zum Blogpost ) Da schreibt er, das Agilität im Zentrum vieler neuer Bewegungen steht und das wir uns als Gesellschaft und vor allem als Führungskräfte auf  Veränderung einstellen können oder gar müssen.

Ausgehend von seinem Bild möchte ich nun auf die Veränderung im Bereich Management Modell eingehen. In den meisten Firmen welche bereits seit vielen Jahren Scrum machen wird mir folgendes Bild vorgelegt:

Klassische Linienorganisation

Klassische Aufbaustrukturen. Klare Linienfunktion und auch von den Örtlichkeiten ist immer klar ablesbar, wer in der Organisation welchen Platz inne hat.

Überlegen wir uns kurz wie hilfreich diese Organisationsstruktur ist, damit sich die Team-Mitglieder berufen fühlen Entscheide wie selbstorganisierte Teams zu fällen.

Richtig, es passiert nichts. Selbst wenn die Führungskräfte aus vollem Herzen die Selbstorganisation herbeiwünschen, das Resultat stellt sich einfach nicht ein.

Initiale Selbstorganisation

Es wird ein grosser Workshop organisiert, den Menschen wird nochmal erklärt, das sie nun wirklich selber Entscheide fällen dürfen, ja das dies sogar von ihnen verlangt wird.

Die Idee ist gut. Nur hat von den Teams und von den Führungskräften keiner Erfahrung wie die neuen Aufgaben und Verantwortungen wirklich gelebt werden sollen.

Das Ergebnis sind unzufriedene Mitarbeitende und Führungskräfte, die an ihren Entscheidungen und an dem Konzepten der Sebstorganisation zweifeln. Wenn dieser Zustand länger anhält, dann entwickelt sich die Organisation vermutlich eher wieder zurück zu einer klassischen Linienorghanisation mit Teams die fast Scrum machen.

Manager führt das Team

Mutige Führungskräfte wollen an dieser Stelle natürlich nicht aufgeben. Das haben andere ja auch geschafft. Das kriegen wir auch hin. Dann machen sie den Fehler in ihre alten Führungsmuster zurück zu fallen. Sie deklarieren sich als Mitglied des Teams und sagen von heute an wohin das sich die Firma, das Produkt und das Team entwickeln soll.

Damit ist das Team natürlich auch kein selbstorganisiertes Team geworden. Die Teammember warten in kniffligen Situationen immer noch darauf das die Führungskraft die Kohlen aus dem Feuer holt oder wichtige Entscheide dem Team abnimmt.

Selbstorganisation durch klare Regeln und neu erlerntem Verhalten

Damit gibt es nur noch einen Schritt. Entscheide müssen anders gefällt werden. Jedes Teammember muss und soll an den Entscheidungen mitwirken und die Konsequenzen mittragen wollen. Dies bedeutet für mich ganz klar, das hier den Führungskräften eine neue Aufgabe zufällt. Sie müssen den Teams helfen die Fähigkeiten zu entwickeln um Entscheide zu treffen und die neuen Rollen zu leben.  Dies bedeutet natürlich auch dass die Führungskräfte sich mit dem Thema wesentlich auseinandersetzen. Sie sind der Change den sie haben wollen und leben diesen vor.

Ich denke das uns das Thema Selbstorganisation als Agile Coaches immer mehr begegnen wird. Ich vermute, das es als Coach nicht mehr reichen wird den Teams Kanban und Scrum zu vermitteln. Wir müssen uns darauf vorbereiten Teams und Führungskräfte in die Selbstorganisation entwickeln zu können. Und diese Veränderung beginnt zuerst bei uns, den Coaches.

Selbstorganisation, das „Grosse nächste Ding“ nach Agile. 🙂

Näheres zum Thema kann hier gelesen werden oder zu Sigi an einen Workshop.

 

Global Scrum Gathering Minneapolis 2018

Ich konnte dieses Jahr am Global Scrum Gathering in Minneapolis teilnehmen. Ich war gespannt wie die Amerikaner einen solchen Event durchführen und welche Themen die Scrum Welt in den USA beschäftigen.

Nachhaltig zum Denken angeregt hat mich dann allerdings die Eröffnungs-Keynote von Billy McLaughlin.  Billy ist ein Gitarrenvirtuose der in den 90er Jahren viele Erfolge feierte. Anfangs der 2000er Jahre verlor er die Feinmotorik über 2 Finger an seiner linken Hand.

Seine Karriere, sein Berufsleben war vorbei. Er ist von Hand-Spezialist zu Chirurgen und hat jede Spezialisten besucht und konsultiert damit der das Problem an seiner linken Hand gelöst kriegt. 2002 wurde bei ihm eine Neuromuskuläre Krankheit diagnostiziert welche die rechte Hirnhälfte betrifft und seine Feinmotorik in der linken Hand zerstört.

Billy schaute schelmisch ins Publikum und fragte; Wie oft suchen wir die Lösung für ein Problem an der Hand und stellen dann fest das die Ursache der Probleme gar nicht da liegt sondern in der Steuerzentrale, im Gehirn?

Billy hat mit Scrum sein Gitarrenspiel neu entwickelt und von Anfang an eine neue Art des Gitarrespielen entwickelt, indem er einfach sein Gehirn „umprogramiert“ hat und neue Wege gesucht hat mit seinen Limitierungen wieder ein Weltklassegitarrist zu werden. 2013 erhält Billy einen Emmy für sein neustes Album. Alleine dieser Beitrag war die Anreise nach Minneapolis wert.

Für mich als Coach hat diese Keynote viele Einsichten vermittelt.  Doch zurück zu der Geschichte mit der Hand und dem Gehirn. Wie oft arbeiten Scrum Master und Coaches mit der „Hand“, den Teams, und versuchen Probleme zu lösen deren Ursprung gar nicht dort zu finden ist? Wir sollten uns viel öfter fragen wo die Probleme wirklich herkommen. Versuchen wir mit den Teams ein System zu reparieren, das an einer ganz anderen Stelle Defekte aufweist? Probleme in der Ausführung fangen oft schon weit vor der Umsetzung an. Wir sollten hinschauen wie Produktentwicklungen gestartet werden und wie Projekte geführt werden. Die Arbeit mit den Teams ist und bleibt ein wichtiger Bestandteil unserer Arbeit. Wenn es um Agile Transformationen und Digitalisierungthemen in Firmen geht solten wir das Augenmerk viel mehr auf das „Gehirn“ richten. Da liegt der grösste Hebel zur Transformation und zum Change.

Wie entwickle ich mich als Scrum Master?

Als Coach frage ich mich ab und zu in welche Richtung ich mich entwickeln will. Die Frage ist bloss.. wo stehe ich jetzt und wohin kann ich mich entwickeln?

Im Gespräch mit einem anderen Coach habe ich dieses Bild gesehen.

Das Bild stammt aus dem The Agile Coaching Institute (ACI).  Wie die meisten habe auch ich als Agile & Lean Praktiker begonnen. Zuerst habe ich mich etwas in die Richtung „Content“ entwickelt und wollte anderen zeigen wie es „richtig“ geht. Dabei habe ich festgestellt, das es nicht so nachhaltig ist, den Menschen einfach zu zeigen wie „es“ geht.

Ich habe mich dann mehr in Richtung „Process“ zu interessieren begonnen.

Damit bin ich zum ersten Mal mit Coaching in Berührung gekommen. Mit dem obigen Bild kann ich nicht nur zurückblicken und erkennen welchen Weg ich zurückgelegt habe, ich kann auch erkennen, wo ich mich in Zukunft weiterentwickeln möchte. Ich kann mich in diesem System finden und ausrichten. Das gibt mir Sicherheit in meinen Entscheidungen zu meiner Entwicklung.

 

Das Ikigai Konzept, oder warum ich morgens aufstehe

Auf der Webseite des WEF Forums bin ich auf einen Beitrag gestossen.

Da wurde das Ikigai Konzept aus Japan vorgestellt. Es ist eine Visualisierung, warum ein Mensch morgens aufsteht und warum er in seinem Leben einen Sinn finden kann/soll.

Spannend finde ich vor allem die Zonen in welchen ein Teil der Hauptkreise fehlt. Also die Hauptkreise;  „Ich bin gut darin“, „Was ich liebe“, „Wofür ich mich berufen fühle“  bilden eine Schnittmenge, aber der Kreis „Wofür ich bezahlt werde“ ist beispielsweise nicht enthalten.  Wenn meine Freizeitaktivitäten in diesem Bereich angesiedelt sind. Prima.

Auf einer persönlichen Perspektive kann aus der Visualisierung sehr viel entnommen werden um sich über seine berufliche oder private Situation zu reflektieren.

Aus meiner Arbeit als Coach habe ich mir immer überlegt, was sind die Faktoren die aus einem Produkt eine „Wow-Produkt“ machen. Wenn wir in der agilen Welt den Benutzerzentrierten Ansatz ernst nehmen, dann müssten Produkte eigentlich auch dem Ikigai Konzept folgen.

Im kommerziellen Umfeld ist es dann natürlich sehr übel, wenn wir im Hauptkreis „Wofür ich bezahlt werde“ keine Argumente finde. Ich werde in den kommenden Wochen bei Itaeration Zero Events und Produktentwicklungs Mandaten auf die Ikigai Kreise achten. Mal sehen ob das einen Zusammenhang hat.

Wer bereits Erfahrungen oder Ideen hat, hinterlasst einen Kommentar.

 

Sprichst du fliessend „Agile“?

In den letzten Wochen wurde ich gelegentlich darauf angesprochen, worauf ich als Coach achte, wenn ich ein Team zum ersten Mal besuche oder an einem Zeremonien-Tag begleite.

Ich konnte die Frage nicht beantworten, da ich mich oft von der Situation in der die Teams gerade sind leiten lasse.

Ich habe dann versucht herauszufinden ob ich einem Muster folge. Dabei bin ich über den Begriff „Agile Fluency Project“ gestolpert.

Das Modell schlägt vor, das ein Team einem Lernpfad folgen sollte. Martin Fowler hat auf seiner Seite  den einzelnen Stufen auch noch Sternchen verpasst. Damit kann ein Coach einem Auftraggeber auch gleich sagen wie viele „Sternchen“ das Team hat.  Damit ist das Thema Metriken abgedeckt und Gamification ist auch nicht weit, da jedes Team sicher nach dem nächsten Stern greifen will.

  • Die Grafik zeigt in etwa wie ich bei der Teamdiagnose starte.
  • Wer ist im Team? Welche Kultur herrscht im Team?
  • Welche Fähigkeiten sind im Team vertreten? Welche fehlen?
  • Liefert das Team Wert? Wo finde ich Verschwendung?
  • Wie passt das Team in die Wertstromkette der Firma? Sind sie vernetzt im Produktionssystem?

Das Bild von Martin Fowler mit den Sternen.

Ich kann nun einige meiner Aktivitäten und Themen anhand des Modells der „Agile Fluency“ erklären. Auch wenn ich die Coachings in der Vergangenheit analysiere, dann stelle ich fest, das ich diesem Modell oft gefolgt bin.

Nun kann ich sogar erklären wie ich vorgehe, wenn ich meine Arbeit mit einem Team beginne.

Anmerkung: In dem Modell werden Skalierung und Koordination in einem Multi-Team Umfeld nicht sehr ausführlich beschrieben.

Hier noch der Link zur Beschreibung der Sterne ganz unten auf der Seite

 

 

Mit SAFe eine agile Firma werden?

Ich hatte gestern das Vergnügen an einer Firmenpräsentation eingeladen zu sein. Das Thema war der Agile Weg dieser Unternehmung. Drei Coaches haben aufgezeigt wie sie die ca 400 Personen der Unternehmung in die Agilität geführt haben.

Neben der Präsentation der Firma war ein grosser Teil der Zeit das Thema Change. Wie schwer es ist die Mitarbeitenden der Firma auf die Veränderung einzustimmen, sie abzuholen und ihnen durch das Tal der Tränen zu helfen.

Tönt alles nach einer ganz normalen Veränderungsgeschichte.

Dann kam der Satz; Nach zwei Jahren haben wir nun die SAFe – Einführung abgeschlossen und wir sind nun eine agile Firma.

Im Kontrast dazu dieses Zitat: „Agilität ist eine Kulturform und kein Werkzeug“

Meine Nachfrage, ob nun die Mitarbeitenden auch die agilen Methoden und Mindset angenommen haben, wurde erklärt das sie die Werkzeuge prima beherrschen, aber die Kultur und die Haltung noch nicht wirklich agile sei.

Genau in dieser Situation sehe ich die Gefahr eines Frameworks wie SAFe, das in einer Unternehmung eine Methodenkompetenz aufgebaut wird, die Werkzeuge werden für teures Geld geschult und nach zwei Jahren ist die Firma „agile“.

Die Menschen die darin arbeiten sind es leider (noch) nicht.