Agile Verbesserungsexperimente – transparent, wirksam, motivierend

AdobeStock_80783015

„Oh, stimmt, wir hatten uns ja Verbesserungsmaßnahmen vorgenommen. Weiß jemand, wo das Fotoprotokoll ist?“ „Leider keine Zeit gehabt…“. Trotz Retrospektiven bleiben Verbesserungs-Vorsätze oft auf der Strecke.

Zunächst einmal sollten wir uns bewusst darüber sein, dass es sich bei Verbesserungsversuchen um Experimente handelt: Wir wissen nicht, ob die Verbesserungsidee tatsächlich zum gewünschten Erfolg führen wird. Wir brauchen dafür einen gewissen Forscher-Geist und die Bereitschaft zum Lernen. Experimente schlagen nicht fehl, sondern zeigen uns, dass es so nicht geht.

Bevor wir also blauäugig jede Verbesserungsmaßnahme umsetzen, sollten wir uns überlegen, was wir durch unser Experiment lernen wollen, also welche Hypothese wir bestätigen oder widerlegen wollen.

Beispiel:

Auf dieser Basis können wir weitere Prinzipien und Praktiken nutzen, die wir für die Entwicklung von Software und Produkten mit Scrum anwenden:

• 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 schon während des Sprints ist, hat das Team hier die Zeit für die Priorisierung, Verfeinerung und Entscheidung zur Durchführung von Experimenten.
• 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.

Ein wenig Systematik kann helfen, sichtbare Ergebnisse zu erzielen. Das macht Spaß und motiviert zum Weitermachen!

Die agile Organisation: Der Weg ist das Ziel

Fotolia_65125778_M

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 Sinn und 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.

 

Mein agiler Traum – 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.

Photo by rawpixel.com from Pexels

Und siehe da, die ersten sinnvollen Dinge geschahen: die Mitarbeiter fanden sich spontan zu neuen, buntgemischten Gruppierungen zusammen. Entwickler, Tester, Architekten, Designer, Datenbank-Experten, Business Analysten… sie alle waren dabei. Selbst Leute aus dem Marketing, dem Vertrieb und aus der Personalabteilung! 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.

Photo by Aphiwat chuangchoem from Pexels

 

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.

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.

Photo by rawpixel.com from Pexels

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!

 

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 ;-).

 

Mein Block

Als ich neulich einem Kollegen von einigen Erfahrungen berichtete, war die Reaktion „Das ist ja interessant. Hast du das schon auf deinem Block gepostet?“ An meiner verständnislosen Mine war unschwer zu erkennen, dass dies nicht der Fall war. Meinen Block hatte ich schon vor Jahren abgeschafft, als ich noch an das papierlose Büro glaubte, aber noch keinen rechten Ersatz dafür gefunden. So konnte das nicht weitergehen! Schlimm genug, dass ich immer noch kein Smartphone und nur 4 Freunde bei Facebook habe, zwar ganz gern mal einen zwitschere, aber Twitter-abstinent bin. Wenigstens der blockfreie Zustand musste beendet werden! Nachdem meine Internet-Recherchen ergeben hatten, dass es den Ostblock nicht mehr gibt und der Schwarze Block von St. Pauli sich auch nicht zum posten (bestenfalls zum prosten) eignet, wurde ich relativ schnell bei WordPress fündig. Hier ist er also, mein eigener Block und mein erster (erstes?) Post – Prost!