Det smidige manifest – fase 1 er over

De første 10 årene med Agile Manifesto har rystet IT-bransjen. På tide å oppsummere.

Om et par måneder er det 10 år siden 17 personer møttes på “The Lodge” i Wasatch mountains of Utah der de etter noen dager med diskusjoner signerte det smidige manifest (Norsk utgave her: http://agilemanifesto.org/iso/no/). Dette var representanter for Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development og Pragmatic Programming – alle ulike retninger og metodeverk som hadde det til felles at de brøt fundamentalt med tradisjonell prosjekttankegang. En slags visjon for et gigantisk endringsprosjekt! Som vi vet ble de enige om 4 overgripende utsagn som skulle beskrive de endringene IT-bransjen måtte gjennomgå for å utvikle bedre softwarebaserte systemer:

Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan

Hvordan er tilstanden her 10 år etter? Setter vi menneskene og kommunikasjon høyere enn prosedyrer? Setter vi fungerende programvare over dokumentasjon? Har vi blitt bedre til å samarbeide kunde – leverandør? Har vi klart å frigjøre oss fra detaljplanen og blitt gode til å håndtere endringer med største selvfølgelighet? Ikke lett å svare på dette selvsagt, men en viss bevegelse har det utvilsomt vært!

De fire utsagnene er veldig overordnede og umulig å bruke som målestokk for en framdrift fra høyre mot venstre. Da er det kanskje mer matnyttig å gå de tolv underliggende prinsippene litt etter i sømmene. Man finner norsk utgave at prinsippene her: http://agilemanifesto.org/iso/no/principles.html. Her kan det være på sin plass med en presisering. Manifestet har blitt forsøkt marginalisert og bagatellisert av tradisjonelle prosjektledere. Utsagnene sier ikke mye om graden av endring – det skal innrømmes – men jeg vil våge påstanden at samtlige av disse 17 både da og den dag i dag vil mene at det man er ute etter et et paradigmeskifte. Altså ikke prosjektstyring med visse justeringer og presiseringer.

En subjektiv evaluering

Jeg snakker med mange “smidig-entusiaster”, deltar på konferanser og meetups og jeg har jobbet med ca 25 ulike organisasjoner de siste 2 årene. Så jeg tenkte jeg skulle våge meg på en enkel og høyst subjektiv evaluering av “tingenes tilstand” i Norge ved inngangen til 2011.

De 3 første prinsippene gjelder enkelt sagt hyppige leveranser og kontinuerlig verdiskapning. Bemerk: Når manifestet sier leveranse betyr dette leveranse helt ut til brukeren og altså ikke ut på en test-server eller lignende. Her må vi nyansere litt, for det er en del tilfeller der hyppige leveranser er meningsløst. Dette er spesielt der hardware/firmware utvikling er sentralt samt enkelte markeder som av natur gjør store lanseringer av nye produkter (som f.eks spillbransjen).
Tilstand: Her er det enorme forskjeller; jeg kjenner til organisasjoner som har vært “smidige” i tre år og kun har levert en gang i året. Samtidig finnes det organisasjoner i Norge som leverer ukentlig med største selvfølgelighet. Det er nok spesielt innen kontraktsregulert systemutvikling at man fremdeles leverer sjelden.

Det 4. prinsippet tar til orde for daglig samarbeid mellom forretningssiden og utviklerne. Jeg tror mange kan oppnå stor forbedring om man ikke nødvendigvis har kontakt daglig – men prinsippet er godt.
Tilstand: Store forskjeller her og, men spesielt der hvor man driver egenutvikling av IT-systemer er det mange som får til dette. Igjen er det mest å hente i kontraktsregulerte prosjekter.

Det 5. og 6. prinsippet sier at vi må fokusere på motiverte, flinke folk som samarbeider tett og som får tilgang på den infrastrukturen og de hjelpemidlene de trenger.
Tilstand: her er vi blitt ganske gode i Norge! Mitt inntrykk er at de fleste føler at de blir hørt når de ber om bedre utviklingsomgivelser. Når teamene henvender seg til linja som team eller via en Scrum Master så blir de ofte hørt på og behovene tilfredsstilt. Unntak her synes å være de store organisasjonene som har utpreget kostnadsfokus. Distribuerte team er kanskje den største hindringen.

Prinsipp 7 sier rett og slett “Fungerende programvare er det primære målet på fremdrift.” Vel, dette krever jo at man har noe ferdig produkt å vise fram med jevne mellomrom.
Tilstand: I likhet med de tre første prinsippene varierer dette naturlig nok voldsomt. De som kjører kontraktsbaserte prosjekter vil ofte “rapportere framdrift” på en ganske tradisjonell måte.

Prinsipp nummer 8 tar til orde for å jobbe i et jevnt tempo.
Tilstand: De fleste som bruker Scrum har utnyttet dette med ganske stabile team over tid – og mange har sluttet å kjøre småprosjekter for å få ting gjort. Dette lager en fin rytme og stabil framdrift over tid. De som har lengst vei å gå her er nok de med veldig spesieliserte folk og de som jobber i kontraktsbaserte prosjekter.

I prinsipp 9 skal man ha kontinuerlig fokus på “teknisk kvalitet”. Dette henger igjen tett sammen med det å lage noe helt ferdig ofte slik at man får synliggjort og evaluert denne kvaliteten.
Tilstand: Ingen overdrivelse å si at dette varierer kraftig – det er veldig mange som sliter med gammel teknisk gjeld og når de innfører Scrum så blir det helt tydelig at dette smerter. De som er så heldige at de kan få starte fra scratch vil uten unntak (i min erfaring) ha stort fokus på “clean code”, enkelt design, kode-review og lignende tankesett for å addressere dette.

Det 10. prinsippet er “Rema 1000-prinsippet”; “Det enkleste er ofte det beste”. Unngå å lage mer funksjonalitet enn brukerne virkelig trenger. Brukervennlighet. Unngå å lage fancy, generiske komponenter – sørg i stedet for at arkitekturen består av løst koblede moduler som alle lar seg videreutvikle separat.
Tilstand: Igjen, de som er så heldige at de kan få starte fra scratch vil ofte angripe systemutviklingen på denne måten. Men dette problemet synes å leve i beste velgående i større offentlige prosjekter der men over tid har akseptert en voldsom kompleksitet. Når resepten blir et “SOA-prosjekt” er det slett ikke gitt at ting blir mye bedre…

Det 11. prinsippet tar til orde for å jobbe i selvstyrte team – hvilket jo er et krav i Scrum.
Tilstand: Mye står igjen her over hele linja. Selvstyrte team fordrer en ganske voldsom endring i kultur, holdninger og lederstil – hvilket selvsagt ikke skjer over natta. Jeg har sett noen få virkelig selvstyrte team som tar kollektivt ansvar og som har stor myndighet og selvstendighet. Men ikke mange.

Til slutt det 12. og kanskje viktigste prinsippet som handler om kontinuerlig prosessforbedring.
Tilstand: De aller fleste som bruker Scrum har retrospectivemøter som siste gjøremål i en iterasjon. Slett ikke alle klarer å utnytte dette til fulle – her ligger det etter mitt skjønn store gevinster å høste. Igjen er det nok de som har kontraktsbaserte prosjekter som sliter mest med uttellingen. Ikke helt opplagt at det lønner seg å legge sjela si i å forbedre metoder, verktøybruk og arbeidsformer i et midlertidig team i et tidsbegrenset prosjekt..

Konklusjon

Agile Manifesto har hatt en stor påvirkning på IT-bransjen. Ingen ignorerer dette lenger, men det er veldig varierende hvor omgripende endringer man er beredt til å innføre. Vi får jo her bekreftet at organisasjonsendringer nødvendigvis må ta tid. De siste 3-4 årene har det virkelig skjedd mye i Norge og i store deler av verden, men jeg har en følelse av at vi bare så vidt har begynt. Spesielt der man kjører kontraktsbasert utvikling – kanskje særlig innen offentlig sektor – kan man tjene mye på å utfordre prosjekttankegangen og ikke minst å fokusere mye mer på å forenkling, å fjerne konpleksitet og å unngå å pådra seg teknisk gjeld.

Posted on December 30, 2010 at 12:01 pm by gamsjo · Permalink
In: inkrementell utvikling, ledelse, Samfunn, Scrum · Tagged with: , ,

3 Responses

Subscribe to comments via RSS

  1. Written by Vegard I.
    on 14/06/2011 at 11:27 pm
    Reply · WordPress › Error