Produkteierrollen

Jeg husker for et par år siden at jeg spurte ulike personer i en organisasjon om hvilke funksjoner i et planlagt produkt som var viktigst. Jeg fikk mange ulike svar! Og jeg fikk mange ulike beskrivelser av funksjonene og produktet! De jeg snakket med var typisk markedssjefer, produktsjef, linjeleder, driftssjef, arkitekturansvarlig samt noen utviklere. (De hadde nylig startet med Scrum og hadde faktisk kvittet seg med prosjektlederrollen, og det kan nevnes at jeg ikke fikk snakket med “ekte brukere”). Vi ser ofte at forskjellige personer har ulikt syn på et produkt, alt avhengig av hvilken rolle personen har. Hvordan produktet forklares vil avhenge av hvilket perspektiv man ser produktet fra. Dette perspektivet avgjør også hvilke egenskaper man vil ønske å vektlegge. Fenomenet fører selvsagt til en ganske uholdbar situasjon med uklare prioriteringer og forståelse av behov. Løsningen er heldigvis enkel:én og bare én person med det hele og fulle ansvaret – en produkteier (Scrum Product Owner). 

Rollen er punktvis beskrevet slik av Scrum Alliance:

 

 

The Product Owner has the following responsibilities.

• Define the features of the product;
• Decide on release date and content;
• Be responsible for the profitability of the product (ROI);
• Prioritize features according to market value;
• Adjust features and priority every 30 days, as needed; and
• Accept or reject work results.

 

 

Rollen må tilpasses

Det er mange hensyn å ta når man skal implementere en produkteierrolle. Hvilke kvalifikasjoner bør personen ha? Hvilke støttespillere trenger produkteier? Hvor mye interaksjon trenger PO med kunder, brukere, interessenter. Hvilket samarbeidsformer skal vi ha med med Scrum teamene og med Scrum Masterne? Hvilke metoder og verktøy skal man ta i bruk?

Rollen skalerer

Selv om produkteier skal være én person med det hele og fulle ansvaret, vil det ofte være uoverkommerlig å fylle rollen fullt ut for en person. Store, komplekse systemer vil ofte bestå av sub-systemer eller ulike markedssegmenter. Da kan det være nødvendig med et hierarki av produkteiere der et antall produkteiere for hvert sitt delsystem har mandat knyttet til en del, men samtidig må underordne seg hovedprodukteier (Chief Product Owner) som tar de overordnede beslutningene og prioriteringene.

Produkteierteam

Svært ofte er det nødvendig å alliere seg med spesialkompetanse slik at alle viktige hensyn ivaretas. Mange vil da danne et produkteierteam som ledes av produkteier. Dette kan ofte være roller av mer teknisk karakter, ettersom produkteier ofte rekrutteres fra forretningssiden. Ikke-funksjonelle krav må analyseres av eksperter på arkitektur, database, brukerinteraksjon osv. Ulike interessenter kan med fordel være representert i et slikt team slik at man får belyst og vurdert mange ulike hensyn opp mot hverandre. Dessuten kan det være på sin plass med roller fra porteføljestyring, salg og forretningsutvikling. Slike team fungerer best om de er samlokalisert (akkurat som alle andre team). Kort avstand fremmer kommunikasjonen som er vesentlig når mange ulike parter skal ha en felles forståelse av hva man jobber med.

Hvilke egenskaper bør en produkteier ha?

Generelt kan vi si at en god produkteier må være en visjonær entrepenør med god gjennomføringsevne og samtidig en lydhør, ydmyk leder som motiverer og engasjerer sine omgivelser. Slike mennesker vokser vel ikke på trær akkurat, men vi kan heldigvis spisse kravene til personlighetstrekk litt avhengig av omgivelsene. Vi kan dele karakterisere omgivelsen ut fra tre egenskaper:
* Type produkt (innovasjonsgrad, kompleksitet)
* Type kundeforhold (hyllevare, eller kundeoppdrag)
* Størrelse (mengde interessenter, antall Scrum Team)

 

 

 

Chrome vs Windows: Heia Google!

Jeg er dyktig lei Windows. Vista tok knekken på siste rest av aksept for dette operativsystemet. Allikevel fortsetter jeg å kjøpe Windows! Dette kun fordi jeg er for lat til å kjempe mot strømmen – jeg føler at jeg trenger å være kompatibel med resten av verden. Jeg sitter nå med en splitter ny Dell Latitude nedgradert til Windows XP. Jeg har betalt Dell for å nedgradere! Hvor fornuftig er det?

Problemet med Windows er tredelt:

1. Hver nye versjon blir større og tyngre hvilket selvsagt gjør at maskinene må oppgraderes eller byttes ut – bare på grunn av dette. Sånn sett er Windows maskinleverandørenes beste venn, og miljøet/forbrukernes verste fiende.

2. Brukergrensesnittet blir stadig rikere og dermed mer komplisert å bruke. Vista er et skrekkeksempel i så måte, operasjoner jeg har vent meg til i XP er endret og blitt “rikere” og dermed enda vanskeligere å bruke. Det er ikke all forandering som gir forbedring! Ett eksempel er filbehandleren som i XP fikk en fin, enkel knapp kalt Up for å navigere ett nivå opp i filstrukturen. Flott, enkel funksjon som i Vista er erstattet med en langt mer komplisert navigeringsmetode!

3. Windows er ustablit og usikkert. Vel, dette har blitt bedre med årene, men vi opplever stadig at Microsoft slipper nye versjoner med tusenvis av kjente og ukjente feil. Og at den voldsomme kompleksiteten gjør sikkerhet til et mareritt. Nå skal det også sies at feilhåndteringen har blitt bedre, slik at det er forholdsvis sjelden at en programfeil får operatisystemet til å krasje. Derfor er dette momentet på tredjeplass i denne lille lista.

Når vi legger til arrogansen til Microsoft (som jo har vært dyktige til å holde en markedsandel på over 95% i en årrekke) fører til å de ikke følger internasjonale standarder, samt at de krever at vi betaler for nye Windows-versjoner som vi ikke har bedt om – så er det etter min mening på høy tid med en troverdig utfordrer! Joda, jeg har hørt om Apple og det kunne kanskje vært en utfordrer om de ikke hadde opptrådt like arrogant i forhold til internasjonale standarder..

Google har alle muligheter til å lykkes med Chrome OS. For det første er de (nå blitt) store og pålitelige nok til å ha den nødvendige troverdigheten. (Se forøvrig Gisle Hannemyrs kommentar her). For det andre mangler de historie og har dermed den luksusen det er å kunne starte med blanke ark uten å tenke så mye på bakoverkompabilitet. De kan (og vil) fokusere på ytelse og enkelhet framfor kompletthet og rikhet – slik de hele tiden har gjort. Les mer om dette på Google Bloggen

Google er et moderne selskap tuftet på ideene om å sette brukerne i fokus, styre etter langsiktige mål fremfor kortsiktig profitt og å arbeide i korte sykluser med stadige leveranser og mulighet for feedback fra markedet. Disse prinsippene kaller vi jo gjerne Lean og Agile og representerer et helt annet tankesett enn det de store, tunge, veletablerte aktørene står for. Dette har jeg virkelig tro på!

Har jeg overhodet ingen motforestillinger? Joda, vi skal være klar over at Google skaffer seg en voldsom makt gjennom at de lagrer dataene våre og til og med scanner/indekserer informasjonen slik at de kan skreddersy reklamen. Denne makten vil få et nytt tilskudd om de lykkes med Chrome OS. Denne vil selvsagt være basert på at dataene våre i enda større grad ligger på nettet. Dette er jo behagelig og brukervennlig – så lenge nettet er oppe og så lenge Google er til å stole på. Google har som kjent mantraet “Do no Evil“. Det er i dag. Hvem vet hva som kommer i morgen? Hvem eier Google om 10 år? Vel, fram til dette er jeg villig til å ta sjansen!

Det er selvsagt skrevet mye om denne strategien til Google. Dette må sees i sammengeng med Google Wave, Android og “Cloud Computing”. Her er en god, liten artikkel om temaet: http://turl.no/49n

Tro og tvil om systemutvikling

Jeg leser alltid Magne Jørgensens kronikker på baksiden av Computerworld med stor interesse. Kanskje ikke den helt store nytteverdien alltid, men det er fornøyelig lesning! Magne harsellerer nemlig med våre menneskelige svakheter og det er jo gøy. Velskrevet og med vitenskapelig tyngde er det jo også. Han har vist oss at vi lett mister vår kritiske sans når det er noe vi gjerne vil tro på, at vi ofte lyver og at vi ofte er overdrevne optimister når vi har en viss avstand til det vi estimerer.  Han er mest kjent som forsker på estimering og han har påvist at ankereffekten ofte spiller oss et puss når vi skal estimere.

I siste Computerworld skriver han om et eksperiment med 50 Polske programmerere der han vil påvise at vi er forutinntatte når vi skal uttale oss om vi tror en viss metode gir positiv eller negativ effekt. Det er smidige metoder som denne gangen er gjenstand for undersøkelser. Og konklusjonen er at de som på forhånd hadde sagt at de god tro på smidige metoder også tolket det datasettet de ble presentert som om det viste at smidige metoder hadde en positiv effekt på for eksempel brukerfornøydhet. Selv om datasettet var tilfeldig generert. Javel? Hva så? Denne gangen må jeg si at jeg ikke fikk den store a-ha-opplevelsen av Jørgensens forskning. I stedet må jeg innrømme at jeg min første tanke var “bruker de dyrebare forskningsmidler på dette?”

De som kjenner til Scrum og andre rammeverk av typen Agile (som vi ofte kaller smidige metoder her i landet) vet at dette handler om langt mer enn en metode. Dette er omfatter også et verdisyn, og en ledelsesfilosofi. Åpenhet og ærlighet må til for at vi skal lykkes fullt ut. Kontinuerlig forbedringsarbeide, selvstyrte og tverrfaglige team krever store holdningsendringer mange steder. Langsiktighet fremfor kortsiktighet likeså. Verdiene stammer fra Toyota (“The Toyota Way”) og Lean. For å ta spranget fra tradisjonell organisering og prosjektstyring over til dette, må man være sterk i troen! Jeg synes dette er helt uproblematisk. Det er en logikk i alt dette som man må forstå fullt ut for å få tilstrekkelig tro til å sette i gang en slik snuoperasjon. Mange får nok også godt påfyll i troen direkte fra en opplevelse av at Toyota er verdens desidert mest vellykkede bilprodusent, eller at megasuksessen Google styrer med Lean og Agile prinsipper og verdsetter åpenhet, ærlighet og langsiktighet.

Kan vi måle effekten?

Vi kan ikke måle produktivitetsforbedring i antall kodelinjer eller funksjonspoeng per utvikler når vi vet at en av de underliggende prinsippene til det smidige manifest sier: “Simplcity – the art of maximizing the amount of work not done – is essential”. Det er ikke om å gjøre å dynge ned brukeren med funksjonalitet – poenget er å treffe så godt at brukeren får det minimumet han har behov for. Jeg tror sterkt på at en velfungerende Scrum-organisasjon vil kunne forbedre seg på flere helt ulike områder – men det er sannelig ikke lett å måle! Dette tror jeg vi trenger forskere til! Simula-senteret ville jo vært en opplagt kandidat for å gjøre en kartlegging av effekten av omlegging til Scrum eller Lean Software Development. Hvordan virker det inn på medarbeidstilfredshet, graden av effektivitet, brukertilfredshet, kundetilfredshet, måloppnåelse, inntjening etc? Godt anvendte forskningsmidler spør du meg!

Vi er verdens smidigste nasjon;)

ScrumAlliance.org har samlet data på utbredelsen av Scrum sertifiserte i verden. Dette bekrefter det vi visste – at Skandinavia ligger helt i verdenstoppen på dette området. Selvsagt også interessant at verden har fått over 50.000 CSM’s! Spesielt om vi tar med i betraktning at dette har skjedd de siste 5-6 årene.

Som vi ser av tabellen er nesten halvparten fra USA. Så er det et stort sprang ned til UK tett fulgt av de skandinaviske landene pluss Tyskland og Canada.

At IT-landet India har mindre enn 2000 CSM’s er litt oppsiktsvekkende svakt, men det er visstnok i rask vekst. Frankrike ligger sørgelig langt nede her..

Alle som er Certified Trainers (CST) har også vært med på en liten undersøkelse for å kartlegge “farten” på Scrum utbredelsen. Det er nok utløst av finanskrisen og rykter om at ting er i ferd med å stoppe opp. Resultatene er ikke særlig dramatiske. Mange trainere rapporterer om noe flere kansellerte kurs, litt færre deltagere på kursene og man har begynt å planlegge med litt færre kurs i nær framtid. Dette er helt som forventet.

