Why not release earlier?

A post about how to overcome the terror of feedback, and why it is an important step towards continuous delivery 


I had a conversation yesterday with a team that was putting out version zero of a product. “Yes, yes. Release early, release often. We absolutely agree.” I thought the conversation was going well. “Of course, we need [insert completely useless feature here] before first release.” Dang. Again?

I have had this discussion, with others and myself, a hundred times. What is going on? Why do we repeatedly agree that feedback is good and then do really crazy things to avoid feedback?

Having watched myself elevate unimportant features to the status of must-haves many times, I have decided that I am at war with myself. On the one hand I want feedback. Of course I want feedback. Feedback makes me better and smarter. Feedback makes my projects more successful. Even if the feedback is “cancel the project”, that just means I have more time for other potentially-useful projects.

On the other hand I hate feedback. To work on a project I become emotionally attached to it (too much). I believe it will be successful. I care that it will be successful. I am afraid that if I lack passion, I won’t be able to work. From this perspective, feedback is a threat, not just to my project, but to me.

Psychologists talk about boundaries, having a good sense of what is me and what is not me. When I manufacture enthusiasm for a project, I blur my boundaries. I begin to think, even though it isn’t objectively true, that my project *is* me. Feedback at that point becomes a personal, existential threat, and my brain is really good a performing rhythmic gymnastic contortions when faced with a personal, existential threat. Like believing, really believing, that automated deployment infrastructure is absolutely vital for the first release.

When I catch myself thinking this way I use a few techniques to return towards sanity:

  • Ask for feedback. Friends don’t feel an existential threat, so they remain saner. “Here are all the things I have to do before first release. Anything on this list optional?”
  • Remind myself that my project is not a part of me. Over and over. I figure if I repeat it ~1e6 times I may begin believing it.
  • “What’s the worst that could happen?” There’s a sequence to my thinking. It’s quick, but if I am aware I can catch the steps: 1) think about getting feedback, 2) imagine failure, 3) terror, 4) invent new must-have feature. If I can intervene at 2), I ask myself, “What’s the worst that could happen?” The project is cancelled. My reputation is ruined. I never program again. My whole family starves to death. I go to hell forever. Okay, so the consequences won’t be that bad really. What’s likely to happen? Change the project direction. Oh, that’s not so bad.

I’m not sure everyone reacts this badly to the prospect of feedback, but from the conversations I have I suspect that many people do.

What’s your “terror of feedback” story?

Svarteper i smidig utvikling

Du er inne i et prosjekt som har gått et par tre måneder. Det finnes ikke noe i produksjon, men backloggen er lang som et vondt år og består av noen hundre user stories som ble estimert en gang i begynnelsen. Første release nærmer seg med friske stormskritt, ingen vet egentlig hvor mye som er ferdig og hvor mye som gjenstår.

Flickr creative commons: jwright4701

Høres dette kjent ut? Da kan det hende at ditt prosjekt snart skal utnevne svarteper. Denne personen skal vade gjennom krav og user stories og rydde opp i backloggen. Prosjekter bygger nemlig ikke bare opp teknisk gjeld. Funksjonell gjeld eller rot i funksjonelle krav, kan være minst like hemmende.

Så hvem er svarteper? Det er stakkaren som blir utnevnt til funksjonellt ansvarlig, og som kommer til å kjempe de neste ukene eller månedene bare for å få hodet over vannet.

Åpent spørsmål til slutt, hvorfor tar det ofte så lang tid, gjerne helt til prosjektet er i krise, at man innser at noen må ha overordnet funksjonell oversikt? Og at dette er en veldig viktig oppgave som noen må jobbe med på fulltid helt fra starten av.

Books Our Developers Should Read

There are a few books that every developer in Iterate should read because they express what we believe in and are extremely valuable in themselves. The books chosen are generally and broadly useful and not tied to some too limited domain (contrary to e.g. Effective Java).  The list is kept as short as possible, about 4-5 books, and is revised regularly.

