Teknik: tvärfunktionellt arbetslag

En agil teknik är det tvärfunktionella arbetslaget. Vilket problem vill man lösa genom att ha tvärfunktionella arbetslag?

Att ett arbetslag är tvärfunktionellt innebär att det innehåller en blandning av kompetenser som krävs för att skapa ett visst värde. Motsatsen, ett enfunktionellt arbetslag, består av specialister på en del av arbetet. Som till exempel vid vissa systemutvecklingsmetoder: en grupp lösningsarkitekter som utifrån en beskrivning av verksamhetslogiken och informationsmodellen skapar en övergripande teknisk lösningsskiss som de skickar vidare till de som arbetar mer kodnära.

De enfunktionella arbetslagen uppstod ur en idé om specialisering och enkelriktade arbetsflöden: inom tillverkningsindustrin är det rationellt med specialiserade arbetsstationer och så låter man arbetspaketet flöda genom systemet från den ena stationen till den andra. Problemet var att utvecklingsarbete handlar om att tillsammans förfina information om både problem och möjliga lösningar. Att generera beskrivningar av verksamhetslogik, av lösningsarkitekturer, och av kod är bara utflödet av denna informationsförfining.

Enkelriktade flöden mellan specialiserade grupper är bara ekonomiskt effektiva om transaktionskostnaden mellan grupperna är låg och inget värdeutbyte sker mellan grupperna. I utvecklingsarbete är det värdeskapande med ett kontinuerligt utbyte (inte ett enkelriktat flöde) mellan olika kompetenser så att man kan skapa en gemensam bild (inte olika sorters dokument som ägs av helt olika personer). Utvecklingsarbete måste därför optimera informationsutbytet och kunskapsförfiningen.

Detta kan göras om personer med olika kompetenser arbetar tillsammans i ett litet samkört arbetslag med att förfina och till slut kodifiera samma kunskapsmängd och på så sätt skapa en gemensam leverabel. Ett tvärfunktionellt arbetslag.

I grunden är det ett leanverktyg från tillverkningsindustrin: gruppera människorna runt samma arbetspaket så att de kan blir experter på att samarbeta om att skapa en leverabel så fort de får en förfrågan. I lean kallas det en "cell", till skillnad från en station vid ett löpande band.

Om du nu inte har tvärfunktionella arbetslag, hur anpassar du metoden då? Du behöver titta på det bakomliggande syftet med det tvärfunktionella arbetslaget, nämligen kommunikation och kunskapsförfining, och se hur man kan åstadkomma detta även när nyckelkompetenser befinner sig på olika platser i organisationen. Kan de dela möten med varandra? Kan deras respektive grupper samplanera? Kan de olika enfunktionella grupperna arbeta runt samma flödestavla där de har arbetspaketens hela flöde i centrum, och inte bara den egna lilla delen av processen?

Det är nyckeln i all anpassning av agila metoder när du inte kan anpassa dig till att använda en viss teknik: se till teknikens bakomliggande syfte och försök uppfinna en egen teknik som uppfyller syftet. Pröva lite olika varianter, mät för att se vilka tekniker som innebär bäst förbättring hos er, och besluta er runt dem.

Vad ni inte ska göra är att behålla arbetssätten oförändrade jämfört med så som de beskrivs i de agila ramverken, när förutsättningarna hos er faktiskt inte är uppfyllda. Har ni inte tvärfunktionella arbetslag ska ni inte låta era enfunktionella arbetslag imitera hur de tvärfunktionella brukar arbeta. Ni kommer inte att få några bra resultat då. Det blir bara en rituell imitation av agila arbetssätt och ingenting som kommer att leda till större agilitet.

Vad vill metoden lösa?

När man inför agila metoder i olika samarbeten dyker man alltid på spänningsfältet mellan de som vill följa metoderna till punkt och pricka och de som vill anpassa dem. Och bland dem som vill slaviskt följa efter finns det de som vill följa av rätt anledningar och de som vill göra det av fel anledningar. Precis som hos de anpassliga: vissa vill anpassa utifrån ett verkligt behov av anpassning, medan andra vill anpassa för att undvika någon av de förändringar som metoden kan komma med.

Så hur vet man hur man ska förhålla sig till anpassningar av agila metoder då? Hur vet vi om vi ska följa slaviskt eller om vi ska ändra i metoden? Genom att man förstår hur metoderna fungerar.

Metoderna är påsar med tekniker i. Även om det står olika namn på påsarna innehåller de påfallande ofta samma tekniker, och det är teknikerna som påverkar samarbetet till att bli mer agilt om man tillämpar teknikerna rätt.

Varje teknik finns där för att lösa ett specifikt problem. Folk har erfarit strukturella hinder mot större agilitet, och så har de experimenterat fram en teknik som hjälpt deras samarbete att ta sig över det specifika hindret. Metoderna är inte magiska och teknikerna är inga ritualer som fungerar oavsett förutsättningarna. Om du inte har den situation som tekniken är tänkt att hantera, så ska du inte använda dig av just den tekniken.

Så står ni med en frågeställning rörande ett visst arbetssätt så börja med att undersöka om ni verkligen förstått hur det nuvarande arbetssättet påverkar den aktuella situationen, och vilka alternativa arbetssätt som skulle kunna påverka på ett annat vis. Sedan bör ni experimentera med arbetssätten för att validera de här hypoteserna, utvärdera på empirisk grund, och bestämma er för förhållningssätt därefter.

Det viktiga med införandet av agila metoder är att ni hela tiden är öppna för det här prövande förhållningssättet. Det kräver att ni aldrig standardiserar runt en viss metod eller teknik utan optimerar organisationen för förändring. Agilitet är ett lärande.

Kravkurs GBG den 30 mars!

