Smidiga saker

Jag håller ju på att skriva en liten bok som heter "Smidigt - Agila arbetssätt för en vanlig arbetsplats". Den innehåller ett antal smidiga tekniker lånade från agil systemutveckling och från lean, men beskrivna på ett sånt sätt att de går att tillämpa i många sorters arbeten.

Några av teknikerna hänger intimt samman med varandra, nästan som ett metodramverk. Jag tänkte att jag skulle beskriva lite av det i en post. Så bort med engelskan och bort med systemutvecklingen: nu ska jag berätta om smidiga arbetssätt.

Laget

För att öka värdeskapandet och minska risker och negativ stress försöker man att samarbeta om en värdeström (=saker som gör en mottagare glad) i arbetslag om upp till 8-9 personer. Alla i laget har inte samma kunskaper och färdigheter, och kommer därför aldrig att kunna göra varandras arbetsuppgifter fullt ut, men man försöker så långt det är möjligt att samarbeta.

Laget är självorganiserade, dvs de bestämmer själva (inom givna ramar) hur arbetet ska bedrivas, men de är inte självstyrande eftersom det handlar om att betjäna en mottagares intressen. Vad som ska göras kommer i slutändan alltid att bli givet utifrån.

Inkorgen

Det vanliga är att arbetsuppgifter flödar in över människor på ett lite okontrollerat sätt. Det viktigaste för att få smidighet på arbetet är att varje arbetslag centraliserar sin inkorg. Kanalerna in till laget kan fortfarande vara flera och till och med gå via olika individer i laget; men därifrån måste ärendena samlas på ett och samma ställe så att man kan ha kontroll över dem.

Förfining

En värdeström har en början och ett slut. När ärenden kommer in i lagets del av värdeströmmen är de troligen inte tillräckligt väldefinierade för att man ska kunna börja jobba med dem, de har troligen inte ett väldefinierat slutmål beskrivna så precist så att man kan otvetydigt avgöra om ärendet är klart, och vi vet förmodligen inte hurpass stora de är. Varje ärende måste göras startklart så att:

• inga avgörande frågor är obesvarade,
• vi vet hur vi ska kunna testa om ärendet är färdigt,
• vi vet någorlunda om det kan göras färdigt inom en dag, en vecka, en månad, ett kvartal, eller längre än så.

Att föra ärendet till att bli startklart kallas för förfining och utförs av hela eller delar av laget vid behov. Det är vanligt att laget skapar en veckorytm där särskilda tillfällen viks åt förfiningsarbete.

Tidsramning

Att skaffa sig en idé om hur stort ett mål är, det krävs för att kunna planera men också för att kunna förfina det till rätt nivå. Därför måste man se vilken tidsram som gäller för varje ärende. Ärendet måste tidsramas. Observera att detta inte är detsamma som en tidsuppskattning där man (mycket osäkert) gissar hur lång tid saker tar för att bli färdiga. Istället gör man en grovskattning om vilka tidsramar som krävs:

• Är det här klart inom en dag? Då är det ett dagsmål (D).
• Om inte: klarar vi av detta inom fem dagar? Då är det ett veckomål (W).
• Om inte: klarar vi av detta inom fyra veckor? Då är det ett månadsmål (M).
• Om inte: klarar vi av detta inom tre månader? Då är det ett kvartalsmål (Q).
• Om inte: klarar vi av detta inom fyra kvartal? Då är det ett årsmål (Y).

Så man bör sikta på att kunna uppnå flera dagsmål på en dag, flera veckomål på en vecka, flera månadsmål på en månad, flera kvartalsmål på ett kvartal, och flera årsmål på ett år.

Nedbrytning

Även årslånga projekt utförs i dagsetapper. Årsprojekt bör brytas ner i månadsmål, månadsmål i veckomål, och veckomål i dagsmål. Så snart man har förfinat ett ärende och antagit att ärendet tar en vecka eller mer, måste man bryta ner det i delmål. Delmålen blir egna ärenden som först är oförfinade och sedan startklara. Är de nedbrutna ärendena större än dagsmål bryter man ner dem ytterligare ett steg osv.

Prioritering

Det troliga är att lagets arbete är en flaskhals i värdeströmmen, dvs att det finns fler önskemål om att de ska utföra värdeskapande ärenden än vad de hinner med att utföra. Det betyder att prioritering blir viktigt: vad är det vi inte ska göra?

Prioriteringen äger alltid rum inom en struktur som är större än laget. Det kan hända att laget är betrott att prioritera helt själva, men det sker ändå på delegation från någon yttre intressent. Om inte annat så sker det på delegation från en kund. Hur prioriteringen sker, om det är en prioriteringschef som griper in, om det är en utsedd styrgrupp som fattar besluten, om laget prioriterar enligt vissa på förhand uppsatta regler; det spelar ingen roll. Det viktiga är att den är tydlig och att den sker direkt vid behov.

