Hva legger vi i Smidig?

Jeg blir stadig forbløffet over hvor ulike oppfatninger folk har om Smidig. Selv mener jeg jeg har et “modent og reflektert” syn på hva Smidig egentlig innebærer, men jeg innser også at dette er mitt eget private syn. For Smidig (Agile software development) er ikke veldefinert. Det er definert av 17 herrer som møttes i Snowbird, Utah og formulerte de 4 berømte verdisetningene. Deretter ble det definert 12 prinsipper – som også er ganske korte, overordnede setninger. Selvsagt er det mulig å legge både ulik vekt og ulik betydning i disse til sammen 16 utsagnene.

Min Smidig

Min smidigforståelse er altså “moden og reflektert”. Dette mener jeg å kunne si siden jeg har fulgte mange av disse 17 personene ganske tett helt siden 2001. På den tiden jobbet jeg med prosessforbedring innen softwareutvikling og så på Agile som “artig og lovende”, men uten å legge veldig mye i det. (Jeg kommer fra forsvars- og telecom-bransjen og jeg trodde ikke dette ville ha mye betydning innen slike kritiske og komplekse systemer. Etter hvert innså jeg at jeg hadde feil.) Jeg leste bøker og publikasjoner, dro på konferanser, fulgte blogger og ikke minst diskusjonsgrupper. Alt dette – sammen med det jeg har erfart som kursholder og coach – har fram til nå formet min forståelse av Smidig.

Mine helter

Alle de som var med og signerte agilemanifesto er mine helter, men det er selvsagt enkelte som har hatt ekstra mye innflytelse. Hvem jeg har fulgt tettest er kanskje litt tilfeldig, men det har også med hvor stor synlighet og hvor mye aktivitet de har hatt. Dette er i alfabetisk rekkefølge:

Kent Beck – som var først ute med eXtreme Programming bok og som stadig er aktuell

Alistair Cockburn – mannen bak bl.a. Crystal Clear og som jeg faktisk overværte disputasen til på UiO i 2003 og som er en svært aktiv debettant

Martin Fowler – med en av nettets beste agile blogger spesielt god på refactoring og teknisk gjeld.

Jim Highsmith – med veldig god blog og med en hel del bøker på samvittigheten

Ron Jefferies – også en XP forfatter. En svært aktiv debattant som dukker opp på svært mange ulike diskusjonsfora. Har også en god blog. Han har bidratt mye til å sveise sammen XP og Scrum og jobber for tiden hardt med å få på plass Agile Atlas.

Brian Marick – som har hatt spesiell fokus på test og “eksempeldrevet utvikling” 

Robert C. Martin – “Uncle Bob” er en svært populær foredragsholder som har spesiell fokus på XP-praksiser som parprogrammering, TDD, Clean Code – i det hele tatt Software Craftmannship.

Ken Schwaber – en dogmatisk og ganske kontroversiell fyr som har gjort en formidabel jobb med å gjøre Scrum forståelig, enkel og til det desidert mest brukte smidige rammeverket. Har brutt ut av Scrum Alliance og driver nå Scrum.org.

Jeff Sutherland – “pappan til Scrum” og en svært viktig person i forhold til utbredelsen av Smidig og Scrum. I likhet med Ken Schwaber ganske kontroversiell. Blogger her.

Utover disse må jeg nevne en rekke andre helter som alle har skrevet bøker, artikler og stadig holder Key-notes på konferanser og som har betydd mye for min “dannelsesreise” innen Smidig. Denne listen kunne vært betydelig lengre, men jeg har forsøkt å være nøye med å plukke ut de jeg har hatt mest å gjøre med i en eller annen form. Dette er:

Mike Cohn – Har en meget god og lettfattelig Scrum orientert blog og har gitt ut tre bøker om Scrum og User Stories.

Craig Larman – Er spesielt opptatt av de store organisasjonene og har skrevet spesielt en meget lesverdig bok kalt Scaling Lean and Agile Development.

Mary Poppendieck –  Har betydd svært mye for meg og mange andre i det at hun på en genial måte klarer å knytte Lean sammen med Agile. Har gitt ut tre bøker sammen med sin mann Tom og som alle er pensum.

Jeff Patton – Svært viktig på området produktdesign og brukeropplevelse med Story Mapping som flaggskip og jeg gleder meg til den første boka hans kommer ut!

Jim “Cope” Coplien – Aktiv innenfor Patterns bevegelsen og er opptatt av arkitektur, organisasjon og Scrum.

Henrik Kniberg – eneste skandinav på lista, men han er en svært viktig spreder av Smidige ideer, gjennom sin suverent pedagogiske fremstillingsevne. Scrum & XP from the trenches er allerede en klassiker.

Jeg er fristet til å liste opp nasjonale helter også – for det er klart at min smidig-forståelse også er preget av utallige meetups, konferanser, fora og blogger nasjonalt. Men her merker jeg det blir veldig vanskelig å trekke opp grensen for hvem som skal med og ikke. Så jeg tror jeg nøyer meg med å nevne Johannes Brodwall som er en svært dyktig meningsbærer og som har vært primus motor for mye av smidig-aktivitetene her til lands i en årrekke. Tom og Kai Gilb bør også nevnes – de er kontroversielle og får deg til å tenke over en del ting, blant annet målbare produktegenskaper framfor features. Tom er virkelig en smidig pioner med flere bøker på samvittigheten.

Jeg kan også liste opp en rekke eldre, viktige inspirasjonskilder og jeg kunne ramset opp 20-30 yngre navn som representerer  innovasjonen som skjer på agile-fronten for tiden, for det er ikke lite. Men det får bli en annen blog-post…

Ulike syn på Smidig

Har nå alle disse “heltene” det samme synes på Smidig? Selvsagt ikke! De fokuserer på ulike ting, vektlegger ulike ting og de er også uenige om en del ting. De krangler til tider åpenlyst og de krangler i lukkede fora. Ett velkjent eksempel er Jeff Sutherlands voldsomme fokus på Velocity og hans argumentasjon at man enkelt – med Scrum – kan mangedoble teamets hastighet og nå et Hyperperforming state. Dette avfeies som både feil fokus og umulig å måle av mange av de andre heltene. Selv ser jeg på dette som “interessant”, svært avansert og litt urealistisk, selv om jeg har stor respekt for Jeff Sutherland.

Men det slår meg også at alle disse sterke personlighetene er bemerkelsesverdig enige! Det skal litt til at såpass mange forfattere av bøker med stor definisjonsmakt bevarer enigheten over tid, men det mener jeg bestemt de faktisk har gjort. De synes enige om alle de store linjene og de synes enige om at Agile forutsetter et paradigmeskifte som på mange måter så vidt har startet. Hensikten med manifestet var IKKE å justere litt på måten vi jobbet på. Nei, hensikten var å etablere fullstendig annerledes tankesett, organisasjonssyn og fremgangsmåte. Jeg må innrømme at jeg blir litt opprørt når folk hevder at noe er Smidig, selv om gammelt tankegods, organisering og arbeidsform i det store og hele er bevart. Et aktuelt eksempel på dette er den såkalte smidige varianten av Statens Standarsavtale som etter min forståelse er langt unna Smidig.

Din og min Smidig

Så dette er mitt smidige univers. Vi må leve med ulike syn, ulike “dialekter” av Smidig. Og vi må selvsagt leve med at ulike organisasjoner vil ha forskjellig tilnærming, og at de vil kunne oppnå ulik grad av smidighet. Og enten vi vil eller ikke, effekten av Smidig vil aldri bli objektivt målbar så det vil også koke ned til en tro. En overbevisning.

Så, dette er min smidig. Hvordan ser din ut?

 

Den menneskelige siden av smidig

Smidig har en sterk menneskelig side, det ser vi allerede i første setningen i agile manifesto:

People and Interactions over Processes and Tools

 

Hva er så et smidig menneske?

Det er velkjent at et Scrum team er tverrfaglig og selvorganiserende. Vi ser altså etter en team-orientert person. En “team-player” med visse egenskaper. Hva innebærer dette for de som bemanner disse teamene. Hvordan er egentlig en “smidig person”? Finnes det faktisk et “smidig menneskesyn”?

Jeg har akkurat lest – og ble veldig inspirert av – “Teamwork is an individuall skill” av Christopher M. Avery som omhandler hva det egentlig vil si å jobbe under delt ansvar og eierskap. Han kaller dette TeamWisdom og diskuterer spesiellt inngående hva det vil si å ta ansvar.

 

Jeg har forsøkt å danne meg et bilde av hvilke særtrekk en ideell smidig person vil inneha.

En smidig person:

• er opptatt av helheten (sluttresultatet) – selv om dette lett forsvinner ut av syne i det daglige arbeidet
• er opptatt av de som skal bruke sluttresultatet – selv om disse kanskje ikke er så lett tilgjengelige
• tar ansvar – selv om ansvaret for å ta tak egentlig (formelt sett) ligger hos noe andre,
• tør stole på andre – selv om man er kompetent og gjerne ville ha detaljert oversikt selv
• er generøs og deler seireren raust med de andre i teamet – selv om bidraget i stor grad kom fra deg
• deler informasjon – selv om det i enkelte sammenhenger kan ha verdi å være den eneste som vet
• synes det er gøy med tverrfaglige ide-dugnader for å finne gode løsninger – selv om du selv kunne løst problemet mye raskere på egen hånd
• tør å feile åpenlyst – selv om det ikke føles godt eller kan føre til ubehageligheter
• aksepterer at andre feiler åpenlyst – så lenge man evner å lære av dette
• tør å bryte regler og konvensjoner – selv om det betyr “å legge hodet på blokka”
• kjemper for det man tror på – selv om det bryter med (andres) etablerte sannheter
• ser verdien av å jobbe tett sammen med folk som er og tenker annerledes – selv om man kanskje synes kommunikasjonen går trått
• gjør håndtverket sitt skikkelig – selv om presset fra omgivelsene til å jobbe raskere er stort

Ut fra disse punktene kan vi se at smidig faktisk baserer seg på et spesielt menneskesyn. Respekt, tillit, ansvar og helhetssyn er nøkkelord. Det ligger i kortene at vi må gi enkeltmennesket stor grad av frihet, samtidig som det vil måtte gjelde spilleregler og begrensninger innad i teamene. Så med andre ord: organisasjonen må vise folk respekt, gi teamene tillit og ansvar for sluttresultatet. Hvor lenge vil de virkelig smidig orienterte menneskene holde ut i organisasjoner som ikke deler dette menneskesynet?

NB: Christopher Avery kommer til Oslo 23 April

 

 

altinn – som forventet

Det fine med kriser er at det gir en anledning til å lære. Enkelte områder ansees så kritiske at det øyeblikkelig nedsettes en havarikommisjon eller lignende når en ulykke inntreffer. Hensikten er selvfølgelig å dra lærdom av hendelsen. Det positive med de siste dagers altinn-problemer er at DNV sin Tekniske Rapport Vurdering av Altinn II Plattformen ble frigitt. Rapporten har faktisk en litt misvisende tittel, for her vurderes i stor grad utviklingsprosjektet og ikke den ferdige løsningen. Veldig interessant lesning!

Prosjektets utilstrekkelighet

Altinn II utviklingen ble kjørt som et tradisjonelt prosjekt mot en sluttermin, med Accenture som leverandør. Dette prosjektet må kunnes sees på som ganske vellykket, for Altinn er blitt et system som gjør hverdagen til både bedrifter og enkeltpersoner betydelig enklere. Men så var det dette med kvaliteten da. Hvor gode betingelser har vi for å levere god kvalitet når arbeidet organiseres som prosjekter? SMÅ! I hvert fall om det som skal utvikles er komplekse systemer. Vi har snakket og skrevet om dette gjentatte ganger.

Problemet er altså at det synes uungåelig at vi styrer mot tid og kost, i stedet for å fokusere på høy kvalitet. For hva er egentlig høy kvalitet i programvare? Ikke helt lett for en stakkars kunde å vite hvordan man måler dette. Og det som ikke er målbart, blir konsekvent ofret – når vi er under press. Leverandøren har som regel kunnskap om hva som er kvalitetsmessig godt håndtverk, men velger under press å ofre dette. For godt håndtverk tar tid.

Testing og feilretting

“Alle” i programvarebransjen vet nå ta du må teste grundig, automatisk og så tidlig som mulig. Feil skal ikke finnes i produksjon – da er de ekstremt dyre å finne og rette. Vi automatiserer gjerne tester på flere nivåer. Problemet med dette er at det tar tid. Fra rapporten:

5.2 Feil og feilretting

Som beskrevet i avsnitt 5.3 Test, er det vår oppfatning at kvaliteten på testingen har vært for dårlig i alle faser – fra modul-/ enhetstest til akseptansetest. En konsekvens har bl.a. vært at det er produksjonssatt en løsning med mange kjente og ukjente feil. For dårlig testing i alle faser har resultert i at mange feil har blitt oppdaget sent. Feil som burde vært funnet