Jag håller, tillsammans med Informator, en kurs i agil kravhantering i Göteborg den 30 mars 2016.

I kursen provar vi på olika tekniker hämtade från det verksamhetsfält som kallas för Lean UX: Personas och Impact Mapping / effektkartläggning, samt typiska agila kravtekniker som CCC-kompletta User Stories och Story Mapping.

Det hela synkas ihop med backloggarbete i en tredelad backlogg som är kompatibel både med SAFe (portfölj-, program-, och teambackloggarna) och med vår kurs i agilt produktägarskap.

Är du beställare, kravfångare, eller produktägare i en agil organisation så kommer du att ha nytta av den här kursen!

Oförutsägbara framtid

Den amerikanska ekonomiprofessorn Don Reinertsen har helt rätt i att produktledningsbeslut, till exempel om en systemförändring i en IT-tjänst eller IT-produkt, måste följa ett ekonomiskt ramverk. Hans förslag är att man kvantifierar väntekostnaden, vad det kostar att inte ha något på plats, för de olika alternativen och prioriterar utifrån det. Det blir då ganska uppenbart att man för systemförändringar som är ungefär likvärdiga ska man prioritera den förändring som man snabbast får ut i produktion så att det kan börja hämta hem värde. "Prioritize the Weighted Shortest Job First (WSJF)".

Man kan ganska enkelt göra spel och simuleringar som visar nyttan av detta.

Men man får samtidigt inte glömma bort att värdet av en systemförändring framförallt är kvalitativ. En IT-tjänst ingår i flera värdeströmmar. Varje förändring i tjänsten förändrar samtidigt flödet på ibland oförutsägbara sätt. Ny utformning av verktygen kommer att påverka hur själva arbetet går till. Ny utformning av tidsfördriven förändrar hur vi fördriver vår tid. Kanske till och med förändrar IT-tjänsternas utformning hur vi definierar både arbete och fritid.

Eftersom effekterna på hela flödena är oförutsägbara kan man ofta inte kvantifiera någon väntekostnad. Men hur ska vi då veta om vi ska försöka oss på den snabbaste förändringen först? Om vi inte vet om förändringarna är likvärdiga?

Svaret är att vi ska bli ännu mer angelägna om att prioritera utifrån snabbhet. Med snabb förändring får man snabbt svar på vad förändringen innebär i en komplex och oförutsägbar verklighet. En snabb förändring är en billig förändring så även förändringar som visade sig vara dåliga bör vara snabba att få ut i produktion.

I komplexa och adaptiva system, vilket nästan alla värdeströmmar är (om man tar hänsyn till människors beteende vilket man måste), är det förmågan att få snabb återkoppling på en prövande rörelse som är den avgörande, inte förmågan att förutse. Det ekonomiska ramverket vi beslutar utifrån måste därför vara inriktat på att minska risk och omfattning, och på att snabbt mäta utfall av olika förändringar. Inte vara inriktat på förutsägbarhet om förutsägbarhet ändå inte finns.

Don Reinertsen tar upp även denna aspekt i sin bok om produktutvecklingsekonomi, Flow och Eric Ries bygger hela tankegången i Lean Startup på principen om prövande förändring till låg risk och snabb återkoppling. Tyvärr har inte Dean Leffingwell i SAFe betonat värdet av utforskning tillräckligt hårt, utan lyfter framförallt principen om Weighted Shortest Job First, en princip som bygger på att man faktiskt kan vikta värdet av förändringarna på förhand (och korrekt estimera deras längd/kostnad). Man riskerar att gå miste om potentiellt väldigt höga värden bara för att man inte vågar utforska det okända.

Återigen alltså en risk med SAFe när det tillämpas utan en ifrågasättande självständig tanke. Det är alldeles för frestande för många, gärna i stora organisationer, att försöka optmimera för förutsägbarhet. Det logiska felslutet att påstådd förutsägbarhet är verklig förutsägbarhet, eller att förutsägbarhet alltid innebär låg risk, eller att låg risk alltid innebär god ekonomi, ligger nära oss, i synnerhet i organisationer som har lätt för att straffa.

Det är viktigt att snabbt få ut förändringar i produktion, men inte baserat på en falsk känsla av förutsägbarhet och kontroll utan baserat på vårt behov av att testa oss fram i en oförutsägbar verklighet.

Kaos in, kaos ut

Var på ett industriföretag igår och pratade agil systemutveckling (produktägarkurs), om hur kraven måste flöda. Drog följande lilla mentala ordbild:

"Om inköp och logistik inte gör sitt jobb, om det inte kommer några inleveranser till fabriken, eller om de kommer i fel ordning, eller är ofärdiga och fulla med fel, eller inte är förpackade på ett hanterbart sätt, inte 17 går cheferna då runt och skäller på arbetarna för att inget produceras. Nej, i ett sådant läge skulle cheferna styra upp inflödet direkt, och se till att inleveranserna sköttes i god ordning.

Detsamma måste folk börja göra inom IT-utveckling. Sluta gräla på systemutvecklare och testare och drift när utleveranserna dröjer, om inleveranserna, de uttryckta behoven, kraven och önskemålen och informationen om hur allt funkar, bara är ett stort kaos."

De organisationer som har koll på kravflödena och där produktägarskapet sker i god ordning, där verksamhet och IT samverkar, där har man ett stort och jämnt utflöde av nytta.

Beställare och utförare

Det finns i synnerhet en form av bristande markkontakt som förstör bra och effektiv utveckling av IT-system: abstraktionen i beställare och utförare, att någon beställer IT-utveckling av någon annan på ungefär samma sätt som man beställer tillverkning.

