Mut

Ich war so schüchtern als Kind! Ich war als Schülerin in allem gut, was mit Schreiben, Rechnen und Denken zusammenhing – aber nicht im Reden. Meine Noten in mündlicher Beteiligung waren dementsprechend schlecht. Ich traute mich nicht, mich zu melden, wenn ich mir vorher nicht ganz genau überlegt hatte, was ich sagen wollte – und dann war natürlich längst eine andere Schülerin dran. Wenn ich aufgerufen wurde, ohne mich gemeldet zu haben, bekam ich Schweißausbrüche und lief rot an, was mir entsetzlich peinlich war.

Ein von mir bewunderter Deutschlehrer verpasste mir als Teenie eine Einzelsitzung, indem er mich den Aufsatz von Heinrich von Kleist „Über die allmähliche Verfertigung der Gedanken beim Reden“ verordnete und mit mir darüber ein Zweiergespräch führte. Da dieser Lehrer gleichzeitig der Direktor der Schule war und eine echte Autoritätsperson, war ich natürlich sehr aufgeregt. Im Nachhinein betrachtet, war dieses Gespräch meine erste Coaching-Erfahrung. Ich nahm mir vor, mich in jeder Unterrichtsstunde mindestens einmal zu Wort zu melden, auch ohne bis ins Detail zu wissen, was ich sagen würde. Manchmal ging das in die Hosen, aber meistens klappte es ganz gut – ich hatte für mich das Prinzip der iterativ-inkrementellen Verbesserung entdeckt.

Meine nächste große Herausforderung ereilte mich, als ich mich zu Beginn meines Studiums als Erstsemestersprecherin meldete. Nicht etwa, weil ich so studentenbewegt gewesen wäre oder mich diese Aufgabe besonders gereizt hätte – es lag einzig und allein daran, dass ein wirklich unwiderstehlicher Kommilitone aus einem älteren Semester diesen Wunsch an mich herantrug. Vor jedem meiner Auftritte vor meinen 500 Kommilitonen (Elektrotechnik, 95% Männer!) konnte ich vor Aufregung nicht essen, nicht schlafen… aber da musste ich nun durch. Und siehe da, es ging irgendwie. Auftritte vor solchen Menschenmassen sind nach wie vor nicht meine Lieblingsbeschäftigung. Ich habe die Angst davor trotz einiger Gelegenheiten zum Üben nicht verloren – so wie etliche Schauspieler und Musiker vor jedem Auftritt Lampenfieber haben. Ich habe jedoch die Erfahrung gemacht, dass ich die Angst bisher immer überwinden konnte – und damit das Zutrauen, dass es auch beim nächsten Mal klappen wird. Ich bekomme oft das Feedback, dass man mir meine Aufregung gar nicht anmerkt. Ich genieße das Gefühl von Stolz und Erleichterung, das sich nach einem gelungenen Auftritt einstellt. Und wenn es mal nicht so gut gelaufen ist, stecke ich die Enttäuschung einigermaßen schnell weg.

Viel später lernte ich Scrum kennen und erfuhr von den fünf Scrum-Werten: Fokus, Offenheit, Commitment, Respekt – und Mut. Die ersten vier sind für mich keine besondere Herausforderung, sie entsprechen meinem Naturell. Aber Mut? Obwohl ich im Sternzeichen des Löwen geboren bin, bin ich wirklich kein mutiger Mensch. Ich habe Angst vor Konflikten, vor Blamage, vor Ärzten mit Spritzen, vor dunklen Kellern, und manchmal auch vor Autoritätspersonen (wie meinem Deutschlehrer). Und das ist ganz normal. Ängste sind uns von der Evolution in die Wiege gelegt als Schutz- und Überlebensmechanismus. Wenn vom ältesten Teil des Hirns, dem Stammhirn, ein Signal für Gefahr ans Großhirn gesendet wird, bleibt keine Zeit für ausgiebiges Denken. Das Großhirn geht in den Stand-by Modus und der Körper übernimmt die weiteren Reaktionen: Fight, Flight oder Freeze. Mut ist nicht die Abwesenheit von Angst, sondern die Fähigkeit, diese zu überwinden und trotzdem vernünftig zu denken und zu handeln. Und das kann trainiert werden: durch Bewegungs- und Entspannungsübungen, Meditation, durch Konfrontation mit der Angst. Auch das Sprechen (oder Schreiben) über die eigenen Ängste kann schon zu einem verstärkten Kontrollgefühl führen.

Ich bin mittlerweile viel mutiger als früher. Zu Beginn meiner Berufstätigkeit hatte ich meine „Mutprobe“ aus Schulzeiten noch aufrechterhalten und mir auferlegt, mich in jeder Besprechung mindestens einmal zu Wort zu melden. Mittlerweile fällt es mir eher schwer, mich nicht zu Wort zu melden, weil ich überall meinen Senf dazu geben möchte. In meinen ersten Trainings bin ich noch rot angelaufen, wenn ich eine Frage nicht beantworten konnte. Das ist mir schon seit Jahren nicht mehr passiert. Ich habe nicht den Anspruch, im Besitz der alleinigen Wahrheit zu sein und alle Fragen beantworten zu können. Ich ermutige meine Teilnehmer sogar dazu, meine Äußerungen in Frage zu stellen und ihre eigenen Sichtweisen zu entwickeln. Dennoch bin ich noch längst nicht zufrieden mit meinem Mut. Ich bewundere Menschen wie Martin Luther, die Geschwister Scholl, Mahatma Ghandi. Und auch weniger prominente Beispiele: Menschen, die unbeirrt für ihre Überzeugung einstehen, auch wenn sie sich damit gravierende Nachteile für sie bedeutet. Menschen, die alles hinter sich lassen und sich in ein überfülltes Boot zwängen in der Hoffnung auf ein besseres Leben. Menschen, die dazwischengehen, wenn Schwächere angepöbelt oder gar angegriffen werden. Menschen, die unter Einsatz ihres eigenen Lebens andere aus dem kalten Wasser oder brennenden Autos retten. Ich weiß nicht, ob ich zu solchen Dingen jemals in der Lage wäre. Diese Vorbilder inspirieren mich und zeigen mir, was möglich ist – und verhindern, dass mir meine bescheidenen Erfolge zu Kopf steigen.

Zurück zu Scrum: Scrum bedeutet Veränderung. Dies bedeutet, Vertrautes und als sicher Empfundenes zu verlassen, sich heraus aus der eigenen Komfortzone zu bewegen. Oft wird bei Veränderungsprozessen wie agilen Transitionen der Widerstand beklagt. Peter Senge, der Systemdenker, hat gesagt: „Menschen wehren sich nicht gegen Veränderung, sondern dagegen, verändert zu werden.“ Und genau dazu brauchen wir Mut. Zusammen mit Optimismus und Selbstvertrauen, die uns die Angst vor dem Unbekannten überwinden lassen. Kleine (iterative) Schritte heraus aus der Komfortzone helfen dabei – so dehnt sich die Komfortzone immer weiter aus. Deswegen ist Mut für mich der wichtigste Scrum-Wert und eine Voraussetzung für die anderen. Als Coaches sind wir Vorreiter und zeigen, wie das geht. Wir können offen (=Scrum-Wert) reden über unsere Ängste, Schwierigkeiten und Fehlschläge – und unsere Hochgefühle und Erfolgserlebnisse teilen, wenn uns etwas gelungen ist. Wir können empathisch und respektvoll (=Scrum-Wert) mit den Ängsten anderer umgehen. Wir können zu unserer Überzeugung und Eigenverantwortung (=Scrum-Wert) stehen – auch wenn wir damit „Autoritätspersonen“ oder dem gängigen Mainstream wiedersprechen. Wir können uns inspirieren lassen von Mahatma Ghandi: „Sei du selbst die Veränderung, die du dir wünschst für diese Welt.“ Dadurch können wir andere ermutigen, es auch zu tun.

Ein paar Zitate:
Aus Heinrich von Kleist-Aufsatz:
„l’idee vient en parlant“ – die Idee kommt während des Sprechens
„Ich glaube, daß mancher großer Redner, in dem Augenblick, da er den Mund aufmachte, noch nicht wußte, was er sagen würde. Aber die Überzeugung, daß er die ihm nötige Gedankenfülle schon aus den Umständen, und der daraus resultierenden Erregung seines Gemüts schöpfen würde, machte ihn dreist genug, den Anfang, auf gutes Glück hin, zu setzen.“
„Es ist nicht genug zu wissen, man muss auch anwenden; es ist nicht genug zu wollen, man muss auch tun.“ (J.W. Goethe)
„Mut besteht nicht darin, dass man die Gefahr blind übersieht, sondern darin, dass man sie sehend überwindet.“ (John Paul)
„Mut hat die Angst zur Voraussetzung. Mut heißt, trotz Angst kühn zu denken und zu handeln. Der Ängstliche ist der Mutige. Vor den Furchtlosen kann einem dagegen Angst werden.“ (A. Retzer)

Advertisements
Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Agil im Akkord – Akkord durch Agil?

Schlagzeile in der Süddeutschen vom 16.12.2016, Wirtschafts-Teil: Akkordarbeit für alle. Ich hätte über diese Schlagzeile wahrscheinlich hinweggelesen, hätte mich nicht mein Freund der passionierte Zeitungsleser darauf aufmerksam gemacht, dass es dabei um „Agil“ geht. Was bitte hat Agil mit Akkord zu tun? Aber tatsächlich, der Artikel startet wie folgt: Die Revolution kam langsam, aber gewaltig. „Es wurde irgendwie ein Dauerstress“, sagt der Software-Entwickler über seine Arbeit. „Alle vier Wochen muss was gezeigt werden und man hat immer diese Deadline.“ Früher dagegen sei es nur einmal am Ende der Entwicklung einer Software richtig stressig geworden, „und dann war es gut“. Da sehnt sich jemand nach den guten alten Wasserfall-Zeiten zurück!

Risiken und Nebenwirkungen der Scrum-Säule Transparenz werden so beschrieben: Diese Transparenz zerstört den Schleier, hinter dem Experten bisher werkelten, und ermöglicht scharfe Leistungsvorgaben. Die Taktung der Arbeit verhindert jeden persönlichen Rhythmus.

Schon mal vom Agilen Manifest gehört? Was hat das mit Selbstorganisation zu tun (Prinzip Nr. 9)? Und mit nachhaltigem Schritttempo (sustainable pace, Prinzip Nr. 8)? Mich erinnert das sehr an einen Hammer, den man einsetzen kann, um ein Baumhaus zu bauen, oder ein Bild an die Wand zu hängen – oder aber um jemandem damit den Schädel einzuschlagen. Schuld ist natürlich nicht der Hammer, sondern die Intention der Person, die ihn schwingt. Was uns daran hindert, anderen Menschen den Schädel einzuschlagen, sind unsere moralischen und ethischen Werte. Und genau darum geht es auch bei dem oben beschriebenen, fehlgeleiteten Einsatz von agilen Methoden. Ohne die Einhaltung von agilen Werte und Prinzipien werden sie zum Schädelspalter. (Disclaimer: Diese drastische Metapher dient der Klarheit. Mir ist der Unterschied zwischen einem Kapitalverbrechen und einer Verdichtung des Arbeitstaktes durchaus bewusst.)

Dass es nämlich auch gut gehen kann, beschreibt der Artikel so: Und wenn diese Teams anders als bei klassischen Firmenhierarchien selbst viel mitbestimmen können, profitieren die Mitarbeiter. Bekommen sie mehr Entscheidungsmacht, macht ihnen die Arbeit mehr Spaß, und sie werden innovativer. Die Firmen würden sich jedoch gern die Rosinen herauspicken. Sie nehmen gerne mehr Taktung und Transparenz. Sie zögern, den Teams mehr Entscheidungsmacht über ihre Arbeitslast zu geben.

Also aufgepasst bei der Anwendung von Lean und Agile. Geht es wirklich um Flexibilität, Anpassungsfähigkeit und Innovation? Oder vornehmlich um die Steigerung der Effizienz und die Reduzierung der Kosten? Eine Implementierung von Scrum-Praktiken kann beides bewirken, also im negativen Fall eine dichtere Taktung, Erhöhung des Gruppendrucks, mehr statt weniger Mikromanagement, Ausbeutung der „Ressource“ Mensch. Einige Symptome habe ich selbst in der Praxis erlebt: im „Sprint Planning“ weist der Chef Arbeitsaufgaben einzelnen Mitarbeitern zu, das „Daily Scrum“ wird als Reporting-Meeting gesehen, das elektronische „Task-Board“ dient zur Kontrolle der Arbeitszeiten, eine Erhöhung der Velocity wird als Ziel ausgerufen, ScrumMaster und Retros werden wegoptimiert, die ständige Anwesenheit des „Product Owners“ führt zu noch mehr Druck… Bitte nicht mit Versprechungen hausieren gehen, dass wir durch Agile schneller und kostengünstiger werden. Dies ist durchaus ein erstrebenswertes Ziel, wird jedoch zu leicht missverstanden. Wir erreichen es durch Effektivität – engen Kundenkontakt, Priorisierung, kurze Releases, Einfachheit – und nicht durch Druck auf die Mitarbeiter.

Als Agilisten fühlen wir uns Werten und Prinzipien verpflichtet – und versuchen nicht, einige Praktiken Cargo-Kult-artig zum Einsatz zu bringen. Das wiederum bestärkt mich in meiner Auffassung, in meinen Trainings immer wieder auf die Wichtigkeit von Werten, Prinzipien und Mindset hinzuweisen. Wie der Artikel zeigt, ist dies keine Theorie, sondern äußerst relevant für die Anwendung in der Praxis.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Meine drei agilen Mindsets

Neulich fragte mich jemand: „Wenn beim Planning Poker bereits in der 1. Runde alle den gleichen Wert schätzen, muss ich dann auch eine 2. Runde schätzen lassen?“. Fragen dieser Art sind sehr häufig: „Kann ich das User-Story-Template auch für Product Backlog Items anwenden, die keine User Stories sind?“, „Ist es zulässig, dass Product Owner und ScrumMaster die gleiche Person sind?“, „Entsteht das Sprint-Ziel vor oder nach dem Sprint-Planning?“. Sie deuten darauf hin, dass Scrum leider meist als Methodik verstanden wird, als Kochbuch, und nicht als Framework zur Umsetzung eines „agilen Mindset“. Meine Hypothese ist, dass sich diese Fragen aus einem agilen Mindset heraus selbst beantworten lassen.

Agiles Mindset ist in aller Munde. Was genau ist damit eigentlich gemeint? Woran kann ich ihn erkennen, und was kann ich tun, um ihn zu fördern?

Ich übersetze „Mindset“ mit „Denkweise“ oder „Haltung“. Diese Haltung wird beschrieben durch Werte und Prinzipien, wie sie im hinlänglich bekannten Manifest für Agile Softwareentwicklung zusammengefasst sind. Hier geht es immer um Kunden und Teams. Eine Organisation wird erst dann agil sein, wenn alle sich auf diese gemeinsamen Werte und Prinzipien verständigen und sie einhalten. Eine Haltung ist aber auch und vor allem eine sehr persönliche Sache.Was ich unmittelbar beeinflussen kann, ist meine persönliche Agilität. Sie zeichnet sich aus durch

  • Meine Beziehung zum „Kunden“, dem Empfänger meiner Ergebnisse und Dienstleistungen: ich möchte für meinen Kunden Wert erzeugen und Verschwendung vermeiden.
  • Meine Beziehung zu meinem Team: ich bin überzeugt, dass die besten Ergebnisse im Team entstehen. Ich vertraue darauf, dass meine Team-Mitglieder ihr Bestes geben und bin daher bereit, Team-Entscheidungen mitzutragen.
  • Ich selbst und meine persönliche Entwicklung: ich habe eine positive, konstruktive Haltung zu mir selbst und anderen Menschen. Ich bin bereit für Veränderungen, zum Experimentieren und zum Lernen aus Feedback und Fehlern.

