Autor: Ruedi

Wie findet man heraus, was dazu führt, dass ein Team nach einer langen Performance Phase plötzlich in eine Phase der Demotivation gerät? Kann es sein, dass die Summe der Motivation der einzelnen Teammitglieder die Teammotivation darstellt?

Auslöser zu diesen Fragen war ein Workshop an welchem das Team gefragt wurde; Was muss sich ändern, damit ihr wieder voll motiviert an dem Projekt mitarbeitet?

Antwort des Teams: Wir wissen nicht was geändert werden muss damit wir wieder Spass an unserer Tätigkeit und in unserer Organisation haben.

Die Demotivation ist offensichtlich und feststellbar. Sachliche Veränderungen oder Vorschläge zum Mitwirken haben keine Besserung hervorgebracht. Das Team befindet sich mehr oder weniger offensichtlich in einer Widerstandssituation.  Selbst die Wunder-Frage: Wie sieht für dich / euch die  perfekte Zukunft aus? bringt keine Verbesserung der Situation, keinen konstruktiven Lösungsprozess.

Ein neuer Ansatz ist gefragt. Meine Hypothese lautet dass die einzelne Motivation einen grossen Beitrag zur gesamt Teammotivation beiträgt. Ich vermute auch dass die Demotivation nicht nur aus fachlichen Situationen in der Organisation und dem Projekt herrührt.  D.h die intrinsische Motivation der einzelnen Teammembers ist der Kern des Problems.

Meiner Überlegung liegt die Theorie der intrinsischen Motivation nach Pink zugrunde.  (Offizielle Webseite)

Hier könnten folgende Fragen gestellt werden welche auf die Elemente nach Pink einzahlen.

Sinnhaftigkeit;  Hat sich etwas an der Sinnhaftigkeit meiner Arbeit verändert? Sehe ich den Sinn meiner Tätigkeit heute anders als noch zur Zeit als wir ein Performance Team waren?

Meisterschaft; Werde ich heute in meiner Tätigkeit gefördert um eine Meisterschaft zu erreichen? Werde ich weiterhin als meisterlich in meinem Fach wahrgenommen? Warum werden meine Argumente nicht mehr gehört? Ist mein Beitrag weniger Wert als früher?

Autonomie; Bin ich heute freier oder eingeschränkter in meiner Autonomie als zur Zeit als ich noch in einem Performance Team war? Warum glaube ich dass ich heute weniger Autonomie im Handeln und Entscheiden habe?

Zu jedem Bereich könnten noch weitere Fragen gestellt werden welche dazu führen zu verstehen was sich subjektiv verändert hat.

Aus den Antworten müsste es dann gelingen, Verbesserungsvorschläge zu entwickeln welche es den einzelnen Teammembers erlaubt die intrinsische Motivation zurück zu gewinnen welche dann wieder zu einer Verbesserung der Teamsituation führt.

Allerdings… aus Erfahrung kommt noch eine weitere Betrachtungsweise dazu. Ich behaupte dass es einen Zusammenhang zwischen Motivation und Statistik besteht. 🙂 die Formel lautet:

Motivation = Eintretenswahrscheinlichkeit x Gewinnerwartung

Meine Motivation wird durch zwei Faktoren wesentlich geprägt. Gewinnerwartung; Was kann ich durch meinen Einsatz gewinnen? Je höher der Gewinn, desto höher die Motivation. (Gewinn ist nicht nur materiell gemeint). Der Höchste Gewinn nutzt aber nichts, wenn der Faktor Eintretenswahrscheinlichkeit = 0 ist. D. h. Wenn ich nicht daran glaube das ich eine Chance habe zu gewinnen wird die Gewinnerwartung mit 0 multipliziert, Ergebnis ist 0. Also keine Motivation.

Das bedeutet, dass alle intrinsische Motivationsfaktoren keinen Wert haben, wenn das Team oder die Teammembers nicht daran glauben das sich etwas verändern wird oder die Eintretenswahrscheinlichkeit der Veränderung = 0  ist.

Was hat SHU HA RI mit Service Angeboten zu tun?

Oft werde ich gefragt was den ein Agile Coach so tut.  Naja.. irgendwie kommt der Namen der Tätigkeit ja schon recht nahe denke ich mir da gelegentlich…. Wenn die Frage dann, vermutlich wegen meines Gesichtsausdrucks, präzisiert wird fange ich an zu verstehen. Trainierst du auch Teams? Machst du auch Beratungen von Teams oder einzelnen Menschen?
Oder machst du nur Coaching ?

Selbstverständlich biete ich Training, Beratung  und Coaching an. Jetzt sind die Gesprächspartner meistens etwas in der Klemme. Was sollen sie nun von mir wollen? Schnell kommt die Anfrage; Lass uns mal mit Coaching starten… da kann man nichts falsch machen…

Welchen Service könnte ich nun sinnvollerweise meinem Gesprächspartner anbieten?  Dabei mache ich mir folgende Gedanken:

Aus den Budo- Kampfsportarten habe ich mir das SHU HA RI Konzept ausgelehnt. Es bezeichnet die drei Stufen eines Lernenden zum Beispiel in Aikido oder Karate.

SHU bedeutet genau so zu lernen wie der Lehrer es dir zeigt. Es dient als Grundlage um die nächste Stufe zu erreichen. Wörtlich bedeutet das Wort „Bewahren“ oder „Gehorchen“.  Ich setze den Service „Training“ der Stufe SHU gleich. Wenn also der Gesprächspartner erst mit Agile beginnen will oder erst vor kurzem gestartet ist, dann befindet er sich auf der Lernstufe SHU und dann bin ich sein Trainer.

HA bedeutet „frei werden“ oder auch „Frustration“ aber auch „mit Traditionen brechen“. Auf dieser Lernstufe haben die Teams oder die Menschen verstanden was und wie Scrum und die agilen Werte und Prinzipien funktionieren. Sie stossen mit dem Befolgen des Scrum Guides an Grenzen. Sie kommen mit dem gelernten in ihrem Umfeld nicht weiter. Sie müssten mit der Tradition brechen um ein höheres Level des Lernens zu erreichen. Wenn sich ein Team oder ein Mensch im HA befindet bin ich vor allem Berater. Ich versuche Erfahrungen zu vermitteln und neue Ansätze zu erklären.

RI bedeutet „verlassen“, „trennen“, den eigenen Impulsen folgen. Teams und Menschen auf dieser Lernstufe haben hohe Kompetenzen im Agilen Kontext entwickelt. Sie sind Profis auf ihrem Fach. Sie können abschätzen, wenn sie ausgetretene Pfade verlassen können oder sogar verlassen müssen um wertvolles, Neues zu schaffen. Auf dieser Lernstufe kommt Beratung nur noch selten vor. Hier ist Coaching gefragt.

Dies sind in etwa die Überlegungen die ich mir mache, wenn ich gefragt werde, welchen Service ich einem Auftraggeber/ Kunde anbieten sollte. Ich überlege mir auf welcher Lernstufe sich das Team oder der Mensch befindet und biete entsprechend Training, Beratung oder Coaching an.

PS: in einigen Umgebungen findet man alle drei Lernstufen im Team…  😉

In Projekten welche in einem anspruchsvollen fachlichen Umfeld und in kurzer Zeit etwas erreichen wollen stellt sich immer die Frage;  wie schaffe ich als Coach eine gute Lernumgebung?

Neben kurzen Iterationen oder Sprints mit guten Retrospektiven kann man schon sehr viel erreichen. Nur das reicht oft nicht. Wie gelingt es eine steilere Lernkurve zu erhalten?

Auf der Suche nach einer Antwort bin ich über das Konzept Think-Pair-Share gestolpert.

Im wesentlichen geht es darum:

Think:
Die Teammitglieder lernen zuerst individuel und vertiefen ihr Wissen. Um Wissen aufzubauen kann auch eine Timebox verwendet werden. Dh, das Team trifft sich für eine Stunde. Jedes Teammitglied hat Zeit sich mit einem Thema auseinander zu setzen und sich Gedanken darüber zu machen.  Das kann von 5 Minuten bis 30 Minuten dauern.

Pair:
In Zweierteams tauschen sich die Teammembers über das gelesene oder gelernte aus.  Der erste Lernpartner beschreibt wie er das Thema verstanden hat und was er gelernt hat und was für ihn wichtig ist. Der Lernpartner 2 macht sich Notizen. Als nächstes werden die Rollen umgedreht. Diese Timebox kann von 5 Minuten bis 15 Minuten gehen. Beide Lernpartner haben die Lerninhalte des anderen Verstanden und können beide Perspektiven  einnehmen.

Share:
Zum Abschluss stellen die Lernteams der Gruppe die Ergebnisse vor. Das kann als Minivortrag oder mit Flips gemacht werden.

Mit dieser Form der Lernverantstaltung sollte es möglich sein in einem kleinen Team innerhalb einer Stunde 3 bis 4 Themen in einer guten Tiefe zu erarbeiten. Dieser Event könnte zum Beispiel nach einem Refinement oder nach einem Planning 1 oder 2 stattfinden, wenn das Team erkennt das es mehr über das Thema in der User Story wissen sollte.

Natürlich kann diese Methode auch angewendet werden während der normalen Arbeit um die Software Craftsmanship zu verbessern.

Seit einiger Zeit grüble ich an einem Slogen eines „Agile Transition Programms“ nach.

Schneller, schlanker, effizienter…

Schneller; ja, Time to Market ist ein wichtiger Punkt bei der agilen Produktentwicklung. Aber nach Geschwindigkeit streben ist ja ein alter Hut.

Schlanker; Was mag das genau bedeuten? Weniger Kosten? Weniger Prozesse, Weniger Qualität im Produkt. Mit etwas Phantasie und gutem Willen kann man sagen, ok, weniger Verschwendung, das ist ja auch ein agiles Prinzip.

aber jetzt kommts…

effizienter

Echt jetzt?

In unseren Trainings verwenden wir oft die Stacey Matrix um zu erklären warum eine Firma Agilität braucht.

Wir starten die Produktenetwicklung in einem Bereich wo wir nicht genau wissen wie die Anforderungen und die Technologie das neue Produkt beeinflussen werden. Wir starten in einem komplexen Umfeld.

Über Iteration und Iteration findet das Team heraus, welches Produkt die besten Chancen auf dem Markt haben wird. Wir reduzieren von Iteration zu Iteration die Komplexität und finden heraus was wirklich funktioniert.

Wir lernen wie das richtige Produkt hergestellt wird.

Hier wird der Unterschied von Effektivität und Effizienz noch intensiver erklärt.

Daraus schliesse ich das es im Agilen Produktentwicklungsprozess vor allem darum geht das „Richtige“ auf den Markt zu bringen. Da kann der Herstellungsprozess schon ab und zu Umwege machen…. aber Scrum ist da ja auch sehr effizient wenn es um die Herstellung von Produkten geht und Vermeidung von Overhead.

Wenn das Produkt dann mal da ist kann die Unternehmung oder das Team ja an der Effizienz feilen, oder das Produkt weiter verbessern und den Begeisterungsfaktor erhöhen.

Zurück zu meinem, eingangs erwähnten „Agile Transition Programm“.

Wie erkläre ich nun dem Management, dass sie den Slogan falsch gewählt haben? Es sollte nicht Schneller, schlanker, effizienter heissen, wenn schon dann Schneller, schlanker, effektiver.

Heute über ein Video auf Youtube gestolpert.

Ein Talk von Jeff Sutherland, auf englisch. Ein Beitrag von TED:
The art of doing twice as much in half the time | Jeff Sutherland | TEDxAix

Eine schöne Zusammenfassung von Jeff über seinen Weg zum Scrum Framework. Dauer 15 Min.

Letzte Woche ist es wieder passiert.

Anlässlich eines Meetings hat ein Teil der Teilnehmenden versucht dem Top Stakholder ein „Produkt“ zu verkaufen. Dabei sind die Verkäufer auf Desintresse gestossen und mussten eine Menge komischer Fragen beantworten.

In meiner Rolle als Coach und Change Agent habe ich gesehen, dass dieses Meeting ein unzufriedenstellendes Ende nehmen wird. Für das „Verkaufsteam“ wie für den Top Stakeholder. Leider ist es mir nicht gelungen den Dialog in die richtige Richtung zu lenken. Jede Intervention wurde vom „Verkaufsteam“ als Kritik am Produkt angesehen und es entwickelte sich eine heftige, nicht zielführende Diskussion.

Wenn ich einen Change führe, dann beachte ich sehr genau das AIDA Konzept.

Es ist völlig unnötig einen Dialog mit einem Stakholder über ein Produkt zu führen, solange er noch nicht die Stufen; Bewusstsein, Interesse und Wunsch nach einer Lösung durchlaufen hat.

In dem Beispiel von letzter Woche war der Stakeholder sehr interessiert. Aber noch nicht an der Lösung. Er stand kurz vor der Stufe Desire (Wunsch).

Ich vermute sein Wunsch wäre es gewesen in dem Change eine wichtige Rolle zu spielen. Diese Rolle hätte er erreicht, wenn er ein sehr gutes Produkt an seine Abnehmer anbieten könnte. Da er aber nicht gesehen hat welche Rolle Ihm in diesem Change zuteil wird, hat er auch nicht auf das Produkt eingehen wollen.

Da das Meeting vor allem als Produktmarketing genutzt wurde hat der Stakeholder nie zugesagt und wird sich nun gut überlegen ob er dieses Produkt unterstützen soll, da er ja immer noch nicht weiss welche Rolle er spielen wird.

Ich vermute wenn wir das Meeting genutzt hätten eine gute Beziehung zum Stakeholder aufzubauen, ihm seinen Wunsch nach einer wichtigen Rolle aufzeigen hätten können… das Produkt wäre mit offenen Armen, quasi als Geschenk entgegengenommen worden.

Am Swisscom CX-Day 2016, der am 27. Oktober 2016 in La Werkstadt in Biel stattgefunden hat, durften wir einen Speech halten:

Präsentation „Kultur wirkt stärker als Strategie“

Fazit des Vortrags: Den theoretischen Teil hätten wir uns sparen können, erst bei der Praktik Iteration Zero haben die Zuhörer Feuer gefangen!

Der Austausch über agile & kundenzentrierte Themen, das Networking und die Toblerone waren für mich das Highlight des Anlasses. Der Swisscom CX-Day zieht Menschen aus dem In- und Ausland aus unterschiedlichsten Firmen an. Ich hatte z.B. Gespräche mit Vertretern von Hugo Boss, Matterhorn-Gotthard-Bahn, Start-Ups, Versicherungen etc. Sehr spannend und äussert vielfältig.

Meine Resume: Wir in der SBB mit dem Agilen Coaching Team und einem Management, das die Agilen Prinzipien und Werte in der SBB verankern will, sind auf dem Weg zu einer Agilen Unternehmung im vorderen Feld der Starter. Im Vergleich zu Huawei, die ihre Teams mit Kundenkontakt zu Oberst in der Hierarchie angesiedelt haben und ganz auf die Geschäftsleitung verzichten, sind wir aber noch in den Kinderschuhen. Also kein Grund, sich auf den Lorbeeren auszuruhen, sondern volle Fahrt voraus!

Ganz herzlichen Dank an die Swisscom, die uns diesen erlebnisreichen Tag geschenkt hat!

Am zweiten Tag am Global Scrum Gatherin 2016 in München hat Christopher Avery einen Vortrag über sein neues Buch gehalten.

The Responsibility Process

Hier die kurzen Beschreibungen der einzelnen Stufen:

