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å.

Vaddå coach?

"Vaddå agil coach?" "Lean-coach?" "Är det en sån där få-varm-känsla-i-magen-grej?". Sådana frågor får jag ofta, så jag tänkte berätta ungefär vad det är jag gör.

I princip handlar det om en enda sak: att facilitera förbättringsmöten. Det spelar ingen roll om det är en ledningsgrupp som vill dryfta ett införande av smidigare arbetssätt, eller ett arbetslag som jobbar med kontinuerlig förbättring, eller folk från flera olika avdelningar som behöver hitta ett sätt att jobba bättre kring ärenden som de har gemensamt. Min syn är densamma: de har ett gemensamt mål att förbättra sitt arbete, och jag faciliterar (=underlättar) för dem att nå dit.

Innehållet

Först och främst måste vi få en gemensam bild av nuläget. För ett samkört lag har man redan detta på plats, och vi kan ganska raskt gå in på flaskhalsar och hinder för förbättring. Men om det t ex gäller att förbättra ett samarbete som idag inte finns eller fungerar trögt, så är det nästan alltid så att bilden av flödet ser olika ut beroende på vem som beskriver det. Då blir det stora och viktiga steget att komma fram till en bild av verkligheten som alla inblandade kan känna igen sig i.

I fokus står värdet. Vem ska bli glad av vårt gemensamma arbete (den egentliga kunden, beneficarien)? Hur? Hur ökar vi tillsammans den glädjen idag? Finns det exempel på hur vi trasslar till det för den människan? Runt det värdeflödet kan vi sedan gruppera våra aktiviteter. Det blir en systemskiss av hur värde skapas i organisationen. Värde för en människa.

Det är vanligt att organisationen istället har beskrivit sig efter hur man är organiserad, och det är ju inte samma sak som värdeflödet.

Sedan måste vi komplettera med lite data. Vad vet vi om hur väl det här värdeskapande systemet fungerar? Särskilt ledningsgrupper som kanske befinner sig ganska långt från golvet behöver kritiskt ifrågasätta sin verklighetsuppfattning och se över på vilka sakliga grunder de skaffar sig uppfattningar om systemets förmågor.

Sedan skapar gruppen insikter. Man ifrågasätter, kartlägger orsakssambanden, och skaffar sig en välgrundad bild av varför det funkar precis som det gör. Gruppen vet att alla system är perfekt konstruerade för att ge precis det utfall som man har idag, och det gäller att skaffa sig kunskap om den konstruktionen.

Det är vanligt att organisationen istället styrs av en massa oprövade antaganden, utan varken data som backar upp eller en analys som håller.

Nästa steg är viktigt. Insikter skapar i sig ingen förändring. Endast förändring ger förändring, dvs att man börjar bete sig på ett annorlunda sätt. Gruppen tittar på de samband de nu känner till, och så bestämmer de sig för vilka de ska försöka påverka med ett annorlunda beteende.

Man ska se på förbättringspunkterna som små experiment: man prövar ett nytt arbetssätt under nästkommande veckor, och så följer man upp och ser om man ska permanenta det. Tanken är ju att det här bara är första steget på en resa, och att man tar nästa, sedan nästa, sedan nästa, sedan nästa...

Formen

Det här kan man göra som heldags- eller halvdagsövningar. Det är vanligt att folk köper in min hjälp i form av paket om 4-8 tillfällen, så att jag kan stötta en grupp eller en organisation med regelbunden hjälp under längre tid.

Oavsett vilket så är det ingen magi bakom. De flesta kan genomföra den här typen av övningar utan hjälp av någon utifrån. Det jag bidrar med är erfarenheten: vilka sorters problem är vanliga i vilka sorters organisationer? Hur har andra grupper gjort för att angripa en viss typ av problem? Vad brukar fungera och vad brukar inte göra det?

Ofta blir jag inblandad under en inkörningsperiod. Sedan lär sig gruppen att facilitera sin egen förbättring, fram till en viss punkt kanske ett år bort då jag blir inblandad igen för att ge ytterligare en liten knuff.

