Agile Coach Camp Norge vel overstått

ACCN ble avholdt for andre gang og er nå offisielt definert som tradisjon! Fra 6 til 8 januar opplevde de 35 deltagerne et veldig praktisk rettet dypbykk ned i temaet Smidig coaching. Temaene var godt spedt rundt Retrospectiver, Coaching Skills, Scope Discovery, Bruk av LEGO i undervisning, Coaching Big organisations, Agile Strategy, Coding dojo etc etc. De fleste deltagerne var allerede erfarne praktiserende coacher hvilket gjorde at nivået ble veldig høyt. Evalueringen (siste punkt på agendaen) var udelt positiv og vi følger etter alle solemerker samme oppskrift også neste år. En stor takk til Sergey Dmitriev som er primus motor for dette evennementet.

Agenda

Campen hadde en veldig enkel agenda:

Fredag kveld: alle presenterer seg – 2 minutter hver. ”Hemmelig key-note”: Jan Georg Kristiansen holder en introduksjon til faget Coaching.

Lørdag: Coaching Dojo og Open Space til langt på natt.

Søndag: Open Space og avslutning/retrospective før lunsj kl 12.30.

 

Introduksjon til profesjonell coaching

 Olaf Lewitz har blogget om dette innslaget her

Vi starter Coaching Dojo

Først går vi igjennom Powerful Questions, de tre nivåene av lytting og GROW modellen.

 

Detaljert agenda blir til underveis

 

Sergey hjelper oss til å holde fokus

 

Noen av profilene:

 

 

Andre som har blogget om coach campen:

Marianne Worren

Rob van Lanen

Johannes Brodwall på Sterk Blanding

Fler? Anyone?

Et spørsmål om kompleksitet

Vi har diskutert dette før. Hva baserer vi beslutninger på? Hvordan styrer vi mot et mål? Hvordan planlegger vi på best mulig måte? Hvordan sikrer vi at vi jobber effektivt? Disse fundamentale spørsmålene må ledere på alle nivåer ha et bevisst forhold til. På mange måter kan alle disse spørsmålene besvares med “Det kommer an på kompleksiteten“. Svarene blir forskjellige, avhengig av hvor enkle problemstillinger vi typisk må hanskes med. 

Holder vi på med forholdsvis enkle oppgaver gir det mening å lage en detaljert plan med milepæler som vi kan følge opp etter. Hvis vi repeterer disse enkle oppgavene gir det også mening å lage detaljerte prosedyrer og å sørge for å måle effektiviteten slik at vi stadig kan forbedre oss. Men hvordan skal vi lede og styre når oppgavene er innviklede og komplekse slik at vi ikke en gang klarer å estimere hvor lang tid en oppgave vil ta?

Arbeidslivet har forandret seg radikalt siden mellomkrigstiden. Allikevel baserer den rådende læren om ledelse seg på Frederick Tailors ideer kalt Vitenskapelig ledelse. Dette er “command & control” type styring hvor lederne leder og arbeiderne utfører oppgaver. Vitenskapelig ledelse var effektivt når Ford produserte biler ved hjelp av en mengde maskinelle og forholdsvis enkle prosesser. Men filosofien kommer sørgelig til kort i dagens svært komplekse oppgaver som innebærer stor grad av nyskapning, usikkerhet og kompleksitet.

Mennesker undervurderer lett kompleksitet. Vi har ofte en naiv tro på enkle årsak- og virkningsforhold selv om bildet er svært sammensatt. Innen helse og kosthold gir forskningen få helt entydige svar. Menneskekroppen er rett og slett en svært innviklet og kompleks organisme. Grundige studier viser at det ikke finnes noen vidunderkur mot forkjølelse. Allikevel har mange en klokketro på forkjølelsesmedisin. Vi synes vi ser et årsaksforhold, selv om årsaken til at forkjølelsen forsvinner alltid er at mikrobene blir nedkjempet på vanlig måte av kroppens forsvarsmekanismer. “Det tar den tiden det tar”.

Det er selvsagt vanskelig å planlegge forskning, og det er svært ofte at store gjennombrudd i innovasjon og forskning slett ikke var planlagt, men snarere et biprodukt som oppstod på veien. Derfor er det et paradoks for meg at søknader om forskningsmidler gjerne krever en detaljert plan. Det som skjer er at forskerne tilpasser seg systemet og later som de kan lage detaljerte målsetninger og fremdriftsplaner, men de vet at så snart de har fått tilsagn om midler vil de i praksis få stor frihet til å avvike fra planen.

Et annet eksempel er helsevesenet som skal behandle søknader om støtte eller erstatning etter sykdom. Det er slett ikke alle sykdommer som har en enkel diagnose og kombinert med en litt uvanlig arbeidssituasjon så kan saken få svært mange variabler og mulige utfall. Allikevel er NAV fullstendig regel- og prosedyre-styrt med lite rom for individuelt skjønn. Konsekvensen er at de kompliserte sakene bruker svært lang tid rundt i systemet og belaster totalen, selv om det kanskje ikke er så mange av dem.

I IT-bransjen har vi lang tradisjon for å undervurdere kompleksitet. Vannfallsmodellen er basert på Taylors ideer og forutsetter at vi estimerer og jobber planmessig mot en leveranse av noe vi gjetter på at det vil være etterspørsel etter. Selv om mange i dag bruker smidige metoder og Scrum på utvikling er fremdeles kontraktsgrunnlaget og de tidlige fasene preget av tradisjonell tenkning. Det som skjer i praksis er at vi “later som” om vi ikke har stor usikkerhet. Vi avkrever folk estimater selv om de ikke har forutsetninger for å vite hvor lang tid en oppgave vil ta. Og når vi så begynner å jobbe går det ikke lang tid før vi må gjøre det beste vi kan for å komme i land med noe som gir verdi, selv om den opprinnelige planen har null verdi.

