Kundens smidige manifest

Hvordan ville det smidige manifestet ha sett ut dersom det var blitt skapt av kunder?

Det smidige manifestet ble skapt av en gruppe svært talentfulle mennesker. Men alle sammen kom fra leverandørsiden av utviklingsprosjekter, noe som er tydelig allerede i den tredje av de fire verdiene:

Samarbeid med kunden framfor kontraktsforhandlinger

– som implisitt sier at «vi» ikke er kunden.

For å få ut de største gevinstene av smidige filosofier, må kundesiden også jobbe på en smidig måte. Dette betyr mer enn å skaffe en Produkteier som utviklerteamene kan jobbe med eller for. Kundesiden av prosjektet må jobbe ikke bare med utviklerne, men også med sin egen organisasjon og andre interessenter. Spesielt viktig er det at kundesiden av prosjektet må finne ut hvilke mål produktet må nå for å skape virkelig verdi for interessentene.

Så derfor lurer jeg på: Hvordan ville det smidige manifestet ha sett ut hvis det hadde blitt skapt av kunder i stedet for leverandører?

Her er resultatet av mitt lille tankeeksperiment.

Smidige verdier

Vi oppdager stadig bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe andre. Derved har vi lært oss å verdsette:

  • Individer og samspill framfor prosesser og verktøy
  • Fungerende system framfor utførlig dokumentasjon
  • Å levere verdi til interessenter framfor å fullføre funksjonalitet
  • Samarbeid med leverandør og egen organisasjon framfor kontraktsforhandlinger
  • Å reagere på endringer framfor å følge en plan

Smidige prinsipper

(Merk: Nedenfor har jeg inkludert de original prinsippene, men uthevet de nye forslagene, slik at du enkelt kan se likhetene og forskjellene. Den norske oversettelsen av originalprinsippene er forøvrig basert på en diskusjonsmidig.no-forum.)

Vi følger disse prinsippene:

  • (NY)
    Det hjelper ikke å gjøre tingene riktig hvis vi ikke gjør de riktige tingene. Vi må jobbe kontinuerlig med organisasjonen vår og med sluttbrukerne for å finne ut hva som er de riktige tingene.
  • Vår høyeste prioritet er å tilfredsstille kunden gjennom å levere et verdifullt, kjørende system tidlig og hyppig.
    Vår høyeste prioritet er å skape verdi for interessentene gjennom tidlige og hyppige leveranser av programvare.
  • Ønsk endringer i krav velkommen, også sent i utviklingen. Smidige prosesser utnytter endringer til å gi kunden konkurransefortrinn.
    Ønsk endringer i krav velkommen, også sent i prosjektet. Smidige prosesser utnytter endringer til å gi organisasjonen vår konkurransefortrinn.
  • Lever fungerende programvare hyppig, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
    Lever verdifulle løsninger hyppig, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
  • Forretningssiden og utviklere må jobbe sammen daglig gjennom hele prosjektet.
    Jobb sammen med interessentene og utviklerne kontinuerlig gjennom hele prosjektet.
  • Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
    Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
  • Den mest effektive metoden for å formidle informasjon til og innen et utviklingsteam, er å snakke ansikt-til-ansikt.
    Den mest effektive kommunikasjonsformen er å snakke ansikt til ansikt mens dere visualiserer samtaleemnet på papir eller tavle. Bruk andre former kun når tilleggsverdien er større enn tilleggskostnaden.
  • Kjørende system er det primære målet på framdrift.
    Verdi realisert av interessentene er det primære målet på framdrift.
  • Smidige prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et konstant tempo i ubegrenset tid.
    Smidige prosesser fremmer bærekraftig utvikling. Interessentene og utviklerne bør kunne opprettholde et konstant tempo i ubegrenset tid.
  • Kontinuerlig fokus på teknisk kvalitet og godt design fremmer smidighet.
    Kontinuerlig fokus på høy teknisk kvalitet fremmer smidighet.
  • Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
    Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
  • De beste arkitekturene, kravene og designene vokser fram fra selv-organiserende team.
    De beste løsningene oppstår i selv-organiserende teams med klare mål.
  • Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og justerer arbeidsmåten sin tilsvarende.
    Med jevne mellomrom reflekterer alle involverte over hvordan de kan bli mer effektive, og justerer arbeidsmåten sin tilsvarende.

