LAGARBEID: I smidig metodikk kreves det mye av medarbeiderne. Her er en liste med faresignaler som hinter om at endring av lagoppstillingen kan være påkrevd for å lykkes. (Foto. iStock)

Tydelige tegn på at teamet ikke er smidig

Prosjekter som bruker smidig metodikk kan gi store resultater, men det krever de riktige deltakerne.

Publisert Sist oppdatert

Smidige prosjekter betyr tett samarbeid og svært raske runder med tilbakemeldinger. Når det fungerer blir brukernes forventninger knyttes tett til sluttresultatet av prosjektet, og svært lite tid blir kastet bort på kjekt-å-ha funksjoner eller perfeksjonisme som ikke påvirker forretningen. Når smidig gjøres riktig, er det vakkert, og på toppen av det hele økonomisk.

Samtidig avhenger smidig produktivitet på kvaliteten til prosjektdeltakerne. Det kreves høy IQ, høy EQ og tydelig fokus. Settes noen inn med utilstrekkelig ekspertise, gjennomføringsevne eller beslutningsevne, vil teamet raskt løpe rundt i ringer.

I tillegg krever smidige metoder at det er liten motstand mellom ressurser og oppgaver: Om et teammedlem rett og slett ikke bryr seg, eller ikke tåler å være i samme rom som et annet medlem av prosjektet, kommer tett samhandling ganske enkelt ikke til å skje.

Vurder deltakerne

Ettersom smidig utvikling handler om fleksibilitet og raske iterasjoner, er det rimelig at du også vurderer deltakerne i den smidige prosjektgruppa så tidlig og ofte som mulig, for å oppdage og korrigere problembarn. «Fail-fast», altså stans opp og erstatt den feilende komponenten, er en beste praksis når det kommer til bemanning av teamet.

Dersom zen-buddhistenes uttrykk «Hvordan du gjør noe er hvordan du gjør alt» er sant, burde det være mulig å oppdage problemer med teamdeltakerne før den første sprinten er fullført. Ideelt sett burde du gjøre det før den første sprinten har startet, men hvordan?

Fire hovedområder i smidige team

Dersom det er en god ting med karakterbrister, så må det være at eieren av bristen sjelden erkjenner at vedkommende har den. I tillegg er bristen ofte åpen for alle å se, du må bare vite hvor du skal se etter. I de fleste smidige team er det fire hovedområder som trenger særlig ettersyn: Brukerne, utviklerne, konsulentene og administrasjonen.

Her er førti hint i ingen spesiell rekkefølge som må heise et rødt flagg om vi ser dem i smidige team.

1: Brukere som...

  • Ikke er engasjert, interessert eller motivert. De er for travle med sin vanlige jobb til å delta på skikkelig vis.
  • Har uvilje mot å eie problemer, tiltak, eller tidsfrister. De er generelt uvillige til å sette navnet sitt bak noe som helst, særlig formelle krav, valideringerog testløp.
  • Betrakter risiko, endringer og læring som problemer, ikke som ingredienser.
  • Unngår å påta seg tiltak og tidsfrister, som er allergisk mot oppfølging.
  • Viser tendenser til skyldfordeling og bruker tid på å dekke sin egen rygg.
  • Er høylytte om hva de vil ha, men som er uvitende om realitetene i utvikling; som antar at den inkrementelle konstnaden for et ønske er null.
  • Synes å legge til forsinkelser og tvil til de fleste beslutninger, som hater å komme til saken og som er uvillig til å skjære gjennom.
  • Fyller møtene med mangelfulle betraktninger, og som tenderer til å blåse opp klart avgrensete problemer til uløselig store saker.
  • Er uvillig til å handle basert på ufullstendig informasjon, og som alltid forsøker å helgardere seg.
  • Lider av ADHD eller har manglende evne til å lese eller skrive noe som helst med substans.

2: Utviklere som...

  • Er uvillig til å forfølge grovhugde løsninger.
  • Lider av perfeksjonisme.
  • Overfokuserer på arkitektur og lengelevende programvare.
  • Fokuserer mer på å unngå kritikk enn å få programvaren ut.
  • Er altfor villig til å kode først og stille spørsmpl etterpå.
  • Har dårlig evne til kommunikasjon, særlig under press og stress.
  • Hater, eller mangler empati med sluttbrukerne.
  • Mangler evnen til prosjektledelse eller har en leder som heller ikke mestrer det.
  • Er redd og ubesluttsom.
  • Mangler evnen til å lytte.

3: Konsulenter som...

  • Er desperate etter å vinne en avtale eller holde på en kunde. Tips til kunder: Gjør et intervju om tilbudet med konsulentenes tekniske direktør.
  • Er for fleksibel, for ettergivende, er villig til å gi forpliktelser de strengt tatt ikke kan overholde. Tips til kunder: Se opp for kulturforskjeller.
  • Ikke er i stand til å overbringe dårlige nyheter raskt of effektivt.
  • Ikke er i stand til å si nei, og stå ved det.
  • Er uvillig til å ta ansvar i en usikker situasjon.
  • Ikke er i stand til å lytte.
  • Er uvillig eller ikke i stand til å svare på forespørsler den samme dagen. Tips til kunder: Krev en SLA.
  • Er «ja-menn» eller ikke er i stand til å bidra.
  • Fokuserer for mye på rask koding og mengden av produsert kode, og for lite på å bygge det riktige.
  • Er uvillig til å være på lokasjonen – eller i det minste i samme tidssone som resten av teamet.

4: Administrasjon som...

  • Er uvillig til å delta aktivt i prosjektet, i tillegg til å kjempe for det.
  • Er overdrevent opptatt av kommando og kontroll, som krever at alle beslutninger skal eskaleres opp til sitt nivå, som er uvillig eller ute av stand til å stole på og virkelig delegere ansvar.
  • Er mer fokusert på budsjett enn på verdi. Som er overdrevent interessert i smalt definerte måleverdier og har begrenset oppmerksomhetsspenn på de bredere målsetningene.
  • Viser symptomer på ADHD eller som har problemer med hukommelsen.
  • Er villig til å forfremme noen som egentlig ikke har god kjennskap til området, og som heller ikke er interessert i å lære det.
  • Oppfrordrer til hard konkurranse mellom delene av prosjektet, slik at lederne har klare insentiver til å underby hverandre på budsjettene, overdrive leveringsevnen og spille spill med milepælene.
  • Holder folk ansvarlige uten å gi dem myndighet over ressurser.
  • Bruker frykt som et styringsverktøy, og straffer fiaskoer offentlig.
  • Er uvillig til å sette utvetydige prioriteter, sette realistiske tidsfrister eller erkjenne konsekvenser av valg; uvillig til å skille signal fra støy.
  • Under avtaleforhandlingene legger til urealistiske krav eller asymmetriske risikoelementer.

Bunnlinjen

Det finnes ikke noe poengsystem her, men om du oppdager tilstrekkelig mange av elementene vi har nevnt over i noen av prosjektdeltakerne, så er det på høy tid å vurdere om vedkommende skal byttes ut, og det raskt. Om du finner mange nok av problemene nevnt i seksjonen om administrasjonen, så er det ikke sannsynlig at smidig utviklingmetode kommer til å bli en suksess i den delen av organisasjonen.

Denne artikkelen er opprinnelig publisert på cio.com. Den er oversatt og bearbeidet av Stig Øyvann.