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.

VannScrumFall

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å.

 

DebuggingOrg

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.

Tada

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.

Posted on October 30, 2014 at 6:26 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, ledelse, Scrum, systems thinking, Teamarbeid · Tagged with: , , , ,

Evolusjon

IT-bransjen er inne i en langvarig, dramatisk evolusjon, der stadig flere organisasjoner innfører ulike former for iterative prosessmodeller for sine IT-satsninger. På 90-tallet satset alle på sekvensielle faser og tradisjonell prosjektstyring. Jeg har selv vært med på å lage noen veldefinerte eksemplarer. Denne tankeganger er forlatt av store deler av bransjen, men ennå henger en del igjen. De aller fleste har innført eller har ambisjoner om å innføre mer smidige metoder. Verden går gradvis framover i retning av stadig kortere iterasjoner og hyppigere leveranser. Jeg har funnet at det grovt sett dreier seg om fire stadier:

  1. Vannfallsmodellen – Sekvensielle faser. Typisk årlige leveranser.

  2. Hybrid – Vannfall med Scrum i utviklingsfasen. Noe hyppigere leveranser.

  3. Scrum – Smidig, iterativ, evolusjonær. Leveranse typisk annenhver uke.

  4. DevOps – Kontinuerlige leveranser, mange ganger daglig.

Vannfallsmodellen

Trykk for å se større bilde

Praktiseres stadig av en del aktører som av ulike grunner ikke behøver å være særlig innovative. Ideen er å standardisere en fremgangsmåte gjennom detaljerte regler, sjekkpunkter, prosedyrer og rollebeskrivelser slik at man kan gjenta den samme fremgangsmåten prosjekt for prosjekt. Holdes i stor grad i live av prosjektstyringsaktørene som Project Management Institute (PMI) og Prince2 samt IT Service Management og ITIL. I offentlig sektor i Norge er det Difi og Prosjektveiviseren som holder denne ideen levende.

 

 

Hybrid

Svært mange (antageligvis de aller fleste) IT-organisasjonene i Norge er i dette stediet i evolusjonen. Noen er her helt bevisst og ser dette som en endestasjon, for andre er dette en mellomstasjon på vei mot “helt smidig” og Scrum. NB: en del svært synlige aktører vil helt feilaktig kalle dette for “smidig”. Dette er høyst tvilsomt, ettersom denne modellen har en lang rekke klare brudd med verdiene og prinsippene i Agile Manifesto – som definerer Smidig. Prosjektveiviseren til Difi har en viss støtte for iterasjoner og faller inn i denne kategorien. Det man forsøker på her er å blande to svært ulike tankesett der det ene fokuserer på grundig analyse og planlegging, mens den andre fokuserer på å feile billig og raskt og å lære mens man jobber. En del vil hevde at disse to er som olje og vann…

 

Scrum

Denne modellen bryter fullstendig med det meste innen tradisjonell prosjektstyring og ledelse. Dette er empirisk prosesskontroll, hvilket betyr at resultatet av en iterasjon danner basis for de neste iterasjonene. Forståelsen av Scrum forvaltes av Scrum Alliance og Scrum.org. Du finner en god definisjon her. Scrum er fullstendig i tråd med Agile (smidig) som sier at suksess ikke dreier seg om prosjektstyring, men i stedet om å ha flinke, dedikerte folk som jobber godt sammen tverrfaglig i korte iterasjoner – sammen med kunde/sluttbruker og forretning.

 

 

DevOps med kontinuerlig leveranse

DevOps

Ukentlige leveranser er alt for sjelden for mange, og de senere årene ser vi stadig fler som tar skrittet “forbi Scrum” og frigjør seg fra de tidsgitte iterasjonene. Her er det om å gjøre at utviklerne jobber så produksjonsnært som mulig og idriftsetter nye små oppdateringer mange ganger daglig. En kommentar til dette er det er fullt mulig å levere daglig innenfor Scrum-rammeverket også.

 

 

Posted on October 13, 2014 at 12:48 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, inkrementell utvikling, Scrum · Tagged with: , , , , ,

Bokomtale: User Story Mapping

rc_cat_USMJeff Patton nærmer seg endelig ferdigstillelse av boka si om User Story Mapping. Denne er svært etterlengtet og denne ikke helt ferdige utgaven jeg har lest, lover veldig godt! De som overhodet ikke er kjent med User Story Mapping kan godt ta en sveip innom denne siden til Patton.

Boka beskriver selvsagt teknikken (eller metoden om du vil) User Story Mapping. Men dette er kanskje ikke det mest interessante. Teknikken er fin den og forholdsvis lett å praktisere. Men som med alle metoder og teknikker – det blir ikke skikkelig bra før vi forstår det grunnleggende tankesettet bak.

Så boka er mye mer enn en lærebok i USM – den handler også grunnleggende om innovasjon, læring, tverrfaglig teamarbeid, design, kommunikasjon, smidig systemutvikling og optimalisering.

 

Man kan si boka handler om den oppdagelsesreisen en IT-organisasjon gjør sammen med brukerne sine. Hvordan jobber vi for å finne ut hva vi skal lage? Noen gjør dette helt tilfeldig og følger prinsippet om “siste taler får fokus”. Noen baserer seg på rene gjetninger. Andre går etter den komplette spesifikasjonen og gjør tidkrevende analyse- og planarbeid før man setter i gang å lage funksjonalitet. Jeff Patton argumenterer svært overbevisende om at vi må være bevisste og strukturerte når vi forsøker å oppdage de viktigste behovene til brukerne. Og vi må jobbe inkrementelt og evolusjonært tett sammen med dem. Ett er sikkert – det holder ikke bare å spørre brukerne. Vi må være sikre på at vi forstår hva de trenger – ikke bare hva de sier de trenger.

USM

Et veldig spennende aspekt ved USM er at teknikken hjelper deg å identifisere hva du skal VENTE med å lage, og ikke minst hva du IKKE skal lage. Her ligger et enormt potensiale; IT-bransjen har lang historie i å utvikle, levere og vedlikeholde en helt unødvendig stor mengde funksjonalitet. Det blir veldig naturlig å kombinere USM med Lean Start-up. USM kombinerer veldig godt med Build-Measure-Learn syklusen og er uovertruffen for å identifisere Minimal Viable Product.

Jeg har i flere år benyttet USM i Scrum-kursene mine. Særlig i Certified Scrum Product Owner kurset vil en vesentlig del utnytte USM. Hver gang Product Owner vurderer å setter i gang med en større satsning (uavhengig om dette er innenfor et eksisterende område eller et nytt) anbefaler jeg å planlegge inn en USM-workshop. Ta med representanter for de potensielle brukerne, andre interessenter, Scrum Master og ikke minst hele utviklingsteamet.

” Story mapping is a technique that provides the big picture that a pile of stores so often misses”

Martin Fowler i forordet til boka

Hvem er du som trenger denne boka? Vel, alle som er interessert i smidig systemutvikling! Litt mer spesifikt det er i hvert fall

“But when the two strains of practice—design and development— collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.”

Alan Cooper i forordet til boka.

