Kontinuerlig förbättring i det långa loppet – hur och varför?

Facebook

Google

Twitter

Linkedin

Hej kära läsare! Mitt namn är Martin och jag är en “process-aholic”. Jag har sett processer (eller avsaknaden av dem) överallt sedan jag var barn. Jag har sett en del människor som gör saker på “fel” sätt och en del människor som gör saker på “rätt” sätt. På universitetet lärde jag mig dock att inte ens när det kommer till processer är livet svart eller vitt, men jag förstod aldrig hur jag skulle kunna särskilja en “bättre” processen från en “sämre”. 11 år senare när jag fann Scrum blev jag glad över att hitta en process med inbyggd processförbättring. Jag kunde äntligen experimentera och sedan utvärdera om det hela blev bättre eller sämre. När jag insåg att de flesta team körde Scrum utan denna del, bestämde jag mig för att försöka lära världen ämnet kontinuerlig förbättring. Detta är ett sådant försök, men det var nog uppenbart…

Vad jag har saknat när jag predikat om tillbakablickar/retrospektiv är tydliga och konsekventa mål. Att nyttja de fantastiska grundvärden som agila metoder vilar på, såsom Extreme Programmings kommunikation, återkoppling, enkelhet och mod (inklusive respekt från version 2) och Scrums öppenhet, engagemang, fokus, etc, har hjälpt mig att sikta bättre på kort sikt. Men det var inte förrän jag lärde mig om två specifika (och överlappande) mognadsmodeller, en via Torbjörn Gyllebring och en via min kollega Fredrik Lingren (tack så mycket till er båda!) som jag förstod hur jag skulle kunna tillämpa en mer fokuserad strategi för ständiga förbättringar. Detta är min strategi:

Att kontinuerligt försöka förbättra din process tvingar dig att faktiskt tänka på processen istället för att fastna i vad som ska byggas härnäst. Människor och team som inte har ett processtänk har mycket svårare för att bibehålla sin effektivitet (dvs. sin status quo). Över tid kommer processen att vittra sönder. En enkel processförbättringsmetod som att ha retrospektiv ofta kan hålla dig och teamet på status quo-linjen och en genomtänkt metod får dig att ständigt förbättra.

Att kontinuerligt utvärdera den nuvarande processen och göra små inkrementella förbättringar på den, det vill säga Scrums retrospektiv är ofta tillräckligt för att nå bättre effectiveness (att se till att vi bygger rätt sak) och efficiency (se till att vi bygger denna sak på rätt sätt, i båda fallen med så lite waste som möjligt). Detta gör man genom att alltid noggrant följa upp åtgärder man beslutade om i förra retrospektivet och agera därefter.

Men en dag kanske teamet står där på toppen av en mindre kulle. Då krävs en metodik för att traska ned för den kullen och finna en högre att gå upp på. Detta handlar om att ändra tankesätt.

Att röra sig från vänster till höger i bilden, att ändra tankesätt, är något Bob Marshall kallar för Rightshifting. För att mogna måste vi ändra tankesätt och det innebär att teamet (eller personen) måste gå igenom ett slags trauma. Att gå från “jag jobbar bäst ensam” till “vi fungerar bäst som ett team” inte ett lätt steg att ta.

En av de mest välkända förändringsprocesserna är Kurt Lewins modell med tre steg.

• Upptiningssteget handlar om att göra sig redo för förändring. Man behöver förstå varför förändringen behöver ske, att den är nödvändig.
• Det andra steget är när vi gör de förändringar som behövs. Att ändra något händer inte omedelbart, det är en process, en övergång, för att överbrygga klyftan mellan tankesätt.
• I det tredje steget fryser vi förändringen, vi gör den permanent. En välkänd metod för detta är 30-day-challenge, där man gör någon sak i 30 dagar. Då lär du dig förändringen, det blir en vana.

Bob Marshall har en modell som kan visa teamets (eller hela organisationens) olika kullar och berg att bestiga. Han kallar den naturligtvis för Marshallmodellen.

Marshall listar fyra tankesätt (eller snarare sju steg) – ad-hoc, (nybörjare / kompetent) analytisk, (tidig / mogen) synergistisk och (tidig / skicklig) kaordisk. Låt oss hoppa över den sista, som är lite mer av en utopi, just nu och fokusera på de för ämnet mer relevanta:

• Ad-hoc är när en organisation eller team hittar på allt eftersom och ständigt löser samma typ problem, dessutom ofta på olika sätt. Jag tror att detta är teams normaltillstånd. Vi är helt enkelt inte mer mogna i allmänhet… ännu.
• Analytisk när det finns en organisationsstruktur som på papperet ser bra ut med tydligt fokus, men varje del av arbetet utförs i silos. Detta tillstånd är vanligt i team, de har ett strukturerat arbetssätt, men när det kommer till detaljerna, det är fortfarande ad-hoc. Detta gör att man inte kämpar för att få ett gemensamt mål, utan varje team lokaloptimerar sin situation.
• Synergistisk är när man organiserat sig så att man hela tiden följer gemensamma mål. Beslutsprocessen är ofta bevisbaserad och alla vet vad som verkligen värdefullt för företaget och slutanvändarna. Det är där team som har gjort övergången till agilt på ett bra sätt hamnar. Synergieffekter som uppstår är högre motivation, snabbare lärande och god förändringsbenägenhet.

Mellan de här tankesätten finns övergångszoner som kräver aktivt och långsiktigt förändringsarbete. Zonerna är tuffa att ta sig igenom och det är lätt att falla tillbaka in i gamla tankesätt. Detta är skälet till att vi ser så många team som har ett vattenfallstänk i en Scrum-struktur. Metoden kan vara den synergistiska och man kan vinna en del på det, men om det gamla tankesättet fortfarande är kvar så presterar man troligen sämre överlag än om man behållit den gamla metodiken.

Låt mig berätta en anekdot från ett team som jag arbetade i det var enkelt att se utvecklingen hos teamet och hur vi passerade de olika tankesätten. När teamet formades bestämde vi oss tidigt, tack vare vår coach, att ha retrospektiv varje vecka. Detta var troligen nyckeln till att vi lyckades mogna relativt snabbt. Under det första halvåret handlade de flesta diskussionerna på retrospektiven om byggservrar och kodgranskning, fokus låg helt på utvecklingsdelen av arbetet, jag som UX:are och min kollega PO:n satt mest och lyssnade. Under andra halvåret blev vi mer inbjudna in i processen och man pratade mer om hur vi skulle fördela arbetet i hela teamet på bästa sätt. I början av andra året började vi utöka teamet med fler roller och kompetenser för att se till att vi faktiskt byggde rätt produkt. Man diskuterade skälen bakom varje funktion. Och några månader senare började teamet ifrågasätta beslutet om att driva projektet överhuvudtaget, med mycket välgrundade argument vill jag tillägga.

En annan modell för tankesätt är Samarbetsmodellen med sina 5 steg som delvis överlappar Marshallmodellen.

• Konkurrens – Varje person i teamet har sitt eget individuella mål och sätter sitt mål framför andras.
• Konglomerat – Varje person i teamet har sitt eget individuella mål. En övergripande organisation utnyttjar detta faktum och ser till att varje person jobbar så hårt som möjligt. Ett exempel är företag som ger bonus till “hjältar”, de som har lagat något som är trasigt, släckt bränder, men (omedvetet) förminskar de som förebygger problemen.
• Samordning – Varje person i teamet har sitt eget individuella mål. Dessa mål kombineras (inte slås ihop) och teamet samordnar sina insatser för att säkerställa att alla mål uppfylls. Arbetet utförs individuellt. Ett exempel är ett team vars stories i en sprint inte hänger ihop och varje person jobbar på varsin story. Det här ser vi ofta som resultat av dålig projektledning.
• Samverkan – Varje person i teamet har sitt eget individuella mål. Varje person är medveten om sina kollegors mål. Arbetet sker mest individuellt, men man stödjer varandra. Varje person i teamet har sin specifika roll och arbetet går från roll till roll. Ett exempel är en story som först designas av en designer, sedan byggs av en utvecklare och till sist testas av en testare. Detta är i grund och botten vattenfall och ett analytiskt tankesätt. Ett annat exempel på en samverkansmetodik är kodgranskning.
• Samarbete – Alla personer i teamet delar mål samma mål eller har mål som inte kan uppfyllas utan att möta de andra. Arbetet sker samtidigt av flera personer med regelbundna och informella kompromisser mellan människor. Personerna har individuella talanger och nyttjar sina talanger på flera aspekter av arbetet. Ingen enskild del av arbetet kan associeras med någon person. Detta är agilt. Med gott samarbete får man starka och positiva synergieffekter. Ett exempel är mobbprogrammering (i naturlig kombination med single piece flow) där alla personer i teamet tillsammans arbetar på en story i taget och givetvis gör den viktigaste storyn först.

Denna modell har hjälpt mig mer än den tidigare, trots att den “bara” fokuserar på samarbetet, men detta är säkert eftersom en av de agila grundvalarna är just samarbete och därmed kan den appliceras på de flesta agila metoder och tekniker.

Summa summarum – ha bra retrospektiv ofta och lyft blicken för ett långsiktigt mognadstänk! Lycka till!