Vad gör mig till en bra agil coach eller Scrum Master?
Jag har arbetat med agila metoder i många olika roller. Som agil coach har jag hjälpt till att
införa agila metoder och utbildat team och individer som arbetat med traditionella metoder, och coachat chefer, Scrum Masters, produktägare, och teammedlemmar. Som chef har jag implementerat agila metoder i organisationer, och i rollen som Scrum Master har jag arbetat nära teammedlemmar med coaching, utbildning och det praktiska dagliga arbetet. Som produktägare har jag ansvarat för en produkts utformning och ekonomi, samarbetat med mina utvecklingsteam och samordnat önskemål från externa intressenter, och som utvecklare har jag själv byggt system med Scrum och Kanban. Jag har också arbetat i mer traditionella projekt, och sett hur det alternativet ser ut. Dessa erfarenheter har gett mig en förståelse, både på bredden och på djupet, för agila metoder och hur de passar in i olika organisationer.
Min erfarenhet är inte begränsad till de metoder som tillämpas för att organisera arbetet inom ett team – oftast Scrum. Jag har också kunskap om organisationskultur, ledarskap, och tekniska praktika – nyckelområden som ofta förbises vid agila transformationer.
Mitt arbete utgår från ett evidensbaserat, empiriskt förhållningssätt, vare sig det gäller vilka arbetsprocesser eller organisationsförändringar som rekommenderas, hur jag coachar andra, eller vilka tekniska förändringar som krävs för att arbetssättet ska fungera optimalt.
Agila metoder är inte nya – begreppet “Agilt” är nästan 20 år gammalt, och många av metoderna är äldre än så. Metoderna är väl beforskade, och vi kan med stor säkerhet säga vad som fungerar bra och vad som fungerar mindre bra – vi behöver i många frågor inte längre gissa, tro, eller tycka. Därmed inte sagt att ett arbetssätt och ett förhållningssätt fungerar för alla. En central del av de agila metoderna är just att anpassa och kontinuerligt uppdatera arbetssättet för att passa en specifik organisation vid en specifikt tidpunkt. Dessa två saker står inte i motsats till varandra.
Varför ska man jobba agilt?
Det finns stark evidens för att företag, organisationer, och projekt som drivs agilt uppnår bättre resultat än med andra metoder. Med det agila arbetssättet produceras bättre system, med högre kvalitet, snabbare, och får nöjdare medarbetare och högre vinst, oavsett bransch, vilken typ av system det rör sig om, eller projektets storlek.
Agila metoder fungerar helt enkelt.
De vanligaste orsakerna till att välja agila metoder är att man vill leverera snabbare, kunna anpassa sig snabbare till förändringar, öka produktiviteten, och öka kvaliteten. Några väljer ett agilt arbetssätt för att de vill ha ett bättre arbetsklimat, nöjdare medarbetare, eller förändra sin företagskultur, men de flesta har trots allt ekonomiska motiv. Men, även om en organisation vill bli mer agil av ekonomiska skäl uppskattar nog de flesta att samtidigt få nöjdare medarbetare och kunder, och en bättre produkt.
Kultur och värderingar
Agilt är i mångt och mycket en reaktion mot andra, mer processorienterade och processtunga metoder, och innebär ett skifte från processer till pragmatiskt samarbete, från dokumentation till fungerande mjukvara, och från planer till anpassning. Agil kultur handlar om att sätta människan och kunden i fokus, och arbeta på det sätt som bäst producerar den mjukvara kunden behöver, oavsett vad processer, kontrakt, eller best practices föreskriver.
Den vanligaste orsaken till att agila införanden misslyckas är oförmåga att förändra organisationens kultur.
Värderingar och kultur kan inte separeras från de agila metoderna. Ett vanligt fenomen när organisationer skiftar från traditionella till agila metoder är att de agila metoderna bara ses som en ny arbetsprocess. Nya processer införs, dokumenteras och följs upp, och det är processerna som står i centrum istället för idéerna bakom dem. De gamla processerna tas (i bästa fall) bort och ersätts med nya, men den gamla kulturen består. Detta kallas ofta för Cargo Cult Agile eller Flaccid Scrum.
När agila metoder har blivit allt mer populära har tyvärr också avarterna blivit fler. Många “agila” utvecklingsavdelningar har förvisso scrum i sina team, men inte så mycket mer än så. På samma sätt som agilt är en reaktion mot dysfunktionella traditionella processer och organisationer, så har DevOps fötts som en reaktion mot dysfunktionella implementationer av agila metoder. DevOps och de “gamla” agila metoderna är i princip identiska, men DevOps lägger tyngdpunkten på de delar som oftast gör att man inte lyckas få ut önskad effekt av agila införanden – kultur, samverkan mellan olika delar av organisationen, och de tekniska komponenter som stöttar agila metoder.
Teknik och praktika
DevOps lägger stort fokus på interaktionen mellan utveckling och drift, men också på teknik och praktika så som continuous integration, continuous delivery, testautomation, etc. En av de tidiga agila metoderna, eXtreme Programming, la också stor vikt vid mer tekniknära arbetsmetoder, om än med ett mer utpräglat utvecklingsfokus, som parprogrammering, testdriven utveckling, och kodstandarder. Tyvärr tappar man ofta fokus på dessa delar, och många organisationer som arbetar med Scrum och Kanban har svårigheter i att tillämpa delar av dessa metoder, som täta releaser, tvärfunktionella team, eller fokus i sina sprintar, utan att riktigt förstå varför. Många tänker att de agila metoderna inte riktigt passar dem och deras vardag, jobbar istället runt problemen, eller fortsätter som vanligt, men ger i praktiken upp sina försök till kontinuerlig förbättring. Kulturen, samarbetet med den omkringliggande organisationen, strategi, och ledningssätt är vanliga orsaker till dessa problem, men tekniken är ofta också en osynlig bov i dramat.
Ett exempel kan vara svårigheter att göra meningsfulla releaser varje sprint. Man upplever långa ledtider då flera team behöver vara inblandade i utvecklingen av många funktioner, det tar lång tid att kvalitetssäkra innan release, och själva produktionssättningen kan bara genomföras under vissa fönster för att inte störa verksamheten. En vanlig reaktion på dessa problem är en känsla av att den agila metoden man använder inte är riktigt anpassad till ens egen verksamhet, den verkar passa bättre för mindre, konsumentorienterade mjukvaruprodukter där ett team sköter nästan allt själva, buggar inte får så stora konsekvenser, och användaren själv snabbt kan uppdatera en app eller ladda om en webbsida för att få en ny version när det passar dem. Här hjälper inga nya kolumner på kanbanboarden, bättre kommunikation, eller mer coachande ledarskap – man behöver tekniska praktika för att lösa tekniska problem. Man kan göra om sin applikationsarkitektur till mindre, mer fristående tjänster som kan uppdateras oberoende av varandra, med väl definierade ansvarsområden och kontrakt så att ett team kan uppdatera sin komponent utan beroenden till andra, automatisera sina tester och releaser så att de manuella testerna går snabbare att genomföra och kan fokusera på andra saker än funktionalitet och prestanda, och hitta sätt att deploya sin applikation som inte innebär någon nedtid eller några störningar alls – zero downtime releases.
Att börja med effekterna, till exempel snabba leveranser, utan att ha gjort grundarbetet som säkerställer kvalitet och kundnytta leder sällan till bra resultat. Att bara skjuta ut ny mjukvara till sina kunder på daglig basis är enkelt, men att konstruera automatiserade testsviter som ser till att inga buggar följer med är arbetskrävande och svårt. Agila metoder har oftast ingen separat test- och kvalitetssäkringsfas innan en produktionssättning, men det innebär inte att man bara kan ta bort den utan att ersätta den med något annat. På samma sätt behöver detaljerade kravspecifikationer ersättas med ett effektivt kundsamarbete, detaljstyrning med egenmakt och systemdokumentation med självdokumenterande system. Agilt är inte enbart att ta bort traditionella processer och artefakter, det är att ersätta dem med nya.
Om agila metoder inte kan implementeras (effektivt) utan att också förändra organisationens kultur gäller även det omvända. Att förändra kulturen utan att förändra arbetssättet leder till en organisation där människor vill arbeta på ett effektivt sätt och producera bra produkter, men hålls tillbaka av processerna.
Certifieringar, kurser, och utbildningar
- Professional Scrum Master I
- Professional Scrum Master II
- Professional Scrum Master III
- Professional Scrum Product Owner
- Professional Scrum Developer
- Leading SAFe
- NoEstimates med Vasco Duarte
- Testdriven Utveckling med Alistair Cockburn
- Cost of Delay med Özlem Yüze
Vill du veta mer?
Kontakta mig gärna! Jag tar uppdrag som agil coach och Scrum Master, men utbildar och coachar också i agila metoder.