Posted on August 29, 2014 at 3:20 pm by gamsjo · Permalink · Leave a comment
In: forretningssiden, Planlegging, produkteier, Teamarbeid, Uncategorized · Tagged with: , , ,

Selvorganisering – hva og hvorfor

De fleste organisasjoner styres etter en ovenifra-og-ned modell, der medarbeidernes autoritet avgjøres av hvor høyt oppe i hierarkiet de befinner seg. StyringspyramideJo større beslutning, desto høyere opp skal den tas. I slike organisasjoner kommer også mål, planer og budsjetter ovenifra. Man antar at vi på forhånd vet hvilke strukturer (prosesser, roller, avdelinger, partnere, outsourcing etc..) organisasjonen behøver for å drives effektivt. Eventuelle endringer i strukturene har stor betydning, er krevende og fordrer derfor grundige analyser og planer. Og vil derfor nødvendigvis ta lang tid.

Alternativet er en nedenifra-og-opp modell der beslutninger tas med minst mulig avstand til virkeligheten (og brukeren). Her er tankegangen at den personen (eller den gruppen) som er midt oppe i situasjonen også er den (eller de) som er best egnet til å beslutte. I en slik situasjon vil tidsforbruket nødvendigvis kunne kortes kraftig ned, og vil kan raskt få erfare hvor god beslutningen var.

Dette innebærer implisitt at makt forskyver seg nedover i systemet og at arbeidet kan gjøres i ganske autonome, selvstyrte team. Lederrollen går dermed fra å sende styringssignaler nedover i systemer til å bli en tilrettelegger for de som gjør jobben. Fokus dreier på denne måten vekk fra organisasjonen selv og over på brukerne/kundene. Man kan si at pyramiden blir flatere og snus opp ned.

Ovenifra-og-ned står for fall

Tradisjonelle styringssystemer bygger på Taylorisme eller “vitenskapelig ledelse” beskrevet av Fredrick Taylor på begynnelsen av forrige århundre. Dette regimet ble ikke laget for omgivelser med stor dynamikk og kompleksitet – som vi har i dag – så det er et opplagt behov for å tenke nytt her. Mange gjør nettopp det og det er slående at svært mange eksperter på ledelse er samstemte her:

Peter Drucker uttaler (allerede) i 2001 i Management Challenges for the 21st Century “Knowledge workers have to manage themselves. They have to have autonomy”

Gary Hamel, en annen inflytelsesrik ledelsesguru, tar sterkt til orde for langt mer selvorganisering og flate organisasjonsstrukturer i boka What matters Now, How to Win in a World of Relentless Change, Ferocious Competition, and Unstoppable Innovation

Hamel stor også bak Management innovation eXchange (The MiX) et svært aktivt nettverk der blant annet Statoils Bjarte Bogsnes er en vesentlig bidragsyter om Beyond Budgeting og Smidig virksomhetsstyring.

John P. Kotter gjør på mange måter det samme som Drucker og Kotter og etterlyser lederskap i HBR-artikkelen Management is (still) not leadership: “Leadership is about vision, about people buying in, about empowerment and, most of all, about producing useful change.”

Det smidige manifestet (fra 2001) sier Individuals and interactions over processes and tools og The best architectures, requirements, and designs emerge from self-organizing teams. I ettertid har opphavsmennene (og andre) brukt mye energi på å poengtere at dette mener de faktisk! Det er altså dedikerte, flinke, autonome mennesker som samhandler godt som er mest avgjørende for suksess.

Autoriteter innen kompleksitetsteori er også klare på dette punktet. Dagens utfordringer er på mange måter mer sammensatte, dynamiske og komplekse enn vi hadde for en del tiår siden. Når vi gir oss i kast med komplekse problemer duger ikke lenger de detaljerte planene og de lange beslutningsveiene. På samme måte er det med styringssystemer; de detaljerte stillingsinstruksene, prosedyrene og måleregimene (Management By Objectives) vil være i veien for innovasjon og tilpasningsevne. Disse beskrivelsene og målingene vil på mange måter sementere Status Quo i stedet for å stimulere til den nødvendige nytenkning. De som vil kan lese mer om dette her.

 

Hva innebærer egentlig selvorganisering?

Når jeg snakker om dette opplever jeg stadig at ledere finner dette “interessant” og “spennende”, men samtidig veldig fremmed og nærmest eksotisk. Noe som sikkert kan passe for andre…

gjess2

Selvorganisering i naturen

Vi finner selvorganisering overalt i naturen. Når flokker av gjess flyr sydover om høsten har de funnet ut at det kan være lurt å legge seg i en V-formasjon for å spare krefter. De bytter på å “dra”. De tar litt ulik rute hver gang, selv om de skal til samme bestemmelsessted som i fjor. På den måten tilpasser de seg vær og vind og mellomlander der de finner en fredelig liten slette som passer de behovene de har. Det har ingen kunnskap om aerodynamikk, ingen plan, ikke kart – bare retningssans og en fantastisk, dynamisk tilpasningsevne.

 Fiskestimer, maurtuer og bisvermer er andre eksempler på selvorganisering i naturen. Hvorfor skulle ikke vi mennesker kunne operere på denne måten? Vel vi gjør jo det allerede.

I små oppstartsbedrifter vil måten de jobber på og hvem som gjør hva avhenge av ting som tilgjengelighet, erfaring og lyst – ikke stillingsbeskrivelsen. Du hører aldri “nei, det der er ikke min jobb” i en liten gruppe gründere som brenner etter å lykkes. Samhandlingen vil være spontan og tilpasset situasjonen. Det er forresten dette som er modellen for et Scrum team som skal være av passe størrelse (4-9 personer på heltid) der rollene har mindre betydning enn teamet som helhet.

Byutvikling er et annet eksempel. Vel, det vil alltid være byplanleggere som forsøker å anslå behov for butikker, bank, skoler osv og lager en initiell plan. Men over tid vil vi se stor dynamikk – styrt av loven om tilbud og etterspørsel – der butikker og andre bedrifter kommer og går.

Til slutt vil jeg trekke fram rundkjøringen der myndighetene har valgt å la hver og en av oss avgjøre om vi skal kjøre, sakke farten eller stoppe helt opp. Motpolen – som baserer seg på Taylorisme – er jo lyskrysset der myndighetene har tatt kommandoen og bestemmer for deg om du skal stoppe eller ikke. Vi vet ut fra utallige målinger at rundkjøringen er fullstendig overlegen både hva gjelder flyt (gjennomløpskapasitet, throughput) og ulykker. Les mer om dette her.

 Vi behersker med andre ord selvorganisering ganske godt, bare vi slipper den til.

Gruppedynamikk

Dette temaet er det skrevet, forsket og sagt mye om. Selvsagt! Gruppedynamikk er et stort fagfelt som vi kan bruke for å forstå samhandling innen lagspill, i familier, i stammer / klaner, i ledergrupper og ikke minst i tverrfaglige team.

Bruce Tuckmann definerte i 1965 gruppedannelse som en firetrinns utvikling: Forming – Storming – Norming – Performing. Målet er (selvsagt) å nå Performing, der gruppa fungerer godt sammen. En enkel erkjennelse vi finner når vi anvender denne modellen er at det tar tid å bli et godt team. Og så er det viktig her å minne om at Performing ikke er en stabil tilstand. Alle team vil når de blir utfordret på nye områder – eller når teammedlemmer blir byttet ut – finne seg i å starte på Forming igjen.