Det finns många ställen som ska prioriteras: I vilken ordning ska ärendena i inkorgen förfinas, i vilken ordning ska de förfinade ärendena utföras, och i vilken ordning ska vi sedan testa av att de är korrekt utförda? Utan prioritering kan vi inte arbeta. Därför måste laget sätta krav på sin omgivande organisation, särskilt ledningsfunktionerna, för att få till en vettig prioritering.

Akutärenden

Akutärenden är specialfall som tillåts köra över all prioritering och alltid gå först. De måste ändå igenom hela kedjan: förfining, tidsramning, nedbrytning, ytterligare förfining osv.

Prognosmakande

Ett veckomål tar inte precis en vecka för laget, och ett dagsmål tar inte precis en dag. Beroende på omständigheter kan man klara av flera dagsmål på en dag, eller sitta en vecka med ett dagsmål. Det spelar ingen roll. Det intressanta är att laget i genomsnitt kommer att klara av ett visst antal dagsmål på en vecka. Det är veckorytmens hastighet. På samma sätt kommer laget att klara av ett visst antal veckomål på en månad, och ett visst antal månadsmål per kvartal.

Det betyder att vi kan titta på ett ärende och givet dess förhållande till andra ärenden få en idé om när i tiden ärendet kommer att bli färdigt. Erfarenheten visar att precisionen man får i prognoserna är mycket bättre om man på detta sätt mäter ärendenas hastighet och baserar gissningarna på detta data. Dock kommer akutärenden alltid att kunna slå sönder dessa planer.

Fasta datum

Alla ärenden kan ges datum i form av prognoser: givet den här hastigheten och prioriteringen, så kommer detta ärende att vara färdigt vid en viss tidpunkt. Ett ärende som har ett fast datum, en deadline är något annat: ett datum som måste hållas. Det betyder att ärendet ges rätt att, precis som akutärendet, slå sönder den övriga prioriteringen. Skillnaden mellan akutärenden och ärenden med fasta datum är att de fasta datumen bara slår sönder prioriteringen om det fasta datumet är hotat.

Bokslut

Efter varje vecka samlar laget ihop de färdiga dagsmålen. Man

• Räknar hur många icke-akuta ärenden man gjort färdigt, dvs lagets hastighet.
• Ser hur många persondagar veckan innehöll (normalarbetstiden minus frånvaron).
• Räknar hur många procents övertid man lade (bör vara noll).
• Uppskattar hur många procent av tiden (tioprocentsintervall per person räcker) som varje ärende tog, både akuta och icke-akuta.

Dessa enkla siffror kan ge enormt stor planeringskapacitet och förmåga till budgetuppföljning och information till hur man ska kunna förbättra verksamheten.

Liknande bokslut kan göras efter varje månad, kvartal, och år.

Flödestavla

Det är smart att samla alla ärenden på en tavla. Ett exempel på en tavla har en rad för varje horisont (vecka för alla dagsmålen, månad för alla veckomålen, och kvartal för alla månadsmålen). I varje rad finns kolumnerna ospec, startklar, prio, utförs, verifieras, klart. Vem som jobbar med vad synliggörs med personliga magneter (begränsa antalet per person). Tavlan brukar dessutom innehålla inkorgen samt den första priolistan, och lite annat som behövs.

Metodvägg

Laget skriver ner sitt arbetssätt, t ex noteringar om när de olika mötena hålls osv, i enkla punkter att sätta upp på väggen. Att göra sitt arbetssätt uttalat och synligt gör det lättare att ta ansvar för det.

Tjänstekatalog

Ett av de viktigaste dokumenten på metodtavlan är den som presenterar lagets tjänstekatalog, en beskrivning av varje tjänst som de utför för sin omgivning. I det dokumentet skriver man upp vad som krävs av en beställing av varje sort, hur man kan vänta sig att den behandlas osv.

Förbättringsmöte

För att kunna ta ansvar för sitt eget arbetssätt och förbättra sin metod har laget med jämna mellanrum förbättringsmöten. Där ser man vad nästa delmål i processförbättringen skulle kunna vara, man gör en rotorsaksanalys för att se vad det beror på att man inte redan är där, och man beskriver ett nytt experimentellt arbetssätt som förmodas kunna avhjälpa bristen. Laget beslutar om att genomföra experimentet under en period och bokar upp en uppföljning där man beslutar om den experimentella förändringen ska permanentas (och metodväggen uppdateras).

Förbättringstavla

Förslagsvis använder man A3-analys för att arbeta med förbättringen. Sätt upp A3-orna på en förbättringsvägg. Läs på om och träna på A3-analys och Toyota Kata för att få mer konkreta tips på hur man kan följa upp sin förbättring.

Synkmöte

En gång om dagen brukar laget samlas till ett kort (max 15 minuter) synkmöte stående framför flödestavlan, där man stämmer av hur det har gått hitills och hur man behöver hantera det. På synkmötet hanterar man uppkomna svårigheter och ändrade prioriteringar, och man ser hur man behöver fördela sin tid mellan utförande, verifiering, prioritering, förbättring, förfining och nedbrytning. Synken är bland de viktigaste mötena man har, och det ersätter många andra möten.

Sammanfattning

I princip så ser ramverket ut. Ni som arbetat med Scrum, Scrumban, Kanban, förbättringsmöten i lean osv känner igen er. Skillnaden mot Scrum är bl a att jag rekommenderar en flödestavla som kan hantera flera rytmer (inte bara en enda sprintrytm), att flödet uppdateras löpande (ingen nollställd tavla), att jag inte pekar ut en explicit metodcoach (motsvarande en "Scrum Master") eftersom tanken är att laget tar ansvar för detta, och att jag inte pekar ut en explicit prioriteringsperson (en "Product Owner") eftersom jag ser att det snarare är en funktion än en roll, en funktion som kan behöva täckas av flera roller och personer i en organisation.

Många som haft mig som agil coach känner igen delarna, för det är de här teknikerna jag brukar ta till för att hjälpa lag att hantera t ex polyrytmiska flöden, planerings- och prognossvårigheter, eller frånvaro av prioriteringar.

Jag är också rätt explicit med vilka tekniker jag tycker att folk ska använda (treskiktad flödestavla, Toyota Kata och A3, metodvägg etc). Därmed inte sagt att man måste. Det här är en startpunktsmetod: börja så här. Sedan använder man förbättringsmötena för att skapa något ännu bättre av det.

The position for a Scrum Master is open!

(Another attempt to blog in English, since this is a commentary to this post by Henrik Berglund.)

Position now open. But what is the proper position for a Scrum Master then?

According to the very definition of Scrum: the Scrum guide, the role of the Scrum Master is to make Scrum understood and enacted. As a Scrum Master, you don't have any formal authority to do so, so you have to resort to helping others understand their parts. The guide talks about understanding and helping others to understand.

In that sense, the position of the Scrum Master (or a similar coach-like servant leader when other frameworks than Scrum is being used) is always needed. Just as Henrik points out: we are never fully learned. And still I think that it is a worthy target for a Scrum Master to try to make herself unneeded. Or rather: her current position unneeded.

I look upon it as an instance of situational leadership. While the overarching goals remains (developing high value through optimizing flow and value generation), the actual job description have to change continously. In an organization involved in some kind of agile transformation, things change with time:

Knowledge of the framework change: When you start out with Scrum or Kanban or some other approach, people will need a lot of hand holding. The Scrum Master will need to facilitate the events by booking them and even leading them to begin with. With time, people will learn to manage these themselves, if the Scrum Master helps them take that responsibility. While the Scrum Master exists to make Scrum happen, Scrum isn't supposed to die when the Scrum Master is away.

The team matures with time: The dynamics of the group evolves with time. Bruce Tuckman noticed that the maturity of the team can be measured by its ability to reach good collective agreement. As Wikipedia states it:

These high-performing teams can function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. By this time, they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channeled through means acceptable to the team.

Helping them to reach there and remain there is a constant responsibility of a team coach. Exactly how it is done varies greatly, and a lot of the things the team need help with in earlier stages of their development, they will be able to take on themselves. In this sense, it is good for a Scrum Master to make herself unneeded.

The organisation matures with time: Here is where I see that the job of a Scrum Master / agile coach might be a transitional phase in an organisation's development. If you start Scrum in a hostile environment, fx an organisation where certain fundamental truths about software development isn't regarded properly, a lot of energy needs to be spent on protecting the team from bad management decisions. You will create some agile bubbles by fending off too heavy and/or too vague work items being pushed; and try to minimize the impact of bad incentives and other mangagement dysfunctions.

But that will probably change with time. When we use visual management to become good at showing the impact of bad decisions, the decisions will be better. When more people in the organisation becomes aware of the fundamental psychological and mathematical truths that every member of the lean family (of which agile is one) is built upon, the management will no longer stand in the way for team development.

And when that happens, why can't the management take on the coaching servant leader role? Do we need a separate Srum Master role for this?

In mature lean organisations, it is the floor-management, the manager closest to the team, who take on the responsibility of coaching the team on its continuous improvement journey. This is a natural step in meeting the need that Henrik points out: Organizations need to learn how to learn. It is obviously a waste having both a management structure that works against agility in the organisation, and then have a Scrum Master who is there to minimize the impact of the bad management. The natural fix after a root-cause analysis would be to fix the management.

However, the path for an organisation to walk before they understand this might be long, and it is clear that the majority of the organisations have a need for guides who can help them do the walk. Our job as agile coaches are far from over. But I can definitely see that it is a transitional phase, and when that is over we need to take another job. Probably as managers of the organisations that now has integrated agile values and practices in their very core.

SAFe and different scaling dimensions

(Since I was asked in English about some of my views on the Scaled Agile Framework, I will try to blog in English, even though it is not my first language.)

