Die 10 Voraussetzungen von Scrum

Bild: pxhere - CC0 1.0

"Wir haben es mit Scrum versucht, aber es funktioniert nicht!" Diese irgendwo zwischen Stossseufzer und Resignation schwankende Aussage dürfte schon in vielen Firmen gefallen sein. "Natürlich nicht, bei Euch fehlen die Voraussetzungen!" ist die in den meisten Fällen zu hörende Antwort. Was diese Voraussetzungen sind bleibt allerdings häufig unausgesprochen. Das muss nicht so sein, in den meisten Fällen reicht ein Blick in den Scrum Guide. Aus ihm lassen sie sich ableiten. Im folgenden zehn wichtige von ihnen, samt einer kurzen Erläuterung.

1. Scrum is founded on [...] empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known

• Was heisst das? Dass Scrum Teams alle relevanten Zahlen kennen müssen. Nicht nur Bugrate und Umsetzungszeit sondern auch Herstellungs-, bzw. Personalkosten, Kundenbewertungen, Nutzungsdaten, Marktforschungsergebnisse, etc.
• Warum ist das wichtig? Weil ohne Datengrundlage alle Verbesserungsversuche nur auf Mutmassungen basieren könnten und nicht validierbar wären

2. Everyone focuses on the work of the Sprint and the goals of the Scrum Team

• Was heisst das? Dass es für die Mitglieder eines Scrum Teams keine Teilzeit-Zugehörigkeit und keine Zusatzaufgaben geben darf
• Warum ist das wichtig? Weil Kontextwechsel und Verfügbarkeitsengpässe zwangsläufig dazu führen, dass Konzentration abnimmt, Wartezeiten und Konflikte dafür zunehmen
  

3. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work

• Was heisst das? Dass alle sich darauf einlassen, dass die Zukunft sich anders entwickelt als es geplant wurde, wodurch auch das Ergebnis ein anderes sein kann
• Warum ist das wichtig? Damit nicht weiter an obsolet gewordenen Plänen festgehalten wird, die nicht mehr zu Rahmenbedingungen und Marktbedürfnissen passen

4. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team

• Was heisst das? Dass die Selbstorganisation ernst gemeint ist. Nur das Scrum Team selber entscheidet wieviel Arbeit es in den Sprint nimmt, welche Metriken es erhebt, etc.
• Warum ist das wichtig? Um Bürokratie und Ineffizienz zu vermeiden. Die Effekte von Top Down-Management (Stille Post-Effekte, Reporting-Overhead, Entscheidungsverzögerungen, unrealistische Planungen) sollen vermieden werden
  

5. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team

• Was heisst das? Dass jede Fähigkeit die zur Herstellung eines Produkts nötig ist im Team vertreten sein muss, egal ob es um Backend, Frontend, UX, Marketing, Recht oder sonst etwas geht
• Warum ist das wichtig? Weil externe Abhängigkeiten immer wieder dazu führen, dass benötigte Personen nicht verfügbar sind und Arbeiten deshalb nicht beendet werden können
  

6. Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available

• Was heisst das? Dass nach jedem Sprint ein Produktionsrelease möglich ist. Er muss nicht stattfinden, er muss aber möglich sein
• Warum ist das wichtig? Weil sonst die Gefahr besteht, dass sich Integrations-, Release- oder Dokumentationsaufwände zu einer Bugwelle stauen die am Ende nicht mehr bewältigbar ist

7. For the Product Owner to succeed, the entire organization must respect his or her decisions

• Was heisst das? Dass der PO entscheiden darf ob bestimmte Funktionen ein- oder ausgebaut werden oder ob das unterbleibt
• Warum ist das wichtig? Um zu verhindern, dass Managementrunden, Steuerungskommittees oder andere Kontrollgremien zu Verzögerungen oder politisch getriebenen Entscheidungen führen
  

8. Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint

• Was heisst das? Dass die Teamgrösse zwischen 3 und 9 Mitgliedern (plus PO und Scrum Master) liegen muss (diese Zahlen sind ebenfalls aus dem Scrum Guide)
• Warum ist das wichtig? Weil zu kleine Teams hohe Ausfallrisiken haben und nicht crossfunktional sein können und grosse zu starke Effizienzverluste durch hohen Kommunikationsbedarf haben
  