Bilden är från en coachning under fältmässiga förhållanden på Sweden Social Web Camp 2012. Workshopdeltagaren Johan Lange förevisar mina analoga slides om spill medan jag i bakgrunden gnager av bitar från en gaffarulle för att sätta upp dem på tältväggen.

Fem svenska S

OK, eftersom jag titt som tätt dyker på det här: jag pratar om lean och folk blir lite tomma i blicken, och jag tvingas fråga dem: "Har ni haft en 5S-konsult på jobbet?" och de nickar. Fem S är en enkel men genial liten pusselbit i smidigt arbete, men på svenska kontor går det just nu runt folk som för dyra pengar berättar att det bara ska finnas en och endast en papperskorg i varje konferensrum och att det på något vis är helt avgörande för resultatet för folks arbete och att det är det som kallas "fem S".

Högst obegripligt. Men vad handlar det då om? Jo, om att det blir smidigare med ordning och reda, och att om en smidig process är på plats så blir och förblir det ordning och reda. Och att arbetet med att ta fram den processen driver så mycket god förändring att man häpnar.

Det handlar om min källare

Men vad är det då? Jo, det är till exempel att min källare med alla snickargrejerna ser ut som hej-kom-och-hjälp-mig. Jag behöver Städa.

Städning i min källare går till så att jag tar en grej, till exempel en hammare, och så går jag runt i en kvart tills jag hittar en hylla där det finns en liten tom fläck över. Där lägger jag hammaren. Sedan går jag runt med en färgburk i en kvart tills jag kommer på att den minst dåliga platsen är balanserande ovanpå hammaren. Och så vidare, och så vidare...

Nä, man spiller helt enkelt en massa tid och tankemöda (beslutsmöda!!!) på att försöka improvisera fram nya platser för saker och ting. Tänk om man istället tog sig tid att Systematisera alla grejerna. Först skapa en plats för varje sak, sedan lägga var sak på sin plats. Det hade varit smartare. Så jag bestämmer att färgburkarna ska upp på hyllan, och verktygen ska hänga på väggen.

Men bäst som jag spikar upp verktygskrokar på väggen så slår mig en sak. Jag har flera likadana hammare. Skulle jag inte kunna nöja mig med att hänga upp den bästa av dem på väggen och stuva undan de andra. Och jag har färgburkar med intorkad färg som aldrig kommer att användas. Innan man systematiserar kanske man borde Slänga? Skapa system för burkar och verktyg jag ändå inte behöver ha framme, vad ska jag göra det för?

Så där är då de tre första S:en på plats, i den ordning där de skapar minst slöseri:

• Släng först det du inte behöver, sedan kan du
• Systematisera genom att skapa en plats för varje grej, och först därefter
• Städa för då kommer du bara att städa nödvändiga saker som har plats. Inget mer improviserande med hammare och färgburkar.

Det kommer ju aldrig att hålla!

När jag snickrar, hur gör jag då? Jo, jag kommer på vad jag ska göra, tar fram material, tar fram verktyg, sätter igång, och när grejen är färdig går jag iväg med den...

...och funderar inte på vem som ska ta undan överblivet material, hänga upp verktygen på sina platser, och sopa av bänken! Nä, så länge jag gör på det vanliga slarviga sättet lär det inte hålla. Jag behöver hitta någon sorts Standardprocedur för att få det att fungera.

En nyckelgrej med lean är skillnaderna mellan processtegen som ökar värdet på en artefakt, och artefakten i sig. Artefakten är det stycke värde som ramlar genom vår process. Den ska tillverkas eller förädlas hos oss, genom arbetet vi gör. Sedan ramlar den ut till mottagaren, och vi påbörjar förädlingen av en ny artefakt.

