Agile Reflection

Eine Analogie…

Magst du dein Leben? Gestaltest du dein Leben selbst?
Dann bist du ein Product Owner – oder nennen wir‘s Life Owner.

Du hast bereits viele Dinge auf Done. Einiges hat dich weitergebracht, einiges nicht. Das ist ganz okey, wir lernen ja mit dem Älterwerden unsere Zeit dafür einzusetzen, was uns wirklich einen Mehrwert bringt – sei es persönlich, zwischenmenschlich oder beruflich.
Nebst den Dingen auf Done hast du auch einiges in Progress, in Plan oder in deinen Options. Du schreibst dein Life Backlog ständig um… -> Refinement. Du überlegst was du alles noch anstellen möchtest um deinem Leben Sinn zu geben, einfach glücklich zu sein oder dorthin zu kommen wo du gerne möchtest.

Dann gibts bestimmt Dinge, die du in deinem Kalender festhälst -> Planning. Du planst wahrscheinlich so 2-3 Wochen im Voraus -> Selected Life Backlog. Dinge die weiter in der Zukunft liegen sind eher noch unklar -> Backlog. Natürlich gibt‘s einige Meilensteine -> Releaseplan, wie z. B. Urlaub, das ist natürlich bereits fett in deinem Kalender eingetragen.

Ab und zu zeigst du deinen Freunden, deiner Familie oder deinen Arbeitskollegen was du in letzter Zeit so gemacht hast, z.B. Ferienfotos -> Review.

In deinem Leben wirst du immer von irgendwelchen Menschen umgeben oder begleitet. Für deine Weiterentwicklung – in allen Bereichen – sprichst du mit ihnen und überlegst dir was gut läuft und was nicht -> Retrospektive. Du sprichst mit ihnen darüber was du allenfalls ändern könntest -> New Life Backlog Item, um deinem Leben Sinn zu geben, einfach glücklich zu sein oder dorthin zu kommen wo du gerne möchtest.
Viel Spass beim Backlog Management liebe Life Owner.

Heute durfte ich am Mobile Business Forum der Hochschule St. Gallen am Podiumsgespräch teilnehmen. Ich durfte dort mich als Agile Coach der SBB sowie das Framework Iteration Zero, welche ich mit Ruedi Gysi gemeinsam designed habe, präsentieren.

Hier findet ihr die aktuelle Visualisierung der Iteration Zero.

Die Iteration Zero schliesst die Lücke zwischen der Produktidee und dem Initialen Backlog. Die Erfolgsfaktoren bei einer Iteration Zero sind:

• das Team (interdisziplinär, keine Hierarchie, kein Macht Gefüge)
• den Zeit & Raum für die Zusammenarbeit
• Fokus auf den Kunden und den Wert (für die Firma und/oder den Kunden)
• professionelle Moderation der Workshops

In der HSG wird aktuell in einer Doktorarbeit das „neue“ Innovationsframework designed, welches auf der Activity Theory basiert. Auch hier finden sich die gleichen Erfolgsfaktoren wie bei der Iteration Zero:

• die Nähe zum Kunde
• iterative Entwicklung der Produktidee
• Raum & Zeit zur Verfügung stellen
• dem Team das Vertrauen und einen Geldbetrag zur Verfügung stellen, um seine Produktidee als PoC zu lancieren

Wer ist jetzt schneller, die Forschung oder das Fussvolk? 😉

Mein Fazit des heutigen Tages:

• Beim Machen /Umsetzen blühe ich auf, ich habe grosse Mühe mit theoretischen Abhandlungen ohne Bodenhaftung
• Lernen tun wir nur, indem wir etwas umsetzen. Und dann reflektieren ;-). Ev. umfallen und dann wieder aufstehen… Krönchen richten… und weitergehen. (Resilienz nennt sich das;-))
• Agilität ist Tod, es lebe die Agilität!

 

Heute hatte ich einen interessanten Austausch mit einer Kollegin. Sie ist neuer im Agile Coaching Geschäft und hat mir geschildert, dass sie teilweise die Geduld nur schwer aufbringen kann, ihre Kunden mit auf dem agilen Weg zu begleiten. Sie hat selbst so viel Feuer für die Sache und es kann ihr nicht schnell genug gehen.

Als ich mit dem Coaching gestartet bin, bzw. generell in den ersten Jahren meiner Berufszeit hatte ich sehr oft genau das gleiche Gefühl. Ich war voller Energie für ein Thema entbrannt. Damit wir als Team jeweils möglichst schnell vorwärts kamen, habe ich sehr viel von meiner eigenen Energie in die Sache gesteckt. Hab somit (alle) angetrieben.

Mit der Zeit ist mir bewusst geworden, dass dies zum einen Raubbau an meiner Energie ist und zum anderen nicht wirklich Zielführend. Muss nicht jeder den Weg selbst gehen, in seiner eigenen Geschwindigkeit? Muss ich nicht den anderen die Chance geben, ihre eigenen Erfahrungen zu machen?

