På begynnelsen av dette årtusenet jobbet jeg i konsulentbransjen, i et selskap som var langt fremme når det gjaldt moderne systemutvikling og metodikk. På den tiden forkynnet vi fortreffeligheten ved iterative metoder. Vi snakket mye om Rational Rose og Rup, og kundene både lyttet og implementerte. Og det ga gode resultater

Så fulgte fem år i Microsoft, hvor jeg ikke jobbet med utviklingsprosjekter i det hele tatt. Ikke fulgte jeg med på hva som skjedde i den delen av bransjen heller. Derfor var overraskelsen stor da jeg tok steget over til konsulentbransjen igjen. Metodene hadde utviklet seg voldsomt, og fokuset på produktivitet var stort. Metodene hadde blitt mer detaljerte, mer formaliserte. Men hadde de blitt bedre?

I utgangspunktet jobber jeg med å leie ut systemutviklere og -arkitekter. Og det var det kundene leide dem inn som. Men gang på gang ble de satt til å hjelpe kundene til å få Scrum til å fungere. Veldig mange av dem hadde bestemt seg for å bli simidige, og da var Scrum det naturlige svaret. De hoppet rett på metoden og implementerte den uten å helt forstå hvorfor de gjorde det og uten et klart bilde av hva de skulle oppnå.

En stund lurte jeg på om jeg kunne ha misforstått ordet “Smidig”, fordi det jeg så var alt annet enn en det jeg forbandt med det å være smidig. Og da jeg leste det Smidige Manifest ble jeg enda mer i tvil. Det så ikke ut til å være noen åpenbar sammenheng mellom tankene bak Smidig og de såkalte smidige metodene.

Her er hovedpunktene i det Smidige Manifestet:

• 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

Dette høres fornuftig ut, gjør det ikke?

I tillegg til at det høres fornuftig ut, viser en rekke vitenskapelige studier at de som skrev det smidige manifest virkelig var inne på noe smart. For noen år siden publiserte MIT resultatene av en stor studie rundt hva som gjør noen team mer effektive enn andre. Mer enn 2000 personer var med i studien, og man så på team både på tvers av bransjer og i de samme bransjene. Resultatet var slående. Den faktoren som utgjorde den største forskjellen på hvor gode resulateter et team oppnådde, var måten de kommuniserte på. Det var viktigere enn alle andre faktorer til sammen: alder, intelligens, utdanning osv!

Det som kjennetegner team som oppnådde gode resultater var:

• Alle på teamet snakker og lytter i omtrent like stor grad, og holder sine bidrag korte og konsise.
• Medlemmene ser på den de snakker med, og samtalene er engasjerte.
• Medlemmene tar opp ting direkte med hverandre, ikke bare med lederen.
• Medlemmene snakker seg i mellom, også utenom møter.
• Medlemmene søker informasjon og inspirasjon utenfor teamet.

Her er det mye som sammenfaller med punktene i det agile manifest, ikke sant?

Med tanke på hvor opptatt bransjen vår er av å være smidige, synes jeg det er merkelig at man har klart å glemme kjernen i det agile manifest, og så til de grader ignorere det når vi skal bli smidige. For ha er det som, satt godt på spissen, skjer når en bedrift bestemmer seg for å jobbe smidig:

• Personer og samspill fremfor prosesser og verktøy
  • Vi implementerer en metode og en haug med verktøy vi ikke helt forstår.
• Programvare som virker fremfor omfattende dokumentasjon
  • Vi må minimere antall bugs. Om det faktisk løser den utfordringen det skal, er ikke like nøye.
• Samarbeid med kunden fremfor kontraktsforhandlinger.
  • Smidig er noe vi driver med i utviklingsavdelingen.
• Å reagere på endringer fremfor å følge en plan
  • Det mest vanlige er å lage det man tror brukerne trenger, og heller fortsette å gjette til enten brukerne er så lei at de ikke gidder mer eller til man har flaks og gjetter riktig nok. Jeg kaller dette Antagelsesbasert Utvikling (AU!).

Jeg må bare understreke at jeg ikke mener at det er feil å benytte Scrum aller andre metoder og verktøy. Jeg tror bare man trenger å ha noen annet på plass først. Som en grunnmur for disse metodene. Uten en solid grunnmur, klarer men ikke å bygge et hus som vil stå lenge. Så hva mener jeg man bør gjøre? La meg ta for meg punkt for punkt.

Personer og samspill

• Individer og relasjoner

I stedet for å starte med å implementere Scrum, hva med å fokusere på folkene i teamet og relasjonene mellom dem? Mange tror de driver med relasjonsbygging ved dra ut i skogen og forsere hinderløyper eller lage skuespil sammen. Og jaaaada: Man blir litt bedre kjent med hverandre. Men på en veldig situasjonsbestemt måte.

