Umsetzung

Das Refit Agile Blueprint lehnt sich an die agilen Methoden APM [1] (Agiles Projektmanagement) und FDD [2] (Feature Driven Development) an, indem es sich an einigen zentralen Planungskonzepten aus diesen Methoden bedient, ohne die jeweiligen Regelwerke komplett zu übernehmen. Ebenso werden von Scrum einige Begriffe zu den Aktivitäten verwendet, die sich in der Branche etabliert haben. Im nächsten Abschnitt wird konkret auf einige Aspekte des Scrum-Guides eingegangen, in denen sich Refit Agile von Scrum unterscheidet, da es derzeit eine der bekanntesten agilen Methoden ist.

Die Bezeichnung Refit leitet sich ab aus der Bedeutung einer Übersetzung des Wortes mit "Nachrüsten" der agilen Vorgehensweisen mit wertvollen Anteilen der klassischen Verfahren, die für Softwareprojekte mit einer längeren Lebensdauer besser geeignet sind. Diese Voraussetzung teilt das Refit Agile Blueprint grundsätzlich mit den agilen Methoden APM und FDD, welche auch auf einige Vorteile der klassischen methodischen Softwareplanung nicht komplett verzichten wollen. Der Rückbezug zu den klassischen Methoden bezieht sich bei APM eher auf die Erhaltung der Projektschritte des Requirements Engineering und einer über den gesamten Lebenszyklus durchgängigen Softwarearchitektur, während bei FDD eine starke Orientierung an einem Phasenmodell erkennbar ist. 

Im Vorwort eines Buches zu APM wird eine kurze Antwort zur Einordnung dieser agilen Entwicklungsmethode in die übrige Welt der agilen Vorgehensweisen gegeben:

“Wenn Sie Scrum machen können, machen Sie Scrum! Wenn Ihnen Scrum als agiles Framework zu umfangreich erscheint, setzen Sie Kanban ein! Wenn Sie jedoch aus unterschiedlichen Gründen mehr brauchen als Scrum, dann ist APM die richtige Methode für Sie!”

Diese Antwort wäre ebenso für Refit Agile (und FDD) angemessen, wobei Refit Agile im Wesentlichen eine leichtgewichtige Anpassung von APM darstellt, die "Lösungswege ermöglicht, die in der Praxis funktionieren", wie es im Vorwort des APM-Guides sinngemäß heißt.

Schließlich wird im APM-Guide unter dem Kapitel "Was ist APM?" eine Beschreibung der fünf Säulen gegeben, auf denen APM basiert und die eine Auswahl von Best Practices aus unterschiedlichen methodischen Vorgehensweisen darstellen. Von diesen seien hier jene zitiert, auf die sich das Refit Agile Blueprint ganz wesentlich fokussiert und die hier ebenso (leicht eingeschränkte) Geltung besitzen:

"APM beinhaltet ein inkrementelles Vorgehen. In einer Iteration erarbeiten wir ein prüfbares Ergebnis von direktem Nutzen für den Kunden bzw. die Anwender, also ein Stück funktionierender Software. Das Ergebnis eines Projekts wird schrittweise erarbeitet. Ein Zwischenergebnis bezeichnen wir als Inkrement. Die Inkremente bauen aufeinander auf, sodass wir uns mit jedem weiteren Inkrement dem Projektergebnis konkret nähern. Damit ein inkrementell-iteratives Vorgehen funktioniert, strukturieren wir unser angestrebtes Projektergebnis derart, dass wir ausreichend kleine, sinnvolle Teilstücke als Inkremente innerhalb einer Iteration umsetzen können." 

"APM ist ein architekturzentriertes Vorgehen. Die Arbeit an der Softwarearchitektur findet kontinuierlich statt, wobei regelmäßig im Projektverlauf grundlegende Architekturfragen im Vordergrund stehen."

Als Ergänzung könnte man für Refit Agile eine weitere Säule nennen, die in Korrespondenz zu dem letztgenannten Aspekt den Fokus nicht nur auf eine durchgängig gepflegte Architekturdokumentation legt, sondern ebenso auf eine konsequent strukturierte Definition aller Nutzerinteraktionen. Also beides ganz im Sinne eines klassischen Pflichtenheftes, an dem selbstredend eine kontinuierliche Überarbeitung stattfindet.   

Um sowohl die kontinuierliche Arbeit an der Softwarearchitektur wie auch an der Definition der Nutzerinteraktionen arbeitsteilig auf einem hohen Niveau zu organisieren, misst Refit Agile einer effektiven Dokumentation im Sinne von Spezifikation und Entwurf wieder einen angemessenen Stellenwert zu, den sie im klassischen Wasserfallmodell immer schon hatte. Dort sind die Ergebnisse der Anforderungsanalyse einmalig in den Projektschritt zur Definition des Fachkonzeptes eingeflossen, dessen Ergebnisse wiederum im folgenden Projektschritt zum Entwurf des Systemdesigns verwendet wurden. Da es im Wasserfallmodell keine zyklischen Iterationen gibt, macht eine Unterscheidung in Problemraum und Lösungsraum keinen Sinn, denn es gibt dort ein einmalig erstelltes Lösungskonzept, welches beide Aspekte vereint.

Im agilen Kontext macht diese Unterscheidung aber sehr wohl Sinn, da es über viele Iterationen hinweg immer wieder neue Lösungskonzepte gibt, die sich in das bisher entwickelte Gesamtsystem möglichst nahtlos integrieren müssen, wenn es nicht zu technischen Schulden kommen soll. Wenn man neue Anforderungen in der aktuellen Iteration schon im Problemraum mit den bisher erfolgten Spezifikationen abstimmen kann und ein entsprechendes Lösungskonzept mit dem bisherigen Systementwurf im Lösungsraum integrieren kann, werden genau die Probleme im  Verlauf der Implementierung vermieden, die durch eine ungenügende Betrachtung der bisher dokumentierten Spezifikation auftreten können.

Eine Sichtweise der agilen Entwicklung, die dem von Refit Agile verfolgten Ansatz in hohem Maße entspricht, wurde bei Heise in dem iX-Artikel "Spezifikation im agilen Kontext" [3] veröffentlicht. Die Begrifflichkeiten dort stimmen nicht immer mit denen des Refit Agile Blueprints überein. Aber es gibt eine Übereinstimmung in der einleitenden Betonung der wesentlichen Rolle von Spezifikationen bei der Softwareentwicklung:

"Bei der agilen Softwareentwicklung besteht das oberste Ziel darin, funktionierende Software zu erstellen. Spezifikation steht dabei bisweilen zur Diskussion, da man sie oft mit einem umfangreichen und detaillierten Spezifikationsdokument assoziiert. Dennoch ist sie unabhängig vom gewählten Vorgehen für professionelle Softwareentwicklung unverzichtbar. Dieser Artikel zeigt, wie man Spezifikation in den Rahmen agiler Softwareentwicklung so einpassen kann, dass sie zu den Zielen des agilen Vorgehens beiträgt."

"Spezifikation steht im Wesentlichen für zwei Dinge: die Aktivität des Spezifizierens und die Spezifikationsartefakte, die dabei als Ergebnis entstehen (...). Ziel des Spezifizierens ist es, zu Anforderungen an ein Softwaresystem ein valides fachliches Lösungskonzept zu finden und darzustellen."

"Das Lösungskonzept ist dabei ein gedankliches Modell, das erst durch eine geeignete Darstellung für andere Personen sichtbar wird. Die vier Schritte des Spezifizierens beeinflussen sich gegenseitig. Man durchläuft sie mehrfach und in wechselnder Reihenfolge, bis zu einem Satz an Anforderungen ein valides Lösungskonzept vorliegt und für die Beteiligten zufriedenstellend dargestellt ist."

Zum aktuellen Zeitpunkt gibt es bei den Begrifflichkeiten im obigen Artikel den wesentlichen Unterschied zum Refit Agile Blueprint, daß im Artikel mit "Spezifikation" die Tätigkeiten und Ergebnisse gemeint sind, die sich sowohl auf die fachliche als auch auf die technische Lösung beziehen. Im Refit Agile Blueprint bezieht sich die Spezifikation als Tätigkeit hingegen nur auf die Definition der UI Artefakte, während die Tätigkeiten und Artefakte der modelltechnischen Lösung ganz klassisch als Entwurf eines Designs bezeichnet werden. Bei der konkreten Abbildung auf ein Ticketsystem wurde allerdings für die Tickets ein Tracker des generischen Typs "Spezifikation" geschaffen, der sich über die Kategorien "Definition" und "Design" ausdifferenziert. Man könnte hierfür ebenso zwei getrennte Tracker Typen konfigurieren.

Im Scrum Guide heißt es:

"Die Artefakte von Scrum repräsentieren Arbeit oder Wert. Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. So haben alle, die sie überprüfen, die gleiche Grundlage für Anpassungen."

Diese Definition ist so präzise, daß ihr Nichts hinzuzufügen wäre, außer daß der letzte Satz eine Voraussetzung für die Präzision von Arbeit ist. Jedoch unterscheiden sich die Artefakte von Scrum von dem was im Refit Agile Blueprint ein Artefakt ist, nämlich ein fachliches Dokument.

Im Scrum Guide heißt es:

"Das Refinement des Product Backlogs ist der Vorgang, durch den Product Backlog Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden."

Der Scrum Guide lässt damit die Frage offen, wann genau und wie oft dieser Vorgang in Bezug auf einen Sprint stattfinden soll.
Die obige Definition ist auch für das Refit Agile Blueprint gültig, wobei der Schwerpunkt aber im Unterschied zu Scrum nicht nur auf der Zerlegung sondern vor allem auf der weiteren Ausdifferenzierung liegt. Der entscheidende Unterschied des Refit Agile Blueprints setzt genau hier an, indem dieses konkret vorschreibt, wie genau diese Zerlegung aussehen soll, also welche Refit-spezifischen Artefakte dabei entstehen sollen und wie diese Artefakte in Beziehung zueinander stehen. Dem Refinement entsprechen im Blueprint die Erstellung von Feinspezifikation und Feinentwurf.  

In der Scrum-Praxis ist die "Definition of Ready" eine vom Team vereinbarte Checkliste, deren Kriterien der Entscheidung darüber dient, ob die Qualität eines Backlog-Items ausreichend ist, um im Sprint verarbeitet zu werden. Im Wesentlichen prüfen die Kriterien, ob die Akzeptanzkriterien der Backlog-Items ausreichend klein sind, klar verständlich formuliert und vor allem auch von den Teammitgliedern verstanden sind. 
Das ist wichtig, weil das Ziel von Scrum-Teams darin besteht, so schnell wie möglich die Backlog-Items mit dem größten Mehrwert umzusetzen. Die Absicht besteht also darin, mit Hilfe eines Gütekriteriums für Backlog-Items (z.B. User Stories) es dem Entwicklungsteam zu ermöglichen, sich auf die Verfeinerung von wichtigen Backlog-Items zu fokussieren. Damit ist die Berücksichtigung der "Definition of Ready" also ein Quality Gate für die Backlog-Items, wenn es bei der Sprintplanung um die Übernahme von Backlog-Items vom Product-Backlog in den Sprint-Backlog geht. 