Cynefin – et rammeverk for å forstå kompleksitet

I HBR-artikkelen A Leader’s Framework for Decision Making av David J. Snowden and Mary E. Boone diskuterer forfatterne modellen og hvordan den kan benyttes av ledere. Snowden deler “universet” inn i 4 ulike domener:

Enkle

Dette er “Best Practice” området. Det finnes fasitsvar og årsak-virkningsforholdene er ganske åpenbare. Vi kategoriserer oppgavene og kan deretter gjennomføre slavisk. Gode muligheter for automatisering. Prosedyrer, regelverk, detaljplaner og ytelsesmålinger kan brukes med hell.

Kompliserte

Ekspertenes domene. Minner om det enkle, men her finnes flere mulige riktige svar og vi må konsultere spesialistene for å finne ut av et problem. Ting kan estimeres av ekspertene med OK presisjon og detaljplanlegging kan fungere helt greit, men man må være forberedt på at målingene man gjør ikke alltid er sammenlignbare.

Komplekse

Domenet for “emergence“. Dynamikk gjennom at alle systemets bestanddeler påvirker hverandre, omtrent som i en bisverm eller en maurtue. Resultatet blir robust og godt, selv om det ikke foreligger noen klar plan. Her finner ikke lenger fasitsvar, kun oppfatninger. Vi kan finne årsak-virkning forhold i retrospekt, men vi kan ikke forutsi problemer. Vi må ta raske beslutninger basert på ulike typer av informasjon. Dette er selvsagt området for nyskapning og innovasjon – der “prøving og feiling” er en farbar vei. Tverrfagling teamarbeid og selv-organisering er effektivt siden ingen enkeltperson sitter med løsningen.

Kaotiske

Domenet for rask handling. Her er det ikke tid til å analysere, man blir tvunget til å handle basert på erfaring, strategi og “mavefølelse”. Katastrofer og krig faller inn her. Ingen riktige svar, årsak-virkning ofte umulig å finne.

Modellen er veldig nyttig for å bestemme seg for ledelsesform i et selskap. Alle fire domenene har sine spesielle karakteristika og og det gjelder å motstå fristelsen til å tro at ting er enklere enn de er. Mange organisasjoner vil måtte jobbe med hele spekteret og derfor være bevisste på hvilken styringsform som er best egnet. Om man ønsker å fordype seg i dette har Agile42 et kursopplegg for ledere basert på Cynefin.

IT-bransjen og Cynefin

Vi har en god blanding av alle 4 domenene i bransjen.

Rent datakvalitetsarbeid kan bli rutinepreget og enkelt, mens mye forvaltningsarbeid nok faller inn i kategorien komplisert. Det aller meste nyutvikling av IT-systemer faller inn i kategorien komplekst. Kaos kan vi også oppleve om enn sporadisk. Enkelte samfunnskritiske funksjoner kan falle ut på grunn av en IT-feil, og da er det ikke rom for mye analyse og planlegging lenger.

Valg av styringssystem

• Er ting enkelt så fungerer jo gode gamle Taylor med Command & Control og detaljstyring.
• Til mer kompliserte oppgaver som forvaltning kan det være lurt å vurdere å bruke Kanban, der oppgavene som kommer inn prioriteres og løses fortløpende en av gangen med en klar begrensning gitt av teamets kapasitet.
• I det komplekse området er Scrum skreddersydd. Dette rammeverket har alle de nødvendige mekanismene innebygget.
• Og er det kaos og kritisk – vel, da er det vel bare å mobilisere de flinkeste folkene og være en tydelig leder.

 

 

I løvens hule

Det var med skrekkblandet fryd jeg tok plass på første rad på Dataforeningens arrangement Smidige metoder i Prosjektgjennomføring her om dagen. Jeg skulle som tredje og siste taler forklare alle de 80 fremmøte prosjektlederne at Prosjektet som arbeidsform har en del svakheter. Selv om “Smidige” var det første ordet i tittelen på dette medlemsmøtet, merket jeg raskt at forståelsen av Smidig ikke var helt i henhold til Agile Manifesto. Ikke helt uventet. Jeg åpnet mitt foredrag med å be de deltagerne som hadde et forhold til Agile Manifesto om å rekke opp hånda. Mindre enn en tredjedel responderte. Men de fleste var antageligvis kommet for å lære – og det er jo bra.

Foredraget ligger på Slideshare

Har Prosjektet skylda?

Jeg mener faktisk at Prosjektet har en betydelig del av ansvaret for kvalitetsproblemene og den enorme kompleksiteten vi ser i IT-systemene. Dette med programvarekompleksitet er ikke noe nytt, jeg husker vi for 10 år siden også var veldig opptatt av “kompleksitetskrisa” vi står overfor. Hvordan kan Prosjektet få skylda for dette da? Jeg tror hovedproblemet er at i Prosjektet gir vi alt for mye ansvar til en midlertidig organisasjon som jobber mot en sluttermin. Denne overleveringsdatoen blir veldig styrende og de som jobber i prosjektet vil fokusere på å oppfylle avtalen på dette tidspunktet. Dette hensynet har en tendens til å overskygge ønsket om å skape mest mulig verdier for brukerne av systemet. Dette er ikke særskilt IT-problem, et godt eksempel på dette problemet har vi sett i vegbransjen se senere årene:

HVORFOR?

