“Der er to ting, der kan slå agile ihjel: Kompleksitet og afhængigheder”, hørte jeg engang nogen sige. Man kan sikkert finde mange andre ting, men disse to kan jeg i hvert fald også selv skrive under på!
I disse måneder rådgiver jeg en større dansk virksomhed i Lean-Agile udviklingsmetoder og ledelse forud for udbredelse af den agile arbejdsform til flere projekter, forbedringsopgaver og drift. I foråret tog et pilotteam hul på deres nye agile liv, og de har rykket sig selv og hinanden med ekspressfart. De kom (fra 0, hvad angår agil viden og erfaring), og har siden set og sejret – men netop mange afhængigheder, både til hinanden internt i teamet, til eksterne systemer og projekter har bestemt ikke sparet dem for frustrationer undervejs.
Stort set hver eneste sprint har været præget af grimme overraskelser undervejs, fordi afhængighederne, både de eksterne og de interne, har medført ventetider og blokeret for teamets fremdrift. Nogen gang var teamets medlemmer forhindret i at arbejde videre, fordi de ventede på at deres kolleger blev færdige med deres opgaver (den såkaldte idle time, som vi jagter så nådesløst). I de helt grelle tilfælde var idle time oppe på flere dage. Og når den agile modenhed samtidig er lav, har det ikke været nemt at gennemføre effektive sprint planning sessioner. At de så på trods har tredoblet deres velocity hen over 8-10 sprints er dog et tiltrængt plaster på såret.
De interne afhængigheder skyldes, at de kommer fra en verden, hvor et hav af rollebeskrivelser har fastholdt dem i specifikke, næsten samlebåndsagtige arbejdsforhold, der har medførte, at hver passede sit, og få opgaver er blevet løst på tværs. Dette er en problemstilling, vi ofte støder på, både i Danmark og i udlandet.
Teamet har arbejdet hårdt på at begrænse disse interne afhængigheder, fordi det hurtigt stod klart for dem, at deres respektive specialistroller har stået i vejen for en mere smidig og effektiv krydsfunktionel måde at arbejde på.
I dette forløb har teamet opfundet en simpel teknik, som jeg synes fortjener offentliggørelse, da det måske kan inspirere andre teams til at gøre deres sprint planning bedre og imødegå ligenede problemer med interne afhængigheder.
Teamet selv kalder teknikken for “Sprintsimulering”, og det går i al sin enkelthed ud på at simulere hele sprintet på noget der ligner ½ time som fast afslutning på hver sprint planning.
Altså: Teamet stiller sig op ved sprintboardet og kører hele deres 2-ugers sprint igennem, task for task, for at sikre sig at planen holder vand, og for at udfordre hinanden på hvem der gør hvad. Man kunne sige, at de afholder 10 daily scrum møder i rap med “fast forward” knappen holdt nede.
De skiftes simpelthen til at fortælle hinanden, hvad de afslutter og går i gang med for hver dag, og hvem de har behov for at samarbejde med, og hvem de er afhængige af. Denne gennemgang er naturligvis et “happy day scenario” og forudsætter, at deres estimater holder, men sådan må det jo nødvendigvis være, når man kaster sig ud i at forudsige fremtiden.
På sprintboardet styres simuleringen af nogle virtuelle rækker for hver dag i sprintet, så teamet kan følge den simulerede fremdrift. På billedet kan man se en række opgaver, som er flyttet til TU I, dvs. tirsdag i første uge af sprintet, og to opgaver flyttet til W I, altså onsdag. Efterhånden som simuleringen skrider frem flyttes opgaverne til de resterende dage i sprintet, og som sagt; efter ca. ½ time, er alle sedler (tasks) flyttet i done og sprintsimuleringen afsluttet.
Ifølge teamet selv har denne simulering dette givet:
- Mere præcis timing af opgaverne så teamet ved, hvilke opgaver der skal færdigøres, hvornår og af hvem
- Væsentlig reduktion af den såkaldte idle-tid, fordi teamet identificerer og mitigerer risikoen under simuleringen
- Mere tro på sprint planen, og dermed højere incitament til at nå sprint målet
- Større incitament til samarbejde på tværs, altså mere krydsfunktionalitet
- Bedre indblik i hinandens opgaver og dermed i produktet generelt
Hvis du mener, at denne teknik kunne være værdifuld for det team du arbejder i, eller for teams der arbejder for dig, så prøv det af, og giv meget gerne dine erfaringerne nogle ord med på vejen i kommentarfeltet nedenfor.
