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

Keiserens gamle, loslitte klær

På tide å kle av prosjektveiviseren!

Følgende artikkel ble i dag 21.02.14 publisert som med tittelen Utdatert Utvikling i Dagens Næringsliv. Signert Benjamin Sommer og Geir Amsjø, Axio Consulting.

———————

Digitaliseringen av Norsk offentlig forvaltning skal få et løft gjennom IT-prosjekter etter en utdatert, standardisert mal. Er Killengreen og Chaffey klar over hva de gjør?

Det er rart hvordan avdanket teknologi og forkastet tankegods kan få noen ekstra leveår i det offentliges regi. Disketten (og maskiner som kan lese disketter) har fremdeles et marked i norsk helsevesen. Bra for de som lever av sånt, men er selvsagt svært ineffektivt.

 

prosjektveiviser

På samme måten er Prosjektveiviseren.no som Direktoratet for forvaltning og IKT (Difi) lanserte ny versjon av rett før jul basert på forkastet tankegods når det gjelder programvareutvikling. Veiviseren institusjonaliserer ”vannfallsmodellen” der prosjekter går igjennom 5 ulike faser, med beslutningspunkter mellom hver fase. Gevinster tas ut når hele prosjektet omsider er ferdig. Dette kan fungere godt for en del typer prosjekter, men er særdeles lite egnet for kunnskapsintensivt, dynamisk og innovativt arbeid som programvareutvikling vitterlig er. Ingen av de store, men fremdeles unge programvarebaserte lokomotivene i IT-bransjen (som Google, Amazon, Facebook, eBay, Yahoo, Salseforce.com, Spotify, FINN.no, for å nevne noen få) benytter denne modellen. Veldefinerte, standardiserte fasemodeller er 90-tallets forsøk på å øke suksessraten til IT-prosjektene. Vi vet i dag hvordan det gikk.

Prosjektveiviseren ble 18 desember 2013 presentert i et 4 timer langt seminar publisert her: http://www.prosjektveiviseren.no/2013/12/digitalisering-gir-gevinster. Ingelin Killengreen innledet og snakket varmt om å ”forenkle, fornye, forbedre”. Paul Chaffey overtok så og holdt et godt innlegg om viktigheten av å realisere gevinstene. Han ville ha fokus på innovasjon, gjennomføringsevne og endringsledelse. Og han avsluttet med å si at ”Difi kommer til å bli departementets viktigste verktøy!”

