Aussagekraft von Scrum-Zertifizierungen

„Diese Zertifikate sind doch nur eine reine Gelddruckmaschine.“ „Was ein Scrum Master / Coach [beliebige weitere Rollen] wirklich braucht, lernt er nur in der Praxis und nicht durch Zertifikate.“

Meine Antwort darauf: Zertifikat ist nicht gleich Zertifikat. Es ist richtig und sollte sich auch in Personalabteilungen rumgesprochen haben, dass die „Einstiegs-Zertifikate“, egal von welcher Organisation, nicht überbewertet werden sollten und den Inhabern bestenfalls theoretisches Wissen, aber keine praktische Erfahrung bescheinigen. Auf diesem Stand stehenzubleiben, ist nicht sehr sinnvoll, da theoretisches Wissen ohne praktische Anwendung und „Auffrischung“ schnell verfällt (wie das CSM-Zertifikat). Und genau zu diesem Zweck gibt es ja die weiterführenden Zertifikate, bei der Scrum Alliance (übrigens eine non-profit Organisation) z.B. den Pfad Certified Scrum Master (CSM) -> Advanced CSM (A-CSM) -> Certified Scrum Professional (CSP-SM) -> Certified Team Coach (CTC) -> Certified Enterprise Coach (CEC). Diese Zertifikate sind als Meilensteine einer persönlichen Entwicklungsreise zu sehen. Natürlich kann ich mir meinen eigenen Entwicklungspfad zurechtzimmern, aber bei der Scrum Alliance waren viele kluge Köpfe daran beteiligt, die aufeinander aufbauenden Learning Objectives zu definieren. Man kann die Learning Objectives auf unterschiedliche Weise erfüllen: durch Kurse, Coaching, eigenständiges Lernen… Die Zertifizierungsstufen ist dann eine Möglichkeit, den erreichten Stand von einer unabhängigen Instanz bewerten und nach außen sichtbar zu machen (incl. der für die Zertifizierung nachzuweisenden Erfahrung, z.B. 1000 Stunden Agile Coaching innerhalb von 2 Jahren für den CTC). Die höheren Zertifizierungsstufen schließen zudem Feedback und Mentoring von sehr erfahrenen Kollegen ein.

Dies ist ein jahrelanger Weg der ständigen persönlichen Weiterentwicklung, der einiges an persönlichem Einsatz nicht nur von einem selbst, sondern auch von den Freiwilligen erfordert, die sich bei der Scrum Alliance um die Zertifizierung kümmern. Ich finde, darauf darf man stolz sein, auch wenn es immer wieder Menschen gibt, die den Wert von Zertifikaten ganz generell in Frage stellen :-).

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

„Nur ein Narr macht keine Experimente“ – Vergleich von PDCA und Desing Sprints

Charles Darwin, von dem dieser kluge Spruch stammt, ist den meisten von uns als Urheber der Evolutionstheorie bekannt. Er hatte schon als Kind ein ausgeprägtes Interesse an Naturwissenschaften und am Experimentieren. 1831, mit 22 Jahren, ging er auf eine Entdeckerreise mit der HMS Beagle, die in in 5 Jahren einmal um die Welt führen sollte. Seine Neugier und sein Wissensdurst machten ihn zu einem der bedeutendsten Naturwissenschaftler.

Neugier – das ist das Verlangen, Neues zu erfahren und zu lernen, gepaart mit der Bereitschaft, sich überraschen zu lassen. Ohne diesen Wissensdurst gäbe es kaum Experimente, Innovationen oder Fortschritt. Albert Einstein stimmt zu: „Ich habe keine speziellen Talente, ich bin nur leidenschaftlich neugierig.“

Die Bedeutung der Neugier als Motor der geistigen Entwicklung ist in der (Entwicklungs-)Psychologie inzwischen aner­kannt. Schon bei Neugeborenen lassen sich erste Hinweise darauf finden. Mit etwa 1½ Jahren beginnen Kleinkinder regelrecht mit Gegenständen zu experimentieren, um ihre Beschaffenheit zu erkunden und herauszufinden, was sich mit ihnen alles machen lässt. Leider verlieren viele Menschen ihre Neugier mit zunehmendem Alter, weil sie sie mit Ungewissheiten, Risiken, Gefahren, Fehler, Versagen verbinden. Das Bedürfnis nach Sicherheit scheint das Bedürfnis nach neuen Erkenntnissen zu überdecken. Zudem unterbinden die vom Tayorismus geprägten Management-Methoden den geistigen und zeitlichen Freiraum, um Effizienz und Auslastung der Mitarbeiter zu optimieren.

Photo by Janko Ferlic from Pexels

Viele Unternehmen haben heute die Bedeutung der Neugier als Erfolgsfaktor für Innovationen (wieder)entdeckt. Der Gründer und Chef des Computerherstellers Dell brachte es auf den Punkt: „Wenn ich auf eine Fähigkeit wetten müsste, die ein Unternehmenschef in Zukunft braucht, wäre es die Neugier“, sagt Michael Dell, „daraus entstehen Ideen. Und wenn man keine Ideen hat, hat man ein großes Problem.“

Wie können wir die Fähigkeit zur Neugier nutzen und gleichzeitig dem Bedürfnis nach Sicherheit gerecht werden? Am besten wären doch „Safe-to-fail“-Experimente, bei denen das Scheitern einkalkuliert ist und dessen Folgen unter Kontrolle gehalten werden können. Unmöglich? Tim Harford verrät uns in seinem Buch „Adapt“, wie das geht:

The three essential steps are:

  • to try new things, in the expectation that some will fail;
  • to make failure survivable, because it will be common;
  • and to make sure that you know when you’ve failed.

Dieser Forschergeist und die Bereitschaft zum Scheitern um des Lernens willen ist für viele Organisationen ein Kulturschock. Sie haben sich noch nicht mit der zunehmenden Komplexität unserer (Arbeits)welt abgefunden: in komplexen Systemen gibt es keine planbaren Zusammenhänge zwischen Ursache und Wirkung. Sie sind nur durch Selbstorganisation anpassungs- und damit überlebensfähig. Auch wenn wir noch so viel Mühe in die Planung investieren, können wir nicht mit Sicherheit sagen, was die Wirkung unserer Aktionen ist. Also bleibt uns gar nichts anderes übrig als Experimente durchzuführen, deren Ergebnisse uns neue Informationen über das System liefern – und dabei keinen unakzeptablen Schaden anrichten (zu Details zu komplexen Systemen und Möglichkeiten, damit umzugehen, s. Cynefin).

Ein Experiment stellt eine Frage dar, der eine bestimmte Hypothese zugrunde liegen kann. Das Experiment kann aber auch einfach darin bestehen, ohne bestimmte Hypothese eine bis dahin nicht beobachtete Situation herbeizuführen und sich vom Ergebnis „überraschen zu lassen“. Dieser Unterschied wird deutlich bei der Gegenüberstellung von zwei Verfahren: dem PDCA-Zyklus und dem Design Sprint.

Bei dem PDCA-Kreislauf (Plan – Do – Check – Act) handelt sich um ein experimentelles Verfahren, der die Phasen im kontinuierlichen Verbesserungsprozess (KVP) beschreibt. Damit wird eine stetige Verbesserung der Prozesse und Abläufe verfolgt mit dem Ziel, die Effizienz, Kunden- und Mitarbeiterzufriedenheit des Unternehmens zu verbessern. Die Ursprünge entstanden bereits in den 30er Jahren des letzten Jahrhunderts (Shewhart, später von E. Deming weiterentwickelt). Die 4 Phasen sind:

  • Plan: Plane eine Veränderung oder einen Test mit dem Ziel der Verbesserung (Hypothesen-Bildung).
  • Do: Führe die Veränderung oder den Test durch – in möglichst kleinem Umfang (Experiment).
  • Check: Untersuche die Ergebnisse: Was haben wir gelernt? Was ist schiefgegangen? (Evaluierung)
  • Act: Setze die Veränderung um oder breche ab oder durchlaufe den Zyklus erneut.

Ein Design Sprint ist ein 4-5tägiger Workshop mit dem Ziel, ein Produkt, Prozess oder Service unter realen Verhältnissen zu testen. Das Format wurde bei Google entwickelt und wird mittlerweile bei vielen Unternehmen eingesetzt. Design Sprints lassen sich für die Entwicklung und Verbesserung von neuen Produkten (z.B. Apps) und für die Lösung von komplexen Herausforderungen nutzen. Es kommen dabei Methoden aus dem Werkzeugkoffer des Design Thinkings zum Einsatz. Diese Methoden bilden die Zutaten, während der Design Sprint das „Rezept“ ist, mit dem die Zutaten in einer bestimmten, strukturierten Abfolge „verarbeitet“ werden.

Der PDCA-Zyklus beginnt mit einer oft sehr umfangreichen Analyse der (problematischen) Ist-Situation, zum Beispiel mit Hilfe einer Ursachen-Analyse. Es wird eine Hypothese formuliert und damit auch die Kriterien oder Messdaten, mit der die Hypothese nach Durchführung des Experiments bestätigt oder verworfen werden kann. Die Veränderungs-Experimente sind eher klein, und der Prozess sieht nicht die Bewertung unterschiedlicher Optionen vor. PDCA ist also eher für iterative Prozessverbesserungen geeignet.

Beim Desing Sprint steht am Anfang eine Herausforderung. Der Problemraum wird durch Experteninterviews „erforscht“, und es werden massenhaft Lösungsideen generiert. Konvergentes und divergentes Vorgehen, Arbeit allein und im Team, wechseln sich sowohl bei der Problembeschreibung als auch bei der Lösungsfindung ab. Die Stärke vom Design Sprint liegt in der Entdeckung und Erforschung von Innovationen.

Beiden gemeinsam ist der Test: im PDCA-Zyklus die Überprüfung der Hypothese anhand von konkreten Daten, im Design Sprint das Feedback der Endanwender zu einem Rapid Prototype. Beide Verfahren kann ich zum Aufbau von safe-to-fail Experimenten nutzen: im PDCA-Zyklus, indem ich die Veränderungsschritte klein und überprüfbar plane. Im Design Sprint, indem ich in extrem kurzer Zeit „quick and dirty“ Prototypen baue, zu denen ich Feedback bekommen kann.

So können beide Prozesse dazu beitragen, Neugier, Interesse und die Offenheit für Neues und die Freude am Experimentieren und Lernen wiederzubeleben! Um am Schluss noch einen großen Autor und Beobachter zu zitieren: “Continuous improvement is better than delayed perfection.“

 

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

Brauchen „reife“ Teams noch einen Scrum Master?

„Sollen wir wirklich einen Scrum Master pro Team einstellen?“ „Ein paar Meetings organisieren, das kann doch keine Vollzeit-Rolle sein!“ “Was soll denn der Scrum Master machen, wenn das Team gut arbeitet?“ „Wie können wir die Produktivität des Scrum Masters messen?“ Solche und ähnliche Fragen meiner Kunden zeigen, dass die Rolle des Scrum Masters auch 20 Jahre nach der Erfindung von Scrum immer noch ein Mysterium ist.

Laut Scrum Guide ist der Scrum Master ein Coach und Servant Leader: er coacht alle Beteiligten (Product Owner, Entwicklungsteam und die gesamte Organisation) dabei, Scrum richtig anzuwenden. Er führt das Team zur Selbstorganisation und sorgt dafür, dass die Organisation incl. des Managements den nötigen Rahmen dafür gewährleistet. Je nach Organisation kann das eine anspruchsvolle und langwierige Aufgabe sein.

Ich fasse die Verantwortlichkeiten und Nicht-Verantwortlichkeiten des Scrum Masters so zusammen:

Verantwortlich:

  • Ermöglichen / Erleichtern der Arbeit und des ständigen Lernens des Scrum Teams sowie der gesamten Organisation (z.B. durch Beseitigung von organisatorischen Hindernissen)
  • Informationen sichtbar machen, dem System den Spiegel vorhalten
  • Kommunikation ermöglichen

Nicht verantwortlich:

  • Inhaltliche Arbeit zur Produktlieferung oder Projektarbeit
  • Management-Funktionen, z.B. Reporting
  • Administrative Aufgaben (JIRA, Meeting-Einladung, …)
  • Team-Performance (ist schwer zu messen, und alle Messungen tendieren dazu, ein lokales Effizienz-Optimum im Team zu erzeugen anstatt eines globalen, organisationsweiten Wertschöpfungs-Optimums)
  • Konfliktlösung (meist reichen die Skills dazu nicht)

Diese Liste von möglichen Aktivitäten entkräftet die Befürchtung, dass der Scrum Master herumsitzt und Däumchen dreht. Sie erfordern natürlich, dass die Organisation auch mitspielt und den Scrum Master seinen Job machen lässt – über das Einüben von Scrum-Praktiken im Team hinaus.

Tatsächlich ist es nicht so einfach, diese Verantwortlichkeiten und die Wirksamkeit eines Scrum Masters zu verdeutlichen. Er agiert oft im Verborgenen, und die Ergebnisse seiner Arbeit zeigen sich indirekt darin, dass andere besser werden. Die Rolle des Scrum Masters wird daher oft unterschätzt, erfährt keine angemessene Wertschätzung und wird schlecht bezahlt. In vielen Organisationen fehlen die Unterstützung und Möglichkeiten zur Weiterentwicklung.

Und nun zurück zur Ausgangsfrage: Wenn das Team und die ganze Organisation reibungslos nach Scrum arbeiten, hat dann der Scrum Master seinen Job getan? Besteht die Aufgabe des Scrum Masters darin, sich selbst überflüssig zu machen?

Photo by football wife from Pexels

Manche vergleichen den Scrum Master mit dem Coach eines Sportteams. Würde die deutsche Fußballnationalmannschaft, auch wenn sie noch so erfolgreich ist, ohne Coach auskommen? Auf der anderen Seite: kann man ein Scrum-Team mit einem Fußballteam vergleichen? Im Fußball sind das Ziel und auch die Regeln immer gleich. Ein Scrum Team dagegen sollte auch auf Änderungen der Zielsetzung und der Rahmenbedingungen schnell – „agil“ – reagieren. Bei der Reflexion des eigenen Handels sollte es in der Lage sein, die persönlichen Normen, Werte, und Regeln infrage zu stellen und zu ändern. Dieses sogenannte „Double Loop Learning“ [C. Argyris, D. Schön] ermöglicht im Gegensatz zu einfachen, situativen Verbesserungen (Single Loop Learning) grundlegende Verhaltensänderungen. Das kann bedeuten, dass ein Scrum Team nicht nur z.B. über Retrospektiven die Art und Weise verändert, wie es seine Meetings abhält, das Backlog priorisiert oder Tests durchführt. Vielmehr könnte es sich dazu entschließen, das Scrum Framework hinter sich zu lassen, weil es ihm nicht mehr hilft bei seiner agilen Reise. Damit wäre auch der Scrum Master – strenggenommen – kein Scrum Master mehr. Ein grundsätzlicher Unterschied zum Fußballteam: Wenn ein Fußballspieler auf die Idee kommt, die Regeln zu missachten, gibt es die Rote Karte!

Für diesen Lernprozess ist ein Coach mindestens genauso wichtig wie für das Fußballteam. Und er sollte außerordentlichen Fähigkeiten haben: er hat eine klare Vorstellung von seinen Zielen und Werten, ist aber auch in der Lage, seine Unzulänglichkeiten zu erkennen, zu bewerten und aus ihnen zu lernen. Er verfügt über Emotionale Intelligenz (in Bezug auf sich selbst), Soziale Intelligenz (in Bezug auf andere) und „System-Intelligenz“. Die Fähigkeiten ähneln sehr denen, die ich mir vom „Management der Zukunft“ wünsche. Ist es daher nicht naheliegend, die Rolle des Scrum Masters mit der eines Managers zu verbinden? Dies wird häufig abgelehnt, mit der Begründung, dass Mitarbeiter sich in der Gegenwart ihres Vorgesetzten „unnatürlich“ verhalten, auf den eigenen Vorteil bedacht und nicht als Team-Player. Der Grund sind klassische Management-Aufgaben wie Performance-Beurteilung, Gehaltsfestlegung, Beförderungen, Einstellungen und Entlassungen. Diese Aufgaben sind jedoch nicht automatisch an die Rolle der disziplinarischen Führungskraft gebunden, und es gibt bereits viele Firmen, die andere Wege gehen und sie dem Team überlassen.

Meine Zukunftsvision ist, das Scrum Master und Management miteinander verschmelzen, dass es also nur noch eine Rolle gibt, die sich um die Weiterentwicklung und Zukunftsfähigkeit von Mitarbeitern, Teams und der Organisation kümmert – den Agile Leader. Der Scrum Master macht sich also nicht überflüssig, nimmt aber mit zunehmendem „Agilitäts-Reifegrad“ andere Aufgaben wahr. Bis es soweit ist, haben einige Organisationen und Menschen noch einen weiten Weg vor sich.

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

Mut zu Agile

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 schlecht. Ich traute mich nicht, mich zu melden, wenn ich mir vorher nicht ganz genau überlegt hatte, was ich sagen wollte. Wenn ich aufgerufen wurde, ohne mich gemeldet zu haben, bekam ich Schweißausbrüche und lief rot an, was mir entsetzlich peinlich war. Dabei bin ich im Sternzeichen des Löwen geboren, sollte also von Natur aus mutig sein. Da muss wohl irgendwas schief gelaufen sein.

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. Ich lernte, dass man Mut trainieren kann.

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  – 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 und versuche daraus zu lernen.

Ich bin immer noch kein besonders 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.

Viel später lernte ich Scrum kennen und erfuhr von den fünf Scrum-Werten: Fokus, Offenheit, Commitment, Respekt – und Mut. Werte sind etwas sehr Persönliches: „Wofür stehe ich? Was möchte ich mit meinem Leben / mit meiner Arbeit vermitteln?“ Sich mit diesen Fragen auseinanderzusetzen, erfordert Mut. Daher ist Mut für mich die Voraussetzung für die anderen Werte.

Im Scrum-Guide steht zum Mut: Mut, das Richtige zu tun und an schwierigen Problemen zu arbeiten. Was genau ist das „Richtige“ und was sind „schwierige Probleme“? Dies hat sich seit den Anfangszeiten von Scrum und Agilität in den 90ern des letzten Jahrhunderts gewandelt. Erinnern wir uns: 1991 startete das Word Wide Web, 1999 erschien die erste „Cloud“. Die Software-Entwickler kämpften mit dokumentenlastigen wasserfallartigen Vorgehensmodelle. Organisationen waren hierarchisch und nach Funktionen in Silos organisiert. Eine erschreckend hohe Zahl von Software-Projekten scheiterte. Und so entwickelten clevere Leute leichtgewichtige Alternativen zu den vorherrschenden Prozessen, wie z.B. Scrum und xP. 2001 trafen sich 17 Repräsentanten dieser neuen Methoden in Utah zum Skifahren – und beim Apres Ski entstand das berühmte Manifest für Agile Software-Entwicklung. Diese agilen Vorreiter nannten sich selbst „Organisationsarnarchisten“. Wir können uns vorstellen, dass sie viel Mut brauchten, um gegen die herrschenden Zustände und Machtpositionen anzukämpfen. Mittlerweile ist Agile – oder besser Varianten von Scrum – zum Mainstream geworden – fast schon zu einer heiligen Kuh. Es erfordert keinen Mut mehr, sich für Scrum einzusetzen – eher wohl, etwas dagegen zu sagen. Oder darauf hinzuweisen, dass wir die erwähnten Probleme der 90er nicht alle in den Griff bekommen haben – insbesondere die, die mit der Organisationkultur zusammenhängen. Wie viele Unternehmen können 18 Jahre nach dem Agilen Manifest von sich ernsthaft behaupten, agil zu sein? Und vielleicht haben wir sogar trotz unseres guten Willens zur Schaffung neuer Probleme beigetragen. Mit Hilfe von Scrum lösen wir schwierige und komplexe Probleme und sind dabei kundenorientierter, flexibler und schneller als früher – aber tun wir damit wirklich das Richtige? Die Produkte und Technologien, die wir schnell und kundenorientiert auf den Markt bringen, haben komplexe Auswirkungen. Nur ein paar Beispiele: Ständige Internet-Nutzung schädigen das Gedächtnis und die Konzentrationsfähigkeit – nicht nur von Kindern. Arbeitsplätze gehen verloren durch den Einsatz von künstlicher Intelligenz. Persönliche Daten werden missbraucht, um Wahlen zu manipulieren. Bitcoin-Transaktionen verursachen horrenden Stromverbrauch.

Auch die Arbeitsprozesse haben Nebenwirkungen. Menschen brennen aus durch Informationsüberflutung und Beschleunigung von Arbeitsabläufen. Menschen, die sich nicht ständig selbst optimieren können oder wollen, fühlen sich abgehängt. Die Zufriedenheit der Mitarbeiter wird oft nur als Mittel zum Zweck gesehen, um die Profitabilität zu steigern.

So viele Veränderungen, die wirklich Angst machen können. Aber erheben wir Agilisten nicht den Anspruch, mit Veränderungen umgehen zu können? Wir brauchen Mut, um diese Angst zu überwinden. Wir brauchen auch Zuversicht und Optimismus, dass wir etwas ausrichten und die Zukunft mitgestalten können.

Liebe Product Owner, habt den Mut, nicht nur ans schnelle Geschäft zu denken, sondern an den gesamten Lebenszyklus eurer Produkte, mit all seinen möglichen Auswirkungen auf die Gesellschaft und die Umwelt. Liebe Teams, habt den Mut, über den Tellerrand eures Sprints hinaus Verantwortung für eurer Handeln, eure Produkte und eure Firma zu übernehmen. Liebe Scrum Master, habt den Mut, nicht nur die Produktivität und Effizienz, sondern Persönlichkeiten und Talente der Menschen zur Entfaltung zu bringen. Habt den Mut, euch zu wehren und zu verweigern, wenn nur ein Scrum-Etikett auf althergebrachte Vorgehensweisen geklebt werden soll. Ihr seid die Mut-Vorbilder für eure Teams! Liebe Führungskräfte, habt den Mut, euch vor allem auf die Menschen und dann erst auf die Zahlen zu konzentrieren. Habt den Mut, euren Mitarbeitern zuzuhören und deren Meinung auf Augenhöhe zu respektieren. Entwickelt Unternehmen, in denen erfolgreiche Beziehungen entstehen können und die der Arbeit der Menschen einen Sinn gibt und damit Freude.

Scrum ist „the art of the possible“ – das Beste aus dem Vorhandenen zu machen. Lasst uns unsere Erfahrung, unsere Werte-Orientierung und unser Methoden-Know How nutzen, um die wichtigen Probleme unserer Zeit zu lösen.

 

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , , | 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 | Verschlagwortet mit , , , , , , , , | Kommentar hinterlassen

Agiles Mindset – 3in1

agile-mindset-2

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. Vielleicht es für ein schon zum Buzzword geworden, das ihr nicht mehr hören könnt? Was genau ist damit eigentlich gemeint? Woran kann ich es erkennen, und was kann ich tun, um es 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 meinen Kunden verstehen, für ihn 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.

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.

Photo by rawpixel.com from Pexels

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 Scrum Master, die als Interessensvertreter von Kunden und Team für Balance sorgen – für meine eigenen Interessen bin ich selbst zuständig.

Photo by Akil Mazumder from Pexels

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. Ein Mindset entsteht nicht aus dem Nichts, sondern ist das Ergebnis von Erfahrungen. Ich kann nicht einfach einen Schalter umlegen und ein neues Mindset einschalten. Ich kann aber dafür sorgen, dass Menschen die Gelegenheit haben, neue, agile Erfahrungen zu sammeln. In der Arbeitswelt ist dazu ein organisatorisches Umfeld nötig.

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 | Verschlagwortet mit , , , , , , , , | 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 Schwarzen 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 | Verschlagwortet mit , , , , | Kommentar hinterlassen