Van kanban tot scrum: kies voor onze agile-methode

Waarom het Micros Scale-team van Atlassian is overgestapt van kanban naar scrum

Nelly Sattari Door Nelly Sattari
Onderwerpen zoeken

Om een gezond engineeringteam te kunnen zijn, moet het team zichzelf kunnen organiseren! Het is een team met duidelijke rollen en verantwoordelijkheden dat zich inzet om projectresultaten te behalen met behulp van een goed doordacht plan.

Vorig jaar hebben we een nieuw team opgericht, genaamd Micros Scale, dat zich richt op het ontwikkelen van het interne Platform-as-a-Service (PaaS) van Atlassian, ons ervaringsplatform voor ontwikkelaars. Omdat ons werk een vaste scope en duidelijke tijdlijnen heeft, richten we ons meer op het voltooien van incrementeel werk en zijn we meer gefocust, doelgericht en proactief.

Voorheen kreeg ons team echter veel incidenteel operationeel werk waardoor we sprints niet goed konden plannen. Er werd van wel minimaal 55 procent van de teamcapaciteit gebruik gemaakt voor de Keep-The-Lights-On (KTLO)-roulaties. Daardoor was kanban op dat moment de meest geschikte methode voor ons.

Een belangrijk feit is dat het Micros Scale-team, volgens het Tuckman-model in de fase Forming zat en dat er een aantal verbeterpunten waren, zoals het plannen van de capaciteit, het plannen van sprints, het stellen van doelen, teamreflecties, het wegwerken van taken, het uitbreiden van story’s, het maken van schattingen, het maken van projectoverzichten, enzovoort.

afbeelding van het Tuckman-model

Welke agile methode was geschikt voor ons?

Micros Scale heeft twee grote projecten die zeer complex zijn en waarvoor een deadline openbaar bekend is gemaakt voor onze klanten. Dat betekent dat sneller leveren van cruciaal belang is. We wilden kunnen vertrouwen op onze leveringsmethode en aan onze planning werken als een echte agile pro. We wilden een zelforganiserend team creëren, gemeenschappelijke doelen bereiken en empirisch zijn.

We hebben onze agile aanpak opnieuw beoordeeld door de volgende vragen te stellen:

  • Is het mogelijk om voor elke iteratie een doel te stellen om een doelstelling te behalen met een uniek thema?
  • Kunnen we gedurende één of twee weken werken aan de scope van te leveren producten?
  • Kunnen we de vereisten waaraan we moeten werken uitbreiden en vastleggen?
  • Is de frequentie van incidentele aanvragen om takenprioriteiten te veranderen laag en is de kans dat er ingrijpende veranderingen optreden voor ons kleiner?
  • Is ons team nieuw en heeft het zich nog niet ver ontwikkeld op het gebied van agile processen?


Omdat onze antwoorden op deze vragen ‘ja’ waren, realiseerden we ons dat scrum de meest geschikte agile methode was voor ons team. De volgende informatie heeft verder bijgedragen aan de overweging van onze beslissing:

 

 

 

 

Agile methodologie

Waar gaat het over?

Helpt het ons?

Waarom?

Scrum

Bij scrum staan een duidelijke roadmap en werkonderdelen waaraan prioriteiten zijn gesteld centraal, terwijl het visualiseren van je werk, dat incidenteel aan het team wordt overgedragen, bij kanban centraal staat.

Ja

We hebben een duidelijke en vooraf gedefinieerde backlog die moet worden verfijnd en waarvoor prioriteiten moeten worden gesteld. Ons werk is voorspelbaar, in tegenstelling tot ons vorige team, dat voor veel verassingen kwam te staan en aanvragen met hoge prioriteit ontving.

Story’s zouden niet midden in de sprint moeten worden veranderd.

Ja

We kunnen een flexibelere aanpak kiezen, en in dit geval is dat scrumban (een combinatie van scrum en kanban).

Scrum is eenvoudiger te implementeren voor agile teams die functie-leiden nog aan het leren zijn. Scrum is meer voorschrijvend, met rituelen en tijdvakken die als vangrails dienen.

Ja

We hebben een nieuw team met nieuwe leden, dat nog in de fase Forming-Storming zit, dus met behulp van scrum kunnen we ons verder ontwikkelen. Bekijk het Tuckman-model.

kanban