Responsibility
Owning your ability and power to create, choose, and attract
Quit
Giving up to avoid the pain of Shame and Obligation
Obligation
Doing what you have to instead of what you want to
Shame
Laying blame onto oneself (often felt as guilt)
Justify
Using excuses for things being the way they are
Lay Blame
Holding others at fault for causing something
Denial
Ignoring the existence of something

Die Reihenfolge muss von unten nach oben gelesen werden Er beschreibt das Menschen, wenn sie auf Widerstand stossen oder glauben nicht erfolgreich zu sein diese Stufen durchlaufen.

Nur wer bis zur Stufe „Verantwortung übernehmen“ gelangt kann Probleme überwinden und erfolgreich sein.

Ich habe den Vortrag als nicht so prikelnd empfunden. Trotzdem habe ich dann begonnen mich zu beobachten wenn ich irgendwo auf ein Problem gestossen bin oder etwas nicht erreicht habe. Kleine alltägliche Situationen.

Erstaunlicherweise hat er recht. Ich durchlaufe diese einzelnen Schritte auch.  Speziell bei der Steuerabrechnung verweile ich extrem lange im Bereich „Obligation“. Ich weiss das ich muss, ich werde auch … irgendwann… und „Quit“ wird nicht wirklich funktionieren. Also: Verantwortung übernehmen und das unleidige Thema erledigen. Steuererkärung gemacht, „Verantwortung“ getragen, und, oh Wunder man fühlt sich besser.

Ich habe dan angefangen in den Gesprächen von Teamretrospektiven die Kommunikationsmuster nach dem „Responsibility Prozess“ zu suchen. Und siehe da; überall taucht dieses Muster auf. Das war für mich dann doch Erstaunlich.

Ich habe festgestellt das es mir hilft, in meiner Rolle als Coach, herauszufinden auf welchem „Layer“ das Team über ein Problem spricht. Nun werde ich mal experimentieren wie ich als Coach ein Team durch diesen Prozess durchlotsen kann damit sie oft und schneller in die Verantwortung gehen. Update wird folgen.

und… danke Christopher Avery für den Talk. 🙂

Kürzlich wurde ich in Gesprächen gefragt, warum man beim Einführen von agilen Methoden so einen riesen Wert auf Teamwork, Face-to-Face Kommunikation und Co-Location legen soll. Es geht doch auch sonst. Gut organisierte Unternehmen brauchen Agilität gar nicht.

In diesem Gespräch ist mir aufgefallen, was gut organisierte Unternehmen tun, wenn sich etwas unvorhergesehenes erreignet. Sie bilden eine Taskforce.

Ok, was passiert wenn man eine Taskforce einsetzt? Das Team versammelt sich in einem Raum, Hirarchie wird (fast) vollständig ausser Kraft gesetzt und es gibt einen Taskforce-Leiter welcher die Entscheidungen direkt und unabhängig trifft.

In dieser Situation legt die Unternnehmung alles Vertrauen in die Hände dieses Teams und dieses Taskforceleiters. (Meistens sind es ja knifflige Probleme die schnell zu lösen sind und nicht die langweiligen Alltagssorgen.)

Ist eine Task-Force eine agile Arbeitsform? In gewisser Weise schon, nur kann ein Team diese Arbeitsgeschwindigkeit nicht auf ewig halten und brennt nach kurzer Zeit aus. Aber wiso ist noch keine Unternehmung auf die Idee gekommen den Taskforce-Modus so zu transformieren dass er dem Team Spass macht, für die Firma Wert schafft und der Firma ermöglicht schnell auf Veränderungen zu reagieren? Weil es diese flexible, selbstorganisierte und crossfunktionale Arbeitsform schon gibt?

Warum nimmt man nicht einfach ein Scrum-Team? 🙂

Da gibt es einen Product Owner der sich um die schnellen Entscheide kümmert und ein Team das mit Comittement und Selbstorganisation darum kümmert das die Interessen der Firma bestmöglich umgesetzt werden.