Det är en abstraktion som kan fungera när man är i avtalssituationer, till exempel när man måste teckna ett avtal som fördelar tänkt ansvar mellan två entiteter eller när något har gått snett och vi måste utföra den där ansvarsfördelningen i verkligheten. Men den fungerar inte när man utvecklar. Inte ens om man faktiskt är två olika juridiska entiteter som ska samarbeta om utvecklingen.

För det är samarbete som krävs. Som det agila manifestet formulerar det: We value Customer collaboration over contract negotiation.

Mjukvara är kodifierad kunskap och förståelse. Det behövs såpass mycket förståelse av både problemdomänen och vilka tänkbara lösningar som finns i lösningsdomänen att man till slut kan kodifiera denna kunskap så att också en dum dator förstår. Det är en kunskap man skaffar sig tillsammans: både de som ska använda det färdiga resultatet av utvecklingen och de som är bra på att fånga kunskap och förfina den till kodifierat skick.

Det finns inget sätt att göra en tydlig ansvarsfördelning i en process vars framgång bygger på mycket tät och rik kommunikation. "Beställare" och "utförare" sitter bokstavligen i varandras knä. Om de inblandad är duktiga på det de håller på med så kan de minska riskerna för att den här kommunikationen går fel, men de är i lika mån ansvariga för slutresultatet.

När man, som vi på Squeed, arbetar i en renodlad utförarorganisation som säljer oss som länkar i utvecklingskedjan behöver man ta ut en ekonomisk riskpremie av varje kund. Ibland går det fel i kommunikationen och då behöver man kunna ha lite kapital för att kompensera för denna varians.

Men situationen är långt värre för de som arbetar med IT-utveckling internt i organisationer där de som ska använda resultatet betraktar sig själva som beställare som kan flytta en stor del av ansvaret över på utvecklingsorganisationen, men utan att dessa får lov att ta ut någon riskpremie. I ett flöde kommer problem att uppstå överallt, men de kommer att manifesteras långt ner i kedjan nära leveransen. Det är som ett stopp i avloppet i källaren: problemet har inte uppstått där utan beror på det som kommer längre upp ifrån.

Så oavsett var kommunikationen och kunskapsförfiningen brister är det "utförarna" som kommer att framstå som de skyldiga, om man saknar förmåga att se kommunikationsbristen i samma ögonblick som den uppstod. Det "beställarna" måste förstå är att om de tar ansvar för sin beställning så har de samtidigt ansvar för utförandet.

En ännu mer bisarr avart av detta är organisationer där den delen av utförarorganisationen som beslutar om utvecklingen på strategisk och taktisk nivå betraktar sig själva som beställare i förhållande till de som befinner sig på operativ nivå nära koden. Där har man verkligen lyckats att ge sig själva stora mandat och samtidigt undvika ansvar.

Det må vara en god ordning för de som placerat sig i den positionen, men vad jag inte kan förstå är hur ledningen för sådana organisationer tillåter det att ske. Dessa organisationer brukar ju ha en lång historia av misslyckad IT-utveckling, och med tanke på hur systemet är riggat kan man bara dra slutsatsen att dessa misslyckanden är avsiktliga.

Nytt kursmaterial färdigt

Så är äntligen uppdateringen för min kurs "Product Ownership" färdig. Vi talar om vad en produktägare är i Scrum och i SAFe, hur man budgeterar och styr en IT-produkt på strategisk, taktisk, och operativ nivå, och litegrann om mjukvaruekonomi (hur man styr systemutveckling på ett ekonomiskt rimligt sätt och hur man följer upp).

Vill du gå den? Hör av dig!

Medarbetarundersökningen vartannat år

Läste i dagens Göteborgs-Posten om att kommunen nu utfört sin medarbetarundersökning och då sett vilka kommunala organisationer som hade högst respektive lägst personalnöjdhet.

Det är i vanlig ordning lite si och så med ledarskapet, kanske särskilt i kultursektorn, och det är ju ett problem i sig. Min erfarenhet av ledarskap är att det är inte supersvårt att skapa en organisation med något sundare ledarskapsstrukturer. Ofta gör man organisationen markant bättre genom att bara bättra på en handfull ledarskapsbeteenden.

Men det som jag studsade över var det här: "När den förra medarbetarundersökningen gjordes för två år sedan..."

Två år.

Det är visserligen bra att mäta. Men om man inte kan agera på mätetalet så är mätetalet istället en farlig fiende. Mätetalet behöver ingå i en uppföljningscykel: man agerar, man mäter, man justerar, man mäter, man justerar och så vidare. Det är beteendet som är det intressanta, utfallsmåttet ska bara berätta för oss att vi behöver ändra kursen.

Ett utfallsmått som tas en gång vartannat år kan visserligen berätta för oss att vi behöver ändra oss, MEN ger oss ingen vägledning hur. Den längsta justeringscykeln som alls är rimlig att ha är väl i storleksorningen ett kvartal. Gärna kortare, om ni vill gå snabbare fram.

Det kan hända att man på lokal nivå arbetar med tätare uppföljningscykler. Men jag tror inte det, för då hade inte situationen hunnit bli såpass bedrövlig på de ställen där det är dåligt. Då hade utfallsmåttet triggat en uppryckning, som man följt upp betydligt tätare.

I mina ögon ser det ut som tvåårscyklerna är ännu ett bevis på att Göteborgs kommun har stora svårigheter med sin styrning och ledning. Jag tycker att utfallet i de kommunala verksamheterna också tyder på detta, så det kommer jag nog tro tills dess att jag har blivit överbevisad om motsatsen.

New game based on Reinertsen's principles

Teaching mathematical concepts late in the afternoon can be tiresome for the students.