Und wenn man am Gras reisst, wächst es ja deshalb nicht schneller.

Heute nehme ich mich oft bewusst zurück, lasse die anderen den Weg selbst gehen. Ich gehe als Coach neben ihnen und weise sie ab und zu auf Wegweiser, Hindernisse und Brücken hin. Mehr kann (und will) ich nicht investieren.

Dies hat zur Folge, dass meine Energiebilanz viel besser ist und meine Kollegen ihre eigenen Erfahrungen in ihrer Veränderungsgeschwindigkeit (z.B. in Richtung Agile) machen können.

Aus meiner Sicht klar eine Win-Win-Situation :-).

 

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.

 

Letzte Woche dürfte ich mit einer Kollegin meinen ersten, lösungsorientierten Workshop moderieren. Es war eine Offenbarung, ich habe höchstwahrscheinlich an diesem Workshop von allen Anwesenden am meisten gelernt 😜.

Wobei, ich hab schon Lösungsorientierte Tools angewendet, nie aber so bewusst.

In diesem Workshop wurden, durch diverse Inpulse, die Teilnehmer dazu angeregt, neue Lösungen zu suchen, den Lösungsraum zu Öffnen. Ein Tool war, anhand der persönlichen Werte, die sie zuerst ausgesucht haben, in Kleingruppen neue Lösungsexperimente zu designen. Z.B. Mit dem Wert Kreativität sind sie auf ganz neue Ideen gekommen. Sehr wertvolle Übung, die ganz viel Energie geliefert hat.

Ich werde zukünftig viel mehr auf die Lösungsorientierung achten und will mir dazu auch einen Werkzeugkasten anlegen. Hier schon mal ein lesenswertes Buch dazu: Solution Tools. Die 60 besten sofort einsetzbaren Workshop-Interventionen mit dem Solution-Focus, von Peter Röhrig.

 

Ich wundere mich immer wieder das gewisse Praktiken in den Agilen-Frameworks auf Sozialwissenschaftlichen Theorien beruhen, diese jedoch nie erwähnt werden. Wenn ich auf Google nach AGILE suche finde ich fast ausschliesslich Themen rund um die Softwareentwicklung.

Dabei gab es das Wort AGILE ja schon in den 50er Jahren. Da wurde es unter dem Begriff AGIL-Schema geführt. Es handelte sich auch nicht um eine Produktionsmethode oder Geisteshaltung in der Softwareproduktion. Der Begriff wurde als Systemtheoretisches Modell entwickelt.

Es sollte die Frage beantwortet werden, was braucht es damit ein System zur Selbsterhaltung fähig ist? Diese Beschreibung wurde dann von Talcott Parsons auch auf soziale Systeme übertragen.

Die Beschreibung ist auf Wikipedia zu finden, das ist auch die Quelle der Grafik.

Für diejeniken die nicht klicken wollen hier die zusammenfassung der Abkürzung:

• Adaptation (Anpassung): die Fähigkeit eines Systems, auf die sich verändernden äußeren Bedingungen zu reagieren, sich anzupassen.
• Goal Attainment (Zielverfolgung): die Fähigkeit eines Systems, Ziele zu definieren und zu verfolgen.
• Integration (Eingliederung): die Fähigkeit eines Systems, Kohäsion (Zusammenhalt) und Inklusion (Einschluss) herzustellen und abzusichern.
• Latency bzw. Latent Pattern Maintenance (Aufrechterhaltung): die Fähigkeit eines Systems, grundlegende Strukturen und Wertmuster aufrechtzuerhalten.

Ich finde diese Quelle daher besonders wertvoll, da ich der Ansicht bin, das es bei der Agilen Produktentwicklung oder Softwareentwicklung vor allem darum geht einen menschenzentrierten Ansatz zu fahren und Teams zu Leistungen zu führen die eine einzelne Person nicht hervorbringen kann.

Neben all den technischen Themen rund um die Begriffe Software Craftsmanship und technische Excellenz lohnt es sich das Team als System zu begreifen.

Eine andere Quelle, welche das Thema abdeckt ist hier. Eine Arbeit mit dem Titel: Theorien und Konzepte zu Agilität in Organisationen

 

Gestern war ich en einem debriefing zweier Coaches anwesend. Sie haben zusammen eine Checkliste abgearbeitet.

Checkliste.. naja, irgendiwe öde… oder?

Sie haben  „The Seven C’s of Effective Teaching“ zusammen abgearbeitet.

Was zuerst ziemlich langweilig ausgesehen hat entpupte sich als sehr spannender Ansatz um die Wirkung als Coach oder als Lehrer auf die Klasse zu prüfen und zu reflektieren.

