Scaling agile

I've had some conversations regarding "scaling agile" recently, with people from other countries than Sweden. I promised them to put together blog posts on how I teach and coach agility in an organization that spans many departments, many teams, and many components. For their sake I try to do it English which is my second language, so bear with me.

Scaling

The descriptions of the agile methods such as Scrum often focus on the convenient small scale: the whole client organization may be represented by a single Product Owner, the whole IT-department by the cross-functional team (max 9 persons) that actually has the competence to create a full feature end-to-end in the few objects that they need to manage, etc.

As soon as the reality is more complex than this (many objects, many teams, many departments, complex platform, different technologies etc) you will need to scale. Scaling can be done in many dimensions, depending on where you actually have the increased complexity; and when we do, we must be sure that we keep our focus on maintaining our agility

Agility

First: remember what it is we want to achieve when we use "agile" methods. Remember that the "agile" methods aren't agile at all, but that they help us - if the methods are properly applied - to become more agile in our collaborations. There is this constant need for any organization that develops new software and IT-based services to change direction quickly, since development is all about discovering new things:

Aha, the reference user group didn't understand the proposed user interface! Let's change it! Ooops, we found hidden complexity in the organization's view on what actually constitutes a customer! Integration to System Gizmo is problematic since it shows that Gizmo cannot handle UTF-8 data as it said it could!

The inherent inability to plan ahead development calls for a more flexible way of controlling the value creation in a collaborations focused on developing things, than what project models that rely on extensive planning can do. Hence the rise of the "agile" methods, and a manifesto that says that it is more important to be able to respond to changes, than be able to follow a plan.

Inspect & Adapt

The thing that actually makes us agile, our ability to change quickly in respond to new circumstances, comes from an increased ability for all of us to actually see the current situation as it is; and an increased ability to change accordingly. In agile circles this is called "inspect & adapt", and it is an observation that the frequency of our inspect & adapt-events will determine our agility. Faster feed-back loops means better steering ability.

