De 6-weekse cyclus: een broodnodig alternatief voor Scrum en Kanban

Veel bedrijven hebben een agile mindset omarmd. Binnen deze agile mindset vormen Scrum of Kanban vervolgens het tactisch raamwerk. Maar hoe zorg je voor iets met meer substantie, maar minder intensiteit dan scrumsprints? In dit artikel deel ik mijn zoektocht en uitkomst – de 6-weekse cyclus – met je.

Ik heb gewerkt met Scrum, maar voor het gros van m’n carrière zat ik rotsvast in team Kanban. Projectmanagement zag er daarmee als volgt uit: ik stippelde een product-roadmap uit voor 12 maanden en het tech team-pakte daar dan projecten uit om aan te gaan werken.

“Development hell”

Als er een product-idee binnen kwam dat belangrijk leek, zette ik dit vaak bovenaan op onze to-do lijst. En dit werd dan de volgende dag opgepakt door een developer.

Dit, zo dacht ik, is het idee achter agile. Je blijft flexibel en lean ten koste van alles. Als team wil je je focus kunnen verleggen naar hetgeen wat op dat moment de meeste waarde toevoegt aan je organisatie.

En met nieuwe producten werkte dit. We bleven nieuwe functionaliteiten lanceren en het product werd elke week beter. Spontane ideeën konden op de to-do lijst van het kanban-board worden gegooid en werden opgepikt door de ontwikkelaar die er het snelste bij was.

Maar op een gegeven ogenblik liet deze aanpak z’n beperkingen zien. Feature development leek plotseling eindeloos lang te duren. Developers kregen burnout-verschijnselen. En het product verbeterde nauwelijks meer.

Op zoek naar een nieuw raamwerk

Om dit op te lossen begon ik een zoektocht naar een nieuw projectmanagement-raamwerk. We hadden een structuur nodig met zekere begrenzingen die tot meer creativiteit zou leiden. Tegelijkertijd moest deze structuur wendbaar genoeg zijn om snel te kunnen blijven werken. En dit proces moest herhaalbaar zijn gedurende het jaar en passen binnen onze business-tools.

Ik zocht naar iets iets met meer substantie, maar minder intensiteit dan scrumsprints. De gedetailleerde inschattingen van stories en de krappe scrum-sprint tijdsduur van twee weken zijn niet praktisch vanwege de overhead die ze met zich meebrengen. En omdat scrum-sprints te kort zijn om iets zinvols te ontwikkelen, krijg je alsnog dat projecten zich blijven voortslepen voor een onbepaalde tijd. Zij het nu in tijdsvlakken van twee weken.

De oplossing: een 6-weekse cyclus (the six week cycle)

Wat voor mijn bedrijf uiteindelijk de oplossing bleek, was het gebruik maken van een 6-weekse cyclus, gebaseerd op Basecamp’s six week cycle-filosofie.

Het idee hierachter is als volgt. Elke zes weken start je een nieuwe cyclus van projecten die je opdeelt in twee categorieën:

• Big Batch: deze projecten zijn grote projecten of features die meestal de volledige 6 weken nodig gaan hebben om afgerond te kunnen worden.
• Small Batch: deze projecten zijn kleine bug fixes of verbeteringen die ergens tussen een dag en twee weken kosten.

Om je hier een concreter beeld van te geven: dit is een memo waarin ik onze eerste productcyclus aankondigde.

Nadat je een cyclus van zes weken hebt afgerond, is het tijd voor 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. Daarnaast gebruik je deze periode om projecten uit te denken voor de volgende cyclus.

Ik wil hier graag benadrukken dat een cyclus niet hetzelfde is als een sprint. Sprints gaan gepaard met stress en overspannenheid, wat leidt dat mensen uitgeblust zijn en daarmee inefficiënt aan de nieuwe sprint starten. Een cyclus zorgt voor kalmte.

Het plannen voor een cyclus

Op het moment dat een nieuwe cyclus van start gaat, werk je in parallel aan nieuwe product ideeën voor de volgende cyclus.

Net nadat de cyclus is afgerond, is het tijd voor een meeting om pitches voor de volgende cyclus bespreken. Pitches zijn features die tijdens de vorige cyclus zijn ontwikkeld door het productteam. 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. Bij ons waren de teamleden die deelnamen de CTO, een select aantal senior developers en ikzelf. Iedereen heeft voorafgaand aan de meeting de ingeleverde pitches goed bestudeerd, en het doel van de meeting is te bepalen welke pitches ontwikkeld gaan worden tijdens de volgende cyclus.

Binnen de 6 weken blijven

Na jaren van softwareontwikkeling geloof ik dat van bijna elk project een uitstekende ‘zes weken-versie’ te ontwikkelen is. Dit kan alleen als je echt kritisch naar een project durft te kijken: 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.

Dus als je begint met het project, kom je voor geen of weinig verrassingen te staan. Op die manier gaan de 6 weken van de cyclus om implementatie en uitvoering – niet planning.

Neem je ontwikkelaars in bescherming

Om er zeker van te zijn dat je de zes weken niet gaat overschrijden, moet je je tech-team in bescherming nemen.

Dit doe je door nee te zeggen tegen ‘snelle’ verzoekjes van bijvoorbeeld een accountmanager. Als een niet-technisch persoon denkt “dit kan toch niet meer dan 5 minuten werk zijn?”, zie je vaak genoeg dat de werkelijke duur meer in de buurt van 3 uur zit.

En dan zit je nog met de kosten die met task switching gemoeid zijn. Als een developer ineens een ander project moet oppakken, zal dit zijn flow verstoren. Developers versnipperen hun dagen niet in kleine stukken zoals een marketeer of salesmanager dit doet: ze hebben lange aaneengesloten dagdelen van volle concentratie nodig.

De moraal van het verhaal: bescherm altijd je developers’ tijd.

Wat te doen met bugs in de 6-weekse cyclus?

Mensen denken vaak dat een bug een goede reden is projecten stil te leggen en pas weer door te gaan als de bug is opgelost. Maar alle software heeft bugs. Er is niks bijzonders aan.

Bij ons kwam het wel eens voor dat we een bug ontdekten die er al maanden bleek te zitten. De neiging was dan vaak om die bug bovenaan ons to-do lijstje te gooien en deze zo snel mogelijk op te lossen – vooral als het een investeerder was die ons er op wees.

Een betere aanpak is dit: als er een bug wordt gerapporteerd, maak je hier een ticket voor aan. Vervolgens kan het zijn dat een developer hem oppakt tijdens de cool-down. Wordt deze bug niet door een developer opgepakt? Dan kan hij altijd ge-pitched worden voor de aankomende cyclus. Maar de bug zal niet lukraak toegevoegd worden aan de huidige cyclus.

De uitzondering hier is als de bug het product om zeep helpt. Bijvoorbeeld, het zorgt bij een app voor crashes bij een populair telefoontype. In dit geval moet je natuurlijk alle werkzaamheden neerleggen en de bug zo snel mogelijk oplossen.

Dieper in de materie

Natuurlijk is dit onderwerp nog een stuk gedetailleerder te bespreken. Als je hier interesse in hebt, dan kun je Basecamp’s gratis boek Shape Up lezen. Basecamp zet hun methodiek extreem gedetailleerd uiteen.

Ik zou hun boek beschouwen als een buffet. Kies wat voor jouw organisatie van toepassing is en negeer de rest. Als je niet houdt van sushi, eet dan niet de sushi.

Uiteindelijk heeft de 6-weekse cyclus bij ons geleid tot de volgende voordelen:

• Developers werden er gelukkiger van
• De kwaliteit van het product werd beter
• En projecten sleepten zich niet meer eindeloos lang voort

Heb je nog vragen of opmerkingen over de 6-weekse cyclus, of denk je dat jouw team een aanpak heeft die beter werkt? Laat dan hieronder een bericht achter.