I have just finished the design of a game for my Product Owner / Product Manager course (latest version, premiere on this monday in collaboration with Informator). From the game you can learn a couple of Don Reinertsen's economic principles from the book The Principles of Product Development Flow. It is one of my favorite books, about how you prioritize in a sound economical way in lean and agile development.

The game teaches the concept of Weighted Shortest Job First (that is one of the principles of SAFe), and also teaches (by introducing random factors) the importance of being prepared to handle variation and the dangers of trying to maximize resource utilization. It is a simulation of 12 weeks in a software development department where the release date moves closer and closer while the scope is being fixed...

I have tried it out using people at my company, Squeed and they were quite happy. Among them are people very interested in strategic board games, and they felt that the game is actually interesting from a gamer's perspective (about optimizing a schedule), not only from a learner's perspective (even if it actually teaches the tricky concepts of the book quite well).

Markkontakt och flöde

De agila värdena och principerna är en sak. De storskaliga ramverken gör så gott de kan. Men det finns ett par andra viktiga principer som många glömmer av när de ska implementera agila arbetssätt hos sig. Det gäller kanske framförallt när de ska införa agilt i de större sammanhangen, och det beror inte på vilket ramverk man väljer, utan hur man väljer att tillämpa det.

Det är principerna om markkontakt ("gemba") och flöde ("flow").

Vissa agila ramverk, t ex lean software development och SAFe, är tydliga med vad de lånat från Toyota. Men alla ramverken har lånat från Toyota, och i synnerhet dessa två principer.

Hela skälet till att vi investerar i att bli mer lättrörliga (agila) är för att vi vill uppnå ett bättre flöde även i en komplex och oplanerbar miljö. Vi vill bli bättre på att möta behov, även när vi inte riktigt vet hur. Då behöver vi investera i flödesskapande arbetssätt så att vi kan leverera mindre paket men göra det snabbare och bli duktigare på att snabbt fånga upp återkoppling.

Att optimera på flöde är att rensa bort allt onödigt arbete och all onödig väntan. Det är att först och främst se till att informationen flödar fritt och effektivt, för informationsflödet påverkar alla andra flöden. Det är att se till att ingen del i systemet (till exempel en människa) är överlastad. Optimerar man på flöde kan man inte optimera på ett högt resursutnyttjande, men genom att få ner varianser i arbetsbelastningen så kan man förbättra bägge.

Alla agila ramverk är flödesoptimerande i någon mån. Just förmågan att flödesoptimera blir testad när man vill bli agil i större organisationer och värdeflöden. Det är här som lättviktiga ramverk får problem om de inte kompletteras med verktyg för att hantera det större flödet. En hel del av verktygen i SAFe försöker lösa precis detta.

Men det man ofta misslyckas med när man försöker bli storskalig och agil är att behålla markkontakten. Principen om gemba, att vara verklighetsnära i allt man gör, är central för alla smidiga arbetsmetoder.

Det började i verkstadsföretaget Toyota som en idé att den som ska leda ett arbete själv måste veta vad arbetet innebär. Chefen måste ha jobbat på golvet. Det fortsatte med en tanke att beslut inte ska fattas på tyckande utan på fakta. När man gick mer mot massproduktion innebar detta att chefer inte skulle fatta beslut på aggregerade nyckeltal utan istället gå ut i fabriken för att på plats se hur det faktiskt fungerar. Detta ledde sedan fram till insikten att det är folket på golvet som själva bör få mandat och förmåga att också fatta beslut.

När det gäller att utveckla produkter och affärer har principen om markkontakt lett till insikten att gemban ("golvet") inte i första hand är fabriken eller utvecklingsavdelningen eller styrelserummet, utan är den verklighet där produkten används.

Jag har sett storskaliga agila ansatser inom mjukvaruutveckling som aktivt motverkat principen om markkontakt på alla nivåer. De som sätts att leda produktens utveckling på strategisk och taktisk nivå (till exempel i portföljstyrningen eller i programledningar) saknar erfarenhet av att utveckla system. Man fattar beslut baserade på planer och tyckande istället för på faktiska kapaciteter och relevanta mätetal. Ingen av de som styr tar sig någonsin dit där de kan observera det faktiska arbetet äga rum. Man hindrar folket på golvet att själva ta kontrollen över sina arbetsformer, istället standardiserar man i onödan runt praktiker som i det enskilda fallet minskar möjligheten att nå i mål. Och man undviker i det längsta att införa kravfångstmetoder som bygger på att observera verkliga användare och låta nya insikter om deras behov få påverka de redan fastslagna planerna.

Det behöver väl knappast nämnas att resultatet i alla dessa fall blir sämre än det var tidigare?

Jag är beredd att ge ramverken halva skulden för att det är på det här viset. SAFe-införande löper, förmodligen på grund av sitt språkbruk, en notoriskt hög risk att överstandardisera när ledande personer beslutar om att likrikta utan att riktigt förstå varför man vill likrikta eller vilka de skadliga konsekvenserna kan bli.

Men ett ramverk kan aldrig göras ansvarig. Ansvaret vilar på dem som fattar besluten. Om de fattar beslutet att följa ett halvbra ramverk till punkt och pricka på grund av att de själva saknar kunskap att hantera verktyget rätt, så bör de överväga att lämna över en del av beslutsmakten till de som har bättre insikt.

I synnerhet då insikter i principen om flöde och principen om markkontakt.

Det är skalan och inte ramverken

Kritik mot storskaliga agila ramverk bygger ibland på att de bryter mot några av de fyra agila värdena eller de tolv bakomliggande principerna. Och det stämmer i viss mån. Men jag vill ändå försvara de storskaliga ramverken med att brotten mot till exempel de fyra värdena snarare är en produkt av storskaligheten än en produkt av ramverken.

Individer och deras samspel framför processer och verktyg? Ja, men om vi ska synka samspelet mellan hundra individer behöver vi ha något strukturerat sätt att samspela på. Kanske är en tvådagars produktinkrementsplanering med alla i rummet ett bättre verktyg för detta än många alternativ?

Fungerande mjukvara ofta? Ja, men i vissa tekniska plattformar innebär "ofta" var tionde vecka istället för varannan. Trögheten behöver inte ha med processen att göra, utan med övriga strukturer (tekniska och organisationella).

Kundsamverkan framför avtal och friskrivningar? Ja, men där är ramverken, både lättviktiga (som Scrum) och tyngre som (SAFe), helt i händerna på säljprocesser och avtalsjuridik. Det bästa vi kan göra är att försöka övertyga kunder och säljare och ledning om behovet av andra angreppsätt, men då behöver vi presentera ekonomiska modeller och andra kringstrukturer. Lättviktighet som innebär att vi inte svarar på vissa frågor från omgivningen hjälper oss inte i den kampen.

Omplanering framför att följa planerna? Japp. Men på rätt nivå. Om vi använder de agila verktygen för löpande omplanering till att vimsa omkring så tar vi oss ingenstans.

Agilitet har inget egenvärde. Värdet ligger i om ökad agilitet gör oss bättre på att uppfylla människors behov. Vi kan använda vår agilitet för att kunna söka oss fram, men den övergripande riktningen behöver vara fastslagen så att vi vet vilka behov som är viktigare än andra. Särskilt om vi är många som ska springa mot samma mål.

Mer lättviktiga metodramverk som Scrum döljer den här problematiken.  Man antar att det finns en person, PO, som helt enkelt vet hur man värderar och prioriterar. Men den PO som läser Scrumguiden får liten eller ingen vägledning för sitt arbete. "Organisationen ska veta vad som är viktigt och ställa sig bakom PO:ns prioriteringar!" Men hur organisationen kommer fram till detta besvaras inte.

Man kan ha synpunkter på hur SAFe föreslår att en produkt- och portföljledningsstruktur ska se ut. Det finns fler bra sätt att lägga upp arbetet på än vad SAFe beskriver. Men man är farligt naiv om man påstår att en sådan struktur inte behöver finnas utan bara är ett sänke för agiliteten. Scrum implicerar att den finns där. På något sätt behöver PO:n ta reda på vad som är viktigt inför sprintplaneringen.

Däremot lider flera storskaliga agila implementationer av problem. Men dessa menar jag snarare uppstår när man frångår två viktiga leanprinciper: den om "gemba" och den om "flow". Man behöver markkontakt och flöde. Men det får bli ämnet för ett annat inlägg.

De storskaliga ramverkens grundantagande

De tre mest kända ramverken för storskalig agil utveckling: SAFe, Nexus och LeSS utgår från samma grundantagande: utmaningen för storskalig agil utveckling är hur man ska koordinera flera team runt en produkt.

SAFe kallar för ett "Agile Release Train". Nexus kallar det för ett "Nexus". LeSS kallar det inte för något särskilt, bara "det här är Scrum fast för flera team". Men det handlar om en samling av team som samplanerar sin utveckling av en och samma produkt från en och samma behovslista.

I grund och botten är ramverken väldigt lika. Nexus och Less beskriver inte behovslistan på något annat sätt än Scrum (det finns färdignedbrutna saker och ofärdiga) förutsätter värdeskapande varje sprint och tillför få (Nexus) eller inga (LeSS) nya roller. SAFe går lite längre och tar höjd för att varje värdeskapande kan ta några sprintar (ett sk "produktinkrement") och arbetar därför med en tredelad behovslista med vissa specifika artefakter i samt några nya roller för att koordinera detta.

Men inget av ramverken tar höjd för den situation där ett utvecklingsteam behöver stötta flera parallella utvecklingsansatser (projekt eller produkter). Inget av ramverken kan rakt av lösa frågan om hur man koordinerar värdeskapande som sker kors och tvärs och inte sällan i konflikt med varandra. SAFe har åtminstone i och med beskrivningen av värdeströms- och portföljnivån ett förslag på hur det ska lösas, men om ingen finns som kan prioritera på portföljnivå så fungerar det inte.

Problemet är vanligt, det kan lösas och det är inte jättesvårt att lösa även om det ofta inbegriper att man behöver se över beslutsmandat, projektfinansieringsmodeller och uppföljingsmodeller. Men det måste bli mer känt att inget av de existerande ramverken i sig löser den situationen.

Skalningsramverken försöker lösa koordineringsproblemet när flera team ska samsas om en backlogg. Det är en sorts skalproblem. Organisationer vill istället alldeles för ofta använda dem för att få ett eller flera team att samsas om flera skilda backloggar. Det går inte. Det är en helt annan sorts skalproblem.

Det spelar då ingen roll att ramverket har förmågan att hantera flera team. Det man behöver är ett sätt att hantera flera olika beställare med vitt skilda prioriteringar.

(...och apropå storskalighet, som vanligt säger Jurgen Appelo som det är!)

Scrum avslöjar mer än förbättrar

Nej, Scrum är inte definitionen på vad en agil metod är och ska vara. Scrum är en samling av tekniker. Det finns andra samlingar.

Scrum är däremot ofta en bra startpunktsmetod: den hjälper dig att komma igång. Ändå har jag mött många som säger sig ha startat med Scrum, men sedan känt att de liksom fastnat. "Vi kör Scrum men vi behöver komma vidare. Det har inte riktigt lossnat för oss!"

När man tillsammans med dem då tittar på vad de har gjort och inte gjort så ser man att de ofta hoppat över bitar i sin Scrumimplementation. Viktiga bitar som står i Scrumguiden, svart på vitt, men som de missat. Scrumguiden är ganska korthuggen. Även ganska stora insikter nämns i förbigående.

Väldigt ofta hoppar folk, i synnerhet i ledande ställning, över den här lilla passusen:

Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

Det finns handgrepp och tekniker i Scrum som direkt löser problem folk brukar dras med. Sprintar löser en viss typ av planerings- och uppföljningsproblem. De dagliga mötena löser ett antal koordinations- och arbetsledningsproblem.

Men det räcker ju inte. I just ditt sammanhang har ni säkert strukturella hinder för er agilitet som inte utan vidare löses av att införa nya sorters möten.

Det är då som transparensverktygen i Scrum gör sitt. Ramverket avslöjar, men löser inte, de utmaningar ni har. "Scrum makes clear the relative effiacy of your product management and development practises..."

Det är ett artigt sätt att säga: "Skälet till att ni är sjukt oagila kan vara att er produktledning suger, och Scrum kommer att avslöja precis detta." Ofta så visar det sig att de som "fastnat" har stannat inför just detta: rotorsakerna till ineffektiviteten finns hos produktledningen, men viljan att förändras är inte speciellt stor på den nivån.

Då kommer man inte att komma någon vart. "...so that you can improve." står det. Du måste vara villig att förändra dig om du vill komma åt effekten.

Vad måste synkas då?

Vad måste göras lika då, i en stor organisation som försöker utveckla agilt? Måste man inte likrikta?

Det är inte organisationen som styr det utan värdeflödet. Om ett team självständigt kan leverera värde behöver det inte synka med någon annan. Om ett team måste leverera värde tillsammans med ett annat team är det dessa två team som behöver synkronisera med varandra. Om det finns ett projekt eller liknande som håller samman utvecklingen måste alla teamen vara synkroniserade med projektets planeringsrytm.

Det betyder inte att teamet inte kan ha sin egen takt. Det betyder bara att den takten behöver vara synkroniserad med omgivningens behov av planering, beställning, och leverans. Inga dikterade sprintrytmer alltså, däremot att man uttrycker sina behov för varandra och går varandra till mötes.

Backloggstrukturen som rör de gemensamma delarna. Ofta behöver enskilda funktioner utvecklas gemensamt av olika team. Då behöver beskrivningen av funktionerna vara överenskomna, och beskrivningen av de enskilda paketen. Men de olika teamen behöver inte bryta ner funktionerna på likartat sätt till likadana sorters skivor. Projekt och program ska ändå inte följa upp på den delnivån, det sköter teamet så bra självt. Inget detaljreglerande av teamets egen del av backloggen alltså, nöj er med att skapa en gemensam förståelse av de delar som är gemensamma.

Prognoser i timmar och datum. För att kunna synkronisera och ha kontroll över kostnaderna behöver man ha någon sorts aning om när i tiden saker blir färdiga och hur mycket de kostar (oftas i persontimmar). Det finns inget skäl att kräva att team ska använda estimering för att skapa sina prognoser, inget skäl att kräva att estimeringen ska bygga på storlekspoäng, och det finns inget skäl att försöka ensa storlekspoängen med varandra. Diskutera i datum och persontimmar istället, med konfidensintervall. Det är ju det som storlekspoängsestimering ger oss när den fungerar. Men andra tekniker kan ge antingen ännu bättre precision i prognosen, eller lika dålig precision som estimering fast utan estimeringskostnaden. Kräv inte estimering, kräv prognoser!

Ständig förbättring. Detta är det viktigaste: att varje team och varje gruppering av team som samarbetar med varandra har regelbundna förbättringsmöten för att arbeta bort sina strukturella hinder för agilitet. Förbättring innebär förändring, därför måste allt vara öppet för ifrågasättande, utom just förbättringsarbetet i sig självt. Det är en ständigt pågående aktivitet. Det får ni inte tumma på! Och om teamet inte kan ständig förbättring så får deras närmaste chef visa dem hur man gör. Eller ta in en agil/lean-coach om chefen inte vet hur man lär ut ständig förbättring..

Sund kultur och coachande ledarskap! Vi standardiserar runt följande beteenden: uppmuntran, experiment, kvalitet, transparens, tydlighet, självstyre, tillmötesgående, tillåtande. Från alla. Respektera människan.

Alla måste inte göra lika

En missuppfattning om sk "storskalig agilitet":

"När en stor organisation inför agila arbetssätt måste dessa likriktas!"

Nej. Nejnejnej. Eller: nja, jo, lite, ibland. Men akta er!

Agila metoder bygger på metodutveckling på teamnivå. Scrum, SAFe och andra ramverk är startpunktsmetoder. De erbjuder ett enkelt paket av några tekniker man kan använda för att lösa vissa problem (och har man inte just de problemen ska man inte ge sig på att använda just de verktygen).

Men vad metoderna gör är att de framförallt avslöjar strukturella hinder för agilitet, och genom den strukturerade ständiga förbättringen (i form av retrospektiv och liknande) erbjuder möjlighet att ta bort hindren. Det kräver frihet att experimentera med arbetsformerna.

Den organisation som tar bort möjligheten för ett team att experimentera med arbetsformerna kan inte vara agil. Och likriktning omöjliggör experiment.

Vissa organisationer har dåliga erfarenheter av experiment. Men lösningen är inte att likrikta, utan att bli bättre på att experimentera. Gör man det rätt blir det både säkert, effektivt, och produktivt.

Det är ett stort problem att det mest kända ramverket för agilt arbetssätt i stora organisationer, SAFe, på många ställen uttrycker sig som om likriktning är av nöden. I tidigare versioner av SAFe har man krävt att alla team ska arbeta med tvåveckorssprintar, att alla team ska använda estimering som prognosverktyg, att estimering måste ske med storlekspoäng, och att alla storlekspoäng i hela organisationen ska kalibreras utifrån samma skala där 1 poäng motsvarar 1 effektiv persondag.