Why particularly these books, why lean and agile? Our people are primarily responsible for crafting solutions for our clients, for making sure that they use the customers’ limited resources efficiently to produce the maximal business value possible. However, according to our experience, it is never truly known upfront where that value lies. Software development is therefore inherently a learning and exploration process. A process that needs to be continually adjusted based on empirical feedback from the reality and on shifting conditions. This is what lean is about: eliminating waste, maximizing value by maximizing learning, making sure that the right product is built. We value software craftmanship and building things right – but building the right things is crucial.

Here are the books and why we believe they are so important.

Continue reading

Få betalt for feil du ikke finner!

På dagens frokostmøte ble det ytret frustrasjon rundt testere i ett prosjekt som så det som sin oppgave å finne flest mulige feil i applikasjonen. Og det er greit nok det, om man har rigget prosjektet sitt på en måte som gjør at det er mulig å implementere feil i utgangspunktet. Kollegaen min refererte hele tiden til “oss” og “dem” når vi snakket om situasjonen.  Noe som forsterket muren som stod mellom utviklere og testere i dette prosjektet.

Dette er fra et prosjekt med den klassiske designe-alt-utvikle-alt-teste-alt-produksjonsette-alt-tankegangen (også kjent som vannfall). Ett av problemene er jo selvsagt strategien som er valgt, men hovedproblemet til min stakkars kollega er at utvikling kommer før test i et slikt sekvensielt løp. Det må jo være bedre om utviklere og testere samarbeider i større grad, tenker jeg? Noe man kan dra nytte av helt uavhengig av metode og strategi.

Continue reading

The splendid long iterations

Some times, we want longer iterations.

We waste to much time in meetings and other activities associated with iteration turnovers, so we decide to extend the duration of the iteration. Let’s make those planning meetings, estimation workshops, retrospectives and what-have-you happen less frequently. We might even get some work done, right?

Sadly, longer iterations don’t change how customers interact with us. We continue to get expedite requests, like having to fix a bug (which obviously shouldn’t have been there in the first place). Now that iterations are longer, we appear less responsive to our customers, which of course wasn’t the idea at all. To compensate, we could introduce mid-iteration releases?

Moreover, with longer iterations management feels less in control, because feedback is less frequent, and problems seem to pile up more now than before. That wasn’t the idea in the first place, so they feel compelled to introduce stricter reporting. How about a mid-iteration report?

Finally we get to the iteration turnover. We have experienced flow and feel great, except lack of coordination within and between teams makes our stuff not work that well together when we integrate. We decide to talk more. So we introduce a regular integration planning meeting with the other development teams. Would twice each iteration do?

Making iterations longer can be comfortable for a while. It feels better to work longer periods at a time undisturbed, and it feels better to spend our working time developing as opposed to attending meetings.

What's the scent of your learning cycle?

Longer iterations are however nothing more than a dangerous painkiller, which conceals the real problems we have. Double the iteration length, and iteration turnover gets four times as painful and half as useful. The reasons we have iterations in the first place is to create learning opportunities. Why would we want less of them when we could have more?

Longer iterations create room for more waste, forcing us into compensations that drive more compensations. We get iterations within iterations. We get wasteful reporting. We get less coordinated and produce more bugs. We stop doing retrospectives because we don’t have time to follow up on the resulting action points anyway. The resulting problems call for more meetings, and we get tempted to extend the iterations even further, which makes iteration turnovers even more painful. In the end we’re so sick of iterations that we start longing for waterfall.

Taiichi Ohno, the great engineer and systems thinker at Toyota had a helpful analogy about rocks and water. Imagine your process being a river with rocks on the bottom. The water is our level of comfort, and the rocks are everything which we shouldn’t be doing. Ohno calls them waste, which he defines as everything we do that doesn’t bring value to the customer. When the water level is high, we hardly see any rocks, hence the only way to find waste is to lower the water level. In other words, make ourselves less comfortable.

How does this translate to the pain of iteration turnovers? We do more of it. We have those turnovers so frequently that we have no other choice but to get good at it. In other words: When iteration turnovers are painful, we make the iteration duration shorter.

Here’s a question to ask our team: What would it take to go to half the iteration length, while keeping our current velocity?

We would have to make meetings shorter and more efficient. We would have to reduce the defect rate. We would have to make deployments faster. We would have to stay coordinated at all times, both within and between teams. We would have to follow up rigorously on action points from retrospectives.