Artefakten förändras i processen, men processteget förändras inte. Starttillståndet för ett processteg är istället identiskt med sitt sluttillstånd. Processtegen är cykliska, och därmed väldigt resilienta. Så om starttillståndet är att verktygen hänger på väggen, materialet i sina lådor, och bänken är tom; då ska också sluttillståndet vara så! I min standardprocedur ska jag alltså återställa verkstaden. Annars är jag inte färdig.

Detta cykliska sätt på standardprocedurer skapar stora effekter i organisationen när man är Ståndaktig med procedurerna och stannar kvar i dem. Så de får bli vårt femte S: att vi vågar hålla ut för att se hur dessa nya rutiner påverkar oss på lång sikt. Saker kommer att hända. Vi justerar arbetssätten efter verkligheten.

Alltså

Det är detta som är fem S: man tittar på vad som är värdeskapande, och så bygger man processteg runt detta värdeskapande som inte resulterar i ökad kaos eller spillprodukter som inte tas om hand. När man bygger ett processteg kollar man vad det är för grunkor som faktiskt behövs, slänger resten, skapar en systematik där varje grunka har sin plats, man städar, standardiserar processen genom att bestämma hur och när det fortsättningsvis ska städas så att processteget alltid är redo att ta emot, och så är man ståndaktig och hänger i.

Det kanske är superviktigt att det bara finns en papperskorg i konferensrummet. Men troligen inte. Ofta drivs leansatsningar i kontorsmiljö av att optimera själva kontorsarbetet: man blir bättre på att ta kopior, slå hål, sätta in i pärmar, sitta av tiden på möten osv. Men kontorsarbetet är ju sällan värdeskapande i sig. Det är kunskapsarbetet som sker på kontoret som utmynnar i värdet. Kontorsarbetet är bara vägen dit.

Så en ytlig lean-konsult kanske begår lite fem S på ett kontor där ni jobbar. Då är det ju bra att ni nu, med lite djupare kunskaper om 5S kan stötta varandra och peka på att 5S-konsulten borde röja runt lite bland de fjorton nivåerna byråkratiska mellanchefer och då praktisera en smula Släng

1. Släng!
2. Systematisera!
3. Städa!
4. Standardisera!
5. Ståndaktighet!

Läs mer om 5S här!

Lean Coffee Göteborg

Folk världen över som är intresserade av smidiga arbetsmetoder har startat en liten trend: att med jämna mellanrum träffas och diskutera detta över en kopp kaffe: Lean coffee. För att få någorlunda struktur i samtalet börjar deltagarna med att skapa en behovslista (backlog) för diskussionen (alla bidrar med ett ämne), som sedan rangordnas (alla får två röster att lägga på ämnena). Processen beskrivs i denna lilla video.

Nu är tanken att vi gör detsamma i Göteborg. Mellan 7.15 och 8.45, onsdagar jämna veckor sitter vi på Espresso House på Göteborgs Central. Det strukturerade samtalet äger rum mellan 7.30 och 8.30. Tanken och förhoppningen är att få med folk från högst olika branscher och situationer, så att det inte blir ännu en metodgrupp för folk som är i IT-svängen. Målet är intensiv korsbefruktning.

Första tillfället alltså onsdag i vecka 16, den 17 april. Komsi komsi!

Bilden är från @KevinTretherwey.

Självstyre och tydliga processer

Det man vinner med att decentralisera makten över arbetssätten till dem som utför själva arbetet är att ingen längre kan låta osmidigheter finnas kvar. På golvet har vi alltid upplevt osmidigheterna, sett spillen, försökt med våra egna kroppar och hjärnor att kompensera för ett system som beter sig tokigt. Om vi nu tar oss makten över vårt arbete sitter vi plötsligt med ansvaret att göra det i grunden bättre.

Det är en av grundprinciperna i lean: det är på golvet både värde skapas och spill manifesteras. Det är alltså där som både förmågan att se, och mandatet att förbättra ska finnas. Det låter rimligt. Självstyre verkar vara sunt och förnuftigt. Folk i organisationer världen över kan intyga att det fungerar. Vad är det som hindrar?

