Agile Reflection

Seit mehreren Jahren darf ich Teams beim Start in die agile Produktentwicklung unterstützen. Sehr oft führe ich zu Beginn eine Iteration Zero durch. Dabei gehen wir gemeinsam den Weg von einer Produktidee über die Produktvision mit Kundenfokus zum initialen MVP-Produkt-Backlog.

Der Fokus dieser Startphase lag bis jetzt bei mir darin das Team zu Formen und ihnen eine vergemeinschaftete Produktvision mitzugeben. Dabei habe ich mich sehr stark auf den Kunden, die Wertschöpfung und das neue Produkt fokussiert. In diesem starken gemeinsamen Committment habe ich ein sehr grosse Energiequelle für die weitere Produktentwicklung gesehen.

Bei meiner letzen Iteration Zero Ende Januar 2019 habe ich diesen Fokus erstmals neu auf das Kundenerlebnis gelegt. Ich habe mit dem Team zuerst das bestehende Kundenerlebnis / den IST-Prozess analysiert und die Painpoints rausgearbeitet. Dabei haben wir einen Film zum bestehenden Kundenerlebnis angeschaut, Konkurrenzprodukte unter die Lupe genommen und dann gemeinsam an einer grossen Wand das Kundenerlebnis aus der Perspektive der unterschiedlichen Akteure visualisiert. (Das Produkt ist ein Medizinprodukt mit Akteur Zahnarzt, Assistent, Patient.) Während dem ganzen Workshop war auch ein Kunde anwesend, der laufend die Ergebnisse mitgestaltet hat.

Als nächster Schritt haben wir dann mit Design Thinking Methoden neue Produktideen generiert. Da wir vorab den Fokus auf den Prozess gelegt hatte sind ganz viele Ideen zur Verbesserung des Prozesses entstanden. Das Produkt per se ist in den Hintergrund gerückt, da das wahre Potential für die Verbesserung im Prozess lag.

Diese Iteration Zero mit Fokus auf Solution / Prozessverbesserung hat mich stark zum Reflektieren angeregt. Mein Fazit bis jetzt: das wahre Potential für Verbesserungen liegt oftmals nicht bei einem Produkt selbst. Dies ist viel zu kurz gedacht. Viel mehr muss der Wertschöpfungsprozess für den Kunden in den Fokus rücken und echte Verbesserung innerhalb dieses Prozesses stattfinden. Dort sind die wahren Schätze verborgen ;-).

Die Konsequenz daraus ist, dass ich beim Design einer Iteration Zero mit dem Auftraggeber noch viel stärker die Integration eines Kunden, bzw. die Auseinandersetzung mit dem Kundenerlebnis im Workshop einfordere. Mal schauen, wo mich das noch hinbringt.

Wie Ying und Yang setzt sich die agile Arbeitsweise aus zwei Teilen zusammen.

Auf der einen Seite haben wir die Methodik oder Praktik, die relativ einfach zu verstehen und vom handwerklichen auch rasch umzusetzen ist. Diese Eingängigkeit ist ein wichtiges Merkmal einer agilen Methode, bzw. zeichnet sie als agile Methode / Praktik aus. Diesen Teil nenne ich die Arbeitsebene oder „doing agile“.

Auf der anderen Seite haben wir die Haltung der Beteiligten und Betroffenen, die oft auch als agile Kultur umschrieben wird. Sie ist per se nicht sichtbar und hat ganz viel mit zwischenmenschlicher Interaktion zu tun. Lebe ich die agilen Werte wie Mut, Vertrauen, Fokus, Kommunikation etc. wirklich? Spreche ich z.B. in der Retrospektive die effektiven, schwierigen Probleme an oder führen wir eine Retrospektive in der Komfortzone durch, einfach damit sie durchgeführt ist. Diesen Teil  nenne ich die Kulturebene oder „being agile“.

Um diesen Sachverhalt zu Visualisieren, verwende ich den Eisberg:

oberhalb der Wasserlinie = doing agile

 

 

unterhalb der Wasserlinie = being agile

 

 

In meiner Coaching Praxis sehe ich sehr oft, dass Agilität mit dem ersten Teil, dem „doing agile“ abgehandelt wird. „Ist die Methode handwerklich in etwa korrekt eingeführt, dann sind wir agil!“

Das wahre Potential der agilen Arbeitsweise kann erst ausgeschöpft werden, wenn wir uns auch agil Verhalten. Und diese Veränderung braucht viel mehr Energie und Achtsamkeit. Und genau hier sehe ich meinen Hauptauftrag als Agile Coach. Dem Team den Raum zu Gestalten, damit sie achtsam und fokussiert diese Veränderung bewirken können.

 

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?

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.

 

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 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.

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.

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.

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.

 

Das Framework Iteration Zero dient dazu, die Lücke zwischen einer Produktidee und dem initialen Backlog zu schliessen.

Nachdem die Methodik seit mehreren Jahren erfolgreiche Starts in der Produktentwicklung von Software-Produkten und Strategien ermöglichte, hat sie jetzt ein neues Universum erreicht: dies der physischen Produktentwicklung.

Ich durfte bei einer internationalen Firma, die Zahnfüllungen und Zahnprothesen herstellt, zwei Produktstarts mit der Iteration Zero befeuern. Wir haben das Framework wie auf iterationzero.works beschrieben angewendet: Anhand des Elevator Pitches haben wir uns mit den Kunden und ihren Bedürfnissen auseinandergesetzt. Dazu haben wir eine Produktvision entwickelt und mittels einer Story Map das MVP erarbeitet. Dann hat uns ein Zahnarzt (Kunde :-)) besucht und wertvolles Feedback gegeben.  Das Feedback wurde von Produktteam verarbeitet und schlussendlich wurde ein initiales Backlog für den Start der agilen Produktentwicklung erstellt. Ja, richtig gelesen, auch bei der Entwicklung von Zahnfüllungen wird agil und mit Scrum entwickelt.