Het werk in uitvoering beperken en concentreren op het verminderen van de projectcyclustijd. Het gebruiksscenario is wanneer je team geen tijdslimiet en vastgelegde tijdlijn heeft voor werk. De aanvraag wordt ingediend bij het team en wordt zo snel mogelijk afgehandeld (zoals een SLA waar servicedeskteams mee werken).

Nee

Andere teams zijn afhankelijk van ons, en daarom hebben we geschatte tijdlijnen nodig waarmee anderen rekening kunnen houden in de planning. Sommige van onze verplichtingen worden openbaar bekend gemaakt aan klanten van Atlassian, en daarom moeten we met hen rekening houden in de planning. We hebben weinig aanvragen die snel behandeld moeten worden, zoals bij een servicedesk.

Perfect voor teams die veel inkomende operationele aanvragen hebben die variëren in prioriteit en grootte.

Ja

We hebben geen zware KTLO-last en de werkstroom wordt beheerd door de rol van één persoon in het team op basis van roulatie. We kunnen die gekozen rol als kanban uitvoeren als we dat willen.

We hebben scrum geïmplementeerd

Ik ben me er volledig van bewust dat het aannemen van de rol als leider één van de belangrijkste kenmerken is van engineeringmanagers, naast de rollen als verbindingspersoon, kompas en coach. Daarom moest ik constant mijn spieren als leider opbouwen. Dit is hoe ik dit doel heb bereikt:

Meer informatie over agile werkwijzen

De interne leerbronnen van Atlassian hebben me geholpen mijn vaardigheden op het gebied van agile werkwijzen verder te ontwikkelen. Ik heb uitgebreide cursussen over de agile-methode gevolgd en een agile coach geraadpleegd. Ik heb een aantal engineeringmanagers van andere organisaties en teams geïnterviewd om meer te leren over hun ervaringen.

DACI gebruiken

Het DACI-besluitvormingsframework, waarin DACI staat voor Driver (aanjager), Approver (goedkeurder), Contributor (bijdrager) en Informed (geinformeerde), is gebruikt om effectieve en efficiënte groepsbeslissingen te maken. Ik heb het DACI-veranderingsvoorstel met mijn team doorgenomen om ervoor te zorgen dat ik hun opmerkingen, toestemming en ondersteuning had.

Gebruik een sprintsjabloon

Ik heb een proces bedacht om onze sprints te beheren en een sjabloon aangemaakt voor elke sprint om meer realistische planningen te kunnen maken. Het sprintplanningssjabloon bevatte het volgende:

  • Hoe de vorige sprint kan worden beoordeeld, zodat het duidelijk is wat we bereikt hebben en deze resultaten kunnen vieren.
  • Hoe we met terug kunnen kijken en kunnen reflecteren op de vorige sprint en onze kennis kunnen toepassen op de volgende sprint.
  • Wat is de cadans en de naam en wat zijn de doelen en doelstellingen van de sprint?
  • Hoeveel story’s willen we gaan leveren? Wat is de sprint-scope?
  • Hoe je capaciteit inplant op basis van de beschikbaarheid van werknemers.
  • Welke activiteiten tijdens de sprint hebben we nodig om volledig voorbereid te zijn op de volgende sprint?
  • Hoe je story’s schrijft, de vereisten uitwerkt en een oplossing vaststelt om resultaten te behalen.
  • Hoe je de status van geplande story’s bijhoudt en wat je kunt doen met onvoltooide story’s.

Daarnaast hebben we een goede tutorial over hoe je sprints uitvoert in Jira Software.

De overstap naar scrum was de moeite waard

We hebben de volgende verbeteringen aangebracht door over te schakelen op scrum:

Verbetering van de snelheid

In de agile-methode is één van de factoren om de productiviteit van een team te meten de snelheid, wat de gemiddelde hoeveelheid werk is die een scrumteam tijdens een sprint voltooit. We gebruiken een snelheidsgrafiek om te begrijpen wat het geplande werk was voor het team en wat er werd geleverd. In de snelheidsgrafiek hieronder bevat de grijze kolom het aantal storypoints dat het team heeft gepland op basis van hun capaciteit. We vergelijken het met de blauwe kolom, die het aantal storypoints bevat dat ze daadwerkelijk hebben geleverd. Het team kan deze gegevens vervolgens gebruiken om voorspellingen voor toekomstige sprints aan te passen.

Snelheidsgrafiek

Identificeert risico’s vroeg