Hva med å heller sette seg ned og la folk fortelle litt om seg selv? Hvem de er, hvor de kommer fra, familien sin, interessene sine, fremtidsplanene sine, hva som motiverer dem? Jeg har gjort denne øvelsen mange ganger. Det krever veldig lite, annet enn en villighet til å dele litt av seg selv. Og jeg har aldri opplevd at ikke deltakerne har lært ganske mye om hverandre. Selv folk som har jobbet sammen i mange år.

I stedet for å dra på kokkekurs, hva med å heller jobbe bevisst med hvordan teamet lytter til hverandre og snakker med hverandre? Gjør de sitt beste for å forstå hverandre, eller sitter de bare og lytter etter feil? Prøver de å skape gode løsninger gjennom engasjert dialog, eller prøver hver eneste en av dem å vinne diskusjonen. God interaksjon krever både bevissthet og øving.

Samarbeid med kunden

• Tillit og samarbeid

Består teamet av alle de personene og all den kunnskapen man trenger for å lage en god løsning? Er brukere og forretningssiden representert i teamet? Er det engasjert i det som skal lages. Er de som skal drifte det med i prosjektet? Har vi gjort noe for å bygge opp tillit innad i teamet, og tillit mellom team og prosjekteier? Stoler de som betaler for løsningen på de som skal lage den?

Programvare som virker

• Overføring av kunnskap og dialog og kommunikasjon

For å lage gode løsninger, må man overføre kunnskap fra de som forstår domenet og forretningen til de som skal lage løsningen. De som skal lage en løsning, trenger faktisk å forstå domenet bedre enn de som skal bruke løsningen. De skal jo tross alt lage noe som fungerer bedre enn det man har i dag.

For å få til en effektiv overføring av kunnskap, kreves det først og fremst at de rette folkene er involvert i prosjektet. De behøver ikke være allokert 100%, men de må være tilgjengelig for de andre deltakerne. Både ved fysisk sitte i nærheten av de andre i teamet, og ved å ha tilgjengelig tid hver dag for avklaringer og spørsmål.

Dernest må man jobbe for at alle i prosjektet snakker et språk de andre forstår. Forretning må kunne forklare utfordringene på en måte som en ikke-ekspert forstår, og teknologene må lære seg å lytte og stille spørsmål. Alt for ofte går man i kompileringsmodus og lytter etter feil og logiske brister. Ja, på ett eller annet tidspunkt MÅ man det som utvikler. Men man kan kanskje vente til man har fått satt seg inn i problemstillingen? Man må forstå hva som er problemet først, bestemme seg om man skal gjøre noe med det, og så begynne å tenke på løsning.

En annen faktor som ofte ignoreres er hvor kompleks organisasjonen og dens løsninger er. Ofte er det ingen som har full oversikt over hvordan ting henger sammen. Det å skaffe seg et oversiktsbilde av både forretningsprosesser og tilhørende IT-løsninger er en utrolig nyttig men svært undervurdert øvelse. Dette kan både hjelpe forretningsfolkene til å forstå IT-løsningene bedre, samtidig som det hjelper IT-folkene til å forstå forretningen.

Å reagere på endringer

• Evaluering og Evolusjon

Den beste måten å reagere på endringer, er ved å være proaktiv. Ved å så tidlig som mulig få frem forslag til forbedringer og justeringer. For å få til dette må man med jevne mellomrom evaluere arbeidet som er gjort og måten man gjør det på. Man må hele tiden lete etter de små tingene som kan bli bedre.

Skal man lykkes med dette må man sørge for at de som jobber i teamet bryr seg om arbeidet som gjøres og resultatene man oppnår. De må stole såpass på hverandre at de tør å være ærlige. De må ha så gode relasjoner at de tør å være kritiske, også til hverandre.

Noen ganger kommer krav om endringer uventet og i stort omfang, og da er man avhengig av et team som evner å jobbe sammen og få endringene gjennomført. Men i vår verden er det også andre rammer som gjør at vi klarer å gjennomføre endringer. For eksempel løsningens kodekvalitet og arkitektur. Har vi husket å kutte den tekniske gjelden, slik at det faktisk er mulig å gjøre endringer i koden?

Synes du dette høres spennende ut, men at blogposten ikke er nok for at du klarer å gjøre noe med det? Fortvil ikke! Vi har nemlig laget et kurs som kan tilpasses både utviklere, prosjektledere og ledelse.

På kurset går vi gjennom:

• Hva er grunntankene bak Smidig?
• Hva kjennetegner team som leverer ekstraordinære resultater? Hvordan korresponderer dette med det Smidige Manifest?
• Hva kan du gjøre for å bli mer smidig og oppnå bedre resultater? Vi vil gi deg en innføring i teorien bak, og et sett med oppgaver og øvelser som vil hjelpe deg og organisasjonen din på vei.
• Hvilke rammer skal til for å lykkes med å jobbe bedre sammen? Alt løses ikke med smidig. Hvilke andre rammer bør være på plass?

Hvis du er interessert, kan du ta kontakt via kjell@webstep.no.

Kategorier:Organisasjon

Tagged as: prosjekt relasjoner smidig

kljostad