Jeg tror ikke vegentrepenørene er noe spesielt umoralske eller slurvete. De tar en kalkulert risiko og de regner med at de ikke vil bli stilt til ansvar for eventuelle problemer som kan oppstå senere. I IT-bransjen er sjansen for å “slippe unna” med dårlig håndtverk betydelig større. Og forskjellen på godt og dårlig håndtverk er mye mer flytende. Programmering har ikke forskrifter, retningslinjer eller standarder. Det finnes anerkjente mønstre (Patterns) og det begynner å bli en etablert forståelse av “best practice” innen systemutvikling. Men slikt har kundene typisk inget forhold til.

Vi ofrer selvsagt kvalitet fordi det koster noe. Det koster typisk både tid og penger. Når penger og/eller slutterminen blir styrende blir vi tvunget til å velge, og spørsmålet blir fort “hvor lite kvalitetsfremmende tiltak kan vi slippe unna med“. Etter min erfaring er ikke dette noe som sies høyt, men enhver håndtverker vet at dette er en realitet.

Programvarekvalitet?

Om et prosjekt virkelig har et brennende ønske om å etterlate seg et velstrukturert, lettfattelig og fremtidsrettet system så finnes det en hel del gode metoder og praksiser man kan velge å benytte. Refaktorering  - gjerne på flere nivåer – synes å være en betingelse. Etter hvert som systemet utvikler seg vil gamle design- og arkitekturbeslutninger stå for fall. Vi bør gjøre en jobb under overflaten som gjenoppretter systemets struktur. (Se presentasjonen til Karianne Berg fra Javazone : Strukturert refaktorering).

Dengang jeg programmerte brukte vi peer-reviews mye. Vi leser hverandres kode før den slippes inn i systemet. Dette er en enkel og kraftfull praksis som både fører til bedre lesbarhet, færre feil og kompetansespredning. Et godt alternativ til dette kan være par-programmering.

I de senere årene har det kommet en hel del nye teknikker og konsepter: Test Driven Development (TDD), Acceptance Test Driven Development (ATDD) , Behavior driven development (BDD), Clean Code, etc etc..

Felles for alle disse metodene er jo at de har en prislapp. Verdsetter kunden kvalitet så høyt at han alltid er villig til å bruke tid og penger for dette, selv om slutterminen da ryker? De finnes nok, men jeg har aldri sett en slik kunde. The Iron Square er ubarmhjertig – skal du være sikker på at systemet i det lange løp er vedlikeholdsvennlig nytter det ikke å prioritere ned kvalitetsfremmende teknikker og metoder. Litt av problemet her er nok at vi er vant til at vi kan velge oss et kvalitetsnivå for en vare. Dette er en farlig tanke når det gjelder programvare (som Martin Fowler har beskrevet her i sin “Tradable Quality Hypothesis”). Kunden vil alltid måtte betale for denne manglende kvalitetene senere en gang i form av høyere vedlikeholdskostnader. Vi kaller dette gjerne teknisk gjeld. Som all annen gjeld har den renter (høyere endringskostnader) og den skal betales tilbake på et senere tidspunkt.

Vi må begynne ta virkeligheten på alvor

De fleste IT-kundene utvikler sine systemer mer eller mindre kontinuerlig. Hvorfor ikke da etablere en kontinuerlig organisasjon? På denne måten kan vi slippe unna denne slutterminen som blir så styrende. I Scrum er det ingen prosjektleder og det er ikke tilfeldig. Det er jo ikke noe prosjekt heller – det ble laget for produktutvikling.

De mest vellykkede smidige organisasjonene har ganske permanente Scrum team som utvikler systemene. Produkteier og utviklingsteamene vet at de skal jobbe med dette produktet over lang tid. Ingen sluttermin. Dermed blir det også i deres egen interesse å holde kvalitetsnivået så høyt som mulig – for hvis ikke blir de selv forsinket.

I noen perioder et det stor aktivitet i andre mindre. Det er unødvendig med en egen “vedlikeholdsfase”. En Scrum-organisasjon lar seg lett skalere opp og ned, uten at man dermed behøver å lage revolusjon og etablere en ny organisasjon av den grunn. Om man ønsker det kan man enkelt starte og stoppe prosjekter “på utsiden” av Scrum. Disse prosjektlederne må da legge fram gode kost/nytte analyser og på den måten få Product Owner til å slippe dem til høyt oppe i Product Backlogen. De er med andre ord interessenter på lik linje med de andre.

Jeg tror på ingen måte Prosjektets tid snart er omme i IT-bransjen. Men jeg tror denne arbeidsformen vil få mindre og mindre betydning både i offentlig og privat sektor.

 

 

 

Hva er nytt i Scrum?

Jeg har tidligere proklamert “Det kommer ingen Scrum 2.0″ og det er fremdeles slik jeg tolker herrene Jeff Sutherland og Ken Schwaber. Men det forhindrer ikke at Scrum guiden på Scrum.org nylig fikk en oppdatering. Ingen stor dramatikk i endringen, men enkelte presiseringer og endringer kan være verd og merke seg.

Endringene forklares av Ken selv i denne podcasten. En kortversjon av endringene finner du her.

Jeg synes enkelte endringer er ubetydelige, noen er gledelige og andre kan være mer problematiske. Her følger noen synspunkter.

Gledelig endring

Det er gledelig at Release Planning meeting og Release Burndown nå ikke lenger er en del av Scrum. Dette er gledelig siden det har vært en tendens til at “gammeldagse” prosjektledere har brukt dette som en slags unnskyldning for å ikke release oftere og oftere. En eller annen form for langsiktig planlegging er selvsagt fornuftig, men dette tones altså ned i Scrum Guiden. Teknikker som Road Maps, Minimal Marketable Features, Story Mapping osv kan passe å bruke her, men Scrum skal som kjent ikke inneholde teknikker.

Problematisk

Jeg liker ikke at ordet commitment er erstattet av forecast for Sprint planleggingen. Bakgrunnen er at mange opplever at commitment er et litt for sterkt ord og at en del ledere vil opplever dette som et løfte. I komplekse IT-satsninger er det selvsagt umulig å love noe. Men vi kan love å gjøre vårt beste! Og vi kan jobbe hardt for å rydde unna avhengigheter og usikkerhet slik at vi får tro på Sprinten. Jeg liker å knytte forpliktelse til Sprinten for å være tydelige på at Product Backlog i motsetning til Sprinten ikke kan være en forpliktelse. Enkelt sagt tydeliggjør dette forskjellen mellom Product Backlog og Sprint Backlog. Forecast er jo som i en værmelding en slags prognose over hva vi sannsynligvis vil klare å levere. Helt greit det og, men vi mister da verktøyet for å nyenasere forskjellen på Product Backlog og Sprinten.

Ubetydelige presiseringer

Jeg synes det er en grei presisering at Scrum Teamet nå omfatter produkteier, Scrum Master og utviklingsteamet – the Development Team. Viktig å få fram at PO, SM og utviklerne må fungere som et team.

Helt OK også at burndown chart ikke lenger er mandatory. Andre teknikker kan fungere like fint når det gjelder å holde rede på gjenstående arbeid og hvordan man ligger an.

Bruken av Sprint Backlog er åpnet litt opp. Ikke lenger nødvendig å lage tasks – man kan jo for eksempel velge å bryte ned Sprinten Broduct Backlog Items på en annen måte. Eller ikke bryte ned i det hele tatt.

Product Backloggen er nå ordnet (ordered) i stedet for prioritert (prioritized). Poenget er at den til enhver tid skal ligge i en bestemt rekkefølge som PO har bestemt. Jeg synes denne endringen er ganske ubetydelig og de som vil kan lese Jim Copliens begrunnelse her.

 

 

 

Prosjekter kommer og går, Scrum teamet består

Sammenfallende interesser

Jeg ble nylig spurt om hvilken faktor som er mest avgjørende for suksess innen prosjektstyring og jeg tror kanskje svaret er at kunde og leverandør har de samme interessene. Som kunde skal man velge riktig leverandør som er kompetent til å gjøre jobben, men som ikke tar for høy pris. Og man skal sikre at gjennomføringen skjer i henhold til avtalen. Om man finner en leverandør som brenner for å skape verdier for deg av høy kvalitet på en rimeligst mulig måte er mye av denne jobben gjort!

Skal man selge et hus er det vanlig at eiendomsmegleren skal ha en liten % av salgssummen. Min eneste interesse som selger er at huset mitt blir solgt for høyest mulig pris, så her har vi en opplagt sammenfallende interesse. Men vent nå litt – dette er kanskje litt for enkelt. Om den eneste interessen vi begge har er høyest mulig pris i salgsøyeblikket så vil man lett bli fristet til å overselge. Hvis vi kliner på et malingsstrøk over den flassende bakveggen og brålegger noen fliser over det fæle gulvbelegget på badet så kan vi sikkert oppnå høyere pris! Høres ut som en god ide, men ikke særlig etisk. Dessuten finnes det garantiordninger som gjør det risikabelt å ty til slikt juks for å optimalisere egne interesser. Heldigvis, for i løpet av noen få år vil resultatet av hastverksjobben komme til overflaten.

Når jeg skulle male huset, tok jeg en del bilder og anslo flateinnholdet til husveggene og satt ut jobben på anbudstorget.no. Jeg fikk over 20 fastpris-tilbud som strakk seg fra 6.000 til 70.000 kroner(!) Jeg er ingen ekspert på husmaling, men jeg har satt litt inn i det. Det skal man selvsagt gjøre som kunde. Jeg vet at om resultatet skal bli godt – i mange år framover – skal overflaten skrapes, vaskes, påføres soppdreper, så tørke (i 14 dager) for deretter å påføres 2 strøk maling. Jeg gjetter på at de billigste ikke hadde tenkt å skrape og vaske mye… Hvordan velge maler og være trygg på at jobben blir riktig gjort samtidig som det ikke blir veldig dyrt? Instinktivt så jeg meg om etter en lokal maler. Han oppga referanser i mitt nærområde og hadde opplagt interesse i at jeg ble fornøyd. Både med selve gjennomføringen og med sluttresultatet. Han som fikk jobben lå ganske lavt i pris (ca 25.000) og leverte en fremragende jobb. Det må legges til at selv om jeg var ganske trygg på at maleren var interessert i å gjøre en håndtverkmessig god jobb, så passet jeg på å følge med litt. Men jeg er ikke kompetent til å avgjøre om skrapingen og vaskingen ble gjort med den nødvendige grundighet.