agile-mindset-2

Ich habe also genaugenommen nicht ein, sondern drei agile Mindsets!

Wenn du deine persönliche Agilität anhand dieser drei Kategorien überprüfen möchtest, kannst du diesen Selbstcheck dazu nutzen.

Soll das heißen, dass persönliche Agilität das Vorhandensein eines Kunden und eines Teams erfordert? Kann ich nicht auch für mich allein, in meinem persönlichen Umfeld, agil sein? Natürlich kann ich anpassungsfähig und lernbereit sein – ob ich dafür den Begriff „Agil“ verwende, ist für mich nicht relevant. Wichtig wird die Begriffsklärung in der Zusammenarbeit mit anderen. Agil ist die Fähigkeit zur schnellen Veränderung, um mit Hilfe von anderen (dem Team) wertvolle Ergebnisse (für Kunden) zu erzeugen.

Im Dreieck „Kunde – Team – ich selbst“ kann es zu Interessenskonflikten kommen. Wenn das Team zu sehr unter dem Pantoffel des Kunden steht und keine Zeit mehr bleibt, die Axt zu schärfen, wird die Zusammenarbeit und letztendlich auch die Produktivität und die Qualität der Ergebnisse darunter leiden. Wenn das Team an wunderschönen Lösungen feilt und kein Auge auf die Vermarktbarkeit legt, ist das geschäftsgefährdend. Wenn ich auf Dauer meine persönlichen Interessen hinter den Team-Interessen zurückstelle, werde ich unzufrieden. In Scrum haben wir den Product Owner und den ScrumMaster, die als Interessensvertreter von Kunden und Team für Balance sorgen – für meine eigenen Interessen bin ich selbst zuständig.

Was ist, wenn ich dieses Mindset nicht habe, oder feststelle, dass Menschen in meiner Umgebung es nicht haben? Kann sich das ändern? Natürlich! Agilität ohne den Glauben an Veränderung ist ein Widerspruch in sich. Carol Dweck hat dazu sehr interessante Gedanken und Untersuchungen in ihrem Buch „Mindset: The New Psychology of Success“ dargelegt:  Sie unterscheidet zwischen „fixed“ (festgelegtem) und „growth“ (wachstumsorientiertem) Mindset.

  • Menschen mit einem „fixed mindset“ sind überzeugt, dass Fähigkeiten und Talente im wesentlichen angeboren sind. Sie vermeiden Herausforderungen mit Möglichkeit zum Scheitern und vertuschen ihre Fehler.
  • Menschen mit einem „growth mindset“ trauen sich zu, jede beliebige Fähigkeit durch entsprechende Anstrengung, Ausbildung und Übung zu entwickeln, zumindest bis zu einem gewissen Grad. Fehler liefern für sie wertvolle Informationen für die Weiterentwicklung.

Mit anderen Worten: Persönliche Agilität erfordert einen „growth mindset“. Zum Glück ist – nach Carol Dweck – auch die Einteilung der Menschen in „fixed“ vs. „growth“ nicht etwa „fixed“, sondern kann durch geeignete Maßnahmen (z.B. Loben von Anstrengung, Strategie und Vorgehen anstelle von Ergebnissen; Lesen von Artikeln, die die Überlegenheit des „growth“ mindsets belegen) beeinflusst werden. Es kann schon reichen, sich über den Unterschied bewusst zu werden und sich klarzumachen, dass das „growth mindset“ oft zwar anstrengender ist, dafür aber auch mehr Erfolg verspricht und weniger Stress im Umgang mit Rückschlägen.

Ich selbst erwische mich übrigens immer wieder dabei, dass mein Mindset und mein Verhalten nicht immer agil sind. Ich will meinen Kopf durchsetzen und lasse es an Wertschätzung für die Beiträge meiner Team-Mitglieder mangeln, weil ich glaube, es besser zu wissen. Ich möchte in meiner Komfortzone bleiben und erprobtes Vorgehen beim Kunden wiederverwerten, auch wenn es gar nicht zu dessen Bedürfnissen passt. Ich ärgere mich über Kritik und fühle mich verletzt, anstatt sie als Feedback und damit als Geschenk zu betrachten. Was soll’s – Agil ist eine Perfektionsvision, und ich bin nicht perfekt, sondern „work in progress“. Wenn ich das erkenne, kann ich auch besser mit schwächelnder Agilität bei meinen Team-Mitgliedern, Vorgesetzten und anderen Mitmenschen umgehen.

Mit diesen Gedanken möchte ich zurück zu meiner Eingangssituation kommen, die Frage nach der 2. Schätzrunde. Ich kann meinem Fragesteller helfen, sich seine Frage selbst zu beantworten, indem ich Gegenfragen stelle:

  • Wem nützt oder schadet es? Dem Kunden? Dem Team? Mir selbst?
  • Was kann ich, können wir daraus lernen?

Eine 2. Schätzrunde nützt erst mal niemandem und schadet vielleicht sogar, weil sie Zeit verschwendet und das Team nervt. Wenn ich als ScrumMaster das Gefühl hat, dass noch etwas offen ist, kann ich Fragen stellen, z.B. „Welche Ähnlichkeit seht ihr zwischen dieser Story und Story xxx (mit der gleichen Punktzahl)? Welchen Unterschied zu Story yyy (mit einer anderen Punktzahl)?“ oder „Welche Optionen seht ihr für die Umsetzung?“ oder einfach „Was gibt es zu dieser Story noch zu sagen?“ Aus den Antworten darauf kann das Team neue Erkenntnisse gewinnen.

Dieses kleine Beispiel zeigt: mit Blick auf meine drei Mindsets (Kunde – Team – ich selbst) kann ich Antworten auf meine Fragen nach konkreten Praktiken finden und situativ Entscheidungen fällen. Als Trainer und Coach kann ich andere unterstützen, selbst ein agiles Mindset zu entwickeln. Anstatt zu signalisieren „ich allwissender Trainer – du dummer Schüler“, kann ich ihnen die Erkenntnis vermitteln, dass sie selbst die Experten für ihre Fragen und Probleme sind und daher auch die besten Antworten und Lösungen dafür finden können. Damit unterstütze ich ihren „growth mindset“. Scrum hilft dabei als Framework zum disziplinierten Experimentieren mit begrenztem Risiko. Und wenn sie oder wir gemeinsam dabei Fehler machen… prima, wieder was gelernt! Oder wie Samuel Becket, offensichtlich ein echter Vertreter eines „growth mindsets“ sagte:

Ever tried. Ever failed. No matter.

Try Again. Fail again. Fail better.

 

 

Veröffentlicht unter Uncategorized | 5 Kommentare

Mein Scrum-Commitment

Es gibt seit neuestem eine neue Version des Scrum Guides, die die Definition von Scrum enthält. Er zählt nun wieder die fünf Scrum-Werte auf, die auf dem langen Weg zwischen dem Schwaren Buch von Ken Schwaber und dem Scrum Guide verloren gegangen waren: Commitment, Courage, Focus, Openness and Respect. Das ist gut so, denn dadurch wird deutlich, dass Scrum nicht (nur) ein Methoden-Framework ist, sondern ein Wertesystem. Die Werte weisen uns die Richtung. Bei allen Entscheidungen, die wir fällen bei der Anwendung von Scrum, der Anpassung an den jeweiligen Kontext und der Erweiterung mit ergänzenden Praktiken, sollen diese Werte verstärkt und nicht verwässert werden. Dazu ist ein gemeinsames Verständnis dieser Werte wichtig. Gar nicht so trivial. Bereits beim ersten Wert, dem Commitment, stoßen wir bei der Übersetzung auf Schwierigkeiten. Commitment = Versprechen? Wir fühlen uns wie Faust bei der Übersetzung der Bibel:

Geschrieben steht: »Im Anfang war Versprechen!«
Hier stock ich schon! Und drohe zu zerbrechen.
Ich kann das Wort so hoch unmöglich schätzen,
Ich muß es anders übersetzen.

Vielleicht mit „Vorhersage“? Erinnern wir uns: bei dem update des Scrum Guides im Jahre 2011 wurde das Wort „commit“ durch „forecast“ ersetzt. Ehemals sollte sich das Entwicklungsteam zu Product Backlog Items für einen Spring „committen“, nun sollte es nur noch einen „forecast“, eine Vorhersage, dafür abgeben. Darüber wurde und wird kontrovers diskutiert. Wo bleibt da die Verbindlichkeit? Wir denken an eine Wettervorhersage, die Wettermoderatoren wie Claudia Kleinert oder Karsten Schwanke abgeben, ohne dass wir sie dafür zur Rechenschaft ziehen können. Hey, Herr Schwanke, Sie haben sich für heute zu gutem Wetter committed, und jetzt stehe ich da mit meiner Gartenparty und 50 Gästen im strömenden Regen! Das müssen Sie wieder gutmachen! Ein an den Haaren herbeigezogener Vergleich? Unser Entwicklungsteam sollte doch hoffentlich mehr Einfluss auf die Fertigstellung der Product Items haben als Herr Schwanke auf das Wetter, aber dennoch liegt es nicht komplett in seiner Hand. Nicht eingehaltene Versprechen sind Gift für das Vertrauensverhältnis zwischen Product Owner, Stakeholdern und Entwicklungsteam. Es kommt zu Forderungen, Suche nach Verantwortlichen und Schuldzuweisungen. Um das zu vermeiden, stellt das Team vielleicht das nächste Mal seine Items fertig, ohne die Qualitätskriterien einzuhalten, und baut somit technische Schulden auf. Oder es committed sich übervorsichtig, um auf der sicheren Seite zu sein, und erwirbt sich so den Ruf, faul zu sein, nicht ambitioniert oder nicht bereit, Verantwortung zu übernehmen. Ein so verstandenes Commitment richtet eher Schaden an als dass es Gutes tut.

Lesen wir weiter im Scrum Guide: “People personally commit to achieving the goals of the Scrum Team.” Aha, es geht gar nicht um ein Commitment zu einzelnen Product Backlog Items, sondern um ein Commitment zu einem gemeinsames Ziel. Und: es geht auch nicht um ein einseitiges Commitment des Entwicklungsteams, sondern jeder committed sich persönlich! Wir versprechen uns gegenseitig, unser Bestes zu geben, um das gemeinsame Ziel zu erreichen. Dieses Versprechen ist übrigens auch der Kern der „Prime Directive“ für Retrospektiven: Unabhängig davon, was wir heute entdecken, glauben wir aufrichtig, dass in der gegebenen Situation, mit dem verfügbaren Wissen, Fähigkeiten und Ressourcen, jede(r) sein Bestes getan hat.

