Dual-Track Scrum

Als ik voor het eerst met agile productteams in aanraking kom, bevinden de teamleden zich meestal in een situatie waarin ze geplaagd worden door lange en frustrerende Sprint Planning meetings, omdat de Backlog Items slecht gedefinieerd zijn en niet goed begrepen worden. De Velocity is laag en het ontwerp slecht, omdat er ook tijdens de Sprint nog details uitgewerkt worden. Bovendien is er veel verspilling en moeten er veel aanpassingen gedaan worden, omdat de Backlog Items niet gevalideerd waren.

Onthoud dat ons overkoepelende doel is om onze ideeën op de snelste en meest kostenefficiënte manier te valideren. Een productidee daadwerkelijk bouwen en op de markt brengen is in principe de langzaamste en duurste manier om dat te doen.

Wat is Dual-Track Scrum?

Daarom ben ik een groot fan van iets dat onder andere bekend staat als Dual-Track Scrum. Vroeger gebruikte ik de term "Discovery Sprints" hiervoor, maar dat wekt de indruk van een tijdgebonden Discovery en het serieel doorlopen van fases.

Jeff Patton vertelde me voor het eerst over "Dual-Track Scrum". Ik geef de voorkeur aan deze term, omdat hij de gelijktijdigheid van Discovery en Delivery beter tot zijn recht laat komen.

Bij de Product Discovery Track gaat het erom zo snel mogelijk gevalideerde Product Backlog Items te genereren. Bij de Product Delivery Track gaat het erom opleverbaresoftware te genereren.

Een andere reden waarom ik de metafoor van twee "sporen" bij Dual-Track Scrum zo fijn vind, is het feit dat ik vaak mensen zie die in feite mini-watervallen in hun Scrum Framework inbouwen. De productmanager doet wat "requirements-werk", dat hij vervolgens doorgeeft aan een designer. Die maakt dan een ontwerp en genereert zijn artefacten (meestal geannoteerde wireframes), waarna alles voor ontwikkeling en testen aan het Delivery Team wordt overgedragen.

In tegenstelling hiermee wordt de werkwijze bij Dual-Track Scrum niet gekenmerkt doordat individuele rollen artefacten doorgeven aan de volgende stap. In plaats daarvan is Dual-Track Scrum collaboratief – productmanagers, designers en de lead developer werken zij aan zij om Backlog Items te creëren en te valideren.

Lezers van mijn artikelen weten hoe belangrijk User Experience Design in mijn ogen is. Toch kunnen het ritme en de snelheid van Scrum voor veel traditionele UX-teams een probleem vormen. Daarom ben ik zo'n groot fan van Lean UX. Lean UX en Dual-Track Scrum zijn als voor elkaar gemaakt. In plaats van ons op artefacten te richten, concentreren we ons bij de Discovery op prototypes en de validatie van deze prototypes. Een bijkomend voordeel is dat deze prototypes als specificaties voor de Delivery dienen.

Het belangrijkste punt is echter dat de validatie niet zoals bij een watervalproces na de release plaatsvindt, maar dat we de validatie bij Dual-Track Scrum al tijdens de Discovery uitvoeren. Met het principe in gedachten om iets zo snel en goedkoop mogelijk te valideren, kunnen we de validatie vaak al uitvoeren voordat er ook maar één regel code is geschreven – helemaal in de geest van het motto "fake it before we make it", oftewel net doen alsof totdat het daadwerkelijk werkt.

Conclusie over Dual-Track Scrum

Als je team gefrustreerd is omdat er zoveel verspilling is en omdat concrete bedrijfsresultaten maar langzaam worden behaald, overweeg dan Dual-Track Scrum. Misschien kan dat leiden tot betere samenwerking, sneller itereren en valideren, en daarmee tot beter werk.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.

Bedrijfsstrategie vs. Productstrategie

Leer meer over mogelijke strategieconflicten in ons artikel over het verschil tussen bedrijfs- en productstrategie.