Hva er så interessene til en kunde i typiske IT prosjekt? Han har først og fremst et behov som skal tilfredsstilles gjennom utvikling av ny IT-funksjonalitet. Det kan dreie seg om å bygge videre på eksisterende systemer, eller å lage noe fra grunnen av. Uansett må vi sikre oss at prisen er riktig, at leverandøren er kompetent og at han er i stand til å kjøre prosjektet med god kontroll. Men dette er ikke nok, situasjonen er litt mer sammensatt enn som så. Når vi legger ut anbud vil pris bety mye for hvem som blir valgt. Pris behøver ikke nødvendigvis å bety alt, men det vil typisk bety mye. Alle som har vært med på noen IT-prosjekter vet at det er umulig å detaljspesifisere alt omfanget. Og planen vi legger i starten må ganske raskt revideres. Det er kompleksitet og usikkerhet i flere ulike dimensjoner som gjør at vesentlige ting høyst sannsynlig vil endre seg. Hvilke interesser har kunden og leverandøren i lys av dette? Kunden er opplagt interessert i at spesifikasjonen treffer behovene så godt som mulig og at det dermed blir så lite endringer som mulig. Kunden må alltid betale prisen for endringer. Man bruker endringsordre og en formell prosess for godkjenning av endringer for å forhindre at antallet endringer “tar helt av”.

Leverandøren vil se seg tjent med endringer. De erfarne leverandørene vet at de faktisk kan gå inn med en urealistisk lav pris for å vinne oppdraget, men allikevel ende opp med pen gevinst på grunn av alle endringsordrene. I tidlig fase vil leverandøren være tjent med at detaljene er uklare og løsningene som er foreslått er uhensiktsmessige. Slikt vil gi mulighet for endringsordre. Vi har her en kraftig polarisering av interesser!
Susan Atkinson og Gabrielle Benefield utbroderer dette problemer på INFOQ i artikkelen The Curse of the Change Control Mechanism.

Et annet område der det er vanskelig å ende opp med sammenfallende interesser er på “vedlikeholdbarhet”. Dette er en egenskap ved leveransen som er vanskelig å måle. Og nettopp fordi den er vanskelig å måle blir den ofte neglisjert. IT-systemer kan være overraskende seiglivete og de har en tendens til å bli svært store og uoversiktelige over tid. Dette resulterer selvsagt i at kompleksiteten blir stor og at systemene blir gradvis mer arbeidskrevende å endre. Kunden har alt å tjene på at dette problemet bekjempes med harde midler. Men lite tyder på at dette blir gjort. Kostnadene ved å gjøre endringer er svært høy – og vi leser stadig om at politiske reformer og lovendringer nesten ikke lar seg implementere på grunn av at IT-systemene ikke lar seg endre på noen fornuftig måte. Slike systemer har stor teknisk gjeld. En leveranse kan altså være strålende på overflaten (det som kunden ser), mens selve strukturen og lesbarheten på koden er så som så. Det bør ikke stikkes under en stol at de store leverandørene og konsulentselskapene lever godt av denne kompleksiteten. Ja, vi kan si det så sterkt at vi også her har en polarisering av interesser.

Vi vet en del om håndtverket programvareutvikling. Akkurat som malermestere vet hva som er godt håndtverk, har vi en del gode prinsipper og metoder å følge innen programvare. Og akkurat som grunnarbeidet til maleren vil disse tingene ta tid og koste innsats. Enhetstester, systemtester, kodegranskninger, refaktorisering (refactoring), konsepter som “Clean Code” og Testdrevet utvikling – alt dette vil nødvendigvis ta tid. Og bare for å ha sagt det: utviklere flest ønsker å gjøre håndtverket sitt godt, det er ikke her problemet ligger. Konsulenten blir ikke premiert for å bruke tiden sin på dette, snarere tvert imot. Men hvilken kunde er det som har nok innsikt i programvareutvikling til å virkelig verdesette dette? Nei, det er betydelig enklere å kjøpe malertjenester enn IT-systemer på fastpris.

Selv om det er vanskelig å være IT-kunde må dere slutte å stikke hodet i sanden og ønske dere en verden som er enkel, grei og visuell. De store skjærene ligger dessverre under overflaten og er ikke lett å få øye på for et utrenet øye. Dessuten er det naivt å regne med å få hjelp fra leverandørene, de tjener penger på disse skjærene…

Scrum feiler ikke!

Jeg er vant til at enkelte blir litt provosert over dette utsagnet. Kanskje ikke så rart, det er unektelig en bastant påstand!

Jeg berørte dette sammen med Sergey Dmitriev på XP meetup i Trondheim her for leden med overskriften Scrum fungerer alltid!

Poenget er selvsagt at Scrum er et enkelt rammeverk – som egner seg utmerket som basis til å lage seg en metode. Man må se på dette som et verktøy. Om du kjøper deg en skikkelig hammer og leser et par “Gjør det selv-bøker” blir du ikke nødvendigvis en god snekker, vel? Ikke umiddelbart i alle fall. Vil du da skylde på hammeren? Har du talent og praktiserer og øver så kan du komme ganske langt, selv uten fagutdannelse.

Veldig mange mislykkes dessverre med Scrumsatsningen sin. Dette skyldes sjelden rammeverket. Rammeverket er jo laget for å legge til rette for øving. Scrum kan skape en fantastisk gjennomsiktighet. Du kan analysere delleveransene og arbeidsmetodene dine om igjen og om igjen om derigjennom bli veldig god – hvis du er villig til å legge arbeid og dedikasjon i å optimalisere metoder og verktøy.

Gartner Group har nok forstått at Agile-toget forlot perrongen mens Gartner stod med ryggen til og de forsøker stadig å posisjonere seg inn igjen. Det siste innspillet fra Peter Hidas på Peters Plass i Computerworld gikk på at Scrum er ikke nok – Gartner mener vi trenger Enterprise-class Agile Development. Mulig det. Om du bruker Scrum etter intensjonen vil du oppdage dette og innlemme dette i egne Scrum-baserte prosesser. Man trenger ikke noen Gartner-modell for det vel?

Jeg har sans for måten Ken Schwaber uttrykker det:

Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played, or not. Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become outstanding development organizations, cherished by their customers, loved by their users, and feared by their competitors.

