Toen ik voor het eerst gaan werken met een Agile product team, één van de meest voorkomende situaties vind ik waar de teams hebben een lange en frustrerende Sprint planning meetings, omdat backlog items zijn slecht gedefinieerd en niet goed begrepen; ze zijn langzame snelheid zo goed als slecht ontwerp omdat de details worden nog uitgewerkt tijdens de Sprint; en de hoeveelheid afval en rework is zeer hoog, omdat backlog items nog niet is gevalideerd.

onthoud dat ons hogere doel is om onze ideeën zo snel en goedkoop mogelijk te valideren. Eigenlijk bouwen en lanceren van een product idee is over het algemeen de traagste, duurste manier om het idee te valideren.

daarom ben ik een groot voorstander van wat soms aangeduid wordt als Dual-Track Agile (aka 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, etc.).

ik gebruikte om dit te verwijzen als gewoon Discovery Sprints, maar dat heeft een implicatie van tijd-boxed Discovery, en ook serialisatie van fasen. Jeff Patton eerst gedeeld met mij de term “Dual-Track Scrum” en ik geef de voorkeur aan deze term, omdat het beter vangt de parallelle aard van ontdekking en levering.

de Discovery track draait om het snel genereren van gevalideerde product backlog items, en de Delivery track draait om het genereren van vrij te geven software.

een andere reden waarom ik de tweesporige Agile metafoor leuk vind, is dat ik veel mensen vind die in wezen kleine mini-watervallen doen binnen hun Scrum framework. De product manager doet een soort van” eisen ” werk, en dat wordt doorgegeven aan een ontwerper die zijn ontwerpen doet en genereert zijn artefacten (meestal geannoteerde wireframes), en dan dat wordt overgedragen aan de levering team te bouwen en te testen.

in Dual-Track Agile daarentegen wordt de workflow niet gekenmerkt door elke rol die artefacten naar de volgende stap levert; eerder is het collaboratief-de productmanager, ontwerper en lead engineer werken samen, zij aan zij, om backlog items te creëren en te valideren.

lezers van deze artikelen weten hoe belangrijk ik user experience design vind, maar een van de problemen voor veel Agile teams is dat het ritme en tempo van Agile erg moeilijk kan zijn op traditionele UX teams. Daarom ben ik een fan van Lean UX. Lean UX en Dual-Track Agile zijn voor elkaar gemaakt. In plaats van ons te richten op artefacten, richten we ons op prototypes en het valideren van die prototypes in Discovery, met het extra voordeel dat het prototype dient als spec voor Levering.

het belangrijkste is dat we, in tegenstelling tot een Watervalproces waarbij de validatie plaatsvindt na release, in Dual-Track Agile valideren tijdens Discovery. In het principe van valideren zo snel en goedkoop als we kunnen, veel van de tijd kunnen we in feite onze validatie doen voordat we een productiecode schrijven, in de geest van “fake it before we make it.”

dus als uw productteam gefrustreerd is door de hoeveelheid afval en het trage tempo in het bereiken van daadwerkelijke bedrijfsresultaten, overweeg dan om Dual-Track Agile uit te proberen. Kijk of dit kan inspireren tot een niveau van samenwerking, snelle iteratie en validatie die resulteert in veel beter werk.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.