i modul-/ enhetstest avdekkes ikke før i integrasjonstest, feil som burde vært funnet i integrasjonstest avdekkes ikke før i systemtest, osv. Erfaringene fra akseptansetest er at det ble funnet feil som klart burde vært avdekket tidligere. Videre har vi også fått opplyst at fatale feil ikke ble avdekket før produksjonssetting.

Grafen er sakset fra rapporten og viser DNV sitt syn på kostnadskonsekvensene ved å oppdage feil sent i prosessen.

Dette viser en utvikling som ikke akkurat er under kontroll. Når man finner så mye feil så sent i prosessen forteller det oss at dette systemet ikke er stabilt.

Teknisk Gjeld

Rapporten peker gjentatte ganger på at man her har bygget opp en teknisk gjeld. Teknisk gjeld er en god metafor for det som skjer når man forsøker å vinne tid eller penger ved å unnlate å gjøre håndtverket skikkelig. Testing er en opplagt kandidat til å gjøre mindre av. Dokumentasjon og refaktorisering av kode og struktur er andre områder. DNV har skutt inn et utdrag fra en annen rapport:

CapGemini gjorde på oppdrag av BRREG to kodegjennomganger en i 2009 /112/ og en i 2010 /113/.
Fra CapGemini code review report /112 / har vi sakset følgende oppsummering:
“De svakeste områdene i Altinn II er følgende:
Enhetstestene inneholder mange feil og er ikke komplette
Deler av koden virker uferdig med mange TODO‟s og utkommentert kode
En del metoder er svært lange og komplekse
Noen steder har vi funnet try-catch-blokker som ”svelger” feil uten å gjøre noe med disse
Presentasjonsprosjektet framstår som rotete. Det er ingen skiller mellom presentasjon,
datahåndtering og forretningslogikk. “

Endringskostnader

Alt dette peker mot det vi ofte kaller “slutterminens forbannelse”. Når man kjører komplekse prosjekter på denne måten virker det som en naturlov at denne gjelden blir stor. Stor teknisk gjeld fører til ustabile systemer med mye feil. Men det har også en annen effekt, nemlig at endringskostnadene over tid skyter i været.

IT-systemer har ofte (overraskende) lang levetid, og de er under stadig utvikling. Det er sjelden slik at en stor leveranse er slutten på nyutvikling. Når vi så kjører mot slutterminen med en leverandør som er på fastpriskontrakt får vi også unødvendig dyrt vedlikehold over tid. De store IT-kundene bør tenke nøye igjennom hvordan de bruker pengene på IT-utvikling. Kanskje det er på tide å utfordre prosjekttankegangen?

Bruk rammeavtale i stedet!

Altinn er ikke enestående, dette er normalen innen IT-prosjekter i norge. Vi kan anta at det er bygget opp en formidabel teknisk gjeld i IT-systemene her i landet. Men det er fullt mulig for en IT-kunde å ta styringen selv. I stedet for å legge ut fastprisavtaler med en leverandør som ikke har egen interesse av å levere høy kvalitet kan man bruke en “Time and material” type avtale der leverandørene stiller opp med kompetanse og ressurser, mens kunden selv styrer. Vi tror dette vil kunne spare samfunnet for mye tid, penger og ergrelser. I en rammeavtale kan fokuset ligge på det som er viktig over tid. Man kan spare mye ressurser i startfasen, siden man slipper den store, tunge anbudskonkurransen. Samtidig kan styringen gjøres betydelig enklere gjennom smidige metoder. Og man får validert løsningene underveis og kan med enkle grep unngå at testing og annen god praksis ofres til fordel for framdrift.

Begynn å ta virkeligheten på alvor! 

 

Scrum som innovasjonsmotor

Mange tror at Scrum dreier seg om daglige, stående møter, klistre post-it lapper på veggen, produktkøer og sprinter. Man gjør de foreskrevne aktivitetene, og lar det bli med det. Noen velger å se det som en ren prosjektstyringsmodell. Det er forbausende hvor mange som har et slikt overforenklet syn på hva Scrum egentlig dreier seg om. Dette er et forsøk på å forklare kjernen i Scrum.

Bakgrunn – The New New Product Development Game

Når Dr. Jeff Sutherland i 1993 var på utkikk etter “best practice” innen programvareutvikling dumpet han borti artikkelen The New New product development game i Harvard Business Review fra 1986. Dette dreier seg ikke i særlig grad om programvare, men snarere om produktutvikling og innovasjon generelt. Artikkelen er mest kjent for å ta til orde for at “stafettløpet” der ulike spesialister jobber hver for seg og sender informasjon til hverandre må forkastes til fordel for tette team, omtrent som man gjør i en Scrum i Rugby. Her diskuterer to de Japanske forskerne Hirotaka Takeuchi og Ikujiro Nonaka (disse kalles nå “The Godfathers of Scrum”) hvordan datidens beste innovatører opererte.
Artikkelen baserer seg på studier i firmaer som Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, Hewlett-Packard og IBM. I artikkelen belyser de hvordan helt konkrete, banebrytende produkter kom til live gjennom at en tverrfaglig gruppe mennesker ble plassert sammen, fikk en veldig utfordrende målsetning, store fullmakter og budsjetter og ellers hva de måtte behøve tilrettelagt. Vi vet jo for eksempel at IBM PC ble unnfanget i en lagerbygning i Boca Raton, langt unna andre av IBMs fasiliteter av en tverrfaglig ingeniørgruppe med store fullmakter og liten ekstern styring.

Fellestrekkene de fant kategoriseres slik:
1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

1. Built-in instability

Det handler om å kaste seg ut på dypt vann. Toppledelsen tar strategiske beslutninger om en ny satsning og setter sammen et kompetent team som får store fullmakter og en tidsfrist. Men de stiller få eller ingen krav til løsning, kun krav til egenskaper som skal gi dem et betydelig konkurransefortrinn. Ingen vet på forhånd hva dette vil ende opp i.

2. Self-organizing project teams

Prosjektteamet blir hensatt i en tilstand som tilsvarer et oppstartsselskap; man ønsker å gjenskape gründerånden selv om man er en del av et veletablert, stort selskap. Da må gruppen få en stor grad av autonomitet, hvilket innebærer at de ser lite til moderselskapet mens det står på. Det er ingen tvil om at de har tillit – de blir ikke spurt om timerapportering, kun oppnåelse av delmål som gruppen selv setter seg. De legger en mer eller mindre detaljert plan som stadig revideres. Medlemmene av gruppen har stor bredde av spesialisering og vil typisk bestå av ulike ingeniører, salgsfolk, fagspesialister osv. Det studien er veldig klar på er at disse menneskene med svært ulik bakgrunn begynner å lære av hverandre.

3. Overlapping development phases

Når fasene går etter hverandre (stafettløpet) blir det vanskeligere å samarbeide og å utveksle tverrfaglig kunnskap. Og det blir bortimot umulig å integrere og validere delresultater underveis. Når de støter på hindringer og flaskehalser blir det tydelig at hele teamet må jobbe sammen for å løse opp i disse. Derfor er det maktpåliggende at man evner å blande de fasene som lar seg blande i et produktutviklingsløp.

4. “Multilearning”

Et slikt tverrfaglig team må også ha direkte kontakt med omverdenen eller “markedet” om man vil. Det er maktpåliggende å teste ut konsepter på markedet og det er like viktig å fange opp endringer. Teamet som helhet kan nå respondere raskt på ny lærdom og endrede markedsbetingelser. Alle i teamet blir nå bevisste på markedsmessige forhold og dette vil også prege den læringen som foregår. Det vil alltid være ulike nivåer av læring. Det fundamentale nivået dreier seg om å foredle den ekspertisen du allerede har. Andre nivåer kan omhandle samarbeidsformer, markedsforståelse, andre tilstøtende ingeniørfagfelt osv.

5. Subtle control

Ledelsen behøver selvsagt å kunne følge med på progresjonen, men dette må gjøres uten byråkrati og uten å hindre spontanitet og kreativitet. Enkelt sagt får ledelsen kontroll ved å skape gjennomsiktighet. I artikkelen tar forfatterne til orde for 7 prinsipper:
1. Sørge for at gruppedynamikken er ivaretatt og at teamet fungerer godt,
2. skape åpenhet og nærhet,
3. sørge for at ingeniørene får møte kunden og brukerne,
4. evaluere gruppen framfor individer,
5. ha fokus på rytmen teamet jobber i, i de ulike fasene,
6. tolerere og forvente feil – “ingen feil, ingen innovasjon”,
7. oppfordre leverandørene til å selvorganisere og å jobbe tett med teamet.

6. Organizational transfer of learning

Forfatterne nevner her flere eksempler på hvordan store selskaper forsøker å institusjonalisere sine suksesshistorier ved å lage prosedyrer og standardisere metoder. Dette punktet må vel kunne sies å være det svakeste – historien viser at det er uhyre vanskelig å finne gode modeller for slik kunnskapsoverføring på tvers.