Oppsummerende ord

Jeg har holdt meg tett opp til de originale verdiene og prinsippene – kanskje for tett. Å ligge opptil originalen kan ha verdi – på en måte gir det kunde- og leverandørsiden en tydelig felles plattform. Dessverre det kan også bety at jeg overser noe viktig. Men det er ikke meningen her å skrive et helt nytt manifest (hvordan skulle jeg kunne det?), men heller leke rundt med «hva om…» og kanskje få fram noe verdifullt om likhetene og forskjellene mellom utvikleres og kunders perspektiv.

Hva synes du?

(takk til Johannes, Eli og Simen for innsikter og forslag som gjorde denne artikkelen bedre)

3 kommentarer om “Kundens smidige manifest”

  1. Hei Trond,

    ikke hver dag jeg er her (men kommer gjerne oftere nå 🙂 – så det Smidige Manifestet var nytt for meg.

    Noe jeg umiddelbart reagrete på, som også jeg tro har betyding for kunder, og det var den smale implisitte definisjonen av «prosess»:

    «Individer og samspill framfor prosesser og verktøy» – individer og samspill er jo prosess, sekventiell eller paralell jobbing, så lenge ikke «prosess» forståes smalt som rigid og forhånds bestemt. Prosess kommer man ikke unna og den kan godt være av en slik art at «prosess medlem bestemmer neste aktivitet utifra situasjon». Dette er den mest vanlige type prosess der folk er involvert (omtrent 60% eller mer av WW GDP) og den trenger et rammeverk like mye som de lineære, forhånds satte prosessene. Dog et rammeverk type «elveleie» og ikke «rørgate» 🙂

    Hvis prosess inkluderer denne mest vanlige typen så burde den paragrafen vært annerledes. Samme gjelder for «Å reagere på endringer framfor å følge en plan» idet den og implisitt anser prosesser som lineære og forutbestemte med eventuell «endringer/avvik».

    Hvis prosess ble definert som nevnt, at den ikke altid er frohåndsbestemt med krav til inngrep fra prosess medlem, da vil kunde og prosess medlem lettere forstå hva som skjer og hva skal skje med klar oversikt over hvilke punkter i prosessen der retningsendring er forventet.

  2. Hei, Sigurd!

    Takk for tilbakemeldingen!

    Jeg er kjent med – og enig i – din bredere forståelse av prosess. Det smidige manifestet bruker derimot «prosesser» i betydningen «forhåndsbestemte rutiner og prosedyrer». Manifestet oppsto som en reaksjon mot de den gang etablerte, beskrevne forhåndsdefinerte prosessene for hvordan man skulle kjøre prosjekter (som typisk innebar masse planlegging og spesifisering før man begynte å lage noe som helst av det man egentlig skulle lage). Og selv om smidige metodikker i stor grad er bygget rundt noe som likner dine tanker om «barely repeatable processes», så har man (hvem nå dét er) fortsatt å bruke den snevrere definisjonen av prosess.

    Ord er viktige, utviklingen av kunnskap er avhengig av utviklingen av ord og deres meningsinnhold. Det smidige manifestet er et historisk dokument som har 10-årsjubileum neste år, med ord og meningsinnhold knyttet til sin tid. Kanskje det er på tide å endre forståelsen av «prosess» for å få nye innsikter?

    Og så får jeg vel tillate meg å linke til http://thingamy.com/ siden du – kledelig beskjedent og dannet – lot være å linke dit selv 🙂

  3. Hehe, takker for link!

    En ting som jeg er rimelig sikker på er at den enkleste, kanskje sterkeste men ihvertfall den med «most bang for the buck» metoden for innovasjon er «challenge assumptions»! Masse overraskende innsikt å hente der, for ikke å snakke om ideer.

    Og med det må man jo begynne med semantikken, der ligger mye «assumptions» bakt inn – en billig og grei metode.

Legg igjen en kommentar