Endringer i Scrum
Vel, endringer er kanskje å ta hardt i – presiseringer er nok et bedre uttrykk. Herrene Jeff Sutherland og Ken Schwaber har i hvert fall funnet det riktig å lage en ny versjon av Scrum Guiden. Her kommer en liten oppsummering av det som er gjort:
1. Gjennomsiktighet (transparency) har alltid vært viktig, men dette er ytterligere understreket ved et nytt kapittel kalt Artifact Transparency. Om ikke alle artifaktene er tilstrekkelig forståelige og tilgjengelige for alle interessenter vil vi risikere at noen tar dårlige beslutninger.
2. Sprintplanlegging er ikke lenger todelt og det tidligere noe diffuse Sprint Goal har blitt tydeligere og fått større betydning. Egentlig ikke noe nytt her, bortsett fra at dette ikke lenger er 2 etterfølgende time-boxer, pluss at det tydeliggjøres at det er en stor fordel for fokus (som jo er viktig) og for gjennomsiktigheten at hver sprint har en samlende, klar målsetning.
3. Scrumguiden har som Scrum Alliance´Core Scrum tatt i bruk Refinement i stedet for Grooming om det kontinuerlige Product Backlog arbeidet som må gjøres. De tar også til orde for å sette en egen tilstand kalt Ready på Produktkøen, tilsvarende Done som er tilstanden på et produktinkrement.
4. Bruk av tidsbokser: En Sprint er en tidsboks av absolutt lengde, mens de andre aktivitetene i Scrum som også har en tidsangivelse skal tolkes som en maksimal lengde. Om man for eksempel har gjort grundig Produktkøraffinering (og har en streng definisjon av Ready) vil kanskje behovet for å bruke opp tidsboksen for Sprintplanlegging ikke være tilstede.
5. Viktigheten av å bruke de daglige Scrummøtene til planlegging og ikke rapportering blir understreket. Dette er først og fremst fordi erfaring har vist at dette er en vanlig feil mange gjør, noe som nok er et tegn på at gamle uvaner henger igjen. Det tas til orde for å knytte dette møtet sterkere til Sprint målet, og ikke bare være fokusert på detaljer.
6. Til slutt blir det understreket at Sprintreviewet må brukes for å optimalisere verdi, og ikke bare fokusere på hva som ble levert.
Jeff og Ken forklarer utviklingen i denne videoen
Den nye versjonen vil foreligge på norsk – en eller annen gang… Frivillige kan gjerne melde seg:)
In: Scrum · Tagged with: Scrum
Tillit og slakk
Skal du innføre smidig systemutvikling må det organisasjonsendringer til. Alltid. Hvilke endringer kommer selvsagt an på utgangspunktet. Og på ambisjonsnivået.
Jeg er kanskje urealistisk og veldig utålmodig av meg, men jeg kan ikke fri meg for å tenke: “hvorfor må det ta så lang tid?” og “hvorfor er det så mange som mislykkes?” Svaret ligger vel i at organisasjonsendringer nødvendigvis må ta kalendertid, at det koster innsats som må veies opp mot annen innsats, at det vil møte motstand og at det vil skape en viss utrygghet. Dessuten er mange aktuelle organisasjoner skrudd sammen på en slik måte at de vil motsette seg endring. Man kan si at mye innenfor tradisjonell ledelse er optimalisert for å opprettholde status quo.
John Kotter sier mye klokt om hvordan å lykkes med endringsledelse og at framtidens organisasjoner trenger “leadership” og ikke bare “management”. Leadership er altså å peke ut retningen, kommunisere og motivere og ellers skape et system som er dynamisk og endringsvennlig. Man trenger både leadership og management, men Kotter sitt poeng (som også sammefaller godt med Gary Hamel og Steven Denning) er at “management” fremdeles regjerer og at svært få organisasjoner reelt sett er styrt av “leadership”.
OK, så til poenget med denne posten. For å lykkes med endring er det to ingredienser som må være på plass: Tillit og slakk.
Tillit
Når jeg snakker med organisasjoner, har jeg i praksis formelle og uformelle møter med enkeltpersoner og grupper. Disse møtene kan være en prat ved kaffemaskinen, lunsj, coachesamtaler, intervjuer, kurs og workshops. Etter noen slike møter reflekterer jeg gjerne over inntrykket: Er dette et sted med høyt tillitsnivå, eller ikke. Det første tegnet på lav tillit er at jeg får en annen historie på tomannshånd, enn jeg får i grupper. Det er tydelig at folk ikke er helt åpne i plenum, selv om de har meninger om at ikke alt er helt bra. Enkelte ganger (men ikke alltid) er dette knyttet til en spesiell person (selvfølgelig en sjef) som signaliserer at han helst ikke vil ha negativitet eller konflikter.
I boka The Five Dysfunctions of a Team forteller Patrick Lencioni at tillit har vi om folk 
viser sitt sanne jeg – evnen til å innrømme feil og svakheter. Det å våge å være sårbar. Dette gir den nødvendige tryggheten vi trenger for å ta opp ubehagelige ting. I boka argumenterer Lencioni godt for at mangel på tillit er den mest fundamentale feilen i mange organisasjoner, en dysfunksjon som vil komme i veien for evnen til å ta tak i problemer, grad av forpliktelse, grad av pålitelighet og til slutt evnen til å fokusere på resultater. I modellen ser vi at Trust er selve fundamentet for å få resultater.
Hva om man forsøker å sette i gang en storstilet endringsprosess, uten at tilliten er på plass? Organisasjonsendringer er noe av det vanskeligste man kan gjøre, og det vil utfordre eksisterende roller, posisjoner og maktstrukturer. Og det vil skape utrygghet. Dette krever virkelig lederskap! Og all erfaring viser at man må involvere de ansatte. Alle roller og nivåer må bidra. Og her er det viktig med en presisering: At de ansatte må involveres og bidra er noen alle snakker om i slike prosesser. Men ekte tillitsfull involvering gjør man fordi alle de ansatte faktisk har noe å bidra med. Det er ingen fastisvar eller noen ferdig modell for hvordan en organisasjon skal se ut og styres. Spørsmålet vi da bør spørre oss er “Hvordan kan vi sikre at de ansatte ser på dette som en mulighet og ikke en trusel og faktisk engasjerer seg i å skape en bedre orgaisasjon og en bedre arbeidsplass?” Skal vi få til dette må vi hilse høylydte diskusjoner og engasjement velkommen. Først da får vi løsninger med den grad av forpliktelse som vi faktisk trenger. Og vi vil høyst sannsynlig få bedre løsninger!
OK, så hvordan adresserer vi denne manglende tilliten? Er det i det hele tatt mulig å reversere en organisasjon som har vært mistillitsbasert i tiår? (Det er selvsagt ingen leder som vil si at man baserer seg på mistillit, men i praksis er dette slik det fungerer overalt i offentlig sektor og i de fleste vel etablerte private. De ansatte blir systematisk overprøvd og styrt av regelverk, prosedyrer, KPI-er og milepælsplaner, og det er små muligheter til å utøve et faglig skjønn som bryter med regler). Vel, dette er et kjærnepunkt tror jeg. Med tillit følger ansvar og en eksponering man ikke er vant med. Mange vil føle at dette ansvaret er skummelt og denne åpenheten invaderende og konfliktene blir kanskje ikke riktig så saksorienterte som vi skulle ønske. Så dette må addresseres aktivt, for saken er jo den at i det øyeblikket vi har tillit til hverandre har vi også en helt annen trygghet.
Vi adresserer tillit når vi coacher Scrum-team som skal i gang. Vi kaller dette gjerne team start-up. Det vi gjør her er jo egentlig ren team-building, som skal sikre at teammedlemmene blir kjent, får et felles mål og er enige i hvordan de skal jobbe sammen. Om vi vil fokusere på tillit er det mange ulike teknikker man kan bruke. Jeg var på “Culture Fitness Training” i Berlin med Olaf Lewitz her i juli. To dager med fokus på firmakultur – og vi endte opp med å fokusere en hel del på tillit og relaterte tema; Non-violent communication, The Core Protocols, Lego Strategic Play og Temenos med Influence Maps er alle metoder som er egnet til å få teammedlemmer til å åpne seg opp, forstå hverandre bedre og derigjennom å øve på tillit.
Det kraftigste virkemiddelet for å øke nivået av tillit i en organisasjon tror jeg er å systematisk og åpent å evaluere resultatene av arbeidet som gjøres. Særlig når noe går galt er det viktig å diskutere hva som skjedde og hva som kan gjøres for å unngå å gjenta dette. Om man klarer å gjøre dette konstruktivt, uten å fokusere på person og skyld, vil man ha tatt et stort skritt i riktig retning. Det beste en leder kan gjøre for å øke organisasjonens tillitsnivå tror jeg er å gå foran og bekjenne sine feil. Når en leder eksponerer sine feil og svake sider og våger å invitere til diskusjon rundt feilen, vil man effektivt ufarliggjøre det å feile, og de ansatte vil gradvis våge å gjøre det samme.
Slakk
“Dette var ikke bra, det må vi gjøre noe med!”
“Ja, her må vi finne ut hva som egentlig skjedde!”
“Enig, dette må vi for all del unngå at skjer igjen!”
Slike utsagn borger for at man ønsker å trekke erfaring ut av ting som går galt og gjøre de nødvendige endringene som skal til for å bli bedre. Problemet er at slike utsagn ofte ledsages av et lite
“… men først må vi fullføre dette viktige prosjektet”
Alle tradisjonelle organisasjoner jeg vet om er besatt av tanken på at alle til enhver tid skal være 100% belagt. Og særlig de som er involvert i det aller viktigste prosjektet – de skal gjærne være 120% belagt. Denne situasjonen er svært dårlig egnet for læring, forbedring og endring. Det langsiktige taper hele tiden kampen mot det kortsiktige.
Denne tankegangen gjelder også på porteføljenivå. Man forplikter seg til store batcher av arbeid og ender opp med et stort antall køer rundt om i systemet. Disse køene skal administreres og prioriteres og vil i praksis gjøre det svært vanskelig å få innsyn i hva som egentlig er situasjonen på et gitt tidspunkt. Så på organisasjonsnivå vil denne besettelsen etter å til enhver tid ha mer enn nok å gjøre gjøre det bortimot umulig å gjøre årsaksanalyser og virkelig lære noe når ting går galt.
Tom DeMarco har skrevet en rekke bøker, blant annet om det å utvikle programvare på enbest mulig måte. Boka Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency. Han hevder her at det aller mest effektive er å bevilge seg litt “dødtid” og ikke til enhver tid være fullt belagt. Dette er ikke helt intuitivt selvsagt, men om man er i en kunnskapsintensiv bransje har han utvilsomt rett.
DeMarco: Slack is the degree of freedom in a company that allows it to change
De aller fleste “moderne” organisasjoner (selv i bank og finans og i offentlig sektor) har et mål om å være tilpasningsdyktige når markedet krever dette. For å lykkes med dette er det helt nødvendig å ha tid og krefter til refleksjon. All endring har to hovedkomponenter:
1. finn ut hva som behøver å endres (evaluering)
2. iverksett endring
Begge disse to tingene vil ta tid og koste krefter, og særlig nummer 2 er det helt vanlig å undervuredere.
(Bemerk: Enkelte vil sikkert her reagere på at jeg overforenkler litt. Det er vel Deming/Shewhart´s Plan-Do-Check-Act som gjelder her? Joda, men i denne sammenhengen mener jeg forenklingen er forsvarlig.)
Har slakk noe med tillit å gjøre?
Ja, jeg mener bestemt det. Sett at en ledelse kjøper argumentene om at å innføre slakk er en nødvendighet for å være effektive på sikt. De er med på dette rent intellektuelt. Men om de har å gjøre med en organisasjon med lavt tillitsnivå spørs det om de vil våge å stole på at de ansatte ville bruke denne nyvunne “dødtiden” til firmaets beste. Jeg tror denne tvilen er høyst berettiget. Om de ansatte ikke er vant til å få ansvar og tillit, vil de ikke automatisk bruke slakken fornuftig. De ansatte må vennes til at de har reell inflytelse på egen arbeidssituasjon og at det er greit å feile.
In: ansvar, ledelse, systems thinking, Tillit · Tagged with: Ansvarliggjøring, endringsledelse, ledelse, organisasjon, systems thinking
Om teknisk gjeld
Core Group fikk nylig en interessant artikkel om IT-systemenes tekniske gjeld inn i Finansavisen kalt “Norges ukjente gjeldsberg“. På høy tid at blårussen får en vekker her! En god artikkel som oppsummerer problemet helt fint, men (selvsagt) litt tabloid.
Dette problemet er jo helt trivielt og grunnleggende; Det er mulig å spare tid å penger ved å gjøre dårlig håndtverk. På en eller annen måte vil dette hastverksarbeidet føre til kostnader senere en gang. Mitt favoritteksempel går på utvendig husmaling: Du skal skrape godt, vaske huset, det skal tørke, du skal ha på soppdreper, før to lag maling påføres. Når jeg skulle sette bort dette arbeidet hadde ikke de med det laveste tilbudet (6000 kr) tenkt å gjøre annet enn å kline på maling. Dette ville sett helt fint ut i et par år, men så ville det vært nødvendig med en ny runde og nye kostnader.
Akkurat som for husmaling vet vi i dag mye om hva som er “godt håndtverk” i programvareutvikling, men det selvsagt langt mer komplekst og rom for langt flere nyanser. Den beste referanser er nok fremdeles boka til Uncle Bob kalt Clean Code. Ren kode er omtrent som i et profesjonelt kjøkken. En fredag kveld på en stor, god restaurant vil kjøkkene syde av aktivitet og for en utenforstående vil det fortone seg fullstendig kaotisk. Men studerer man det hele kan man finne ut at det råder en fantastisk orden og disiplin og at alle kokkene tar seg tid til å vaske benker, skylle kniver og ikke minst sørge for at all redskapen er å finne på sin faste plass. Dette “ekstraarbeidet” er helt nødvendig for å klare å være effektive i en kompleks setting! På samme måte sørger de beste programmererne og teamene for at koden de etterlater seg til enhver tid er vel strukturert, følger logiske navnekonvensjoner, er kommentert og ikke minst inneholder tester. Test Driven Development synes å ha etablert seg som en “best practice” i store deler av programvarebransjen. Man gjør rutinemessig re-factoring og code reviews.
Så spørsmålet blir da selvsagt: “Når vi har denne kunnskapen, hvorfor skjer det da ikke?” Vi har berørt dette temaet mange ganger som for eksempel her, her og her. Dan Vigeland kommenterer det i artikkelen i Finansavisen, men berører ikke alle aspektene.
Teknisk gjeld er økte endringskostnader
Vi må akseptere at etter hvert som IT-systemene utvikles vil det koste noe mer å gjøre en endring (Cost of Change – CoC). Denne utvik
lingen er nærmest lineær og fullt ut håndterbar, om man hele tiden sørger for å systemet er velstrukturet, lettfattelig og inneholder automatiske tester, mao det som ansees som “godt håndtverk”.
Det er når man ikke tar seg tid til å gjøre det gode håndtverket at endringskostnadene skyter i været. Dette blir fort en ikke-lineær kurve – om endringskostnadene øker kan man regne det som sikkert at man ikke klarer å holde det man lover og tidspresset blir enda større enn tidligere; “Man har det gående”.
Årsaker til at vi bygger opp teknisk gjeld
Utviklerne bryr seg ikke. Det er desverre slik at mange utviklere og testere fremdeles ikke har særlig sterkt eierskap til produktet de lager. De er ikke med på å utforme kravene og de er heller ikke informert om visjonen – selve hensikten med jobben de gjør. De blir styrt av prosjektledere som forteller dem hva de skal gjøre. De blir målt etter KPI-er som ikke adresserer sluttproduktet. Og de får omtrent ikke reell feedback på jobben de gjør. De er ferdig med jobben når ting er utviklet, etter dette er det driftsavdelingen som “eier problemet”.
Om ikke utviklerne bryr seg, vil de – selv om de har kunnskap om “Clean Code” – gi opp å argumentere for å jobbe saktere en stund for å rydde opp i spaghettikoden. De venner seg fort til at “tid er det som betyr noe her”.
Forretningssiden / kunden undervurderer problemet. Dette dreier seg selvsagt om (mangel på) kunnskap hos de som sitter med styringen. Når jeg skulle ha huset mitt malt – og skulle velge leverandør og pris – forsto jeg fort at det var lurt å sette meg inn i hva som et godt håndtverk, slik at jeg unngikk å bli sittende med et stort problem om noen få år. Jeg forsto at jeg kunne velge mellom billigløsningen (6000 kroner og null forarbeid) og “Rolls Royce” (60.000 kroner der alle malerne hadde erfaring og fagbrev). Jeg valgte noe i mellom, men forvisset meg om at de skulle følge alle prosedyrene. På samme måte må de som definerer kravene og forplikter leveranser ha en viss grunnleggende forståelse for programvareutviklingens særegenheter og ikke minst konsekvensene av å “kutte hjørner”.
Vi har her et vanskelig og grunnleggende problem. Hvor høy rente har egentlig denne gjelda? Er det mulig å si noe generelt om dette? Det er ekte vanskelig å måle “vedlikeholdsvennligheten” til systemer. Når da tilliten mellom IT-avdelingen og forretningssiden (som vanlig) er frynsete, hjelper det ikke så mye om utviklerne eller de på drift roper høyt. “Det kan da umulig være så ille, de bare misliker å bli presset på tid!”
De som har makt blir målt kortsiktig. Jeg har jobbet tett med mange organisasjoner og blir stadig overrasket over at selv om “alle” forstår teknisk gjeld så går de fremdeles i fella! Kall det gjerne “luksusfellen”. Man forstår det innerst inne, men som vi ser på TV3 evner vi ikke å ta det inn over oss. Det kan være ulike grunner til at vi havner der, men hodesakelig kommer det nok av at de som bestemmer ikke kommer seg ut av gamle tankemønstere og strukturer.
Noen steder er det salg som er for dominerende. De styres tradisjonelt med provisjoner og de lover rutinemessig litt mer enn de kan stå inne for. Hele organisasjonen kommer “på hæla” og man venner seg til at man må ofre det gode håndtverket på tidspressets alter. Andre steder er ikke salgsdrevet, men snarere budsjettdrevet. I forbindelse med budsjettering eller anbud “selger” interessentene/leverandørene inn ideene og planene sine og i denne prosessen faller man for fristelsen til å “bråestimere” omfang og å låse en løsning. Deretter blir oppgaven å forsøke å holde det man på sviktende grunnlag har lovet. Prosjektets deadline blir styrende og når dette punktet nærmer seg blir alt annet enn framdrift lett ofret. Det tragiske er at i dette scenarioet kan Prosjektet være en suksess, målt på sluttermin. Men om man måler vedlikeholdsvennligheten til dette systemet et år etterpå vil svaret ofte være noe annet – den tekniske gjelda er stor. Det burde være unødvendig å påpeke at dagbøter i forbindelse med IT-kontrakter er selve oppskriften på å pådra seg teknisk gjeld.
Hva kan vi gjøre?
Teknisk gjeld adresseres implisitt på veldig mange måter gjennom Smidig programvareutvikling. For det første kan vi benytte omfang (scope) som variabel når vi styrer mot en tidsfrist. Jeg har beskrevet hvordan her. Ved å betrakte omfanget som åpent, der vi forplikter oss til løsning og funksjonalitet i “siste ansvarlige tidspunkt” synliggjør vi framdriften på en helt annen måte og får fokus vekk fra tid.
Vi kan gi utviklerne langt større myndighet og ikke minst ansvar for selve produktet, slik at de virkelig begynner å bry seg. De kan også eie visjonen og kravene – sammen med forretningssiden.
Forretningssiden/kunden og IT-siden må forstå – og respektere – hverandre bedre. De må rett og slett jobbe langt tettere sammen, slik man gjør i Scrum (om man følger “boka”).
Unngå de store “big-bang” leveransene – om man leverer i små inkrementer vil også kvalitetene bli satt på prøve tidligere og utviklerne få feedback på den jobben de gjør. Dette er uslåelig om man ønsker å lære – og det er vel det dette til syvende og sist dreier seg om.
In: Kvalitet · Tagged with: kompleksitet, Kvalitet, ledelse
Den aller viktigste faktoren…
Jeg har diskutert “kvalitet” i det siste, blant annet på Sikkerhet og kvalitet i din utviklingsprosess hos DnD i Bergen. Hva er det som fører til produkter med ypperste kvalitet?
Jeg tenker ikke her å definere kvalitet, i denne sammenhengen 
holder det lenge med ordet slik vi bruker det i dagligtale. Når jeg holder kurs og foredrag åpner jeg gjerne med å spørre deltagerne om hvilken ene faktor som betyr mest for å ende opp med høy kvalitet på produktene. Svarene jeg får er gjerne slikt som:
- Godt håndtverk
- Tett samarbeid med brukerne
- God nok tid til å gjøre jobben skikkelig
- Gode testere
- Flinke folk
- De som gjør jobben bryr seg
- Godt team-arbeid
- osv..
Gode poenger alt dette – en fin liste med viktige faktorer. Men jeg har en klar favoritt:
- De som gjør jobben bryr seg
Om de som skal lage produktet virkelig bryr seg om sluttresultatet er mye gjort! Etter mitt skjønn må dette være den aller mest grunnleggende og betydningsfulle faktoren.
Jeg forteller gjerne historien om filosofen og steinhuggerne som jeg hørte av Mary Poppendieck for mange år siden. Den går omtrent sånn:
En filosof gikk tur i fjellene og traff på tre menn som sto og hugget i stein med store hakker. Han går bort til den ene og sier: “Hei der, hva holder du på med?” Svaret er kort og ganske bryskt: “Er du blind, ser du ikke at jeg hogger i stein?” Filosofen går videre til nestemann og sier det samme: “Hei der, hva holder du på med?” Denne gangen får ha en annet svar: “Jeg står her og tjener til livets opphold, jeg har en famile nede i dalen som trenger mat”. Hmmm. Et helt annet perspektiv på den samme jobben tenker filosofen. Han går så bort til tredjemann og spør det samme: “Hei der, hva holder du på med?” Og nå får han et tredje svar: “Jeg bygger en katedral!” Samme jobben men nå et tredje perspektiv! Her kan vi spørre oss: Hvem av disse tre vil lete etter de beste steinene? Et retorisk spørsmål selvsagt.
Har du overvekt av steinhuggere, eller katedralbyggere i din organisasjon?
Katedralbyggerne vil anstrenge seg og yte det lille ekstra for at produktet skal bli bra og brukerne fornøyd. Jeg tror vi trenger noen katedralbyggere i alle organisasjoner og team, for å lage bra saker. Jeg ser for meg at katedralbyggeren insisterer på å ikke ofre det gode håndtverket, selv om slutterminen nærmer seg faretruende fort og alle fornemmer at nå er det tid som er pri 1, 2 og 3. Mer om dette her.
Så hva slags forhold har folk til de produktene de jobber med? Bryr de seg om det? Liker de det? Elsker de det, kanskje? Det kan være verd å jobbe litt med dette, om det betyr mye for kvaliteten, ikke sant?
Olaf Lewitz og Dirk Bartels hadde en workshop i idealo Internet GmbH der 
målet var å undersøke dette. Hva legger folk i utsagnet “I Love my Product”? Hva legger de i “Love” og hva legger de i “Product”?
I følge Olaf medførte dette til et stort engasjement og ikke minst at hver og en virkelig tenkte igjennom hva som betyr noe når det gjelder de produktene de lager. Det dreier seg om følelser. Og følelser er kanskje ikke det vi snakker mest om? Eller naturligst om… Kanskje det nettopp derfor kan være lurt å gjennomføre en workshop med enkle retningslinjer og fasilitering?
Så: Hvilke følelser trigger ditt produkt hos deg?
In: Kvalitet · Tagged with: Kvalitet
Slutterminer
Vi må leve med “harde” tidsfrister for når ting må være ferdig. Så det gjelder å ha en god strategi på hvordan vi håndterer dette, enten vi kjører tradisjonelt eller smidig. Som vanlig har smidig tilnæring noen fortrinn. Det finnes gode og dårlige begrunnelser for å sette tidsfrister.
Dårlig motiverte tidsfrister
Mange mener det er motiverende og gir et sundt fokus å sette milepæler å jobbe mot. Man setter derfor frister som strengt tatt er unødvendige. Psykologen Dr. Leslie Becker-Phelps skriver om dette i artikkelen How deadlines can be murder on motivation; hvordan kunstige slutterminer er begrenset til å gi ytre (ekstrinsisk) motivasjon, og at dette vil gå på bekostning av indre (intrinsisk) motivasjon. Den helhjertede, indre motivasjonen er det vi egentlig er ute etter mens – som Becker-Phelbs skriver – sluttermin-motivasjonen lett utvikler seg i helt feil retning og faktisk blir en de-motivator. Lystbetont arbeid som man i utgangspunktet setter stor pris på, kan gradvis utvikle seg i negativ retning, da det ikke lenger er lyst som er drivkraften, men snarere plikt eller i verste fall frykt for å mislykkes.
Programvareprosjekter styres ofte mot slutterminer som ikke alltid er velbegrunnede. Fristen er ofte satt av prosjektlederen i samråd med kunden og er ment som en slags forsikring om at leveransen ikke skal “trekke ut i tid”. Ofte avtaler de stilletiende en “hemmelig buffer” på slutten, slik at den reelle tidsfristen egentlig er senere (“vi har jo dårlig erfaring med slike programmeringsprosjekter”). Tanken er at slutterminen blir et styringsredskap basert på tidlige estimater.
Tidsfrister med fast omfang
Vi er vant med å se på omfanget av en leveranse som absolutt. 
Dette er naturlig, for det er jo slik det er i dagliglivet og i veldig mange prosjekter vi kan observere. Entrepenøren leverer hele broen, ikke bare deler av den. Vi klipper snorer og spretter (eller knuser) champagneflasker for å markere overlevering.
Vi har gjentatt dette til det kjedsommelige: Programvare er ikke det samme som å lage en bygning eller en “ting” som utgjør en opplagt leveranse. Programvare er nesten alltid gjenstand for en mer eller mindre kontinuerlig utvikling – en evolusjon. Tidsfrist mot en hovedleveranse er derfor unødvendig. Ikke bare er det unødvendig, men det er direkte skadelg! Alle som har vært med på slikt vet at stressnivået stiger voldsomt mot leveransetidspunktet. Og det er selvsagt i denne tilstanden, når tiden begynner å bli den altoverskyggende parameteren vi styrer etter, at vi ofrer det gode håndtverket. Vi tester det vi får tid til å teste, dokumenterer lite, får ikke tid til refactoring, selv om alle ser at det burde vært gjort. Vi lapper alt sammen etter beste evne og håper det beste. En uslåelig måte å maksimalisere dette stressnivået er å knytte dagbøter til slutterminen. Da kan du som kunde være helt trygg på at du må slite med anseelige mengder teknisk gjeld i systemet i årevis etter denne datoen.
Smidige slutterminer
Det er rikelig med gode eksempler på at harde terminer har sin berettigelse. Regnskapssystemer må gjerne leveres i ny versjon i forbindelse med årsavslutning. Andre systemer lages for å støtte et arrangement (OL på Lillehammer var en rimelig hard milepæl), og det er forhold som at markedsvinduet snart lukker seg, som gjør at vi trenger en absolutt frist. Så dette må vi takle.
Produktkø
Spørsmålet blir da: “hvordan kan vi styre mot en absolutt tidsfrist, uten å ende i dette uføret der stressnivået øker så mye at vi kaster det gode håndtverket over bord?”
I Scrum styrer vi med variabelt omfang (scope). Så lenge omfanget er variabelt, kan vi holde tid, kost og kvalitet fast. Hvilke implikasjoner har dette? Jo, det har flere, men først og fremst innebærer det at vi kan beholde roen og fokusere på det viktigste, nemlig å gi brukerne og interessentene mest mulig verdi uten å ofre langsiktig kvalitet.
Omfanget ligger altså i en kø med arbeid kalt produktkø, som til enhver tid er prioritert. De ulike elementene er også grovestimert. På denne måten kan vi vurdere de ulike elementene opp mot hverandre og etter hvert som vi nærmer oss slutterminen blir det tydeligere og tydeligere hva som vil komme med.
For at produktkøen skal bli et godt styringsredskap er det selvsagt viktig at vi har en formening om framdriften. Dette får vi gjennom å jobbe i korte iterasjoner og ved at vi grovestimerer produktkøelementene. Bruk gjerne relative størrelsestall på elementene, slik at vi kan skaffe oss empiri knyttet til hvor mange av disse tallene dette teamet i gjennomsnitt leverer i en iterasjon. Planning Poker er en fin teknikk for dette som sikrer at et helt team gjennom en strukturert prosess kommer fram til en felles forståelse av et element og et tall som representerer estimatet. Dette kalles ofte et Story Point.
Fordelen med denne styringsformen er at fokus hele tiden er på “hva er det aller viktigste i dette omfanget”. Det blir helt klart for kunden at han må engasjere seg i denne løpende prioriteringen og bidra til at prosjektet gjør gode valg.
På denne måten vil vi ofte ende opp med et ganske minimalistisk system som har visse mangler. (Vi vil fremdeles estimere feil og vi er fremdeles notoriske optimister, så jeg tror ikke vi skal ha illusjoner om at estimatene vil være veldig nøyaktige.) Så vi kan sette i drift et system som har verdi og som gjør jobben, men som alle vet må videreutvikles senere.
Hovedgevinstene ved variabelt omfang:
- Vi unngår det høye stressnivået som forleder oss til å ofre kvalitet og tolerere teknisk gjeld.
- Systemet blir enkelt og ukomplisert der manglene i systemet er et resultat av bevisste valg.
In: kontrakt, ledelse, prosjektledelse, Scrum · Tagged with: Kvalitet, produkteier, prosjektstyring, Styring
Systemtest
Gitt at
* 10.000 Nordmenn er så syke at de er arbeidsuføre av en mystisk og uklar sykdom og
* ingen har noen kur eller noen god forklaring på årsaken og
* Norske forskere oppdager et stoff som gjør én person frisk og
* de samme forskerne gjennomfører studie på 30 personer der ⅔ av pasientene (som ikke får placebo) får en svært positiv effekt og
* det er godt håp om at denne forskningen kan lede til kunnskap om årsaken til sykdommen.
Når
* de samme forskerne søker om (skarve) 9 MNOK for starte ny, større studie for å forske videre på denne hypotesen og når
* denne søknaden er gjennomarbeidet og formelt korrekt
Så
* skal de få et klart JA fra Norsk Forskningsråd.
Mange slike systemtestbekrivelser gir et rimelig innlysende resultat. Dette er en no-brainer tenker du kanskje. Men ikke så rask der. La oss kjøre denne testen med ME som sykdom, Fluge og Mella på Haukeland sykehus er forskerne og stoffet er Rituximab. Da feiler Systemet! Svaret fra forskningsrådet blir utrolig nok NEI. Hva går galt? Her må noen fram med den store debuggeren…
Crowdfunding som alternativ
Maria Gjerpe er ikke den som venter på at Systemet skal begynne å fungere. Hun er utdannet lege, har selv ME og har vært så heldig at hun har fått være pilotpasient på Rituximab, med veldig god effekt. Hun bruker nå all sin nyvunne energi på initiativet MEandYouFoundation for å finne penger til videre forskning.
Vil du være med og støtte med 200 kr? Send MEANDYOU 200 til 2377
Folk bryr seg! I skrivende stund har allerede over 500.000 kroner kommet inn!
In: Forskning, Samfunn, systems thinking · Tagged with: forskning, ME, systems thinking
Det nye testamentet…
Tilsvar til “Det nye testamentet” av Peter Hidas
Peter Hidas reagerer ganske sterkt på artikkelen min kalt “Smidig villfarelse i offentlig sektor” og harselerer på ”Peters Plass” med at jeg fremstår som en slags religiøs predikant med agile manifesto som bibel. Det er greit. Alle som jobber for å endre verden vet at litt provokativ evangelisering må til for å lokke frem reaksjoner. Agile Manifesto ble skrevet for å endre verden – i hvert fall den delen av verden som dreier seg om programvareutvikling.
Om prosjektstyring
Hidas spør: ”er det virkelig sånn at prosjektstyring er uten verdi?” Nei, det mener jeg selvsagt ikke. Prosjektstyring må til for å løse veldig mange av samfunnets store oppgaver. Det jeg mener er at prosjektstyring ikke er formålstjenlig når vi har kompleksitet og usikkerhet. Er det tilstrekkelig av dette vil prosjektstyring ikke bare være verdiløst, men også direkte skadelig.
I Scrum er det ingen prosjektleder og det er selvsagt bevisst. Scrum er helt eksplisitt laget for å håndtere kompleksitet og usikkerhet. Om man leser Scrumguiden eller Agile Atlas blir det tydelig at vi trenger tre og bare tre roller: Produkteier (som utvikler og prioriterer kravene), Scrum Master (som er en ”prosesscoach”) og Utviklingsteamet (som er ansvarlig, tverrfunksjonelt og selvorganiserende). Dette utgjør et fint balansert team som i tett samarbeide med interessentene har alt som skal til for å lage veldig gode produkter. En prosjektleder midt oppe i dette vil ødelegge denne balansen og veldig lett redusere ansvarsfølelsen til utviklingsteamet.
Om smidigforståelse
Jeg har lest Hidas i mange år, og det er tydelig at han etter hvert har fått en ganske god forståelse av smidig. Men han roter det til når han påstår at ”scope creep” er vanlig i smidig. ”Scope creep” er tvert i mot et stort problem som smidig er designet for å løse! Får du dette med Scrum er du sikker på at du ikke gjør det helt riktig…
Det virker som alle er for smidig for tiden. ”Vi vil ha smidig, bare vi ikke trenger å endre på noe særlig” synes å være innstillingen mange steder. Og her er vi ved selve kjernen av problemet. Agile Manifesto var ment som en utfordring til det bestående. De aller fleste steder må det en radikal endring til.
Jeg blir bekymret for den allmene forståelsen av begrepet smidig når jeg ser smidig-initiativene som kommer fra det vi kan kalle ”prosjektstyringsmiljøet”. Disse har opplagt ingen ting å tjene på smidig, og det går da som det må gå: Vi får en blodfattig, tannløs smidig som ikke vil gi noen særlig positiv effekt. Problemet er at det ofte kan gi en viss liten positiv effekt, men langt unna potensialet. Når DIFI lager ny prosjektveiviser kaller de inn det norske prosjektstyringsmiljøet som rådgivere – og resultatet blir deretter. Jeg håper som tidligere sagt at DIFI lytter til andre når de tar fatt på 3.0 versjonen. Det er kanskje ikke så veldig store endringer som skal til. Jeg har ikke problemer med de to første fasene, Konsept og Planlegging. Hovedproblemet er at Gevinstrealiseringen kommer til slutt. Dette må skje løpende om smidig skal ha noen mening.
Om offentlig sektor
Jeg følger Hidas rundt de kulturelle utfordringene i offentlig sektor: ”Offentlig sektor er hierarkisk, ansvaret er vertikalt fordelt, lag på lag” og ”Noen må styre og styringshierarkiet må respekteres”. Mulig dette er sannheter som er så urokkelig at ordentlig smidig er en illusjon. Jeg håper virkelig ikke det! Som skattebetalere synes jeg ikke vi skal sitte og se på at det offentlige kaster IT-kroner ut av vinduet, bare fordi ”kulturen er sånn”. Når du plasserer ”Gevinstrealisering” på slutten av prosjektet innebærer det også at du sitter med alt for mye av risikoen på slutten; Akkurat der du ikke vil ha den. Det er slik tankegang som fører til at interessentene blir overrasket over at nødnettet ikke fungerer innendørs, helt på tampen av prosjektet.
In: prosjektledelse, Samfunn, Scrum · Tagged with: ledelse, organisasjon, prosjektstyring, Scrum
Scrum på norsk
Endelig er alle de viktigste Scrum-kildene å få tak i på norsk.
Vi har oversatt Scrum Guiden som ligger på Scrum.org, Ken Schwaber og Jeff Sutherland sitt nettsted.
Nå er også Core Scrum på Scrum Alliance´s Agile Atlas oversatt.
Begge disse dokumentene er kortfattede beskrivelser av hva Scrum er. Henholdsvis 16 og 9 sider. Beskrivelsene er overlappende og de er ikke motstridende på noe måte, men de fokuserer på litt ulike ting.
Norsk Wikipedia er også oppdatert med henvisning til disse dokumentene.
Agile Manifesto har allerede i noen år vært å finne på Norsk.
In: Scrum · Tagged with: Scrum
Smidig villfarelse i offentlig sektor
Artikkelen ble publisert i Norsk Computerworld 1 Februar 2013
Det er nå ganske nøyaktig 12 år siden Agile manifesto for software development (agilemanifesto.org) ble signert og lansert. Tanken var at programvareutvikling må basere seg på en helt annen virkelighetsoppfatning enn den rådende.
Selv har jeg jobbet med agile (eller smidig som vi kaller det på norsk) på heltid siden 2005. Manifestet har hele tiden ligget i bunn. Manifestet er svært kortfattet og består av 4 verdisetninger og 12 prinsipper som kan leses og forstås overordnet på et par minutter. Men for å forstå grunntankene her må man selvsagt fordype seg i emnet. Dette kan man for eksempel gjøre ved å følge et utvalg av de 17 som i sin tid signerte. De fleste har jo skrevet bøker, blogget, diskutert og foredratt om temaet. Og selvsagt blir forståelsen gjenstand for modning etter hvert som man vinner erfaring. I 2013 er erfaringsgrunnlaget enormt, siden smidig i store deler av IT-bransjen har blir en ad-hoc standard.
Rett før jul lanserte DIFI “Prosjektveiviseren 2.0” som skal “støtte smidig” og som har et eget smidig-kapittel. Jeg gikk inn her forleden og det første som fanget oppmerksomheten min var en punktliste midt på siden. Her var det mye bra!
Begrepet «smidig» favner om flere metoder, med noe ulikt fokus. Enig!
Smidige metoder bør imidlertid ha følgende definerende egenskaper:
- Virksomhetsverdi er det viktigste kriteriet for kvalitet og målstyring. Høres bra ut, selv om jeg ikke helt forstår hva Virksomhetsverdi betyr.
- Kontinuerlig prioritering av funksjonalitet ut fra kost/nytte. Flott!
- Tett dialog mellom forretning, brukerinteresser og utviklere. Nå snakker vi!
- Korte iterasjoner/sprinter med leveranse av kjørbar kode. OK bra. Men hva er egentlig kjørbar kode..?
- Hyppige leveranser til produksjonssetting. ”… til produksjonssetting”?? Hva betyr dette?
- Forpliktende beslutninger tas så sent som mulig (rullerende planlegging). I Like!
- Evaluering, læring og forbedring underveis. Veldig bra!
- Autonomi: Selvorganiserende, tverrfaglige team. Supersmidig, jo!
- Fjern overflødig arbeid. Veldig bra!
Det var da jeg tenkte at jeg skulle skrive en positivt ladet artikkel om smidig forståelse for en gangs skyld. Dette her lover jo veldig bra – selv om det er 2-3 litt svake formuleringer så er helhetsinntrykket langt bedre enn jeg noen gang har sett fra offentlig forvaltning og “prosjektstyringsmiljøet”.
Men vent nå litt. Hva signaliserer prosessmodellen øverst på siden? Dette ser da ut som en god gammeldags vannfallsmodell? Har de glemt å oppdatere figuren? Eller har de virkelig tenkt å vente med gevistrealiseringen til hele prosjektet er ferdig? Har de virkelig tenkt å la risikoen akkumulere seg opp på godt gammeldags vis? Hvorfor snakker de om smidig i det hele tatt her? Jeg begynner å forstå punktene 4 og 5 i lista over. Det står kjørbar kode og ikke kjørende kode. Det står ikke noe om å levere ofte!
Det blir verre. Alle fasene har et smidig-kapittel så jeg klikker meg inn på “Smidig i konseptfasen” og leser: “Denne fasen – som alle andre faser i PRINCE2®-modellen – kan organiseres i sprinter for leveranser i henhold til smidige metoder.” OK. Skjønner. Det blir liksom smidig av å kjøre alle fasene i iterasjoner. Huff! Fullstendig misforstått, det vi trenger er Empirisk Prosesskontroll.
Skuffelsen er stor, selvsagt. Nok en gang et initiativ som er egnet til å vanne ut forståelsen av smidig. Nok en gang et initiativ tatt av prosjektstyringsmiljøet der de i praksis tar avstand fra de virkelig grunnleggende “nye” tankene i agile manifesto. Nok en gang et initiativ som ikke kommer til å ta bedre vare på skattebetalernes penger i noen særlig grad. Selv om intensjonene virker ganske gode opplever vi igjen at misoppfattelsene fremdeles florerer og at noen helt sentrale egenskaper ved smidig utelates. Å lage kjørbar kode i hver Sprint vil dessverre ikke gi mye læring underveis. Å kjøre Sprinter i de ulike fasene får det kanskje til å “virke smidig”, men er fullstendig misforstått. Det er ikke faser i “ordentlig smidig”.
Hva er så grunnen til at alle “smidige” initiativ i offentlig sektor feiler (kan her nevne PS2000 sin smidige veileder, DIFIs SSA-S, Danske Digitaliseringsstyrelsens K03)? Misforstår de med vilje, eller har de ikke brydd seg med å sette seg skikkelig inn i Agile Manifesto? Ønsker de kanskje en annen definisjon av smidig, som ikke er så “krevende” kanskje? En som gjør at prosjektstyringsparadimet fremdeles gjelder? For de som ikke er klar over det – smidig har et annet virkelighetsbilde i bunnen enn tradisjonell organisering og styring. Den første setningen i Agile Manifesto lyder: People and Interactions over processes and tools. Setningen i seg selv sier kanskje ikke så mye, men om man investerer noe tid i å følge de som står bak manifestet (Tips: start på agileatlas.org) vil man oppdage at det ligger mye substans her. Samtlige av de 17 opphavsmennene vil i en eller annen form hevde at fokus må vekk fra prosjektstyring og over på de som skaper verdier. De utviklerne, designerne og testerne som skal gjøre jobben må få tillit, få selvorganisere og gjøre håndtverket sitt etter en høy standard. Og de må få levere tidlig og ofte. Programvareutvikling handler også i offentlig sektor om læring underveis – og da må vi få rask og validert feedback på det arbeidet som gjøres.
Jeg tror “ordentlig smidig” vil tvinge seg fram, også i offentlig sektor. Såpass overlegent er det. Men for at det skal skje må DIFI og andre fordype seg i faget. Og de må slutte å kun alliere seg med prosjektledere og de store konsulenthusene. Disse representerer på mange måter fortiden og mange er ikke tjent med noe paradigmeskifte. Smidig truer jo posisjonen til hele prosjektstyringsmiljøet. Jeg håper arbeidet med prosjektveilederen 3.0 starter snart. Da må DIFI snakke mye mer med med utviklerne. Det er de som vet hvor skoen trykker og DIFI vil da få andre svar. Er det en ting vi har lært de siste 12 årene er det at har du motiverte, kompetente, erfarne utviklere som får anledning til å ta håndtverket sitt på største alvor vil mye være gjort.
In: kontrakt, ledelse, prosjektledelse, Scrum · Tagged with: ledelse, prosjektstyring, Scrum
5 smidige prinsipper for å bli best
Spørsmål: Hva skiller de beste fra de middelmådige?
Smidig produktutvikling er ikke basert på en veldefinert prosess som vi følger slavisk. Nei, smidig er tvert imot basert på tilpasningsdyktighet og kontinuerlig forbedring. Den prosessen vi følger i dag er ikke nødvendigvis den beste i morgen. Hovedtanken er kontinuerlig å samle erfaring, lytte til markedet og å gjøre små endringer i måten vi løser problemer på. I Scrum kaller vi det gjerne “inspect and adapt”; Prosessen er i kontinuerlig utvikling.
Hva er det i Scrum som hjelper oss til kontinuerlig tilpasning og forbedring? 
Her vil mange med Scrum-opplæring svare Retrospectiver! Dette er ikke feil, men det er langt flere mekanismer som stimulerer til dette i Scrum. Og tro meg, det å gjennomføre retrospectiver “etter boka” fører ikke nødvendigvis til denne utviklingen.
Her følger 5 prinsipper man kan velge å følge om man virkelig ønsker å hele tiden forbedre seg:
- Jobben gjøres i ansvarlige, tverrfaglige team
- Ta Scrum Master rollen på alvor
- Jobb i korte iterasjoner med hyppige leveranser
- Sørg for tett samarbeid mellom produkteier og utviklingsteamet
- Gjennomfør helhjertede Retrospectiver
I denne rekkefølgen. Retrospectiver kommer nederst på denne listen…
Ansvarlige, tverrfaglige team
Det er ingen tvil i Scrum – de som gjør jobben må få myndighet til å beslutte hvordan jobben skal gjøres – selvsagt innenfor gitte, tydelige rammer. Alt er basert på et grunnleggende positivt menneskesyn (theory Y) nemlig at folk er grunnleggende konstruktive og motiverte – gitt at de får tillit. Folk ønsker å gjøre en god jobb – å bidra til en større helhet.
Jobben gjøres i selvorganiserende team, hvilket innebærer at vi må våge å stole på at teamene løser problemene slik de selv finner best. Teamene må selvsagt ha all den nødvendige kunnskapen og ferdighetene som skal til for å utvikle gode løsninger. Når vi legger til at disse teamene får jobbe tett på markedet/kunden og stadig er i dialog med disse, vil vi kunne ende opp med team som har et fantastisk eierskap til jobben og som vil være genuint interessert i å gjøre en bedre og bedre jobb. Når dette prinsippet er på plass, vil veldig mye løse seg!
Scrum Master rollen
Et selvorganisert team skal ikke styres, men samtidig vet vi at det kan være svært krevende å få en gruppe med mennesker til å danne et velfungerende team med et brennende, kollektivt eierskap til jobben sin. Derfor trenger vi Scrum Master-rollen som er en person som jobber tett på teamet, men ikke er en del av teamet. En god Scrum Master er en menneskekjenner som vet noe om gruppedynamikk og teambygging, er en tilrettelegger og fasilitator, kan noe om coaching, og vet når det er riktig å utfordre Status Quo. Det er vanskelig å være en god Scrum Master om du befinner deg midt i teamet – og er en integrert del av prosessen. Du må faktisk ha en viss avstand for å gjøre gode observasjoner og evne å sette fingern på ting som kan forbedres. (Les gjerne mer om coaching av Scrum team her: )
Ofte vil teamet finne hindringer i organisasjonen de er en del av. Dette kan være i ledelsen, i andre avdelinger eller hos eksterne interessenter, altså steder som er utenfor teamets myndighet. Da er det helt vesentlig at Scrum Master tar med seg disse hindringene og snakker med de det gjelder og forsøker analysere ende-til-ende prosessene med tanke på å fjerne hindringer. Gjør gjerne dette i tverrfaglige workshops, eller inviter dem med i retrospectiver. Gode Scrum Mastere våger å utfordre!
Hyppige leveranser
Jeg har jobbet med faget prosessforbedring siden tidlig 90-tall, og den desidert største hindringen for å oppnå kontinuerlig forbedring var alltid mangel på feedback. Vi fikk kunnskap om hvor god jobb vi hadde gjort på et alt for sent tidspunkt, og dessuten var feedbacken ofte knyttet til en diger leveranse som gjorde det nær umulig å trekke noen konklusjoner. Årsak og virkning ble utvisket og vi var henvist til gjetning når vi skulle forbedre oss. Alt dette blir ekstremt mye bedre når vi klarte å dele opp leveransen i småbiter, levere ofte og få rask feedback. Dette er for meg så innlysende og grunnleggende at jeg kan glemme å presisere det når jeg holder kurs eller coacher.
Et godt team lager funksjonalitet som oppleves verdifullt i hvert inkrement. På den måten får vi alltid verdifull feedback og læring mens vi utvikler produktet.
Det tette samarbeidet mellom produkteier og utviklingsteamet
Scrum er basert på empirisk prosesskontroll og designet for å forhindre sub-optimalisering. Derfor er selve definisjonen av rollene i Scrum veldig tydelig: Scrum Teamet består av 3 og bare 3 roller: Produkteier, Utviklingsteamet og Scrum Master. Det er helt vesentlig at hele Scrum Teamet har en “vi-følelse” og aktivt bygge ned den tradisjonelle kløften mellom forretningssiden og IT-siden. Produkteier må virkelig representere forretningssiden – og ikke bare være en slags stedfortreder.
I gode Scrum team har produkteier jevnlig kontakt med utviklingsteamet (gjerne i forb med daglige scrummøter), de jobber jevnlig (ukentlig fungerer som regel godt) sammen med Product Backlogen der elementer estimeres, bearbeides og stykkes opp i mindre biter. Hver gang større produktikrementer planlegges, vil produkteier kommunisere visjonen til utviklingsteamet og jobbe sammen med dem i workshops for å utarbeide de nødvendige elementene (gjerne i form av User Stories).
Så, når denne kollektive vi-følelsen er på plass vil også utviklingsteamet fatte interesse for de virkelige, forretningsmessige problemstillingene man står overfor når de forsøker å finne bedre egnede metoder og teknikker. Jeg ser desverre svært sjelden at dette tette samarbeidet er på plass. Svært ofte er situasjonen motsatt: Produkteier er oppgitt over at utviklingsteamet ikke holder det de lover, utviklingsteamet skylder på at produkteier ikke var tydelig nok når han beskrev eller fortalte dem hva de skulle lage. Og sist men ikke minst: Retrospectivene blir innadvendte og forbedringene man diskuterer er ikke fundamentert i virkelige problemer. Det blir synsing og akademiske diskusjoner om hvilke teknikker som er best. Jeg kaller dette gjerne systematisk sub-optimalisering.
Retrospectiver
Så, til slutt, er det selve retrospective-møtet. Et vellykket retrospective er ikke i særlig grad avhengig av den prosessen som følges. Eller av de brainstormingsteknikkene man bruker. (Ikke noe feil med boka Agile Retrospectives av Diana Larsen og Ester Derby, men å følge denne prosessen er ikke nok!) Vellykketheten avhenger at punkt 1-4 over! Mangler ett av disse prinsippene vil retroen få begrenset nytteverdi.
Om teamet for eksempel mangler ansvarsfølelsen og eierkapet vil også disse møtene ganske snart ende opp i et kjedelig mønster. Et pliktløp. Og ting stagnerer.
Om de ikke har rett Scrum Master som brenner for sin del av jobben, våger å utfordre autoriteter og som evner å coache som en “servant leader”, vil også interessen for retrospectivene stagnere. Det er lite motiverende å oppleve at de finner hindringer, vedtar å forsøke å rette på disse, men ingen ting skjer…
Alt for få Scrum team leverer hvert produktinkrement. Dette kan vi ofte se på engasjementet i retrospectivene. Om alle vet at det som ble demonstrert på Sprint reviewet på langt nær var ferdig og skal igjennom vidreutvikling og debugging senere, har vi lite håndfast å snakke om på møtet. I team som leverer annenhver uke derimot, vil retrospectivene ta en helt annen form og vil ofte dreie seg om hvordan siste leveranse ble mottatt i markedet. Eller hvorfor en kritisk feil ikke ble detektert av kodereviewet.
Om produkteier ikke er interessert eller ikke en gang er invitert til retrospectivene vil møtene raskt gli over i en introvert, teknisk diskusjon som ikke er forankret i forretningsmessige forhold. Forandring er ikke nødvendigvis forbedring! Forbedring må resultere i en positiv effekt for hele organisasjonen.
Svaret på spørsmålet i innledningen blir da: De beste utfordrer kontinuerlig Status Quo gjennom å ta alle de 5 punktene på alvor!
In: ansvar, ledelse, Scrum, systems thinking, Teamarbeid · Tagged with: forretningssiden, kommunikasjon, ledelse, produkteier, Scrum, Smidig, systems thinking