Uppskalning av agila metoder- Del 4: Kom så nära idealet som möjligt givet din situation

I tre tidigare delar har jag presenterat strategier som egentligen undviker frågan om det går att arbeta agilt i riktigt stora projekt. Betyder det att jag menar att det inte går att vara agil och stor på samma gång? På sätt och vis är det självklart så. Det behövs bara några enkla exempel för att visa det: En supertanker svänger inte lika snabbt som en motorbåt. En stor armé kan bli besegrad av en liten rörlig rebellstyrka. Stora företag som inte hänger hänger med i den kommande teknikgeneration blir omsprunget av hungriga uppstickare.

Men på ett annat sätt inte så. Det finns ett ställe dit storföretagsmentaliteten aldrig kan nå: Din egen hjärna. Du kan fortfarande tänka agilt. Det kan vara din grundläggande attityd. Om du har en agil grundinställning menar du att det finns primära faktorer som bestämmer om du är framgångsrik eller ej, till exempel vilka individer du jobbar med och hur bra feedback du får, och du eftersträvar alltid att maximera dessa.

* * *

Låt oss ta en ledande fråga: Om vi antar att du har en agil attityd och du därför vet att kommunikation är väsentligt och sedan sätter du upp ett stort, distribuerat projekt med alla dess kommunikationsbarriärer, borde du då fokusera mindre eller mer på kommunikation?

Mer, förstås!

Om omständigheterna gör det svÃ¥rt för oss att kommunicera mÃ¥ste vi kämpa ännu hÃ¥rdare med det. Gör vi det svÃ¥rt för oss att samarbeta med kunderna mÃ¥ste vi fokusera ännu hÃ¥rdare pÃ¥ det. Är det ett svÃ¥rt arbete att fÃ¥ till ett färdigt leveranspaket varje tisdag mÃ¥ste vi… Ni fattar. Den här extra ansträngningen är helt enkelt priset vi fÃ¥r betala för att vi har valt att organisera oss pÃ¥ ett ineffektivt sätt.

Titta på agila manifestet. Titta på det som står till vänster. Den som tror på agila metoder menar att det som står till vänster är viktigare för att lyckas än det som står till höger. Det är ingen slump att det som händer i stora projekt är att man reflexmässigt ökar allt det på höger sida: Processer, dokumentation, striktare kontrakt, mer detaljerade planer. Visst kan det finnas en poäng att lägga ner mer tid på ett stort kontrakt, men mycket viktigare för att lyckas är att fokusera än mer på vänstersidan. Man kan också uttrycka det så här: Agila värderingar avslöjar ineffektiviteten i stora, distribuerade projekt.

I stället föreslår jag att vi tolkar situationen så här:

“Du vet vad idealet är. Gör vad du kan för att komma sÃ¥ när idealet som möjligt – givet DIN situation”.

Det är min strategi nr 4.

* * *

LÃ¥t oss börja med att titta pÃ¥ kommunikation. Om vi inte kan kommunicera bra, kan vi inte samarbeta och inte ge bra feedback; tvÃ¥ grundstenar för framgÃ¥ng. Vi mÃ¥ste alltsÃ¥ jobba hÃ¥rt för bra kommunikationskanaler. En sÃ¥dan sak är att maximera antalet fysiska möten, speciellt i början. Samla gärna alla team för en flera dagar lÃ¥ng releaseplanering. Det är viktigt att “fÃ¥ ett ansikte” pÃ¥ folk som man ska vÃ¥ga prata med.

En annan ovärderlig vana är att skapa ett gemensamt, viktigt mÃ¥l. Bland grupper utan ett sÃ¥dant uppstÃ¥r i stället en tävlan mellan team när de borde tävla mot konkurrenterna. En gÃ¥ng var min kollega Johan pÃ¥ ett uppdrag där ett team hade splittrats till tvÃ¥. Jag frÃ¥gade av ren nyfikenhet hur lÃ¥ng tid det tog frÃ¥n beskedet att teamen skulle splittras tills dess att nÃ¥gon sa nÃ¥got tävlingsinriktat om det andra teamet. En halv dag? En timme? Svaret kom direkt: Ca 30 sekunder. 30 sekunder till “vi och dom”. Vi är ganska snabba pÃ¥ att demonisera “de andra” och det gäller att se till att “de andra” är rätt andra.

Inom Scrum finns tekniken “Scrum of Scrums” för att skala upp kommunikationen i stora projekt. Den innebär i korthet att personen i varje team som har rollen ScrumMaster (SM) gÃ¥r iväg och har ett stÃ¥-uppmöte med andra SM direkt efter att varje enskilt team har haft det. De synkar och berättar sedan för respektive team vad som händer. Det här är en ganska hierarkisk idé enligt mitt synsätt och en Ã¥tergÃ¥ng till vad vi hade när vi hade Projektledare med stort ‘P’. Tanken med SM var ju att revitalisera rollen och göra om den till en stödjande ledare.

Min tanke: Varför inte låta alla roller synkronisera sig med sina gelikar? UX:are går iväg. Testare går iväg. Databasdesigners går iväg. Etcetera. Alla behöver synkronisera med likartade personer i andra team för att hör hur andra har löst saker och enas om gemensamma sätt.