Damit ein Commitment große Wirkung hat, muss es:

  1. Freiwillig sein: Mit Druck und Drohungen erzwungene Commitments nimmt niemand ernst
  2. Öffentlich gegeben werden: Je mehr Personen es hören, desto wahrscheinlich halten wir es ein

Mit diesen Voraussetzungen können wir das Ritual eines feierlich abgegebenen Commitments = Versprechen zu einem gemeinsamen (Sprint)-Ziel pflegen. Wir können sagen „wir versprechen“ und „wir fühlen uns verpflichtet“ anstatt kryptische denglische Ausdrücke wie „wir committen uns“ oder „wir sind committed“. Dass die Erreichung mit Anstrengung verbunden ist, ist dabei kein Hindernis, im Gegenteil. Es erhöht die Wertigkeit des Versprechens.

Was ist nun, wenn wir feststellen, dass wir das Versprechen nicht einhalten können? Müssen wir dann ein schlechtes Gewissen haben?

Als Leserin des Magazins der Süddeutschen Zeitung kommt mir sofort Dr. Dr. Ehrlinger in den Sinn, der sich wöchentlich zu Gewissensfragen äußert. Und siehe da, meine Recherche ergibt, dass er sich auch mit dem Thema Versprechen auseinandergesetzt hat, z.B. dem Eheversprechen:

„Insofern muss man von einem Treueversprechen ausgehen, das die beiden Brautleute nacheinander abgeben und wechselseitig annehmen und das erst durch die Annahme wirksam wird. Das aber hat zwei Konsequenzen: Zum einen sind die Eheleute dem jeweils anderen verpflichtet und nicht sich selbst oder einem Prinzip gegenüber. Zum anderen gilt bei einem Versprechen der Grundsatz, dass derjenige, dem gegenüber man die Verpflichtung eingegangen ist, denjenigen, der ihm das Versprechen gegeben hat, von der Verpflichtung auch wieder entbinden kann.“

Auch wenn Product Owner und Entwicklungsteam nicht miteinander verheiratet sind, schließen sie einen Bund für die Produktentwicklung (mit dem ScrumMaster als Pfarrer ;-)). Sie müssen sich nicht gerade lieben, aber achten und ehren, in guten und in schlechten Tagen. (Schnüff. Ja, dies ist ein emotionaler Moment, und ja, Versprechen haben was mit Emotionen zu tun.) Sie können sich gegenseitig von der Verpflichtung entbinden, möglichst in gegenseitigem Einvernehmen.

In diesem Sinne gebe ich hiermit ein freiwilliges und öffentliches Versprechen zum Commitment und die anderen Scrum-Werte ab. Ich werde mein Bestes tun, sie als Richtungsgeber meiner Arbeit zu beherzigen.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Agil verbessern

Trotz Retrospektiven bleiben Verbesserungen oft auf der Strecke. Das kann sich ändern, wenn wir einige Prinzipien, die wir für die Entwicklung von Software und Produkten mit Scrum anwenden, auch bei den Verbesserungsmaßnahmen beachten.

  • Priorisierung nach Wert (Kosten und Nutzen): Verbesserungspotenzial wird überall und täglich sichtbar: bei der täglichen Arbeit, während der Scrum-Meetings, durch Fortschritts-Indikatoren. Manchmal sind es kleine Ideen, „low hanging fruits“, die sich schnell umsetzen lassen. Manchmal sind es handfeste Probleme, für die eine Lösung noch nicht sofort erkennbar ist und die sich vielleicht auch nicht innerhalb eines Teams lösen lassen. Wir können nicht alles gleichzeitig angehen. Wir müssen priorisieren, und zwar nach Kosten und Nutzen. Dazu eignet sich ein Verbesserungs-Backlog (oder Hindernis-Backlog).
  • Verbesserungs-Stories: Wir können die Items dieses Backlogs als Stories formulieren, damit erkennbar ist, für den die Verbesserung welchen Nutzen bringt. Z.B. „Als Entwickler brauche ich das Feedback des Product Owners auch während des Sprints, damit ich weiß, ob ich auf dem richtigen Weg bin.“
  • Aufsplitten in kleine, machbare Teile: wenn wir es mit einem „Verbesserung-Epic“ zu tun haben (z.B. „Zusammenarbeit mit dem Product Owner verbessern“), sollten wir es in Stories herunterbrechen, die in einem Sprint umsetzbar sind. Die Definition von Aktzeptanzkriterien hilft dabei, das Etappenziel für einen Sprint zu klären. Für unser Beispiel oben: „Der Product Owner reserviert sich Dienstags und Donnerstag mindestens 1/2 h nach dem Daily Scrum, um mit den Entwicklern zu arbeiten. Die Entwickler kündigen ihren Bedarf vorher an und einigen sich untereinander, wie sie diese Zeit nutzen wollen.“
  • Verbesserungs-Backlog-Grooming: Die Pflege des Verbesserungs-Backlogs kann in der Retrospektive stattfinden – wenn das Aufsammeln von Verbesserungs-Items eine tägliche Aktivität ist, hat das Team hier die Zeit für die Priorisierung und Verfeinerung.
  • iterativ-inkrementelle Abarbeitung und Transparenz über den Fortschritt: die machbaren Verbesserungs-Stories werden im Sprint Planning eingeplant und im Sprint umgesetzt. Als Daumenwert sollte man 10% der Team-Kapazität als „Zeit zum Schärfen der Axt“ veranschlagen. Am Ende des Sprints kann das Team kontrollieren, ob die Akzeptanzkritierien erfüllt und der erwartete Nutzen eingetreten ist. Da sich der Nutzen oft nur schwer in hart messbaren Zahlen ausdrücken lässt, bietet sich eine Zufriedenheitsabfrage im Team an, die man ggf. über mehrere Sprints verfolgen kann. Z.B. „Wie zufrieden sind wir mit der Zusammenarbeit mit dem Product Owner?“ Es können weitere Stories iterativ angegangen werden, bis die Zufriedenheit ausreichend ist. Um die Nachhaltigkeit der Umsetzung sicherzustellen, ist es ratsam, die Abfrage auch danach in regelmäßigen Abständen durchzuführen. So eine Nutzen-Kontrolle muss man natürlich nicht für jede Verbesserungs-Idee durchführen, nur für die „dicken Brocken“ (großer Aufwand, großer Nutzen).
  • Verantwortung beim Team: oft wird der ScrumMaster als derjenige angesehen, der verantwortlich für die Beseitigung von Hindernissen ist. Tatsächlich sollte sich ein selbst-organisiertes Team eigenverantwortlich an seiner kontinuierlicher Verbesserung arbeiten. Der ScrumMaster ist lediglich dafür verantwortlich, den Prozess dafür aufzusetzen.