Im Scrum Guide kommt die "Definition of Ready" gar nicht vor, sondern dort ist nur die Rede von Backlog-Items, die so "vorbereitet" sind, dass das Entwicklungsteam sie in den Sprint übernehmen kann. Wie genau entschieden wird, wann ein Backlog-Item soweit ist, besagt der Guide nicht. Aber offenbar gibt es bei vielen Scrum-Teams in der Praxis hierzu einen Bedarf, der dann mit der "Definition of Ready" erfüllt wird. Um die "Definition of Ready" für die einzelnen Backlogeinträge zu erfüllen, müssen diese Teams dann vor dem nächsten Sprint durch geeignete Refinements dafür sorgen, daß die Backlogeinträge dann bei der nächsten Sprintplanung durch ausreichende Vorbereitung das Quality Gate passieren können.

Im Scrum-Guide heißt es zum dritten Thema "Wie" des (pro Sprint einmaligen) Scrum-Events "Sprint-Planning":

"Für jeden ausgewählten Backlog-Eintrag planen die Entwickler die notwendige Arbeit, um ein Inkrement zu erstellen, das der Definition of Done entspricht. .... Wie dies geschieht, liegt im alleinigen Ermessen der Entwickler."

Weiterhin lautet der letzte Satz zum (täglichen) Scrum-Event "Daily Scrum":

"Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Entwickler ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints." 

Das zentrale Problem, nämlich ein gemeinsames Verständnis der Entwickler unter den jeweiligen Aspekten von Frontend und Backend zu erreichen, wird dadurch aber nicht gelöst, denn es wird nicht sichergestellt, WORIN GENAU das Verständnis und WORÜBER GENAU ein Konsens der Planung besteht. Es kann dazu führen, daß einige Beteiligte für sich ein Verständnis entwickeln, daß jeweils NICHT zum Verständnis der Anderen passt. Diese Diskrepanz führt dann meistens erst während des Sprints zu Problemen, wobei die dann folgenden Diskussionen durch keine Scrum-Artefakte unterstützt werden, sondern nur durch den aktiven Einsatz von Scrum-Mastern das Verständnis zeitaufwändig im optimalen Fall verbal erreicht werden kann. Im schlechtesten Fall wird eine Lösung des Backlog-Items umgesetzt, die den Vorstellungen des Product-Owners nicht entspricht und deshalb aus dem Inkrement herausfällt. 

Das Refit Agile Blueprint ersetzt nun die "Definition of Ready" als Quality Gate durch eine "Definition of Artefacts" als Gütekriterium in Form von Regeln die vorschreiben, wie genau die Bedingungen der Zerlegung aussehen, also welche Artefakte zur Spezifikation dabei entstehen sollen und wie diese Artefakte in Beziehung zueinander stehen. Dabei sollte der notwendige Vorgang der Zerlegung durch erfahrene Experten unmittelbar nach einer Iterationsplanung vorgenommen werden, kann aber während der Iteration als explizite "Revision" solange wiederholt werden, wie es sich bei der Bewertung der Güte der Artefakte in Bezug auf die aktuelle Iteration als notwendig erweist. An diese Spezifikationsartefakte werden dann ein oder mehrere Entwicklungstasks gebunden, entsprechend der Regel, daß es keine Entwicklung ohne Spezifikation geben kann. 

Das Refit Agile Blueprint stellt ein gemeinsame Verständnis des geplanten Ausbauzustandes dadurch sicher, indem es aus Sicht des Frontends eine formale Feinspezifikation und aus Sicht des Backends einen formalen Feinentwurf geben muss, so daß es allen Beteiligten klar wird, wie eine mögliche Lösung aussehen kann. Die FDD-Methode adressiert dieses Problem, indem es den Schritt "Entwurf je Feature" mit den jeweiligen Artefakten voraussetzt, bevor mit dem Schritt "Programmierung je Feature" die Entwicklung eingeleitet wird. Das Refit Agile Blueprint greift diesen Ansatz auf und erweitert ihn dahingehend, indem diese vorläufigen Spezifikationen und Entwürfe als Grundlage für das Gewinnen von weiteren Erfahrungen in der Iteration dienen können. Auf diese kann dann während der Iteration flexibel reagiert werden, indem jedes Teammitglied bei Implementierungsproblemen über eine "Revision" eine formale Anpassung der Spezifikation oder des Entwurfs erwirken kann.

Der entscheidende Unterschied zu Scrum liegt also in einer konkreten Vorgabe für die Zerlegung der Backlog-Einträge und deren Ausprägung als neue spezifische Artefakte und dem Ersatz des täglichen Scrum-Meetings zur Bewertung des Fortschritts in Bezug auf das Sprintziel durch bedarfsgerechte Abstimmungen für eine als notwendig erachtete zielgerichtete Neuplanung.
Ein weiterer Unterschied liegt im Wegfall der zwingenden Befristung bei den Scrum Events, wo jedes Event eine maximale Dauer haben darf. Die Dauer eines Sprints steht dort zu Beginn fest und darf weder gekürzt noch verlängert werden. Bei Refit Agile dürfen alle Ereignisse so lange andauern, bis sie ihren Zweck erfüllt haben, was vor allem für die Dauer einer Iteration gilt.

Am Anfang eines Produktlebenszyklus legt die Planungsphase mit einer Auflistung aller Anwendungsfälle als Grobspezifikation und einem Modellentwurf der Systemkomponenten als Grobentwurf die Grundlage für die nachfolgenden iterativen Engineering Zyklen, in denen repetitiv Spezifikation und Entwurf in Form der jeweiligen Artefakte verfeinert oder neu definiert werden. 

In jedem Engineering Zyklus (Iteration) entsteht ein neuer Ausbauzustand des Produktes, und zwar immer zunächst durch Erweiterungen oder Änderungen an den Artefakten, bevor an der Codebase entwickelt wird. Damit durchläuft ein Engineering Zyklus mindestens einmal die folgenden Phasen:

• Spezifikation der User Stories durch Feinspezifikation bzw. Redefinition
• Entwurf der Modelle und der API's durch Feinentwurf bzw. Redesign
• Entwicklung durch Implementierung der Artefakte bzw. Refactoring

Abhängig davon, ob bestimmte Leistungsmerkmale erstmalig oder wiederholt bearbeitet werden, ergeben sich folgende Bearbeitungsschritte an den Artefakten bzw. der Codebase:

Grundsätzlich gilt: Jedes zu implementierende Feature wird auf mehrere Tickets zur Spezifikation, zum Entwurf und ggf. zur Implementierung abgebildet, die sinnvoll zueinander in Beziehung stehen. Diese Tickets können eine Spezifikation oder einen Entwurf zunächst direkt enthalten, aber sobald die Arbeit an den jeweiligen Artefakten begonnen hat, dienen sie zum Tracken des Reifegrades eben dieser Artefakte. Um sie jederzeit im Ticketsystem leicht zu finden, sollten sie Container-Trackern, die für einen Use Case, eine Komponente oder eine übergreifende Fachlogik stehen, untergeordnet sein. Zum Tracken der Implementierung eines Features kann bei Bedarf auch ein Ticket vom Typ Task angelegt werden.

Ein übergeordneter Container-Tracker dient als Engineering-Kontext, der stets einen Informationsüberblick zu allen geplanten, aktuell durchgeführten und vergangenen Aktivitäten zu einem Feature erlaubt. Alle Engineering-Kontexte zusammen bilden die Entwicklung des Ausbauzustandes des gesamten Produktes als Änderungen von Spezifikationen und Modellentwürfen ab. 