I have spent the greater part of my consulting time the last three years in larger organisations that are trying to achieve more agility in their systems development, so questions of how one handles different scalability issues when it comes to lean and agile has been quite important to me. One can not mention the words "agile" and "scale" without thinking of Dean Leffingwell's Scaled Agile Framework ("SAFe"), and when trying to be agile at a scale you have to deal with one or more of the issues that he touches. So it doesn't matter if you choose to follow his advise in a particular question or if you choose do the opposite: you need to have an informed opinion of what the SAFe says and why it is wise to follow or go against in your particular case.

First, you need to understand what you mean by "scale". The context of the Scrum definition is a product where a single Product Owner can prioritize among customer values - often in the form of features -, and a integrated cross-functional team can implement at least one feature within the boundaries of a couple of weeks. As soon as your reality transcends that, you need to employ some strategies in order to cope with it. Some of those strategies might be of the sort that they break the rules of Scrum.

Here usually comes the first set of criticism against attempts to scale: "This smells of component teams!", "You shouldn't have to coordinate among several teams, why can't they self-organize?", "You should be able to show an integrated piece of functionality after each sprint!" To which the thoughtful reply always is: "Well, yes, but if we can't?" Certain problem and solution domains are so complex that we need to take time, to use many teams, to build up a small testing debt once in a while. It is not by choice, we have inherited the complexity, and now we have to do the best we can with what we have.

Scaling is basically done along the dimensions of either the number of people necessary to create the value, or the time neeed, or both. We might need more than one team, and we might need more than one sprint. When you think of it, both the Scrum team and the sprint are in themselves scaling techniques along these dimensions: if you need more than one person, use a cross-functional team; and lock the requirements for 2-4 weeks (and call that period a "sprint") before integrating, since it will probably take more than a day to implement. SAFe is basically an extension of those Scrum strategies.

Even the single team organisation has in fact a scalability issue: that of time. Even where you can develop single features within a sprint, features are often meaningful only in contexts together with other features, for instance to support a whole scenario for some user. So even in the small scale you will probably have to coordinate implementation activities over time, aggregating sub-goals towards a more valuable bigger goal. The act of identifying important larger goals and decompose them into smaller but meaningful slices is called "refinement", and the backlog very much resembles a refinery where crude ideas enter at the bottom (like crude oil) that will be clarified and broken down further up.

While cracking and refining crude oil is a continuous process, refining backlog items is best done in distinct levels. Dean Leffingwell's book Agile Software Requirements (which would later be developed into the SAFe) proposes three distinct levels of the backlog, expressed as three distinct backlogs: the portfolio level, the program level, and the team level. The levels are typically coordinated with time frames of the different planning horizons so that the team level coordinates sprints, the program level coordinates releases, and the portfolio level coordinate the investments either they are done continuously (which SAFe and beyond budgeting suggests) or on a year-by-year basis.

That approach is in my experience very fruitful. In fact, the backlog is a value stream map of the development. Development is the generation, refinement and codification of knowledge; the backlog tracks exactly that; and when implementing lean (and agile is a lean implementation) you need to organise (and thus scale) around the value stream. In my experience, you often need a bit more granularity in the backlog levels: I often propose the horizons/levels of: within a sprint (2 weeks), an iteration (3 sprints), 2-4 iterations (2-6 months), and a "project" level that tracks initiatives that lasts for half a year up t two years (even if the usefulness of initiatives of that size can be doubted). While the division of the backlog needs to fit the particular situation, this approach of dividing the backlog into sections is fruitful.

SAFe strategies can however be problematic when it comes to how you organise work. The depiction of the backlog levels as if they were separate backlogs owned by separate departments tempts people into organising handoffs instead of using soft handovers involving members from different departments swarming around the items when they need to be refined. While Leffingwell himself always stresses the use of such lean practises instead of wasteful formalism, the presentation of the SAFe easily lends itself to a bureaucratic interpretation as I have encountered many times.

Another problematic area is that SAFe, just as Scrum, doesn't scale well when we need many different cadences - rythms - in parallel. Scrum talks about only one cadence, the sprint, and SAFe expands with adding the concept of iteration (a period of a couple of sprints in which you can develop several parts and integrate them), and a more elaborate description of how you manage releases. Scrum explicitely states that the sprint should rather not be replanned, which is a way of saying that the sprint is the shortest cadence you should allow for, and SAFe talks about the need of having all involved teams using the same takt of sprints and iterations. SAFe even mandates that the different teams should employ the same strategy when calculating velocity and making forecasts.

In my experience, this is where both SAFe and Scrum breaks. First because the domain of them both is limited to just one small part of the product/service lifecycle: the development. When doing development and development only, you might have the luxury of plans that can remain static for two weeks. But I have yet to see even a development team that never have to respond quickly to some external requests. Therefore: every Scrum team I have seen have had to be able to handle several cadences. On a side note, it is also often a bad practise to have isolated teams doing only planned development. The more responsibility and understanding of the lifecycle they can have, the better they understand the user's actual needs and the business value they provide. DevOps are good for a reason.

So since almost every Scrum team need to handle issues on both a daily, weekly, and bi-weekly basis, maybe using Scrumban or some other Scrum/Kanban hybrid, the organisation need to be polyrythmic in more complex figures than what both Scrum and SAFe assumes. A team where 80% of a week's work isn't possible to plan at the beginning of the week, will need to employ different strategies for doing development in a predictable way compared to the team where only 20% of the work has to be unplanned. They need different methods of forecasting, different jidoka conditions, and thus different ways of working. One or two sizes can't fit all situations we end up in. We need to bring in more practices and techniques than what is suggested in Scrum and SAFe in order to make it work well.

So in short: this is why in my experience SAFe suggests many good ways of coordinating the enterprise backlog among several teams and disciplines; but is too limited and can be harmful when it comes to coordinate the actual work.

Att förändra

Som sagt: du (och jag) ÄR inte si eller så. Vi har lättare för att bete oss på det ena eller andra sättet, särskilt i vissa situationer, men att det finns någon statisk personlighet som sätter ramarna för oss är det svårt att finna bevis för. Däremot verkar vi ha en inbyggd bias för att tro på personligheter. (Och det verkar som om vi behöver en någorlunda konsistent berättelse om vår egen person för att må bra, men det är delvis en annan fråga).

Det betyder att folk kan förändra sina beteenden ganska mycket, mer än många tror, och det är en väldigt bra egenskap hos oss när vi kastas in i nya situationer. De som leder en organisation där många människor samarbetar för att uppnå ett syfte är det helt nödvändigt att kunna verka för förändrade beteenden, annars kommer inte att organisationen att uppnå sina syften tillräckligt bra. Risken är istället att folk mår dåligt där.

När jag hjälper människor i organisationer att stärka varandras förändring blir jag hjälpt av att arbeta utifrån modeller om hur människor beter sig och fattar beslut. Modeller beskriver aldrig verkligheten särskilt exakt, utan är fulla av förenklingar, men om de är tillräckligt beskrivande kan de vara användbara.

En modell jag använder är till exempel en uppräkning av saker som påverkar mitt beteende:

• Världsbild - hur analyserar jag situationer, med vilka ord, hur tror jag att världen hänger ihop?
• Attityd - vilka grundläggande förväntningar och angreppssätt har jag?
• Strategier - vilka konkreta beteenden har jag tillgång till (kunskap om, vana vid, osv)?
• Omvärldsbeteende - hur upplever jag att världen möter mig precis just nu?

När mitt, eller andras, beteende behöver förändras så kan jag med hjälp av modellen titta på situationen utifrån dessa vinklar, och undersöka om det finns sätt att påverka världsbilden, attityden, strategierna eller omvärldens beteenden.

När jag fått frågan om jag kan hjälpa till i ett förändringsarbete har ofta de som frågar redan försökt. Men deras modell brukar bara innehålla omvärldsbeteende ("Vi ska försöka ändra på de här yttre begränsningarna, men vi kommer att bli tvungna att acceptera det mesta av dem ändå!") parat med gnäll över felaktiga beteenden ("Men sluta bete dig som du gör!"). I bästa fall försöker de åtminstone föreslå ett par nya strategier att pröva ("Bete dig så här istället!").

Men det är alltför sällan som folk kommer på tanken att attityder i högsta grad är situationsbundna och därför möjliga att påverka. Det är också alltför sällan som folk förstår hur mycket våra världsbilder som påverkar våra beteenden. Man fastnar, helt i onödan, för att man inte har tillgång till så många verktyg. Jag hoppas kunna beskriva en del av de verktyg jag använder mig av, verktyg som då bland annat används för att påverka den här modellen.

Nej, du ÄR inte sån!

Vi tror ofta att folks beteende beror på hur de innerst inne är. När vi däremot ser på hur vi själva beter oss i särskilda situationer, så vet vi ju att vårt beteende just där och då berodde på en mängd olika faktorer som fanns i situationen. Och om vi lägger samman dessa två saker och tänker över det hela en smula så inser vi nog att också andras beteende förmodligen i hög grad beror på deras situation där och då.

Den här tendensen att tänka sig att andras beteende minsann beror på hur de är, den kallas ibland för det fundamentala attributionsmisstaget, och den skapar hos oss en statisk syn på vår omgivning och oss själva. Vi upplever att beteenden verkar vara omöjliga att förändra. Att folk är låsta i sina attityder. Att kulturen här helt enkelt är sådan, det sitter i väggarna, det är kört. Och folk här verkar banne mig vara både lata och korkade!

Men det stämmer inte. Vad vi vet är att våra beteenden i givna situationer beror på attityder vi har med oss in i situationerna, OCH på de strategier vi har lärt oss tillämpa i liknande situationer, OCH på de faktorer som är unika för den här situationen och som får oss att improvisera.

Det betyder att det finns en enormt massa möjligheter för den som vill ändra samspel mellan folk, till exempel inuti organisationer, eller mellan sig själv och sin omgivning. Kan vi hjälpa oss själva eller någon annan att litegrann byta attityd så har det skett en ändring. Kan vi få tillgång till, eller ge någon annan tillgång till, en ny strategi så öppnas möjligheter. Kan vi förändra en av de lite besvärliga situationsfaktorerna, så blir förmodligen utfallet ett annat än tidigare.

På grund av vår tendens att se beteenden som funktioner av folks inbyggda karaktärsdrag har vi skapat en hel språkvärld, en hel diskurs, som förutsätter eller antyder oföränderliga eller svårförändrade beteenden. Vi talar om någons personlighet, att den-och-den personen är lugn, kolerisk, glad, osv. Det här sättet att prata och tänka om oss själva gör det svårt för oss att starta förändringar.

Samtidigt mår vi dåligt och behöver förändring. I våra liv och på våra arbetsplatser. Första steget är att inse att saker går att förändra. Folks beteende, även ditt, beror av en kombination av dispositioner, attityder, vanor, inlärda beteenden och strategier. Genom att laborera med pusselbitarna kan vi förändra hela pusslet.

Mätetal

Mätetal verkar vara dagens tema. Många diskussioner idag och förra veckan har handlat om dem, och jag tänkte att jag får ge en liten sammanfattning runt vissa aspekter av dem som man brukar lyfta fram när det gäller att få smidigare arbetssätt. Det blir som ett litet förtydligande av det här inlägget.

Tre sorter

Lite grovt kan vi dela in mätetalen och "mätningarna" i tre olika kategorier:

1. Hälsoindikatorer. Dessa mäter hur en process eller del av en process mår. Nettovinsten (eller nettoförlusten) på sista raden är en sådan, eller kalendertiden mellan att en beställning är lagd tills att kunden sitter nöjd efter en väl genomförd leverans, eller kanske dagens uppmätta kroppstemperatur.
2. Larmvillkor. Dessa värden är viktiga eftersom de signallerar en allvarlig avvikelse i processen som behöver hanteras. Skenande kostnader är ett exempel, eller så fort man märker att en leveranstidpunkt inte kommer att kunna hållas, eller varför inte nysningar och feberfrossa som indikerar att jag har blivit sjuk.
3. Styrindikatorer. Dessa värden visar för oss vad vi ska göra. Det återstår att se om det alls går att finna styrindikatorer som är relevanta över tid och på flera ställen.

Viss optimistisk management-litteratur runt KPI:er gör ingen större skillnad mellan dessa, utan hoppas många gånger kunna hitta värden som kan fungera som alla tre. Drömmen är att hitta styrande indikatorer man kan kommunicera nedåt ("Gör bara många sådana här!"), och som samtidigt fungerar som larmvillkor ("Nu gör ni inte tillräckligt många!") och som hälsoindikator ("Nu görs det många, allt är bra!").

Sanningen är att i varje verksamhet med lite komplexitet är det högst otroligt att man kan finna ett sådant värde, särskilt ett som står sig över tid. Det är bättre att titta på olika saker beroende på vad man vill åstadkomma, och då se till deras olika begränsningar.

Hälsoindikatorer

Eftersom vi försöker optimera helheter ska hälsoindikatorer mäta utfall av så stora delar av processen som möjligt. Att mäta t ex produktivitet i delar av systemet är meningslöst eftersom detta inte säger något om produktiviteten i helheten. I ett system är inte utfall en enkel summa av delarna, utan samverkan sker på komplexa sätt. Särskilt om vi vill ha stabila mått som säger hur organisationen utvecklas över tid är det viktigt att vi mäter oss på så hög nivå vi bara kan. Hur ser vår totala produktion ut? Hur är vår totala kvalitet? Hur mår vi?

Larmvillkor

Dessa är egentligen inga mätvärden, utan är komponenter i processen, det standardiserade arbetssättet. Larmvillkoren säkerställer att vi reagerar på avvikelser på ett bra sätt och på så sätt garanterar att organisationen - helheten - producerar stabilt, att hälsoindikatorerna inte sjunker. Många som vill tvinga andra, särskilt underställda, att införa mätningar är egentligen i behov av trygga larm.

Ett exempel jag sett flera gånger är ledningar i mjukvaruutvecklingsorganisationer som vill standardisera utvecklarnas sätt att mäta sin hastighet eller standardisera ett visst flödestavelutseende. Idén är att ledningen på så sätt ska kunna röra sig bland tavlorna och snabbt skaffa sig en uppfattning om läget. Men det är ett stort slöseri. All likriktning av processer blockerar kontinuerlig förbättring, och det är dessutom spill att behöva övervaka en process.

Vad som istället behövs är larmvillkor. Om varje utvecklarlag till exempel omedelbart larmar när de inte kommer att klara av ett vecko- eller tvåveckorsmål, så behöver ledningen inte övervaka alla. Vad ska de göra med den standardiserade informationen? Meddela en grupp att de har problem, baserat på det data gruppen levererar? Men det vet väl gruppen redan om? Kan man inte be gruppen flagga när de märker problemen istället? Och på det sättet slippa likrikta allt?

Ingen är betjänt av att mäta produktivitet eller kvalitet eller liknande på lokal nivå. Däremot ha en överenskommelse om vilka avvikelser som är godtagbara, och en process som signallerar när de inträffar så att man kan ta reda på varför.