En annen mye referert ekspert på teamarbeid er J. Richard Hackman som er veldig klar på hva som er ekte team (og ikke bare en gruppe mennesker som samarbeider litt): Research confirms that the presence of the five conditions–real team, compelling direction, enabling structure, supportive context, and competent coaching–enhances team performance effectiveness.

TeamBalanseMIT har forholdsvis nylig gjennomført en stor studie der de målte samvirkningen mellom teammedlemmer med måleintrumenter og komme fram til det klare resultatet at de beste teamene er “balanserte”. Dette betyr at alle teammedlemmene interagerer med alle de andre – med omtrent samme intensitet. Av dette kan man slutte at team med en utpekt, styrende og kontrollerende teamleder har vanskelig for å fungere like optimalt som et selvorganiserende team der alle i utgangspunktet er likeverdige.

Det er en helt klar konsesnus om at et godt team har større kapasitet enn summen av individenes kapasitet. Samarbeidet er i seg selv verdiskapende og fører til bedre, mer robuste løsninger.

 

Kjennetegn ved gode team

Klare mål og verdier – alle i teamet har samme oppfatningen av retningen, det er ikke konflikt mellom egne mål og teamets mål. Og de har i stor grad de samme verdiene.

Medlemmene forstår sin egen rolle i teamet – I alle team er det visse strukturer – ofte et slags hierarki – der folk spiller ulike roller. I de gode teamene er alle inneforstått med sin egen rolle – som vil være relativ til de andre i teamet.

Tillit – Folk i teamet er trygge nok på hverandre til å være åpne og ærlige, også når ting går galt.

Åpen, effektiv kommunikasjon – I de gode teamene kan vi observere at de snakker med hverandre i “halve setninger” og stikkord. Allikevel blir det ikke misforståelser.

Energi og engasjement – Man kan tydelig se at folk i teamet bryr seg – det kan observeres ved tidvis høylytte diskusjoner.

Full deltagelse i beslutningsprosesser – Alle i teamet deltar når viktige beslutninger skal tas. Ikke dermed sagt at alle har like stor vekt.

Ledere med ubetinget støtte – Omgivelsene rundt gode team viser tydelig at de har tillit til teamet ved å la være å blande seg. Om teamet hele tiden produserer resultater er det nok å observere det de produserer og effekten av dette. Lederne er alltid parat til å finansiere forbedringer.

Konstruktiv konflikthåndtering – Det etablerer seg en form for energiske diskusjoner der man kommer styrket ut av konflikten.

Ulikheter – I de gode teamene er ikke medlemmene alt for like. De har ulike personlighetstrekk, ulike styrker og svakheter.

Intakte over lang tid – Gode team består av individer som er bortimot full tid i teamet og dessuten er  teamet er intakt over lang tid. Det tar tid å bli et godt team!

Blir coachet- team må stadig fornye seg når de får nye utfordringer, men behovet for fornying og forbedring er vanskelig å detektere innenifra. Derfor er det av stor verdi å ha en alliert som er tett på – men på utsiden – som kan observere og utfordre Status Quo når det er nødvendig.

Innovasjon og grader av selvorganisering

I arbeidslivet ser vi grader av selvorganisering, og slik vil det nok alltid være. Dette har med størrelse å gjøre, med firmakultur og ikke minst med typen arbeid som skal utføres. Om man er i et domene med forholdsvis lite dynamikk og kompleksitet vil Taylorisme kunne fungere godt. Har vil effektivitet og lave kostnader være styrende suksessfaktorer. Om man derimot befinner seg i et domene der suksess baserer seg på tilpasningsdyktighet og innovasjon, vil man måtte bevege seg i retning av selvorganisering.

Hackman differensierer mellom fire grader av selvstendighet eller autonomitet:

Manager-led teams Teamet utfører det de får beskjed om. De har ikke autoritet til annet enn å utføre oppgaver. Ledelsen definerer teamet, retningen og prioriterer oppgaver. Ledelse følger opp framdrift. Teamet kan ha noen grad av myndighet til å bestemme hvordan en oppgave skal løses.

Self-managing teams Teamet er ansvarlig for detaljplanlegging og oppfølging av progresjon.

Self-designing teams Teamene har myndighet til å endre på team-sammensetningen og til å utfordre omgivelsene for å oppnå innovasjon og forbedring.

Self-governing teams Helt autonome team som sette seg mål, former seg selv og ellers tar alt ansvar.

Dette er i realiteten en ganske flytende skala. Man innfører ikke selvorganisering over natta. Særlig ikke om man befinner seg i startgropa; der utgangspunktet er svært tradisjonelt styresett med høyt hierarki og streng avgrensning mellom ledelse og arbeid. Vi må her huske at dette skiftet innebærer både omfattende struktur-, prosess- og ikke minst kultur-endringer. Dette vil være en reise over mange år.

(Norsk arbeidsliv nok heldigere stilt enn det vi finner i helt andre kulturer. I Norge har vi tradisjonelt hatt en pragmatisk lederstil og arbeiderne “på gølvet” har gjennomgående en ganske stor grad av myndighet.)

Det er spennende å studere suksessfulle firmaer som Morning Star (som står bak self management instituteGore og Semco (les boka Maverick!) som alle langt på vei er basert på Self-governing prinsippet. Disse selskapene er ekstremt opptatt av innovasjon og deler synet på at innovasjon kommer nedenifra der de som gjør jobben møter kundene. Når en medarbeider får en god ide, skal det være raskt og enkelt å finne finansiering og støtte til å sette ideen ut i live. Men disse selskapene er svært modne og representerer foreløpig et ganske uoppnåelig regime for mange mellomstore og store bedrifter.

Spotify er et spennende eksempel på et svært innovativt selskap som vokser hurtig for tiden.  Hvordan de klarer å beholde selvorganisering som prinsipp på tross av at de begynner å bli et ganske stort selskap kan man se mer om her. Bruker vi Hackmans terminologi her vil de nok havne på Self-designing teams.

Maktforskyvning

Når vi innfører økende grad av selvorganisering fører dette til at noen personer mister makt og posisjon, samtidig som andre tilføres det samme. Jeg har selv observert organisasjoner som har beveget seg i denne retningen og som ender opp med langt færre mellomledere. De fleste er med på at dette kan være et gode for bedriften; Sjefer tilfører ikke direkte verdi – de bare styrer og koordinerer. En grundig verdistrømanalyse i et Lean-program vil typisk peke på mellomledere som “waste”. Dette er en brutal, men ikke desto mindre reell erkjennelse.

Så, selv om mange (alle?) kan være med på at lavere hierarkier, færre ledere og mer fokus på de som faktisk skaper verdi kan være av det gode, vil det nødvendigvis føre til motstand. Få vil aktivt jobbe for å overflødiggjøre seg selv! Så for å lykkes med å øke graden av selvorganisering må toppledelsen være villige til å sette mye på spill og de vil miste gode medarbeidere. Create a Sense of urgency (Kotter) er fremdeles punkt nummer én over faktorer som må til for å skape endring; Det skal mot og utholdenhet til for å oppnå varig endring!

Cynefin for beslutningsstøtte og ledelse

Etter at Dave Snowden i 2007 publiserte A Leader’s Framework for Decision Making i Harvard Business Review har han vært en ettertraktet fordragsholder og Cynefin-modellen blitt stadig mer referert. Særlig i forbindelse med ulike former for Lean- og Agile-relaterte konferanser og blogger. Han er for eksempel Keynote-speaker på årets Scrum Gathering i Berlin. Cynefin blir også trukket fram blant annet av Gartner som i denne rapporten predikterer at 10% av IT-selkapene vil benytte Cynefin til å fatte belutninger.

Hva er Cynefin?

Cynefin er et rammeverk som gir oss svært nyttige holdepunkter når vi skal fatte beslutninger og løse problemer. Modellen beskriver ulike nivåer av kompleksitet og sier at hvilken problemløsningsmetode vi bør velge, avhenger av problemets kompleksitet. De opplagte problemene løser vi på en måte, de kompliserte litt annerledes, for de komplekse må vi tenke helt ulikt og de kaotiske problemene får vi en fjerde tilnærming.

Orden eller uorden?

Cynefin1

Først kan vi lage et grovt skille mellom det vi kan kalle ordnet og uordnet. I det ordnede området har problemet klare begrensninger og vi har stabilitet. Disse problemene kan vi løse slik vi alltid har gjort: Vi analyserer og vurderer de ulike opsjonene vi har, veier dem opp mot hverandre og gjør et valg. Vi regner da med at vi har funnet en løsning som er god nok. Her kan vi med andre ord forstå relasjonen mellom årsak og virkning (kausalitet). I det uordnede området har vi grader av ustabilitet og vi vil ikke klare å finne løsningen kun ved analyse. Her er det rett og slett for mange ulike faktorer som spiller inn. Mange av faktorene påvirker dessuten hverandre, og noen ganger har vi så mye dynamikk at analysen lett blir utdatert før vi får satt løsningen ut i live. Vi har ikke lenger en brukbar kausalitet hvilket innebærer at vi må forsøke det beste vi kan – og så kan vi finne ut i ettertid om løsningen var brukbar eller ikke.

 

Cynefin2Snowden har funnet at det ordnede området egentlig består av to ulike domener: Det Opplagte og det Kompliserte. Begge er såpass enkle at vi kan finne de vesentligste årsak-virkning sammenhengene, men de er også ulike av natur. De opplagte problemene er deterministiske, repeterbare og har løsninger som er allment kjente. Løsningene er ikke engang avhengige av konteksten – “det bare er sånn”. Én og bare én løsning. Her gir uttrykket “beste praksis” mening. De Kompliserte problemene finner vi en løsning på ved å tilkalle eksperter på området og be de analysere. Det vil her finnes flere mulige løsninger, så vi må vurdere alternativer opp mot hverandre og fatte beslutning. Her finnes altså en klar relasjon mellom årsak og virkning, men de kan være separert av tid. Hvilken løsning som er best vil avhenge av konteksten. Her finnes ingen beste praksis, siden vi har en sterk kontekstavhengighet. Men vi kan operere med “god praksis”.

 

Cynefin3Det uordede området deles også i to ulike domener. Det Komplekse domenet kjennetegnes ved at vi kan finne relasjonen mellom årsak og virkning, men kun i ettertid. Her har vi en grad av stabilitet, men den vil være flyktig. Uansett hvor grundig og dypt vi analyserer blir vi aldri sikre på at vi finner en god løsning.

Vi må allikevel operere i dette domenet, hvilket betyr at vi må bruke vårt beste faglige skjønn og utføre eksperimenter som vi evaluerer i etterkant. Har vi styrket, eller svekket antagelsene våre? Dette kan vi resonnere rundt, umiddelbart etter at resultatet foreligger. Vi må her gi slipp på den sterke kontrollen. Vi kan her se etter mønstre og vokse frem en bedre og bedre praksis, dvs vi beveger oss over i det Kompliserte domenet.

I det Kaotiske området råder fullstendig ustabilitet. Ingen ting synes å være forutsigbart. Allikevel må vi handle – og vi har alltid svært dårlig tid. Intuisjon, skjønn, magefølelse vil være styrende for hva vi foretar oss. Resonnementer rundt årsak og virkning er meningsløse. Hver situasjon er per definisjon ny, og vi må finne ny praksis hver gang. Bemerk at dette er en transisjonstilstand; Det er svært vanskelig å forbli i kaos over lang tid.

Snowden har i tillegg definert et femte domene – Disorder – som han gjerne plasserer midt i mordellen. Vi kan kalle dette Forvirret på norsk. Dette er domenet du havner i om du ikke klarer å bestemme i hvilket domene du egentlig er. Og ikke minst, om du innbiller deg at du er i feil domene. I følge Snowden er dette den mest vanlige tilstanden…

Problemløsning i de ulike domenene

Det er først og fremst kausaliteten som skiller de 4 domenene fra hverandre. Dette gir at vi trenger 4 ulike fremgangsmåter for å fatte beslutninger:

Implikasjoner på styring og ledelse

Hvordan innvirker dette på ledelse og lederrollen? Igjen får vi 4 ulike løsninger:

Det er selvsagt på dette området Cynefin virkelig vil være verdifull. Det er jo fremdeles slik at faget ledelse defineres og læres bort uten å ta hensyn til disse domenene. I stedet predikes “one-size-fits-all” der man oppfordres til å finne den ultimate organisasjonen og styringssystemet. Vi ser det overalt, i privat som i offentlig sektor – det er reglene, prosedyrene, stillingsintruksene og målingene som regjerer – som om vi alltid hadde orden. Vi gjør grundige analyser, legger store, detaljerte planer og oppfører oss som om vi hadde orden og kontroll. Vi må snart innse at vi ikke alltid har orden, og at dette på mange måter er et tilbakelagt stadium.

Dette er jo dårlige nyheter for de som har bygget hele sin karriære på å best mulig håndtere Orden.

Et synlig bevis på at kompleksitet ikke er særlig godt forstått for tiden kan vi se på utbredelsen av PRINCE2. PRINCE er et akronym for “PRojects IN Controlled Environments”. Dette er med andre ord laget for det Ordnede (kontrollerte) domenet. Allikevel benyttes dette for styring av programvareprosjekter som i stor grad befinner seg i det Komplekse området. IT-bransjen sender horder av medarbeidere på slike kurs for tiden.

Dynamikken i systemer

Dette er et “sense-making framework”, men brukes for ofte (til Snowdens store fortvilelse) som en ren 2×2 kategoriserings-matrise. Nei her er det dynamikk og vi vil typisk vandre rundt i modellen, avhengig av hvordan vi innretter oss. Cynefin4Snowden gjør et poeng av at vi i vår tidsalder bør instille oss på å være i det komplekse hjørnet en hel del. Vi vil måtte regne med flyktige dykk ned i Kaos, og det er helt OK så lenge vi er klar over det. Og i dagens  kunnskapsorganisasjoner vil vi ofte osillere mellom Komplekst og Komplisert. Vi trenger å ha en grad av uorden for å finne de virkelig gode løsningene på dagens svært komplekse virkelighet. Samtidig er vi tjent med å jobbe med en grad av orden når vi vet hva vi skal gjøre og hvordan.

Det Opplagte hjørnet er for arbeid som skal dø. Det er dette som skal automatiseres eller outsources. Det er ikke her vi skal være gode i Norge!

Det er intessant å merke seg at Snowden mener at Scrum utført riktig vil fremme denne stadige runddansen mellom Komplekst og Komplisert.

 

Oppsummert modell

CynefinFull (1)

Referanser:

A Leaders Framework for Decision Making av David Snowden og Mary J. Boone

Cynefin 101 – an introduction av  Greg Brougham

Diverse blogposter på Congitive Edge taget Cynefin

 

 

 

Posted on July 31, 2014 at 1:02 pm by gamsjo · Permalink · One Comment
In: kompleksitet, systems thinking · Tagged with: ,

Fortsatt god sommer!

Fellesferien slutter i disse dager og de fleste er gradvis på vei tilbake på jobb. Men det betyr ikke at det er full rulle ennå. Alle er delvis i feriemodus og hverken sjefen eller kundene har begynt å mase. Nå gjelder det å utnytte det litt bedagelige tempoet i kontorlandskapet til litt faglig påfyll. Ikke vær redd for å bruke arbeidstiden på å lese bøker, blogger og presentasjoner. Selv liker jeg å se videoer.

Ett tema som har opptatt meg (og mange med meg) den siste tiden er hvordan smidig fungerer i store organisasjoner. Er det mulig å skalere opp en smidig arbeidsform, en smidig kultur? Er det ønskelig? Dette temaet er jo relevant både for privat og offentlig sektor. Her kommer et lite knippe med presentasjoner som addresserer dette temaet – på ulike måter. Til sammen 3,5 time – det har du sikkert tid til :)