Als zentrale Regel gilt, daß es zu jedem Feature immer mindestens ein Ticket zur Spezifikation geben muss. Weil es zur Spezifikation eines Features für ein Inkrement normalerweise mehrerer Artefakte (User Stories, API-Designs, UML-Diagramme, usw.) bedarf, gibt es entsprechend zu jedem Feature auch mehrere Spezifikations-Tickets, die sich jeweils auf ihr Artefakt beziehen. Andererseits kann sich die Implementierung eines Features auch mal über mehrere Iterationen erstrecken, wozu es erforderlich sein kann, mehrere Tasks zu Teil-Implementierungen in den aufeinander folgenden Iterationen anzulegen.

Für eine ideale Arbeitsteilung zwischen dem Ticket-System und der Dokumentation der Artefakte gilt: Ein Spezifikations-Ticket soll generell nicht dazu dienen, die Spezifikation selbst zu enthalten, sondern soll den Reifegrad eines Artefaktes anzeigen, das selbst als ein Teil der gesamten Spezifikation eines Features dient, also in Form einer User Story, eines API-Designs oder eines UML-Diagramms. 

In vielen Ticket-Systemen kann man durch Konfiguration spezieller Auswahllisten die Spezifikations-Tickets den Kategorien Definition oder Design zuweisen, um dadurch schon die Art des Artefaktes zu kennzeichnen, auf welches sich das Ticket bezieht. So beziehen sich die Tickets der Kategorie Definition auf die Spezifikation von Eigenschaften der Benutzerschnittstelle und die Tickets der Kategorie Design auf den Entwurf von digitalen Systemschnittstellen und Klassenmodellen. Zur Anzeige des aktuellen Reifegrades eines Artefaktes für die Dauer einer Iteration dient eine Auswahlliste für den Status von "Entwurf" über "Abgestimmt" und "Revision" bis "Bereit", und zwar unabhängig vom daran getätigten Aufwand. 

Da die Spezifikations-Tickets immer dem Engineering-Kontext eines Features zugewiesen werden, sollten die Titel der Spezifikations-Tickets auch den Namen des jeweiligen Artefaktes und des Features enthalten. Dann können die Tickets auch in beliebig generierten Übersichten, z.B. in einer Roadmap, eindeutig einem Feature zugeordnet werden.  

Beispiele für Kategorie und Titel von Tickets zur Feinspezifikation oder zum Feinentwurf nach dem Muster: <Artefakt> zu/für <Feature> :

• [Definition:] "User Story: Konfiguration von XY"
• [Definition:] "Wireframe-Layout für Konfiguration von XY"
• [Design:] "Domänenmodell A für Konfiguration von XY"
• [Design:] "REST-API Ressource B für Konfiguration von XY"

Beispiele für Kategorie und Titel von Tickets zur Überarbeitung einer Feinspezifikation oder eines Feinentwurfs in weiteren Iterationen:

• [Definition:] "Redefinition der User Story: Konfiguration von XY"
• [Design:] "Redesign des Domänenmodells A für Konfiguration von XY"

Die Implementierung eines Features, das möglichst einem Engineering-Kontext zugeordnet ist, wird im Team über den dynamischen Reifegrad der zugehörigen Artefakte koordiniert. Es gilt der folgende Lebenszyklus für den Status eines Spezifikations-Tickets, um den Reifegrad eines gesamten Spezifikations-Artefaktes oder eines bestimmten im Ticket benannten Teils davon anzuzeigen :

Status Lebenszyklus eines Spezifikations-Artefaktes: "Entwurf"  ↔️  "Abgestimmt"  [ ↔️  "Revision" ]  ↔️  "Bereit" 

Der Status der für eine Iteration relevanten Artefakte stellt also eine notwendige Bedingung für die iterativen Entwicklungsarbeiten an Features dar. Erst wenn alle relevanten Spezifikations-Tickets einer Iteration den Reifegrad ihrer Artefakte mit dem Status "Abgestimmt" anzeigen, sollte die Implementierung der davon abhängigen Features in der laufenden Iteration begonnen werden. Die Implementierung der abhängigen Features sollte nicht mit dem Status "Erledigt" abgeschlossen werden, bevor sich die zugehörigen Artefakte nicht in dem Status "Bereit" befinden. Selbstverständlich können sich die Artefakte von einer Iteration zur nächsten ändern, aber der Status "Bereit" gilt final für die jeweilige Spezifikation zur Änderung der Artefakte in der gerade aktuellen Iteration.