Förändringar i larmvillkoren drivs bland annat av att de övergripande hälsoindikatorerna visar på ett otillräckligt utfall. En rotorsaksanalys har visat på att en viss del i kedjan behöver ändras, och i samband med förbättringsarbetet där justeras larmvillkoren.

Styrindikatorer

I drömmen om KPI:erna ingår att man ska kunna hitta värden som både berättar var man är och vad man ska optimera på att utföra. Det är en vansklig dröm, eftersom kopplingen mellan utfall och möda sällan är så linjär. Vi blir troligen inte betjänta av varken ett produktionsmål eller kvalitetsmål, eftersom vi inte direkt kommer att kunna styra det ena eller andra. Det är vår nuvarande arbetsmetodik som ger oss dagens resultat, så ska vi förbättra oss är det våra arbetssätt vi ska skruva på.

I en smidig organisation är styrindikatorer aldrig en del av kontrakten mellan organisationens delar. En del av organisationen, till exempel ett arbetslag, tar på sig att arbeta i enlighet med vissa ramar: tar på sig arbetsuppgifter enligt en viss process, prioriterar mellan dem enligt en viss process, rapporterar tids- och resursåtgång enligt en viss process, lämnar ifrån sig resultatet enligt en viss process, och rapporterar avvikelser enligt en viss process. Detta kan sägas utgöra arbetslagets kontrakt med sin omgivning.

Men inom dessa ramar kan laget skruva fritt för att försöka förbättra sig. Förbättringscykeln där man identifierar ett hinder till förbättring och testar ett nytt sätt att arbeta för att eliminera hindret, är en ständigt pågående aktivitet för ett arbetslag i en smidig organisation. Och det är där och då som en styrindikator är intressant. När vi planerar experimentet, dvs att testa ett nytt arbetssätt, tar vi fram relevanta mätvärden som kan visa oss hur vi ligger till idag, och hur vi ligger till när vi har utfört experimentet under en tid. Baserat på de indikatorerna kan vi sedan bedöma utfallet av vårt experiment, och fatta beslut om vi ska permanenta det nya sättet att arbeta på.

Så nästa gång du funderar över mätvärden i allmänhet och styrindikatorer i synnerhet, så fundera på om det inte är standardiserade arbetssätt, larmvillkor, och ständig förbättring du behöver.

[ Uppdatering: Torbjörn Gyllenbring tipsade mig om att påminna om Goodharts lag i sammanhanget. Den brittiske ekonomen Charles Goodhart skrev 1975 angående försök att styra och reglera komplexa samband att "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes." Dvs så fort vi försöker styra direkt för att påverka ett uppmätt utfall i en process, så blir mätetalet värdelöst.

Tänk på en febertermometer och ett sjukt barn som vill gå ut och leka. Säger vi att barnet får gå ut så snart termometern visar 37 så kommer barnet naturligtvis att försöka kyla ner termometern, trots att det ju är infektionen - feberns rotorsak - som vi menar. Det här är en del av kritiken mot Peter Druckers organisationsstyrning mot numeriska mål, "management by objectives". Det är alldeles för naivt att tro att man kan hitta värden som samtidigt berättar för oss sanningen om vår organisation och som vi samtidigt kan styra på. Numeriska värden beter sig inte på det sättet.

Det blir viktigt när vi tittar på t ex hälsoindikatorer. Om vi tänker oss att vi ska styra direkt på dem blir resultatet ofta katastrofalt. Omloppstiden från beställning till leverans är i nästan alla organiationer ett viktigt mätetal. Men det är knappt man vågar säga det, för det finns alltid folk som då får för sig att det viktigaste är att hetsa igenom alla beställningar, oavsett vad som händer med kvaliteten eller organisationens långsiktiga stabilitet. Sådana människor behöver sitta en liten stund och fundera över vad Goodharts lag kan innebära. ]

Out of the crisis, kap 2, punkterna 1-3

Här kommer så en liten genomgång av de första tre punkterna i Out of the Crisis:

1. Constancy of purpose

Den första punkten handlar om att vara framåtblickande. Dagens problem kanske man till viss del löser med effektivisering, dvs att man gör ungefär samma saker som idag, fast på ett mer resurseffektivt sätt. Men det kommer en morgondag också, om man tror på den. Effektiv produktion räcker då inte. Man måste ständigt utveckla tjänsterna och produkterna så att man håller sig relevant. Effektiv produktion av det som ingen vill ha är en meningslös aktivitet.

Istället måste man se till att hålla sig relevant över tid. Deming föreslår att man utgår från människan och hennes behov: arbeta ständigt på att förbättra tillvaron för människor, genom bättre produkter och tjänster. Ett långsiktigt perspektiv är ett motgift mot kostnadsjaktsjukan, den där man uppskattar korta anställningar eftersom de, var och en för sig, är billigare. Med ett långsiktigt perspektiv, när man räknar på värdet över tid, framstår andra saker som värdefulla: utbilda personalen, skapa utrymme för innovation, och värdera företagets resultat om 10, 20, eller 30 år högre än nästa kvartalsrapport. Det gäller att stå emot frestelsen att agera kortsiktigt.

