Under mina dryga 25 år som projektledare inom utveckling av mjukvara har jag sparat på olika minnen relaterat till kommunikation mellan personer. Jag sitter ofta och lyssnar till diskussioner där personerna i diskussionen pratar förbi varandra och enligt min erfarenhet uppstår problem i ett projekt ofta då personer som interagerar inte förstår varandra men tror att de förstår varandra. Detta blogginlägg tar avstamp i dessa observationer och pekar på de fällor man kan hamna i när man skalar upp Agil utveckling.
I Manifestet för Agil systemutveckling är en av punkterna ”Individer och interaktion framför processer och verktyg”. Det säger också att ”Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer.” Som jag ser det är det en balansgång mellan dessa två och det är viktigt att inte hamna åt ena eller andra hållet.
Vi inleder med några exempel på situationer som jag upplevt genom åren. Det första utspelar sig för 15-20 år sedan innan vi där började arbeta med prioriterade krav, ja vi hade prioritering men de flesta krav hade högsta prioritet. En utvecklare hade i den organisationen många ”kravställare” och i ett specifikt fall där det blev många hårda ord i efterhand om att fel saker prioriterades etc gjorde vi en genomgång av hur arbetsuppgifter kommunicerades till utvecklaren. Eftersom detta var före backloggens inträde på företaget kom direktiven/instruktionerna om vad som skulle göras kontinuerligt under arbetsdagen via mail, telefon och besök på rummet hos utvecklaren. Om dessa varit samstämmiga hade väl inte så stora problem uppstått men i detta fallet drog de åt olika håll. Utvecklaren fick inte hjälp med prioriteringen utan han gjorde det som verkade vara viktigast först för man kan ändå inte göra allt samtidigt med resultatet att det blev stormigt. En genomgång av vem som försökte styra honom resulterade i en lista på ca 8 personer. Det var utvecklingschefen, arkitekten, testare, linjechefen, andra utvecklare som behövde hjälp samt linjechefen.
Ett annat typiskt problem är att vi missförstår varandra eftersom vår terminologi är olika. Följande utspelade sig för bara några veckor sedan i ett projekt där jag är projektledare. Diskussionerna var förstås långa men om man sammanfattar dem så pratade en högre chef men en utvecklare så där i förbifarten vid lunchen och frågade om vad han arbetade med. Svaret blev att vi förbereder en leverans. Svaret gjorde chefen förbryllad eftersom han inte förväntade sig en leverans just nu utan först när allt var färdigt och det skulle ske först om flera månader enligt projektplanen. Följaktligen fick jag, som jag uppfattade det, konstiga frågor från chefen och undrade var han fått det i från. Efter den del diskussioner så fick vi klargjort att det där med leverans kan betyda flera saker. För utvecklaren var det leveransklart enligt SCRUM terminologi där vi har som mål att vi efter varje SPRINT skall vara redo att leverera det vi utvecklat medan chefen tänkte på leveransen till kunden.
Misstänksamhet mot att andra inte gör rätt saker och inte förstår vad de borde göra är ofta utbrett i stora organisationer. Om det skall skapas förtroende inom en organisation för att alla gör vad de bör göra för att uppfylla företagets mål måste bakloggen vara transparant. Det räcker inte med att den finns och är synlig utan alla måste förstå den. Det jag såg på Ericsson i 2005-2006 när vi diskuterade införandet av Agila metoder var att man från programledningen misstrodde utvecklarna och inte gillade att man inte visste vem som gjorde vad utan bara att det var ett team eller område som ansvarade. Finns det en utpekad person kan man följa den och diskutera med personen men i en Agil organisation upplevdes det som att utvecklarna kunde göra vad som helst. Här kan den sanna Agila evangelisten protestera genom att säga att programcheferna kan alltid gå på Daily SCRUM mötet men om man har 100-150 team är det inte alltid så lätt att veta var man skal vara och när. Vi lyckades inte heller hitta ett bra sätt att göra dessa mötestider allmänt tillgängliga och koppla dem till enskilda krav osv. Kopplingen mellan roadmapp och de enskilda tasks som utvecklarna jobbade med kunde varit bättre men verktygen fanns inte som stödde detta. Programcheferna var helt klart trygga i att de kunde detaljstyra utvecklarna. Man vet vad man har men vet inte vad man får om man släpper lös utvecklarna. Jag brukar jämföra det med en orienterare som detaljstyrs eller målstyrs. Helt klar använder vi potentialen bättre om vi delegerar mer ansvar till den enskilde. Mer om det i ett framtida blogginlägg.
Vad händer då när vi skalar upp en organisation och arbetar Agilt. Ja, först är det viktigt att tänka på vad det innebär att inte vara ”co-located” som anses som det bästa. Som jag ser det finns det flera olika möjligheter för teamet att plötsligt bli ”distribuerade”. Först och främst förstås att man inte sitter fysiskt på samma plats. Här tänker många på att en person sitter i ett land/stad och en annan del av teamet i en annan. Jag ser dock att det redan blir besvärligt när man inte sitter i samma rum och än värre när man plötsligt sitter i olika korridorer och aldrig stöter på varandra. Redan i den situationen måste man jobba med att få personer att interagera.
Ett annat sätt att bli distribuerad är att man blir distribuerade ur ett tidsperspektiv. I stället för att diskutera F2F börjar man skriva dokument och mail till varandra. Då blir teamet distrubuerat tidsmässigt och plötsligt arbetar man inte samtidigt mot samma mål utan personerna i teamet jobbar med olika mål och drar inte samtidigt mot det gemensamma målet.
Det tredje sättet att bli ”distribuerade” är att personerna i teamet kommer från olika kulturer och/eller har olika modersmål. Det skapar distans mellan personerna och försvårar interaktionen och det är lätt att kommunikationen mellan dem minskar om man inte ser upp.
När en organisation växer är det troligt att alla dessa tre aspekter på distribuerad utveckling sammanfaller.
När vi arbetar Agilt med bara ett team har vi en backlogg som alla arbetar med. Vi får då en strikt prioritering vilket gör det lättare att få alla till att ha samma bild. Det är fortfarande viktigt att alla diskuterar vad det olika backlogg items innebär så att vi inte bara kommunicerar med texter i backloggen. Om vi skulle missförstå varandra så har vi alltid en snabb feedback genom att vi levererar något som produktägaren kan förstå och därmed reds missförstånd ut tidigt och inte efter månader av utveckling. Detta var ett stort steg vi gjorde på t ex Telelogic för att lösa de problem vi hade där utvecklaren själv fick prioritera. Fast alla gillade inte att de behövde ta beslut och ansvar. Det var lättare för produktansvariga att ta med allt som en kund eventuellt ville ha eftersom då hade produktägaren inte missat något.
Att jobba med vattenfall är inte helt fel i många projekt. Gör man det rätt och kravbilden är väldigt stabil kan detta vara ett effektivt sätt att utveckla saker som är förutsägbara. Vi glömmer ibland att Agilt inte är effektivast i alla sammanhang. Problemet med dessa vattenfallsprojekt är ofta inte vattenfallet i sig utan att personer i organisationen slutar prata med varandra och börjar lämna över dokument till varandra utan att diskutera dem. Ungefär som att man har en mur mellan sig. Det kan bero både på att man sitter på olika platser och att man jobbar med sakerna vid olika tillfällen. Det går ofta att lösa om man är medveten om problematiken.
Utifrån detta perspektivet ser jag en överhängande risk i att när vi tror att vi övergår till Agilt arbetssätt så fortsätter att arbeta med dokument utan att diskutera dem med varandra. Vi måste överbrygga distributionen av personerna i projektet genom att främja, eller kanske till och med tvinga, fram interaktion mellan personer.
Hur vill, t ex SAFe, att vi löser uppskalningen av Agila metoder? Det finns många delar men jag vill peka på att det i SAFe finns 4 backloggar. Det är portföljsbackloggen, Programbackloggen, Teambackloggen, dessa tre tolkar jag som att SCRUMs Produktbackloggen delats upp i tre olika, och sedan har vi SPRINTbackloggen. Varje nivå jobbar med sin backlogg och frågan är hur dessa synkas på ett effektivt sätt. Hur ser de som arbetar med portföljen hur projektet ligger till? Är det en virtuell backlogg eller 4 fysiskt åtskilda backloggar som uppdateras manuellt? Att ha allt information i ett Excelark innebär inte att det är en backlogg och ett företag jag pratade med för några dagar sedan kallade det ”Excel hell”. Risken är att var och en arbetar i sin backlogg för att det är enkelt och att man missar att förstå varandras backloggar. Med en gemensam backlogg tvingas folk att förstå vad som står och därmed göra aktiva val. Risken är stor att de som skriver portföljbackloggen förutsätter att de som tar denna information och gör en programbacklogg gör rätt och likadant på nästa nivå.
Hur ser ni att vi kan främja interaktion när vi skalar projekt? Jag ser ett behov av ett verktyg, ACT, som hjälper oss att skapa olika abstraktionsnivåer samtidigt som förändringar på en nivå automatiskt slår igenom på de andra nivåerna. Blir något försenat i ett av 100-tals team skall det flaggas till portföljsnivå direkt så att det kan vidtas åtgärder när det fortfarande finns möjlighet att påverka resultatet och inte när produkten skall levereras. Generellt sätt vill också management kunna göra ”What if”-analyser kontinuerligt, t ex om en kund gör en förfrågan på en viss funktionalitet, kan vi stoppa in det högt i backloggen för att leverera den utan att någon annan leverans riskeras.
Finns då ett ACT verktyg idag? Genom åren har jag tittat på många produkter som säger sig hantera större agila projekt men det bygger på ärendehantering och där finns ett inbyggt problem med att göra om dem till projektledningsverktyg då de inte har arkitekturen för att lösa ovanstående frågeställningar. Till slut har jag dock hittat ett lovande verktyg som jag återkommer med mer information om i ett senare inlägg.