|1 - Mangelfuld backlog refinement
For rigtig mange projekter har produkt backloggen karakter af en uprioriteret ønskeliste af ting forretningen gerne vil have. Mangelfuld refinement er et stort problem i agile projekter, fordi det desværre alt for ofte betyder, at sprints bliver fyldt op med ”elementer”, der ikke er ”klar” til udvikling og sprint teams derved får svært ved, at levere til tiden, inden for budget og i rette kvalitet.
Intet element bør være at finde på et projekts backlog, hvis ikke der findes et klart og entydig svar på: hvad er det, der skal udvikles, hvorfor det skal udvikles, hvordan det bidrager til produktets vision samt hvem eller hvordan, det skaber værdi. Det bør også altid findes et groft estimat på kompleksiteten i det enkelte element, ligesom eventuelle afhængigheder bør være klart defineret.
Formelt set er det produktejer, der er ansvarlig for backloggen, men i mine øjne, bør det altid være en opgave, der involveret hele scrum teamet.
| 2 - Urealistisk estimering
Mange udviklingsteams enten overvurderet hvad, der kan opnås inden for et sprint, eller er for dårlige til at sige fra, når produktejer presser på for at få yderligere funktionalitet presset ind i et sprint.
Typisk går ca. 20% af tiden i et sprint alene til de faste ritualer som fx. Daily standups, sprintplanlægning (est.10%), møder, demoer, sprint retrospective, beskrivelse og dokumentation af løsning mv. Læg hertil ferier/helligdage, udskiftning af medarbejdere mv som betyder, at vi hurtigt kommer tæt på 25% af et sprint som går til overhead mm.
Manglende forståelse for overhead eller evnen til at sige fra overfor produktejer kan have katastrofale for evnen til at lykkedes med at komme i mål med et sprint og bør have særskilt fokus i alle agile projekter.
|3 - Manglende eller for lille buffer
Alle projekter oplever uforudset kompleksitet, tekniske problemer, nedbrud, sygdom, afskedigelser/organisationsændringer, juridiske disputer osv. Uforudsete hændelser udgør en risiko for alle projekter, uanset om de er agile eller ej og bør forsøgt minimeret ved at indlægge en buffer.
Hvor stor ens buffer bør være et en temperamentssag, men min. 20% af den samlede tid/ressourcer er i hvert fald ikke for lidt.
|4 - Relevante ressourcer er ikke tilgængelige eller har for lav allokering
Kender du det? Dit projekt endelig er klar til at gå i gang med en bestemt user story og så er det komplet umuligt at booke en kritisk ressource med kort varsel? Kritiske ressourcer er ofte både få, eftertragtede og dyre at have siddende på udskiftningsbænken. De er ofte delt mellem flere projekter, skal bookes i god tid og er derfor sjældent tilgængelige, når projektet skal bruge dem. Manglende ressourcer kan være dræbende for fremdriften i et projekt men et vilkår i mange organisationer og sjældent noget man kan gøre en masse ved.
Apropos deling af ressourcer. Deling af ressourcer på tværs af projekter er virkeligheden for de fleste projekter. Meget sjældent er ressourcer allokeret 100% til et enkelt projekt. Ressourcer med en lav allokering er ineffektive og har ikke fuld fokus på projektet. Typisk sker der nemlig det, at ressourcer med lav allokering ender med at bruge en uforholdsmæssig stor del af deres tid med overhead, hvilket kun efterlader en begrænset del til udvikling. Eller det modsatte; at de bruger det meste af deres tid på udvikling men er ikke en del af de vigtige ceremonier og koordinationen med de øvrige ressourcer. Sørg for altid at allokere ressourcer min. 30% af deres tid på et projekt.
|5 – Agile principper lever kun i IT
Introduktion af agile principper ændrer fundamentalt set modus operandi, for de dele af virksomheden hvor de implementeres (Typisk i IT-afdelingen).
Problemet, ved at den agile modus operandi kun lever i IT afdelingen er to-fold: Dels skaber det friktion i den daglige fordi de traditionelle siloer ikke er gearet til at supportere og samarbejde med en IT-organisation, der arbejder i sprints, og ikke har tid til ex. at vente 3 måneder på en juridisk udredning af at konkret problem.
Typisk opleves problemerne når IT-projekter er tvunget til at involvere eller samarbejde med medarbejdere (jurister, tekstforfattere osv.) eller samarbejdspartnere med ingen eller begrænset kendskab til principperne, eller når processer, arbejdsmetoder og systemer støder sammen.
En af måderne at takle udfordringen omkring manglende agilitet i de funktionelle siloer kan være at skabe en pool af ”frie” ressourcer der tilflyder projekter efter behov efter den såkaldte ”Flow to Work" model. Er man en mindre organisation, er denne tilgang typisk ikke en mulighed. Her må man af nød nøjes med at forsøge at involvere centrale ressourcer tidligt in processen og samtidig holde dem tæt på processen og kommunikationen, så de gives bedst mulighed for at allokere deres tid til projektet
|6 - Kontrakter med fast defineret leverance/kvalitet
I modsætning til traditionelle vandfaldsprojekter ligger tid og ressourcer i agile projekter fast mens leverancen er variabel; primært fordi den er designet til at kunne håndtere skiftende eller ændrede kundebehov. Det er derfor en udfordring, når der i nogle tilfælde indgås kontrakter med partnere hvor leverancen / kvailtet er låst fast på forhånd. Det efterlader nemlig ikke mulighed for at justere leverance eller kvalitet.
Men blot fordi det er en udfordring betyder der ikke nødvendigvis, at der ikke kan findes en løsning. Løsning i dette tilfælde være en udvidet backlog-planlægning med henblik på at afdække kundebehov og reducere/mitigere de væsentligste risici for at løbe over tid eller bruge for mange penge da dette som bekendt ikke er en mulighed. Paradokset ved dette er imidlertid, at det tager tager tid fra udviklingen.
Et godt råd bør derfor være aldrig at låse leverancen eller kvaliteten fast i en kontrakt med en leverandør, men i stedet at prioritere sin backlog så man øger sandsynligheden for at få det med, der er vigtigst for kunderne.