9. Scrum Masters do this [promoting and supporting Scrum] by helping everyone understand Scrum theory, practices, rules, and values

• Was heisst das? Dass der Scrum Master nicht nur für das Coaching des Teams zuständig ist sondern auch für das Coaching von Managern und Stakeholdern
• Warum ist das wichtig? Weil sonst den (ggf. versehentlich) destruktiv handelnden Personen die Tragweite ihrer Handlungen nicht bewusst wird
  

10. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint

• Was heisst das? Dass a) Stakeholder im Review-Meeting anwesend sein müssen und b) sie dort aktiv Feedback geben müssen statt nur zuzuhören
• Warum ist das wichtig? Um zu vermeiden, dass das Scrum Team versehentlich am Bedarf vorbei produziert und schlimmstenfalls betriebsblind wird

Um es klar zu sagen: das sind anspruchsvolle Voraussetzungen, vor allem für grosse und hierarchische Organisationen. Im Zweifel sind sie nicht sofort erreichbar, was aber nicht schlimm ist, so lange man sie erreichen will und darauf hinarbeiten kann (jede Firma sollte sich dann aber fragen ob sie diesen Zustand bereits Scrum nennen will). Vielleicht passen sie aber auch gar nicht zur Unternehmenskultur und -struktur - dann ist Scrum vermutlich nicht der passende Ansatz.

Design Sprints (am Beispiel von illegalem Whisky)

Es geht doch nichts über eine Erklärung komplexer Sachverhalte anhand von abseitigen Beispielen.

Der vergessene Ursprung von Scrum

Eigentlich könnte man denken, dass über die Ursprünge von Scrum alles bekannt ist. Die Grundidee wurde in den 80er Jahren von japanischen Fabrikteams entwickelt und von Hirotaka Takeuchi und Ikujiro Nonaka in ihrem bahnbrechenden Artikel im Harvard Business Review The New New Product Development Game beschrieben, in dem auch erstmalig das Wort Scrum auftaucht. Ab 1993 wurden diese Erkenntnisse von Ken Schwaber und Jeff Sutherland auf die IT übertragen und 1995 wurde das so entstandene Vorgehensmodell der Öffentlichkeit vorgestellt. Zumindest ist das die weitverbreitete Annahme.

Was in diesem Zusammenhang wenig beachtet wird ist ein Buch aus dem Jahr 1990, das den Titel Wicked Problems, Righteous Solutions trägt und von zwei Amerikanern namens Peter DeGrace und Leslie Hulet Stahl verfasst wurde. DeGrace und Stahl wollten in diesem Werk die Probleme aufzeigen die durch die Anwendung eines Wasserfall-Vorgehens auf einen Softwareentwicklungsprozess enstehen und mögliche Alternativen erörtern. Neben anderen, mittlerweile vergessenen Ansätzen wie Whirlpool, Sashimi und Hollywood stellten sie auch einen namens Scrum vor, der auf autonomen, crossfunktionalen selbstorganisierten Teams beruht.

Nun könnte diese inhaltliche Ähnlichkeit, zeitliche Nähe und gleiche Benennung auch Zufall sein, es gibt aber Indikatoren dafür, dass Schwaber und Sutherland das Buch von DeGrace und Stahl kannten. Der offensichtlichste unter ihnen ist die Benennung: beide beriefen sich auf den oben genannten Artikel von Takeuchi und Nonaka, The New New Product Development Game. Was dabei leicht übersehen werden kann - in ihm wird das Vorgehen als Rugby Approach beschrieben, das Wort Scrum kommt nur einmal vor, und das an einer wenig prominenten Stelle. Es namensgebend zu übernehmen ist keineswegs naheliegend.