Wir sehen, dass sich Verbesserungen nahtlos in das Scrum-Vorgehen integrieren lassen und wir Scrum so nutzen können, um uns agil zu verbessern.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Die agile Organisation: Der Weg ist das Ziel

In meinem letzten Post habe ich meine Vision einer agilen Organisation dargestellt. „Ab heute sind wir eine agile Organisation“ – wie sollen gehen? Gibt es „die“ agile Organisation überhaupt?

Nein – eine Schema F gibt es weder für den Weg noch für das Ziel. Und doch gibt es ein wesentliches Kennzeichen, das agile Organisationen auszeichnet: autonome, sich selbst organisierende Teams, die selbst entscheiden, wie sie arbeiten. Es wird Vorgaben geben, was zu tun ist. Wenn für die Teams zudem klar erkennbar ist, warum etwas zu tun ist, können sie Entscheidungen selber treffen und ihr Potenzial wertschöpfend einsetzen.

Was bedeutet Autonomie nun konkret? Wer hat die Geschäftsverantwortung? Wer entscheidet, an welchen Produkten oder Projekten gearbeitet wird – und an welchen nicht? Wer legt die Verteilung des Budgets fest? Wer entscheidet über die Einstellung von neuen Mitarbeitern und deren Zuordnung zu Teams? Wer beurteilt die Leistungen der Mitarbeiter und bestimmt das Gehalt? Die Antwort auf diese Fragen hängt – wie immer – von den Randbedingungen ab. Die Palette von Organisationen reicht von innovativen Startups, die noch ihre Kunden suchen, über Software-Dienstleiter, die für einen Kunden nach einem detaillierten Lastenheft arbeiten, bis zu Produktentwicklungen, die z.B. in einem streng regulierten Umfeld wie der Medizintechnik agieren.

Wenn wir uns entschlossen haben, die Organisation zu „agilisieren“, betreten wir Neuland. Es wird auch nicht viel helfen, wenn wir versuchen, Erfolgsstories wie Spotify und Google 1:1 auf unser Unternehmen zu übertragen.  Sowohl der genaue Weg als auch das genaue Ziel sind unklar. Wir sollten uns gleich von der Vorstellung verabschieden, den Endzustand irgendwann „einfrieren“ zu können, denn dann wären wir ja nicht mehr agil. Wir können bestenfalls Etappenziele festlegen. Geleitet von einer Vision (dem Was) und einem klaren Verständnis vom Nutzen, den diese Veränderung mit sich bringen soll (dem Warum), können wir Maßnahmen zur Erreichung der Etappenziele planen (das Wie) – und regelmäßig kontrollieren, ob wir noch auf dem richtigen Weg sind. Die Chancen auf Erfolg erhöhen sich, wenn wir an der Umsetzung folgender Prinzipien arbeiten:

  • funktions-übergreifende, an der Wertschöpfungskette orientierte Ausrichtung der Teams und Prozesse (das kann den Wegfall etablierter funktionaler Silos bedeuten)
  • Exzellenz in allen relevanten Funktionen (bzw. die Möglichkeit, diese Exzellenz durch Training und Coaching aufzubauen)
  • Zugriff zu allen relevanten Informationen
  • Transparenz zum Fortschritt und Erfolg unserer Aktivitäten (erfordert oft die Umstellung des klassischen Reportings)
  • Einbeziehung aller Unternehmensteile incl. Vertrieb, Personalwesen etc.
  • unterstützendes Management (Vorbild und Coach)

