Product management: de 6-weekse cyclus, een alternatief op kanban en scrum
Tot vrij recentelijk werkte het tech team van mijn onderneming via een kanban systeem. Qua product management hield dit in dat we een product roadmap hadden uitgedacht voor een heel jaar, daar projecten uitplukten en die dan een voor een oppakten en begonnen te ontwikkelen.
Wanneer je product management verandert in “development hell”
Op het moment dat er een product idee binnen kwam dat urgent leek – zij het een feature verzoek van een klant, een idee van de CEO, of een bug – dan kon dit mooi bovenaan aan ons to-do lijstje worden toegevoegd en per direct worden opgepakt door een developer.
Dat is het immers het idee achter agile development toch? Je houdt jezelf lean, flexibel en snel ten koste van alles. De wereld verandert in een razend tempo en als team wil je rap je focus kunnen verleggen naar hetgeen op dat moment het meest de moeite waard is om aan te werken.
En in het begin werkte dit. We lanceerden feature na feature en ons product verbeterde met de week. Er was geen vuiltje aan de lucht. Spontane ideeën konden gewoon op de to-do lijst van het kanban board worden gegooid, bovenaan worden geplant, en opgepikt door de developer die er het snelste bij was.
Maar op een gegeven moment gebeurde er iets geks. Feature development leek plotseling eindeloos lang te duren. Niks werd meer afgerond. Developers begonnen uit te branden. En het product verbeterde nauwelijks meer, maand na maand.
Wat was er aan de hand?
Om dit op te lossen begon ik een zoektocht naar een nieuw product management framework. We hadden een structuur nodig, met zekere begrenzingen die meer creativiteit zouden afdwingen, zodat we gepolijste en hoogstaande product features zouden kunnen ontwikkelen. Maar met genoeg wendbaarheid om snel te kunnen blijven en dit proces te kunnen blijven herhalen gedurende het jaar. We wilden iets met meer substantie, maar minder intensiteit dan scrum-sprints.
Alle gedetailleerde inschattingen van stories en de zeer krappe scrum-sprint tijdsduur van twee weken zijn niet handig vanwege de enorme hoeveelheid tijd die je steekt in het gedetailleerde plannen. En omdat het tijdsbestek van scrums te kort is om iets zinvols te verschepen, krijg je alsnog dat je projecten zich blijven voortslepen voor een onbepaalde tijd, zij het nu in brokken van twee weken.
De oplossing: gebruik de 6-weekse cyclus voor je product management
Wat voor ons perfect bleek te werken is het opdelen van ons werk in een 6-weekse cyclus. Elke zes weken starten we een nieuwe cyclus van projecten. Elke cyclus bestaat uit twee soorten projecten:
Big Batch: Big Batch-projecten zijn grote features of projecten die waarschijnlijk de volledige zes weken nodig gaan hebben om afgerond te kunnen worden. Over het algemeen stoppen we maar twee of drie Big Batch projecten in een cyclus.
Small Batch: Small Batch-projecten zijn kleine verbeteringen, aanpassingen, of bugs die ergens tussen een dag en twee weken opgelost kunnen worden. Onze cyclussen bevatten over het algemeen zo’n zes tot acht small batch projecten.
Om je een idee te geven hoe dit in de praktijk werkt: dit is een memo waarin we onze eerste product cyclus aankondigden (we vernoemen onze cyclussen naar creaturen uit de Engelse mythologie).
Nadat we een cyclus van zes weken hebben we afgerond, hebben we een cool-down periode van twee weken. Developers kunnen gedurende deze tijd zelfstandig projecten oppikken, verbeteringen doorvoeren of nieuwe technologieën onderzoeken, zonder dat ze aan een strak schema vast zitten. Dit stimuleert creativiteit en houdt de energielevels op peil. Eveneens gebruiken we deze periode om vast te stellen aan welke projecten we willen werken voor de volgende cyclus.
Voor de duidelijkheid: een cyclus is niet hetzelfde als een sprint. Sprints gaan gepaard met stress en overspannenheid aan het einde van de sprint, wat leidt dat mensen uitgeblust zijn en daarmee inefficiënt aan het begin van een sprint. Dit biedt niet een regelmatige en kalme manier van werken, wat leidt tot suboptimale resultaten.
Hoe ziet het plannen voor een cyclus eruit?
Op het moment dat een nieuwe cyclus van start gaat, werken we in parallel aan nieuwe product ideeën voor de volgende cyclus. Net nadat de cyclus is afgerond, gedurende de cool-down periode, plannen we een meeting in waarin we onze pitches voor de volgende cyclus bespreken. Pitches zijn projecten die gedurende de voorgaande cyclus zijn ontwikkeld door het product team (hoewel developers en marketeers ook vrij zijn om zijn pitches in te dienen). Voor pitches die nieuwe product features zijn geldt hier dat het UX-design en graphic design op z’n minst 80-90% afgerond moeten zijn.
Zo’n meeting kan wel twee uur duren. De teamleden die deelnemen zijn een select stel senior developers, de CEO en ikzelf. Iedereen heeft voorafgaand aan de meeting de ingeleverde pitches goed bestudeerd, en het doel van de meeting is te bepalen welke pitches geselecteerd gaan worden voor de aankomende cyclus.
Hoe zorg je dat big batch projecten niet langer dan 6 weken duren?
We geloven dat van praktisch elk project een uitstekende “zes weken versie” te ontwikkelen is. Er zijn natuurlijk altijd uitzonderingen: bijvoorbeeld een geheel nieuw product ontwikkelen from scratch, iets proberen te maken met gloednieuwe technologie, etc. Maar je komt erachter dat bijna alle projecten van substantie binnen zes weken of minder ontwikkeld kunnen worden. En kunnen worden ontwikkeld op een kwalitatief hoogstaande manier.
De truc hier is om een feature kritisch onder de loep te nemen: wat moét het zijn, in plaats van wat kán het zijn? Dit leidt ertoe dat je voordat je met het ontwikkelen van een feature begint je al gaat snijden. Je focust je op de essentie en laat alles varen wat niet substantieel hieraan bijdraagt. Zo kom je erachter dat je in een tijdsbestek van zes weken bijzonder veel kunt bereiken. Wanneer je vervolgens aanvangt met het ontwikkelen van het project, kom je voor geen of weinig grote verrassingen te staan. Op die manier staan de zes weken van de cyclus enkel in het teken van implementatie en uitvoering – niet plannen.
Om er zeker van te zijn dat je de zes weken niet gaat overschrijden moet je je dev team in bescherming nemen. Dat betekent nee zeggen tegen “snelle” product verzoekjes van bijvoorbeeld je sales team. Het gaat fout wanneer een non-techneut denkt “dit moet toch wel in vijf minuten te doen zijn?” Ogenschijnlijk kleine dingen kunnen nog bijzonder lang duren – die vijf minuten die je marketeer aanneemt kan in werkelijkheid meer in de buurt van drie uur zitten.
En dan zit je nog met de kosten die met “task switching” gemoeid zijn. Als een developer ineens iets heel anders moet oppakken dan waar hij mee bezig was, zal hij uit z’n flow raken. Developers versnipperen hun dagen niet in kleine brokjes zoals een marketeer dit doet: ze hebben lange aaneengesloten dagdelen van volle concentratie nodig. En daarbij komt dat ieder project aanlooptijd nodig heeft om er lekker in te raken.
Zo kan dat kleine verzoekje van “5 minuten” de ochtend van je developer om zeep helpen. Die verloren ochtend kan vervolgens zijn dag verpesten.
En zo ga je uiteindelijk over de zes weken van je cyclus heen. De moraal van het verhaal: bescherm je developers alsof je leven ervan afhangt.
En wat nou als iemand een bug ontdekt tijdens een cyclus? Dit wil je toch zeker direct aanpakken?
Alle software heeft bugs. Er is niks bijzonders aan. Bij ons kwam het wel eens voor dat we een bug ontdekte die er al maanden zat. Soms wees een gebruiker ons op een bug. De neiging was dan vaak om die bug bovenaan ons to-do lijstje te gooien en deze zo snel mogelijk op te lossen.
Dit doen we niet meer. Als er een bug wordt gerapporteerd, nemen we hier notitie van, en het kan zijn dat een developer hem dan oppakt tijdens de cool-down aan het einde van de cyclus. Wordt deze bug niet spontaan door een developer opgepikt, maar achten we de bug wel van belang? Dan kan die ge-pitched worden voor de aankomende cyclus. Maar de bug zal niet toegevoegd worden aan de huidige cyclus.
De uitzondering op deze regel is als de bug het product om zeep helpt: bijvoorbeeld, hij veroorzaakt app crashes voor een significant aantal gebruikers. In dit geval leggen we wel onze werkzaamheden neer en lossen we de bug zo snel mogelijk op.
Er is uiteindelijk natuurlijk nog een stuk dieper in te gaan op dit onderwerp. Als je hier interesse in hebt, kun je Basecamp’s Shape Up lezen. Basecamp heeft het principe van de 6-weekse cyclus geïntroduceerd en zijn zeer genereus in het – gratis – uiteenzetten van hun methodiek. Ik stel voor dat je hun boek aanvliegt als een buffet: kies wat er voor jouw organisatie van toepassing is en negeer de rest. Als je niet houdt van zalm, eet dan niet de zalm. Zo zijn wijzelf uiteindelijk ook uitgekomen op een aanpak die het beste aansluit op onze organisatie en cultuur.
Uiteindelijk heeft deze aanpak bij ons geleid tot de volgende voordelen qua ons product management: onze developers zijn gelukkiger in hun werk, we leveren hogere kwaliteit product werk af, en onze projecten slepen zich niet meer eindeloos lang voort.
De take-aways
- Je hoeft met softwareontwikkeling niet te kiezen tussen kanban en scrum
- Een zes-weekse cyclus kan veel van de nadelen die deze twee methodes met zich meebrengen oplossen
- Praktisch elk project van substantie is wel in zes weken te ontwikkelen
- Bescherm je dev team kostte wat het kost: laat ze hun focus houden op slechts de cyclus, niets wat daarbuiten valt