Ein zweiter Indikator ist der, dass überhaupt auf den Harvard Business Review-Artikel verwiesen wird, was voraussetzt dieses Magazin überhaupt gelesen zu haben. Aus heutiger Sicht erscheint das zwar nicht ungewöhnlich, eine so bekannte Publikation wird vielen Menschen gekauft worden sein. Man darf aber eines nicht vergessen: in ihm geht es um die Fertigung von Hardware in japanischen Fabriken. Das auf die Software-Industrie zu übertragen ist keineswegs etwas Naheliegendes worauf man schnell kommen würde.

Ein dritter Indikator ist schliesslich, dass sich einer der zentralen Slogans des heutigen Scrum bereits im Buch von DeGrace und Stahl findet. Es ist das kontrovers diskutierte doing twice the work in half the time. In Wicked Problems, Righteous Solution wird es noch weniger griffig formuliert, es heisst dort you further unsettle the team by saying that their job is to produce the system in, say, half the time and money and it must have twice the performance of other systems. Anders, aber klar widererkennbar.

Zur Ehrenrettung von Schwaber und Sutherland muss man ergänzen, dass viele der heute zentralen Elemente von Scrum bei DeGrace und Stahl noch nicht zu finden sind. Es gibt keinen Scrum Master, keine Sprints und keine Retrospektiven. Andere, wie z.B. die Incrementelle Lieferung, kommen zwar vor, werden aber separat von Scrum erläutert. Scrum im heutigen, engeren Sinn haben sie also erfunden. Trotz allem bleibt aber der Verdacht, dass die beiden sich anfänglich bei Wicked Problems, Righteous Solution bedient haben ohne es zu sagen.

Start where you are (II)

Bild: Max Pixel - CC0 1.0

Das mit dem Kanban-Prinzip Start where you are ist bekanntlich so eine Sache. An vielen Stellen muss man zuerst Klarheit darüber schaffen, was der Ist-Zustand ist, häufig verbunden mit der schmerzhaften Erkenntnis, dass der offizielle Prozess nur eine Fassade (so genanntes Business Theater) ist, während das gelebte Vorgehensmodell ganz anders aussieht. Selbst das lässt sich aber nochmal ins Unschöne steigern, und zwar auf eine Art die gerade in agilen Transitionen häufig ist.

Ein immer wieder anzutreffendes Phänomen ist es, dass eine festgefahrene Transition erst dann wieder Fahrt aufnehmen kann wenn man sich in Bezug auf die bisher erzielten Ergebnisse ehrlich macht. Und dort wo man sich an diese Wahrheiten traut kann es peinlich werden: gerade die scheinbaren Vorzeige-Erfolge entpuppen sich häufig als Missverständnis, nicht zielführende Umsetzung oder im schlimmsten Fall sogar Etikettenschwindel.

Einfach ist es noch dort wo offensichtlich getrickst wurde. Wenn nur bestehende Rollen, Prozesse und Meetings ohne inhaltliche Änderung umbenannt wurden lässt sich der Finger schnell in die Wunde legen. Das kann zwar für diejenigen peinlich sein die sich mit den scheinbaren Erfolgen gebrüstet haben, im den meisten derartigen Fällen ist der Etikettenschwindel aber ohnehin ein offenes Geheimnis, dessen Aufdeckung nur mit einem "endlich sagt es mal einer" kommentiert wird.

Schwieriger ist es in Konstellationen in denen in grösserem Ausmass Cargo Cult anzutreffen ist. Wenn die Verantwortlichen und Beteiligten aufgrund von fehlendem Verständnis bisher davon überzeugt waren alles richtig gemacht zu haben, dann kann das Aufdecken dieser Illusion eine unschöne Überraschung sein, häufig verbunden mit emotionalen Abwehrreaktionen. Diese sanft aufzufangen und sachlich auf die Missverständnisse hinzuweisen kann eine herausfordernde Aufgabe sein.

Wirklich kompliziert kann es dann werden, wenn zwar das richtige Verständnis und grundlegend richtige Massnahmen anzutreffen sind, die scheinbaren Erfolge aber nur auf unerkannten Seiteneffekten beruhen. Ein Beispiel dafür könnte ein Kanban-Pilotteam sein, dass scheinbar seinen Wertstrom erfolgreich optimiert hat, bei dem in Wirklichkeit aber die Protegierung durch den Geschäftsführer zu einer Vorzugsbehandlung im Vergleich zu anderen Teams geführt hat, wodurch die unverändert im System vorhandenen Unwuchten bei Auslastung und Staffing einfach an andere Stellen verlagert werden.