Zu diesen eher strukturellen Faktoren kommen weitere aus dem Bereich der Organisationskultur, die „unsichtbar“ sind, schwer zu erkennen und zu beeinflussen, aber mindestens genauso wichtig. Z.B. das gegenseitige Vertrauen zwischen Mitarbeitern und Management, der Wille zum Experimentieren und zum Lernen aus Feedback und Fehlern. Genau dieses Experimentiere und Lernen, oder in Scrum-Sprech „inspect and adapt“, brauchen wir für den Weg zur agilen Organisation.

 

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , | Kommentar hinterlassen

Ab heute sind wir eine agile Organisation

Als ich heute morgen in die Arbeit kam, fiel mir gleich auf, dass irgendetwas anders war. Kein Stau an der Eingangskontrolle, die „Personenvereinzelungsanlagen“ waren abmontiert. Der Pförtner begrüßten die Ankömmlinge mit einem strahlenden Lächeln und wünschten einen schönen Tag. Dann, auf dem großen Bildschirm im Eingangsbereich, ein Bild unseres Chefs mit einem Schriftzug „Ab heute sind wir eine agile Organisation“.

Und da stand er persönlich, der Chef, mitten unter den Mitarbeitern. „Liebe Kolleginnen und Kollegen“, sagte er gerade, „wir werden die Zukunft nur agil meistern. Dazu brauchen wir Sie, Ihr Wissen und Ihre Erfahrungen, Ihr Engagement, Ihre Ideen und Ihre Kreativität. Sie werden ab sofort als autonome Teams arbeiten. Ich bin überzeugt, dass Sie so den wertvollsten Beitrag für unser Unternehmen, unsere Kunden und die Gesellschaft zu leisten können. Sie sind die Experten und wissen doch ganz genau, was zu tun ist. Und damit Sie sehen, dass ich es ernst damit meine: ich verabschiede mich jetzt für 3 Monate von Ihnen. Ich gehe in Elternzeit. Ich bin überzeugt, dass Sie wunderbar ohne mich klarkommen werden. Viel Erfolg!“ Mit diesen Worten nahm er seine Krawatte ab mit einer Geste, als würde er sich von einer langjährigen Fessel befreien, und verließ fröhlich pfeifend den Raum.

Die Ankündigung löste tumultartige Reaktionen bei den Mitarbeitern aus. Kolleginnen und Kollegen lagen sich in den Armen, Freudentränen in den Augen. „Ich habe kaum zu hoffen gewagt, dass ich das nochmal erlebe! Endlich sind wir frei! Lasst uns gleich mit der Arbeit anfangen.“ Nur ein paar wirkten eher orientierungslos uns schauten sich hilfesuchend um.

Und siehe da, die ersten sinnvollen Dinge geschahen: die Mitarbeiter fanden sich spontan zu neuen, buntgemischten Gruppierungen zusammen. Entwickler, Tester, Architekten, Designer, Datenbank-Experten, sie alle waren dabei. Ich sah, wie sie eifrig damit beschäftigt waren, Ideen und Diagramme an großen freien Flächen zu skizzieren. Manche setzten sich auch gleich zu zweit oder zu dritt an einen Computer, um ihre Ideen auszuprobieren. Trotz des fieberhaften Eifers verlief das Geschehen in geordneten Bahnen – mit Hilfe einiger Personen, die als Moderatoren agierten. Sie erstellten Listen aus bunten Klebezetteln, die die neuen Teams Punkt für Punkt bearbeiten konnten. Ein paar wenige rafften ihre Aktenordner zusammen und verließen das Gebäude – ihnen war dieser Aktionismus wohl unheimlich.

Ich konnte förmlich zuschauen, wie sich eine neue Ordnung etablierte. Auch wenn ich es vorher nie in dieser Form gesehen hatte, erkannte ich es so fort: das war Selbstorganisation.

Plötzlich ging ein Raunen durch die Menge. Eine neue Gruppe von Personen betrat etwas schüchtern den Raum – die Kunden. „Wir haben gehört, dass Sie ab heute agil sind. Sollten wir dabei nicht eine entscheidende Rolle spielen? Unsere Lastenhefte haben wir heute mal zu Hause gelassen, damit wir unbelastet miteinander reden können.“ Unsere Mitarbeiter empfingen sie mit offenen Armen und verwickelten sie sofort in intensive Gespräche. Die Kunden schilderten mit leuchtenden Augen ihre Bedürfnisse und Wünsche. Nachdem sie das Gefühl hatten, verstanden worden zu sein, verabschiedeten sie sich mit dem Versprechen, in einer Wochen wiederzukommen. „Jetzt habe ich endlich kapiert, was die eigentlich von uns wollen“, hörte ich eine Mitarbeiterin sagen, „und ich glaube ich weiß sogar, wie ich ihnen wirklich helfen kann.“

Ich konnte es kaum erwarten, selbst bei dieser traumhaften Veränderung aktiv zu werden. Ich hatte auch schon einige Ansatzpunkte erkannt. Es schien mir z.B., als ob die verschiedenen neu entstehenden Gruppen versuchten, ähnliche Probleme zu lösen, ohne sich untereinander abzustimmen. Auch die Orientierungslosen konnten sicher Unterstützung gebrauchen…

„Jetzt nur nicht aufwachen“, dachte ich mir. Und wenn doch: einen Teil dieses schönen Traumes bewahren für die raue Wirklichkeit. Ich werde ihn dringend brauchen.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen