Werkwijze developers aangepast: Shape Up

Binnen het Debble Team gaan we starten met een nieuwe werkwijze binnen agile development: Shape Up.

Binnen het Debble Team werken we sinds kort met een nieuwe werkwijze binnen agile development: Shape Up.

De Shape Up-methode beschrijft de specifieke processen die door productontwikkelingsteams worden gebruikt om zinvolle producten vorm te geven, in te zetten en te bouwen. Het geeft teams specifieke technieken om de risico's en onbekende factoren in elke fase van productontwikkeling aan te pakken met het uiteindelijke doel om op tijd een geweldig product te verzenden.

In plaats van elke twee weken een nieuwe sprint te draaien, werken we met een periode van zes weken. In deze periode van zes weken ligt de nadruk op focustijd, die is 4 weken aaneensluitend. Binnen deze focustijd geldt één regel: geen verstoringen en 100% tijd voor productontwikkeling. Daarbij is de tijd fixed en de scope variabel, mét een helder doel waaraan teamleden zich committeren.

De focustijd staat in de afbeelding hieronder beschreven als een Build cycle. Deze heeft 100% focus op één duidelijk doel en eindresultaat. Dat bereiken we door afleidende zaken af te houden, waardoor focus, rust en duidelijkheid ontstaat. De blokken voor Quality time zijn bedoeld voor oplossingen voor verstoringen, kleine aanpassingen op het huidige product, nieuwe installaties en algemeen onderhoud.

Meer focus betekent minder verschillende dingen oppakken waardoor we meer kunnen bereiken. Meer kwaliteit, meer tijd voor dingen die er toe doen en meer ruimte voor (product)innovatie en technische verbeteringen.

Dat betekent ook minder releases, wat inhoudt dat we meer tijd hebben voor iedere release. Hiermee kunnen we kijken naar verbeteringen met meer impact. Dat betekent ook dat we de releases opdelen in:

• Minor release: bevat kleine aanpassingen op het huidige product, oplossingen voor verstoringen en algemeen onderhoud. Minor releases komen voort uit de Quality time.
• Major release: bevat nieuwe functionaliteiten of doorontwikkelingen daarvan. Deze komen voort uit een Build cycle en worden via onze release ringen uitgerold.

Zoals in de afbeelding hierboven is te zien, is het team onderverdeel in twee development teams. Op die manier kunnen we de snelheid in het oppakken van eventuele verstoringen hoog genoeg houden. Uiteraard worden verstoringen van een prio 1 of 2 altijd opgepakt, ook al beide teams in een Build cycle zitten.

Het eerste team is begin deze sprint gestart met een eerste build cycle. Daarover later meer via de relase notes!