Deming menar att varje verksamhet tydligt ska kungöra sitt syfte att vara uthållig, och att lova att inte säga upp folk till följd av kvalitetsarbetet. Högsta ledningen måste också vara tydlig med att man värderar produktivitet och kvalitet, så att övriga nivåer i organisationen tar efter. Har det kortsiktiga tänkandet premierats under lång tid så har samtliga av dagens ledare avancerat till sina positioner genom sin förmåga att agera kortsiktigt. Där finns ett ledarskapsproblem att ta tag i, och det är högsta ledningens uppgift.

2. Adopt the new philosophy

Deming spinner vidare på den högsta ledningens ansvar att driva förändringen. Den "nya filosofi" han pratar om är det målmedvetna kvalitetsarbetet där man inser hur oerhört dyra alla irriterande småfel blir när varor och tjänster inte håller måttet. USA hade haft tätpositionen när det gällde industrivaror, men nu är Japan (med sitt lean- och kaizentänkande) förbi och det gäller att skärpa sig. Tänkandet måste omfatta hela organisationen. Det kräver alltså ledarskap, att man leder i och till förändring. Inte bara en förvaltande skötsel (management) utan riktigt förändrande ledarskap (leadership).

Nyckelkomponenten är att få alla att förstå varför kvalitetsarbetet är centralt och inte en komponent bland andra. Han ställer en exakt japansk tågtidtabell med blott minutpassning för byten emot slarvet och defekterna i en amerikansk leverans med pärmar han drabbats av. Det slår honom att så få förstår de förödande ekonomiska effekterna av defekter. Folk ser till det lilla sammanhanget och förmår inte överblicka de systemiska konsekvenserna av dålig kvalitet.

Han pratar med en öltillverkare som inte tycker det gör något att leverantören av ölburkar levererar så många felaktiga burkar, eftersom ju leverantören faktiskt ersätter de defekta burkarna utan kostnad. "Utan kostnad"? Deming förundras över att öltillverkaren inte förstår att han faktiskt betalar för varenda en av de dåliga burkarna, inbakat i priset för de bra. Någonstans måste ölburkstillverkaren få betalt för sina kostnader, även när kostnaden består i hens egen oförmåga att leverera en jämn och hög kvalitet.

INGEN tjänar på defekter. De innebär en faktiskt förlust i den samlade produktionsapparaten, och vi är alla med och betalar för dem. Applicera nu den insikten på hela landets aggregerade defekta produktion: enorma summor går förlorade!

3. Cease dependency on massinspection

När en process levererar dålig kvalitet uppstår en tro att man kan höja kvaliteten genom att inspektera alla leveranser så att inget dåligt slinker ut till kunderna. Man gör sig beroende av massinspektion.

Men du kan inte inspektera fram kvalitet i något som redan är producerat, det är för sent då. Tinget är ju redan ihopsatt, med defekten inbakad. "Du kan inte inspektera fram kvalitet!" Detta sade redan den statistiska kvalitetskontrollpionjären Harold Dodge. När inspektionen säger: "Gör om!" eller: "Släng!" så är det redan för sent. Spillet har redan uppstått. Det vi vill förhindra genom att filtrera bort defekterna är ytterligare spill som uppstår när vi tillåter defekterna att gå ut till kunderna.

Istället är det processen som ska förbättras. Själva mätandet är dyrt. Det kostar på att mäta, det kostar på att inte kunna använda den tiden och energin till produktivt arbete, och att ständigt bli påmind om att man skapar defekter är nedbrytande. Eftersom energin läggs på att mäta istället på att förbättra, så kan man inte förvänta sig någon förbättring. En oförändrad process kommer att ge ett oförändrat resultat.

Istället förordar Deming små statistiskt representativa mätningar som visar om processen levererar tillräckligt bra kvalitet, och sedan förbättra processen om kvaliteten inte är tillräcklig. Automatisering löser inte grundproblem. Deming ger ett exempel där folk skriver in registreringsnummer på en blankett. Det blir många felslag och man överväger ett IT-system för att fånga felslagen. Men istället bör man först och främst förbättra processen och blanketterna och göra dem mer lättjobbade, för det är där som rotorsaken till misstagen ligger.

[Den här punkten har fått stor aktualitet i dagens Sverige. Ett flertal offentliga verksamheter kostar mer och mer pengar utan att leverera proportionerligt högre nytta. Det visar sig att flera av dem försöker hantera sina problem, inte genom att få ständig förbättring på plats, utan genom att mäta. Och så snart fler defekter upptäcks (t ex fallande skolresultat) så blir svaret att öka antalet mätningar. William Deming, Walter Shewhart och Harold Dodge från USA, eller Shigeo Shingo, Taiichi Ohno och Eiji Toyoda från Toyota; skulle kunna berätta för svensk statsförvaltning varför detta inte hjälper.]