Scrum als System für agile (adaptive) Produktentwicklung

Nehmen wir einmal an agile Methoden wie Scrum (XP, etc.) wurden von ihren Erfindern als ein zweckmäßiges System zur iterativ inkrementellen Entwicklung von Software designed, sodass die Teile (Entwicklungsteams und Kunden) so interagieren, das benutzertaugliche Software dabei herauskommt. Vieles spricht dafür, dass Scrum und auch XP als System zusammenhängender Praktiken designed wurden. Die Erfinder haben immer wieder betont, man könne nicht einfach einige nützliche Teile implementieren und dann hoffen, den gewünschten Zweck damit zu erfüllen, da die Teile nur in ihrer Gesamtheit dazu in der Lage sind, aber nicht beliebige Teilmengen dieser Praktiken.

Diese Sichtweise von interdependenten, agilen Praktiken liefert gleichzeitig einen Ansatz für die Definition eines minimalen agilen Vorgehens, etwas das bei Crystal leichtgewichtige Methode oder "barely sufficient methodology" genannt wird
http://alistair.cockburn.us/Balancing+lightness+with+sufficiency

Was "barly sufficient" ist, hängt dabei vom Kontext ab, bei der Crystal Familie z.B., die Größe und die Kritikalität (Risiko) des Projekts. Laut Cockburn soll es einen "sweet spot" geben, wonach in einem bestimmten Kontext (Größe, Risiko) keine Praktiken mehr weggenommen werden können, ohne dass die Effektivität der Methode leidet.

Diese Minimalität ist auch ein wichtiger Punkt bei der Definition der Regeln des Large Scale Scrum Frameworks aka LeSS,
https://less.works/less/principles/more-with-less.html

wobei der sweet spot in der Skalierung laut LeSS hauptsächlich in der richtigen Gewichtung von agilen Praktiken und Prinzipien liegt. So legen die Lernende Organisation und Kanban zu viel Gewicht auf Prinzipien und Scaled Agile Framework (SAFe) und RUP zu viel auf Praktiken. Der sweet spot in diesem zweidimensionalen Raum ist - wie nicht anders zu erwarten - LeSS.

Für das agile Coaching bedeutet dies, des es durchaus Sinn mach bestimmte Praktiken einmal wegzulassen - sofern dies nicht agilen Werten und Prinzipien widerspricht - um das Vorgehen zu vereinfachen und damit auch Verschwendung zu vermeiden. Die Einschränkung auf Agilität ist wichtig, denn Softwareentwicklung ohne häufige Lieferung, Zusammenarbeit mit Kunden und Anpassungen, zum Vorteil des Kunden ist keine Agile Softwareentwicklung, das wäre wie bei einem Auto den Motor oder die Reifen wegzulassen! Dementsprechend hat Scrum und LeSS deutlich weniger Rollen, Meetings und Artefakte als SAFe oder RUP, und man tut gut daran zu fragen, wofür es diese extra Rollen, Meetings und Artefakte denn braucht und was passieren würde, wenn man sie einfach weglässt. Kann ich den beabsichtigten Zweck der Entwicklung auch noch ohne diese Praktiken erreichen?

Dies ist ein Problem als auch ein Trend, der bei SAFe vor nicht allzu langer Zeit zur Definition von Essential SAFe geführt hat:

http://www.scaledagileframework.com/guidance-essential-safe/

Dabei stand aber weniger die Minimalität des Ansatzes im Vordergrund, als dass man definieren wollte, was man denn bei SAFe als "best practice" weglassen kann, ohne die Effektivität des gesamten Frameworks zu beeinträchtigen. (Das Ziel ist bei SAFe die Verbesserung von Engagement und Produktivität der Mitarbeiter, höhere Qualität und kürze Time to Market)

Was die Frage der Effektivität und das Ziel agiler Methoden anbetrifft, so gibt es einige Unklarheiten und Verwirrung.

Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive 
Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.