Het vroegtijdig vaststellen van risico’s en een mogelijke oplossing bedenken is van cruciaal belang voor het succes van projecten.

Door de doelen en thema’s van sprints vast te stellen, hebben we samenhangende story’s kunnen kiezen om doelen te bereiken. Tijdens de sessies halverwege de sprint heeft ons team de story’s weggewerkt, verfijnd en uitgebreid. Tijdens de uitwerking stelden we de volgende vragen:

  • Wat moet er gebeuren?
  • Waarom voeren we dit werk uit?
  • Welke bedrijfswaarde voegt het toe?

Hierdoor konden onze engineers afhankelijkheden vaststellen en tickets met een grotere impact prioriteren om problemen op te lossen. Daarnaast hebben we hierdoor onze werkwijze veranderd en hebben we een betere teamfocus per project.

Dit mag gevierd worden! We hebben geleverd

Het plannen van de capaciteit en het stellen van doelen gaven ons zinvolle motivatie en de uitdaging om transparant te zijn over onze plannen. We hebben met succes één fase van cruciaal belang van Atlassian PaaS Account Sharding uitgevoerd. Daarnaast staan we op het punt om de eerste fase van ons gegevenslocatieproject uit te voeren om meer AWS-regio’s te kunnen behandelen met betrouwbaarheid, veerkracht en naleving van de regelgeving als doel.

De transitie van Forming naar Norming

Zoals ik hierboven heb vermeld, is het Micros Scale-team relatief nieuw en bevindt het zich volgens het Tuckman-model meestal in de fase Forming.

Het definiëren van een gezamenlijk doel voor het team zorgde ervoor dat iedereen op één lijn kwam, stimuleerde teamleden om elkaar te ondersteunen om teamdoelen te behalen en versterkte de teammotivatie. We hebben fouten gemaakt, gereflecteerd, geleerd en verbeteringen gemaakt. Na drieënhalve maand namen we 50 procent meer werknemers in dienst voor Micros Scale, en ik definieer het team nog steeds vol trots als een Norming-team.

Verbeterde communicatie

Door een plan te hebben opgesteld en toegewijd te zijn tijdens elke sprint, is de zichtbaarheid van welk werk gepland was voor het hele team verbeterd en waren we op elkaar afgestemd. Het is veel gemakkelijker voor engineeringmanagers en belanghebbenden om de belemmeringen en de voortgang van projecten bij te houden.

Hoe je je agile methodologie kiest

  1. Aarzel niet om je processen te controleren als je een probleem ziet. Denk op agile wijze: personen, processen en tools.
  2. Evalueer het project en de verantwoordelijkheden van je team om de beste agile methode te vinden die bij je team past. Bekijk onze Kanban-versus-scrum-pagina voor meer informatie over deze methoden.
  3. Als je besluit over te stappen op scrum, raad ik je aan om een Jira-scrumbord te gebruiken of een sjabloon aan te maken met Confluence of je favoriete tool.

Maak voor elke sprint een sprintplanningspagina aan om de meest recente sprint te bekijken en op deze te reflecteren en om de volgende sprint te plannen op basis van de capaciteit van het team en het sprintdoel. Dit is mijn persoonlijke Confluence-sjabloon:

Afbeelding van een sprintplanningssjabloon

Dit is mijn capaciteitplanningssjabloon dat onderdeel is van mijn algemene scrum-sjabloon:

scrum-beschikbaarheden

Daarnaast zijn deze mijn sprintdoelstellingen en is dit mijn scope-sjabloon:

afbeelding van een sprintdoel

Het is halverwege de sprint handig om een andere pagina te hebben aangemaakt om bij te houden hoe het team de afgelopen week heeft gepresteerd, welke story’s we moeten meenemen naar de volgende sprint door te kijken naar de huidige voortgang van de sprint (wat wegwerken wordt genoemd) en story’s die je hebt weggewerkt verder uit te breiden (story-verfijning). Dit is mijn backlog-grooming- en verfijningssjabloon voor halverwege de sprint:

Backlogs wegwerken

Elk team is anders, en wat voor ons geschikt was, is mogelijk niet geschikt voor andere teams. Scrum, kanban of een combinatie van beide, zoals scrumban en kanplan, is mogelijk een betere methode. Het is van cruciaal belang om de specifieke behoeften van je team te evalueren en inzicht te krijgen in welke methodologie bij hen past.