In derartigen Fällen muss das Start where you are dazu führen, dass das scheinbare Erfolgsmodell als Problemfall erkannt und offensichtlich gemacht wird. Nur dann kann der kontinuierliche Verbesserungsprozess einen Ansatzpunkt finden und Wirkung entfalten. Die Reaktionen darauf können nochmal heftiger ausfallen als im Fall der Cargo Cult-Implementierung, schliesslich können die Beteiligten zu Recht darauf verweisen "alles richtig gemacht zu haben". Diesen Frust ernst zu nehmen, in konstruktive Bahnen zu lenken und zum Ausgangspunkt einer echten Transition zu machen ist dann das Meisterstück des verantwortlichen Change Managers.

"El Jefe", der Kunde

Bild: Wikimedia Commons / Er nun wieder - CC BY-SA 3.0

Einmal mehr ist es der Zufall durch den eine interessante Geschichte zu Stande kommt. Zu Besuch bei dem in Spanien lebenden Teil der Familie kam das Gespräch zufällig auf die Supermarktkette Mercadona, die in den letzten Jahrzehnten viele ihrer Konkurrenten verdrängt hat. Das wäre auf ein fortschrittliches Management-Konzept zurückzuführen, hiess es. Neugierig geworden nutzte ich später die Zeit am Flughafen für eine kurze Recherche, und tatsächlich - im Wall Street Journal, in El Pais und in Publikationen der Harvard Business School liess sich einiges über dieses Unternehmen finden was sich bemerkenswert anhört.

Eine der interessantesten Ideen ist die Hierarchie der verschiedenen Zielgruppen und Stakeholder die durch das Unternehmen bedient werden sollen. Der Wichtigkeit nach absteigend sind das der Kunde, die Angestellten, die Gesellschaft, die Lieferanten und die Eigentümer. Das ist bemerkenswert: nicht nur, dass der Kunde an der Spitze steht (das behaupten fast alle Firmen von sich), sondern auch das was danach kommt - Angestellte, Gesellschaft und Lieferanten nicht nur als Zielgruppe zu nennen sondern sie sogar über den Eigentümern einzuordnen ist etwas was ich noch nicht gehört habe.

Ungeachtet dessen scheint es so, dass auch versucht wird dem Anspruch der Kundenorientierung gerecht zu werden. Dazu gehört nicht nur freundliches, gut ausgebildetes Personal (kann ich aus eigener Anschauung bestätigen) sondern auch darüber hinausgehende Ansätze: das Management wird angehalten regelmässig auf der Verkaufsfläche mit Kunden zu sprechen, und nicht nur im sondern auch um die Supermärkte findet Marktforschung statt. Etwa durch Kundenmanager die in den umliegenden Cafes mit den Kunden über ihre gerade getätigten Einkäufe reden.

Apropos Personal: um die Wünsche des Kunden (intern "El Jefe" genannt) besser erkennen und umsetzen zu können sind die Teams der einzelnen Supermärkte so crossfunktional wie möglich. Das heisst nicht nur, dass sie (wie auch in Deutschland üblich) je nach Bedarf zwischen Kassieren, Reinigen und Einräumen wechseln können, sondern dass sie Fortbildungen in Warenkunde, Kundenansprache, Betriebswirtschaft und Logistik erhalten. Mit Hilfe dieses Wissens sind sie in ganz anderer Weise in der Lage Prozesse erkennen, beurteilen und optimieren zu können.

Diese Optimierungen finden schliesslich fast nie in Form von grossen Change-Programmen statt sondern durch viele, kleine, ständig durch Feedback verbesserte Schritte. Mal ist es die Einführung von Familienpackungen, mal die Reduktion von Verpackungsmüll (beides in Kooperation mit Lieferanten), an anderen Stellen werden Arbeitsschritte automatisiert (z.B. bei den Preisanzeigen), Beratungsangebote verbessert, Transportwege verkürzt oder Recyclingquoten erhöht.