That’s when we stop curing symptoms and start acting on root causes of problems. That’s when we start doing continuous process improvement.

That’s when we want even shorter iterations.

The user feedback problem

If you’re into agile, you’ve probably encountered this question: If iterating over user feedback is so fundamentally important, how come Apple has repeated success with their apparent one-off, non-iterative, grandiose launches of new products?

Monty Python I'd like to have an argument

Is this the place for user feedback? (I told you once)

Agile skeptics love this argument. To them it’s a once for all win over advocates of frequent releases. They probably feel like Michael Palin in his surreal Monthy Python sketch with John Cleese, where they enthusiastically have an argument about whether they have an argument. Desperately fighting and imminent defeat after failing to stop arguing when “time’s up”, Cleese responds “I might be arguing on my spare time”, to Palin’s pointing-in-your-face-gotcha-finger.

“No you’re not”. “Yes I am”. “No you’re not”. “Yes I am” …

Similar surreal arguments happen in software companies. There are always someone who doesn’t want to go into production in short, regular intervals, and there are always someone who wants it.

So what’s Apple doing? Iterating on their spare time? Maybe the rest of us should look to Apple and grant the skeptics right. Stop nagging ourselves with those tedious deployments, not to mention the even more tedious user feedback. We’re talented developers, trained professionals, experienced craftsmen – let’s go with our vision and gut feelings just like Jobs did!

Both within the agile community and other places I encounter this misunderstanding disturbingly frequently. Moving on from the triumphant Apple argument, the skeptics continue: Users lack fantasy. They don’t know what they want, and will ask for solutions within a narrow mindset framed by whatever it is they use today. Henry Ford nailed it forever with his famous quote: “If I had asked people what they wanted, they would have said faster horses.”

This is where I think things get tricky: In a sense the skeptics are both right and wrong. It’s true that users lack imagination and even lie some times. Hence, they are right that we shouldn’t ask users what they want. They are however wrong about not frequently releasing to production.

The fact that users don’t know what they want is no excuse not to iterate.

We should still interact with our users – and we should use our software as medium. First and foremost we must have empathy with our users. We need to fundamentally understand them, better than they understand themselves. If we do ask users questions, we don’t ask about features. We ask how they feel when logging into their computer. We ask what’s their favorite software, and why. We ask why they are using our product.

When iterating cleverly we’re somewhere in the middle. (Comic: Calvin & Hobbes)

From this insight we might get tons of ideas for features. We verify them one at a time, quickly. We refine them and verify the refinements in a tight build-measure-learn loop: Cut a feature into the thinnest slice possible, and deploy it. Monitor what happens. Deploy two different versions of the same feature and monitor what happens. Pull a feature which is hardly used and see what happens.

What’s interesting about this approach, is that neither the overacting agile crowd, nor the agile skeptics will agree with you. To them you’re either not listening to your users, or you’re letting them dictate a product without direction. (Thanks to Kent Beck for this perspective).

From Eric Ries book The Lean Startup: We really did have customers in those early days – true visionary early adopters – and we often talked to them and asked for their feedback. But we emphatically did not do what they said. We viewed their input as only one source of information about our product and overall vision. In fact, we were much more likely to run experiments on our customers than we were to cater to their whims.

In the Scrum world there is a lot of discussion about a Definition of Done. Jeff Sutherland has a long list of steps that need to be carried out before a task is done. To me he’s missing the most important part: That you’re not done with a feature until you’ve analyzed the behavior of paying customers using it.

Focus groups, user dialog, staged usability tests in artificial environments and situations can all be sources of insight, but they can also be deceiving. The interesting part is not what the users say – it’s what they do, on a daily basis: The Proof of the Pudding is in the production usage data. Hence we should develop a way to quickly try out features, gather usage statistics, opinions and other knowledge. It might also be a good idea to recap statistics classes from the university days, make A/B-testing easy, and if your product is in the public, use sites like usertesting.com.

I don’t believe Apple isn’t iterating. Having hardware products they cannot iterate like a software company. Having a marketing strategy which builds up hype around spectacular launches calls for subtlety. But you don’t really think they came up with all those products without seeking insight into their users?

