Hörni boken Team Topologies av Matthew Skelton och Manuel Pais har öppnat ögonen på mig för hur vi bör designa mjukvaruteam och dess omgivning. Boken talar om vikten av rätt teamstorlek (Dunbars number) och sammansättning (T-shape) och det är inget nytt. Vidare att vi måste minska vår kognitiva last (färre bollar i luften) så att vi kan fokusera på rätt saker. Och att inse att vi är hämmade av Conways lag (de system vi bygger är ej bättre än vår kommunikations design) när vi designar teamens omgivning. Men det jag tar med mig är hur boken visualiserar de fyra olika teamtypernas beroenden mellan varandra och hur vi delar upp dessa beroenden på tre olika kategorier. Läs mer här. Detta ger en bra grund för att sedan börja inventera vår organisations beroenden, som i grunden är onda och gör oss långsamma, ofta med överlämningar mellan team. När vi väl är medvetna om dessa beroenden kan vi sedan hantera och i bästa fall eliminera dem.
Beroenden är en teamsjukdom.
/Ove Holmberg
Med denna bok i tanken så vill jag rikta strålkastaren mot beroenden som är skälet till att vi ständigt hakar upp oss i kolumnen “hold”. Där ligger arbete och gonar sig vecka efter vecka utan att någon bryr sig. Om man vill ha flow i sitt system och producera så bra grejer som möjligt på så kort tid som möjligt måste man se över sina processer. Jag hävdar att arbete idag ligger 90% av tiden i hold kolumnen. Jag har med framgång tillämpat en egen process på att få högre flödeseffektivitet som bygger just på ovan nämnda bok men som adderar delar jag saknar, som en tydlig process inkluderande prioritering av beroenden. I korta drag har processen 6 steg och bör itereras så ofta som möjligt och varför inte ett steg per sprint i en kvartalspuls (Program Increment)?
- Inventera (Find). Börja med att brainstorma er fram till alla aktörer som har förväntningar på oss och som vi samarbetar med runt vår organisation/team. Sätt upp dessa på en whiteboard med post-it med organisationen i mitten, som ett universum med planeter. Analysera er kanban brädas ”hold” kolumn för ytterligare beroenden. Dra sedan streck från/till respektive aktör och spar bilden som blir input till vidare arebete. Analysera sedan flaskhalsarna, hur ser dom ut och hur allvarliga är dom? Och framför allt vilka är aktörerna (stakeholders) som har ömsedidiga förväntningar på varandra. En beroendebacklog är född. Ladda hem mallen här där detta steg motsvarar den blåa delen.
- Hantera (Agree). Tag kontakt med de andra teamen och de aktörer som är Era flaskhalsar. Sätt er ner och diskutera ömsesidiga förväntningar på varandra och dokumentera dessa. Skriv t.ex. en sida på er Wiki om “avtalet” och om det kräver att vi skapar stories i Jira, säkerställ att vi är överens om hur kriterier för bra förväntningar ser ut (INVEST) samt klarkriterier (DoD/DoR) för dessa. Sätt upp mål för förbättring som vi följer upp i steg 4. Detta steg motsvarar den gröna delen i mallen.
- Eliminera (Minimize). Går beroendet att automatisera eller helt byggas bort? Kan vi bygga team APIer som utan väntetid löser våra ärenden? Kan våra möten ersättas med förtroende? Kan vi delegera? Kan vi lära oss från experterna hellre än att experterna gör jobbet varje gång? Er effektivitet är inte bättre än er svagaste länk – börja där och jobba er nedåt i Er beroendebacklog. Detta steg motsvarar den orangea delen i mallen.
- Följ upp (Inspect) från inventeringen nu när ni har gjort åtgärder. Har vår flödeseffektivitet ökat? Om inte gå tillbaka till steg 2.
- Lär ut (Learn) Nu har ni koll på era beroenden men hur har övriga team det? Hjälp dessa på traven med samma process. Nu blir det intressant att se mönster tvärs över teamen och göra rotorsaksanalyser.
- Fira (Yes) era framsteg tillsammans med era beroenden som nu heter partners, innan ni börjar på nästa varv. På det andra varvet kanske ni vill ta hjälp av någon (coach) som inte var med på det första varvet för att få nya perspektiv?
- Undantagen. Likt fotbollens regel 18 (sunda förnuftet) och den 13e agila principen (det beror på) så har även denna model en sjunde del. Kritiskt granska modellen och låt er inte luras av listiga bokstavslekar. Och framförallt ha färre steg och iterera oftare och ge modellen ett nytt namn.
Med denna process i land kan ni kan ni planera mera träffsäkert tvärs över alla team.
Häng gärna på vår bokcirkel här för att djupare gräva ner oss i ämnet
/Ove Holmberg