Først ut er Dan North, en jeg forsøker å følge ganske tett. Dan representerer på mange måter “advanced agile” og han er mannen bak Behaviour Driven Development (BDD) Se presentasjonen

Why Agile Doesn´t Scale (and what you can do about it) – 56 minutter

Og så må vi innom Spotify. De er et virkelig fasinerende selskap – de vokser hurtig, tar Lean og Agile på alvor og de publiserer bra saker på løpende bånd. Se for eksempel presentasjonen

How Agile Coaches Help Us Win—the Agile Coach Role at Spotify av Brendan Marsh and Kristian Lindwall. 40 minutter

Og om du ikke har gjort det ennå, se den herlige animasjonen

Spotify Engineering Culture (part 1) laget av Henrik Kniberg. 13 minutter

Det lages gode presentasjoner her på berget også. Hvorfor ikke se  Jon Kåre Stene sin Keynote på Smidig 2012, som på ingen måte er utdatert.

End of Big – Hva nå? – 50 minutter

Og så har vi en annen Norsk favoritt, nemlig Bjarte Bogsnes fra Statoil som 3 juni i år snakket om

Smidig virksomhetsstyring – 50 minutter

Alle som er oppatt av storskala IKT-utvikling og innovasjon i offentlig sektor bør unne seg noen minutter med Mette Gjertsen og Statens Pensjonskasse hentet fra det samme seminaret den 3 juni:

Verdi synliggjort i produktkø – 20 minutter

NB:Alle foredragene fra seminaret 3 juni, samt paneldebatten finner du i Vimeo under Smidig digitalisering av offentlig sektor.

 

 

Posted on July 27, 2014 at 2:43 pm by gamsjo · Permalink · One Comment
In: ledelse, Skalering · Tagged with: 

Smidig digitalisering av offentlig forvaltning – video og slides.

Den 3 juni i år arrangerte Smidigkonferansen et ekstraseminar med fokus på offentlig sektor. Det er liten tvil om at potensialet er enormt i denne sektoren. Dette er en oppsummering av seminaret ispedd mine kommentarer. Linker fortløpende til alle foredragene, presentasjonene ligger her.
 
CollaborationSmaller 

Etter at Christina Kjær Seime hadde ønsket velkommen overtok Bjarte Bogsnes podiet og holdt en svært engasjerende og ikke minst viktig tale om hvordan kunnskapsorganisasjoner trenger en smidig styringsstruktur. Det handler om å ta dagens virkelighet på alvor og å slippe opp på kontrollregimet og heller gi medarbeidrne tillit og skape gjennomsiktighet.

Man kan være så smidig og agile man bare vil i et prosjektmiljø, men før eller siden treffer man styringssystemet og hvis det er skrudd sammen etter helt andre prinsipper så har man et problem. Bjarte Bogsnes

Deretter tok undertegnede over og forsøkte å vise hvordan smidig gjennomføring kan bli “raskere, billigere, tryggere og bedre“. Dette høres selvsagt ut til å være for godt til å være sant, men jeg tror ikke det. Tilstanden i de tradisjonelle IT-prosjektene i offentlig sektor er begredelig. Det sløses enormt med kalendertid (særlig i tidlige faser), innsatsen brukes svært lite effektivt, det tas unødvendig stor risiko og løsningene som leveres har ofte dårlig brukervennlighet og bugner av teknisk gjeld. Dette mener jeg er et systemproblem.

Så var det tre ulike miljøer i det offentlige IT-norge som overtok.

Først ut var Mons-Ivar Mjelde som fortalte om hvordan de fikk utnyttet smidige prinsipper til å lage bedre, mer fremtidsrettede løsninger enn opprinnelig specet i OTI-prosjektet. I tillegg konkluderer Mjelde med at utviklingsprosessen har skapt mange ideer for fremtidig utvikling og at smidig støtter opp under innovasjon!

KOMMENTAR: Et godt eksempel på hvordan kunde i tett, tillitsfullt samarbeid med leverandør kan gjøre byråkrati og overhead  unødvendig. Når dette samarbeidet er på plass kan man senke skuldrene og ikke være så redd for å trå feil og heller fokusere på innovasjon.

Så tok Svein Hauge over og fortalte hvordan Statens Vegvesen nå kjører alle utviklingsprosjektene sine smidig. Han begynner med (med glimt i øyet) å fremstille leverandørene som ulver som må holdes i tømmene. Deretter langet han ut mot anskaffelsesreglementet som alt for lett fører til at man kommer skjevt ut. Sannsynligheten er stor både for at man velger feil leverandør og ender opp med et urealistisk lavt budsjett. Og gevinstene har en tendens til å gjemme seg i de kravene som droppes (prioriteres ned). Autosys-prosjektet måtte ofre både gevinstene og kvaliteten for å komme i mål. Hauge hevder at de har vært nødt til å styre etter tradisjonelle PMI-prinsipper, noe som blir erstattet med PRINCE2, mens utviklingsmetodikken er Scrum.

KOMMENTAR: Vegvesenet har her tatt et godt skritt i retning av smidig, men er ikke der ennå. En del av problemene kunne antageligvis vært unngått med en mer helhjertet smidig tankegang. PRINCE2 vil ikke hjelpe til her…

