Till min efterträdare – beyond agile eller UnMgmt i praktiken

Om några veckor avslutar jag min tjänst som utvecklingschef. Normalt sett brukar ju en avgående chef ersättas med en ny. Jag är emellertid inte så säker på att det är en bra idé, åtminstone inte med någon som förväntar sig att få bestämma över så mycket. Jag har nämligen, kan jag så här i efterhand se, delvis ägnat mig åt att dekonstruera den traditionella utvecklingschefsrollen – ett slags un-management i praktiken. Så vad finns det egentligen kvar att chefa över?

När jag tillträdde tjänsten var det en tämligen konventionell tjänst, med en mix av det som brukar ingå i rollen som chef över en grupp experter i en teknikdriven organisation: Stort förväntat inflytande och involvering i teknikval och arkitektur, en ganska stor dos av “leda och fördela arbetet” tolkad i bred mening, och så som sidoverksamhet, det mer traditionella linjechefsansvaret för tider, personal, rapportering och koordinering med andra avdelningar.

Jämfört med större och äldre organisationer tror jag inte man kan kalla web-branchen för hierarkisk och byråkratisk. Ofta handlar organisationsförändringar där om att få lite ordning på kaos. Trots det illustrerar en traditionell pyramid ändå de förväntade makt och arbetsfördelningsrelationerna ganska väl även hos oss.

På fem år har emellertid mycket förändrats. När jag nu sätter mig ner för att sammanfatta vad jag faktiskt har utförande ansvar för numera så blir det inte så väldigt mycket kvar, förutom att vara allmänt närvarande och drivande:

• Säga ja till alla ledigheter
• Rekrytera nya medarbetare
• Attestera tidrapporter och sammanställa månatlig rapport
• Lönesättning och -samtal
• Teamsamtal
• Bestämma över vissa cermoniella datum och resurser, så som releaser och supportbemanning och labbdagar
• Hitta på presenter till folk som fyller år
• Sitta med i ledningsgrupp
• Jobba med budget
• Attestera fakturor

Det kanske låter mycket. Det är det inte. De flesta av dessa aktiviteter har dessutom på olika sätt radikalt förenklats för att minimera arbetsinsatsen.

(Nu ska jag inte överdriva. Det senaste halvåret har jag byggt upp ett nytt team i Malaysia. Under en sådan fas i ett teams liv behövs en helt annan involvering, det är åtminstone min erfarenhet. Men målet har varit att bygga bort mig själv även där. Jag har också jobbat en hel det med R&D.)

Så här såg det emellertid inte alls ut när jag tillträdde tjänsten för snart fem år sedan.

På plats fanns då tre små horisontellt skivade – alltså av varandra beroende – team. Teamen hade just börjat prova “Scrum”, men körde 3-veckorssprintar, med en veckas planering emellan. Releaser ägde rum … nej, jag tror inte jag går in på det. Tänk bara “så som det brukar vara”. Avgående utvecklingschef var också product manager, en roll han skulle bära med sig i den framtida organisationen.

Det fanns med andra ord en del att göra. Hela historien om det hör inte hemma här, den hoppas jag kunna berätta någon annan gång. Poängen just nu är: som chef fanns det oändligt mycket att ta ansvar för. En annan poäng kan jag också passa på att betona: att det som i slutändan kan se ut som en ny form av management eller ledarskap inte formades genom att implementera en eller annan ledarskapsfilosofi utan om dagligt operativ verksamhet med målet att omforma sättet vi jobbar på efter agila värderingar. Att chefrollen därmed förändrats är snarare en bieffekt än ett mål. Jag tror det är helt rätt sätt att göra det på.

Vi etablerade tidigt några vägledande principer för det nya sättet vi ville arbeta på. Dessa är ännu fullt verksamma, men i en mycket förändrad miljö:

• Alla förändringar är experiment, som avbryts om de inte funkar.
• En kult av kvalitet.
• Nyttan av det vi gör ska alltid stå i centrum.
• Vi har långsiktiga mål.

Jag brukade då sammanfatta det med frasen R³: Rätt sak, på Rätt sätt, Regelbundet. Av någon anledning har den aldrig fastnat, men trots att den möjligen saknar en innovativ och distruptiv dimension tycker jag ännu att den fångar andemeningen i en agil organisation: att på ett uthålligt och repeterbart sätt skapa saker inriktat på högt affärsvärde (och en kvalitet som lever upp till alla aspekter av detta).

