Siden jeg begynte som utvikler i 2006 har jeg hørt snakk om forskjellige smidige arbeidsmetodikker. Jeg har jobbet i forskjellige avarter av Scrum og Kanban, kombinasjoner av disse, og helt andre metodikker.
Det som alltid har kjennetegnet arbeidsflyten har vært at man ikke følger noen av metodikkene slavisk, men plukker ut de delene man ønsker og som passer situasjonen man står i. Vanligvis standardiseres det i tillegg på tvers av teamene, slik at det skal bli lettere for ledelsen å få oversikt over progresjon, eller mangel på sådan.
«Problemet der var at ledelsen ikke klarte å slippe taket.»
I en tidligere jobb jeg hadde var det derimot en veldig dyktig teknisk leder som snakket varmt om det han kalte for et selvorganiserende team. Teamene skulle få bestemme mer selv, og de skulle få ta ansvar. Autonomi var nøkkelordet.
Problemet der var at ledelsen ikke klarte å slippe taket. De følte at de mistet kontroll og ikke klarte å rapportere fremdrift og forventet leveringstid til kundene. De fikk derfor en del føringer for hvordan de skulle jobbe, hvilke verktøy de skulle bruke, og hvordan disse verktøyene skulle brukes.
Det ble mye estimering, planning og retros, og mindre tid til produktutvikling. Smidigheten forsvant som dugg for solen.
Hva er behovene vi skal løse?
Da jeg for noen år siden fikk muligheten til å starte helt fra scratch med et nytt produkt og ansette mine første teammedlemmer, så jeg en gylden mulighet til å gjøre ting annerledes, med et selvorganiserende team.
Med meg selv som team lead og etter hvert tre andre utviklere og en fagekspert på teamet, jobbet vi sammen for å definere hva produktet måtte ha av funksjonalitet og hvilke lover og regler vi måtte forholde oss til. Alle ble hørt.
Spørsmålet vi stilte oss var “Hva er behovene til kunden som vi må løse?”. Ofte var svaret langt og komplisert, så vi måtte bryte det ned i mindre bestanddeler.
Når det var gjort måtte vi finne ut hvor vi ville begynne. Selv om man hadde forskjellig kompetanse og forutsetninger, var det viktig at alle bidro i diskusjonen, om det var fag, brukeropplevelse eller av mer teknisk art.
Selv på oppgaver som vanligvis tilfaller en produkteier eller prosjektleder.
Unngår hjemmekontor
Denne måten å jobbe på gjør at teamene tar mer ansvar, tør å eksperimentere og viser initiativ. Samtidig krever det at alle føler seg trygge, og at teammedlemmene har gode forhold seg imellom.
I gjengjeld føler teamet eierskap, noe som gir motivasjon og lyst til å være med å drive produktet videre.
Vi fokuserer derfor mye på samarbeid på kontoret, og forsøker å unngå utstrakt bruk av hjemmekontor. Det er lettere å “bonde” når man snakker sammen ansikt til ansikt, møtes ved kaffemaskinen, og kan diskutere ting rundt en whiteboard.
Det er ikke noe revolusjonerende i denne måten å jobbe på, men det er summen av alle de små grepene som gjør at det funker så bra for oss. Det viktigste er at vi tror at produktene våre blir bedre ved å jobbe på denne måten.
– Kjære tech lead: Jeg håper du innser at du er essensiell!
Krever mye tillit
Vi har nå flere selvorganiserende team, og ingen setter strenge føringer for hvordan noen av teamene skal jobbe. Det finner de ut av selv, og det er til dels store variasjoner.
Det som går igjen er at de får frihet og ansvar, samtidig som de får noen føringer for hva som forventes. Dette kan være tidsfrister, men også på overordnet funksjonelt nivå.
Slik frihet krever mye tillit, men fostrer eierskap, engasjement og innovasjon. Ledelsen vet at det tar tid å lage kvalitetsprogramvare.
De vet også at den beste måten å få det på, er ved å la utviklere, UX-eksperter og fagfolk slå hodene sammen.
De får kanskje ikke det de forventet, men ofte noe som fungerer enda bedre for kundene våre.
