Wie dich Dual-Track-Development aus der Feature-Factory retten kann

Weißt du was Dual-Track-Development/Dual-Track-Agile ist?
Dieser Artikel zeigt dir was Dual-Track-Development/Dual-Track-Agile ist und wie dir diese Methode helfen kann aus der Feature-Factory auszubrechen.

Der Begriff Dual Track Agile[1] wurde erstmals 2005 in einem Paper von Lynn Miller „interconnected parallel design and development tracks“ erwähnt. Zwei Jahre später 2007 hat Desiree Sy den Begriff Dual Track in einem Paper „Adapting Usability Investigations for Agile User-centered Design“ verwendet. Sie definierte die Tracks darin als Phasen die das Team während der Entwicklung durchlaufen. Marty Cagan hat diese Idee in seinen Büchern Inspired und Empowered aufgegriffen und bekannt gemacht.
Beim Dual Track Development geht es darum das Risiko möglichst früh aus dem Entwicklungsprozess zu nehmen, ohne dabei andere wichtige Produktentwicklungsaufgaben zu vernachlässigen. Das gelingt, indem die Entwicklungsaufgaben in zwei Themengebiete mit verschiedenen Zielen aufgeteilt werden.

  1. Discovery-Track
  2. Delivery-Track

Beide Tracks verlaufen demnach parallel zueinander.

Aber warum ist es wichtig Discovery und Delivery voneinander zu trennen?

Die Dual-Track Methode oft auch als Dual-Track-Agile bezeichnet hilft dabei aus pseudo agilen Methoden wie beispielsweise Zombie-Scrum, Feature-Factories, oder Water-Scrum-Antipattern auszusteigen. Es passiert immer wieder das Unternehmen dieses agile Theater spielen ohne dabei wirklich agil zu werden. Mit einem expliziten Discovery-Track werden diese Unternehmen gezwungen sich auf die explorative Entwicklung mittels Hypothesen zu fokussieren. Im Idealfall wird ein Team/Teil des Teams für die Umsetzung des Discovery-Tracks und ein Team/Teil des Teams für die Entwicklung im Delivery-Track eingesetzt.

Durch die Auftrennung in die zwei individuellen Tracks ist es auch möglich sich im Discovery-Track auf die Minimierung der größten Risiken zu konzentrieren. Das Team erstellt Hypothesen zum User-Verhalten und zu User-Bedürfnissen.
Es wird dann versucht bei jeder Hypothese und jeder Idee im Discovery-Track das

  1. Value-Risk (Wollen Kunden das Kaufen was wir entwickeln)
  2. Usability-Risk (Können User das Verwenden was wir entwickeln)
  3. Feasibility -Risk (Können unsere Developer das überhaupt bauen)
  4. Business Viability-Risk (Funktioniert das überhaupt mit unserem Geschäftsmodell/Business)

zu minimieren.

Das Problem

In vielen Unternehmen fokussiert sich das Development-Team auf den Lösungsbereich (Wie bauen wir die Lösung richtig). Der Problembereich (Bauen wir die richtige Lösung) wird jedoch meist vernachlässigt und nicht ausreichend betrachtet. Die Entwicklung wird immer weiter Optimiert um möglichst viel Durchsatz zu schaffen. Eine Feature-Factory mit pseudo-Scrum und agilen Theater entsteht.
Scrum ist nicht immer die effizienteste Lösung, jedoch, wenn es richtig gemacht wird, die effektivste, weil wir uns durch iterativ inkrementelle Schritte im Problembereich bewegen und ein optimum für die User suchen.

Doch viele Development-Teams halten sich den Großteil ihrer Zeit im Lösungsbereich auf. Die Software wächst mit der Zeit und das Team muss sich Gedanken machen über:

  • Skalierbarkeit
  • Verlässlichkeit
  • Leistung
  • Instandhaltung

Da diese Bereiche viele Risiken für das Produkt beinhalten muss sich das Team auch mit diesen Themen beschäftigen.

Fokussiert sich das Team jedoch nur darauf möglichst schnell viel Funktionalität zum User zu bringen, ohne dabei den Problembereich zu beachten, entsteht eine Feature-Factory. Die Anforderungen werden ungefragt umgesetzt und den User released.

Die Lösung – Dual Track Agile Development

Da es beim Dual-Track Development zwei Tracks gibt die sich jeweils auf ihre Gebiete fokussieren werden alle Bedürfnisse berücksichtigt. Im Discovery Track wird explorativ vorgegangen und auf den Wert für User und Unternehmen sowie auf die technische und wirtschaftliche Umsetzbarkeit geachtet, im Delivery Track wird nach strikteren Requirements vorgegangen und versucht auf Skalierbarkeit, Verlässlichkeit, Performance und Wartbarkeit zu achten.

Die Anforderungen für den Delivery-Track sind direkte Ergebnisse aus dem Discovery-Track. Der Discovery-Track wiederum hat die Aufgabe möglichst viele Hypothesen zu erzeugen, zu beweisen oder auch Ideen und Hypothesen zu eliminieren. Dadurch gelangen nur erprobte und für gut befundene Features in die Produktentwicklung.

Um nun aus einer Feature-Factory auszubrechen, muss das Team den Discovery-Track aktivieren. Dies kann entweder durch temporäre oder permanente Aufteilung des Teams in zwei Gruppen geschehen oder durch die logische Trennung der Aufgaben in die beiden Tracks. Egal wie vorgegangen wird, entscheidend ist dass die Aufgaben entsprechend dem Track betrachtet werden und die richtigen Tätigkeiten in den Jeweiligen Tracks durchgeführt werden. Im Discovery-Track muss experimentiert werden und out-of-the-box gedacht werden, während im Delivery-Track Stabilität und Nachhaltigkeit priorisiert werden muss.

[1] . Miller, “Case study of customer input for a successful product,” in Proceedings of Agile 2005. IEEE, 2005, pp. 225–234

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: