Ein alternatives Team-Framework nach lean-agile Prinzipien: Flock
Wie könnte ein modernes agiles Team-Framework aussehen, das die neuen Erkenntnisse und Strömungen aus der agilen Entwicklung und der Lean-Bewegung in praktische Arbeit umsetzt? Flock ist unser Vorschlag für ein Meta-Framework, das Wertschöpfung als grundlegenden Kompass nutzt.
"Flock" kommt aus dem Englischen und bedeutet Schwarm oder Herde. Das Verb "to flock" bedeutet "zusammenströmen". Es steht für den zentralen Teil der Arbeitsweise des Frameworks: Teile eines Entwicklungsteams gruppieren sich um bestimmte Themen, entwickeln Ideen, kommen wieder zusammen und strömen wieder aus, um andere Ideen weiterzuentwickeln. Wir erläutern später detailliert, wie in Flock praktisch gearbeitet wird.
Das Framework adressiert Aspekte, die durch andere, zu ihrer Entstehungszeit durchaus innovative, Frameworks nicht explizit fokussiert werden: Die gezielte Ausnutzung der Eigenschaften von Varianz und die Orientierung an realer Wertschöpfung. Der erste Aspekt zielt auf die Frage: Wann braucht der Produktentwicklungsprozess maximale Varianz, um Raum für neue Ideen zu geben und Innovation zu ermöglichen, wann minimale Varianz, um dadurch die Wertschöpfung zu maximieren? Unter Varianz verstehen wir dabei das Ausmaß der Abweichung vom Standardprozess. Das bedeutet, dass wir über die rein mathematische Definition hinausgehen.
Der zweite Aspekt stellt die Frage nach dem Wert in den Mittelpunkt. Anstatt die subjektiven Einschätzungen beteiligter Produktverantwortlicher als Wertmaßstab zu nehmen, werden Hypothesen aufgestellt und Metriken definiert, um diese Hypothesen zu prüfen. Die Lean Start-Up-Bewegung entwickelt solche Metriken gerade in großer Vielfalt.
Die Sache mit der Varianz
"Variability is the constant travel companion of innovation" (Don Reinertsen, [1])
Zu Beginn der Lean-Bewegung in der Automobilindustrie wurde Varianz häufig als "Waste" (Verschwendung) verstanden. Das ist verständlich, denn in einer Produktionshalle führen Abweichungen vom festgelegten Standard sehr schnell zur Verschwendung von Ressourcen und damit zu weniger Wertschöpfung. Die naheliegende Schlussfolgerung, dass die Wertschöpfung immer dann am höchsten ist, wenn die Varianz in allen Produktionsprozessen minimal ist, lässt sich daraus aber nicht so einfach ableiten. Varianz hat zwei Seiten: Ohne Abweichungen gibt es keine Innovation. Oder andersherum: Überall, wo neue Ideen entstehen, ist Varianz im Spiel. Wenn immer genau das Gleiche passiert, keine Veränderungen geduldet und keine Experimente gemacht werden dürfen, entstehen auch keine neuen Erkenntnisse.
Spätestens die Lean Startup-Bewegung, die die Steuerung der Weiterentwicklung durch schnelle Rückmeldung auf der Grundlage gezielter Experimente propagiert, zeigt das eindrucksvoll. Ob Varianz positiv oder negativ für die Wertschöpfung ist, hängt deshalb vor allem davon ab, wann sie innerhalb eines Prozesses auftritt. Es ist nicht hilfreich, sie zu früh einzuschränken, weil viele Ideen und Optionen dabei verloren gehen. Es ist aber auch nicht hilfreich, zu lange eine sehr große Varianz aufrechtzuerhalten. Irgendwann müssen Entscheidungen getroffen werden, wie eine bestimmte Lösung auszusehen hat. Diese gelten dann, bis eine neue Lösung erforderlich wird.
Es braucht deshalb strukturierte Vorgehensweisen, die die positiven Effekte von Varianz abschöpfen und die negativen Effekte auffangen. Die Frage, die dazu geklärt werden muss, ist: Wann vergrößert Varianz den ökonomischen Wert, wann verringert sie ihn? Flock zielt auf die Beantwortung dieser Frage im agilen Entwicklungsprozess: Wie lange sollte man im Produktionsprozess eine möglichst große Varianz aufrechterhalten, um Innovation zu ermöglichen und ab welchem Zeitpunkt umschalten auf minimale Varianz, um ein passgenaues Ergebnis zu erhalten – beides mit dem Ziel maximaler Wertschöpfung?
Blick in den Arbeitsalltag eines Flock-Teams
Bevor wir zu den Hintergründen des Frameworks kommen, ist es vielleicht am einfachsten, einen Blick auf ein mit Flock arbeitendes Team zu werfen. Nennen wir das Team "Spirit" und gehen wir für einen leichteren Einstieg davon aus, dass die neun Mitglieder des Teams gemeinsam in einem Teamraum sitzen und lassen zu diesem Zeitpunkt alle Skalierungs- und sonstige Komplexitätsfaktoren beiseite, um am einfachsten Fall die Grundidee zu erläutern.
Erste Phase: Konzeption
Es ist Montagmorgen und das Team "Spirit" trifft sich im Teamraum. Für das Feature, dass Anfang letzter Woche live geschaltet wurde, war festgelegt worden, dass es als Erfolg gelten würde, wenn es innerhalb von vier Wochen 5000 Klicks erhalten würde. Die Messungen haben ergeben, dass bereits am ersten Wochenende 5900 Klicks erzeugt wurden. Damit ist das Erfolgskriterium erreicht und das Feature hat sich weit früher als vermutet als erfolgreich herausgestellt. Nun setzt sich das Team zusammen und diskutiert, welches die nächsten Schritte sein könnten. Das Ziel ist, eine gemeinsame Ausrichtung (Alignment) im Team darüber zu erreichen, in welche Richtung man weitergehen möchte. Ein Teammitglied schlägt ein Add-on vor, andere haben unterschiedliche Ideen zu Erweiterungen und es wird solange diskutiert, bis man sich im Team gemeinsam auf eine Idee für ein neues Feature geeinigt hat, das man als nächstes angehen möchte. Unser Team benutzt unterschiedliche Moderations- und Priorisierungsmethoden, heute arbeiten sie mit Story Mapping und innerhalb von knapp 2 Stunden haben sie sich auf den nächsten möglichen Schritt geeinigt.
Jede Idee in der Softwareentwicklung tangiert verschiedene Wissensbereiche (Knowledge Areas) wie beispielsweise Funktionalität, UX, Architektur, Infosecurity, Telemetrie, Infrastruktur, Testen oder Erfolgsmessungen. Nun betritt die neue Idee des Teams die Bühne und jeder der Wissensbereiche stellt eine Art Scheinwerfer dar, der einen anderen Blick auf die Idee ermöglicht und andere Aspekte zu Tage fördert, die man später in der Entwicklung berücksichtigen sollte. Deswegen ist es sinnvoll, jeden Bereich separat zu beleuchten. Das geschieht nun in Untergruppen: Team Spirit teilt sich in kleinere Sub-Teams auf, um jeweils einen dieser Wissensbereiche im Hinblick auf die Idee zu diskutieren. Dazu legen sie sich selbst eine Timebox fest, zu der sie sich alle wieder in der großen Gruppe treffen. Im konkreten Fall vereinbaren sie eine Timebox von 90 Minuten. Drei Teammitglieder machen nun eine Architektur-Session, drei andere diskutieren gemeinsam die Funktionalität der neuen Idee und die restlichen drei sprechen über das Testen. Wie genau die Ideen und Aspekte bearbeitet und dokumentiert werden, ist in der Verantwortung jedes Sub-Teams. Flock als Meta-Framework gibt nur das "WAS", nicht das "WIE" vor.
Es ist nichts beschlossen, bevor nicht alles beschlossen ist.
Nach Ablauf der Timebox kommt das ganze Team wieder zusammen (es "flockt") und bespricht die Ergebnisse. Im Anschluss daran teilt sich das Team in anders besetzte Sub-Teams auf, um weitere Wissensbereiche zu diskutieren bzw. bestehende zu ergänzen. Zwei der Entwickler, die in der Testen-Session waren, finden, dass die Ergebnisse der Architektur-Session wichtige Aspekte außer Acht lassen und beschließen, eine weitere Architektur-Session zu machen. Vier andere möchten sich gerne mit den notwendigen Metriken auseinandersetzen und die verbleibenden drei Teammitglieder aus dem bisherigen Sub-Team Funktionalität möchten die aus ihrer Sicht in der letzten Session nicht erschöpfend diskutierten Aspekte der Funktionalität weiter besprechen. Wieder wird eine Timebox vereinbart, nach deren Ablauf man sich erneut im gesamten Team trifft und die Ergebnisse bespricht. Dies geschieht so oft, bis alle aus Teamsicht relevanten Wissensbereiche erschöpfend diskutiert und geklärt sind. Das ist einer der Grundsätze von Flock: Es ist nichts beschlossen, bevor nicht alles beschlossen ist. Es gilt die maximale Varianz, bevor auf minimale Varianz umgeschaltet wird.
Zweite Phase: Ausführung
Irgendwann ist aus Teamsicht nichts mehr zur Idee hinzuzufügen. Alle Aspekte sind besprochen und ausdiskutiert und daraus in den Sessions ein detaillierter Plan entstanden, beispielsweise mit welchen Pattern die Architektur oder wie das automatisierte Testing umgesetzt werden soll. Dieser Plan liegt nun für alle relevanten Aspekte der Idee vor. Damit ist die Phase der maximalen Varianz abgeschlossen. Das Team trifft die Entscheidung zur Umsetzung (= schaltet auf minimale Varianz um) und legt los. Damit hat das Team einen Plan, und setzt nun in Mob-Programming alles gemeinsam um. Das heißt konkret in der Praxis: Das Team teilt sich wieder in Sub-Gruppen auf und programmiert in diesen gemeinsam jeweils Aspekte der Idee, z. B. den Produktiv-Code oder die Unit-Tests, kommt für Integrationssessions zusammen ("flockt"), trennt sich wieder in Sub-Teams etc. Dies geschieht so lange, bis die Idee umgesetzt ist und live geschaltet wird.
Dritte Phase: Warten
Nun greifen die zuvor festgesetzten Metriken zur Erfolgsmessung und bis diese Kriterien erreicht sind, entsteht eine Wartephase. Das ist trotz aller wissenschaftlicher Nachweise zum Thema Auslastung immer noch eine der härtesten Nüsse: Die Abkehr von der Denkweise, dass hohe Auslastung mit hoher Wertschöpfung gleichzusetzen ist. Um schnell auf die Ergebnisse, also die konkrete Rückmeldung des Marktes reagieren zu können und damit maximale Wertschöpfung zu erreichen, darf das Team nur zu max. 60 Prozent mit Funktionalität ausgelastet sein. Es kann kaum größere Wertschöpfung geben, als die Arbeit, die auf konkrete Rückmeldung des Marktes oder der Community reagiert. Deswegen wird die Wartezeit bis zur Rückmeldung mit Tätigkeiten gefüllt, die problemlos unterbrochen werden können, wenn das Feedback da ist. Das kann beispielsweise das Refinement der nächsten Idee sein oder die Verbesserung der Infrastruktur.
Auch das ist eine der grundsätzlichen Ideen von Flock: Produktentwicklung und Organisationsentwicklung kannibalisieren sich nicht länger, sondern sind beide wichtig und bekommen ihren festen Platz, wenn auch mit leichtem Schwerpunkt auf Produktentwicklung. Dieses Vorgehen klingt zwar in der aktuell vorherrschenden Denkweise fast abenteuerlich, hat jedoch einen klaren wirtschaftlichen Hintergrund: Wird das Team zu mehr als 60 Prozent mit Funktionalität ausgelastet, setzt man statt auf maximale Wertschöpfung auf maximale Auslastung. Das gibt zwar möglicherweise den Verantwortlichen ein gutes Gefühl, ist aber in ökonomischem Sinne kontraproduktiv, weil keine Kapazität zur Verfügung steht, um schnell auf die Rückmeldungen zur geleisteten Arbeit zu reagieren. Obwohl dies eine Jahrzehnte alte Erkenntnis ist und auch mathematisch eindeutig nachzuweisen, halten sehr viele Menschen intuitiv am Gegenteil fest [2].
Alles schon mal dagewesen? Was ist das Neue an Flock?
Die konsequente Ausrichtung an realer Wertschöpfung (anstatt an gefühlten Wahrheiten)
Anstatt sich allein auf die Ideen und das Bauchgefühl von Produktverantwortlichen zu verlassen, wird in kleinen Einheiten entwickelt und direkt am Markt oder einem Proxi getestet. Dieses Vorgehen erfordert den Aufbau der Fähigkeit, die richtige Community für eine schnelle Rückmeldung und die richtigen Erfolgskriterien zu finden und passende Metriken zu entwickeln und zu nutzen, besonders da sich nicht bei jedem Feature sofort diese Feedbackschleifen erschließen.
Die gezielte Ausnutzung der bipolaren Wirkung von Varianz
Wenn man maximale und minimale Varianz sauber trennt und die Losgröße (Batchsize) klein genug hält, gibt es keinen Grund, in der Softwareentwicklung nicht analog zum Bauplan eines Hauses oder zu Fertigungsplänen in Fabriken vorzugehen.
Vereinbarung von Produktentwicklung und Organisationsentwicklung als zwei wichtige Bereiche mit festen Plätzen im Entwicklungszyklus
Die Nutzung von notwendigen Wartezeiten aufgrund einer konsequenten Ausrichtung an maximaler Wertschöpfung (anstelle maximaler Auslastung) gibt regelmäßiger Organisationsentwicklung einen festen Platz und gewährleistet gleichzeitig sofortige Reaktionsmöglichkeit bei Eintreffen der Metriken zu den festgelegten Erfolgskriterien der Features. Dieser feste Platz sorgt für eine kontinuierliche und nachhaltige Weiterentwicklung und Verbesserung der Prozesse und des Fachwissens. Organisationsentwicklung wird dann elementarer Teil des Arbeitsprozesses und ist nicht das Füllmaterial, wenn mal Zeit bleibt (was in der Regel selten der Fall ist).
Positionen statt Rollen
Es gibt keinen Product Owner mehr, der dem Team ein priorisiertes Backlog vorsetzt, aus dem je nach definierten Reifegradkriterien (der "Definition of Ready") ein mehr oder weniger ausgearbeitetes Feature ins Team-Backlog gezogen wird (nicht vergessen: Wir gehen hier vom einfachsten Fall auf Teamebene aus und erläutern noch nicht die Optionen einer Skalierung). Die Teammitglieder arbeiten auf verschiedenen Positionen und setzen die alte, oft geforderte Idee der Crossfunktionalität tatsächlich in die Praxis um.
Um zu verstehen, warum Positionen statt festgelegter Rollen sinnvoll sind, lohnt es sich, einen Blick in die Entwicklung des Fußballs zu werfen, der sich auf einem ganz anderen Gebiet des Teamspiels mehr und mehr von alten Rollen trennt und sich hin zu modernem Positionsspiel bewegt.
Was erfolgreiche Produktentwicklung von Fußball lernen kann
Im modernen Fußball wird mit der Weiterentwicklung des Positionsspiels die Mannschaft zu einem crossfunktionalen Team: Es gibt keine festen Rollen mehr, wie beispielsweise Libero, Mittelstürmer oder Rechtsaußen. Das Spielfeld wird in Zonen aufgeteilt und durch die gesamte Mannschaft sichergestellt, dass je nach Ballposition und Spielsituation die definierten Zonen des Spielfeldes besetzt sind und die dazugehörigen Aufgaben wahrgenommen werden. Dabei ist unerheblich, welcher Spieler eine "Position" bzw. die Zone besetzt. Dadurch kann sehr variabel und für den Gegner schwer vorhersehbar auf die entsprechende Situation reagiert werden. Und da auch die Zonen keine fixen Bereiche auf dem Platz sind, sondern Gebiete, die durch die Ballposition definiert werden und an die jeweiligen Situationen und die Aufgaben angepasst sind, ist ein für den Gegner sehr schwer vorhersagbares variantenreiches Spiel möglich.
Diese Art zu spielen stellt hohe Anforderungen an die ganze Mannschaft, denn jeder Einzelne muss immer die ganze Spielsituation im Blick haben, um sich adäquat auf dem Platz bewegen zu können. Wenn Spieler nicht wissen, wann sie die Positionen verlassen sollen oder wenn sie sich die Aufgaben auf der anderen Position nicht zutrauen, kommt der Aufbau ins Wanken. Jeder einzelne Spieler trägt die Verantwortung für das ganze Team. Das Positionsspiel erhöht die körperliche und kognitive Leistungsfähigkeit der Spieler und führt zum Kompetenzaufbau in technischem Können, der Situationsbewertung, der Beweglichkeit und dem Umgang mit Zeit- und Gegnerdruck [3,4].
Modernes Positionsspiel in der Produktentwicklung
Unter Crossfunktionalität versteht man, dass in einem Team alle Fähigkeiten, die es braucht, um ein Feature in sich geschlossen zu entwickeln und fertigzustellen, gebündelt sind. Das bedeutet möglichst wenig Abhängigkeit nach außen, entspricht aber im Prinzip der alten Rollenverteilung im klassischen Fußball. Jeder hat sein Spezialgebiet und seine Aufgabe auf dem Platz. Gerade in der Crossfunktionalität wird von einem "T-Shaped-Skill-Set" ausgegangen. Das bedeutet, jedes Teammitglied hat seinen Spezialbereich, gleichzeitig aber ein möglichst breites Basiswissen, um auch andere Aufgaben übernehmen zu können [5].
Wissenstransfer ist zwar zeitaufwändig, aber ökonomisch sinnvoll, weil mit stärker verteiltem Wissen viele Teammitglieder in der Lage sind, die Anforderungen zu bearbeiten. Obwohl Techniken wie Paring oder Mob-Programming bereitstehen, scheuen viele Teams diesen Aufwand bzw. es wird in Projekten durch die sehr hohe Auslastung der Teams kein Raum für die Erschließung des Potentials der Crossfunktionalität gegeben. Um im Fußballbeispiel zu bleiben: "Warum sollte ich meinen Rechtsaußen etwas Anderes trainieren lassen? Dafür habe ich doch andere Spieler." Das war die Philosophie von "Football Total" in den 80er Jahren, wie sie vor allem in den Niederlanden praktiziert wurde [6]. Aber diese Spielphilosophie birgt Risiken: Wer mit einem Haufen Spezialisten auf dem Platz aufläuft, sollte für ausreichend Ersatz pro Position sorgen oder darf sich nicht wundern, wenn bei einer Verletzung das Spielkonzept aus dem Ruder läuft. Oder wenn man gegen einen Gegner, der modernes Positionsspiel beherrscht, auf dem Platz plötzlich alt aussieht...
Das Spielfeld der Produktentwicklung
Mit der crossfunktionalen und von der Spielsituation abhängigen Rollenverteilung alleine ist es im modernen Positionsfußball jedoch nicht getan. Genauso wichtig ist, die verschiedenen Zonen eines Spielfeldes zu verstehen und zu erkennen, in welcher Zone man sich gerade befindet und welche Spielzüge dann erforderlich sind.
Die verschiedenen Arbeitsbereiche rund um ein Feature lassen sich wie Zonen des Spielfeldes beim Positionsspiel des Fußballs verstehen. Annähernd jede End-to-end-Funktionalität weist ähnliche typische Bereiche auf, die vom Team bespielt werden müssen. Die Teams machen ein Positionsspiel mit Wissenbereichen (Knowledge Areas). Typische Wissensbereiche bei der Entwicklung eines End-to-End-Features sind
- Funktionalität
- UX (Wie stelle ich das Feature dar?)
- Architektur
- Infosecurity (Habe ich Daten, die ich beachten muss und wie werden die Daten gesichert?)
- Telemetrie (In den Code Funktionalität einbauen, die mir im laufenden Betrieb Rückmeldung über den Gesundheitszustand der Funktionalität gibt)
- Infrastruktur
- Test (Testing-Konzept und ggf. dafür notwendige Infrastruktur)
- Value Measures (Wie will ich den Wert des Features messen? Wann ist die implementierte Funktionalität erfolgreich?)
Die Liste ist nicht erschöpfend. Über all diese Bereiche muss sich ein Team bei der Produktentwicklung Gedanken machen. Positionsspiel erfolgreich zu betreiben bedeutet die konsequente Umsetzung der Crossfunktionalität. Jeder Spieler ist immer für die gesamte Spielsituation mitverantwortlich. Wer sich früher als reiner Stürmer verstanden hat und die Verteidigung als "not my business" ansah, übernimmt im modernen Fußball je nach Spielsituation und Ballposition beispielsweise auch die Verteidigerrolle. Und wer sich als Innenverteidiger definierte, findet sich in einer Zone, die ihm einen Torschuss ermöglicht und ergreift die Chance. Wir erinnern uns: "Das Positionsspiel erhöht die körperliche und kognitive Leistungsfähigkeit der Spieler und führt zum Kompetenzaufbau in technischem Können, der Situationsbewertung, der Beweglichkeit...". Das gilt genauso auch für ein crossfunktionales Entwicklerteam. Es führt dazu, dass die Kreativität und Innovationsfähigkeit des Teams gestärkt wird und Ideen und Lösungsansätze generiert werden können, die jenseits der eingetretenen Pfade liegen. Innovation braucht Varianz.
Und genau diese Art der Entwicklung braucht eine neue Art von Team-Framework, die Positionsspiel ermöglicht, Varianz nutzt und sich konsequent an der Wertschöpfung ausrichtet. Flock ist dabei ein Meta-Framework, das keine konkreten Methoden vorschreibt, sondern die Grundlagen des Spiels bereitstellt.
Varianz in Scrum
Das derzeit meistgenutzte agile Team-Framework ist Scrum, dass bereits in den 90er Jahren entstanden ist. Der Scrum-Guide, der von Ken Schwaber und Jeff Sutherland weiterentwickelt wird, legt dabei dezidiert die Regeln fest, was Scrum ist und was nicht. Das gilt vor allem für Events, Rollen und Artefakte.
In Scrum wird sowohl das Produkt als auch die Planung (Product Backlog) iterativ und inkrementell weiterentwickelt. Für eine definierte Zeiteinheit (Sprint) wird ein Detailplan (Sprint Backlog) erstellt und innerhalb dieses Zeitrahmens eine Produktfunktionalität (Inkrement) entwickelt. Für die Backlog Items hat das Entwicklungsteam zuvor Fertigstellungskriterien (die "Definition of Done") festgelegt. In dem Moment, wo ein Item vom Product Backlog in ein Sprint Backlog gezogen wird, geht es von der Hoheit des Product Owners in die Hoheit des Development-Teams über und wird von diesem innerhalb des Sprints bearbeitet bzw. fertiggestellt.
Wie geht Scrum mit Varianz um?
Wir erinnern uns: Nicht im gesamten Entwicklungsprozess ist hohe Varianz zielführend. Um den Effekt von Varianz optimal ausnutzen zu können, braucht es auch eine klare Definition, wann die innovative Phase großer Varianz, in der alle Ideen, Aspekte und Lösungsvorschläge zusammengetragen werden, endet und die Phase minimaler Varianz, in der der Weg klar definiert ist und jeder weiß, was er zur Zielerreichung wie zu tun hat, beginnt.
Scrum arbeitet nicht gezielt mit den Effekten der Varianz und behandelt sie nur implizit, zum Beispiel im Umfang des Sprints, für den durch das festgelegte Sprintziel nach Sprintstart keine Varianz mehr von außen zugelassen wird. Allerdings ist dabei nicht explizit festgelegt, welchen Reifegrad die Items für die Einplanung haben müssen. Gängige Praxis ist daher eine "Definition of Ready", die Aussagen darüber zulässt, ob ein Item im Product Backlog soweit ausgearbeitet (refined) ist, das es in den Sprint geladen werden kann, aber diese Definition of Ready ist kein Teil des Scrum-Guides [7].
Man könnte demnach bei Scrum Varianz im Refinement-Prozess vermuten, denn es wird empfohlen, 10 Prozent der Sprintzeit für das Refinement der Product Backlog Items aufzuwenden. Das wären 8 Stunden in einem zweiwöchigen Sprint, also immerhin ein ganzer Arbeitstag. Dieses Refinement bezieht sich aber nur auf das Product Backlog und fokussiert vor allem die Items für die kommenden Sprints.
Doch es bedarf auch eines weiteren Refinements der Items, die in den laufenden Sprint geladen wurden und in die Hoheit des Teams übergegangen sind. Meistens sind die Items nicht so klar definiert, dass keine Varianz mehr enthalten und keine weitere Abstimmung mehr notwendig wäre, auch wenn laut Scrum-Guide die Entscheidung, wie die ausgewählte Arbeit erledigt werden wird, am Ende des Sprint Plannings getroffen sein sollte. Das wäre theoretisch ein klarer Umschaltpunkt von hoher Varianz im Refinement-Prozess zu niedriger Varianz in der Abarbeitung im Sprint. Das wird aber im Scrum-Guide nicht ausdrücklich gefordert und in vielen Implementierungen nicht gemacht.
Die Ursache dafür liegt in der Komplexität und gegenseitigen Abhängigkeit der Bereiche, die annähernd jede End-to-end-Funktionalität tangieren wie z. B. Architektur, UX, Test und Value Measurement. Eine Entscheidung, die im Laufe des Sprints in einem dieser Bereiche notwendig wird, hat Auswirkungen auf viele andere Bereiche, wie in einem Mobile, in dem nur ein Ast angestoßen wird und alle anderen Äste mitschwingen und ihre Position verändern. Das bedeutet, dass mit dem Sprint Planning als klar definiertem Übergabepunkt zwar theoretisch festgelegt sein sollte, welche Inhalte im Sprint mit welchen Fertigstellungskriterien wie entwickelt werden, aber danach aufgrund der Komplexität in der Praxis noch Fachlichkeit gerade gezogen werden muss.
Die Innovationskraft kommt erst zur Entfaltung, wenn sie gezielt als Ideenpool wahrgenommen wird.
Bei einem festen Sprintziel bieten sich zu diesem Zeitpunkt jedoch keine großen Freiheitsgrade mehr, um die positiven innovativen Effekte von hoher Varianz auszukosten. Es existiert aber auch keine ausreichende Stabilität, um die positiven Effekte von niedriger Varianz zu nutzen (schnelles Abarbeiten), denn dazu bräuchte es einen festen Plan, den Scrum in der notwendigen Form nicht bietet und der aufgrund der hohen Komplexität in der Softwareentwicklung auch immer nur für eine sehr kleine Losgröße existieren kann.
Scrum klärt den kritischen Übergangspunkt zwischen großer und kleiner Varianz gar nicht und lässt damit ihr Potential ungenutzt. Das ist auch nachvollziehbar: Es wurde zu einem Zeitpunkt entwickelt, als diese Forschungsbereiche noch in den Kinderschuhen steckten. Die Innovationskraft großer Varianz kommt erst dann zur Entfaltung, wenn man sie gezielt als Ideenpool oder im Sinne von Lean Startup als Experiment wahrnimmt. Einfach nur unklare Verhältnisse als innovative Varianz zu betrachten, führt in der Regel nicht zu größerer Wertschöpfung, weil die Lerneffekte nicht gezielt ausgewertet und genutzt werden. Auf der anderen Seite wird die Arbeitsgeschwindigkeit beim Umschalten auf minimale Varianz auch nicht erreicht, denn dazu müssten die Parameter, unter denen "ab jetzt" bis zum Sprintziel entwickelt wird, so detailliert klar sein, wie die Abläufe beim Bestücken einer Platine oder bei der Produktion in einer Fabrikhalle.
Fazit
Flock ist ein Meta-Team-Framework, das keine konkreten Methoden vorgibt, sondern nur den Weg aufzeigt, um aufgrund neuer Erkenntnisse und Entwicklungen die agile Arbeitsweise weiterzuentwickeln oder einen Denkanstoß zu geben, die zu ihrer Zeit innovativen Ideen der agilen Softwareentwicklung mit Frameworks wie Scrum in neue Bahnen zu lenken.
Wir haben hier versucht, den Raum für diese Gedanken zu öffnen und anhand eines sehr einfachen Falles erläutert, wie Flock auf Teamebene funktioniert und auf welchen Grundprinzipien es basiert. Uns ist klar, dass wir viele Fragen hier unbeantwortet lassen mussten und viele "Aber" hervorrufen werden und freuen uns auf die Diskussion, denn auch in der Meinungsvielfalt gilt "Variability is the constant travel companion of innovation".
- D. Reinertsen (2009): Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing
- #163 – Die Warteschlangenformel am Beispiel einer Serviceabteilung
- Positionsspiel
- T. Escher (2016):Vom Libero zur Doppelsechs: Eine Taktikgeschichte des deutschen Fußballs, Rowohlt Taschenbuch Verlag
- J. Schmidt: Crossfunktionale Teams – aktiver Wissenstransfer im Team
- Wikipedia: Totaler Fußball
- K. Schwaber, J. Sutherland: Scrum-Guides
Kommentare (0)