I har sikkert prøvet det. En deadline nærmer sig. Chefen vrider hænder mens hun tilbyder ekstra bonus til dem som igen bliver gennem weekenden. Torsdag aften er der desuden lovet ekstra god aftensmad til en lang aften og I forbereder jer på flere lange aftener i fremtiden. Peptalken virker ikke helt på den falmende flamme af lys i øjnene på kollegerne – det er ikke første gang at I bliver bedt om at arbejde ekstra og I er ved at blive lidt tyndslidte ved tanken om den forsømte familie og nattesøvn. Du er gået glip af datterens fodboldtræning mange gange og nu er det det længe ventede weekendstævne der må ofres.
Historien er sat på spidsen, men flere af os har sikkert prøvet at chefen lokker med lækker aftensmads-sushi, hvis vi tager en arbejdsdag til kl. 22 eller måske har du en chef som bare dikterer at sådan er det – uden at lokke?
I it-branchen er der ikke mange steder, der stadig siger de arbejder efter vandfaldsmetoden – de fleste vil sige at de arbejder agilt og mange har valgt at følge Scrum-tankegangen. I Scrum er der så et overset, men dog centralt begreb “sustainable pace“. Egentlig har jeg ikke skænket det mange tanker gennem tiden (heldigvis er det ikke et af vores problemer), men da jeg var på Product Owner-kursus i sidste uge fik jeg øjnene op for, hvor centralt et begreb det er.
Sagen er jo at Scrum er sat i verden for at håndtere uforudsigeligheden af software-udvikling. Som Product Owner ønsker man at kunne kigge på en product backlog og lave en realistisk forudsigelse af hvor meget arbejde vi cirka vil nå til givne tidspunkter. Det vil som regel være indenfor et interval af stories – en rimelig margin.
Og nu til problemet:
Vi arbejder over i to sprints for at indhente en forsinkelse og product owneren (POen) bruger de sidste 3 sprints til at udregne teamets hastighed for at kunne melde til kunden/opad i hierakiet, hvor langt vi når til et givent tidspunkt. En forudsigelse baseret på “yesterday’s weather”, som man ofte siger i scrum-kredse. Hvis vi antager at voldsomt overarbejde rent faktisk kan forbedre vores hastighed (jeg er ikke 100 % overbevist, men siden vi bliver ved med at gøre det, må der jo være en ønsket effekt), så vil POens tilbagemelding til ledelsen være overdrevet positiv allerede efter første sprint. Efter andet sprint er forudsigelsen virkelig overdrevet og tilbagemeldingen bliver at vi sagtens når deadlinen. Der drikkes champagne og underskrives kontrakt på næste projekt med start ugen efter projektets endelige deadline og vi tænker ikke på at håndtere grunden til at vi rent faktisk blev forsinket til at starte med.
Efter 2 sprints med aften og weekendarbejde er der dog ved at blive en del rumlen i teamet. Der er flere sygedage, en enkelt er gået ned med stress, en skal skilles og en har sagt op. Nu skal vi bruge tid på at genopbygge teamet og vores produktivitet går helt i bund. Vi står tilbage med et team som har gjort sit bedste for at levere varen og som bliver belønnet med dårlig stemning, problemer i familielivet og et ødelagt team…. og måske en pengebonus, hvis vi nåede målet.
De positive forudsigelser kan smides helt ud. Vi nåede vores del-deadline, men vi har ofret de næste måneders arbejde på projektet til gengæld. Det tager tid at få healet et team efter sådan en omgang og måske står vi tilbage med et dårligere team bagefter, fordi stor-talenterne havde andre steder, de kunne søge hen og desuden er moralen i bund. Man kan sige at POen burde have vidst at teamet kørte udenfor normal hastighed og derfor burde basere sine forudsigelser på en tidligere fastsat hastighed, men selv det ville ikke være godt nok – når opsigelsen rammer, ryger alle forudsigelser ud med badevandet (medarbejderen). Den positive forudsigelse virker bare ekstra grotesk, når man ved at overarbejde er ved at ødelægge teamet.
En god PO beskytter fremdriften i projektet bedst ved at sige fra overfor en umulig arbejdsbyrde.
Men hvad skulle vi gøre i stedet for at ty til overarbejde? Ifølge Scrum har vi nogle nød-procedurer vi kan benytte allerede første gang vi opdager at et sprint ikke går efter planen.
- Kreativitet. Lad os kigge på om der er en kreativ måde at nå målet hurtigere. Er vi blevet klogere undervejs og kan vi nu se en alternativ løsning?
- Få hjælp. Vi kender alle historien om de 9 kvinder der fødte efter en måned… Nej? Man kan ikke bare sætte flere på opgaven og så forvente at det hele går hurtigere, men det kan være teamet rent faktisk kender til folk, der kan være hjælpsomme. Det kan være et tidligere teammedlem som kender systemet godt og derfor kan gå ind og overtage nogle opgaver, men det kan også være hjælp til at fjerne flaskehalse, såsom testing, code-review, ledelsesproblemer eller hvor man ellers oplever at flaskehalsene er (men man skal sikre sig at teamet så ikke bare bruger sin tid på at delegere).
- Reducer omfanget af opgaven i dette sprint (scope). Vi ved at det ikke er muligt for teamet at nå deres mål indenfor rammen, så vi tager en (synlig og bevidst) beslutning om at tage opgaver ud af sprintet.
- Stop sprintet. Planlæg et nyt realistisk sprint i stedet med den nye viden vi har/de nye vilkår vi har. Brug jeres retrospective til at lære af den fejlede planlægning – og eskaler identificerede problemer til det rigtige sted i hierakiet, hvis problemet ligger udenfor teamet.
Teamet skal beskyttes så vidt muligt, så de kan få arbejdet fra hånden. Når man handler efter nødplanen bliver det tydeligt at der er et problem og i nogle tilfælde også hvor problemet ligger. Det er et “vink-med-en-vognstang” om at projektet potentielt er i fare og man skal korrigere planer efter den nye viden – projektet får på en måde et gult kort, og man ved at der er ting man skal være opmærksom på her.
Kører I et sustainable pace? Hvis ikke, hvilke ulemper/fordele har I oplevet?
Tak for påmindelsen om de fire “nødtræk”.
Din beskrivelse minder mig om det problem med “commitment” jeg ofte har set med uerfarne teams i en ikke så agil organisation:
Udenfor teamet står en projektleder som er meget fokuseret på om teamet nu leverer hvad de har “lovet” så den overordnede plan holder.
Inde i teamet vil de gerne gøre hvad de kan, men føler at ordet “commit” er blevet lagt dem i munden.
Jeg har set denne situation føre til netop de problemer med “sustainable pace” du beskriver. Det egentlige problem var nok at ledelsen ønskede et højere tempo end teamet var modent til at levere (-så man kan sige at ledelsen ikke rigtig havde taget scrum til sig), men det er jeg nok ikke den eneste der har oplevet.
Ja, diskussionen om hvad der er commitment og hvad der er forecasting kan man se mange steder. Den slags fører til en masse dårlig opførsel – f.eks. at man lige ganger med pi i sine estimater, fordi man ved at man committer sig (og ja, fordi udviklere er håbløse optimister kan det være mere nøjagtigt at gange et estimat med pi, men det forhindrer stadig transparant og ærlig kommunikation).
Jeg har også undret mig over, hvorfor man ofte havner der (og jeg er meget enig i betragtningerne om, hvad man skal gøre og ikke gøre, når man først er der). Det er, efter min mening, en kombination:
Langt de fleste af de folk, som jeg har haft fornøjelsen at arbejde sammen med, har været temmeligt hårde til at estimere eget og andres arbejde, men vi har alle været meget dårlige til at forudse opgaverne fulde omfang; og alt hvad der overses i planlægningen er 100% underestimeret.
Og som en af mine kollegaer udstødte med et suk engang: “Hvordan kan det være, at jo mere urealistisk planen bliver, jo mere optimistisk bliver projektlederne?”. Jeg tror det fordi, at jo længere vi komme frem, jo mindre manøvrerum bliver det tilbage, og til sidst er der kun håb, held og overarbejde tilbage.
Men så er vi blevet klogere til næste gang der er planlægges, ikk’?
Estimering er svært!
Det er blevet moderne at bryder opgaverne meget langt ned for netop at fjerne noget af den usikkerhed omkring det fulde omfang… og mindre mulighed for lige at få ekstra dele ind i sprintet med en vag formulering. En stærk PO (og ScrumMaster) er nødvendig, men desværre ser jeg ofte rollen som PO blive nedprioriteret.