Dadurch daß der Refit Agile Blueprint prinzipiell OHNE Taskboard auskommt und sich komplett auf ein Ticket-System abbilden lässt, ergibt sich der aktuell bedeutsame Vorteil, daß die gesamte Teamarbeit grundsätzlich Remote stattfinden kann. Ob dieser Aspekt förderlich für die Kommunikation bei Besprechungen unter Anwesenheit aller Teammitglieder ist, muss getrennt von der Motivation zu Refit Agile bewertet werden.

Die Ablaufbeschreibung des Refit Agile Blueprints ist als Anregung zu verstehen, in welchen Teilschritten die Arbeit an einem Produkt idealerweise organisiert werden kann, um der Idee von Refit Agile am meisten zu entsprechen. Dies bedeutet keineswegs, dass alle Schritte genau in der dargestellten Reihenfolge stattfinden müssen oder überhaupt durchgeführt werden müssen, damit der Blueprint sinnvoll sein kann. Der Prozessablauf dient nur als eine formalisierte Darstellung einer möglichen Arbeitsteilung, die dahingehend erprobt wurde, dass sie die Merkmale agiler Vorgehensweisen enthält und dennoch die von Refit Agile propagierten Ziele adressiert.

Zu dem skizzierten Ablaufschema ist anzumerken, dass es gewisse Ähnlichkeiten zu dem Prozessablauf von Scrum gibt. In dem Prozessschritt "Iteration", der einem "Sprint" bei Scrum entspricht, gibt es mit der Abfolge der Teilschritte "Release-Planung", den jeweiligen Entwürfen zu den Feinspezifikationen und dem Teilschritt "Abstimmung oder Revision" innerhalb des Teilschrittes "Implementierung" eine logische Sequenz, die in der Welt von Scrum einer (geänderten) Abfolge von "Sprintplanung", "Refinement" und "tägliche Neuplanung" entsprechen würde. Allerdings mit dem oben erwähnten Unterschied, dass der Begriff "Refinement" in Scrum eine andere Bedeutung hat als bei Refit Agile. Das hohe Maß an Agilität wird auch innerhalb des Teilschrittes "Programmierung" deutlich, wo zum Entscheidungspunkt "Spezifikationen sinnvoll und realisierbar" jederzeit so in die Revision der ursprünglichen Abstimmung innerhalb der begonnenen Implementierung zurückgesprungen werden kann, wie es etwa der "täglichen Neuplanung" der Backlogeinträge eines Sprints bei Scrum entspricht. 

Es sei noch einmal explizit darauf hingewiesen, dass die wesentlichen Unterschiede zu Scrum in der empfohlenen Arbeitsteilung und der Planung in Form von Artefakt-Dokumenten liegt. Der Scrum Guide trifft zu der Art und Weise der täglichen Abstimmung keine Aussage, so dass die praktische Umsetzung eher informell gestaltet wird. Eine informelle Abstimmung, auch "Bilaterale Klärung" genannt, hat sowohl Vorteile als auch Nachteile. Gegenseitige Erwartungen, Interessen, Zielstellungen, Bedenken und Einwände werden damit unmittelbar und direkt verhandelt, so dass eine beidseitig getragene Lösung schneller möglich wird. Da Refit Agile als Good Practice verstanden werden sollte, werden informelle Abweichungen vom Blueprint keineswegs abgelehnt. Allerdings soll bei dieser Art "bilateralen Klärung" bedacht werden, dass der Sinn der prozessgemäßen Abstimmung im Rahmen einer formellen Besprechung darin liegt, dass die formalen Artefakte als Basis aller zukünftigen Abstimmungen bei eventuellen Planänderungen auch modifiziert werden und nicht das Risiko besteht, dass die Aktualisierung der Artefakte unter den Tisch fällt. Die sichergestellte Aktualität der effektiven Planungsdokumentation ist das eigentliche Ziel der formalisierten Ablaufschritte.