Den dårlige nyheten er at all erfaring viser at denne vannfallsmodellen fører til sløsing med kalendertid, byråkrati, høy risiko, dårlig kvalitet og er lite egnet til innovasjon. Den er på mange måter naturstridig når vi tenker på hva programvareutvikling egentlig dreier seg om. Vannfallsmodellen ble adoptert og institusjonalisert av US Department of Defence på 1970-tallet og har siden det vært den rådende framgangsmåten. Det er i den forbindelse svært interessant å merke seg at DoD nå synes å ha forkastet modellen og er i full gang med å institusjonalisere ”Agile”! (http://scrum.jeffsutherland.com/2012/04/dod-goes-agile.html)

I 2001 kom startskuddet for det som skulle revolusjonere programvarebransjen; ”The Agile Manifesto”. Dette manifestet definerte helt nye suksessfaktorer og verdier som er tilpasset programvareutvikling. Manifestet sier slike ting som ”Individuals and Interactions over Processes and Tools”. Dette innebærer mao at om de individene som gjør jobben er høyt motiverte, kompetente og samarbeider godt, vil det bety mer for suksess enn verdens beste, veldefinerte prosessbeskrivelser, prosedyrer og sjekklister.

Agile baserer seg på mye av den samme tankegangen som vi finner i Lean. Vi dyrker for eksempel ”pull-prinsippet” der markedet til enhver tid bestemmer hva vi fokuserer på, og at vi tilpasser kapasiteten til etterspørselen. Vi realiserer gevinster tidlig og løpende i tett dialog med interessentene. Det er til syvende og sist vår evne til å lære underveis som vil bestemme hvor godt resultatet blir. På denne måten blir også robustheten til selve produktet langt bedre ivaretatt, og risikoen lavere. Agile representerer mao et annet paradigme, optimalisert for dynamikk, hurtighet , kvalitet og innovasjon. Prosjektstyring er ikke lenger viktig.

”IT-skandalene” er mange i dette landet, og vannfallsmodellen må bære mye av ansvaret. Vi skal ikke ramse alle disse her, men nøye oss med å nevne ett eksempel referert i DN (http://www.dn.no/forsiden/politikkSamfunn/article2546457.ece) som forteller at Estland har kommet i mål med et elektronisk pasientregistersystem for 82 mill kroner. Norge har hittil brukt over en milliard, og har planer om å bruke nye hundretalls millioner.

Det er naturlig at forvaltningen og IT-bransjen har store forventninger til en blå regjering på områder som fornying, innovasjon og effektivisering. Om Difi skal spille en sentral rolle i dette arbeidet må først Difi fornyes! Det ville vært ganske oppsiktsvekkende om den nye regjeringen bidrar til å institusjonalisere en gammel, stiv og forkastet modell.

Posted on February 21, 2014 at 11:32 am by gamsjo · Permalink · 30 Comments
In: kontrakt, Kvalitet, ledelse, Planlegging, prosjektledelse, Samfunn · Tagged with: , , , , , , ,

Kunsten å planlegge det ukjente

Dette er en fortsettelse av forrige post, Kunsten å kjøpe det ukjente. Vi antar nå at vi har fått anledning til å kjøre smidig utvikling av et nytt produkt, og at den utfordringen vi står overfor er å planlegge på en slik måte at vi gradvis bygger opp mest mulig verdi for brukerne.

Den første gangen vi gjør noe slikt føler vi oss på usikker grunn. Vi vet altså ikke helt hva vi skal lage, bare hva vi vil oppnå med det. Hvordan skal en plan for et slikt utviklingsløp egentlig se ut? Hvordan sikrer vi et godt resultat? Hvilken strategi skal vi velge?

Om vi velger Scrum er visse ting gitt

Planleggingsstrategi

Hvilke kriterier vi bruker for å optimaliserer produktutviklingen vil avhenge av mange ting, som for eksempel “nyhetsgraden” av det produktet vi skal lage. Om vi ligger i front å tenker å starte fra scratch med noe kundene ikke har skjønt at de trenger ennå, bør vi legge opp til et løp som benytter Lean Start-up tankegangen. Om vi på den annen side bare skal legge på ny funksjonalitet på et eksisterende produkt med en etablert kundebase, gjelder det å alliere seg med noen representative brukere og å la disse få stor inflytelse på prioritering og utforming.

Men uansett: Planlegging av innovasjon dreier seg om å teste hypoteser. Det som er viktig er å lære mest mulig, billigst mulig. Vi må unngå å låse oss for tidlig, før vi har fått validert vår antagelser om hva brukerne gjerne vil ha. Vi trenger en dynamisk og levende kø av arbeid.

LevendeBacklog

Levende kø

 

Det som til enhver tid ligger på toppen av køen må være brutt ned i ganske små biter og være godt forstått av teamet som skal gjøre jobben. Dette betyr at hver gang en ny iterasjon starter er det enkelt å plukke ut en realistisk mengde arbeid.

Når arbeid tas ut fra toppen blir det plass til mer, hvilket jo betyr at noen av de litt større elementene lenger nede må brytes opp i midre biter og får plass i den øverste delen.

Vi kan gjerne ta vare på større produktideer og hypoteser i en slik kø, men de må bearbeides en del før de innvilges plass lengre oppe.

 

Budsjettering

Det eneste fornuftige er å unngå å låse budsjettet til en spesiell sum per år. Vi vet at vi kommer til å få verdifull ny informasjon etter noen gjennomførte iterasjoner, og denne informasjonen bør vi benytte oss av! Dessuten må vi være forberedt på at uforutsette ting (både muligheter og trusler) kommer til å påvirke vår prioritering. Så vi må være forberedt på å revurdere finansieringen løpende gjennom hele dette produktets levetid – minimum hvert kvartal.

Scenario

La oss si at vi bestemmer oss for å finansiere ett kvartal med utvikling og utviklerne anslår at det bør være mulig å få på plass en stabil plattform med en del kjørbar funksjonalitet etter ca 3 måneder (6 to-ukers sprinter) med et lite team på 5 fulltids utviklere. Her vil det være mulig å vurdere sunnheten til dette initiativet etter hver Sprint (Sprint Review).

OK, etter 6 Sprinter har teamet oppnådd mye og har vist at plattformen duger, og at de kan demonstrere enkel basisfunksjonalitet og at brukerne liker det de ser. Da kan vi velge å øke hastigheten (samt kostnadere selvfølg

Kostnader

elig) ved å sette på 3 til i teamet. Vi bestemmer å kjøre i nye tre måneder med denne bemanningen. Igjen må vi være forberedt på å revurdere denne satsningen etter hver Sprint.

Etter 6 nye Sprinter (totalt et halvt år) har vi fått i gang en aktiv, men liten brukergruppe. Vi ser at teamet nå leverer ny funksjonalitet rutinemessig hver andre uke og at potensialet er der, men vi trenger å skalere opp for å ta markedsandeler. Da kan vi for eksempel velge å sette på 4 utviklere til og dele opp i to 6-manns team. Vi vil tape noe hastighet på å ha to team jobbende på den samme koden, men overheaden behøver ikke være særlig stor.

Etter Q3 har det kanskje dukket opp andre muligheter som gjør at vi må prioritere denne satsningen noe ned, og går ned til det opprinnelige nivået på 5 teammedlemmer. I figuren ser vi hvordan kostnadsutviklingen følger dette forløpet.

Nyttige verktøy for løpende planlegging

Produktkøraffinering: Dette er en løpende aktivitet der interessentene og de som gjør jobben sitter sammen og bearbeider køen av arbeid. Erfaring fra Scrum viser at det er lurt å gjøre dette en gang i uken, til fast tid og sted. Opp mot 10% av teamets kapasitet kan være nødvendig. Her splittes store elementer opp i mindre biter, og teamet grovestimerer bitene.

Visjon: Uttrykk en samlende visjonen klart og tydelig. Det kan være formålstjenelig å både uttrykke en langsiktig visjon som er svært ambisiøs og omfattende, og en kortsiktig visjon som retter seg mot et begrenset produktinkrement. Den kortsiktige er da underforstått et steg på veien mot den langsiktige. Visjonen bør definere interessentene, hvilke behov disse har og hvordan forretningsmodellen ser ut. Det bør også være klart hvordan man har tenkt å måle at man er på vei mot målet. Risiko bør også innbefattes i visjonen.

Måling: Vi må sørge for å skaffe oss solid feedback på det vi leverer. Det er nyttig å få direkte feedback fra brukere på en demontrasjon (Sprint Review i Scrum) men den ultimate valideringen får vi fra markedets respons – som da må sees opp mot den gevinsten vi håpet å få. (Eksempler på målinger: Raskere saksbehandlingstid, flere betalende kunder, øker konverteringsgrad, antall besøk på en web-side, bedre brukervennlighet, høyere kundetilfredshet etc..)

Planleggingsstrategi: Rekkefølgen vi velger å realisere funksjonalitet i vil være svært avgjørende for suksess. Det anbefales sterkt å begynne med å skaffe seg en stabil, men ikke komplett plattform å bygge produktet på. Deretter å lage funksjonalitet beregnet på en liten del av markedet og da prioritere funksjoner dette segmentet ønsker seg. Bruk her gjerne MMF eller MVP. Om det er noen absolutte milepæler i kalenderen vil dette være styrende.

Veikart (Road Map): Det anbefales å vedlikeholde et overordnet veikart som til enhver tid reflekterer hvordan framtiden ser ut. Dette kartet er kun en plan basert på den informasjonen man har på et gitt tidspunkt, og kan ikke betraktes som noe løfte.

Et veikart kan være funksjonsorientert som i figuren, men det kan være formålstjenelig å inkludere andre detaljer slik som avhengigheter, teknologiske milepæler, eller for eksempel opplæringsplan.

 

 

Posted on January 29, 2014 at 12:14 pm by gamsjo · Permalink · Leave a comment
In: Planlegging, produkteier, prosjektledelse, Scrum · Tagged with: , , , , ,