Deretter overtok Mette Gjertsen og fortalte om hvordan Statens Pensjonskasse (SPK) nå forvalter og videreutvikler resultatet av PERFORM-prosjektet. Har for øyeblikket 12 Scrum-team. Dette er tverrfaglige team der noe over halvparten er egne SPK-ansatte. Alle sitter på en flate. Samarbeidet mellom forretning (4 dedikerte forretningsstøtteteam) og utvikling er helt sentralt og fokusert. Har nå sluttet å kjøre egne prosjektteam – dette for å sikre læring; “utviklerne må rette sin egen drit”. De ser at dette fører til bedre kvalitet. Har nå samlet alt arbeid til alle teamene i én kø. “Produkteier bor, lever og ånder i denne køen”. Har stor fokus på løpende prioritering og har klart å løsrive seg fra det tradisjonelle endringsregimet.

KOMMENTAR: Dette er storskala og helhjertet smidig og et eksempel til etterfølgelse!

Etter lunsj startet vi med Ux-designer Sigrun Tallungs som fortalte om det Svenske Pust-prosjektet som klarte kunststykket å gå fra suksess til fiasko. Dette er “polisens nya utredningssystem” som først ble utviklet i Java, et prosjekt som ble kjørt smidig i tett samarbeide med brukerne og som ble tatt godt imot. Etter å ha brukt 100 MSEK på dette ble det brått stoppet fordi Oracle hadde klart å selge inn at det ville bli mye billigere i lengden om de la om til et “standardsystem” basert på Siebel. Etter å ha brukt 200 MSEK på Pust Siebel er nå evalueringen entydig – systemet er nå nærmest ubrukelig! Dette foredraget er en skikkelig tankevekker!

KOMMENTAR: Mye læring å hente her! Rekk opp hånda den som vet om lignende tilfeller i Norge! :-)

Så kom advokat Ståle Hagen opp på podiet for å snakke om kontraktsregulering. Han har hatt en rekke oppdrag de siste årene for å hjelpe til å “rydde opp” mellom kunde og leverandør i “smidige” prosjekter. Hovedproblemet har vært at endringene underveis lett blir uhåndterlige. En typisk feil er at man presser smidig gjennomføring inn i en fossefallslignende kontrakter. Her blir det lett en endeløs tautrekning når det er behov for endring og bruk av advokater for å få avsluttet prosjektet. “Dette er god business for meg, men jeg skulle gjerne tjent de pengene ved å hjelpe til med i starten når kontrakter inngås.” Når det gjelde kontraktsstandarder så har Difis SSA-S alt for mange feil og mangler til at den kan anbefales. Det nærmeste man kommer er dataforedningens SOL-kontrakt men heller ikke denne er god nok.

KOMMENTAR: Det synes som varianter av timebaserte kontraktsformer er det eneste som fungerer godt i programvaretunge prosjekter.

Så var det Sergey Dmitriev sin tur til å fortelle om hvordan Kystverket har lagt smidige prinsipper til grunn helt fra starten av for å utvikle BarentsWatch. Utgangspunktet var at de ønsket å finne leverandører som “er smidige”. Men hva er egentlig dette? Alle sier de er smidige, men det finnes ingen særlig god, målbar definisjon på smidighet. Kystverker med hjelp av Sergey lagde da en halv dags opplegg for å teste leverandørens smidige tilnærming til problemløsning. Når de testet fire leverandører på denne måten viste det seg overraskende nok at ingen hadde en godt, smidig tankesett inne!

KOMMENTAR: Er dette redningen for de kundene som ønsker å sikre seg gode, smidige leverandører?

Deretter overtok Christin Gorman fra Husbanken for å snakke om ansvar. Er det virkelig nødvendig å sette alt utviklingsarbeid ut til konsulentselskaper gjennom tunge anbudsprosesser? Hvorfor ikke ansette flinke, dedikerte folk og gjøre utviklingen med stor grad av egne medarbeidere? Dette kan jo forenkle utviklingsprosessene voldsomt. Hvorfor må leverandørene sees på som sultne ulver? Det må da være bedre å dyrke samspillet og samarbeidet? Uansett kontrakt, så er det kunden som blir sittende igjen med produktet – og vil enten han vil det eller ikke ha ansvaret selv. Staten kan enkelt ansette langt flere utviklere selv og spare penger på det, samtidig som de vil få enklere og bedre løsninger.

KOMMENTAR: På denne måten kan staten sikre seg mye bedre og kvitte seg med byråkratiske, tunge anbudsprosesser.

Sist ut var Lars Nokken fra Difi som redegjorde for Difi sine tanker om smidig. Utgangspunktet til Difi er at prosjektveiviseren kun addresserer det overordnede nivået kalt Prosjekteierstyring og Prosjektstyring. Det utførende nivået er definert som uavhengig av dette og blir ikke adressert. Nokken uttalte veldig tydelig at Difi ER positive til bruk av smidig utviklingsmetodikk. da særlig bruk av Scrum eller DSDM innenfor rammen av Prince2. Utgangspunktet til Difi er prosjektstyring og prosjektlederens vanskelige jobb. Beslutningsvegringen råder i offentlig sektor på grunn av en forsiktighetskultur der det altoverskyggende er å unngå å komme i VG.

KOMMENTAR: I Difi sin verden er prosjektperspektivet rådende mens produktperspektivet er utydelig. Når de i tillegg setter premisset om at topp-nivået skilles fra det utførende nivået, blir det vanskelig å se at dette vil bevege verden i smidig retning. Om Difi ønsker smidig må de kommunisere dette mye tydeligere og synliggjøre dette på høyeste nivå.

Dagen ble avsluttet med 45 minutter paneldebatt. Hovedtema er kontraksformer som passer for IT-prosjekter.

KOMMENTAR: Panelet virket etter hvert ganske samstemte på at Time/Material er overlegent, at kunden ikke kan distansere seg fra produkteieransvaret og at også kunden bør ha en solid andel egne ansatte i utviklingsteamene.

 

 

 

 

Posted on June 12, 2014 at 10:30 am by gamsjo · Permalink · 2 Comments
In: Endringsledelse, kontrakt, prosjektledelse, Samfunn, Scrum · Tagged with: , , , , ,

IT-satsninger ER – og skal være – risikable

En nylig innsatt startssekretær Paul Chaffey uttalte i sin åpningstale på NOKIO 2013:

Den eneste sikre måten å ikke ha mislykkede it-prosjekter, er å ikke ha noen it-prosjekter i det hele tatt. Og det er ikke noe alternativ. Vi kan ikke være så redde for å gjøre feil at vi ikke tar noen risiko og ikke har noe innovasjon.

Den 22 april uttalte NHO-direktør Kristin Skogen Lund:

En offentlig forsiktighetskultur rammer innovasjonen i de offentlige innkjøpene på 400 milliarder kroner: – Mer vekt på innovasjon gir en vinn-vinn-situasjon for alle og vil øke verdiskapingen i Norge.

Begge har selvsagt rett. Å være innovativ betyr å våge å satse nytt. Å tråkke et stykke utenfor det sikre og trygge. De impliserte må utenfor sin komfort-sone – fra tid til annen i hvert fall. Dette stimulerer innovasjon, men ikke bare det; Det er dette som gir utvikling. De involverte enkeltmenneskene hos kunde og leverandør får på denne måten bedre anledning til å erfare, lære og gjennom dette utvikle seg.

Den rådende kulturen

Den rådende kulturen i offentlig sektor i dag er opplagt risikoavers. Det gjelder å ikke bli beheftet med mislykkede prosjekter, og i framdriftsrapportering og evalueringer gjelder det å skjønnmale situasjonen så langt det lar seg gjøre. Dessuten legger hele strukturen i anskaffelsesreglementet opp til å forsøke å redusere risiko gjennom rigide, dyptpløyende analyser og forprosjekter. Dette er en forfeilet strategi om man ønsker innovasjon. Vi taper så mye kalendertid på den måten at verden rekker å endre seg flere ganger mens vi analyserer og planlegger!

Hvordan endre kultur?

Om vi ser på innovasjon som et opplagt gode og samtidig vet at den rådende kulturen er risikoavers, hvordan kan vi da sette i gang en nødvendig endringsprosess? Få har jobbet mer med slike endringsprosesser enn Craig Larman, og han har ganske nylig formulert Larmans law of Organizational Behavior. Jeg tror han er inne på kjernen i det siste punktet “Culture follows structure”. Om prosedyrene og belønningssystemene legger opp til en viss adferd får vi etterhvert en kultur som avspeiler dette. Om vi vil endre denne kulturen bør vi innføre solide strukturelle endringer. Hvis ikke får vi overflatiske “skinn-endringer” som i bunn og grunn er “same shit, new wrapping”. Kulturen er inntakt og forbedringene lar vente på seg.

Smidig kultur

Den smidige fremgangsmåten legger opp til (og betinger) en helt annen type kultur. Nå skal vi sette i gang å lage produktet lenge før vi fullt ut har forstått helheten (Se Kunsten å kjøpe inn det ukjente). Allerede her føler vi oss på tynn is, og den risikoaverse vil etterlyse mer analyse. Men vi motstår denne fristelsen for tryggheten beholder vi allikevel gjennom at vi i tett samarbed mellom brukere og utviklere leverer små inkrementer som vi validerer. Vi løper med andre ord ikke den virkelig store risikoen. Du kan si at vi spiser opp risikoen mens vi jobber! Vi har atså en systematikk som gjør det trygt å feile. Når de involverte oppdager dette, vil de se at det ikke er så skummelt lengre å ta sjanser. Det gir mening å snakke om “Smidig kultur” som er en tillitsbasert kultur det alle er genuint opptatt av utvikling on innovasjon framfor å finne syndebukker når noe går galt. Linda Rising hyller her “Agile Mindset“.

Et ledelsesansvar (selvsagt)

Lederne i offentlig sektor bør snarest ta Chaffey og Skogen Lund på alvor og addressere innovasjonsevne gjennom å finne måter å jobbe på som gjør det trygt å feile. Dette finnes selvsagt, se for eksempel på Scrum. Følger man dette rammeverket etter hensikten bevilger man seg omgivelser der man ikke kommer langt ut av kurs, selv om man forsøker på krevende, risikable ting. Lederne bør gå foran og snakke om unngå de store “big-bang” leveransene og heller levere i små porsjoner. De bør etterspørre – og ivre etter å snakke om – den brutale feedbacken man kan få av brukerne. Jevnlig, også når det går dårlig. Og de bør snakke om utviking og prosessforbedring basert på feedback.

 

Posted on April 30, 2014 at 1:42 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, ledelse, Planlegging, Samfunn, Scrum · Tagged with: , , , , ,

Smidigavtale med bonuser fra DIFI

I januar lanserte DIFI ny versjon av sin SSA-S. En avtaleform som jeg flere ganger har karakterisert som “halvsmidig” – et  langsomt skritt i en riktig retning. Noe som sammen med en veileder kan hjelpe offentlige IT-innkjøp et lite skritt på veien mot noe bedre, men heller ikke mer… Potensialet til “helsmidig” er mye større.

Nå har de  introdusert bonuser. Ideen med slike mekanismer er jo å gi en aktør positive incentiver til å gjøre en bedre jobb enn de ellers ville gjort. Man setter målbare mål, samler data og utbetaler en belønning om aktøren oppfyller kriteriene.

Difi skriver: “Leverandøren får bonus hvis de leverer programvare med få feil, hvis de leverer før eller til avtalt tid, og hvis de leverer til avtalt kostnad eller lavere.”

Konsekvensene av incentiver er svært vanskelig å se på forhånd. IT-prosjekter er (svært) komplekse, sosiale systemer så vi må forstå kompleksitet og vi må bruke systemtenkning. I slike systemer vil “alt påvirker alt” og legger vi  stimuli som bonuser inn i systemet, vil det få sideeffekter. Disse kan være negative. Vi har en del erfaring fra slike ordninger..

 

Bonus for få feil

Dette kan kanskje være OK. Dette er et opplagt gode, og fordi dette er et stort problem i mange prosjekter. Man tar seg ikke tid til å lage solid, korrekt kode som fungerer etter hensikten. Men det som selvsagt blir viktig er å definere “feil” på en slik måte at det blir mulig å telle disse på en fornuftig, objektiv måte, uten for mye skjønn. Når det står pengeutbetalinger på spill, kan vi ikke basere oss på skjønn. Den umiddelbare uønskede sideeffekten jeg kan se her er at leverandøren vil ha interesse av å skjule og bagatellisere feil.

Jeg er spent på hvordan dette skal praktiseres.

 

Bonus for å holde tiden

Dette er ikke OK! Mennesket er i utgansgpunktet dårlig til å estimere, vi er optimister og har vanskelig for å lære av feil (Les gjerne boka Thinking, fast and slow). Dessuten er software-utvikling komplekst, så uforutsette problemer kommer! Så det er normalt å komme på etterskudd. I en slik situasjon, når det er bonus knyttet til fremdrift, vil de som gjør jobben lett kunne ofre det gode håndtverket. Det gode håndtverket tar tid, men er veldig god økononi (for kunden) på sikt. Kunden har små muligheter til å måle og kontrollere den håndtverksmessige standarden som utføres.

Dette er selve oppskriften på å bygge opp teknisk gjeld!

 

Bonus for å levere under kostnad

Dette er ikke OK!  Å levere under avtalt kostnad blir lett uforenelig med ønsket om å lære og finne bedre løsninger mens man jobber. Hva skjer om leverandøren i dialog med brukerne finner ut at ting bør gjøres på en annen måte enn først antatt. Da blir det en vurdering om dette ekstraarbeidet kan komme i veien for bonusen.

Dessuten er dette på akkurat samme måten som bonus for rask utvikling en pådriver for å bygge opp teknisk gjeld. Det gode håndtverket koster tid og penger.

 

Bonus for å nå effektmål?

Om man på død og liv skal gi bonuser må dette knyttes til effektmål (verdi). Dette er uhyre krevende og fordrer stor modenhet både hos kunde og leverandør og man snakker om et regime som dette: http://www.flexiblecontracts.com/. Dette er spennende eksperimenter, men ganske uprøvd. Man bør uansett styre ved å gjøre kost/nytte vurderinger, men dette behøver ikke kobles til kontrakten.

 

Vi må behandle folk som voksne

Agile Manifesto (som definerer smidig) fokuserer på at det er menneskene som gjør jobben som er avgjørende. At du har dedikerte, motiverte folk som tett sammen med kunden finner løsninger underveis. At vi våger å stole på disse. Dette er ikke bare en “vakker tanke” for å gjøre utviklerne til lags. Dette er en nødvendighet hvis dette skal bli skikkelig bra! Vi klarer rett og slett ikke å kvantifisere produktivitet eller kvalitet godt nok. Så vi er henvist til den “kjedelige” virkeligheten at vi må behandle de som gjør jobben som voksne og stole på dem. Gi de ansvar og myndighet. En grad av autonomitet. På den måten får det det aller viktigste: Dedikerte folk som virkelig bryr seg om sluttresultatet.

 

Kunden må engasjere seg

Det finnes realistisk sett ingen andre modeller enn varianter av Time/Material om man virkelig ønsker innovasjon og læring underveis. Og når det gjelder risiko – så sitter kunden med den uansett. Kunden må “dessverre” engasjere seg og ha en viss kompetanse – man kan ikke distansere seg fra det. Jeg vil anbefale alle kunder som utvikler programvare jevnlig å

  1. Sørge for å ha noen egne  ansatte teammedlemmer (programmering test, design etc)
  2. Leie inn resten av kapasiteten på langsiktige kontrakter og bemann teamene med en miks av egne og konsulenter.
  3. Få på plass dedikerte, gode Scrum Mastere og Produkteiere – gjerne fra egne rekker.

På denne måten kan du få dedikerte team som er brennende opptatt av brukernes beste og som vil gjøre håndtverket grundig og bra så vi unngår å akkumulere opp teknsik gjeld.

Programvareutviklingens natur

Når vi skal bestemme oss for hvordan vi angriper problemløsning kan det være en fordel å forstå seg på de særegenhetene som gjelder for det området vi skal inn på. Mange disipliner er gamle og godt kjente og man har mengder av empiri som forteller hvordan det lønner seg å jobbe. Og innenfor veldig mange ingeniørdisipliner finner vi ganske detaljerte forskrifter og regelverk som skal sikre høy kvalitet. Dette finner vi ikke for programvare, både fordi faget er ganske nytt, men også fordi det er for komplekst til at det finnes riktige svar. Jeg mener programvare har en rekke særegenheter som gjør overføringsverdien fra andre disipliner svært liten.
 
Det er nok først og fremst historiske årsaker til at vi vanligvis angriper programvareutvikling med tradisjonelle prosjektstyringsmetoder. Vi drar med oss erfaringer fra samlebåndet, fra andre ingeniørdisipliner og prosjektstyringsfaget. Er dette en god idé?
 

7 typiske særtrekk for programvareutvikling

1. Vi kan velge å levere i små inkrementer

I motsetning til fysiske produkter, kan programvare kuttes opp i småbiter og leveres en for en. Vi kan også i stor grad velge hvilken rekkefølge vi leverer disse i. Vi har disse valgene, men det betyr ikke at det nødvendigvis ligger til rette for det. Mange har store hindringer, bygget opp over tid, som må overvinnes for å klare å levere små inkrementer.

2. Selve produktet er i praksis usynlig

Selve produktet er beskrevet med kodelinjer. Svært få er i stand til å forstå tilstanden på slik kildekode. Er dette “god” kode eller ikke? Dette aktualiserer spørsmålet: Hvordan skal kunden kunne forvisse seg om at hun får “høy kvalitet” – når kvaliteten er gjemt inne i uforståelige kodelinjer?

3. Løsningsrommet er nærmest uendelig

Om du setter 100 programmerere til å løse det samme problemet, vil du få 100 ulike løsninger. Det er en ekstrem frihetsgrad, sammenlignet med de fleste andre ingeniørdisipliner.

4. Nytt hver gang; innovasjon er en opplagt del av jobben

Vi bruker programvare for å løse nye problemer. Hvis det er løst før forsøker vi å bruke andres løsninger. Hverdagen til utviklere er at de må finne løsningen når de står oppe i den. Og man oppdager stadig at i samtaler mellom utviklere og brukere genereres det ideer som man ikke hadde tenkt på før.

5. Stor kompleksitet

Det er lite grad av repeterbarhet i programvareutvikling. Alle omgivelser er litt ulike, rammebetingelser varierer, brukere er mennesker (komplekse vesener) og det er dynamikk. Teamene som lager programvare er også i høy grad komplekse sosiale systemer med flyktig kausalitet. Vi vet at ytelsen kan variere voldsomt mellom individer – og antageligvis enda mer mellom team.

6. Dynamikk

Krav og behov vil endre seg mens vi gjør jobben. Dette varierer selvsagt med typen systemer vi snakker om, men trenden er klar overalt – det blir mer og mer dynamikk. Dynamikken kan også komme av av vi finner bedre løsninger enn vi hadde sett for oss i starten, samt at det i skjæringspunktet mellom utviklere og brukere oppstår en positiv kreativitet.

7. Livsløpskonstnaden avgjøres av vedlikeholdsvennligheten

Hvor mye det koster å gjøre én endring i programvaresystemer varierer med 10-er potenser. I godt strukturerte, vedlikeholdsvennlige systemer med innebygde tester, vil en endring trygt kunne gjennomføres på minutter. I komplekse, monolittiske systemer uten automatikk, ser vi at enhver endring potensielt får alvorlige bi-effekter slik at vi ikke våger å sette i drift uten at en masse regresjonstester kjøres. En begrenset endring kan da koste dagsverk, kanskje ukesverk. Konsekvens: Det er sub-optimalt å fokusere mye på kostnadene til prosjektet som lager funksjonaliteten. Alle programvaresystemer er mer eller mindre gjenstand for videreutvikling og det initielle prosjektet blir etterhvert en liten andel av totalen. Om dette prosjektet etterlater seg dårlig strukturert kode blir økonomien på sikt dårlig.

Konsekvenser

Så, om vi aksepterer at punktene over gir en riktig virkelighetsforståelse, hvilke konsekvenser har det for vår angrepsmåte? Hvilke modeller for organisering, styring og ledelse er best under slike forhold?
PullVsPush
Hva bør vi velge?
I Pull-systemet gir vi et tverrfaglig team fullmakt til å organisere seg på best mulig måte og å utvikle produktet løpende i tett samarbeid med kunden/brukerne. Teamet prioriterer rekkefølgen i samarbeid med kunden.
I Push-systemet forsøker vi å forstå helheten, legger en plan og jobber med hele produktet hele veien mens vi akkumulerer opp hele produktet til en stor leveranse på slutten. De ulike fasene utføres av ulike spesialister eller roller, mens prosjektleder styrer framdrift iht plan og rammer.
NB: Det er ingen premie for riktig svar!
Tips: Se presentasjonen Unngå Teknisk Gjeld på Slideshare