Caring about students (nurturing productive relationships);
Controlling behavior (promoting cooperation and peer support);
Clarifying ideas and lessons (making success seem feasible);
Challenging students to work hard and think hard (pressing for effort and rigor);
Captivating students (making learning interesting and relevant);
Conferring (eliciting students’ feedback and respecting their ideas);
Consolidating (connecting and integrating ideas to support learning).

Beispiele zu den 7 C’s

Caring about students: “The teacher in this class encourages me to do my best.”
Captivating students: “This class keeps my attention – I don’t get bored.”
Conferring with students: “My teacher gives us time to explain our ideas.”
Controlling behavior : “Our class stays busy and doesn’t waste time.”
Clarifying lessons: “When I am confused, my teacher knows how to help me understand.”
Challenging students: “My teacher wants us to use our thinking skills, not just memorize things.”

 

Der original Blog ist hier nachzulesen: http://thepositiveclassroom.org/the-seven-cs-of-effective-teaching/

Ich habe mir vorgenommen beim nächsten Pair-Training oder Coaching diese sieben C’s mal durchzusprechen.

 

In letzter Zeit wurde mir immer wieder gespiegelt, das ich Probleme anspreche, beziehungsweise über Probleme spreche statt Lösungen zu skizzieren.

Mal abgesehen ob die Aussage stimmt oder nicht, ich habe angefangen mich zu beobachten, was erzähle ich. Tatsächlich spreche ich oft Misstände an oder lege den Gesprächsfokus auf Probleme.

Einerseits ist es ja auch eine der Aufgaben eines Trainers oder eines Coaches „Dinge“ auf den Tisch zu bringen, damit sie besprechbar sind oder in das Bewusstsein des Teams oder der Person gelangen.

Andererseits sehe ich in meiner Tätigkeit auch ganz oft Situationen, Regeln, Verhalten, Prozesse die nicht den agilen Werten entsprechen. Es könnte schon sein, das dadurch meine Wahrnehmung entsprechend geprägt wird und ich dadurch viel über „Schlechtes“ spreche.

Ich werde mich in der nächsten Zukunft einmal beobachten und versuche herauszufinden ob ich beeinflusst bin. Alternativ könnte es ja auch sein, das mir die Fantasie oder die Vorstellungskraft fehlt für jedes „Problem“ in der Arbeitswelt eine Lösung bereit zu halten…. moment mal…. müsste ich als Coach nicht die Coache an die Lösung heranführen, nicht selber liefern?

Eventuell muss ich mich in der nächsten Zeit nur achten wer an mich den Anspruch stellt eine Lösung liefern zu müssen. Dann weis ich auch welche Baustelle ich an mir und auch am Fragestelle finden kann.

 

Bei meinen Einsätzen als Agile Coach mache ich in letzter Zeit immer mehr die Erfahrung, dass es sehr schwierig ist, sich in einer konventionellen, hierarchischen Organisation auf das agile Prinzip „manage work – lead people“ zu fokussieren. Warum? Eine Kernkompetenz der Manager in hierarchischen Organisationen ist das „Manage people“. Also, Organigramme definieren, Organigramme anpassen, Reorganisationen durchführen, Ressourcenplanungen erstellen, etc.

Fazit: Konventionelle (organisatorische) Veränderungen finden über Reorganisationen statt, es wird an der Aufbauorganisation anstatt der Ablauforganisation gearbeitet.

Agilität bedeutet ja das schnelle Reagieren auf Veränderungen. Und genau hier wollen wir uns verbessern. Die Ablauforganisation, also die Wertschöpfungskette in der Unternehmung soll optimiert werden. Und dies nicht nur einmal, sondern immer wieder. Ganz im Sinn: run a changing system. So gesehen sollen die Interaktionen zwischen den Wertschöpfungspartner agilisiert werden. Also MANANGE WORK, lead people :-).

Wie bringe ich jetzt die Manager dazu, den Fokus der organisatorischen Veränderung auf die Ablauforganisation zu legen? Ich habs bis jetzt nur Ansatzweise geschafft, indem ich:

• Fokus auf die Vision und die Mission lege
• Fokus auf den Kunden und deren Bedürfnisse lege
• Fokus auf den Wert unserer Organisation und die Wertschöpfungskette lege
• Anschliessend die Vision so weit runterbrechen, damit die Handlungsfelder für das nächste halbe Jahr konkretisiert sind
• Den Beitrag an die Wertschöpfungskette explizit mache und diesen visualisieren

Das tönt alles vernünftig und wäre sicher ein gangbarer Weg. Aber, wie bereits oben erwähnt, wenn man zuerst die Organisationsstruktur festlegen will, für etwas, was man noch gar nicht kennt, dann wirds wieder mal haarig :-).

Bis jetzt ist es mir noch nie gelungen, die Manager so umzustimmen, dass sie effektiv zuerst die Ablauforganisation gestalten. Auch hier gilt für mich, ich muss da einfach noch mehr Erfahrung sammeln und ev. hat mir ja einen Leser eine zündende Idee :-).