Kan dine forventninger påvirke et Scrum-team?

Hos os har vi stor tillid til udviklerne. Så meget at udviklerne selv har ansvaret for en opgave hele vejen fra den startes indtil den er i produktion, og har også ansvaret for opgaven hvis der er problemer i produktion.

Det er udviklerne på opgaven, der bestemmer hvornår der skal deploy'es til produktion, og udviklerne trykker selv på knappen og deploy'er når de mener at kvaliteten er i orden - uden at spørge om lov, det er op til egen vurdering.

Når jeg fortæller om der er mange vantro. "Kan de virkelig det?" - Ja det kan de!

Og de vantro er ved at falde bagover, når jeg så fortæller at otte ud af elleve udviklere lige nu sidder i Ukraine. Så bliver der mumlet noget i skæget om kultur og vi må have et specielt team... Tja, vi har ihvertfald høje forventninger til dem, som bliver indfriet.

Det er fantastisk hvordan forventninger, kombineret med ekstra ansvar, egen bærbar og hjemmearbejdsplads, lige kan presse de 2 ekstra, ikke-fakturerede timer ud af en medarbejder hver dag.

Det er fantastisk hvordan forventninger, kombineret med ekstra ansvar, egen bærbar og hjemmearbejdsplads, lige kan presse de 2 ekstra, ikke-fakturerede timer ud af en medarbejder hver dag.

Jeg er ikke helt sikker på at det var mindet mod mig. Men en ting vi ikke gør, pånær i få tilfælde, er at give udviklerne deadlines. Hvis du vil have det færdigt hurtigt - så reducer scope for opgaven.

Allan, det var overhovedet ikke mindet mod dig.
Ideerne i Scrum er generelt også sunde.
Men har oplevet stand-up møder hvor scrum-master ikke har opfyldt sin rolle. Og så bliver det bare til "nu reddede du jo situationen sidst, så det kan du også lige gøre igen", så sidder udvikleren igen til over midnat fordi der er lavet scope-creep eller tilføjet andre opgaver, som ikke er med i sprintet.

Et af de mest produktivitetsfremmende tiltag i mit team har været, at vi helt har droppet, at udviklerne gætter på estimater på delopgaver. Det er spild af tid, da opgaven erfaringsmæssigt bliver hurtigere færdig ved helt at lade være. "It's done when it's done", groft sagt. På et højere niveau bliver opgaver dog estimeret af hensyn til forretningen, der jo altid gerne vil vide, hvornår en given feature kan forventes i produktion. Det er fair nok. Derfor inddeler vi alle opgaver på story-niveau i XS, S, M osv. Men altså ikke med deadlines med mindre forretningen kræver det. Alt kan jo overrides fra dén kant ...

Vi kører heller ikke med sprints, i øvrigt. Vi har kontinuerligt flow ind i vores svømmebaner. Det er så teamlederens vigtigste opgave: at identificere og prioritere opgaver med forretningen i et passende flow. Det var et problem i begyndelsen, fordi udviklerne lukkede opgaverne meget hurtigere end forventet. Så der opstod en uges tid med manglende opgaver. Vi valgte at tolke det som et positivt problem ... Mødeaktiviteten i forbindelse med faste sprints er for mange udviklere ligeledes spild af tid, da det oftest mere handler om, at diverse ledere skal opnå en god mavefornemmelse, end at udviklerne flytter sig hurtigere. Ulempen ved at køre uden sprints er, at vi selv skal sørge for at lægge passende fejringer af projektsucceser ind ved forskellige pejlinger. :-)

Jeg tror nok, vores model er Kanban/Scrumban-inspireret. Men det interesserer mig ikke så meget. Pointen er, at jo flere forhindringer, du rydder af vejen for dine udviklere, desto højere produktivitet får du. Jo mere strømlinet dit opgaveindtag snurrer, desto højere produktivitet. Surprise! Det lyder banalt, men det er ikke desto mindre svært i praksis, da det netop kræver høj tillid til udviklerne, som Allan også er inde på. Men hvis du ikke stoler på dine udviklere, har du sikkert helt andre problemer, der skal fikses ...

Ja vi har også droppet at estimere. Og burndowns, vi har ikke engang t-shirt sizes. Vi reducere scope i stedet, alt skal kunne leveres på en uge til produktion. Det er utroligt så meget tid vi sparer, ved ikke at lave alt det nedbrydning og estimering. Scrum er mini-vandfald. Nu er det continuous delivery der bliver talt om. B u