Jeg kunne ikke motstå fristelsen: Jeg måtte utvide regnearket jeg fikk fra ScrumAlliance med en veiing for folketall. Vi kan ane resultatet av tabellen over – og ja ganske riktig: Norge har størst antall sertifiserte i forhold til folketallet! Hmmm .. Det ble jo påstått her for leden at jeg var Norges smidigste mann. Det betyr vel da at jeg er verdens smidigste! Hehe, statistikk er flotte saker gitt!

Det er jo interessant å spekulere i årsakene til at dette slår an så bra i Norge. Jeg diskuterer dette fra tid til annen når jeg holder kurs og den vanligste hypotesen går på at vi her i landet har lett for å akseptere konseptet selvstyrte team. Vi er ikke spesielt autoritetstro, vi er uformelle og vi har lett for å tenke det beste om folk. Det er vel fakta at vi jevnt over har flatere organisasjonsstrukturer enn i de fleste andre land. Men det er nok andre medvirkende årsaker også. Under har jeg laget en liten liste over hypoteser som kanskje kan forklare dette fenomenet:

1. Uformellle, flate organisasjoner gjør det hele lettere
2. Vi har et veldig synlig, aktivt “Smidig-miljø” i Norge
3. Vi (spesielt Programutvikling) har klart å hente de tunge kanonene til Norge for å holde kurs og foredrag
4. Vi har god råd
5. Vi er spesielt endringsvillige – har lav terskel for å prøve ut nye ting
6. andre forslag?

Enig? Uenig? Flere hypoteser? Kjør debatt!

Fra Scrum til Kanban: trenger vi iterasjonene?

De fleste Scrum teamene har veldig god nytte av iterasjonene. Ingen tvil om at dette har en rekke gode effekter. Det gir et formidabelt fokus. Det gir teamet muligheten for å gi ganske presise estimater for et begrenset omfang. Vi klarer å innarbeide gode, effektive rutiner for rask planlegging og avslutning av iterasjonene. Dette er gode synkroniseringspunkter, noe de som kjører flere paralelle team på samme produkt får mye nytte av. Men først og fremst institusjonaliserer dette læring. Vi oppsummerer iterasjonen vi akkurat har vært igjennom, ser tilbake, og så gjør vi små grep for å bli bedre.

I tillegg til dette gir skal vi jo lage et inkrement av produktet som er av en slik kvalitet at det kan leveres. Er vi heldige er resultatet av iterasjonen en MMF (Minimal Marketable Feature (set)) slik at vi faktisk kan levere noe til ekte brukere og derigjennom få verdifull feedback på det arbeidet vi har gjort og den retningen vi har staket ut for produktet.

Fra tid til annen møter jeg team som ikke helt får dette med iterasjoner til å passe inn i deres hverdag. Hva er det som kjennetegner disse? Jeg tror det er to kategorier:

Kategori 1: De som ikke klarer å planlegge én uke fram i tid – de er hendelsesstyrte. Dette er som oftest de som drifter systemer i utstrakt bruk og som egentlig jobber med support. Sakene de jobber med dreier seg i stor grad om hastesaker som bare må løses i en fart. Bugs og tilpasninger med høy prioritet. Vi er i brannslokkingsmodus.

Kategori 2: De som er underlagt tidskonstanter som ikke harmonerer med én måneds horisont. Dette er nok hardware/elektronikk/mekanikk-utvikling med noe prgramvare oppå. Vi må bare erkjenne at muligheten til å stykke opp i delleveranser ikke alltid er fysisk mulig når vi utvikler hardwaren sammen med softwaren. Denne kategorien lar vi ligge i denne omgang.

Hvor mye brenner det egentlig?

Vi ønsker jo at Scrum teamet skal kunne detaljplanlegge Sprintene og ha stor grad av forutsigbarhet slik at de fleste Sprintene går på plan og leverer god funksjonalitet. Dette kan vi ikke forvente av et team som ikke har særlig kontroll på tiden sin! Hvordan kan teamet  committe seg til en Sprint backlog om de stadig erfarer at ikke planlagt arbeid og avbrytelser slår bena under estimater og forpliktelser?

Det første man kan spørre seg er “hvordan kan vi begrense andelen brannslokking?” Her kan det være mye å hente ut. Bare en bevisstgjøring kan mange steder hjelpe litt. “Er du helt sikker på at dette ikke kan løses på vanlig måte i løpet av neste iterasjon?” Her hjelper det selvsagt med så korte iterasjoner som mulig.

Vi kan kanskje redusere andelen brannslokkingen gjennom bedre filtrering i tidlig linje support. Et Scrum team bør ikke belemres med trivielle saker som kunne vært tatt hånd om på telefonsupport.

Og så må vi selvsagt redusere antall hendelser ved å lage pålitelige og brukervennlige produkter som treffer brukernes behov. Dette er det langsiktige tiltaket som kan redusere denne effekten betraktelig.

Smidig brannslokking?

OK, vi har redusert andelen brannslokking til et minimum, men hverdagen minner allikevel om slukking av småbranner. Vi er her i “ITIL-land”; vi håndterer ulike strømmer av problemer som kan være underlagt ulike nivåer av servicegrad. En forholdsvis stor andel av disse problemene MÅ løses umiddelbart. Vi må “release” – eller “patche ut” – fortløpende. Iterasjonene virker unødvendige – rett og slett i veien.

Spørsmålet er – kan vi jobbe smidig uten iterasjoner? En ting er sikkert – Scrum har iterasjoner. Der er Scrum veldig klar. Men kanskje vi kan gå tilbake til røttene og finne løsninger i Toyota Production System? Toyota bruker Kanban for å sørge for at innkommende arbeid ikke overstiger ledig kapasitet – og for å sørge for å minimalisere ting i arbeid. Saker under arbeid er definert som waste og skal stadig utfordres.

Hva er Kanban?

Kanban er et signalleringssystem Toyota – og andre som bekjenner seg til Lean – bruker for å sikre at gjennomstømningen av arbeid er optimal og at antall saker i arbeid holdes på et minimum. Selve signalet er ofte implementert med et slags fysisk kort som styrer mengden innkommende arbeid.

Kanban Eksempel: Mengden ferskvarer i en butikkdisk. Vi ønsker å vise fram at vi har en del flotte varer, men vi må også passe på at ikke for mange eksemplarer ligger framme og blir dårlige. Når vi har solgt en del signallerer vi til kjølelageret at vi trenger påfyll – men ikke mer enn at vi har kontroll på kvaliteten. Dette styrer vi best etter at vi vinner erfaring og blir bedre og bedre til å prediktere hvor stor etterspørselen er.

Fra Scrum til Kanban

Scrum har tre faser som vi repeterer om igjen og om igjen: Planlegging, gjennomføring og avslutning. Hver iterasjon skal da ende opp med noe som er fullstendig ferdig i henhold til en definisjon. Dette fungerer veldig godt når vi har et team som forplikter seg til et definert scope i begynnelsen av hver iterasjon. Dette betinger igjen at teamet har noenlunde kontroll på tiden sin. Mange team styrer Sprinten ved at de bruker Task Board (kort som representerer det arbeidet de har tatt på seg som og så følger de den sekvensen som de definerer). Det er mye Kanban tankegang bak dette. Selv om Scrum ikke sier noe om det, vil rutinerte Scrum team vite at det lønner seg å begrense antall saker under arbeid. Vi fullfører så langt det er mulig en og en sak. Nå er virkeligheten som sagt ikke helt sånn for en del team. De er nødt til å planlegge med at en andel av tiden går med til ikke planlagt arbeid. Vi kan i løpet av få iterasjoner bygge opp godt erfaringsgrunnlag på hvor stor denne andelen er. Vi ser av figuren at vi også da må planlegge med en ekstra tilstand for lappene, nemlig I Produksjon. Hastesakene som kommer inn er ofte slik at de må deployes så fort som mulig. Dette er vel og bra, men det er ikke heldig for teamet å måtte håndtere to slike køer med ulik flyt. All erfaring viser at blir andelen ikke planlagt arbeid for stor, blir det tilsvarende vanskelig for teamet å gi gode forpliktende estimater under planleggingen. Dette blir lett som et sammensurium av asynkron og synkron signallering – hvilket sjelden er vellykket!

Vi forsøker her å presse det som er viktigst inn i en prosessmodell som det ikke er egnet for. Kanskje vi skulle tenke motsatt? Kanskje ad hoc-strømmen av vedlikeholdssaker skulle få bestemme flyten? Da kan vi tenke oss innkommende arbeid som en jevn støm av nyutvikling, tilpasninger og hastesaker. Vi må da være gode til å prioritere løpende. Her kan SLA avtaler være til god hjelp. Og så må vi være gode på å deploye ofte – på en trygg måte. Forsøke å komme vekk fra “patche-kulturen” og heller gjøre trygg og god deployment oftere og oftere slik at man etter hvert klarer å automatisere maksimalt av dette. I en slik prosess må vi også være nøye på at vi ikke har for mange ting i arbeid. Det bør finnes regler for hva som er høyeste tillatte antall i både In Progress, To Be Verified og DONE kolonnene.

Hva taper vi med ren Kanban-flyt?

Først og fremst taper vi rytmen. Det blir antageligvis vanskeligere å stoppe opp og lære av erfaring uten iterasjonene. Og det blir nok også vanskeligere å prediktere fremover i tid. Velocity er helt avhengig av iterasjoner. Når det er sagt, vi mangler erfaring med slik fremgangsmåte. Kanskje det ligger uoppdagete muligheter i denne framgangsmåten? Kanskje noen der ute har erfaringer å dele?

Det er ganske stor interesse for Kanban for tiden. Henrik Kniberg skriver for tiden en artikkel om temaet. Og David Anderson har en veldig inteerssant presentasjon fra sin tid i Microsoft på infoQ. Denne casen er fra et sustaining team i India på CMMI nivå 5 som trengte å forbedre gjennomløpstiden. Det klarte de til gangs!

“The L Word”

Jeg er ivrig leser av bloggen til Paul Chaffey. Både fordi han har reflekterte og moderne tanker om organisasjon og ledelse og fordi han er veldig flink til å referere andres artikler og blogger som er av interesse. Den siste av denne typen refererer til Gary Hamels blogg Management 2.0 og artikkelen Generation Facebook vs. Fortune 500. Her viser Hamel til at unge mennesker i “the F generation” (ja F står for Facebook) vil ønske seg – ja til og med kreve – en annen form for organisering enn det de tradisjonelle selskapene kan tilby.

Paul fremhever noen overskrifter fra Hamils blogg:

“Leaders serve rather than preside, 

Tasks are chosen, not assigned, 

Groups are self-defining and -organizing, 

Resources get attracted, not allocated, 

Power comes from sharing information, not hoarding it”.

 

Instinktivt slår det meg at dette er nært opptil Lean. Lean har to hovedpillarer: kontinuerlig forbedring og respkt for mennesket. Inn under menneske-delen her ligger ting som å la team av medarbeidere selvorganisere og styre seg selv. Under oppsyn av en leder som da tjener arbeiderne. Hvorfor kaller vi det da ikke Lean?

Det han beskriver er nært opptil det jeg gjerne kaller Lean Leadership når jeg prediker Smidig ledelse og Scrum. Jeg viser da også gjerne til boka Leading Self-directed Work Teams: A Guide to Developing New Team Leadership Skills av Kimball Fisher for å beskrive ulikhetene mellom tradisjonelle organisasjoner og organisasjoner bygget opp rundt selvstyrte team. Fisher har laget følgende oversikt som beskriver ulikhetene:

Self-directed teams	Traditional organization
Customer-driven	Management-driven
Multi-skilled workforce	Workforce of isolated specialists
Few job descriptions	Many job descriptions
Information widely shared	Information limited
Few levels of management	Many levels of management
Whole-business focus	Function/department focus
Shared goals	Segregated goals
Seemingly chaotic	Seemingly organized
Purpose achievement emphasis	Problem-solving emphasis
High worker commitment	High management commitment
Continuous improvements	Incremental improvements
Self-controlled	Management-controlled
Values/principles based	Policy/procedure based

Heller ikke Fisher tar Lean ordet i sin munn. Ei heller Ricardo Semler som virkelig har tatt den helt ut når det gjelder “mangel på ledelse” i sitt firma Semco refererer til Lean.

Hva kommer det av at man ikke bruker Lean som referanse når man diskuterer disse tingene? Lean er jo en ledelsesfilosofi som både har stor utbredelse og som kan vise til fantastiske resultater! Jeg kan jo forsøke å gjette:

• Lean er jo veldig mye mer enn akkurat dette med selvorganisering – kanskje forfatteren ikke er enig i resten
• Lean betraktes som gammelt og kjedelig – man vil heller sette sitt eget “buemerke” på tingene
• Lean oppfattes som en “rasjonaliseringsteknikk” og det har vært alt for mye fokus på Value Chain Map og eliminate waste
• Lean har en negativ klang hos mange fordi det i nedgangstider har vært brukt som teknikk for å fjerne stillinger som betraktes som waste.

Vel, uansett hva årsaken måtte være; Om Gary Hamel har rett er det ingen tvil om at organisasjoner som bruker Lean og Scrum vil være langt bedre rustet til å tiltrekke seg de beste og best egnede hodene enn de tradisjonelt oppbygde. Vi ser stadig mer fokus på selvstyrte team og ledere som tar et skritt bakover og oppmuntrer til innovasjon. Dette er garantert en av årsakene til at Scrum slår an så godt i IT-bransjen. Unge mennesker deler instinktivt informasjon – det er blant de litt eldre vi finner motstand mot alt dette teamarbeidet og informasjonsdelingen. De som har opplevd kreativitet og problemløsning i tett samhandling med andre vil nødig tilbake til siloene!

Jeg er landets smidigste:)

 

Computerworld har skjønt det. Se bare her: http://turl.no/38s. Kona er merkelig nok ikke helt enig ..

The Fair Play Manifesto

Denne bloggen er jo fortrinnsvis en Agile/Smidig blogg. De innvidde kjenner jo Agile Manifesto og tillegger som meg dette manifestet enorm betydning for utviklingen i IT-bransjen siden 2001.

Men som musikkelskende innovasjonsentusiast kan jeg ikke la være å engasjere meg i den etablerte musikkbransjens hjelpeløse forsøk på å forholde seg til ny teknologi.  Når mp3-formatet kom, internett ble raskt,  minne og prosessorer små, billige og raske – og folk virkelig begynte å ta med seg musikken overalt – kunne de sett på dette som en mulighet. Ikke vanskelig å spå at forbruket av musikk ville komme til å eksplodere! I stedet valgte industrien å kun fokusere på trusselen om at dette lar seg kopiere. Kopisperre ble løsningen og det virkelig store juristskytset ble mobilisert. Her skulle vi ikke ha noe innovasjon, nei! Vi ser smått tragikomiske, men alvorlige utslag av disse holdningene der gamle bestemødre blir straffeforfulgt for å ha lastet ned musikk og Warner får fjernet morsomme, helt uskyldige Youtube-klipp der barn danser og synger med hårbøsdta som mic til musikk Warner har opphavsretten til.

Feartured Artists Coalition er en ny sammenslutning av artister – ikke overraskende startet av Radiohead –  som har sett seg lei av plateselskapenes alt for store makt og deres overgrep mot både artister og forbrukere. Ta en kikk på A Manifesto for Fair Play. De har allerede fått på plass en ganske imponerende liste av medlemmer – som for eksempel David Gilmour, Craig David, Robbie Williams,  Kaiser Chiefs, The Verve og Travis for å nevne noen. Felles for disse er at de bekjenner seg til manifestet som blant annet sier rett ut at vi er inne i en brytningstid der ingen helt vet hvordan relasjonen mellom utøver og fans vil se ut i nær framtid.

Artists are constantly exploring new ways of connecting with their fans. The laws and regulations governing intellectual property, and its administration, will evolve with the digital age. We want the interests of artists to be at the forefront of this transformation.

De vil helt opplagt kjempe for et regime som gir artisten fulle rettigheter over eget materiale. Og en rettferdig andel av rettighetsbruk. Men de faller ikke for fristelsen til å spesifisere nøyaktig hvordan dette skal se ut i praksis.  Jeg tror vi her ser konturene av en helt ny ordning som både artistene og forbrukerne vil tjene på. Gapet mellom ulovlige nedlastningstjenester og plateselskapkontrollerte nettbutikker er fremdeles for stort til at  kopieringsproblemet kan løses. DRM er ikke løsningen og prisen må drastisk ned. Bidraget fra distributørene og den tradisjonelle platebransjen blir ikke lenger nødvendig. Det er dette vi på godt “Leansk” kaller Waste.

“Det virker som vi sluttet å bruke hue”

Tidligere i dag satt jeg i samtale med en gruppe ledere i en større bedrift som har tatt i bruk Scrum. De sliter. Som mange andre. De har daglige stand-up møter, de lager burndown charts (i et Scrum verktøy) og de beregner velocity (i det samme verktøyet). De kjører ganske store prosjekter med paralelle team med stor grad av avhengighet. Så vidt jeg klarer å tolke deltagerne er det ingen motstand mot Scrum. De har alle positive erfaringer, men det er også en god del frustrasjon. Normalt tenker jeg. Vi har ikke så mye tid, kun to timer. Temaet er “hvordan kan vi få Scrum til å fungere enda bedre hos oss”.

En av frustrasjonene kommer fra en av de mest operative lederne: “Nå har vi fått teamene noenlunde tverrfaglige og deltagerne samarbeider godt. De har et flott, kollektivt eierskap. Men nå ser det ut som samarbeidet mellom de ulike teamene er blitt dårligere.” “Er teamene klare over at de har sterke avhengigheter?” spør jeg. “Ja, det er mange i de ulike teamene som har et godt overblikk, så de er klar over dette. Vi har også snakket om dette på retrospective møtene”. “Scrum kommer ikke til å løse dette for deg” sier jeg. “Scrum er egentlig bare er forbedringsprosess, som hjelper deg med å avdekke problemer. Så gjelder det bare å løse problemene eller fjerne hindringene en etter en.” De kikker litt matte opp på meg der jeg står ved tavla. “Dette vet vi jo egentlig” sier den ene – “men vi vil så gjerne at det skal være en oppskrift!” “Med verktøystøtte!” utbryter en annen. “Det virker som vi sluttet å bruke hue” sier den tredje…

Gartner har endelig skjønt det! … eller??

Dagens Computerworld  (papirutgaven) begynner bra med en kommentar av Michael Oreld kalt “Jakten på gode Prosjekter” etterfulgt av Peter Hidas’ sedvanelige Plass som også drøfter utviklingsprosjekter. Jeg leser innledningen med stor interesse: Det virker som Scrum-skeptikeren Hidas har skjønt det! Ta for eksempel utsagnet:

Systemutvikling er ikke en teknisk byggeprosess, det dreier seg om å samle inn og systematisere kunnskaper og synspunkter. Det dreier seg om læring. Designerne strever med å forstå hvilke behov brukere og ledere har. Disse har ideer, men de forandrer seg hele tiden.

eller dette:

Systemutvikling er en reise, ikke et bestemmelsessted

Han snakker varmt om hvordan Nick Jones i Gartner ga ham inspirasjonen til disse nye erkjennelsene. Hmmm.. er det noen som har sovet i timen her? Det er jo nettopp erkjennelsen at det er umulig å love fast pris, tid, omfang og kvalitet som har gjort Smidig systemutvikling til den desidert mest vellykkede måte å drive systemutvikling på. Jeg pleier å illustere dette med den enkle figuren til høyre. Vi kan ikke forplikte oss til å holde omfang, pris, kalendertid og kvalitet fast. Vi må slutte å lure oss selv! Den aller beste kandidaten å holde fleksibel er omfanget. Dette kan vi foredle underveis i prosjektet i tett dialog med de som har behovene. Dette er smidig systemutvikling. Vi ser også at gjennom bruk av for eksempel Scrum får vi helt nye muligheter til å angripe kvalitetsproblematikken.

Dette er så vidt jeg kan se Hidas’ poeng også – i innledningen. Men så begynner desverre artikkelen å ta en overraskende dreieing. I stedet for å nevne at dette har Smidig-bevegelsen hevdet siden slutten av 90-tallet begynner så Hidas å snakke om at vi på grunn av disse karakteristika for utviklingsprosjekter må vi bare finne oss i en del bugs! Han sier ingenting om at det kanskje finnes en løsning på problemet. Artikkelen nevner hverken Agile, Scrum eller Lean…

Det virker desverre her som Gartner ligger ca 10 år etter store deler av bransjen..

• 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)