Det en organisation är rädd för, delvis med rätta, är att decentraliseringen innebär en farlig kontrollförlust. Vad händer om folk bestämmer något heltokigt? Hur snabbt får ledningen reda på det och kan agera? Denna rädsla finns ofta hos både ledning och folk på golvet och förlamar alla.

Att själva rädslan finns är ett tecken på att organisationen har ett större problem: varför är det så farligt att fatta beslut här? Är det farligt för folk på golvet att fatta beslut är det ju lika farligt för dess ledning. Rädslan skapar en förlamning nedifrån och upp: alla vill att någon annan ska fatta beslutet. Ingen vågar ta ansvar. Däremot eskaleras allt uppåt, och ledningen svarar med att öka övervakningen nedåt.

Den smidiga kuren är det som i lean kallas för standardized work. Låt oss kalla det för att vi skapar oss en tydlig process. Idén är att en ledning bara ska behöva hantera avvikelser som kräver extra stöd. Så länge det fungerar som tänkt ska inte en ledning behöva blanda sig i. Då krävs det att vi har definierat "fungerar som tänkt". Att vi har tänkt.

Den tydliga processen har fyra komponenter:

1. En processbeskrivning tillräckligt klar för att var och en inte ska behöva tveka om vad som behöver göras. Den behöver inte detaljstyra mer än nödvändigt: mycket arbete kräver att var och en ges en hel del frihet i utförandet. Men vi ska inte behöva tveka om inom vilka gränser vi har den friheten.
2. Inskrivna randvillkor som gör det tydligt vilka utfall som kräver att vi flaggar till någon annan. När är det kris? När behöver vi assistans? Vilka variationer är acceptabla och vilka är oacceptabla?
3. Avstämningspunkter där vi säkerställer att processen följs och att inga kriser finns som behöver hanteras.
4. En form för kontinuerlig förbättring där vi kan justera vår egen process. Annars stelnar den, och vi har inte längre makten över den. Det ökar risken för mer spill.

För att ta Scrum som exempel innehåller den en processbeskrivning för samspelet inom ett arbetslag utvecklare, och mellan laget och beställarorganisationen. Scrum föreskriver att laget ska komplettera med villkor för hur beställningar får lov att se ut ("Definition of ready"), och kvalitetskrav på de leverabler som laget lämnar ifrån sig ("Definition of done"). Man rekommenderar även att laget skapar föreskrifter om sina "best practises" så att en hög och jämn kvalitet kan uppnås.

Larmvillkoret i Scrum är mycket tydligt: så snart laget misstänker att det gemensamma sprintmålet (målet vi sagt ska uppnås inom en period om ett par veckor) inte kommer att hållas, då ska vi slå larm och få hjälp med en omplanering. Avstämningspunkterna är flera och tydliggjorda: vid planeringen, vid de dagliga tavelmötena, efter sprinten.

Och naturligtvis har vi regelbundna förbättringsmöten som kallas retrospektiv där precis vår process granskas, förfinas, och förändras.

Det är dessutom god sed (rekommenderad t ex i ITIL) att en process har en processägare (process owner) som beslutar om hur processen ska se ut, och en processchef (process manager) som ser till att processen följs.

I en organisation byggd av självstyrande lag är det laget självt som är processägaren. Många har funnit att det även i självstyrande lag är bra med en tydlig processchef, och i Scrum har vi rollen Scrummaster som har precis det ansvaret.

I en organisation där processen är otydlig, både med oklara arbetssätt och oklara villkor för acceptabel variation, är det riskabelt med självstyrande lag. Men i en sådan organisation är det riskabelt även utan självstyrande lag. Om man istället organiserar arbetet i lagen, och bestämmer inom vilka ramar självstyret kan ske, då har man tagit ett stort kliv på vägen mot lägre risk, mindre slöseri, och högre kvalitet. Och det blir ett behagligare ställe att arbeta på, för alla.