Das primäre Ziel scheint irgendeine, von außen vorgegeben komplexe Aufgabenstellung, z.B. ein Projekt. Ein allgemeines, sekundäres Ziel in Scrum ist es, jeden Sprint fertige, (potentiell) auslieferbare Produktinkrement zu entwickeln, wodurch nicht nur der (durch den Backlog definierte) Funktionsumfang des Inkrements wächst, sondern auch eine der Mehrwert (ROI) für den Kunden gesteigert, wenn er (rsp. der PO) das Inkrement in Betrieb nehmen würde. Optimierung des ROI durch den PO steht also für Scrum als Ziel im Vordergrund - Kundenzufriedenheit scheint dabei eher sekundär ein Mittel zum kommerziellen Zweck!

Im Gegensatz zu Scrum scheint bei Adaptiver Software Entwicklung (ADS) mit seinem Speculate, Colloborate, Learn Zyklus das Ziel primär Lernen durch Kundenfeedback zu sein, zu Lernen

- was ein Benutzer zur Erledigung seiner Aufgaben braucht oder
- welches Produkt sich am Markt am Besten gegen die Mitbewerber behaupten kann

Indem wir das unfertige Software Inkrement in Betrieb nehmen, z.B. durch Usability oder Beta Tests, lernen wir, wie Nutzer in der Firma oder im Markt es zur Erreichung bestimmter Aufgaben (jobs to be done) benutzen. Mit den Worten der Lernenden Organisation: wir passen unser Mentales Modell der Benutzung der Software den tatsächlichen Gegebenheiten an. (Diesen Lerneffekt kann man allerdings auch schneller und günstiger bekommen durch Mock Ups, Klick Dummies und Innovation Games we "Me and My Shadow" und "The Apprentice")

Ein weiterer (Meta-)Zweck von Scrum wie ADS ist, dass es eine Produktentwicklung mit hoher Komplexität ermöglicht, also mit

- unklaren oder häufig wechselnden Anforderungen
- unbekannten Technologien und/oder
- mit mehreren, (mehr oder weniger!) voneinander abhängigen Scrum Teams, die das selbe Produkt entwickeln.

Produktentwicklung an der Grenze zum Chaos - was in den heutigen Zeiten der Regelfall geworden ist.

Scrum Praktiken wie, Timeboxing - im besonderen kurze Sprints, Fokus durch auf die Produkt Vision abgestimmte Sprint Ziele, der empirische PDCA Zyklus (empirische Prozesskontrolle), visuelle Artefakte zur Erhöhung der Transparenz, die Definition of Done, teil-autonome, selbstorganisierende Scrum Teams und die Product Owner Rolle als Schnittstelle zum umgebenden sozialen System ...
als das soll helfen jeden Sprint etwas weniger komplex (kompliziert bis einfach) zu machen als das Gesamtentwicklungsvorhaben - eine iterativ-adaptives Teile-und-Herrsche Methode zur Bewältigung der Komplexität.
Weitere Prinzipien zur Beherrschung der Komplexität sind
- Einfachheit des Ansatzes a la Dee Hock:
Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.“
- Leichtgewichtigkeit und Deskalierung a la LeSS (s.o.)

Die Prinzipien des Agile Manifest können helfen, um die Frage des Ziels von agilen Methoden weiter zu klären:
http://agilemanifesto.org/iso/de/principles.html

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Heisse Anforderungsänderungen selbst spät
in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen
zum Wettbewerbsvorteil des Kunden.

Das heißt, Agilität, Flexibiltät und Adaptivität des Vorgehens sind eigentlich nur Mittel zum Zweck, der Steigerung

- der Kundenzufriedenheit und
- des Wettbewerbsvorteils des Kunden.

Diese Ziele der Agilität erinnern stark an die Ziele von Lean Thinking

- höchste Kundenzufriedenheit
- höchste Qualität und
- kürzeste Lead Time

die natürlich zusammenhängen und nicht unabhängig voneinander sind

Das Ziel die Erwartungen der Kunden zu erfüllen oder zu übertreffen, sie zu begeistern, es auch Teil anderer interativer und/oder systemischer Ansätze, deren Ziele eine gewisse Verwandschaft mit dem agilen Vorgehen aufweisen

