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

Her mit den Problemen

In meiner Ausbildung zum lösungsfokussierten Coach habe ich Denken in Lösungen gelernt. Es hilft! Es ist motivierend, sich vorzustellen, wie es sein wird, wenn das Ziel erreicht und das Problem Vergangenheit ist. Daran zu denken, was gut funktioniert und wie man mehr davon machen könnte, eröffnet neue Perspektiven und setzt emotionale Kraft frei.problem lösung

Auf der anderen Seite kenne ich die Vorteile einer strukturierten Problemanalyse. Ich setze Techniken wie die Root Cause Analyse ein, mit denen ich den Problemen auf den Grund gehe. Wenn ich die tieferliegenden Ursachen kenne, kann ich Maßnahmen entwickeln, die das Übel an der Wurzel packen und nicht nur Symptome kurieren. Tabletten bekämpfen mein Kopfweh, aber genau das hindert mich daran, mir die Mühe zu machen, mit einem Kopfschmerzkalender die Ursachen für die Schmerzen herauszufinden.

Schauen wir uns ein anderes Beispiel an. Das Entwicklerteam hat wieder mal nicht alles geschafft, was es sich für den Sprint vorgenommen hat. Der problemorientierte ScrumMaster fragt in der Retrospektive: „Warum haben wir das Commitment nicht geschafft?“ Es kommen Antworten wie „Weil wir uns verschätzt haben“, „Weil der Product Owner mitten im Sprint mit neuen Anforderungen gekommen ist“, „Weil Peter eine Woche krank war“. Das beharrliche Weiterbohren des problemorientierten ScrumMasters fördert die Ursachen zu Tage: „Der Product Owner ist gewohnt, dass seine Wünsche sofort berücksichtigt werden, und möchte das weiter so haben“, „Das Commitment wird doch von niemandem ernst genommen und ist daher eigentlich überflüssig“, „Peter mag sein Wissen nicht teilen“.

Der lösungorientierte ScrumMaster fragt: „Stellt euch vor, wir sind im Review des nächsten Sprints und haben unser Commitment geschafft. Wie haben wir das hinbekommen?“ oder „Im vorletzten Sprint haben wir unser Commitment geschafft. Was war da anders?“ Das Team antwortet: „Wir haben einen Puffer in die Planung eingebaut“, „Wir haben Überstunden gemacht“, „Wir haben die neuen Wünsche des Product Owners ignoriert“.

In welchen der beiden Retrospektiven ist die Stimmung besser? Wahrscheinlich in der zweiten. Welche führt zu den besseren Lösungsansätzen? Wahrscheinlich die erste. Die Problemanalyse bringt uns vielleicht darauf, über den Sinn eines Commitments nachzudenken, anstatt zu überlegen, wie wir es erfüllen.

Komme ich mit Problemanalysen immer weiter? Nein – manche Probleme sind zu schwer zu durchschauen, zu komplex, ohne erkennbaren Zusammenhang zwischen Ursache und Wirkung. Oder die Ursachen entziehen sich meinem Einflussbereich. Ich werde die Haltung des Product Owners oder von Peter vielleicht nicht ändern können. Gerade in solchen Fällen hilft das Bauchgefühl, die Intuition, die das lösungsfokussierte Vorgehen auszeichnen. Sie erleichtern mir den Umgang mit dem Problem – auch wenn ich es gar nicht komplett verstanden habe. Lösungsfokus geht schneller, ist dafür aber weniger gründlich.

Wenn wir Problemanalyse einsetzen, müssen wir uns vor Schuldzuweisungen in Acht nehmen. Edward Deming, der „Erfinder“ des kontinuierlichen Verbesserungsprozesses, hat gesagt, dass 85 Prozent aller Fehler von einem mangelhaften System und nicht von den Mitarbeitern verursacht werden. Nicht Peter ist Schuld, wenn er sein Wissen nicht teilen will – das System honoriert Expertenteam mehr als Teamgeist. Nicht der Product Owner ist Schuld, dass er schnelle Reaktionen auf seine Anforderungen erwartet – seine Kunden erwarten auch schnelle Reaktionen von ihm, und die Auswirkungen solcher ad hoc Unterbrechungen auf das Team sind ihnen nicht ausreichend bewusst. Mit dem Team über Probleme zu diskutieren und ihnen auf den Grund zu gehen, kann Spaß machen – wenn das notwendige Vertrauensverhältnis dazu da ist, alle an einem Strang ziehen und Probleme als Chance für die gemeinsame Verbesserung behandelt werden.

Letztendlich hängt es an einzelnen Menschen, welche Vorgehensweise sie bevorzugen. Manche von uns sind her kopfgesteuert und analytisch, andere eher bauchgesteuert und emotional. Dementsprechend werden wir auch eine Vorliebe für eine der beiden Vorgehensweisen haben. Es ist hilfreich, beide im persönlichen Methodenkoffer zu haben, um sie je nach Situation anwenden zu können.

Probleme sind nicht das Problem – sie bringen uns dazu, uns weiterzuentwickeln. Langfristige und tiefgreifende Verhaltensänderungen sind dann nötig und möglich, wenn das bisherige Verhalten zu Problemen führt. Deswegen bin ich dafür, das Kind beim Namen zu nennen und nicht als „Herausforderung“ oder „Verbesserungspotenzial“ zu verklausulieren – und schon gar nicht unter den Teppich zu kehren. Also her mit den Problemen!

 

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

Ist Scrum Lean?

Heute habe ich gehört, Scrum sei die Anwendung von Lean in der Software-Entwicklung. Dazu habe ich mir meine Gedanken gemacht.

Na klar, Scrum hilft Teams (idealer Weise), Lean-Prinzipien umzusetzen. Ein paar Beispiele:

  • Wertschöpfung: der Product Owner ordnet (idealer Weise) den Backlog nach dem Wert für die Kunden.
  • Pull statt Push: das Team entscheidet (idealer Weise), wieviel Arbeit es in einem Sprint erledigen kann, und wird (idealer Weise) nicht gezwungen, mehr als das in den Sprint aufzunehmen.
  • Kleine Stapel an Arbeit (Batches): durch die zeitlich begrenzten Sprints ist auch die Menge des Work in Progress begrenzt. Dadurch werden (idealer Weise) Warteschlangen und Verschwendung vermieden.
  • Continuous Improvement: In den Retrospektiven entscheidet das Team, wie es immer besser werden kann. Idealer Weise wird dadurch auch die ganze Organisation besser.

Aber warum dieser Zusatz „idealer Weise“?

Mit dem Kunden im C-lean-sh

Ich kenne etliche Beispiele, wo ein „Product Owner“ nach allem möglichen priorisiert, aber nicht nach Wert für den Kunden. Weil er den Wert nicht einschätzen kann, vielleicht nicht einmal den Kunden kennt. Weil er zwar dem Team gegenüber als Vermittler dient, aber keine wirkliche Verantwortung für das Produkt trägt. Der Product Backlog ist eine „irgendwie“ geordnete Liste sein, nach der man die Arbeit organisiert. Das ist ja auch ok, da ich mit Scrum dies und das planen und organisieren kann, zum Beispiel meinen Umzug oder meine Geburtstagsfeier. Lean ist strenger. Lean rückt immer den Nutzen für den Kunden in den Vordergrund. Und zwar den wirklichen Kunden, nicht einen Abnehmer von Zwischenergebnissen am Ende eines Prozessschrittes. Die Testabteilung ist eben nicht der Kunde der Entwicklung. Nein, auch die Fachabteilung nicht. Nicht mal der Vertrieb, und schon gar nicht das Management. Sondern der, der unsere Produkte kauft und so dem Unternehmen die Einnahmen verschafft. Lean verlangt von allen Einheiten, dass sie sich zusammenraufen, um diesem Kunden zu nützen. Und alles, was ihm nicht nützt, wird erbarmungslos als Verschwendung klassifiziert. Wobei klar ist, dass wir diese Verschwendung nicht komplett wegrationalisieren können, weil unsere Organisation darauf angewiesen ist.

Ver-lean-kte Teams

Hilft denn Scrum automatisch dabei, Verschwendung zu vermeiden? Scrum Teams können Verschwendung vermeiden, wenn sie während der Sprints darauf achten, dass keine zu langen Warteschlangen entstehen. Dazu müssen die Team-Mitglieder bereit sein, Wissen und Erfahrungen so zu verteilen, dass sie sich gegenseitig helfen können, wenn es irgendwo brennt. Sie optimieren nur dann zum Wohle des Kunden und der Organisation, wenn sie sich als Teil eines Systems, eines Beziehungsgeflechts sehen und erkennen, dass ihre eigenen Bewegungen an anderen Stellen Zug oder Druck  auslösen. Sonst kann leicht ein lokales Optimum entstehen.

Lean, lean, nur Du allein…

Wenn trotz Scrum die Kunden nicht begeistert sind oder einzelne Einheiten eher gegen- als miteinander arbeiten, versucht es mal mit einer lean-dernden Maßnahmen wie der Wertstromanalyse – danach könnt ihr euch entspannt zurück-lean-en ;-).

 

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