Ein weiteres Beispiel dafür wo man lean und agile Praktiken finden kann. Nicht nur bei Google und Spotify sondern auch um die Ecke, im nächsten Supermarkt.

Kommentierte Links (XXXXIX)

• Steve Denning: Understanding Fake Agile

Der Titel dieses Artikels ist leicht irreführend, da Steve Denning in ihm nicht nur das beschreibt was er (zu Recht) als "Fake Agile" bezeichnet sondern auch Frühstadien und Mischformen die nicht unbedingt schlecht sein müssen. Im Einzelnen spricht er von den folgenden Typen:

• Agile im Frühstadium
• Etikettenschwindel-Agile
• Agile nur in der Software-Erstellung
• Angehaltene Agile Transition
• Gebrandetes Agile
• Skaliertes Agile (v. A. SAFe)
• Agile light
Besonders mit dem vorletzten Punkt hat er natürlich für Gesprächsstoff gesorgt, da er damit einen nicht unwesentlichen Teil aller sich als agil empfindenden Firmen angreift. Die Art wie denen mittlerweile gegenübergetreten wird wäre aber ein Thema für sich und geht über Dennings Artikel hinaus (siehe auch: Extremists and the hate SAFe machine).

• Michael Küsters: It's still about agile teams

  Ein Text der auch als Reaktion auf Dennings Fake Agile-Artikel verstanden werden kann kommt von Michael und versucht sich an der Ehrenrettung von SAFe. In Anerkennung des Phänomens, dass ein Grossteil der SAFe-Implementierungen mit Agilität nicht viel zu tun hat weist er darauf hin, dass nicht alles was schlecht funktioniert auch schlecht gemeint ist. Vor allem mit dem ersten Punkt aus einer von ihm zusammengestellten Liste wiederholt auftretender Probleme dürfte er den Nagel auf den Kopf getroffen haben: SAFe wird als Management-Methode wahrgenommen und nicht als Ansatz der Produktentwicklung. In der Realität dürfte genau das die Ursache für die meisten fehlgeschlagenen Umsetzungen sein. Michaels Gegenmodell einer SAFe-Variante die die Entwicklung und Unterstützung der unteren Arbeits-, bzw. Teamebene in den Mittelpunkt stellt ist zwar idealistisch, in der Realität aber leider fast nicht existent.
  

• Allen Helton: The 5 W’s of Rapid Prototyping

  Aus dem Grossen (der Skalierung) in Kleine. Rapid Prototyping ist eine Entwicklungsvariante die auch da Sinn macht wo von Agilität noch in den Anfängen steckt, die aber ebenfalls in fortgeschrittenen agilen Kontexten anzutreffen ist. Ähnlich wie ein MVP oder ein Proof of Concept ist ein Prototyp ein noch unfertiges Zwischenergebnis, mit dem schon erste Annahmen validiert oder erste Tests durchgeführt werden können. Agil wird diese Idee in Form des Rapid Prototype, was bei Allen Helton bedeutet, dass er innerhalb eines Sprints fertiggestellt werden kann. Anhand von Beispielen erläutert er wo ein solches Vorgehen Sinn macht, wie man es erreichen kann, was als Ergebnis herauskommen könnte und wer mitarbeiten sollte. Das klingt bei ihm erstmal einfach, ist es aber natürlich nicht. Ohne Produktvision, Nutzerverständnis und technische Exzellenz ist Rapid Prototyping nicht zu haben. Was aber auch zu beachten ist: selbst wenn man durch den Versuch einen Rapid Prototype zu bauen nur ein bisschen besser in diesen Bereichen wird ist auch das schon ein Gewinn.