Arguments shouldn’t be about whether we release frequently or not. It should be about how we do it. So if you haven’t already, I encourage you to start a discussion with your team about sources of insight into users, tools for gathering such insight and what iterative strategy would support this. You may also want to reiterate how your organization is set up.

You will be innovating before you know it. @hauge2

Liked the article? Join a free mini-seminar about Guerilla User Reserach in our office in Oslo on the 11th of december, 8:00. You will learn why asking your users for what they want isn’t always helpful, which do-it-yourself techniques you can use to understand their needs, how to make sense of the data you collect, and how all of this translates into the development of better features. Sign up here>>

Ungdommen nå til dags

Ivar og jeg har holdt workshop for IT-elevene på Sandvika videregående skole. TV8-innslag fra workshoppen her. Temaet var smidig utvikling.

Jeg er alltid spent på utfallet av en workshop. Ved siden av mange tilfeldigheter spiller også bedriftskultur, motivasjon og trygghet inn på deltagernes evne til å løse oppgavene. (Litt på samme måte som med systemutvikling forøvrig). Denne gangen var det imidlertid ikke ansatte hos Aker Solutions, Widerøe, Statistisk Sentralbyrå eller andre profesjonelle systemutviklere som skulle i ilden. Hvordan ville de unge og uerfarne elevene prestere? Kom det til å bli for vanskelig for dem?

De fikk to oppgaver. Den første utfordret lagarbeid og prosessforbedring. Den andre utfordret planlegging og innovasjonsevne. Det var voksne oppgaver for et ungt publikum.

De klarte seg imidlertid svært godt, faktisk bedre enn de fleste. Spesielt flinke var de på å utfordre rammene for oppgavene.

Noe av poenget med oppgavene er nettopp å gjøre deltagerne mer bevisste på selvpålagte begrensninger, og det hadde disse ungdommene lite av. Dermed kom de også frem til løsninger tidligere enn normalt, i en inspirerende blanding av ungdommelig overmot, tett samhandling og evne til å jobbe målrettet uten sløsing.

Dette minner meg om en reklamefilm som gikk for noen år siden. Det kryssklippes mellom to grupper, den ene på kurs i å uttrykke følelser, den andre på fotballkamp. De stakkars kursdeltagerne er så stivbente i sine forsøk på å gi hverandre en klem at man blir – nettopp – helt beklemt av å se på. Lettelsen er tilsvarende når man ser gjengen på fotballkamp brøle og kaste seg rundt halsen på hverandre i vill begeistring når laget deres scorer.

Å uttrykke begeistring på en fotballkamp er en evne som må falle seg naturlig – den kan ikke instrueres på detaljnivå. Det samme gjelder team-arbeid og innovasjon.

Elevene angrep problemstillingene uten hensyn til egne begrensninger, verken som personer eller som team. Som en gjeng som trikser med en fotball, ble idéer fortløpende kastet ut, og sparket opp, ned eller ut. Like lett gikk de inn i de påfølgende diskusjonene om realisering. Deres manglende innsikt i teknologiske begrensninger var like mye en fordel for deres evne til kreativ problemløsning.

Min erfaring er at vi som profesjonelle fagfolk jobber motsatt. Vi tenker begrensninger og analyse først, og løsning etterpå. Klok av skade, vil kanskje noen si. Iallefall de som kjørte på som ungdom, og opplevde konsekvensene av å være ugjennomtenkt. Jeg tror imidlertid at vi overkompenserer på dette området.

Elevene hjalp oss iallefall innse at oppgavene de fikk er mer tiltrengt når man har mistet det ungdommelige overmotet. Jeg håper derfor de klarer å bevare energien sin gjennom studier og inngangen til arbeidslivet. Ikke bare er det bra for hver enkelt av dem, det smitter også over på omgivelsene.

Slik det gjorde på Ivar og meg 🙂

Ikke så smidig likevel

I TU nr 38 17/11 2011 fremmes det en advarsel om at smidige metoder går utover det grunnleggende ingeniørhåndverket.

IT-arkitekten Simon Brown mener at arkitekturen kan lide dersom man har en rendyrket smidig tilnærming til IT-utvikling. Han tillegger bransjen et ønske om å være kjappe og effektive, og mener dette er årsaken til problematikken. Et eksempel han trekker frem er et system som gikk i produksjon med passordet “password”, og således stilte seg lagelig til for hack.

Løsningen på dette skal ifølge Brown og Bouvet være å kombinere smidige metoder med tradisjonell tankegang. Dette for å redde software engineering.

Fra Teknisk Ukeblad nr 38, 17. november 2011

Vi mener ingen metoder kan forhindre oss i å jobbe feil. Metoden er teori, produktet du utvikler er praksis. Teorien til smidig tankegang er like enkel som den er krevende å gjennomføre: Jo tidligere og hyppigere vi kan få tilbakemeldinger, desto kortere tid bruker vi på å realisere gevinster.

Tilbakemeldinger kommer fra en rekke kilder, og dyktige utviklere vet hvilke kilder de skal oppsøke. Brukere er en åpenbar kilde, som de fleste oppsøker. Forretningsutviklere, driftere, brukeropplevelse-eksperter og arkitekter er andre eksempler. Jeg kjenner ikke det omtalte “password-prosjektet” fra innsiden, men jeg tillater meg å spekulere i om utviklerne oppsøkte tilstrekkelige tilbakemeldingskilder før de gikk kjapt – men ikke effektivt – i produksjon.

Vi ser tradisjonelle selskaper der den minste arkitekturendring krever store seremonier, politisk spill og tautrekking for å bli implementert, som regel kvartaler etter at behovet oppsto. Implementasjonen blir gjerne også ugunstig, fordi den i slike prosesser alltid blir påvirket av agendaer, som ikke er relevante. Konsekvensen er en metode som hverken er kjapp eller effektiv. Det eneste en slik tankegang fremmer er svært effektive blaim games. Det blir som tittelen til artikkelen ganske riktig påpeker: Ikke så smidig likevel.

Det er mange utfordringer knyttet til innføring av nye tankesett. En av dem er at gamle roller blir utfordret. Med smidig utvikling ønsker vi ikke den klassiske arkitekten lenger, fordi arkitektur skal være utviklerteamet sitt ansvar. De må imidlertid gjerne benytte arkitekter som kilde til kunnskap. Det kan vi anbefale, iallefall i en overgangsperiode.

Smidig tankegang gir oss et konkurransefortrinn gjennom å skape selvstendige enheter som har tilstrekkelig kompetanse til å finne de beste løsningene, gjennom små iterasjoner som i seg selv skaper mye lærdom. Tar enheten avgjørelser uten å oppsøke tilstrekkelige tilbakemeldinger – ja, da gjør de rett og slett ikke jobben sin. Og når noe går galt har de heller ikke muligheten til å skylde på en storebror, det være seg en arkitekt eller andre skrivebordsgeneraler.

Det er når teamet eier løsningen, at de også finner løsningene.

Dersom du står ansvarlig for et smidig utviklingsløp, vil vi heller anbefale deg å forbedre den iterative prosessen, enn å skape rom for utdaterte roller og seremonier. Spør heller teamet ditt jevnlig: Hvilke kilder til tilbakemelding benytter dere nå? Hvilken ny innsikt fikk dere fra forrige produksjonsetting? Hvilke kriterier legger dere til grunn for deres arkitekturvalg?

Endringer kan være smertefulle, men de er betraktelig hyggeligere enn å bli akterutseilt av en konkurrent – som ikke fokuserer på å jobbe kjapt – men derimot klarer å jobbe effektivt. Skal IT-bransjen lykkes med gevinstrealisering må vi slutte å kurere symptomer hver gang vi får problemer med å endre oss.


Noen ganger er det vanskelig å være uenig.

For eksempel når man ser ord, som brukes så mye, overalt, at den egentlige meningen fortrenges til fordel for selvfølgeligheter ingen registrerer. Kvalitet er et slikt ord. Kompetanse er et annet. Kunnskap et tredje. Hva forteller det deg når en virksomhet sier de satser på kunnskap, kvalitet og kompetanse?

Meg forteller det ingen verdens ting. Ganske enkelt fordi nettopp alle i bransjen vår satser på kunnskap, kvalitet og kompetanse. Iallefall tilsynelatende.

Det skulle være moro å se et selskap overføre “rent a wreck”-konseptet til IT-bransjen. “Hos oss får du leie middelmåtelige ingeniører til en rimelig penge! De er rufsete i kantene og velbrukte, men du vet – slike traktorteknologer er kanskje gammeldagse, men desto mer slitesterke!”

Du verden, jeg kunne vært fristet til å kjøpe.

Så hvorfor er kommunikasjonen i vår bransje preget av floskler? Jeg kjørte nettsidene til noen typiske IT-selskaper, inkludert mitt eget, gjennom tagcrowd, og endte opp med følgende liste av ikke-meningsbærende ord:

Brukervennlig, faglig, kundetilfredshet, kunnskap, langsiktig, ledende, medarbeider, muligheter, samarbeid, smart, spennende, troverdig.

Ærlig talt: Er det mulig å ta noe annet standpunkt enn det disse ordene gir uttrykk for? Er det noen som er imot brukervennlighet og kundetilfredshet? Eller hva med medarbeidere? Noen som er imot medarbeidere?

Det neste naturlige steget i tankeprosessen blir å finne et uttrykk for våre faglige ambisjoner, der vi faktisk skiller oss ut. Det er en nyttig øvelse, som jeg kan anbefale alle å gjøre der de jobber. Forsøk å si noe som stemmer om din bedrift, men som du antar noen vil være uenig i. Og si for guds skyld fra til ledelsen om du ikke finner noe.

Kaizen er japansk og refererer til en filosofi om kontinuerlig forbedring. Umiddelbart liker jeg ordet fordi det gir meg en slik mystisk, asiatisk, Uma Thurman-ish følelse av noe sofistikert og tøft. (Jeg liker det også av faglige grunner.)

Uma Thurman fra Kill Bill

Om Uma Thurman bruker Kaizen vites ikke. Men ingen tvil om at hun er tøff.

Ordet Kaizen er imidlertid lost in translation. Kontinuerlig forbedring er jo nok et eksempel på en floskel, iallefall hvis man følger min ad hoc-definisjon: Hvem er vel imot å forbedre seg fra tid til annen?

Spør du meg, er en bedrift som faktisk gjør Kaizen et sted der du merker det allerede i resepsjonen. Det er en bedrift der alt du gjør, fra time til time, utledes fra et ønske om å forbedre seg. Forbedringer blir navet i det daglige arbeidet.

Hvordan arter dette seg i programvareutvikling? Det første mange tenker på er kanskje iterativt arbeid med jevnlige evalueringer. Min erfaring med vanlig praksis innen iterative metoder, er å inkludere et relativt kort evalueringsmøte etter hver iterasjon, lage seg en liten handlingsplan med noen tiltak som lever side om side med de andre, planlagte oppgavene. Jeg lar det være opp til deg som leser å vurdere om slik praksis er Kaizen eller jevnlige forbedringsforsøk.

Det nærmeste jeg har kommet Kaizen-liknende tilstander i mitt fag er lean startup-metoden (som du kan bruke selv om du ikke jobber i en startup). Om du har en time å avse, anbefaler jeg denne introduksjonen fra Eric Ries. Han mener programvare bør utvikles gjennom systematisk validering av antagelsene du har i ditt business case. Det betyr at du må ha et business case – og ikke en kravspesifikasjon – som utgangspunkt for arbeidet. Du jobber i svært korte iterasjoner og bruker all din tid på å skaffe tilbakemeldinger på dine antagelser om kundene og markedet. Ingen tilbakemeldinger er bedre enn det du får høre fra betalende kunder, som bruker programvaren din.

Betyr dette at du lar brukerne diktere produktet ditt? Nei. Det er fortsatt ditt ansvar å tolke svarene du får, og omsette de til et helhetlig, sammenhengende produkt. Poenget er at du skaffer deg svar, hele tiden. At du tolker dem, hele tiden. At denne økende innsikten styrer arbeidsinnsatsen din, hele tiden.

Det er Kaizen.

Ingen motsetning mellom prosjekt og produkt?