- Benutzertauglichkeit in User Centered Design
- Kundenfriedenheit im Kano Modell (Begeisterungs-Features)
- Kunden begeistern in Radical Management (Messung der Kundenzufriedenheit durch NPS)
- Effektivität von Teams in Hackman's Leading Teams
- Problem-Solution-Fit und Product-Market-Fit in Lean Startup und Customer Development

Daher tendiere ich dazu Kundenzufriedenheit auch als primäres Ziel der Agilen Produktentwicklung zu betrachten, wobei die Begriffe von Problem-Solution-Fit und Product-Market-Fit mir aus systemischer Sicht am interessantesten erscheinen

1. weil Experimentieren und Lernenein wichtiegr Bestandteil ist und
2. dort verschieden Faktoren zusammenwirken, wie

- Kundenzufriedenheit
- Produktqualität und
- Wirtschaftlichkeit

Diese Mehrdimensionalität des Zieles ist auch ein Kennzeichnen ganzheitlicher Ansätze wie TQM und Design Thinking (allerdings mit unterschiedlichen Fokus: Prozess-Qualität, Reduktion von Variabilität vs Benutzertauglichkeit, Ausnutzen von Variabilität).

Wie wirkt sich diese Sichtweise auf die Agilen Produktentwicklung und das Agile Coaching aus?

Gemäß den Prämissen:
- Effektivität (das Richtige) geht vor Effizienz (es richtig zu tun) und
- Optimiere das Ganze nicht seine Teile
hieße dies zu klären

Problem-Solution-Fit:
Haben wir ein Kunden Problem identifiziert, das es wert ist gelöst zu werden?

Roman Pichler hat Scrum und Lean Startup miteinander verheiratet und gibt einen guten Überblick über die einzelnen Phasen des Customer Development Prozesses:

http://www.romanpichler.com/blog/new-product-development-with-lean-start...

In der Praxis gibt es - typisch agil - natürlich Überlappungen der Phasen, speziell, wenn man einen leanen "set based design" Ansatz bei der Suche nach passenden Lösungen verfolgt. Außerdem können auch noch in der Wachstumsphase größere Veränderungen im Markt eine Anpassung des Business Modells erfordern und der Prozess geht wieder von vorne los!

Wird nicht ein neues Produkt an den Markt gebracht, sondern ein vorhandener Prozess automatisiert, stellt sich u.U. die Frage des Problem-Solution-Fit so nicht. Da stellt sich eher die Frage, ob der aktuell beschriebene (und gelebte) Prozess so effektiv und effizient ist. Ansonsten sollte der Prozess vor der Automatisierung erst optimiert werden.

Eine beliebte Methode um Prozesse zu Visualisieren und deren Automatisierung zu planen ist das Story Mapping. Mit ihr lassen sich auch kleine (minimale) Inkremente wie das sogenanntes Walking Skelleton und weitere MVPs definieren:
http://jpattonassociates.com/the-new-backlog/

Bei Story Mapping scheint es eher um Problem-Solution-Fit zu gehen, was in Lean Startup eine Vorstufe und Voraussetzung für Product-Market-Fit ist.

Product-Market-Fit:
Bringt das Produkt genug Geld ein, um das Wachstum der weiteren Produktentwicklung zu finanzieren?

Hier gibt Lean Startup und der sogenannte Build-Measure-Learn Zyklus weiterer MVPs interessante Antworten. Product-Market-Fit lässt sich dabei auf unterschiedliche Weise messen, z.B.

- 40% der User müssen für das Produkt oder Feature einen Preis zahlen, der die Kosten und das weitere Wachstums der Entwicklung selbst finanziert.
- hoher NPS von 9 oder 10, sodass Empfehlungen einen viralen Marketing Effekt verursachen (leading indicator)
- oder was sonst gerade marketing-technisch relevant ist, mehr User, höhere Retension (Wiederkehr Rate), mehr Referrals (Empfehlungen), mehr Umsätze, ...

In Scrum und Large Scale Scrum entspricht der Build-Measure-Learn Zyklus dem PO Zyklus von der Produkt Vision (Beschreibung des Problems), über die Release Planung mittels Product Backlog (Beschreibung der Lösung), zur Bewertung der Effektivität des nächsten Releases (outcome statt output).

Dazu wird z.B. bei Specification by Example "Drive Scope from Goals" eine Methode namens Impact Mapping angewendet:
https://www.impactmapping.org/drawing.html

Hier kann ich, wie bei den Lean Startup, den Grad der Zielerreichung messen. Möchte ich mehr User, dann messe ich die Anzahl an Anmeldungen, aktiven Nutzern und Empfehlungen. Möchte ich mehr Umsatz, dann messe ich die Konversionsrate. Mit einem Marketing- und Vertriebs-Modell im Hintergrund, lassen sich einfach passende Ziel definieren und messen.

Also erst Story Mapping, bis zum ersten MVP für Problem-Solution-Fit und dann Impact Mapping, um das weitere Wachstum zu finanzieren. Oder verschieden Canvases wie Vision Board oder Product Board für die einzelnen Phasen verwenden, wie dies Pichler vorschlägt.

Auch Spotify hat einen Ansatz entwickelt, der den Lean Startup Ansatz mit dem Agilen Ansatz verbindet:
“Think It”, “Build It”, “Ship It”, “Tweak It”
https://dl.dropboxusercontent.com/u/1018963/Articles/HowSpotifyBuildsPro...

Ok, wie hilft mir das alles als Agile Coach:

- die Metapher des sozialen, adaptiven System hilf, interessant Fragen zu stellen, z.B.

* Was ist das primäre Ziel des Systems (und was sekundäre Ziele)?
Selbsterhaltung ("to stay in business"), Kundenzufriedenheit, Qualität, Time to Market, Mitarbeiterzufriedenheit oder ROIs (wirtschaftlicher Erfolg)?
* Welche Faktoren (Constraints) begrenzen das Wachstum des Systems, wie mehr zufriedene Kunden, besserer ROI, höhere Qualität und mehr zufriedene Mitarbeiter?
Interessanterweise wirkt sich der Happiness Faktor - MA Zufriedenheit - positiv auf alle anderen Faktoren aus! Aber ist dieser Faktor auch der begrenzende Faktor, der Constraint. Zumindest hängt er eng mit der Knappheit guten Personals, Bindung vorhandenen Personals und Neubeschaffung von qualifizierten Personal zusammen!
* Was ist das einfachste System, dass den primären Zweck der Organisation erfüllen kann?
Einfachheit ist wichtig für den Umgang mit Komplexität aber auch Innovation
* Was sind unbeabsichtigte Nebenwirkungen einer Lösung, die das Problem langfristig verstärken könnten?
Darüber hab ich hier noch gar nichts gesagt, wie zum Beispiel System Archetypen wie "Lösungen die fehlschlagen" (quick fixes), "Policy Resistance" (Widerstand von Betroffenen, die nicht beteiligt wurden), "Driftende Ziele" (bei nicht machbaren oder messbaren Zielen) etc...
Vielleicht ein Thema, für einen weiteren Blogeintrag.

- die Metapher des Systems hilft unterschiedlich agile Ansätze und Methoden miteinander zu vergleichen
Lean Startup, Lean Product Development, Design Thinking, Scrum, XP, LeSS und SAFe wären da die aus meiner Sicht interessantesten Kandidaten.

- die Metapher hilft des Systems hilft beim Verständnis ganz grundsätzlichen Begriffe, wie der Funktion von Teil und Ganzem, Interaktion der Teile, Selbstorganisation und Emergenz, Feedback etc.
Durch diese Begriffe bekommt man einen anderen Blick auf die Realität, weg von unproduktiven Gesprächen über lineare Ursache-Wirkung Beziehungen und Schuld zu solchen über größere Zusammenhänge und Entwicklungen.