Wenn ich anfange, mit einem agilen Produktteam zu arbeiten, ist eine der häufigsten Situationen, in denen die Teams lange und frustrierende Sprint-Planungsmeetings haben, weil Backlog-Elemente schlecht definiert und nicht gut verstanden sind; sie haben eine langsame Geschwindigkeit sowie ein schlechtes Design, weil Details während des Sprints noch ausgearbeitet werden; und die Menge an Verschwendung und Nacharbeit ist sehr hoch, weil Backlog-Elemente nicht validiert wurden.

Denken Sie daran, dass es unser übergeordnetes Ziel ist, unsere Ideen so schnell und kostengünstig wie möglich zu validieren. Das Erstellen und Starten einer Produktidee ist im Allgemeinen der langsamste und teuerste Weg, um die Idee zu validieren.

Deshalb bin ich ein großer Verfechter dessen, was manchmal als Dual-Track-Agile bezeichnet wird (auch bekannt als Dual-Track-Scrum, Fake It Before You Make It, Build Things That Don’t Scale/Build Things That Do Scale, Move Fast/Don’t Break Things, Continuous Discovery/Continuous Delivery usw.).).

Früher habe ich dies einfach als Entdeckungssprints bezeichnet, aber das hat eine Implikation der zeitgesteuerten Entdeckung und auch der Serialisierung von Phasen. Jeff Patton teilte mir zuerst den Begriff “Dual-Track Scrum” mit und ich bevorzuge diesen Begriff, weil er die parallele Natur von Entdeckung und Lieferung besser erfasst.

Beim Discovery-Track geht es darum, schnell validierte Product Backlog-Elemente zu generieren, und beim Delivery-Track geht es darum, freigabefähige Software zu generieren.

Ein weiterer Grund, warum ich die Dual-Track-Agile-Metapher mag, ist, dass ich viele Leute finde, die im Wesentlichen kleine Mini-Wasserfälle innerhalb ihres Scrum-Frameworks machen. Der Produktmanager führt eine Art “Anforderungsarbeit” durch, die an einen Designer übergeben wird, der seine Entwürfe erstellt und seine Artefakte generiert (normalerweise kommentierte Wireframes), und die dann an das Bereitstellungsteam übergeben wird, um sie zu erstellen und zu testen.

Im Gegensatz dazu ist der Arbeitsablauf im Dual-Track-Agile nicht dadurch gekennzeichnet, dass jede Rolle Artefakte an den nächsten Schritt weitergibt; vielmehr ist es kollaborativ – der Produktmanager, der Designer und der leitende Ingenieur arbeiten Seite an Seite zusammen, um Backlog-Elemente zu erstellen und zu validieren.

Die Leser dieser Artikel wissen, wie wichtig ich User Experience Design halte, aber eine der Schwierigkeiten für viele Agile Teams ist, dass der Rhythmus und das Tempo von Agile für traditionelle UX-Teams sehr schwierig sein können. Ich bin ein Fan von Lean UX. Lean UX und Dual-Track Agile sind füreinander gemacht. Anstatt uns auf Artefakte zu konzentrieren, konzentrieren wir uns auf Prototypen und validieren diese Prototypen in Discovery, mit dem zusätzlichen Vorteil, dass der Prototyp als Spezifikation für die Lieferung dient.

Am wichtigsten ist, dass wir im Gegensatz zu einem Wasserfall-Prozess, bei dem die Validierung nach der Veröffentlichung erfolgt, im Dual-Track-Agile während der Entdeckung validieren. Nach dem Prinzip, so schnell und billig wie möglich zu validieren, können wir die meiste Zeit tatsächlich validieren, bevor wir Produktionscode schreiben, im Sinne von “fake it before we make it.”

Wenn Ihr Produktteam also von der Menge an Verschwendung und dem langsamen Tempo bei der Erzielung tatsächlicher Geschäftsergebnisse frustriert ist, sollten Sie Dual-Track-Agile ausprobieren. Sehen Sie, ob dies zu einem Maß an Zusammenarbeit, schneller Iteration und Validierung führen kann, das zu viel besserer Arbeit führt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.