Henrik Kniberg gav ett föredrag om storskalig agil utveckling nyligen, och av döma av sammanfattningen på InfoQ (se länken) så var det ett bra föredrag med observationer som är helt i samklang med mina.
Jag gillar särskilt att han trycker på att man måste förstå varför man skalar. Storskalig agil utveckling är inget eftersträvansvärt. Om en liten grupp människor oberoende av omgivningen kontinuerligt kan leverera nyttigheter som möter människors behov så är det att föredra. De storskaliga teknikerna tar vi till när vi måste koordinera fler än en handfull personers arbete och/eller nyttigheterna tar lång tid att leverera.
Det kluriga är alltså hur teamen kan hålla sig i synk med varandra och hålla ordning på beroendena mellan dem. Henrik pratade om tre grundläggande frågeställningar man behöver ha svaren på:
- Hur man bryter ner det arbete man ska göra ("slicing the elephant").
- Hur man bör organisera arbetslagen (ta reda på vilka människor som bör göra vad).
- Vilka återkopplingar ("feedback loops") som behöver finnas för att koordinera arbetet.
Det är en konkret lista som matchar observationen att man först behöver ta reda på vad man ska göra innan man börjar fundera på organisationsformer och samarbetsmetoder (se Jim Womacks 3P).
Kruxet när man hanterar skalning är att det hela tiden är fråga om avvägningar, något som Henrik också trycker på. Om vi organiserar arbetslagen på ett sätt kommer behovet av återkopplingarna bli ett. Om vi organiserar arbetslagen på ett annat sätt kommer behovet av återkoppling bli ett annat.
Henrik påmminer om att det alltså därför inte kan finnas något rätt eller fel, utan varje organisation måste hitta sina avvägningar utifrån sina behov. Man kan inte hitta ritningar som automatiskt passar flera.
Det jag stannar upp inför är den svåra frågan om hur man fördelar ansvar mellan team. Man kan organisera sig utifrån lösningens bakomliggande komponentstruktur, men det betyder att varje levererad nytta (som ju sker i ett samspel mellan lösningens komponenter) kräver stor koordination mellan komponentteamen. Det är min och hela branschens observation att om det är möjligt ska man istället skapa team som inom sig själva kan leverera hela nyttor (sk "feature teams").
Men i organisationer som har en tillräckligt komplex miljö går det inte att sätta samman team som klarar av att leverera hela nyttor. I de enkla fallen, som i Henriks exempel med en trelagersarkitektur (klient, server, databas) är det förstås möjligt. Men om plattformen är krångligare än så? Teamen blir då antingen för stora, eller så blir de inte stabila utan behöver göras om inför varje ny nytta.
Vi kan sikta på att hålla nere antalet team som krävs per nytta, men det kommer ändå att uppstå ett behov av att för varje sak man gör koordinera mellan åtminstone två team, dvs situationen blir precis som den som Henrik varnar för (se bilden med det ledsna ansiktet vid "Coupled teams"). Det är trögt att få till agilitet i den situationen.
Men det går! Man kan använda smidiga synkroniseringstekniker som gör ansiktena betydligt mindre ledsna, och i de organisationer där jag har ramlat på den här situation har vi använt dem med någorlunda framgång. På samma sätt som smidiga tekniker får individer att jobba bra ihop i team kan smidiga tekniker få team att jobba bra ihop i olika och växlande konstellationer.
En del av de teknikerna utgår från det som Henrik visar i bilden om hur team kan synka med varandra. Organiserar man sig utifrån mönstret "Team of small teams" man man skapa stabila samverkansformer mellan teamen som tar bort en del av synkroniseringssmärtorna. Min erfarenhet är att samma tekniker med framgång kan användas om man organiserar sig i "Team of team of small teams" eller "Web of team of small teams". Det som krävs är en synkronisering på övergripande nivå där organisationen kan ge klara besked om syfte och prioriteringar, så att alla teamen vet vad de ska sträva efter.
Inga kommentarer:
Skicka en kommentar