Vi må snakke om prioritering
Vel, det snakkes selvsagt en hel del om prioritering allerede – alle skjønner at vi må forsøke å bruke det vi har av kapasitet der hvor det betyr mest. Der det gir mest verdi. Men hva mener vi egentlig med ordet “verdi”? Og hvem er “vi”? Dette kan høres ut som halvinteressante filosofiske spørsmål, men jeg tror det er mye mer potent enn som så. Det er slike spørsmål som kan ruste oss til å gjøre riktige prioriteringer og ikke minst skape alignment – en felles sterk forståelse av hva som er viktig for suksess. Ingen sak egentlig, å prioritere noe opp. Det som er vanskelig (og som egentlig er prioritering) er å bestemme oss for hva vi skal prioritere ned.
Det er hovedsakelig to grunner til at det er viktig å beherske prioriteringens kunst:
1) Å kanalisere energien i selskapet i en bestemt strategisk retning og
2) Unngå overbelastning.
Strategisk retning
Det snakkes mye om felles fokus og samkjøring (alignment) av organisasjonen, men det virker som få får det til i praksis. Jeg tror det er mange årsaker til dette. En ganske åpenbar forklaring er at prioritering er ubehagelig – siden det innebærer å gi tommel ned. Det vil være noen som ikke får det de mener de har rett på. Det kan være mange ulike interessenter rundt et produkt som hver og en mener de har en solid case som fortjener fokus. Å si nei til disse betyr at de blir skuffet, kanskje til og med sinte. Tydelig, klar prioritering vil aldri oppleves rettferdig for alle. Det er mye mer behagelig å tilfredsstille alle littegrann, enn å fokusere på bare én på bekostning av alle de andre.
Overbelastning
Det virker som mange produktorganisasjoner er i en konstant tilstand av overbelastning, der man hele tiden febrilsk forsøker å ta igjen det tapte. Arbeidsdagene blir dominert av heseblesende multitasking – noe som vi mennesker stadig innbiller oss at vi behersker godt. I neste omgang blir vi tvunget til å jobbe fokusert med den ene tingen som brenner aller mest. Dette gir et dårlig klima både for innovasjon, forbedringsarbeid og kompetansedeling. Vi trenger faktisk å ha en grad av overskudd og ledig kapasitet for å sikre at vi hele tiden evner å utvikle oss som organisasjon, og å ta vare på det vi oppdager underveis.
Innen produktutvikling er det vanskelig å ta igjen det tapte ved å bemanne opp (Brooks). Den reelle kapasiteten øker saktere enn vi håper, og den er sjelden lineær. Nei, det beste man kan gjøre for å komme ut av en slik tilstand er å begynne å prioritere ting ned – på strategisk nivå; være klare og tydelige på hva vi skal unngå å bruke kapasitet på.
Typiske dilemmaer og potensielle kandidater til nedprioritering
Jeg har samlet en del erfaring som konsulent innen Scrum og smidig og her kommer en (ikke uttømmende) liste over typiske områder som kan lede til overbelastning og manglende fokus hvis de ikke håndteres strategisk, tydelig og gjennomført. Man må bestemme seg – hva skal veie tyngst?
Valg av kundesegment
Vi kan ikke tilfredsstille alle. I hvert fall ikke med en gang. Her er det gylne anledninger til å prioritere så det monner. Det kan være at visjonen (4-5 år) er “verdensherredømme” i et bestemt marked – men vi må begynne smalt og vinne erfaring og bevise at vi er på rett vei i et snevert kundesegment.
Det er også vanlig at man etter noen suksessrike år har “pådratt seg” en rekke små og ulønnsomme kunder. Det kan virke brutalt, men allikevel nødvendig å sanere kundeporteføljen fra tid til annen.
En “nordstjerne”?
Finnes det én egenskap som trumfer alt annet? I så fall kan dette være en ekstremt kraftfull mekanisme for prioritering. Edgeir Aksnes i Tibber hevdet for et par år siden (og gjør det muligens ennå) at de trenger vekst mer enn alle andre ting. Vekst trumfer alt. Det mangler ikke på initiativer og ønsker, men hvis man ikke kan sannsynliggjøre at det vil føre til vekst går det i søppelbøtta.
Mange tror Vipps driver finans, men Rune Garborg vil hevde at nei, det Vipps driver med er én og bare én ting: forenkling. Hvis en produktidé ikke kan vise til at det vil føre til forenkling for brukerne, får det ikke prioritet.
Kortsiktig vs langsiktig
Hvis vi utvikler et produkt eller en tjeneste må vi ganske raskt bestemme oss for om dette skal være robust og bærekraftig på lang sikt, eller om vi må pøse på med nye features (MVP-er) for å lære sammen med kundene. I det siste tilfellet kan vi leve med mangler og litt rufsete kvalitet rett og slett fordi vi er i en læringsfase. Her må vi være sikre på at vi ikke gjør dette til modus operandi slik at det hoper seg opp med teknisk gjeld vi ikke kommer oss ut av igjen.
Det er dessverre altfor vanlig å neglisjere dette dilemmaet og hvis det er uklart vinner nesten alltid de kortsiktige hensynene. Man jager milepæler, tar seg ikke tid til å jobbe med forbedring og ender opp med teknisk gjeld.
Hvem sin gevinst skal være styrende?
Det er ikke nødvendigvis sånn at sluttbrukerne, andre interessenter og egen organisasjon har sammenfallende interesser. Amazon har i flere tiår hatt customer obsession som mantra – og dette prinsippet gjennomsyrer prioriteringene helt fra Jeff Bezos og ned til alle deres “two pizza teams”. Tanken er at hvis tilstrekkelig mange kunder er tilstrekkelig fornøyde, vil de selv gå med overskudd. Ingen tvil om at dette har vært en vellykket strategi for Amazon. Ikke dermed sagt at dette er riktig strategi for alle, men uansett en stor fordel å være tydelig på slike strategiske prioriteringer.
Feilretting eller nyutvikling?
Dette er kanskje det vanligste dilemmaet mange er i nærmest på daglig basis. Man har målsetninger og strategier som innebærer mye nyutvikling, men så kommer disse evinnelige feilrapportene og supportsakene i veien. Ikke lett å si noe generelt om hvordan slikt bør prioriteres, men i hvert fall viktig å legge stor vekt på at ikke feilrettingen tar for mye energi og kapasitet. Har man pådratt seg mer teknisk gjeld enn man kan leve med, kan det være helt avgjørende å prioritere “gjeldssanering” for å komme seg ut av dette uføret.
Smått trumfer stort
Vi slipper ikke unna estimering – uansett hvor lite populært dette måtte være. De som skal gjøre jobben må kunne si noe grovt om arbeidsmengden for at det skal være mulig å gjøre gode prioriteringer. Det som gir best kost/nytte er åpenbart små saker som gir høy antatt nytteverdi for kundene (innenfor den retningen man har satt).
Operativ prioritering
Det er naturlig å begynne på toppen – hva er visjonen for dette nye produktet – eller tjenesten?
VISJON
Denne skal være overordnet og langsiktig. Gjerne så ambisiøst at den kan virke uoppnåelig.
Hvordan ser suksess ut om 3-5 år? Går vi for “verdensherredømme” eller nøyer vi oss med en nisje? Hvor viktig kommer vekst og skalerbarhet til å bli for suksess? Skal vi inn i et marked med strenge regulatoriske krav? Kan liv og helse stå på spill med dette produktet? Skal vi konkurrere på brukervennlighet?
Deretter er det naturlig å sette mål for “mellomlang sikt” (i Scrum: Produktmål). Disse har typisk varighet på ¼ til 1 år. For å oppnå visjonen må vi altså nå en serie med produktmål – men bare det nærmeste målet er operativt.
SERIE MED PRODUKTMÅL
En Product Owner eller Produktsjef vil gjerne bruke produktmålene som som en grov Road Map for produktet. Det er viktig at også disse målene må være effektmål og si en del om hva vi ønsker å oppnå på vegne av kundene, men i liten grad være spesifikke på akkurat hva vi skal lage og hvordan.
Produktmålene tror jeg er nøkkelen til tydelig og god prioritering. Hvilket kundesegment skal vi ha fokus på? Hvilke kunder eller produktområder er vi IKKE skal jobbe med her? Har vi en Nordstjerne? Skal vi gønne på med MVP-er eller skal vi ta det rolig og skape robusthet? Slike ting.
For å oppnå det neste Produktmålet lager vi gjerne en Product Backlog. Denne vil hele tiden være “i arbeid” og altså ikke være “forpliktet”. På den måten vil det være enkelt å omprioritere løpende basert på det vi lærer når vi leverer produktinkrementer til brukerne.
PRODUCT BACKLOG
Bruker man Scrum vil elementene i Product Backlog være input til Sprintene med varighet på 1-4 uker. Hver av disse Sprintene skal ha Sprintmål.
SPRINTMÅL
Unngå Sprintmål av “hummer og kanari”-typen som forsøker å fikse på en usammenhengende liste problemer. Sprintmålene bør også være formulert som effektmål: I denne sprinten skal vi løse dette spesifikke problemet for disse kundene. Det bør være tydelig at Sprintmålet representerer et tydelig skritt i retning av det neste produktmålet.
PRODUKTSJEF/PRODUKTEIER
Operativ prioritering må gjøres raskt, løpende og ofte uten nok informasjon tilgjengelig. Dette dreier seg om handlekraft. Derfor vil mange ta til orde for at dette ivaretas av én person – altså ikke en komité. Med Scrum vil dette åpenbart være Product Owner rollen. Her trenger vi altså en person som er komfortabel med å prioritere andre ned, selv om de åpenbart blir skuffet. En som har en klar visjon, tydelige mål og som står stødig selv når det stormer som verst.
In: Lean, produkteier, Scrum · Tagged with: Prioritering
Estimering
Estimering er en helt naturlig del av prosjektstyringsfaget – vi må jo vite hva det kommer til å koste og når vi kan forvente å være ferdig! Alle metoder og rammeverk som forutsetter å legge en plan mot et mål – for deretter å følge opp mot denne planen – er helt avhengig av gode estimeringsteknikker.
Smidig tankesett og Scrum er først og fremst for problemområder med stor usikkerhet og kompleksitet der vi må manøvrere i retning av målet gjennom læring og feedback. Vi vet at vi kommer til å oppdage interessante ting på veien og at viktige antagelser kan vise seg å være gale, så suksess har ingen ting å gjøre med vår evne til å følge planen. Dette er mao ikke først og fremst et prosjektstyringsproblem. Så da er det vel helt unødvendig å estimere noe som helst? Det er ingen overdrivelse å si at estimering under slike betingelser er kontroversielt. Utviklere sier typisk slikt som:
Hvorfor i det hele tatt forsøke når usikkerheten er så stor?
Demotiverende å stadig oppleve at estimatene var feil
Vi blir tvunget til å estimere for at ledelsen skal kunne følge oss opp!
Hvorfor skal vi bruke tid på noe så unyttig!
Dette er forståelig og gode poenger, men vi kan allikevel ikke bare vri oss unna dette helt. Vi trenger faktisk å forholde oss til fremtiden selv om denne er usikker og det er helt nødvendig å ta med “antatt arbeidsmengde” når vi skal prioritere og ikke minst legge strategier. Vi skal her se litt på ulike teknikker muligheter som vil gi verdi uten at det koster for mye.
Prioritering
La oss tenke oss at Product Owner jobber tett sammen med interessenter, og at de blir enig om en ny feature som vil generere mye verdi. PO lager skisse til et Product Backlog Item (PBI) og tenker at denne her må høyt opp i Product Backlog! Det er helt fint, men det kan jo hende at denne POen antar at “dette kan da ikke være så mye jobb”. Men tenk om utviklerne vet at, joda, dette er faktisk en god del arbeid. Skal vi få til dette må vi redesigne viktige komponenter i tjenestelaget og sannsynligvis skrive mange hundre kodelinjer!
Da vil jo PO se på denne nye funksjonaliteten med nytt blikk, og trigge spørsmålet “hvor mye sånn ca vil det koste?” Med andre ord be om et estimat. Kanskje den ikke er så lovende allikevel? Kanskje dette vil koste så mye at det er tvilsomt om det er verdt investeringen? Så, her må utviklerne og PO sette seg ned og luke ut slike sprikende antagelser. Kanskje det finnes måter å gjøre funksjonen enklere så det ikke blir så mye jobb? I Scrum gjør vi dette i Product Backlog Refinement (PBR).
Enkelte ting kan være av typen “koste hva det koste vil”. Dette er egenskaper eller funksjonalitet som bare MÅ være tilstede. Er det da nødvendig å grovestimere? Ja, det er fremdeles av stor verdi å vite noe grovt om hvor mye tid denne saken vil beslaglegge. La oss si at denne ene saken blir utviklernes eneste oppgave i flere Sprinter på rad. Da vil andre presumtivt viktige saker bli satt på vent. Vi går her glipp av identifiserte gevinster hver eneste dag faktisk, så om ikke annet må PO ha denne informasjonen for å kunne forventningsstyre ift interessentene.
T-skjorte estimering
Dette er kanskje ikke estimering i vanlig forstand, snarere en kategorisering. Allikevel noe som gjør at utviklerne må diskutere forståelsen av en PBI og så si noe grovt om størrelsen på jobben. Skal ikke ta veldig mye tid og blir ikke særlig nøyaktig. Men MYE bedre enn ingenting!
Planning Poker
Dette er en metode som er litt mer sofistikert enn T-skjorte metoden. Vi bruker her en tallskala som er mer finkornet basert på Fibonacci som representeres på fysiske (eller virtuelle) kort. Det finns en del varianter men de fleste har følgende skala: 0,1,2,3,5,8,13,20,40 og 100. Bemerk at Planning Poker bør spilles med streng 2-minutters tidsboksing, og følger man dette vil hva som helst kunne estimeres av et team på maks 14 minutter.
Du kan finne kortstokker og lese mer om denne teknikken her: https://smidigkurs.no/produkt/planning-poker-kort/
Strategisk planlegging
Hvordan vet vi om vi har de kapabilitetene vi trenger for å nå neste Produktmål? Har vi nok fart, eller bør vi skuffe på mer køl? Hvordan ser den sannsynlige framtiden ut basert på det vi vet i dag? Vi må stille oss disse spørsmålene selv om usikkerheten er stor.
Velocity
Selv om dette ikke lenger er en del av Scrum, blir det knyttet til Scrum og svært ofte med negativt fortegn. Og det er forståelig, siden det ofte blir misbrukt. Men brukt riktig, kan dette faktisk være til god hjelp.
Velocity forteller som navnet indikerer noe om teamets fart. Hvor “mye” lager dette teamet per Sprint? Dette gir oss da historikk for et bestemt team, noe som kan være veldig nyttig når vi skal forsøke å spå om framtiden. En slags krystallkule med andre ord.
Det ER ekte vanskelig å uttale seg med noen grad av sikkerhet om framtiden – men det betyr ikke at det er verdiløst å forsøke.
Velocity hviler på noen forutsetninger:
- Et ganske stabilt team
- At alle estimater er relative til en referansesak som alle kjenner
- Sprinter med fast lengde
- At vi er komfortable med usikkerhet og det faktum at vi ikke har all informasjon tilgjengelig
- At det ikke foreligger noen som helst form for belønning for å øke farten eller at man blir målt på presisjonen.
Dette kombinerer veldig godt med Planning Poker, men man kan også bruke T-skjorte metoden.
Grafen forteller bare at med dette teamet er det sannsynlig at vi kan holde en gjennomsnittsfart på 36. Dette trigger da spørsmålet – “er dette tilstrekkelig?” Skal vi øke ambisjonsnivået og dermed kostnadene for å få høyere fart? Eller kanskje vi kan bremse opp litt og ta ut et par teammedlemmer og heller bruke de på et mer strategisk viktig produkt? Velocity gir også et godt grunnlag for å lage et veikart (road map) for produktet slik at man kan ha gode strategiske diskusjoner om produktet og markedet.
Sprint status
Scrum er jo basert på at alt arbeidet gjøres i Sprinter med et klart mål. Vi forutsetter at i en Sprintperiode (1-4 uker) har vi noenlunde kontroll og et noenlunde stabilt utviklerteam. Vi forventer ikke store overraskelser i denne perioden, men vi lever fint med noe usikkerhet.
Så hvordan kan da et team ta “riktig” mengde arbeid inn i en Sprint? Hvordan kan de evaluere sin egen framdrift underveis og uttale seg om de vil nå Sprintmålet eller ikke? Både PO og interessenter vil gjerne vite så tidlig som mulig om Sprintmålet er innen rekkevidde eller ikke. Det viser seg i praksis at dette er svært vanskelig for urutinerte team (uansett hvordan man angriper det), men helt overkommelig etter en del Sprinter.
I tidligere versjoner av Scrum Guiden var det krav til at man under Sprint planlegging delte opp PBI-ene i oppgaver og estimerte disse. Deretter skulle utviklerne lage burndown-graf som viser daglig gjenstående arbeid opp mot gjenstående kapasitet.
Sprint burndown er ikke lenger en del av Scrum – siden det er flere måter å angripe dette på. Ikke dermed sagt at det er en dårlig ide, det tar ikke mange minuttene hver dag å oppdatere dette.
Alternativt, i stedet for å estimere kan man bare telle antall gjenstående oppgaver og lage en burndown ut fra dette. Andre utviklerteam vil bare sørge for at PBIene er såpass små at man bare kan telle antall gjenstående og lage en tilsvarende graf uten å estimere. Mange muligheter!
Epilog
Scrum krever svært lite når det gjelder estimering – kun at man er i stand til å gjøre kost/nytte vurderinger og å lage en grov prognose. De som skal gjøre jobben må altså bruke litt innsats på å forsøke å si noe om fremtiden – både på kort og lang sikt – uten å bruke for mye tid og energi på det. Her er noen punkter som kan være til hjelp:
- Vi estimerer ikke for å “få rett”. Vi estimerer for å si noe om en sannsynlig fremtid basert på den informasjonen vi har i dag. En prognose.
- Ikke bruk estimering til oppfølging. Suksess har ingen ting med estimeringspresisjon å gjøre.
- Estimer som team – så langt det er mulig. En nyttig bi-effekt av dette er at man får antagelser på bordet og at det “bygger team”.
- Estimer med tidspress.
- Lev med grove anslag og usikkerhet.
Ikke-funksjonelle krav i Scrum
Hva er ikke-funksjonelle krav?
Man kan si at dette beskriver hva et produkt er (eller skal bli), mens funksjonelle krav beskriver hva det gjør (eller skal gjøre). Funksjonelle egenskaper håndterer vi enkelt gjennom å beskrive synlige funksjoner i brukergrensesnittet – i Scrum som Product Backlog elementer. User Story formatet er godt egnet til dette. Ikke-funksjonelle egenskaper/krav er slikt som kompatibilitet, sikkerhet, ytelse, responstider, forsinkelse, vedlikeholdsvennlighet, skalerbarhet, brukervennlighet, tilgjengelighet, robusthet, feil-toleranse etc etc. (går ofte under samlebetegnelsen “-ilities” på engelsk) Enkelte av disse vil ha påvirkning på brukergensesnittet, men vil også typisk stille krav til design og arkitektur, valg av rammeverk og hardware.
Hvordan håndtere dette?
For det første er dette er område som krever tett og godt samarbeid mellom forretningssiden og utviklerne. Og det fordrer reell tverrfaglighet i utviklingsteamet. Alle slike krav vil koste innsats og enkelte også investeringer. Derfor blir også dette en kost/nytte vurdering – som faktisk må gjøres løpende. De første produktinkrementene skal kanskje først og fremst validere antagelser rundt verdiforslaget og vil derfor godt kunne ha svak robusthet og mangle feiltoleranse. Det er liten vits i å lage et bunnsolid, feil-tolerant (og dermed dyrt) produkt som løser feil problem.
Hvor i Scrum adresseres dette?
Som nevnt må dette adresseres tverrfaglig, i Scrum i tett samarbeid mellom Product Owner og utviklerne. Mens de funksjonelle kravene enkelt resulterer i Product Backlog elementer, vil de ikke-funksjonelle måtte håndteres med ulike strategier. Vi må her ta i bruk det totale rammeverket.
Visjonen
Det starter med den langsiktige visjonen (som ikke er definert inn i rammeverket – men som bør være på plass). Hvordan ser suksess ut om 2-5 år? Går vi for “verdensherredømme” eller nøyer vi oss med en liten nisje? Hvor viktig kommer vekst og skalerbarhet til å bli for suksess? Skal vi inn i et marked med strenge regulatoriske krav? Kan liv og helse stå på spill med dette produktet? Skal vi konkurrere på brukervennlighet? Hvilke kompatebilitetskrav er det?
Produktmål
For å oppnå visjonen må vi nå en serie med produktmål. Et produktmål har gjerne en tidshorisont på mellom 3 måneder og et år. En Product Owner må gjerne definere en serie med produktmål som da vil fungere som en Road Map for produktet. Hvert av disse må være tydelig på ikke-funksjonelle krav. Hva er hovedhensikten med dette målet? Hvilke brukere adresserer det og hvilke krav vil denne brukergruppa sette til produktet? Vil rask responstid og høy ytelse være avgjørende for disse menneskene? Er vi avhengige av gamle softwarekomponenter, må vi ta med i betraktning om disse har teknisk gjeld må betales ned som en del av jobben. Vil de arkitekturprinsippene softwaren er basert på skalere godt nok, eller må vi gjøre om?
Product Backlog
Ikke-funksjonelle krav vil ofte ende opp som konkrete elementer i Product Backlog. De må da priorities på vanlig måte opp mot andre elementer, både av den funksjonelle og den ikke-funksjonelle typen. Dette er krevende, for her må man avveie tekniske egenskaper som ikke er synlig på overflaten mot synlig funksjonalitet som kan ha en mer åpenbar forretningsmessig verdi. Her er det ekstremt viktig at Product Owner og utviklerne har et tett, tillitsfullt og godt samarbeid.
Sprintmål
For å realisere neste Produktmål gjennomfører vi en serie med Sprinter med formål å oppnå Sprintmål. Disse baserer seg på valgte elementer i Product Backlog. Enkelte ikke-funksjonelle krav vil resultere i Product Backlog elementer som da skal prioriteres inn av Product Owner. Andre kan være vanskelig å knytte til spesifikke funksjoner. Ting som sikkerhetskrav, gode sanntidsegenskaper og høy ytelse kan være verdt å gjøre til en generelt prinsipp. Det kan i så fall gjøres til en del av Definition of Done.
Definisjon av Ferdig
Man kan se på Definisjon av Ferdig (Definition of Done) som en sjekkliste for det kvalitetssikrende arbeidet et produktinkrement skal ha gjennomgått. Alle punktene representerer arbeid, som vil ta tid, og som da definerer det kvalitetsnivået utviklerne mener de trenger for å ende opp med et godt produkt uten for mye feil og teknisk gjeld. Mao, der det ikke-funksjonelle har en generisk karakter og skaper en ramme for “alt vi gjør”. Hvis sikkerhet er kritisk for suksess, vil de da typisk legge til gjennomkjøring av en egen sikkerhetstest for å kunne si at noe er “Ferdig”. Hvis de sliter med teknisk gjeld, stiller de krav til at man “rydder i gammel kode” som en del av jobben.
Scrum er mer åpent enn mange tror
En av hovedgrunnene til at Scrum er så populært er nok enkelheten. Rammeverket inneholder veldig få, men ganske rigide regler. Innenfor de gitte rammene er det – for mange – overraskende stor frihetsgrad. Scrum beskriver ikke hvordan du skal gjøre jobben, men gir noen rammer og sørger for at man ved jevne mellomrom stopper opp, reflekterer og gjør små tilpasninger og forbedringer. Dette kalles empirisk prosesskontroll, som da er motsatsen til definert prosesskontroll.
Scrum er designet for å løse komplekse problemer der det er for stor usikkerhet til at det er fornuftig å låse seg til et omfang. Man vil oppdage nye krav og behov mens man gjør jobben og stadig lære av erfaring tett sammen med brukerne.
Organisasjoner som strever med å bli mer digitale, mer smidige, raskere eller høyne kvaliteten kan med fordel innføre Scrum som en slags motor for de nødvendige endringene. Men først og fremst er Scrum egnet til å maksimalisere verdien som skapes for kundene. Sterke, tverrfaglige team som er autonome nok til å selv kunne avslutte det de har startet på uten hindringer er idealet. Det kan være en lang reise å komme dit.
Det gjelder å prioritere hva man skal bruke kapasitet på – mao finne ut hva man IKKE skal bruke kapasitet på – tett sammen med markedet/brukerne. Med Scrum blir man i stand til til å gjøre tydelige prioriteringer gjennom en lett tilgjengelig Product Backlog som gjenspeiler et overordnet produktmål.
Vi ser en økende tendens til at mange ulike roller kommer på Scrum-kursene våre i Lean Venture. De kommer både fra forretningssiden, ledelse, design, drift, HR i tillegg til “teknisk”. Dette er naturlig siden Scrum adresserer hele verdikjeden, ikke bare utvikling.
Neste Certified Scrum Master 23 august (online) https://smidigkurs.no/kurs/certified-scrum-master-2021-23-08/
Neste Certified Scrum Product Owner 30 august (Oslo): https://smidigkurs.no/kurs/certified-scrum-product-owner-30-08-2021/
En smidig organisasjon, ende-til-ende
Smidig (agile) blir fremdeles nå i 2020 adressert som et “IT-problem” som skal løses gjennom å innføre et eller annet agilt rammeverk i IT-avdelingen. Resten av organisasjonen gjør som regel visse endringer, men fortsetter stort sett som før. Selv om de har forretningsmessige ambisjoner om å bli raskere, mer fleksible eller mer pålitelige, ser vi sjelden helhjertet innsats for å transformere forretningssiden eller ledelsen.
Agile var i utgangspunktet en bevegelse som i 2001 formulerte et manifest for å hjelpe IT-verdenen ut av et ganske dysfunksjonelt, ineffektivt styringssett. Fokuset for de 17 opphavsmennene var programvareutvikling, som på den tiden begynte å bli virkelig forretningskritisk for de fleste organisasjoner i de fleste bransjer. Nå, i 2020, kan vi bytte ut “de fleste” med “alle”.
Det er kanskje ikke så merkelig at dette manifestet blir tolket som “et IT-problem” som har sin løsning i IT-avdelingen. Problemet med denne tankegangen er at ingen IT-avdeling er frakoblet alle andre avdelinger i en organisasjon. Det settes i gang agile transformasjoner over en lav sko for tiden, men med alt for snevert fokus. Jeg har mange ganger de siste 15 årene vært vitne til all forvirringen, friksjonen og frustrasjonen som oppstår når man forsøker å styre IT med et helt annet tankesett enn det som gjelder ellers. Om ledelsen, salg, HR, forvaltning, finans etc fortsetter å tenke og operere tradisjonelt, kommer man ikke langt. Innføringen av agile blir en skuffelse og ofte reelt sett en forverring, snarere enn forbedring.
Virkelig smidige organisasjoner adresserer endringen i full bredde; Det går “ende-til-ende”, tvers igjennom alle verdikjeder – det berører alle nivåer og alle funksjoner. Først da vil man klare å ta ut det fulle potensialet som ligger og venter. Etter min mening er det nødvendig å angripe organisasjonsdesign med systemtenkning , der man anerkjenner at alt henger sammen med alt. Ting er dynamisk, altså ikke ikke lineært, dette i skarp kontrast til det tradisjonelle synet der man fremstiller organisasjonen som ulike bokser i et kart og tverrgående, definerte prosesser. Vi kan bare glemme å optimalisere enkelte enheter separat. Det vi trenger i dag er akkurat det Peter M. Senge beskrev i den etter hvert legendariske boka The Fifth Discipline, the Art & Practice of The Learning Organization i 1990. Vi er i stadig økende grad henvist til å bygge organisasjoner som er kontinuerlig lærende og som evner å gjenskape seg selv når det er nødvendig. Agile organisasjoner eksperimenterer, lærer og tilpasser seg omgivelsenes dynamikk.
Valg av riktige metoder og rammeverk er viktig, men slett ikke det eneste som betyr noe. Dette er kun én av de 8 bitene i det komplette puslespillet som må legges. De 8 områdene er
- Lederskap
- Struktur
- Mennesker
- Kundeforståelse
- Budsjettering og styring
- Metoder og rammeverk
- Håndverk og kvalitet
- Kultur og tankesett.
Hver og en av disse må basere seg på det samme, smidige tankesettet.
Alle brikkene må være på plass. Ta vekk en og du vil oppleve friksjon, hindringer og frustrasjon.
Spørmålet er: Hvordan kan vi gjennom et smidig tankesett skape en organisasjon som er optimalisert for flyt og kundetilfredshet og som endrer seg raskt når det er nødvendig? Hva krever dette av ledelse, struktur, folk, finans, rammeverk, kvalitet og kultur?
Lederskap
Forutsetning: kompleksitet, dynamikk og usikkerhet gjør det nødvendig å fatte raske beslutninger med begrenset informasjon tilgjengelig
Måten organisasjonen styres og ledes på vil selvsagt ha et stor innflytelse på hvordan en smidig transformasjon vil arte seg. Moderne ledere forstår at det ikke bare er å fortelle/forklare hva som nå forventes – de må selv modellere endringen gjennom egne handlinger. De går foran med et godt eksempel.
Lederskap dreier seg om å stake ut kursen og å formidle denne på en slik måte at alle involverte gjerne vil være med. Formulere langsiktige visjoner, og legge strategier som innbefatter å lære underveis. Think big, start small, move fast er et godt mantra.
Man kan også si at ledelse dreier seg om å prioritere, det mangler aldri på ønsker om behov. Spørsmålet er “hva skal velges bort?” På mange måter handler ledelse om å bestemme hva man ikke skal gjøre, slik at det som er i fokus får mest mulig oppmerksomhet.
En smidig leder forstår at de ansatte må få eie sine egne prosesser, beslutninger og løsninger. Dette fordrer en lederstil som minner om coaching. Interessant nok var det akkurat dette som ble ranket som nummer 1 i en intern undersøkelse i Google (Ranked number 1 a great leader “Is a good coach”.)
Smidige ledere er ydmyke og aksepterer at det er umulig å ha alle svarene på forhånd. Man må våge å ta sjanser og tåle å mislykkes. Hvis man aldri feiler går det for sakte, og det blir ikke innovasjon.
Struktur
Forutsetning: Vi må optimalisere systemet for rask arbeidsflyt med få hindringer og høy grad av samarbeid
Hierarkiske nivåer og funksjonelle “siloer” hindrer rask flyt. Tradisjonelle organisasjoner domineres av overleveringer av arbeid og beslutninger mellom ulike funksjoner og mellom ulike eskaleringsnivåer, noe som i sin tur forhindrer god flyt og rask eksekvering. En smidig struktur gir stor grad av myndighet til sterke, tverrfaglige, ansvarlige team som jobber så direkte som mulig med kundene.
Konsekvensen av dette er et synkende behov for mellomledere. Disse teamene, støttet av produkteiere med myndighet til å prioritere, samt Scrum Mastere eller agile coacher kan operere ganske autonomt. Kravet er selvsagt at de stadig beveger seg i retning av de overordnede målene staket ut av ledelsen.
I smidige organisasjoner blir roller noe mindre viktig, mens det tverrfaglige, tette samarbeidet og den kollektive ansvarsfølelsen løftes opp. Det blir tydelig at det hele er et lagspill der man hjelper til der det er nødvendig, selv om det som trengs er litt utenfor kjernekompetansen. Her vil det være vesentlig at målstyrings- og belønningssystemer verdsetter kunnskapsdeling og samarbeid framfor individuelle prestasjoner.
Mennesker
Forutsetning: Folkene som gjør jobben er den viktigste suksessfaktoren, og de gode, raske beslutningene tas tett på virkeligheten av de som utfører.
Smidige organisasjoner er avhengige av å ansette og utvikle team-orienterte folk som liker å lykkes sammen med andre og gjerne tar et kollektivt ansvar. Noen mennesker elsker samarbeid med andre og følelsen av å lykkes i et fellesskap, mer enn å bare fylle en rolle. Viktig å sette sammen team med folk med en slik instilling. Allikevel er det helt nødvendig å ta gruppedynamikk og den mellommenneskelige faktoren på største alvor. Det er naivt å tro at alle team vil bli høypresterende helt av seg selv. De vil trenge gode coacher (som for eksempel en Scrum Master bør være) som klarer å hjelpe teamene gjennom gruppedannelsen, skape en kollektiv teamfølelse, finne gode måter for konflikthåndtering osv.
Smidige medarbeidere motiveres av å være i stadig utvikling (se Carol Dweck – growth mindset). De er ikke redde for å forsøke seg på nye ting og blir gjerne med på eksperimenter med usikkert utfall så lenge de lærer av det. Denne adferden fordrer en stor grad av psykologisk trygghet (i følge Amy Edmondson er dette en forutsetning for læring), der alt er transparent og ingen forsøker å skjule at de tok feil.
Som Senge skriver om i 5th dicipline er Personal Mastery en avgjørende byggesten i lærende organisasjoner. Sterke, høypresterende team med tilgang til gode agile coacher kan gjerne gis full tillit når det gjelder å bruke tid og penger på selvutvikling.
Kundeforståelse
Forutsetning: Det er kundenes tilfredshet som til syvende og sist vil avgjøre om vi lykkes eller ikke
Den brutale dommen om hvorvidt produktet eller tjenesten lykkes i markedet får vi fra sluttbrukerne. Hvis de får sine problemer løst på en så god måte at de blir begeistret, kommer vi til å gå med overskudd. Ambisiøse, smidige organisasjoner er besatt av disse menneskene. Vi bør forstå kundene bedre enn de gjør selv. Når vi serverer de nye løsninger bør vi alltid spørre oss: Hva er jobben dette produktet skal gjøre for disse personene som er bedre enn det de allerede har. Anbefaler alle å finne inspirasjon fra Clayton M. Christensen sitt Job-to-be-done konsept.
Kundene er sjelden i stand til å forklare akkurat hva de trenger slik at vi bare kan sette i gang og lage det. Vi må sette i gang å lage det basert på en rekke sterke og svake antagelser. Vi vet altså aldri hvor godt vi traff før de tar det i bruk. Da gjelder det å fange opp – i retrospekt – hvor fornøyde de ble og hva vi burde justere på slik at vi treffer enda bedre. Smidige team begynner gjerne med å lage en veldig billig, rask representasjon av produktet – gjerne en prototype – slik at vi kan få verdifull feedback fra kundene. Dette kan gjøres systematisk i sykluser, gjerne kalt “build-measure-learn” som Eric Ries definerte i sin Lean Startup bok.
Budsjettering og styring
Forutsetning: Vi kommer til å støte på hindringer vi ikke kan vite om, og vi kommer til å oppdage interessante ting av betydning mens vi gjør jobben.
Det gjelder å ha en realistisk virkelighetsforståelse og å være ydmyke nok til å innrømme at det vi trodde på i starten viste seg å ikke holde stikk. Noen ganger gjelder det å stoppe i tide og heller bruke ressurser på et helt annet problem. Andre ganger holder det kanskje å justere kursen noe. Uansett – i dagens virkelighet må vi styre mot bevegelige mål og derfor unngå å låse oss før vi er nødt. Vi må tåle å jobbe med et ganske åpent omfang som blir til underveis. Hverken tradisjonelle, årlige budsjettprosesser eller prosjektfinansiering (a´la PMI) vil fungere godt. Gå heller for Beyond Budgeting som opererer med prinsipper, verdier og tankesett som er fullt ut kompatible med agile.
Prosjekter er jo per definisjon en midlertidig, fokusert organisasjon som har et klart mål og slutt-termin. Det skal mye til at et prosjekt ikke detaljerer og låser omfanget i langt større grad enn virkeligheten egentlig tillater. Et bedre alternativ vil for de fleste være å finansiere faste, tverrfaglige team med solid domenekunnskap og som på den måten enklere jobber mot bevegelige mål med et ganske åpent omfang.
Kontraktering av leverandører og innkjøps- og anskaffelsesregler vil – særlig i offentlig sektor – gjøre det vanskelig å være smidig. Disse prosessene er ofte tunge og tidkrevende, og har som forutsetning av vi vet hva vi skal lage. Så det klare rådet til alle IT-avhengige virksomheter vil være å ansette en kritisk masse gode folk selv, og så heller leie inn flinke konsulenter ved behov.
Virkelig smidige organisasjoner er gjennomsiktige. Interessenter kan enkelt se med egne øyne hva som foregår og hva som skapes av verdi. Visjon, strategi, prioriteter, mål, Product Backlogs osv publiseres åpent. Demonstrasjon av nye produktinkrementer gjøres jevnlig og det skjer hyppige leveranser til sluttbrukerne. På denne måten vil fokus dreies fra å følge opp ift milepæler til å fokusere på faktisk skapt verdi. Hvor mange nye kunder fikk vi som resultat av denne nye funksjonen? Hva skjedde med kundetilfredsheten når vi skrev om den modulen? Fikk vi den ytelsesforbedringen vi hadde håpet på med det nye produktinkrementet?
Metoder og rammeverk
Forutsetning: Det finnes ingen ferdig, standard beste måte å jobbe på. Alle team må gjøre sine egne tilpasninger.
Ingen tvil om at dette området har fått mest oppmerksomhet når organisasjoner har forsøkt å “innføre smidig”. Det er opplagt viktig at man velger rammeverk og metodikk som legger opp til iterasjoner og kontinuerlig forbedring, men det er altså ikke nok. Alle de andre områdene må endres i takt med dette. Innfør gjerne Scrum, det desidert mest populære rammeverket. Men en “mekanisk” tilnærming til Scrum, uten at ta med et smidig tankesett og høy håndverksmessig standard bringer liten om noen forbedring.
Det valgte rammeverket må være “lett-vekt” altså ikke gå for langt i å beskrive en detaljert, standard måte å jobbe på. Målet må være å oppnå Empirisk prosesskontroll der gjeldende metoder, verktøy og teknikker stadig forbedres basert på det man erfarer. Hyppige leveranser og rask feedback må være integrert. Og rammeverket må støtte selvorganisering i tverrfaglige team som er i stand til å selv fullføre det de har startet på.
Håndverk og kvalitet
Forutsetning: Det er fullt mulig å oppnå rask arbeidsflyt uten å kutte hjørner, uten å kompromisse på kvalitet
Det er svært stor forskjell på å lage en prototype med formål å teste antagelser og å lage et produktinkrement med forventet levetid på mange år. I begge tilfeller må teamet som gjør jobben velge det riktige nivået av kvalitetssikrende aktiviteter. Vil det være nødvendig å bruke TDD (Test Driven Development) med fullt sett av automatiske tester innbakt, eller ikke? Er det egnet for parprogrammering? Skal vi kjøre formelle code reviews?
Gode, smidige team opparbeider seg kapabiliteter både når det gjelder teknisk eksellense og yrkesetikk. De har et langsiktig perspektiv og de vet godt at det å ta snarveier i dag må vi selv betale for i fremtiden. Drivkraften til denne sterke yrkesstoltheten kommer av det sterke eierskapet som følger av tilliten teamene vises av organisasjonen rundt. Det er deres problem, og om de lykkes eller ei er opp til dem selv.
Alle interessenter må være klar over at ingen er tjent med å akkumulere opp teknisk gjeld i produktet. Selv om de ofte er utålmodige og gjerne skulle hatt leveranser “i går” må de finne seg i at det tar den tiden det tar. Det eneste de kan gjøre selv er å være bevisste på å prioritere godt, slik at den begrensede kapasiteten man rår over benyttes til å skape mest mulig verdi – underforstått at man klarer å velge bort kjekt-å-ha funksjoner som brukerne godt kan klare seg uten.
Kultur og tankesett
Forutsetning: Bedriftskultur vil alltid henge sammen med struktur og et smidig tankesett må ledsages av smidige strukturer.
Med organisasjonskultur mener vi de mønstrene av meninger, verdier, normer, roller og adferd som går igjen og som skaper identitet. Kulturen dannes av historiske hendelser med tilhørende fortellinger, men påvirkes også i stor grad av de rådende strukturer, visjoner og lederstiler. Det vil være håpløst å endre firmakutur uten å samtidig adressere strukturelle faktorer. Craig Larman har vært med på å transformere en mengde store selskaper i retning av agile og har konkludert med at det er umulig å endre firmakultur uten å endre strukturer (se Larman´s laws of Organizational Behaviour). Scrum er et godt eksempel på et rammeverk som fordrer ganske radikale strukturelle endringer og som dermed kan påvirke firmakulturen i retning av agile. Avdelingsskiller, eskaleringsnivåer, belønningssystemer, målstyring osv er eksempler på strukturelle faktorer av stor betydning for innføring av et smidig tankesett.
En smidig bedriftskultur har en del klare kjennetegn:
For det første må alle være innstilt på å ta sjansen på å feile – det må oppleves som trygt å våge på noe nytt og ukjent. Denne tryggheten mangler i de fleste tradisjonelle selskaper, der mye er gjort for å unngå feil. I en slik kultur vil folk (bevisst eller ubevisst) forsøke å skjule feil. Dette er et formidabelt hinder for både nyskapning og læring.
Et annet viktig kjennetegn for en smidig kultur er å anerkjenne at vi stadig er i endring. Med jevne mellomrom ser man seg tilbake og forsøker å finne bedre måter å jobbe på.
Det vil også være helt avgjørende at laveste nivå – tverrfaglige, ansvarlige, utførende team – har myndighet til å ta selvstendige beslutninger – forutsett av man jobbe i riktig, omforent retning og at det er transparent.
I smidige organisasjoner legger de vekt på å ha et growth mindset og de vil bevisst forsøke å ansette medarbeidere med en sterk drift mot å utvikle seg og forsøke nye ting.
Det vil være stort fokus på samarbeid. Ingen sitter alene med et problem – man sitter i stedet rundt det samme (fysiske eller virtuelle) bordet og løser problemer i tverrfaglighet. Derfor er det avgjørende med en kultur for samhandling og deling av kunnskap og informasjon. Belønningssystemer som i stor grad måler prestasjoner individuelt kan være en formidabel “show-stopper” her.
Konklusjon
Du kan ikke kjøpe agile. Du kan kjøpe Scrum kurs og du kan engasjere konsulenter og coacher, men dette vil ikke ta deg langt alene. Hele organisasjonen – med ledelsen i spissen – må ta eierskap til og ansvaret for omstillingen. Det finnes ingen fiks ferdig modell å rulle ut (vel, det er mange som selger slikt og det kan være en besnærende tanke selv om det er dyrt) men det vil ikke fungere. Et smidig tankesett får man gjennom å innse at løsningene må vi finne sammen og at det er de som gjør jobben som også må få selv-organisere rundt felles mål og visjoner. Ledelsen må gå foran og være smidige rollemodeller.
In: Coaching, Customer Development, Endringsledelse, kompleksitet, ledelse, selvorganisering, systems thinking, Tillit
Hvordan vokse i Scrum Master rollen
Hva slags ferdigheter og kunnskaper trenger en profesjonell Scrum Master egentlig? Og hvordan utvikler man seg som Scrum Master?
Vi trenger dedikerte, gode Scrum Mastere! Men det har hittil vært svært begrensede tilbud på markedet for å utvikle Scrum Master rollen videre etter et vanlig to-dagers Certified Scrum Master (CSM) kurs. Nå har (endelig) Scrum Alliance lansert en vei videre fra CSM. Dette er et løp som tar minimum 2 år å gjennomføre og som innebærer både opplæring og praktisering.
CSM-kurset er jo å betrakte som et introduksjonskurs for alle som vil lære seg Scrum og agile (“smidig”). Veldig mange har tatt dette (vi i Lean Venture har sertifisert mer enn 2.500 bare i Norge) og vi vet at de fleste spør seg om dette egentlig er nok for å praktisere denne rollen på en god måte. Vi tror ikke det. Når vi kommer på innsiden i organisasjoner for å støtte med innføring av Scrum, ser vi at rollen svært sjelden praktiseres slik den er ment. Det er nok flere årsaker til dette, men den viktigste forklaringen er at denne rollen er veldig uvant for de fleste organisasjoner. Vi ser at få ledere er oppmerksom på at en Scrum Master er en endringsagent som skal utfordre alt som hindrer god flyt i arbeidet. Dette inkluderer ofte ledernes egen adferd…
En ScrumMaster er en Agile Coach
Når man leser Learning Objectives for Advanced Certified ScrumMaster blir det tydelig at denne rollen har mye til felles med en coach. Veldig mye dreier seg om å opptre som en nøytral, positiv fasilitator og coach som hjelper teamene til å forbedre arbeidsflyten i små trinn. En god Scrum Master må kunne drive opplæring (innen agile og Scrum) og må ha ferdigheter innen coache- og fasiliterings-teknikker. Fokus for Scrum Master er å støtte utviklingsteam og produkteier slik at de stadig fungerer bedre og bedre sammen. Men Scrum Master må også ta ansvar utover dette. Scrum team vil støte på hindringer fra omgivelsene, og det er ofte her de store forbedringsområdene befinner seg.
En god leder er en god coach!
Tiden vi lever i er preget av raske omveltninger, usikkerhet og kompleksitet hvilket fører til nye krav til ledere. Moderne ledere må være ydmyke i forhold til at de ikke selv har svarene eller kan ta for mange avgjørelser selv. Moderne organisasjoner trenger ledere som gir slipp på direkte kontroll og i stedet sørger for å gjøre medarbeiderne i stand til å styre seg selv. Alt dette fordrer en adferd som minner veldig mye om coaching.
I google har de gjort systematiske undersøkelser rundt hva som kjennetegner de beste lederen og konkluderer med at de tre viktigste tingene er:
- Er en god coach
- Gir team stor grad av myndighet
- Skaper inkluderende team-omgivelser og psykologisk trygghet.
Advanced CSM i Oslo i september
Vi har gleden av å tilby Norges første A-CSM i Oslo 26 september! (NB: Early Bird pris fram til Her kan du ta skrittet videre og finne ut hvordan du virkelig kan utgjøre en forskjell. På disse to dagene vil du lære å fungere som en endringsagent, som stadig utfordrer det bestående og hjelper organisasjonen til å gradvis få bedre flyt i arbeidet.
Innhold:
- Lean, agile og Scrum: hvordan henger det hele sammen
- Fasiliterings-teknikker (Diverge / Converge)
- Coacheteknikker (basert på Co-active coaching og systemcoaching (ORSC))
- Hvordan støtte utviklingsteamet
- Hvordan støtte produkteier
- Hvordan støtte organisasjonen
- Hvordan dyrke og videreutvikle Scrum Master rollen
In: Coaching, ledelse, Scrum, Uncategorized
Ny versjon av Scrum Guiden – hva er nytt?
Den 7. november kom det en ny oppdatering av Scrum Guiden – som er selve definisjonen av Scrum. Denne guiden er skrevet og vedlikeholdes av Ken Schwaber og Jeff Sutherland. Det var Schwaber og Sutherland som først beskrev Scrum i 1995. Den første versjonen av Scrum Guiden kom i 2010 og det er senere gjort 4 oppdateringer.
Den nye versjonen av Scrum Guiden inneholder både presiseringer for å unngå misforståelser, språklige rettelser og noen endringer av mer prinsipiell karakter. I denne posten fokuserer vi på de viktigste endringene.
Kontinuerlig forbedring
Kontinuerlig forbedring har alltid vært en svært viktig del av Scrum, men gjøres nå enda mer eksplisitt. Sprint Retrospektiv inkluderer nå at ”Scrum teamet planlegger tiltak for å øke produktets kvalitet ved å forbedre arbeidsprosesser eller justere definisjonen av Ferdig.”
Dette kommer også til uttrykk i Sprintkøen. “For å sikre kontinuerlig forbedring skal Sprintkøen inneholde minst en høyt prioritert forbedring identifisert i det foregående Sprint Retrospektive møtet.”
Scrummøter
Det er gjort en generell presisering for å bedre få frem at tidsboksen for møtene er maksimal tid som kan brukes, og at man kan bruke kortere tid dersom formålet med møtet er oppnådd.
Daglig Scrum
I den nye versjonen er det presisert at det er forskjellige måter å gjennomføre Daglig Scrum på. En forutsetning er at Utviklingsteamet fokuserer på sin fremdrift mot Sprintmålet. Dette gjøres ved å inspisere arbeidet og resultatene fra sist Daglig Scrum og tilpasse arbeidet for de neste 24 timene for å optimalisere samarbeid og ytelse. Det utbredte “3 spørsmål” formatet er kun et eksempel og altså ikke en regel.
De 3 spørsmålene nevnt i Scrum Guiden er:
Hva gjorde jeg i går som hjalp Utviklingsteamet å oppfylle Sprint målet?
Hva planlegger jeg å gjøre i dag for å hjelpe Utviklingsteamet å oppfylle Sprint målet?
Ser jeg noen hindringer som forhindrer meg eller Utviklingsteamet å oppfylle Sprintmålet?
Produktkøen
“Produktkøen er en ordnet liste som inneholder alt som er kjent av krav til produktet.”
Tidligere ordlyd var ”alt som kan være nødvendig..”
Hensikten bak denne presiseringen er at Produkteieren kun skal legge til elementer i Produktkøen som hun mener skal realiseres i et fremtidig produktinkrement. Gode ideer, tanker og lignende som ikke er validert som krav som skal inn i et fremtidig produktinkrement skal ikke legges i Produktkøen. På denne måten holdes Produktkøen kortere og den blir lettere å håndtere.
Inkrementet
Det er gjort en presisering rundt inkrementet for at det skal være lettere å forstå hva et inkrement er. “Et inkrement er et stykke inspisertbart ferdig arbeid som støtter opp under empiri ved slutten av Sprinten. Inkrementet er et steg mot en visjon eller mål.”
Scrum er ikke bare for IT
Det er lagt til et nytt kapittel som heter Bruk av Scrum. Scrum brukes i dag mye bredere enn utvikling av programvare. Scrum brukes i markedsføring, infrastruktur, embedded software, skoler og akademia. Scrum er et rammeverk for komplekse problemer – og utvikling av programvare er ofte komplekst.
For å unngå videre misforståelser har man også gjort det tydelig at ordene ”utvikle” og ”utvikling” referer de til komplekst arbeid når de brukes i Scrum Guiden. Det betyr at medlemmene av Utviklingsteamet er personer som utøver komplekst arbeid.
Scrum Master
Rollen som Scrum Master er ofte misforstått og den siste utgaven at Scrum Guiden forsøker å rette opp i noen vanlige misforståelser.
“Scrum Masteren er ansvarlig for å promotere og supportere Scrum, slik det er definert i Scrum Guiden. Scrum Mastere gjør dette ved å hjelpe alle med å forstå Scrum sin teori, praksis og regler og verdier.”
Tanken bak denne reviderte teksten er at man som Scrum Master skal ”promotere og supportere” på en positiv måte. Dette gjelder både for Scrum teamet og de utenfor teamet.
Alle Scrum Team jobber i en kontekst og under visse rammebetingelser. Denne konteksten og rammebetingelser har stor innflytelse på hvor effektiv Scrum teamet kan være. At Scrum Master lærer bort, er en mentor og coach for organisasjonen utenfor Scrum teamet er avgjørende for å kunne optimalisere rammebetingelsene Scrum teamet jobber i.
Det er også lagt til et punkt for hvordan Scrum Master støtter Produkteier. “Sikre at mål, omfang og produktdomene er forstått så godt som mulig av hele Scrum Teamet.”
Dette skal ikke tolkes dithen at Scrum Masteren gjør dette på vegne av Produkteieren, men betyr at Scrum Master har et ansvar for at Produkteier forstår viktigheten av dette og at Scrum Master støtter Produkteieren i å få dette til, f.eks gjennom coaching.
Formålet med denne bloggposten har vært å gå gjennom de endringene i Scrum Guiden som er viktigst for deg som praktiserer Scrum. Om du vil se en oversikt over alle endringene kan du finne det her.
Hva synes du om endringene i Scrum Guiden? La oss få dine meninger under!
Smidig dreier seg om styring og ledelse
Smidig-bevegelsen startet på slutten av 90-tallet i teknologitunge miljøer, med stor vekt på programvareutvikling. Dette forhindrer ikke at verdiene og prinsippene er allmenne og adresserer totaliteten i organisasjoner. Det kommer ikke så tydelig fram i manifestet, men smidig stiller sterke krav til både styring, organisasjon og ledelse. Smidig adresserer ende-til-ende prosessene som starter med et identifisert behov og ender med at dette behovet er tilfredsstilt.
Hensikt
Hovedhensikten med smidig er å skape organisasjoner som raskt fanger opp endringer og muligheter i markedet og som i tett samspill med brukerne leverer verdi i små inkrementer. Det dreier seg om å fatte raske, gode beslutninger med begrensede konsekvenser om det går feil.
Hensikten var i utgangspunktet ikke effektivisering. De som oppnår dette får det som en “spin-off”. Det var heller ikke meningen å skape en “nok en prosjektstyringsmetodikk”.
På den måten svarer smidig godt på dagens utfordringer, der kompleksitet, dynamikk og usikkerhet er økende. Dessuten er det et eksplisitt mål å skape gjennomsiktighet, slik at interessenter enkelt kan følge med på hva som skjer, framdrift og hvilke effekter som er skapt.
Konsekvenser
1. Læring viktigere enn planlegging
Smidig baserer seg på løpende planlegging, basert på fersk informasjon om status. Effekter oppnås gjennom leveranser av små produktinkrementer, som vi setter på prøve og sammen med brukerne lærer av. Denne lærdommen kan få konsekvenser allerede for neste inkrement i kjeden. Du blir altså mer drevet av den løpende læringen enn av de opprinnelige planene.
2. Beslutningsmyndighet på lavt nivå
En konsekvens av dette er at de fleste beslutninger av betydning må kunne tas på lavt nivå i organisasjonen, nærmest i sanntid. Eskalering forsinker prosessen, og fører lett til at beslutninger fattes med for lang avstand til realitetene. Tidlige ledelsesbeslutninger (for eksempel i budsjett og planprosesser) bremser læringen.
3. Opsjoner holdes åpne så lenge det er forsvarlig
En annen, beslektet konsekvens er at vi aktivt må unngå å låse oss før det er nødvendig. Vi må forsøke å holde muligetsrommet åpent, og akseptere at vi med tiden får mer informasjon og kunnskap, eller at virkeligheten rundt oss endrer seg mens vi jobber. Det vi på et tidspunkt hadde stor tro på, kan vise seg å ikke holde vann allikevel. Vi må med andre ord våge å begynne før vi har alle brikkene på plass.
4. Grov, tidlig analyse og planlegging
Dette gir i sin tur sterke føringer for hvordan vi må forholde oss til analyse og planlegging av store satsninger. Det som gjøres av forarbeide må fokusere på de store linjene: Hvilke effekter skal vi oppnå? For hvem? Hvordan er vi sikre på at vi gyver løs på riktig problem for disse menneskene? Hvilke løsningsalternativer skal vi forsøke på? Alt dette kan gjøres gjennom små eksperimenter, piloter og prototyper – i tett samarbeid med brukere. Viktig her å ikke sløse ved dyrebar kalendertid – vi må komme i gang slik at vi raskt kan begynne å skape noe verdig og å få testet ut antagelser. Og viktig å ikke gå for mye i detalj siden sjansene for at de må endres senere er stor.
5. Team med myndighet
Dette vil ha konsekvenser for hvordan vi organiserer arbeidet. Sterke tverrfaglige, selvstyrte team synes å være den løsningen som fungerer best. Hvis slike team forstår – og gjerne har et eierskap til – målene, vil kunne få en egen drivkraft og kunne løse problemene etter hvert som de nærmer seg målet.
6. Færre overleveringer
Rollebaserte prosesser fordrer en rekke overleveringer fra et behov er identifisert til det er tilfredsstilt. Når arbeidet leveres fra et trinn til det neste vil det danne seg køer og flaskehalser. Dessuten vil hver overlevering føre til indirekte kommunikasjon og øke faren for misforståelser (“hviskeleken”) Vi kan profiere på å ha direkte kontakt mellom kundene og de som gjør jobben.
Dette gjelder både horisontale (prosesstyrte) overleveringer og vertikale (hierarkiske) overleveringer.
7. Lavere hierarkier
Dersom en organisasjon bestemmer seg for at tverrfaglige team med stor myndighet er nederste nivået, vil det raskt vise seg at både hele nivåer i hierarkiet og spesifikke roller får mindre å gjøre. Mellomledere må dermed bli mer operative, og inngå i de verdiskapende teamstrukturene.
8. Kontinuerlig endring
Læringen vi får gjennom de korte iterasjonene brukes til systematisk prosessforbedring. Det teamet eventuelt støtte på av hindringer vil de forsøke å få fjernet til neste iterasjon. Og de kan nå enkelt prøve ut nye metoder og verktøy for å få enda raskere flyt og feedback å stole på. Det finnes ingen “beste praksis” som er overførbar fra andre organisasjoner. God praksis er lokal og må eies og forbedres av teamet selv.
9. Eksplisitt forenkling
Det kan ta mange ganger så lang til å lage en løsning som har komplett funksjonalitet enn en som er begrenset. Så – for å skape hurtighet og rask læring er det helt nødvendig å starte med det enkle, lille. Viser det seg å være en god løsning kan den utvides og gjøres mer sofistikert senere – hvis det er viktig for brukerne. Omprioritering resulterer ikke i tillegg, men fører til at noe faller ut. Gjennom en smidig produktplanlegging identifiseres også hva som ikke skal lages. Dette for å unngå “scope creep” og unngå for store og komplekse systemer.
10. Autonomitet i organisasjon og produkt
All verdens smidighet klarer ikke å oppveie for en rotete systemarkitektur med rigide koblinger mellom delsystemer. Dette vil føre til at selv små “uskyldige” endringer ett sted kan få følgeeffekter helt andre steder – og vi blir tvunget til omfattende koordinering og komplett regresjonstest selv ved marginale endringer. Hvis dette er utgangspunktet kommer man neppe utenom en omfattende redesign med tanke på autonomitet.
Organisasjonen vil ofte avspeile systemarkitekturen og vise versa (Conways law) – det vil koste krefter å rive seg løs fra dette. Men om organisasjonen i størst mulig grad består av selvdrevne autonome enheter vil de kunne operere langt raskere siden koordinerings- og planleggingsbehovet synker.
11. Feiltolerang kultur
Mange ledergrupper er klar over at de har en “risikoavers kultur” og forstår at de trenger å bli mer “feiltolerange”. Nå er det slik at kultur førlger struktur – man kan ikke angripe firmakultur alene uten å samtidig gjøre strukturelle endringer. Punktene over representerer slike strukturelle endringer som vil vise at det blir tryggere å feile. Medarbeidere på alle nivåer vil ved selvsyn oppleve at feilvurderinger blir begrensede og konsekvensene små. Dessuten ser alle at det er mulig å lære av feilene. Vi mennesker lærer mye mer av det som går galt enn av suksesser – dette er en nedarvet overlevelsesstrategi!
Endring
Den enkelte ledergruppe må gjøre seg opp en mening om hvor de står i forhold til disse konsekvensene, og hvilke aspekter de eventuelt ønsker å angripe først. Ikke sett i gang “storstilte endringsprogrammer” – sett i stedet tydelige overordnede mål og en retning. Kommuniser så tydelig hvilken retning man ønsker å gå og gjennomfør små, tydelige endringer. Ta ett skritt av gangen – eller som Dave Snowden ofte sier Change through small actions in the present.
Mer om alt dette på ALL-kurs (neste mulighet 9 november)
In: Endringsledelse, ledelse, Teamarbeid · Tagged with: kompleksitet, ledelse, organisasjon, Smidig, Styring
Å planlegge for det ukjente
Hvor langt kan vi se klart?
Erkjennelsen om at fremtiden er høyst usikker synker inn hos de fleste. Heldigvis. Vi vil opplagt tjene på å ha et realistisk syn på den virkeligheten vi befinner oss i. Hvilke konkrete implikasjoner har denne usikkerheten på måten vi setter mål, lager strategier, planlegger og følger opp? Og har det følger for hvordan vi bør organisere oss?
Virksomheter vil fortsatt sette seg store, ambisiøse mål som vil ta lang tid å oppnå. Vi må selvsagt fremdeles lage planer for dette.
En slik plan vil måtte basere seg på antagelser og forutsetninger. En leder- eller styringsgruppe bør nå snarest stille seg noen vitale spørsmål:
- “Hvor lang tid tar det før viktige forutsetninger ikke lenger er til stede?” og
- “hvordan endrer vi planen dersom dette skjer?“ og
- “hvordan detekterer vi raskt nok at vesentlige forutsetninger faktisk endrer seg?”
Det er altså en grense for hvor lenge en langtidsplan har verdi. Problemet er at den ofte vil få leve alt for lenge! Det er tross alt investert arbeid, penger og prestisje i denne planen. Dessuten har vi en tendens til å innbille oss at vi har med kontroll enn vi har grunnlag for.
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”
Mark Twain
Så vi reagerer alt for ofte alt for sent.
Den ene, lineære langtidsplanen har altså utspilt sin rolle. Hvordan ser et mer realistisk planleggingsbilde ut da? Slik?
Å navigere mot mål i bevegelse
Jeg vil her ta til orde for 5 essensielle tankesett for vellykket planlegging i dagens virkelighet:
- Hold opsjoner åpne
- Innhent status basert på fakta
- Unngå indirekte kommunikasjon
- Bygg inn retrettmuligheter
- Endring er positivt
1. Hold opsjoner åpne
Det vil fremdeles kunne ta år å oppnå ambisiøse mål. Samtidig må vi ha stor ydmykhet i forhold til at forutsetninger kan endre seg underveis, slik at vi må endre mål og strategi. Og kanskje terminere først som sist før vi bruker for mye tid og krefter på noe som ikke har livets rett.
Så det første budet er altså å unngå å låse seg for tidlig. Det er i prinsippet to ulike måter å oppnå dette på
A) Løs problemet i korte, etterfølgende iterasjoner der flest mulig er egnet til å få realitetssjekket forutsetninger.
B) Jobb fram ulike løsninger i parallell, før en av disse velges.
Disse to strategiene kan utmerket godt kombineres. A) legger til rette for å raskt (og billig) få gjort en avsjekk på om vi er på vei mot et godt resultat. En “bieffekt” av denne fremgangsmåten er at gevinster kan realiseres tidlig og deretter fortløpende. B) vil naturlig nok koste en del og kan være egnet der usikkerheten er spesielt stor. I en tidlig designfase på et større delproblem vil man på denne måten kunne gjøre A/B testing eller Set based design for å validere ulike mulige valg opp mot hverandre.
Det er her fornuftig å se på valgmuligheter som verdifulle. Chris Matts og Olav Maassen argumenterer godt for dette under Real Options i boka Commitment :
Options have value
Options expire
Never commit early unless you know why.
I klartekst betyr dette at vi må holde planer og spesifikasjoner åpne så lenge som mulig. Langtidsplaner må ikke oppfattes som forpliktende. Dette er jo akkurat det smidige metoder som Scrum legger opp til. Omfanget er en kø med elementer som realiseres i en prioritert rekkefølge. Denne køen er ikke “komplett”. Løsningen leveres i små inkrementer som hele tiden integreres i totalproduktet.
Unngå dette: Definert prosesskontroll, tradisjonell prosjektstyring, grundig analyse og planlegging, separate roller.
Forsøk i stedet dette: Empirisk prosesskontroll, Lean Start-up, Scrum og permanente, tverrfaglige, selvstyrte team.
2. Innhent status basert på fakta
Vi må altså unngå å la antagelser få leve for lenge. Problemet er at det er svært krevende for de som er midt oppe i en problemstilling å vurdere disse på en objektiv måte. Man blir alt for lett “forelsket i ideen sin” og mister nødvendig kritisk sans.
Alle prosjekter baserer seg på en rekke mer eller mindre velfunderte antagelser. Hvor mye verd er utsagnet Status er “på plan” – hvis dette baserer seg på antagelsene om at brukerne aksepterer brukergrensesnittet, at systemet tåler mange samtidige brukere, at sikkerhetsløsningene er gode nok og at lite endrer seg underveis?
Så hva er alternativet? Jo det er lett – bare overlat dette til brukerne. Vel, det er ikke nødvendigvis lett, men ekte brukerne er en alt for lite benyttet ressurs.
I en oppstartsfase trenger vi å eksponere noe håndfast til et antall potensielle brukere. Disse første inkrementene kan godt være prototyper, så lenge vi kan få svar på grunnleggende spørsmål som “sett at denne var helt ferdig, er dette noe du kunne tenke deg å betale for?” eller “hva må vi gjøre med denne for at du vil bruke den?” På denne måten forsøker vi å validere selve ideen. Når vi så har kommet lenger og har levert noen “ekte produktinkrementer” må vi forvisse oss om at brukerne faktisk tar det i bruk i et slikt omfang vi håpet. Spørsmål som “hvor mange faste brukere må vi ha før vi er rede til å finansiere videre satsning” blir da helt avgjørende.
Når vi så har opparbeidet en kundebase kan vi logge brukeradferden i mer detalj og få rikelig med fakta å styre videre framdrift i forhold til. “Har vi tilstrekkelig mange førnøyde kunder nå til at vi skal skalere ytterligere opp?”
3. Unngå indirekte kommunikasjon
Det er altså helt vesentlig å ta beslutninger raskt, basert på faktisk status. Så hvordan designer vi raske, trygge beslutningsprosesser? Hvordan sikrer vi at de som faktisk fatter beslutninger er tett på virkeligheten og ser bildet klart? Hvordan minsker vi gapet mellom strategisk og taktisk nivå?
Det optimale er helt opplagt at de som sitter tett på brukerne og som samtidig er oppdatert på trender og teknologiutvikling bidrar sterkt i beslutningsprosessene. Ledergrupper er alt for ofte langt unna “den virkelige verden” og må basere seg på rapporter som forenkler virkelighetsforståelsen. Noen ser bare tallene, uten å ha grunnlag for å forstå hva som ligger bak disse.
Ergo; raske beslutninger må fattes av tverrfaglige, operative team. Kundesupport, drift, utvikling, test, markedsføring vil alle ha sine verdifulle perspektiver. Når et slikt team har kommet til en konklusjon må de kunne iverksette raskt. Noen tiltak vil utgjøre mindre justeringer slik at ledelsen bare trenger å informeres. Andre tiltak kan utgjøre en strategisk retningsendring, som naturlig nok må godkjennes (raskt) av ledelsen.
Om beslutninger skal fattes effektivt av operative team, må disse naturlig nok ha en like klar målforståelse som ledelsen. Så her er det ingen vei utenom å involvere bredt når nye strategiske mål og visjoner skal meisles ut. Dersom tverrfaglige team har et solid eierskap til selve visjonen de jobber mot vil de i stor grad kunne styre seg selv. Gjør som google og forsøk å gi tverrfaglige team best mulige betingelser for å lykkes.
Både hierarkier og fagorienterte avdelinger (“siloer”) fører til indirekte kommunikasjon, noe som igjen vil føre til misforståelser, kødannelser, sub-optimalisering og forsinkelser. Disse tradisjonelle mekanismene må aktivt bekjempes dersom man ønsker å skape en endringsdyktighet.
4. Bygg inn retrettmuligheter
Løsningene som fører fram mot målet må være fleksible av natur, slik at det ikke koster alt for mye å gjøre om på det som allerede er laget. Det er klart at en strategisk retningsendring vil ha en kostnad i form av at noe utført arbeid vil måtte “kastes” eller gjøres om. Ingen vei utenom dette. Trikset er å bygge opp tjenesten og produktet på en slik måte at ikke alt for mye berøres når ting må endres.
Det finnes utallige måter å strukturere programvarebaserte produkter på. Noen vil hevde at brukerfunksjonene må stå på en solid og veldefinert plattform. Noen vil si at det viktigste er å lage gjenbrukbare felleskomponenter. Andre vil vektlegge autonomitet der løst koblede tjenestemoduler kan operere mest mulig uavhengig av hverandre. Andre vil fokusere mest på svært enkle og veldefinerte API-er. Ikke noe av dette er fullstendig riktig eller galt, men moderne systemer må ta høyde for endringsevne og skalerbarhet. I det perspektivet kan noen basale prinsipper være til hjelp:
Arkitektur laget for fleksibilitet og ikke stabilitet. Ikke forvent at strukturen til systemet vil være stabil i lang tid – forvent at denne må jobbes med hele tiden. Og for all del, unngå at sentrale felleskomponenter får bli så store at selv små endringer får omfattende konsekvenser – og følgefeil – for brukerne av komponenten.
Akseptere duplisering. Duplisering av kode og data virker intuitivt uøkonomisk og skummelt, men må allikevel aksepteres dersom man skal klare å være mer styrt av brukernes behov enn av gamle tekniske valg.
Utnytt skyen. Skyen gir helt nye muligheter for å jobbe i raske sykluser og å unngå at man bli låst fast i egne løsninger som opprinnelig var laget med andre forutsetninger enn dagens for øye.
Rulle raskt tilbake. Når brukerne får noe annet enn de behøver og gir negativ feedback, må vi kunne respondere rask med å korrigere eller evt fjerne det vi lagde. Ta da jobben med å fjerne koden, slik at systemet ikke pådrar seg mer kompleksitet enn nødvendig.
5. Endring er positivt
Når omgivelsene endrer seg må vi altså hurtig tilpasse oss endrede forutsetninger. Hvis vi har på plass punkt 1-4 over vil vi etter hvert se at endringer ikke nødvendigvis er noe problem. Endring gir muligheter. Endring er verdi og ikke kostnad! Vel, endrede forutsetninger kan selvsagt også utgjøre trusler, men en endringsdyktig, robust organisasjon vi kunne omstille seg raskt nok til å utnytte situasjonen.
Når endring kommer inn i “virksomhetens DNA”, vil den begynne å oppføre seg annerledes. Folk venner seg til at vi stadig lærer og det blir tydelig at vi godt kan koste på oss og ta sjanser. Vi kan faktisk utføre små eksperimenter og på den måten teste ut mer eller mindre gjennomtenkte ideer.
Med disse 5 prinsippene på plass vil organisasjonen – offentlig som privat – være rustet for fremtiden og utnytte ressursene bedre enn det som ofte er tilfelle. Hvorfor ikke starte året med å legge en plan for endringsdyktighet?
In: Endringsledelse, ledelse, Planlegging, produkteier, Uncategorized · Tagged with: endringsledelse, innovasjon, ledelse, organisasjon, produkteier
Fri, eller i bånd?
Barco og jeg liker den fine tiden uten båndtvang i Oslomarka. Fra 20 August til 1 April kan han få svinse fritt omkring på tur. Det å møte andre hunder er alltid spennende og ganske uforutsigbart. Er det en tispe med løpetid? Er det en dominant hannhund? Er det en nervøs, liten gneldrebikkje? Enkelte ganger blir disse møtene kaotiske og det kan bli både gneldring og knurring. Men dette er en del av “gamet” – hunder er veldig fysiske og bruker alle sanser og særlig kroppsspråk for å finne ut av hverandre i slike møter. Det kan se voldsomt og kaotisk ut, men det blir aldri “voldelig”.
Enkelte ganger møter vi hunder i bånd – og det er disse møtene som blir problematiske. Disse hundene er helt klart hemmet av båndet og får ikke møtt løse hunder på en naturlig måte. Men enda viktigere er nok at de ikke har trening i å omgås andre hunder fri. Jeg setter bånd på Barco – når jeg rekker det – i slike tilfeller. Vil ikke risikere et møte med alt for mye aggressivitet.
Det hender jeg slår av en prat med hundeeiere med hunden i bånd, og det viser seg ofte at det bunner i en eller flere dårlige opplevelser i møte med andre hunder. Responsen er altså å skape en fysisk hindring (båndet) for at dette skal kunne skje igjen. For dem er løse hunder problemet. Alt ville vært enklere om hunder alltid gikk i bånd. Og de har for så vidt rett i det, men jeg tror ikke hundene er helt enig…
Frihet i arbeidslivet?
Når mennesker og dyr er fri blir det uryddig og uforutsigbart. Adferden kan bli mer styrt av impulser og relasjoner enn av kvantifiserte mål. Hvor mye frihet skal vi tillate i arbeidslivet?
Ledere på høyt nivå vil forståelig nok helst ha orden og forutsigbarhet. De har et opplagt behov for å skaffe seg informasjon og kontroll uten å måtte dukke ned i detaljene. Dette kan de oppnå gjennom å gi medarbeiderne klare, veldefinerte roller og klare mål. Og i forlengelsen av dette sette kvantifiserte målsetninger som kan følges opp og forbedres kvantitativt. Ledelsen får på denne måten servert en mulighet til å styre organisasjonen numerisk. Dette er målstyring, som er en del av New Public Management (NPM) – Norsk offentlig sektors valgte styringssystem. Dette er forståelig ut fra et rent styrings- og ledelsesperspektiv.
Skal vi holde saksbehandlerne i stramt bånd, eller skal vi våge å slippe de fri?
Fungerer egentlig NPM og målstyring etter hensikten? Blir det effektivt? Fører det til forbedring? Gir det god styring? Hva med kvaliteten?
Målstyring koster opplagt penger. Man slipper ikke unna et visst byråkrati for å definere, aggregere og følge opp mål. Fagfolk må stadig dokumentere og rapportere sine måltall slik at andelen produktiv tid synker. For leger har trenden vært jevnt nedadgående i en 10-års periode i følge Tidsskriftet.
At målstyring koster tid og penger er kanskje ikke det viktigste ankepunktet. Det største problemet tror jeg er at folk reduseres til lydige roboter og at samfunnet derfor ikke får nytte av kraften til “frie medarbeidere”. En fri saksbehandler har myndighet til å utøve skjønn og har tid til å gjøre en sak helt ferdig. Ikke slik det er i NAV, der saksbehandlere fortviler over at de blir tvunget til å gjøre en dårlig jobb for å oppfylle strenge målkrav. En dårlig jobb betyr ofte at saken ikke blir fullført og vil dukke opp igjen et annet sted i systemet. Dette er dårlig økonomi, og elendig kundebehandling. Men viktigere – dette gjør at saksbehandlerne føler avmakt i stedet for eierskap og stolthet. De fleste vil slutte å bry seg, og heller begynne å pynte litt på tallene for å komme bedre ut. Det beste man kan håpe på i et slikt system et middels resultat.
En illusjon av kontroll
Ledere ønsker seg altså forutsigbarhet og kontroll. Vi må spørre oss om dette er et realistisk ønske i dagens sammensatte samfunn. Verken saksbehandler eller bruker er maskiner – de er levende vesener som har følelser og skaper relasjoner og forståelse seg i mellom. Dette kan være uhyre verdifullt og nødvendig for å komme opp med gode løsninger. Men da må vi altså akseptere en grad av uorden og tillate fagpersoner å utøve skjønn.
Vi kan fortsette å flikke på New Public Management, fornye og forenkle og fjerne tidstyver, men det vil ikke hjelpe stort så lenge grunntanken er basert på en illusjon.
Jeg mener vi snarest må forkaste den blå, søte pillen som gir lederne anledning til å fortsette med dette systematiske selvbedraget. I stedet må vi svelge den litt bitre røde som innebærer å ta realitetene på alvor. Akkurat som at hunders livskvalitet betinger frihet fra bånd må vi innse at tjenestekvalitet bygger på eierskap og frihet til å finne gode løsninger – i tett samspill mellom fagperson og bruker.
In: ansvar, Endringsledelse, Kvalitet, ledelse, målstyring, Samfunn, selvorganisering, systems thinking · Tagged with: endringsledelse, kundeverdi, Kvalitet, ledelse, organisasjon, systems thinking