Hvordan lykkes med innovasjon?

De beste er fullstendig klar over at innovasjon er en kompleks og ikke-forutsigbar aktivitet, så detaljert planlegging og styring er fåfengt. Det er nødvendig å ha et bevisst forhold til kompleksitet. Enkle oppgaver kan planlegges og styres, komplekse oppgaver krever tverrfaglig teamarbeid og stor frihetsgrad. Sutherland og Schwaber har brukt HBR artikkelen A Leader’s Framework for Decision Making av David J. Snowden and Mary E. Boone som pedagogisk grunnlag for Scrum og bruk av selv-organiserte team i IT-prosjekter. Konseptet selvstyrte team ingen fiks ide man kan velge bort. Dette er core Scrum.

En annen helt sentral faktor er å sette kunden i førersetet. De beste innovatørene gir seg ikke før de er trygge på at de forstår behovet til brukerne – enten disse er eksisterende eller framtidige kunder. Og så må vi la ingeniørene møte brukerne. Ofte. Gjør som Steven Denning beskriver i boka The Leader´s guide to Radical Management: The only goal should be to delight the customer.

Scrum er et enkelt og fleksibelt rammeverk, og følg gjerne “mekanikken” i Scrum til punkt og prikke. Men det er ikke det som til syvende og sist vil avgjøre om du lykkes. Det Jeff Sutherland gjorde – senere med hjelp av Ken Schwaber – var å utarbeide et rammeverk for å skape innovasjon på en effektiv og repeterbar måte. Ideene fra The New New Product Development Game lever videre i Scrum og artikkelen bør leses av alle som virkelig ønsker å lykkes med Scrum.

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…

• En Smidigblogg av

  Lean Venture

• Ressurser

  • Agile (is) Risk Management (video)
  • Debugging the organisation with Scrum (video)
  • Presentasjoner (slideshare)
  • Prosjektveiviseren med Scrum (video)
  • Raskere, billigere, tryggere,bedre (video)
  • The Power of Why (video)
  • Tidstyveri (video)

• Temaer

  Ansvarliggjøring Brukervennlighet Business Model Generation Coaching Customer Development DevOps DRM endringsledelse EVO eXtreme Programming fildeling forretningssiden forskning gruppedynamikk innovasjon ITIL Kanban kommunikasjon kompleksitet kontrakt kundeverdi kunnskapsdeling Kvalitet Lean Lean Startup ledelse ME målstyring opphavsrett organisasjon Prioritering produkteier prosessforbedring prosjektstyring saksbehandling Scrum ScrumBut sertifisering Skalering Smidig Styring systems thinking ulovlig fildeling

• Siste kommentarer

  • Heidi Ihle Edvardsen on Kurs
  • gamsjo on Ny versjon av Scrum Guiden – hva er nytt?
  • Ronny Justsen on Ny versjon av Scrum Guiden – hva er nytt?
  • gamsjo on Å planlegge for det ukjente
  • Jon Steinar Kjøllesdal on Å planlegge for det ukjente
  • Det smidige hjørne » Å planlegge for det ukjente on Det perfekte team
  • Det smidige hjørne » Å planlegge for det ukjente on Empirisk prosesskontroll

• Arkiv

  Arkiv Select Month August 2023  (1) August 2022  (1) July 2022  (1) August 2021  (1) May 2020  (1) August 2019  (1) December 2017  (1) April 2017  (1) February 2017  (1) December 2016  (1) November 2016  (1) September 2016  (1) July 2016  (1) June 2016  (1) May 2016  (1) March 2016  (1) February 2016  (2) December 2015  (1) November 2015  (1) October 2015  (2) September 2015  (2) August 2015  (2) February 2015  (2) January 2015  (1) November 2014  (4) October 2014  (2) August 2014  (2) July 2014  (2) June 2014  (1) April 2014  (1) March 2014  (2) February 2014  (1) January 2014  (3) November 2013  (2) September 2013  (1) August 2013  (1) July 2013  (1) June 2013  (1) May 2013  (1) April 2013  (1) March 2013  (3) February 2013  (1) January 2013  (1) November 2012  (1) October 2012  (1) September 2012  (2) August 2012  (1) July 2012  (2) June 2012  (1) May 2012  (1) April 2012  (3) March 2012  (1) February 2012  (1) 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)