Når smidig møter virkeligheten
Alle smidig-initiativer møter et mer tradisjonelt styringssystem. Hvor annerledes dette systemet er varierer selvsagt, og kommer først og fremst an på to faktorer: Størrelse og alder. I de gamle, store organisasjonene må smidig forholde seg til en virkelighet som på mange måter er i konflikt; Et helt annet paradigme som ikke samvirker særlig godt med smidig.Hybridmodellen
Så, i de fleste forsøk på å innføre smidig vil man i en periode måtte leve med en blanding. La oss kalle dette Vann-Scrum-Fall. Jeg har nylig skrevet om dette her.
Vann-Scrum-Fall
Det er altså fremdeles spesielle roller som gjør forarbeidet, det vil være en kjede av overleveringer mellom brukerne og teamet. Når teamet er “ferdig” vil de ikke ha et “Shippable Product”, men en slags “halvfabrikata” som kan demonstreres, men som på ingen måte er leveringsklar. Det gjenstår flere overleveringsnivåer og det vil ta tid før noe som helst er helt ferdig (i drift).
I en slik setting kan man få visse positive effekter av smidig. Men det er også fare for at effekten blir negativ. Jeg har sett dette mange ganger og jeg har laget en “topp-15” uprioritert liste over de viktigste problemene.
1. Syklusproblemet
Lange iterasjoner gjør det vanskelig å lære og å optimalisere
2. Deadlineproblemet
Fokus på tid og kost gjør at vi ofrer det gode håndtverket
3. Overleveringsproblemet
Lang avstand mellom brukerne og utviklerne fører til manglende forståelse
4. Risikoproblemet
Risiko får vokse seg stor og dyr før den avdekkes
5. Innovasjonsproblemet
Får ikke anledning til å være kreative underveis
6. Flytproblemet
Arbeidet stopper opp fordi vi stadig må vente på andre
7. Eierskapsproblemet
Autoriteter styrer så detaljert at eierskapet hos utviklerne svekkes
8. Retningsproblemet
Roller og individer har ulike agendaer og målsetninger
9. Budsjettproblemet
Rigorøse budsjettprosesser gjør at vi binder oss for tidlig på dårlig grunnlag
10. Kompletthetsproblemet
Alt er like viktig, ingen spissing av tidsbruken mot det som gir mest verdi
11. Sårbarhetsproblemet
Rollefokuset fører til spesialisering og stor personavhengighet
12. Ullenhetsproblemet
At svært mye arbeid samles opp før vi fullfører, ødelegger gjennomsiktigheten
13. Suboptimaliseringsproblemet
Funksjonelle avdelinger med egne målsetninger fortrenger helhetssynet
14. Prosjektproblemet
Stadig opp- og nedbemanning av prosjekter i paralell vanskliggjør teamarbeidet
15. Fokusproblemet
Arbeidsdagen er preget av multitasking og avbrytelser
Hva kan vi gjøre med dette?
Alle disse problemene skal på en eller annen måte komme til overflaten om Scrum-teamene virkelig ønsker å stadig forbedre seg. Forbedring i starten av et slik smidig-løp vil i en eller annen form bestå i å få raskere gjennomløpstid i verdistrømmen. Gode Scrum team vil detektere hindringer og gjøre noe med dem. Det er ScrumMaster sin viktigste jobb å forsøke å fjerne identifiserte hindringer. Dette berører veldig ofte andre deler av organisasjonen, og da gjelder det å våge å si ifra.
Man kan si at god Scrum vil føre til at små “bomber” detonerer rundt om i organisasjonen. I praksis vil det være at Scrum Master ber om en samtale med rette vedkommende og foreslår endringer i arbeidsprosessene. Og siden vi jobber i korte iterasjoner kan vi gjøre disse endringene gradvis. På denne måten blir Scrum en slags debugger på organisasjonsnivå.
Scrum som organisasjonens debugger
Eksempler:
“Teamet støter stadig på løsingsbeskrivelser som bygger på antagelser som ikke lenger er gyldige. Kan vi gå igjennom dette og løse opp i det slik at teamet kan selv kan finne de beste løsningene?”
“Vi opplever stadig at vi i tett samarbeid med brukerne finner enklere løsninger enn det som er spesifisert. Kan vi gå igjennom Spec´en og gjøre den mindre forpliktende?”
“Vi blir alt for ofte belemret med gamle feil, som det er tungt å søke fram og rette. Kan vi begynne å levere hyppigere, slik at feilene kommer raskere tilbake til oss?”
“Vi får ikke integrert systemet godt nok underveis, og det fører til at vi alt for ofte får integrasjoneproblemer rett før leveranse”
Etter at Scrum Master og resten av Scrum teamet iherdig har jobbet med å fjerne hindringer på denne måten, verdistrømmen gradvis kunne bli kjappere med langt hyppigere leveranse og bedre samarbeid mellom Scrumteamet og brukerne.
Optimale forhold for tett kundesamarbeid
Stagnasjon
Det er dessverre alt for mange som blir hengende ved en hybridmodell, og derfor går glipp av de store gevinstene som ligger og venter. Hvorfor skjer dette? Vel, den enkle forklaringen ligger nok i at en overgang til smidig innebærer en betydelig organisasjonsendring. Alle ledere vet at dette er smertefullt og kommer til skape frustrasjon og ustabilitet. Vi risikerer å miste gode folk. Derfor er det veldig lett å prøve seg med en mer overflatisk endring, der vi innfører nye begreper (som Scrum Master, Produkteier, Sprinter, Retrospectiver) uten å endre på noe grunnleggende.
Jeg er ikke noen stor fan av John Kotter, men på øverste nivå er hans 8-trinns modell fornuftig. Og den starter naturlig nok med “establish a sense of urgency“. Om man mangler dette vil resten falle sammen og føre til en skinn-endring som ikke vil gi den potensielle gevinsten. Det kan være mange grunner til at ledelsen velger denne enkle “løsningen”, men jeg tror vi ser to hovedmønstre:
Det første mønsteret er formålsløshet. Det tas en beslutning om å innføre Scrum – uten at man riktig vet hvilket problem man skal løse med dette verktøyet. I samtaler med ledergrupper spør jeg alltid om forretningsmessige problemer og ambisjoner de har. Ikke alle kan gi noe klart svar på det. Når ingen riktig vet hvorfor man skal gjøre en endring er den dømt til å bli overflatisk.
Det andre klare mønsteret er uforstand. Det tas en beslutning om å innføre Scrum – uten at man har satt seg skikkelig inn i hva Scrum og smidig er. Man sender utviklerne på kurs og tenker at det er der – nede på IT-avdelingen – at endringen skal foregå. Stor feil! Scrum og smidig berører hele organisasjonen og alle – særlig ledergruppene – må få en grad av opplæring. Når Scrumteamene kommer settende med identifiserte hindringer de ønsker å få løst opp i, er ikke linjeorganisasjonen forberedt og Scrum Masterne blir bare oppfattet som “negative urokåker”.
Om man ønsker å få kontroll på risiko, komme raskere til markedet, øke innovasjonsevnen eller effektivisere så kan Scrum eller andre smidige rammeverk være løsningen. Men det er ingen vei utenom en helhjertet endringsprosess. Det kommer til å bli krevende, det blir ustabilt og til tider smertefullt.
In: Endringsledelse, ledelse, Scrum, systems thinking, Teamarbeid · Tagged with: endringsledelse, ledelse, organisasjon, Scrum, systems thinking