Store overskridelser i IT-prosjekter. Hva så?

Forskeren Magne Jørgensen resonnerer om overskridelsene i IT-prosjekter i en ny kronikk i Computerworld. Advokaten Jan Sandtrø kommenterer her. De har mange gode poenger, men adresserer ikke det viktigste: De definerer ikke “vellykket” på noen klargjørende måte.

Jeg har vært i IT-bransjen i snart 25 år og når jeg tenker tilbake i tid, kan jeg lett finne eksempler på programvareprosjekter som har vært vellykkede i den forstand at de har levert i henhold til spec, i rett tid og innenfor budsjett. Men jeg finner langt flere eksempler på prosjekter som ikke har vært vellykkede i samme forstand. Det som imidlertid slår meg er at denne vellykketheten ikke betyr mye for den reelle verdiskapningen.

Verdiskapningen må vurderes av interessentene. Interessentene kan vi grovt sett dele i to grupper: De som skal bruke systemet og de som skal vedlikeholde systemet. Om et prosjekt har resultert i en fantastisk forbedring for mange brukere spiller det liten rolle om det har levert på avtalt tid. IT-prosjekter er uansett komplekse og nyskapende og vi bør ikke lure verken oss selv eller kunden til å tro at vi klarer å estimere omfanget med særlig grad av presisjon. (Les mer om ønsketenkning her)

Jeg har observert prosjekter som har levert på tid/kost/omfang, men som har bommet fullstednig på behovene. Eller like ille – som har etterlatt seg en elendig kvalitet og et unødvendig komplekst produkt som er lite vedlikeholdsvennlig. Samtidig er det også lett å finne prosjekter som har vært fullstendig mislykkede etter prosjektdefinisjonen tid/kost/omfang, men som allikevel har skapt fantastiske verdier for interessentene.

Jeg håper og tror IT-bransjen snart begynner å bli moden nok til å begynne å diskutere verdiskapning i stedet for leveranse i h.t avtale. Den dagen forskerne og advokatene interesserer seg mer for dette enn for overholdelse av kontrakt tror jeg vi har kommet et langt steg i riktig retning!

Det smidige manifest – fase 1 er over

De første 10 årene med Agile Manifesto har rystet IT-bransjen. På tide å oppsummere.

Om et par måneder er det 10 år siden 17 personer møttes på “The Lodge” i Wasatch mountains of Utah der de etter noen dager med diskusjoner signerte det smidige manifest (Norsk utgave her: http://agilemanifesto.org/iso/no/). Dette var representanter for Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development og Pragmatic Programming – alle ulike retninger og metodeverk som hadde det til felles at de brøt fundamentalt med tradisjonell prosjekttankegang. En slags visjon for et gigantisk endringsprosjekt! Som vi vet ble de enige om 4 overgripende utsagn som skulle beskrive de endringene IT-bransjen måtte gjennomgå for å utvikle bedre softwarebaserte systemer:

Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan

Hvordan er tilstanden her 10 år etter? Setter vi menneskene og kommunikasjon høyere enn prosedyrer? Setter vi fungerende programvare over dokumentasjon? Har vi blitt bedre til å samarbeide kunde – leverandør? Har vi klart å frigjøre oss fra detaljplanen og blitt gode til å håndtere endringer med største selvfølgelighet? Ikke lett å svare på dette selvsagt, men en viss bevegelse har det utvilsomt vært!

De fire utsagnene er veldig overordnede og umulig å bruke som målestokk for en framdrift fra høyre mot venstre. Da er det kanskje mer matnyttig å gå de tolv underliggende prinsippene litt etter i sømmene. Man finner norsk utgave at prinsippene her: http://agilemanifesto.org/iso/no/principles.html. Her kan det være på sin plass med en presisering. Manifestet har blitt forsøkt marginalisert og bagatellisert av tradisjonelle prosjektledere. Utsagnene sier ikke mye om graden av endring – det skal innrømmes – men jeg vil våge påstanden at samtlige av disse 17 både da og den dag i dag vil mene at det man er ute etter et et paradigmeskifte. Altså ikke prosjektstyring med visse justeringer og presiseringer.

En subjektiv evaluering

Jeg snakker med mange “smidig-entusiaster”, deltar på konferanser og meetups og jeg har jobbet med ca 25 ulike organisasjoner de siste 2 årene. Så jeg tenkte jeg skulle våge meg på en enkel og høyst subjektiv evaluering av “tingenes tilstand” i Norge ved inngangen til 2011.

De 3 første prinsippene gjelder enkelt sagt hyppige leveranser og kontinuerlig verdiskapning. Bemerk: Når manifestet sier leveranse betyr dette leveranse helt ut til brukeren og altså ikke ut på en test-server eller lignende. Her må vi nyansere litt, for det er en del tilfeller der hyppige leveranser er meningsløst. Dette er spesielt der hardware/firmware utvikling er sentralt samt enkelte markeder som av natur gjør store lanseringer av nye produkter (som f.eks spillbransjen).
Tilstand: Her er det enorme forskjeller; jeg kjenner til organisasjoner som har vært “smidige” i tre år og kun har levert en gang i året. Samtidig finnes det organisasjoner i Norge som leverer ukentlig med største selvfølgelighet. Det er nok spesielt innen kontraktsregulert systemutvikling at man fremdeles leverer sjelden.

Det 4. prinsippet tar til orde for daglig samarbeid mellom forretningssiden og utviklerne. Jeg tror mange kan oppnå stor forbedring om man ikke nødvendigvis har kontakt daglig – men prinsippet er godt.
Tilstand: Store forskjeller her og, men spesielt der hvor man driver egenutvikling av IT-systemer er det mange som får til dette. Igjen er det mest å hente i kontraktsregulerte prosjekter.

Det 5. og 6. prinsippet sier at vi må fokusere på motiverte, flinke folk som samarbeider tett og som får tilgang på den infrastrukturen og de hjelpemidlene de trenger.
Tilstand: her er vi blitt ganske gode i Norge! Mitt inntrykk er at de fleste føler at de blir hørt når de ber om bedre utviklingsomgivelser. Når teamene henvender seg til linja som team eller via en Scrum Master så blir de ofte hørt på og behovene tilfredsstilt. Unntak her synes å være de store organisasjonene som har utpreget kostnadsfokus. Distribuerte team er kanskje den største hindringen.

Prinsipp 7 sier rett og slett “Fungerende programvare er det primære målet på fremdrift.” Vel, dette krever jo at man har noe ferdig produkt å vise fram med jevne mellomrom.
Tilstand: I likhet med de tre første prinsippene varierer dette naturlig nok voldsomt. De som kjører kontraktsbaserte prosjekter vil ofte “rapportere framdrift” på en ganske tradisjonell måte.

Prinsipp nummer 8 tar til orde for å jobbe i et jevnt tempo.
Tilstand: De fleste som bruker Scrum har utnyttet dette med ganske stabile team over tid – og mange har sluttet å kjøre småprosjekter for å få ting gjort. Dette lager en fin rytme og stabil framdrift over tid. De som har lengst vei å gå her er nok de med veldig spesieliserte folk og de som jobber i kontraktsbaserte prosjekter.

I prinsipp 9 skal man ha kontinuerlig fokus på “teknisk kvalitet”. Dette henger igjen tett sammen med det å lage noe helt ferdig ofte slik at man får synliggjort og evaluert denne kvaliteten.
Tilstand: Ingen overdrivelse å si at dette varierer kraftig – det er veldig mange som sliter med gammel teknisk gjeld og når de innfører Scrum så blir det helt tydelig at dette smerter. De som er så heldige at de kan få starte fra scratch vil uten unntak (i min erfaring) ha stort fokus på “clean code”, enkelt design, kode-review og lignende tankesett for å addressere dette.

Det 10. prinsippet er “Rema 1000-prinsippet”; “Det enkleste er ofte det beste”. Unngå å lage mer funksjonalitet enn brukerne virkelig trenger. Brukervennlighet. Unngå å lage fancy, generiske komponenter – sørg i stedet for at arkitekturen består av løst koblede moduler som alle lar seg videreutvikle separat.
Tilstand: Igjen, de som er så heldige at de kan få starte fra scratch vil ofte angripe systemutviklingen på denne måten. Men dette problemet synes å leve i beste velgående i større offentlige prosjekter der men over tid har akseptert en voldsom kompleksitet. Når resepten blir et “SOA-prosjekt” er det slett ikke gitt at ting blir mye bedre…

Det 11. prinsippet tar til orde for å jobbe i selvstyrte team – hvilket jo er et krav i Scrum.
Tilstand: Mye står igjen her over hele linja. Selvstyrte team fordrer en ganske voldsom endring i kultur, holdninger og lederstil – hvilket selvsagt ikke skjer over natta. Jeg har sett noen få virkelig selvstyrte team som tar kollektivt ansvar og som har stor myndighet og selvstendighet. Men ikke mange.

Til slutt det 12. og kanskje viktigste prinsippet som handler om kontinuerlig prosessforbedring.
Tilstand: De aller fleste som bruker Scrum har retrospectivemøter som siste gjøremål i en iterasjon. Slett ikke alle klarer å utnytte dette til fulle – her ligger det etter mitt skjønn store gevinster å høste. Igjen er det nok de som har kontraktsbaserte prosjekter som sliter mest med uttellingen. Ikke helt opplagt at det lønner seg å legge sjela si i å forbedre metoder, verktøybruk og arbeidsformer i et midlertidig team i et tidsbegrenset prosjekt..

Konklusjon

Agile Manifesto har hatt en stor påvirkning på IT-bransjen. Ingen ignorerer dette lenger, men det er veldig varierende hvor omgripende endringer man er beredt til å innføre. Vi får jo her bekreftet at organisasjonsendringer nødvendigvis må ta tid. De siste 3-4 årene har det virkelig skjedd mye i Norge og i store deler av verden, men jeg har en følelse av at vi bare så vidt har begynt. Spesielt der man kjører kontraktsbasert utvikling – kanskje særlig innen offentlig sektor – kan man tjene mye på å utfordre prosjekttankegangen og ikke minst å fokusere mye mer på å forenkling, å fjerne konpleksitet og å unngå å pådra seg teknisk gjeld.

Scrum støtter ikke dette!

Vel overstått enda en Smidig-konferanse og igjen på tide med litt ettertanke. Har vi kommet videre? Har vi mer verdifull erfaring enn i fjor? Har vi en dypere forståelse av smidig? Av Scrum? Ser vi tegn til at misoppfattelsene er færre? Jeg har sett igjennom en hel del av lyntalene fra Smidig2010 og vil konkludere med at svaret er “ja, litt”.

Men jeg har lyst til å gripe fatt i ett fenomen som er en slags fellesnevner i en del av lyntalene; “scrum fører til …” eller “scrum støtte ikke …”. Og en undergruppe av disse er de som har erfaring med Scrum-prosjekter der de forsøker å få “prosjektlederoppgaver” til å passe inn i Scrum. Dette er jo ikke lett – vi skal jo nå klare oss med de tre rollene Product Owner, Scrum Master og Teamet. Og helt ærlig – veldig mange (de fleste?) klarer seg utmerket godt uten prosjektbegrepet. Men for de som jobber på kontrakt med ekstern kunde forstår jeg at det fremdeles er prosjekt som gjelder. I denne settingen vil vi operere med prosjekter og prosjektledere en god stund til. Men jeg mener bestemt prosjektlederrollen er utdøende i svært mange situasjoner. Unntaket er der man er nødt til å starte store, omfattende endringer på IT-systemer. Om man ikke i fremtiden klarer å unngå de store prosjektene da.

Vi må altså ikke glemme at vi er på en lang reise som på et vis startet i 2001 med Agile Manifesto. Manifestet er en slags visjon for en omfattende endring som hittil har pågått i 10 år. Vi er kanskje fremdeles i startgropa. De av oss i IT-bransjen som sverger til dette manifestet må aldri glemme at det er lang vei igjen til kundene og organisasjonene rundt oss legger til rette for smidig. Smidige kontrakter, smidig budsjettering (beyond budgeting), smidig linjeledelse osv vil gradvis bli vanligere. Men inntil vi er der, må vi stå på og kjempe for forandring – samtidig som vi må forholde oss til den virkeligheten vi er midt oppe i. Ikke helt enkelt det der!

Smidig er basert på en ledelsesfilosofi som bygger på Lean og Systems Thinking – som er et motstykke til tradisjonell tankegang som bygger på Frederich Taylor´s Scientific Management. Det jeg synes prosjektlederne som snakker om Scrum gjør er å forsøke å etablere strukturer basert på Taylors ideer om ledelse for å kompensere for manglene i Scrum. “Smidig er bra, men hvordan tilpasser vi Scrum slik at den funker i en vanlig prosjektsetting”. Disse prosjektlederne snakker lite om hyppige leveranser eller det å forbedre arbeidsmetodene gjennom hyppige retrospectiver…

Jeg forstår at hverdagen til en del prosjektledere og -deltagere er vanskelig. Balansegangen mellom å pushe kunden mot smidig, samtidig som vi må forholde oss til status quo er ikke lett. Men om vi lener oss tilbake og slutter å trykke på vil vi ikke få særlig endring – det bestående er trygt og vil lett vinne over endring som er ukjent og “farlig”.

Dette er også et pedagogisk dilemma. Vi MÅ lære bort Scrum slik det er tenkt å være i smidige omgivelser. Samtidig må vi klare å formidle at vi ikke kan unnlate å forholde oss til den virkeligheten, den “smidig-modenheten” omgivelsen er i i dag. Jeg synes det er trist å høre Craig Larman bli sitert slik: “Da må bare omgivelsene endre seg da” med dårlig skjult håpløshet i stemmen. Jeg betviler ikke at Craig kan ha sagt noe sånt – men den samme mann vil også gjerne snakke om at endring selvsagt vil ta tid – om man vil høre på det øret.

For ordens skyld: Scrum er mangelfull – og det er også meningen. Scrum er bare et maksimalt enkelt rammeverk med masse huller som man må fylle med fornuftige ting selv. Hele poenget er “Inspect and Adapt”, gjennom hyppig læring tilpasser vi oss og etablerer bedre og bedre praksiser som svarer på våre forretningsmessige behov. Dette ansvaret må vi ta selv. Vi kan med andre ord ikke skylde på Scrum om vi ikke lykkes.

• En agile42 blogg

  

• Kurs

  • 12.03.2012: CSM i Oslo
  • 16.02.2012: CSPO i Stavanger
  • 18.01.2012: CSM Stavanger
  • 23.04.2011: CSPO (3 dager) i Oslo
  • mer …

• Siste kommentarer

  • Johannes Brodwall on Agile Coach Camp Norge vel overstått
  • marit elisebet totland on Et spørsmål om kompleksitet
  • gamsjo on Et spørsmål om kompleksitet
  • marit elisebet totland on Et spørsmål om kompleksitet
  • gamsjo on I løvens hule

• Arkiv

  Select Month January 2012  (2) October 2011  (1) August 2011  (1) July 2011  (1) June 2011  (1) April 2011  (1) February 2011  (1) December 2010  (1) November 2010  (1) August 2010  (2) July 2010  (1) May 2010  (1) March 2010  (1) February 2010  (2) December 2009  (1) November 2009  (3) October 2009  (2) September 2009  (1) August 2009  (3) July 2009  (1) May 2009  (1) April 2009  (5) March 2009  (5) February 2009  (6)

• Temaer

  Ansvarliggjøring Brukervennlighet Coaching DRM EVO eXtreme Programming fildeling forretningssiden forskning innovasjon ITIL Kanban kommunikasjon kompleksitet kundeverdi kunnskapsdeling Kvalitet Lean ledelse opphavsrett organisasjon produkteier prosjektstyring saksbehandling Scrum ScrumBut sertifisering Smidig Styring systems thinking ulovlig fildeling

• Linker

  • Coaching og kurs Komplette konsulenttjenester innen smidig
  • Konsulenttjenester spitia
  • Lean meetup Oslo Lean meetup
  • Scrum Training Institute
  • XP meetup Oslo XP meetup

• Blogroll

  • Johannes Brodwalls blogg
  • Management 2.0 by Gary Hamel
  • Management 3.0 Jurgen Appello’s attempt to define the last version of Manamement
  • Paul Chaffey’s blogg
  • Rune Ulvnes: Ledelse 2.0 Tanker om moderne ledelse – på norsk
  • Smidig forum Noregs beste diskusjonsforum
  • Sterk Blanding Blogg med utgangspunkt i Steria