Categorized | Lean development

Scrum og fossefall som synkende skip

18. september 2008. En merkedag i min løsningskarriere. Den dagen ble jeg “uteksaminert” og fikk den til dels tvilsomme tittelen SCRUM-Master, og kan føye til CSM på visittkortene mine, forkortelser er gøy og fler skal det bli.

Det som var det bemerkelsesverdige var at jeg mer eller mindre hadde en “åpenbaring”;

HVORFOR I SVARTE HAR MAN IKKE DREVET PROSJEKTER PÅ DENNE MÅTEN FØR???

I 1970 beskrev Winston W. Royce (1929–1995) fossefall metodikken for utvikling av programvareløsninger. I 1971 (ca) tok amerikanske Department of Defense metoden i bruk for sine utviklingsprosjekter. Senere, på midten av 70 tallet ble den adoptert av NATO, men da visste allerede DoD at metodikken ikke fungerte særlig bra og har vel side lett etter alternativ metodikk. Men av en eller annen måte har denne metodikken fått spre seg som et prosessvirus og ødelagt mang et utviklingsprosjekt.

I mine 15 år i jobb med utvikling av programvareløsninger har jeg sittet i utallige interne møter der man har prøvd å komme fram til en måte å gjennomføre utvikling fossefallsprosjektene med så liten sprekk og risiko som mulig, men det er nært sagt ingen som er i stand til å gjøre det. Fakta er at 80-90 % av alle programvare prosjekter som startes opp og utvikles etter fossefallsmetodikk bryter sammen på enten økonomi, funksjonalitet/innhold eller tidsfrister.

Det man i utgangspunktet prøver å skape, forutsigbarhet; er nettopp det man ikke klarer å få.

Den eneste forutsigbare faktoren er; en eller annen gang mot slutten av prosjektet vil en prosjektleder og/eller selger måtte ta telefonen til kunden og legge fram at av grunner man ikke kunne forutse i begynnelsen av prosjektet har inntruffet, eller kanskje kunden har endret fokus eller strategi og har ønsket ny og eller endret funksjonalitet.

En dreven kunde vet dette, og når det skjer begynner forhandlingene om hvor mye rabatt man skal få på vedlikehold, support, drift eller liknende på grunn av forsinkelsene alle visste om ville komme. Treenigheten mellom funksjonalitet, pris og tidsramme som låses i de tradisjonelle utviklingskontraktene tvinger en inn i denne situasjonen.

Den beste måten å sørge for at produktet som skal leveres til kunden med den funksjonaliteten og forretningsverdi de her behov for, er å jobbe tettere sammen med kunden. Gjennom hele livsløpet i prosjektet.
Det finnes ingen løsningsarkitekt som klarer å forstå kundens behov ned til minste detalj, og det finnes ingen kunde som vet nøyaktig 100%, ned til minste detalj hva han eller hun ønsker seg. Den beste måten å håndtere dette på er ved å ha intervallermessige gjennomganger (sprinter) av prosjektet.

Ta kunden med på en gjennomgang av hva man har utviklet innenfor en periode av 3-4 uker, for så blitt enige om at det som er utviklet har forretningsverdi og ønsket funksjonalitet, gå løs på neste intervall (sprint) med planlegging av hvilken funksjonalitet man ønsker å demonstrere på neste sprint.

Å rulle tilbake 3 uker med kode/funksjonalitet er langt enklere og mindre kostbart enn å rulle tilbake 6-12 måneders utvikling.

Mye av det jeg har sagt over lærte jeg av Bob Schatz på CSM kurset, og for meg var informasjonen bitene som fikk puslespillet til å falle på plass. 15 år med utviklingsprosjekter som i 90% av tilfellene ikke klarer å innfri de rammene man selv har vært med på å sette opp burde vise at det er på tide å prøve noe nytt.

Jeg vil oppfordre alle som deltar i en eller annen rolle i utviklingsprosjekter til å kikke på sine egne prosjekter, gamle og nye; Hvor mange av dem har IKKE 1 eller flere vedleggs skrevet en god stund etter prosjektets start som beskriver økt kost, tidsramme og/eller lagt til mer eller trukket fra funksjonalitet?

En av de største, etter min mening utfordringene for at scrum som metodikk skal få utviklet seg er selgerne. Selgere må lære seg å kunne selge utviklingsprosjekter basert på smidige utviklingsteknikker. Lære seg å ikke selge en “boks”. men lære seg å selge konseptet “en boks”. forstå kundens forretningsverdig (kunne legge fine ting i boksen for å selge den) og sammen med et team som også inkluderer kunden for å lage boksen slik kunden har sett den for seg.

linker for interesserte, skrevet av andre:
Smidig systemutvikling og innføring i Scrum
Wikipedia
Scrum in 5 minutes
Scrum Alliance

Use Facebook to Comment on this Post

One Response to “Scrum og fossefall som synkende skip”

Trackbacks/Pingbacks

  1. [...] posten ble første gang publisert på min blog Agile Mobility 15. Oktober [...]


Leave a Reply

Google Translate

EnglishFrenchGermanItalianPortugueseRussianSpanish

Blog Traffic

Hits

Pages|Hits |Unique

  • Last 24 hours: 3,657
  • Last 7 days: 16,010
  • Last 30 days: 50,578
  • Online now: 20

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: