Et utviklingsteam må ha et forhold til hvilke oppgaver de skal fokusere på: rette feil, teknisk gjeld eller ny funksjonalitet?
Når vi lager ny funksjonalitet bør vi vurdere: Bør noe skrives om før vi kan begynne å implementere funksjonaliteten? Er det "godt nok", når funksjonaliteten er på plass, eller er det mer som bør gjøres?
Min erfaring er at når jeg jobber på en oppgave, så dukker det opp nye potensielle oppgaver. Man har en esende yak-stack – en voksende liste av ting som må ryddes unna før man kan komme i gang med den egentlige oppgaven Dette kan være kilden til mye usikkerhet, møtevirksomhet, uenighet og antakelser. Ikke bra. Mitt tips er at teamet (eller utvikleren) selv spør seg selv: "Does it spark joy?"
Klø tilbake
Ryddekjendisen Marie Kondo har en enkel måte å avgjøre om noe skal beholdes, eller kastes/gis bort. Hun stiller spørsmålet: "does it spark joy?". Vi har brukt samme metode for å avgjøre hvilke oppgaver som skal gjøres, og hvordan de skal fordeles.
- Er byggepipeline er treg?
- En del av koden er uforståelig?
- Gammel del av kodebasen bør oppgraderes eller skrives på nytt?
Ofte lærer en seg å leve med slike problemer. Eller man lager kanskje en JIRA-sak og legger den i backlog slik at vi kan løse problemet når vi har ledig tid. (Du vil ikke få ledig tid.)
Noen ganger er det slik at én på teamet som brenner for en av disse kjedelige, hårete oppgavene. Han har løst et liknende problem før, eller vet hvordan det bør se ut. Inspirasjonen (noen ganger raseriet) flammer opp i korte øyeblikk og utvikleren har lyst til å sette i gang. Disse øyeblikkene bør teamet gripe fatt i!
Utviklerne kjenner selv hvor det klør og hva som bør jobbes på.
Når kløen på en slik oppgave melder seg, så bør teamet normalt bare sette i gang. Er oppgaven liten og ikke forbundet med stor risiko? Bare sett i gang! Hopp over estimat, planlegging og roadmap. Ta et kort avklaring med teamet, og sett i gang.
Hvis lidenskapen skal vente til etter oppgaven har blitt diskutert, definert, estimert og planlagt, dokumentert så er øyeblikket for lengst passert. Oppgaven som var konkret, overkommelig og krystallklar i utviklerens hode har begynt å forsvinne. Når oppgaven etter hvert kommer opp på radaren så har øyeblikket passert. Inspirasjonen er forsvunnet. Kanskje utvikleren som brant for idéen ikke lenger jobber der.
Ja, men
Jada, det er satt på spissen; vi bruker hodet også. Vi gjør ikke dette når:- noen venter på et reelt viktig forretningsmål
- før en kjempeviktig deadline.
- en fersk utvikler påtar seg å gjøre noe stort og risikabelt
Superkraft
Vi må trå til mens inspirasjonen er der. En inspirert utvikler som jobber på en engasjerende oppgave er mye mer produktiv enn samme utvikler som jobber på en "vanlig" oppgave.