Das Feedback des Produktteams sowie der Stakeholder war, das mit dem Framework Iteration Zero eine neue Ära der Produktentwicklung bei ihnen in der Firma eingeläutet worden ist. Was für ein Kompliment!

Meine Learnings aus diesen Workshops sind:

• Iteration Zero funktioniert hervorragend auch in der physischen Produktentwicklung.
• Kundenfokus, professionelle Moderation und Validierung der Hypothesen mit den Kunden sind auch hier die Schlüssel Erfolgsfaktoren.
• Auch hier hat sich ein enormes Commitment des Teams zu ihrem Produkt entwickelt.
• Der Raum und die Zeit für die Zusammenarbeit an EINEM gemeinsamen Produkt wird als sehr wertschätzend wahrgenommen.

Deshalb darf ich getrost sagen: die Iteration Zero hat sich in die nächste Umlaufbahn geschossen.

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.

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.

 

Gestern durfte ich bei einem Scrumteam coachen. Eines der grössten Probleme dieses Team ist es, dass ihre Entwickler und alle anderen im Team nur 1-2 Tage pro Woche für diese Produktentwicklung leisten können. Alle haben noch x andere Aufgaben, um die sie sich kümmern müssen. Mmhhhh… das Problem begegnet mir in letzter Zeit sehr oft.

Warum müssen wir in der Wissensarbeit immer dieses Multitasking machen? Weshalb erkennen wir nicht, wieviel Energie dabei verloren geht und ändern uns?

Beim Reflektieren ist mir eine schöne Analogie eingefallen:

Wie wäre es, wenn ein Maler 5 Kunden gleichzeitig bedienen würde? Immer streicht er bei einem Kunden eine Wand fertig, muss er bereits zum nächsten. Also alles einpacken, Anreisen, Abdeckung anbringen, Farbe neu Mischen (Achtung, hier sind schon 3 von 4 Wänden gestrichen. Es ist eine grosse Herausforderung, den exakten Farbton bereits zum 4. Mal richtig zu Mischen), die Wand streichen, wieder einpacken, zum nächsten Kunden, auspacken, abdecken, wieder mischen…..

Keiner würde so arbeiten! Alle erkennen auf einen Blick, dass dies extrem ineffizient ist.

Aber wir in der Wissensarbeit arbeiten exakt so. Und haben zusätzlich das Gefühl, dass wir das ohne grosse Ineffizienz Tipp Top hinbringen. Warum sehen wir nicht die Verschwendung? Und warum ändern wir nichts?

Und bekanntlich beginnt jede Veränderung bei einem selbst.

Letzte Woche durfte ich (mit Ruedi) einen Workshop auf der Change Tagung für soziale Arbeit (Thema „Identität in der neuen Arbeitswelt“) anbieten.

Wo haben Agilität und Sozial Arbeit Gemeinsamkeiten?

Sinnhaftigkeit: der tiefe Wunsch nach der Sinnhaftigkeit unserer Arbeit liegt Beidem zugrunde. Sinnhaftigkeit ergibt sich oft auch mit dem Grad der Gestaltungsfreiheit. Bei agilen Methoden wird eingefordert, dass der Mitarbeiter möglichst viel Gestaltungsfreiraum hat und Verantwortung für seine Arbeit / die Teamarbeit übernehmen muss. Dies kann eine ungewohnte Situation sein, der ich als Coach Beachtung schenken muss.

Gruppen-/ Teamarbeit: in beiden Disziplinen ist das Team / die Gruppe (hier als Synonym betrachtet) des Pudels Kern. Geht Agilität ohne Team? Agilität heisst ja, Kompetenzen im Umgang mit Unsicherheit und Veränderung  erwerben, damit Komplexität gewältigt werden kann. Ich bin der Meinung, die Bewältigung von Komplexität funktioniert eh nur im Team. Und wie das Team zusammenarbeitet ist somit ein wichtiger Schlüssel zum Erfolg bei der agilen Produktentwicklung.

Mobiler Arbeitsplatz: Bis anhin haben sich Arbeitnehmer stark mit ihrer Firma identifiziert. Ihr Arbeitsplatz war mehrheitlich an einem Ort, in einem Team verwurzelt. Mit den neuen, mobilen Arbeitsplätzen, Grossraumbüros und Home-Office-Angeboten geht ein Teil dieser Zugehörigkeit verloren (so wurde es an der Tagung postuliert). Ein wichtiger Bestandteil dieser Verwurzelung ist nicht mehr da. Ich kann mir als Coach sehr gut vorstellen, dass ältere Arbeitnehmer mit dieser Situation Mühe haben (ich gehöre auch dazu :-)). Mit den agilen Methoden wie Scrum will man wieder eine grössere Verwurzelung des Individuums mit der Firma (dem Produkt) postulieren. Scrum funktioniert am besten, wenn man einen Teamraum hat und dort physisch vor Ort zusammen arbeitet. Der Austausch soll möglichst face2face stattfinden, so dass alle Kommunikationsebenen zum Zug kommen. Also klar ein Trend weg vom mobilen Arbeitsplatz.

Ich hab an der Tagung gelernt, dass Soziale Arbeit viel Gemeinsamkeiten mit Agilität hat. Aber in beiden Welten sehr unterschiedliche Vokabularien verwendet werden. Und es hier noch ganz viel zu erforschen gibt ;-).