ga('send', 'pageview');
Categories
Metod

Överlämningar förvandlar agilt till minivattenfall

I en mognande mjukvarubranch med hårdnande affärsklimat framstår innovation och samarbete som allt viktigare konkurrensmedel. Många agila avdelningar arbetar fortfarande med vattenenfallsöverlämningar och utnyttjar bara en bråkdel av sin potential. Jag ska visa hur ni med enkla medel kan få ut mycket mer av er organisation!

 I en mognande mjukvarubranch med hårdnande affärsklimat framstår innovation och samarbete som allt viktigare konkurrensmedel. Många agila avdelningar arbetar fortfarande med vattenenfallsöverlämningar och utnyttjar bara en bråkdel av sin potential. Jag ska visa hur ni med enkla medel kan få ut mycket mer av er organisation!

“Ready for test” dödar kommunikation

Organisationer med brist på kommunikation kännetecknas av fasta roller och överlämningar på “tavlan”, mer specifikt i kolumnen ”Ready for test”. De team som sätter väldigt stort värde på denna kolumn ser ofta testarna som slutgiltigt ansvariga för produktens kvalitet. Detta slutgiltiga ansvar särskiljer testarna från övriga i teamet, bland annat programmerarna. Det har skapats två olika grupper där den ena granskar och den andra skapar.

minivattenfall-1024x768

Beställningar går ofta till de som skapar och testarna som granskar hamnar sist i informationskedjan. När test hittar fel pratar de med programmerarna som rättar och om rättningen påvisar luckor i kraven blandar man in produktägarna. Ett vattenfall i miniatyr har bildats.

Minivattenfallets problem

Minivattenfallets allvarligaste problem är att tid investeras i implementation innan tillräcklig kunskap hinner bildas. Överlämningar mellan programmerare och test via tavlan ger en väldigt långsam och tunn kommunikationskanal som ger dåliga möjligheter för teamet att skapa sig en bra uppfattning hur de skall utveckla sina user stories. Ofta upptäcks felaktigheter som påverkar produkten negativt efter att en stor investering redan gjorts. En del av dessa felaktigheter påverkar produktkvaliten negativt i det långa loppet men rättas ändå inte till då mycket annat också måste hinnas med att levereras.

Funktionen plockas heller inte bort eller senareläggs p.g.a. den investering som redan gjorts, utan följer med ut i produktion för att rättas till senare. Om detta beteende upprepas ofta med fel som läggs på hög leder det i slutändan till en allt mer osammanhängande produkt som blir allt svårare att utveckla. Teamet bygger en skuld som någon måste betala av. Bryts inte detta beteende och skulden betalas av finns det stor risk att produktens konkurrenskraft ebbar ut på grund av att det blir svårare och svårare att utveckla ny funktionalitet samtidigt som användarna möts allt flera fel.

Mycket överlämningar gör också att teamdynamiken blir lidande. Varje överlämning gör att arbetsfokus avbryts och ändras, sker detta ofta leder detta till frustration inom teamet och markant nedsatt effektivitet.

Rik kommunikation gör att team lyckas

Jag ser en tydlig skillnad mellan team som lyckas riktigt bra i sitt tvärfunktionella arbete och team som inte gör det. Team som lyckas bra präglas av rik kommunikation kring mål och produkt.

Rik kommunikation uppstår när flera parter blandar sin kunskap så att de kan lösa problem på ett bättre sätt än vad de klarar av på egen hand. Team som saknar rik kommunikation tar inte hjälp av varandras styrkor och kommunicerar istället kring överlämningar.

Det är viktigt att understryka att team kan lyckas bra utan rik kommunikation, men min uppfattning är att team blir är mer tillfredställda och får mer gjort med. Ett bra exempel på rik kommunikation är när tvärfunktionella team tillsammans bygger kunskap, arbetar snabbare och med bättre kvalitet än vad varje enskild individ klarar av.

Synergerande team

Team som lyckats bryta minivattenfallen har gjort det när hela teamet tagit på sig kvalitetsansvaret och teamet samarbetar intensivt för att mycket snabbt skapa en gemensam bild över hur deras user stories skall implementeras och kvalitetssäkras. Ett sätt som hjälper teamet att ändra på sitt rolltänkande är lägga till ett “Designmöte” som det första steg en User Story behöver genomgå för att få utvecklas. Det kan vara en lapp per User Story, kolumn på tavlan eller annat sätt som fungerar bra med er process.

Förslag till “Definition of done” på designmötet är att de tvärfunktionella delar av teamet som kommer att jobba på User Storyn vet hur funktonaliteten skall användas, acceptenskriterier, hur den skall testas, vilket testdata som krävs, hur den ska implementeras och eventuellt automattestas.

Teamet bör även kommit överens om vad som ska göras och på vilket sätt det ska testas av både utvecklare och testare. Det gemensamma kvalitetsansvaret gör att testarna får mer tid över till annat, såsom till exempel utforskande testing, prestandatester och vidareutveckling av automatiska testsviter. Samarbetet gör att det blir färre avbrott på grund av överlämningar och en större del av tiden kan läggas på värdeskapande.

En effekt är att kortast möjliga time to market minskar då teamet fokuserar på att göra klart en funktion i taget. Rik kommunikation gör också att produkten blir mer genomtänkt och att det blir lättare att bygga in en högre kvalitet, vilket ökar produktens värde i det långa loppet.

Jämförelse i praktiken

Mjukvaruutveckling är ett kunskapsintensivt hantverk där stora vinster kan göras ifall utövaren har god kännedom om vad som skall utvecklas, eller som snickaren säger “Mät två gånger, såga en”. Huvudsyftet med rik kommunikation är skapa kunskap så att det första snittet blir så bra att det förbättrar produkten utan ökad skuld. Bilden visar hur en funktion i utveckling går igenom tre värdestadier.

Funktioner i stadie ett är värdelösa då de antingen saknar väsentlig funktionalitet eller har så allvarliga brister att de är inte releasebara. Funktioner i stadie två är releasebara men innehåller brister som gör det svårare att utveckla applikationen i framtiden. Släpps mycket funktionalitet som är i stadie två läggs bristerna på hög och bildar en skuld. I stadie tre är funktionaliteten så utvecklad att den gör det enklare att underhålla applikationen i framtiden.

userstorystadier_opt

Rik kommunikation hjälper teamet att tidigt skapa sig en bra uppfattning för hur en feature skall fungera väl ihop med produkten. Med minivattenfall dröjer förståelsen och risken är stor att tiden tar slut innan funktionen hunnit utvecklas utan skuld. Det är förrädiskt lätt att bortse från den skuld man drar på sig i det korta perspektivet men i längden avgörs produktens framtid av hur skuldbelagd den är.

 

Praktiska tips för att bryta vattenfallet

  • Teamet måste ha goda möjligheter att jobba utan avbrott som teamet behöver hjälp från en långsam yttre värld för att avhjälpa. All information och alla personer som berörs bör vara mycket tillgängliga för teamet under själva arbetet.
  • Teamet måste förstår intentionen (so that… delen) med sina user stories. Kommuniceras inte detta med krav, diskussioner och delaktighet har teamet minskade möjligheter att förbättra produkten på bästa sätt.
  • Fuska inte med designmötet. Ofta är det ett givande rutinjobb som ger möjligheter till andra mycket värdefulla metoder som t.ex. automatisk regressionstestning. Ibland är det svårt att se hur en funktion skall passa in med den övriga produkten och se hur detta skall testas. Denna svårighet är ett tydligt tecken på att funktionen kommer att vara både långsam utveckla och att den i nuläget innebär en hög risk för ytterligare skuld. Senarelägg hellre funktionaliteten tills dess att den är redo att utvecklas och satsa istället på att utveckla det som är redo.
  • Om det är svårt att få till ett bra designmöte kan testakronymen SFDPO hjälpa. Gå tillsammans igenom struktur, funktion, data, plattform och operation (användning) och bestäm vad som kan automattestas, vilka positiva och negativa funktionstester som bör göras och vad som bör testas utforskande.
  • Var observant på om teamet börjar byta mellan tasks för att “inte förlora tid”. Detta kan bero på att designmötet varit otillräckligt eller att teamet inte har tillgång till de resurser som krävs för att utveckla på ett effektivt sätt.
  • Observera ready for test kolumnen. Ju bättre teamet blir på att ta gemensamt ansvar desto färre lappar kommer att hamna här.
  • Rik kommunikation sker inte enbart mellan programmerare, testare och produktägare. Alla som berörs av en produktförändring är viktiga för att skapa den helhetssyn som leder till bra lösningar. Sköts deployförfarandet av en it-avdelning så inkludera dom också. Hur ser det ut med UX? Vilka andra berörs?
  • Kom ihåg att rik kommunikation kräver energi och engagemang för att ta fart. När den väl är på plats ger den igen både energi och engagemang mångfalt – kämpa på, lär och ge inte upp!

Med enkla medel

Ett enkelt möte räcker för att bryta ett oeffektivt beteende och istället få igång rik kommunikation. Rik kommunikation visar ofta på många förbättringsmöjligheter som leder till en positiv spiral och kostar bara genuint intresse, engagemang och förtroende. Precis som det borde vara.

 

Leave a Reply

Your email address will not be published. Required fields are marked *