All den här kommunikationen kostar, givetvis, och är därför frestande att att hoppa över, men allvarligt, vad är alternativet? Att inte kommunicera? Det leder typiskt till saker som lÃ¥g moral, integrationsproblem, distansering, kvalitetsproblem, dÃ¥lig design, med mer. Det här lite som det här gamla fina uttrycket: “If you think a pro is expensive, try hiring an amateur”.

* * *

Separation är ett problem på ett annat område: Programkod. Även där gäller regeln att ju längre tid som vi är isolerade från omvärlden desto värre blir problemen. De flesta vet idag att vi bör integrera så ofta vi kan inom team. Men samma gäller givetvis mellan team.

I ett projekt arbetade jag med en utvecklare, låt oss kalla honom för Mats, som hade problem att förstå detta, med ganska stora besvär som följd. Mats kallade sig för systemarkitekt och tog därför sig alltid an de stora uppgifterna. Och var de inte stora så gjorde han dem stora. Mats satt gärna hela veckan och myshackade i sin bubbla, utan att vare sig göra uppdateringar från lagret eller incheckningar av det arbete som han gjorde. Vi tjatade, men han vidhöll att han inte var i ett läge att checka in. Till slut, ofta på torsdag förmiddag, var det dags. Typiskt följde en hel dags arbete med att slå ihop hans ändringar med våra, plus givetvis gnället över hur jobbigt det var. Dessutom är det lätt att göra fel i det här arbetet, vilket ledde till att han införde några nya fel.

* * *

Ett annat omrÃ¥de där man kan vara sÃ¥ lättrörlig som man kan är organisationens struktur. MÃ¥nga organiserar sig efter lager eller komponenter. Eller “core team” och klientteam. Detta sätt att organisera sig kännetecknas av hög specialiseringsnivÃ¥, vilket vi ofta förknippar med effektivitet. Men stämmer det?

Denna organisation kan verka helt naturligt, men leder ofta till stora problem:

• Inom samma projekt blir ett team kund och ett annat leverantör, vilket pÃ¥verkar samarbetet negativt
• Specialister har svÃ¥rare att kommunicera med andra utanför sitt gebit.
• Det uppstÃ¥r oönskade beroenden mellan team; vad händer om ett team blir sent?
• Vi fÃ¥r integrationsproblem pÃ¥ grund av för mÃ¥nga gränssnitt mellan team för varje funktion.

Ett agilt sätt att arbeta med design är att arbeta med “vertikaler”, utsnitt av applikationen frÃ¥n gränssnitt till data. En organisation som är mer anpassad till detta är en indelning efter användningsomrÃ¥de, även kallade “feature teams”. Det innebär att vi samlar alla som behövs för att ta fram en samling samhörande funktioner inom ett team. Detta team ges alla möjligheter att designa frÃ¥n topp till botten, klientdelar eller API:er, logik och infrastruktur.

Fördelarna med detta är, förutom att vi slipper nackdelarna som nämndes ovan, att teamen är relativt kompletta och kan fortleva. De jobbar redan effektivt tillsammans och kan återanvändas och ta sig an nya uppgifter i framtiden. Dessutom kan teamen arbeta relativt oberoende från varandra. Givetvis måste de synkronisera sina resultat med andra team, som nämndes tidigare. Har ett team till exempel utvecklat en generell kapacitet i central del behöver andra team få höra om det.

Som alla inser så får vi en massa beroenden mellan olika delar i ett stort projekt. Detta är ofrånkomligt och nyttigt. Det är genom integration av delar som större system skapas. Men beroenden har en ond baksida. För många beroenden leder till komplexitet som våra stackars hjärnor inte är byggda för att förstå. Vi kan helt enkelt inte hantera för många beroenden utan måste försöka minimera dem.

Ericsson är stolta över sina “anatomier”. Det lÃ¥ter som ett bra koncept för att visualisera och hantera beroenden i produkter och projekt, men var uppmärksamma pÃ¥ att det inte blir lösning pÃ¥ ett symptom. Det är svÃ¥rt att skilja pÃ¥ ett beroende som mÃ¥ste finnas och ett som har uppstÃ¥tt pÃ¥ grund av nÃ¥got som vi gjort. Det kan vara sÃ¥ i vissa fall att imponerande beroendevisualiseringar bara behövs för att man har organiserat sig pÃ¥ sätt som skapar onödiga beroenden. I stället bör man angripa rotorsaken; hur man har organiserat sig.

* * *

Därmed är denna artikelserie slut. I den har jag presenterat fyra grundläggande strategier för att attackera stora utmaningar inom mjukvaruutveckling med en agil attityd.

Strategierna var:

1. Säg nej! Om du kan, sky stora projekt som pesten.
2. Anpassa arbetets omfattning till er kapacitet – inte tvärtom.
3. Conquer and Divide. Om du måste skala upp, försök att erövra problemet med ett litet hypereffektivt team och dela upp det först när du vet att det behövs.
4. Kom så nära idealet som möjligt, givet din situation. Behåll en agil attityd i en trögjobbad värld.