Den mest fundamentala principen var och är dock denna: Teamen är självorganiserande och har ett gemensamt ansvar för allt de levererar. Ingen har större makt eller befogenheter än någon annan i ett team.

Kanske tål det också att sägas att teamen inte agerar kunder mot varandra, vilket allt annat lika har lett till vertikala korsfuntionella team som äger ansvar för allt som krävs för en viss kundriktad feature.

När vi inledde arbetet var jag närvarande och till stora delar styrande i de flesta aspekter av arbetet. Jag bestämde teamens sammansättning, var scrum master i flera team, planerade backlog med produktägaren och skrev stories, bestämde releaser, ansvarade för supporten, var en av arkitekterna i en extern arkitektgrupp, drev seminarier om kvalitet och kod, arbetade med testmiljöerna, gick igenom testresultat, kvalitetsgranskade stories, för att nämna några aspekter av allt arbete som ingår i en bra utvecklingsavdelning och som jag tog aktiv del i.

Med tiden började emellertid målet att teamen tar full ansvar skava mot allt för stor närvaro av någon med lite för stor formell makt, nämligen chefen. Med tiden drog jag mig därmed ur allt fler sammanhang. Bort från scrum master-roll, bort från dagliga standups, bort från kvalitetskontroll, bort från arkitekturbeslut, bort från möten med produktägaren, bort från sprintplanering.

Det tog knappa två år innan jag kunde skicka ut följande mail (som då var lika mycket en beskrivning av läget som en vision av hur det borde fungera):

Låt oss använda den klumpiga metaforen “fabriken” på det vi gör.

Vi har en kund till vår fabrik, nämligen vår Product Owner. Han bestämmer VAD vi gör.

HUR vi tillverkar det PO beställer bestämmer vi själva.

Ansvaret för att tillverka det PO beställt är delegerat till själv-organiserande team. Dessa är autonoma och skall göra allt de kan för att leverera det PO beställt, givet att vissa grundläggande procedurer följs. De grundläggande procedurerna inkluderar:

* PO har formulerat en levererarbar story
* Hög fokus på kvalitet
* Det som levereras skall gå att använda av slutkunderna (t.ex. dokumenterat)
* Det skall vara hållbart i enterprisesammanhang
* Alltid använda snabbaste vägen för att leverera en beställd feature
* Att aldrig ta spekulativ höjd, men koordinera och ha kunskap om alternativ

Jag är ytterst ansvarig för våra leveranser. Om processen inte fungerar, eller det vi leverera inte håller tillräcklig kvalitet är det ytterst mitt ansvar. Om teamen själva inte klarar detta måste jag involveras.

För att stödja teamen finns ytterligare roller:

* En ScrumMaster i varje team som skall coacha och hjälpa teamen vad gäller process-frågor och koordinera denna typ av frågor via IntegrationsScrumen
* En Arkitekt i varje team som skall uppmuntra och driva arkitektfrågor i teamet och koordinera och inhämta alternativ med hjälp av Arkitektgruppen
* En Arkitektgrupp ĺedd av CTO som koordinerar arkitektfrågor “just-in-time” mellan teamen och som skall fungera som ett forum för att uppräthålla “multiple options” vid arkitektur- och strategiska val. Gruppen beslutar inte över teamen, men ser till att all tillgänglig kunskap finns för teamen vid arkitekturval

Som framgår har teamen fått en stor och ganska tydlig roll, med mycket makt. Men man kan lägga märke till ordvalet ovan: “delegera”. Ansvar och makt strålar fortfarande uppifrån och ner. Läser man texten noggrant kan man få syn på en viktig egenskap i denna delegering: att ansvar och makt hänger ihop. Delegeras ansvaret, ska också makten följa med. Det är så autonomi skapas, och så småningom börjar synen att något är delegerat framstå som allt mer konstigt och gammalmodigt. Det är något som är en naturlig del av ett teams tillvaro.

Här är några saker som ganska snart blev en internaliserad del av teamens eget ansvar och arbete:

• Styra över sitt eget arbete i form av implementations-, arkitektur- och ramverksval.
• Arbeta med backlog och stories direkt med produktägaren.
• Koordinering med externa intressenter.
• Kvalitetssäkra genom parprogrammering, kodgranskning, kodstil, tester m.m.
• Stoppa bandet och laga fel när tester går fel.
• Följa upp och förbättra genom retrospektiver och kaizen-arbete.
• Se till att alla supportade plattformar testas och följs upp.
• Kompetensutveckling och innovation genom regelbundna labdagar.
• Ta hand om och lära upp nyanställda.
• Djup involvering och makt över rekrytering.

När man får ansvar och makt måste man emellertid ha rimlig möjlighet att utöva denna makt. Jag tror två saker har varit avgörande för att vi lyckades:

För det första måste man ha kontroll över sin tid för att få makt. I Scrum är denna egenskap inbyggd i processen. Mellan sprintplanering och leverans i slutet av sprinten äger teamet sin tid. Kan man skapa en sådan loop har man också skapat underlag för egenmakt. Emellertid finns något man aldrig kan komma undan: leverera man undermålig mjukvara med mycket fel kommer det om och om igen slå in sprintarna i form av kundkriser och akuta buggfixar.

Att få kontroll över sin tid handlar därmed mycket om att få kontroll över kvaliteten och att hitta sätt att jobba med defekter. Jag har skildrat delar av detta i föredrag så som stop-the-line (http://www.antman.se/archives/348), men kan inte nog betona detta. Att vi tog kontroll över buggtillväxten och fick ner den till noll var förutsättningen för teamens autonomi. Den här grafen är jag så stolt över.

För det andra är det svårt och kontraproduktivt att försöka detaljstyra förändringar. Dels för att detaljstyrning kräver kunskap som man ofta inte har, dels för att det bryter teamens autonomi och därmed både riskerar att undergräva motivation och lusten och förmågan att ändra på sådant som inte fungerar. Har det införts från ovan är det lätt att dåliga praktiker lever kvar eftersom ingen riktigt vill ta ansvar för dem. I stället bör man som chef och coach arbeta med förändringar genom att ändra på de yttre förutsättningarna.

Vintern 2009 genomförde vi en sådan radikal förändring av våra yttre förutsättningar: vi bestämde oss för att göra tidboxade releaser av produktionskvalitet en gång i månaden. Vi gjorde det först, sedan fick vi anpassa oss (det är väl som när en bit land sliter sig bort och bildar en ö – en radikalt förändring av de evolutionära förutsättningarna). Jag måste erkänna att vi inte läste så jättemycket om theory-of-constraints då; men det var just vad vi övade oss i. Vi tvingades att ändra och kalibrera och automatisera nästan allt för att lyckas med detta (vilket jag skildrat här).

Efter drygt tre år med releaser på exakt datum med ny fungerande funktionalitet av hög kvalitet beslutade vi nyligen att vi blivit bekväma och att det om igen var dags att sänka vattenytan. Nu har vi gått över till att släppa ny funktionalitet via mavens SNAPSHOT-mekanism varje vecka. Exakt vad det trycket driver fram kommer jag själv inte vara kvar och se. Jag är övertygan om att det kommer driva fram nya intressanta anpassningar.

De dynamiska följderna av självstyrande team som arbetar inom en “ekologisk” nisch, som på en och samma gång är externt bestämd (genom tidigare beslut, processregler och utomstående intressenter) och påverkbar av teamen själva, är närmast enorma och så småningom sjävförstärkande.

Det ena som händer är att med tiden utökas cirkeln över saker som blir konstigt att någon annan utanför teamen ska bestämma över. Det andra som händer är att rutiner och processer som är skapade runt individer blir allt mer oanvändbara.

Våren 2011 höll vi en konferens i Eskilstuna. Jag gav den titeln “Next step”. Under åren som gått hade vi provat och infört nästan allt man kunde hitta i agil och lean litteratur. Det var dags att ta självorganisering till nästa nivå. Jag tror att man kan sammanfatta det som att vi ville försöka vända pyramiden upp och ner på riktigt.

Jag hade också – mer eller mindre i tysthet – lagt ner utvecklingssamtalen (på Agila Sverige 2011 höll jag dock ett föredrag om detta, så helt i tysthet var det ju inte) under våren. Jag tyckte då att det blivit mer och mer uppenbart att de agila värderingarna (teamet är ansvarigt, betoning av inre motivation. återkopplingar hela tiden, systemtänkande, vid behov) skar sig mot de värderingar som ligger bakom individuella utvecklingssamtal (bedömning, extern motivation, individinriktat, sällan förekommande, förutbestämt). Genom traditionella utvecklingssamtal visar vi att vi inte litar på våra medarbetare.

Utvecklingssamtal är en liten sak i det hela. Men det har viktiga symboliska följdverkningar.

Senare under hösten provade jag att inför korta personliga samtal, men ingen var intresserad. Däremot upplever jag att teamsamtalen vi drog igång en gång i månaden var både uppskattade och givande. I dessa kunde vi fånga upp behov, önskemål och farhågor utifrån teamets perspektiv och jag kunde hjälpa till med coaching eller makt i organisationen i övrigt.

Samma typ av dilemma kryper också in i lönesättningen. När allt arbete utförs i ett team, när allt ansvar tas av en grupp, när de är kollegorna som utbildar och handleder nyanställda, hur kan man då ha individuell lönesättning? Det är en bra fråga, som jag delvis utvecklade svar på, men som jag ännu inte är redo att skriva om.

Strax efter konferensen upplöste vi teamen för att starta om från början. I stället för att jag på olika fiffiga sätt satte samman team (“äger resurserna”, som man brukar säga), skapade vi två förutsättningar: vi skulle jobba med tre kundvända produktinriktningar och teamen måste vara ungeför lika stora. Sedan fick var och en välja vilken inriktning den ville jobba med. Med några kompromisser gick det alldeles utmärkt att få ihop jämna grupper. Jag har aldrig upplevt så stabila team. Men det är också helt ok att byta team om det gå att få ihop personalmässigt.

I samma veva lade vi ner rollen som ScrumMaster eftersom den spelat ut sin roll. När tankefigurerna bakom agile och lean sitter i ryggraden behövs ingen specifik person som ska ta ett utpekat ansvar för processen, alla ska kunna och vara ansvariga för det. Om teamet behöver röja undan hinder, så kan det själv hantera det. En omedelbar bieffekt blev att tidigare slutna möten (så som pre-planering) omvandlades till frivilla och öppna möte, med en enkel regel: minst en från varje team måste komma (vilket innebär att alla kan dyka upp på ett möte, att olika personer dyker upp på olika veckor).

Vi har ännu kvar de mer eller mindre officiella arkitektrollerna, men på många sätt har de omvandlats från en officiell roll till att handla om senioritet. Också arkitektmötena har öppnats upp för alla som vill delta, för att de har något att bidra med eller för att de vill lära.

Ju längre in i “agile next step” vi kommit, desto smalare har chefsrollen blivit. När jag nu i skrivande stund går igenom de områden där jag själv numera spelar en avgörande inverkan ser jag nu mest en slags buljongchef: rollen reducerad enbart till det som i en traditionell organisation är nära på omöjligt att släppa taget om: tidredovisning, lönesättning, ledigheter, budget och rekrytering.

De sista organisatoriska steg jag är med och tar leder teamen ännu ett steg bortom traditionell management. Det första steget har vi redan tagit. Teamen har helt tagit över ansvaret för sin backlog. I stället för att se sig som mottagare av produktägarens önskemål, betraktar de nu sig själva som en slags egna startups som har ett övergripande mål att driva en viss del av produkten vidare genom att aktivt söka sin(a) produktägare.

Det andra steget ska de ta när jag kliver ut genom dörren. Då ersätter de det jag gör (förutom de ovan uppräknade svårspridda chefsgörorna) genom att utse representanter som möts var annan vecka och löser frågor som går utöver det enskilda teamet: så som vilka som ska sitta i support, hur semestrarna ska fördelas, när labdagar behöver äga rum, om man vi ha en konferens eller behov av ny hårdvara och så vidare. På sätt och vis känns det vemodigt att inte på plats få se hur detta utvecklas.

Just nu kan jag inte riktigt se hur den hårda inre kärnan i den makt (och ansvar) som ingår i arbetet som linjechef ska kunna spridas ytterligare. I förlängningen borde de kanske gå att organisera som tjänster runt teamen, som de kan utnyttja vid behov. Kanske kräver det ännu en radikal omorganisation? Ännu mer un-management? Det är väl en spännande uppgift för en efterträdare.

För den som är intresserad av att läsa mer om agile och management samlar jag intressanta länkar här.

Från 06/18/2012