Många av de frågor jag fått genom åren är relaterade till frågan om underhållet och nyutveckling av ett system skall göras av ett team eller om man skall ha två team. I det senare fallet vill man ha ett team som är ansvarigt för underhållet av ett existerande system och ett som utvecklar nya funktioner i samma system. Argumentationen för två team enligt ovan kretsar oftast kring att organisationen provat ett team och då har den mer långsiktiga nyutvecklingen fått stryka på foten när underhåll till kunder som har akuta problem har prioriterats. När de nu har delat det i två team med olika ansvar fungerar det bättre även om man ser andra nackdelar med den lösningen.
Måste vi verkligen ta dessa nackdelar som uppdelning gör? Varför klarar det Agila självorganiserade teamet inte av att prioritera ”rätt” ? Fungerar inte SCRUM och andra agila ramverk? Eller är det så att vi som ledare detaljstyr agila organisationer alltför mycket genom att inte respektera teamet och ger dem korrekta prioriteringar?
Förutom att det bara behövs en chef om det är ett team så är fördelarna många med ett team. En av de viktigaste aspekterna ur mitt perspektiv är att den som utvecklar programvara skall få feedback, och det så snabbt som möjligt, på det som personen utvecklat. Om det är någon annan som hela tiden städar upp i koden efter leveransen till kund får utvecklaren inte den feedbacken överhuvudtaget. Ska en organisationen kunna bygga programvara med allt bättre kvalitet så ser jag endast ett team som alternativ. Det är egentligen här som agil utveckling kommer in i bilden igen. Vid vattenfallsutveckling så tar det ofta många månader innan utvecklaren får feedback på det som gjorts även om de själva står för supporten efter leverans.
Om då en organisation blir alltför kortsiktig i sin prioritering och lyckas lösa detta genom två team vad är då problemet egentligen. Jag anser att det med stor sannolikhet är så att cheferna inte kan hålla sig från att detaljstyra, och tappar långsiktigheten när supportärendena hopar sig, i de fall där de upplever att allt fokus hamnar på de kortsiktiga supportärenden som kommer in. För trots allt är det lika många personer som arbetar och om det fungerar med två team varför inte sätta dessa två team tillsammans? Vem som gör vilken rättning respektive utveckling kan väl inte påverka resultatet. Det måste vara något annat som gör att det inte blir tillräckligt tydlig kommunikation om prioriteringarna. Att dela i två team ger förstås en tydlig signal om hur mycket resurser som skall läggas på support respektive utveckling av ny funktionalitet men det kan väl cheferna tala om utan att dela det på två team? Så grundproblemet är troligen att cheferna inte lyckas kommunicera detta på ett tydligt sätt när det är endast ett team.
Ge i stället teamet tydliga riktlinjer och prioriteringar om vad som är viktigt och hur resursfördelningen skall vara mellan support och utveckling och låt teamet själv organisera sig på bästa sätt för högsta produktivitet. Det viktiga är väl inte vem som gör vad utan att rätt sak görs vid rätt tillfälle.