Ingen av dessa olika tekniker är i sig fel. Men det finns mängder av exempel på situationer där teknikerna absolut inte ska användas. Om en ledning i onödan har beslutat om att standardisera runt dessa tekniker blir resultatet att det blir svårt att öka agiliteten i organisationen.

För att få agilt att fungera i ett helt värdeflöde krävs synkronisering. Dvs att teknikerna som används i organisationen fungerar tillsammans i harmoni. Från en position uppe i det blå kan det se ut som om likriktning är ett enkelt sätt att garantera harmoni. Men om tekniken du påtvingat en grupp inte harmonierar med deras situation så har du skapat kaos.

Det enda sättet att få arbetssätten smidiga är om de personer som utför arbetet också har friheten att utforma dem, och att de själva bär ansvaret för att arbetssätten harmonierar på ett smidigt sätt. Det sker när ledningen lär dem hur de ska arbeta med ständig förbättring. Ramverken ger vägledning, men de består av tekniker som kan vara mer eller mindre tillämpliga i den aktuella situationen. Man måste välja och vidareutveckla och anpassa, och man måste göra det på ett bra sätt.

SAFe 4.0, den senaste inkarnationen av SAFe, är betydligt mer liberal. Borta är tanken på att alla måste arbeta i samma takt, så länge som de kan samplanera varannan vecka. Fortfarande säger ramverket tyvärr att prognoser ska sättas med hjälp av estimering, att estimering ska ske med storlekspoäng och att storlekspoängen ska vara en gemensam valuta i hela organisationen, men när man går SAFe:s handledarutbildningar så får man höra att även detta är förhandlingsbart.

Viljan att likrikta tror jag kommer ur rädsla. Man vet egentligen inte vad de här teknikerna innebär, så därför saknar man förmåga att välja och anpassa. Men istället för att erkänna sin okunskap och använda lean och agila införandemetoder som bygger på experiment och utforskande, så väljer man att hålla fast vid vad någon någon gång sagt på ett tydligt sätt.

Och det är ju så frestande att tro på tanken att likriktning innebär trygghet.

Smärta? Det är så kulturförändring känns!

Nästa vanliga missuppfattning om agilitet:

"Vi kan inte få agilt att fungera om vi inte först lyckas ändra kulturen!"

Intressant, hur menar du?

"Vi provade det. Vi provade att ha dagliga möten men folk ville inte komma och berätta om vad de hade gjort sedan igår. Vi bad organisationen att prioritera vad de ville att vi skulle ägna oss åt först, men de ville inte bestämma sig. De ville ha allt! Vi slutade leda teamen men de blev inte självorganiserade och produktiva.

Vi gjorde precis som i boken men det hände inte. Vi har inte rätt kultur för agilt. Vi måste först få den att ändra sig!"

Men förklarade ni varför ni skulle ha dagliga möten? Synliggjorde ni problemen som uppstår när man undviker att prioritera? Ledde ni gruppen i konkreta vägar till att bli självorganiserande och produktiva? Stödde ni förändringen med beslut? Tog ni bort gamla beteenden?

Kultur på en arbetsplats är det beteende som vi förväntar oss av oss själva och andra i vissa situationer. Den är alltid vad vi alltid har gjort. Det enda sättet att förändra den är att börja göra på ett nytt sätt, och sedan fortsätta på det nya sättet tills det nya sättet blir det sätt vi alltid har gjort på.

Det gör ont att gå emot det etablerade sättet. Det känns konstigt, det finns inget riktigt stöd för det nya, och egentligen förväntar sig folk att vi ska falla tillbaks till det gamla. Vi behöver påminna oss om varför vi gör på det nya sättet. Vi behöver lyssna på skeptikerna och om det går ta hänsyn till deras invändningar, utan att falla tillbaks. Men framförallt behöver vi fortsätta.

"Men det känns ju så fel! Är du säker på att vi inte ska ändra vår kultur först?"

Det är ju det ni gör. Att det känns fel är ett bevis på just det. Det skaver, och det är precis så en kulturförändring känns!

Det är värdeskapande att säga nej till bra affärer

Det är värdeskapande att säga nej till bra affärer!

Detta är bland det mest kontraintuitiva samband som finns när det gäller produktutveckling (till exempel systemtveckling). Men det är sant. Låt mig förklara:

Din leveransorganisation har en viss bandbredd. Under en given tidsrymd (till exempel ett kvartal) hinner den bara utveckla och leverera ett visst antal värdeenheter (till exempel funktioner, features). Du kan arbeta och investera för att öka din bandbredd, men den kommer alltid att vara begränsad.

Varje värdeenhet har en viss väntekostnad. Varje dygn som en funktion inte är i produktion kostar den dig pengar, antingen direkt (om funktionen ska laga ett kostsamt fel), eller indirekt genom en utebliven effekthemtagning. Att produktionssätta värdefulla funktioner är med andra ord det mest värdeskapande du kan göra.

I varje stund finns det en stor mängd bra förbättringsförslag för din produkt eller tjänst. Betydligt större mängd än vad som kan utvecklas och levereras. På en timme hinner man drömma fram funktioner som tar tusen, femtusen, eller tiotusen timmar att implementera. Listan med potentiella förbättringar är alltid mer än tusen gånger längre än listan över de förbättringar som du kommer att hinna med.

Även om du begränsar listan av tänkbara förbättringar genom att bara ha med de som garanterat innebär en god affär, så kommer den att vara större än vad du mäktar med inom ett givet tidsintervall.

Säger du ja till allt på listan kommer du aldrig att bli färdig med något. Men även om du bara säger ja till en handfull saker på listan kommer det att vara en dålig affär. För om du försöker utveckla och leverera flera saker samtidigt så kommer du att förlänga tiden det tar innan du får ut ens något. Och väntetid kostar. Den kostar summan av väntekostnaden gånger tiden.

Det mest ekonomiska du kan göra är alltså att försöka begränsa antalet leverabler du arbetar med. Fokusera på de viktigaste, de som går snabbast att leverera och som har högst väntekostnad. De leverabler du bestämmer dig för ska du också se över. Går de att minska? Kan du få ut åttio procent av värdet på halva tiden? Hälften av värdet på trettio procent av tiden? Är de paretoeffektiva?

För att få bandbredd nog att få ut någonting alls behöver du säga nej. Av tio bra projekt behöver du säga nej till nio. Du måste tacka nej till nio potentiellt bra affärer för att få utrymme att leverera en faktiskt bra affär.

För det är bara de produktionssatta leverablerna som ger nytta. Säg nej till resten. Det är den bästa affär du kan göra.

Stabila organisationer

Igår skrev jag om missuppfattningen att organisationer ska göras agila för att smidigt kunna anpassa sig efter ledningens oförmåga att bestämma sig. Idag vill jag ta upp ett liknande tankefel:

En agil organisation är en organisation som ständigt organiserar om sig.

Vissa verkar tro att det är kompetensmixen som i varje ögonblick är problemet. De tänker sig att effektivitet handlar om specialisering, och när de ser framför sig hur en avdelning måste hantera ett antal olika uppgifter tänker de sig att varje uppgift kräver ett team som är precist sammansatt för att hantera just denna uppgift.

Följden blir att de föreställer sig att medarbetarna bäst organiserar sig i väldigt tillfälliga team. Och när de hör om "sprintar", iterativt arbete, som ett slags litet miniprojekt på ett par veckor, tänker de sig automatiskt att varje sprint innebär en helt ny arbetsgrupp.

Men specialisering är bara effektivt om transaktionskostnaderna är låga. Om det löpande bandet löper smidigt och förutsägbart, om överlämningarna mellan specialisterna sker utan spill. Och det händer inte om man hela tiden förstör organisationen genom att skapa nya konstellationer.

Kunskapsarbete, där specialisterna hanterar kunskap och skapar kunskap, begränsas främst av bandbredden i kommunikationen mellan dem. Särskilt om samarbetet ska vara agilt, där man alltså ständigt omförhandlar sitt arbetssätt efter vad som krävs just nu. Det kräver vissa saker:

Tydliga spelregler. För att kunna agera tryggt under ständig förändring krävs det ett tydligt ramverk som inte förändrar sig ständigt och skapar osäkerhet. Förmågan att hantera förändring och agera agilt bygger på att fundamentet är oföränderligt och stabilt.

Tid. Bandbredd mellan människor bygger på förtroende och att man känner varandra på djupet. Det är en mognadsprocess som kräver tid. Om man omorganiserar hela tiden och bygger om teamen kommer aldrig den bredbandiga kommunikationen mellan människor att uppstå.

Gemensamt syfte. Vår drift att bilda täta ingrupper med varandra triggas av att vi ser ett gemensamt syfte. Ska vi bygga en stabil grupp behöver vi ha ett gemensamt syfte som står sig över tid. Här har ledarskapet sin viktigaste uppgift: att peka ut vad som är det gemensamma syftet som står sig över tid. The constancy of purpose.

Man kan likna en agil organisation vid en terränggående bil. Den utsätts för ganska många prövningar där den tar sig fram i okänd terräng. Förmågan att kunna hantera det kommer sig av att själva bilen är stadigt byggd.

Därför bygger många agila tekniker på tvärfunktionella arbetslag som hålls stabila. Ständiga omorganisationer som påverkas vilka vi arbetar nära förstör organisationens förmåga att agera agilt.

Lättrörligt, inte rörigt

I takt med att jag får utbilda och coacha fler som befinner sig utanför IT-världen så möter jag fler och fler märkliga omtolkningar av vad organisationsagilitet innebär. Till exempel detta:

En lättrörlig organisation kan snabbt byta riktning. Det är bra, eftersom jag som ledare behöver byta riktning hela tiden!

Fel. Att byta riktning är visserligen en bra grej att kunna. Men om du byter riktning hela tiden så kommer vi ingen vart. Minns varför vi vill vara agila: allt går ut på att bli så bra på att möta människors behov som möjligt. Vi vill vara agila för att det ger oss förmågan att skapa värde. I en komplex och snabbfotad verklighet vet vi inte riktigt hur vi bäst möter behoven, så vi behöver förmågan att söka oss fram till det. Vi behöver kunna validera antaganden, förkasta de som inte gäller, och ändra oss löpande. Införliva insikterna.

Tänk på Demings ord om Constancy of purpose. Tänk på Simon Sineks Start with why. Det finns skäl till varför vi finns som organisation, skäl som inte ändras hela tiden. Det är din uppgift som ledare att ständigt lyfta fram vad mitt i all förändring som förblir.

För då kan nämligen dina medarbetare, inte du, använda de operativa agila teknikerna för att behålla rörligheten och styra organisationen mot måluppfyllelse. Det är inte din uppgift att styra, utan det är din uppgift att peka ut riktningen, och sedan snabbt reagera med stöttning och resurser när de som styr - golvet, organisationens fingerspetsar - signalerar att de har viktiga behov.

Det är i alla hänseenden inte din uppgift att vela fram och tillbaks. Har du det beteendet bör du nog ta av dig kaptensmössan och fundera på vad ledarskap betyder.