• Matthew Strom: Responsive Roadmaps

  Über die Gemeinsamkeiten von Product Roadmaps und geografischen Karten hatte ich schon mal etwas geschrieben, Matthew Strom denkt diese Idee aber nochmal in eine andere Richtung weiter. Angelehnt an die Darstellungsprobleme von Weltkarten zeigt er eine Fehlwahrnehmung auf die mit klassischen Roadmaps verbunden ist: statt sie als vereinfachte Darstellung zu sehen, aus der man für bessere Verständlichkeit einen Teil der Komplexität ausgeblendet hat, werden sie für ein repräsentatives Abbild der Realität gehalten. Sich derartig an ihnen zu orientieren würde aber genau so wenig ans Ziel führen wie eine Übersee-Navigation anhand einer Mercator-Karte. Sein Alternativvorschlag ist erkennbar an das Objectives and Key Results-Modell (OKR) angelehnt, was diesen Artikel aus noch einem anderen Grund lesenswert macht - es zeigt was man mit OKRs alles anfangen kann wenn man aufhört darin nur ein Instrument der Menschenführung zu sehen.

• Stefan Barth: Wann muss das Management in agile Teams eingreifen?

  Noch einmal ein neuer Blick auf ein Thema über das ich schon einmal nachgedacht habe. Unter welchen Umständen darf ein Manager eingreifen und einem selbstorganisierten Team eben diese Selbstorganisation wieder wegnehmen? Die vereinfachte Antwort: wenn es Dysfunktionen entwickelt die so schwerwiegend sind, dass es sie selbst nicht mehr beheben kann. Dass Stefan das derartig offen anhand von (anonymisierten) Fällen aus der eigenen Firma bespricht ist einer der seltenen Fälle in denen offen über ein Phänomen gesprochen wird das häufiger ist als man denkt.

Ein Bild sagt mehr als 1000 Worte (XXV)

In einer besseren Welt wäre das ein Burndown-Chart geworden. Aber es hat nicht sollen sein.

Frontline Staff driven Improvement

Normalerweise würde man die agilen Vorgehensweisen mit ihren kurzen Lern- und Feedbackzyklen und schnellen Reaktionen vor allem in der IT erwarten, wo sie auch bis heute schwerpunktmässig vorkommen. Beispiele für eine Umsetzung in einem anderen Umfeld gibt es trotzdem, und gerade wegen ihrer Ungewöhnlichkeit sind sie in vielen Fällen bemerkenswert. Der Grund dafür ist, dass den Beteiligten die gängigen Frameworks oft gar nicht bekannt sind, weshalb sie Vieles selbst entwickeln und so zu methodischen Innovationen beitragen. Ein derartiger Fall sind die Cleveland Kliniken, eine Krankenhauskette in den USA.



Was in diesem Video zu sehen ist, ist ein auf zweimal täglich stattfindenden "Huddles" (Standup Meetings) beruhender Verbesserungsprozess. Jedes Team führt sie für sich selbst durch, identifiziert hier Verbesserungspotentiale und arbeitet an ihrer Umsetzung. Als Umsetzungshilfe wird dabei ein selbstentwickeltes Improvement Model genutzt, das die Verbesserungsprozesse visualisiert und so vergleichbar und nachverfolgbar macht.

Da zwar viele aber nicht alle Probleme auf diese Art und Weise gelöst werden können kaskadiert der Prozess nach oben. Sobald die Teams der untersten Hierarchieebene sich besprochen haben geben sie die nicht selbst lösbaren Probleme an das zeitlich anschliessende Huddle der nächsthöheren Hierarchieebene weiter. Auch dieses löst möglichst viel davon selbst und gibt den Rest an die nächsthöhere Ebene weiter, die genauso verfährt. Da alle Huddles zeitlich begrenzt sind und aufeinander folgen sind die morgens auf den Stationen festgestellten Probleme spätestens Mittags dort angekommen wo sie gelöst werden können - selbst dann wenn das die oberste Geschäftsführung ist.

Mit diesen so genannten "Tiered Huddles" sind bei den Cleveland Kliniken bemerkenswerte Strukturen entstanden, die so auch in agilen Firmen nicht häufig zu finden sind. Vor allem die Kombination aus Subsidiarität und leichtgewichtigen Prozessen macht eine enorme Geschwindigkeit in der Abstimmung, Informationsübermittlung und Problemlösung möglich. Inspirierend.