I min forrige artikkel diskuterte vi hvordan man kan få gjort mer ved å gjøre mindre. Der pekte jeg på de grunnleggende «Waste» i programvareutviklingen. Ved å eliminere disse en etter en, vil du være mye mer produktiv. I tillegg vil budskapet ditt og produktet du lager være mer treffsikker i markedet. I dag går vi litt i dybden på den første Waste: «Delvis gjort arbeid»

Waste #1 «Delvis gjort arbeid» betyr at din organisasjon eller ditt team skifter fokus fra en funksjonalitet/User Story før den er fullstendig gjort/DONE.

Definisjonen av “DONE” inkluderer som regel følgende:

1. Spec review
2. Unit testing
3. Code review
4. Integrasjonstester
5. Dokumentasjon
6. Deployment

«Delvis gjort arbeid» oppstår vanligvis av følgende mulige grunner:

1. Prioritering av kravs/funksjonalitet inn i produkt backloggen skjer uten at man et helhetlig bilde av hvordan dette skal fungere eller at Produkteier ikke har god nok innsikt i markedsbehovet før implementasjonen tar til.
2. For lite tekniske forberedelser av arkitektene som igjen resulterer i ekstra teknisk kompleksitet
3. Avhengighetene mellom forskjellige krav og funksjonalitet ikke er godt analysert
4. Avbrytelser av arbeid som plutselig får lavere prioritet enn det nye kravet

Hvordan eliminerer du «Delvis gjort arbeid»:

1. Prøv å holde en tverrfaglig diskusjon med produkteier og andre interessehavere rundt hvilken verdi vil det nye kravet tilføre produktet.
2. Reduser avstanden mellom Produkteier eller Business Analysten og utviklings teamet. «Nyttestøy» er viktig under implementasjonen.
3. Evaluer arkitektonisk kompleksitet under estimeringsarbeidet. Om nødvendig bør du også gå inn for en vertikal slice/«spike» for å utrede kompleksiteten.
4. Prøv å gjennomføre implementasjonen i et kryss-funksjonelt team der forskjellige faglige roller er representert.
5. Kjør periodisk, gjerne ukentlig, gjennomgang og fintuning av produktbackloggen slik at avhengigheter blir bedre belyst og nye momenter for hvert krav tatt med.
6. Respekter prioriteringen som er gjort og start aldri på en ny oppgave før den som pågår er fullført.
7. Splitt og hersk. Det vil si at oppgavene/taskene som du identifiserer for hvert krav bør være så små mulig. Jeg operer med task-estimater på maks 2 dager. Er estimatet større, så deler jeg oppgaven i to. Er det lite senior-kompetanse i teamet, anbefaler jeg maks-estimatet. På 1 dag.

Er du usikker på hvordan dette kan gjøres i praksis, ta gjerne kontakt så hjelper vi deg og ditt team!