Jeg mener stadig at IT-utvikling som oftest bør organiseres som produktutviklingsløp og ikke som prosjekter. I Teknisk Ukeblad 13/10 2011 uttaler Tone Bringedal i Difi at det ikke er noen motsetning mellom prosjektorganisering og mine poenger.

La meg først raskt oppsummere hva som er mine poenger: Gode IT-satsinger slutter ikke når verdiskapningen begynner. De lever side om side med brukerne og tilpasser seg kontinuerlig. Offentlige organisasjoner har spesielt behov for dette, på grunn av stadige endringer i politikk, budsjetter og regelverk. Hvordan skal for eksempel Oslo Universitetssykehus klare å modernisere virksomheten og samtidig bruke mindre penger, hvis ikke endringer i IT-systemene er en naturlig, integrert del av prosessen?

Definisjonen av prosjekt på Wikipedia: “Prosjekt betegner innsats som gjøres for å oppnå et definert mål, som oftest innenfor en planlagt tids- og ressursramme (…)”

Flyt av arbeid er viktigere enn kunstige tids- og kostnadsrammer lagt langt frem i tid. Jeg kommer stadig over historier om IT-avdelinger som utvikler ny funksjonalitet til tross for at det brukerne ba om kunne ha blitt løst av funksjoner de ikke visste om. Selv om kunnskapen som slikt dobbeltarbeid – sløsing –  finnes i organisasjonen som helhet, kommer den ikke frem.

Jeg finner like mange eksempler på det motsatte – feilaktige antagelser om at eksisterende funksjonalitet kan løse nye behov. Dette skjer hele tiden, i prosjekter både i offentlig og privat sektor. Det skjer hele tiden, også i prosjekter som hevder å bruke Scrum eller annen smidig metodikk. Det skjer fordi de involverte jager et kunstig mål.

Spørsmålet jeg stiller er derfor som følger: Hvordan kan vi organisere oss på en måte der samhandling mellom utviklere og brukere blir navet i utviklingsarbeidet? Der arbeidskulturen ikke tolererer misforståelser som følge av manglende samhandling?

Jeg mener løsningen må være å fjerne organisasjonsbarrierer. Ledelsen bør fokusere på flyt av arbeid: Hvor mye ny funksjonalitet leverer vi hver uke? Hvor lang tid tar det fra vi identifiserer et behov til vi leverer en løsning? I offentlige virksomheter med saksbehandlere: Hva er utviklingen i saksbehandlingstid?

Man kan selvfølgelig argumentere for at slik tankegang er mulig innenfor et prosjekt. Det finnes flere eksempler på prosjekter der man har levert underveis, og kanskje også realisert gevinster underveis. Men er dette på grunn av prosjekttankegangen eller er det på tross av den? Kan Difi eller andre som forfekter prosjekttankegang gi eksempler på IT-løsninger som ble en suksess fordi utviklingen ble organisert som et prosjekt istedenfor et produktutviklingsløp?

Jeg tror Difi har den riktige pulsen på offentlige IKT-satsinger, noe deres arbeid med kontraktsstandarder bærer preg av. Selv om de forstår mine poenger er imidlertid prosjektbegrepet innarbeidet hos oss alle, også fra politisk hold. Alt for mange offentlige IKT-satsinger har gått galt på grunn av utilstrekkelig styring. Fra politisk hold er det press på kostnadskontroll og risikohåndtering, og der gir prosjekter oss etablerte rammer.

Slike rammer står imidlertid i veien for gevinstrealisering, som seiler opp som det neste store temaet. Min advarsel går først og fremst til de som stiller forventingene til Difi og andre aktører som er toneangivende for hvordan gevinster skal realiseres for det offentlige Norge. Prosjektorganisering er en etablert sannhet. Det er også en selvpålagt begrensning.

Vi må ikke undervurdere de kulturelle konsekvensene av de føringer vi blir pålagt. Det er ikke de som lager prosjektmodellen som gjennomfører satsingene. Det er den enkelte virksomhet, ofte i samarbeid med konsulentselskaper. Det offentlige må sende et tydelig signal om hvordan slikt arbeid skal foregå. Ved å begrense fokuset til en felles prosjektmodell risikerer vi å misforstå poenget, gang på gang.