Wenn dieses Ziel durch die Teammitglieder beachtet wird, sollten informelle Abweichungen vom Prozessablauf des Blueprints kein Problem sein.

Üblicherweise herrscht in der agilen Community die Vorstellung, dass es bei einem formalisierten Verfahren kaum zu der im agilen Mindset geforderten Selbstorganisation eines Teams kommen kann, da die Verantwortlichkeiten durch die eindeutige Zuordnung von Personen zu Aktivitäten zu sehr determiniert seien. Dies trifft aber keinesfalls notwendig zu, da es generell und auch im Refit Blueprint kein Problem darstellt, wenn mehrere Rollen einem Teilschritt zugeordnet werden. Besonders deutlich wird dies in dem Teilschritt "Abstimmung oder Revision" des Prozessablaufs "Implementierung", in dem über die zuvor bei Iterationsbeginn vom UI-Architekten und System-Architekten erstellten Spezifikationsentwürfe vom gesamten Team entschieden wird, bevor die Spezifikationen mit dem Status "Abgestimmt" als verbindliche Entwicklungsgrundlage für das gesamte Team bis zu einer angemeldeten Revision gelten. In organisatorischer Hinsicht der Arbeitsteilung obliegt damit die Verantwortung für den dokumentierten Entwicklungsplan der aktuellen Iteration nicht mehr bei den Spezialisten für die Entwürfe, sondern solange beim gesamten Team, wie jedes Teammitglied das Recht zur Revision einer Spezifikation einfordern kann.

In einem Artikel [4] zur Entwicklung von Softwarearchitekturen mit Selbstorganisation heißt es gegen Ende:

"Im Gegensatz zum klassischen Vorgehensmodell in der Softwareentwicklung, bei dem ein Architekt das gesamte Aufgabenspektrum abdecken und im Blick haben muss, wird bei der agilen Herangehensweise die Arbeit durch das gesamte Team geleistet. Die Abstimmung zwischen Architekt und Entwicklern wird durch ein kollektives Verständnis der Softwarearchitektur ersetzt." (oder: "erreicht")

"Durch die Verlagerung der Architekturverantwortung auf das gesamte Team eröffnen sich noch weitere Vorteile: Die individuellen Fähigkeiten, Erfahrungen und Blickwinkel lassen sich für eine differenziertere und umfänglichere Betrachtung der Architektur nutzen, denn wie heißt es so schön: "Du glaubst nur solange, eine gute Architektur entworfen zu haben, bis du sie jemandem erklärst." Zudem wird jeder Einzelne motiviert, die Architekturprinzipien umzusetzen, wenn das gesamte Team an der Entwicklung mitarbeitet."

Im Sinne eines prozessdynamischen Aspektes von Selbstorganisation kann durch diese schrittweise Verlagerung von Verantwortung sowohl der Vorteil der Planungs-Expertise von erfahrenen Spezialisten als auch die Implementierungserfahrung der Entwickler zum gemeinsamen Vorteil ausgenutzt werden. Die anderen Aspekte von agiler Führung zur Selbstorganisation über Ziele und Rahmenbedingungen werden durch dieses Verständnis ein keiner Weise berührt oder ersetzt, sondern in gewisser Weise ergänzt. 

Quellen:

[1]  APM - Agiles Projektmanagement (Uwe Vigenschow)

[2]  FDD - Feature Driven Development ( it-agile.de )

[3]  Spezifikation im agilen Kontext (Andreas Walter) 

[4]  Agile Softwarearchitektur im Team (Christian Fischer)