All the practises that make up the different agile methods (a method is basically a bunch of practises thrown together in a bag), aims at increasing either the ability to inspect, or the ability to adapt, or both. In particular, they aim to increase the transparency of our work (you cannot inspect if things aren't visible), and they want to increase the power (=ability to steer) on all levels by shifting mandate around and make sure the ability to govern follows the right to govern.

This can be seen in such practises like the self-organized team (increased ability to adapt by delegating mandate to the level where the expertise is), a visible backlog showing the status of both all items and their actual prioritization (increased ability to inspect by letting everyone see what is going on and what limited organizational resources we actually compete for).

No matter what practise: it will affect either the ability to inspect or the ability to adapt or both, and you can tell if you applied correctly if this actually had that effect in your collaboration.

Transparency

So when we scale agile, we must understand that it is the ability to inspect and adapt we actually try to scale. And since the ability to adapt actually comes from our ability to inspect (a blind driver is a bad driver) we must understand that the primary focus must be to increase the ability to inspect. In a big organization it is important to increase the transparency even more. Here are some tricks we've used in different organizations:

Use a single backlog! Put all items for all project and all teams in a single backlog. In all lean implementations (and doing agile is a lean implementation) one of the top priorities is to visualize the value-chain; and in a development organization the backlog is the value-chain. I will explain the extended backlog in a later post, since this is a crucial tool.

All teams on the same wall! If you can: put the teams (with images of the team members) on the same wall. Maybe their boards as well, but at least a team presentation poster (of the individuals and of the team's responsibilities) together with the team's goals for this and the coming sprints (or what you call your planning horizons).

Big visible calendar! One tricky part of scaling is the synchronization issue. You see your team mates, but seldom put that in the larger context; or here the drum beat / see the conductor. But actually the whole organization share common goals, and those goals will be realized through specific events. In order to increase the visibility and synchronize between teams: have a common visible calendar with all the releases, all sprint demos, and all other events that are important to them all.

These are just some of the simple tricks that you can use to increase transparency among many teams. There are more to scaling than this and I will cover them in more blog posts, but now it is sunny weather and I need to prepare for my son's birthday reception.

Aspektledarskap

Jag har blivit bjuden på fika hos företaget Green Bullet, konsulter som jobbar med att hjälpa organisationer att införa smidiga arbetssätt i personalhanteringsprocesserna.

Fikat var bra och samtalet ännu bättre, och en sak vi pratade om var ledarskapets roll i de smidiga teknikerna. Ibland talar man om situationellt ledarskap: att en ledare ska tillämpa olika sorters ledarskap beroende på situation.

Med smidiga tekniker går vi ofta ett steg längre: att ledarskapet för olika aspekter av arbetet fördelas mellan olika funktioner, som alltså utövar detta ledarskap samtidigt.

Det viktigaste ledarskapet är målstyrningen. Där bestäms det åt vilket håll laget ska arbeta:vilka konkreta mål och delmål som objekten ska uppnå. I Scrum och många andra metoder motsvaras detta av en produktägarfunktion, och målen visualiseras i en ordnad behovslista. Detta är verksamhetens värdeskapande: VAD som ska uppnås.

Det näst viktigaste ledarskapet är självstyret i arbetslaget. Här bestämmer man HUR man uppnår målet, och man hur man följer upp att målen nås. Detta ledarskap är emergent: beroende på vad laget ställs inför kommer olika personer att träda fram och ta ledande roller.

Detta samspel mellan mål och utförare äger rum i en miljö. Denna miljö måste skapas av en ledning som förstår att skapa ett stödjande ledarskap som kan hantera individuella problem, som ansvarar för rekrytering, lönesättning, och som har allas välmåga för ögonen. Det är framför allt här processerna runt personalen behövs, och där företag som Green Bullet kan hjälpa till, med sin blick för det de kallar "agil HR".

Sedan kommer processtyrningen. För att samspelen ska fungera krävs det att någon smyger runt och tar ansvar för dem. Vi kan kalla det för en processchef eller scrummaster, någon måste få igång samspelen och coacha fram både självstyre och en jämn nedbrytning i delmål och vara den som ser till att alla relationer är positiva och produktiva.

I en mer primitiv organisation har man Chefen på alla dessa positioner. Det skapar både bräcklighet och toppstyre. Smidiga arbetssätt bygger istället på självstyre och resiliens.

Smidighet?

Ja, vad menar vi med smidiga arbetsmetoder?

För det första att smidighet (liksom lean och agile) beskriver en egenskap hos ett samarbete. Smidigheten är resultatet av en process, men processen i sig är inte nödvändigtvis särskilt smidig. Det är inte våra metoder som är smidiga, men våra metoder gör oss - alltså vårt samarbete - smidiga. Vi vill få organisationer att bli som smidiga organismer, genom att tillämpa metoderna.

Tänk på smidigheten hos en som dansar balett. Träningsmetoderna är inte så smidiga och följsamma alla gånger, men kroppen blir det, som ett resultat av att man uthålligt utövar sin konst. Den smidighet vi vill uppnå gäller alltså samarbetena, de mellanmänskliga relationerna i värdeskapandet. Dansaren tillämpar sina tekniker på sig själv, individuellt; vi tillämpar våra tekniker på oss som grupp.

Smidigheten vill jag sedan påstå kommer av fyra andra egenskaper man ska försöka öka i sitt samarbete: lättrörlighet, slankhet, styrka och uthållighet.

Lättrörlig (agile)

Att vara lättrörlig är att snabbt kunna byta riktning utan större kostnad. Det är en viktig egenskap för alla som arbetar för att tillfredsställa en efterfrågan som snabbt växlar. Den är också viktig för alla som arbetar med att utveckla nya saker och utforska nya områden: de nya insikterna som hela tiden skapas gör att man behöver tänka om.

Det är inte underligt att termen föddes inom systemutvecklingen, och att de metoder som kallas agila kommer därifrån. Att utveckla system är verkligen att jaga ett mål som hela tiden rör sig i takt med att nya insikter görs. Men lättrörlighet är en viktig egenskap för många samarbeten.

De tekniker som skapar lättrörlighet syftar till att skapa snabba återkopplingar i samarbetet, så att processen styrs empiriskt mot det rörliga målet. Man arbetar som en målsökande missil: inspektera nuläget genom att fråga sig var man är och var målet är; och anpassa kursen därefter. Ju snabbare och oftare man kan inspektera och anpassa, desto lättrörligare är man.

Teknikerna syftar till att öka transparensen (annars kan man inte inspektera) och makten (annars kan man inte anpassa någonting).

Slank (lean)

Slankhet, det som på engelska heter lean, innebär att man städar bort allt från processen som faktiskt inte bidrar till värdet. Att man minskar slöseriet. Är man inte slank, dvs om man gör en massa onödigheter i sitt arbete, så kommer det bli mycket dyrt att försöka bli lättrörlig: tänk hur svårt det är att anpassa kursen för en alldeles för tung raket.

Det här tänkandet föddes inom japansk efterkrigsindustri, och det är inte underligt eftersom man var tvungen att försöka bedriva verksamhet med mycket knappa resurser. Slöserier märks ju inte lika lätt i en överflödsekonomi. På sikt innebar knappheten därför en fördel, eftersom man var tvungna att tidigare och hårdare än konkurrenterna göra sig av med slöseri och spill.

Nu, i en tid då både råvaror och uppmärksamhet är knappa resurser måste alla samarbeten bli slankare.

Stark (fit for purpose)

Med styrka menar jag samarbetets förmåga att leverera. Vad hjälper det oss om vi är lättrörliga och utan tungroddhet om vi till att börja med inte klarar av att göra det vi ska?

Det finns en mognadsutveckling i samarbetet som leder till ökad styrka. Först är man fokuserad på individerna: är det Fatima som ska göra det ena eller andra, eller är det Pelle? Sedan mognar man och inser att det egentligen handlar om att olika roller ska göra saker. Och därefter börjar man fundera: mer exakt vad ska göras. Man får ett fokus på sina processer. Individerna och rolltagningen är fortfarande superviktig, men viktigast är att ha klart för sig vad som ska göras.

Det är här som olika processramverk, som t ex ITIL och andra förvaltningsmodeller kan bli till nytta. De standardiserar olika aspekter av arbetet och gör samarbetet duktigare på att utan risk, defekter och avbrott skapa det värde man vill skapa.

Uthållig (resilient)

För att få de långtgående goda effekterna av de smidiga arbetssätten får de inte rinna ut i sanden. De måste vara resilienta, så att vi hela tiden väljer att hålla fast vid dem. Därför kommer uthålligheten av samarbetets förmåga att vara bra för människorna som ingår.

Processerna innebär inte en orimlig arbetsbörda. Folk hittar sammanhang som stärker dem och där de känner att de kan påverka. Rädsla och tvång städas bort. Det finns ett ständigt förbättringsarbete som tar bort hinder för det goda arbetet. Här samverkar mängder med små faktorer och konkreta tekniker i processerna, i spilljagandet, och i inspektera-anpassa-looparna, så att smidigheten inte bara blir en nyårslöftesgrej utan vidmakthålls.

Till vår hjälp har vi principer och värden, som t ex att respektera människan. Men viktigast i uthålligheten är ledningens roll som kulturskiftare och kulturbärare. Här finns ett helt fält av nyttiga insikter, och jag rekommenderar var och en som varit igång ett tag i sin smidighetsrevolution att börja titta på t ex Management 3.0 eller det som kallas för Rightshifting. Där får ni goda tips i kulturskapandet som hjälper er att bevara den smidighet ni är på väg att uppnå.