tisdag 7 november 2017

Tillitsdelegationen

Jag har tidigare skrivit om Ekonomistyrningsverkets rapporter angående digitaliseringen av svensk offentlig verksamhet, och om regeringens expertgrupp för digitalisering.

Smidiga samarbetsmetoder har ju, som ni som följer bloggen vet, mycket att göra med digitaliseringen. Att utveckla digitala tjänster är att pröva sig fram, och för att lyckas med det krävs agilitet.

Ett annat regeringsinitiativ jag följer är Tillitsdelegationen, regeringens initiativ för att utreda alternativ till yxig målstyrning inom välfärdstjänsterna. Jag höll på att skriva närliggande initiativ, för det är det verkligen, men problemet är att det är alldeles för få som förstår hur dessa två saker hänger ihop.

Vissa vill tvärtom se en motsättning mellan å ena sidan tillitsbaserad styrning (att personal och brukare inom välfärdstjänsterna får större förtroende att utforma utväxlingen) och å andra sidan digitalisering (som associeras med numerisk kontroll av allting).

Och det stämmer på ett plan: i händerna på en galen målstyrare kommer digitaliseringen inte att resultera i ökat brukarvärde utan i kraftigt ökad kontroll av allt (som Jonas Söderström skriver om).

Men det är inte den digitaliseringen folk vill ha. Den digitalisering folk, inklusive folket i regeringen, önskar se handlar om att tekniken ska ge nytta och stöd åt det vi vill åstadkomma. Och sådan digitalisering kan inte toppstyras fram.

Den senaste inkarnationen av metoderna för att få ökad smidighet och agilitet i våra samarbeten växte fram inom systemutvecklingen på 90- och 00-talet. Metoder som Scrum och Kanban samlar samarbetstekniker som möjliggör utforskande tjänsteutveckling och har blivit populära eftersom all bra tjänsteutveckling sker utforskande.

Insikten som slagit många är att även bra tjänsteutförande har mycket utforskande element i sig. Och för utforskande tjänsteutveckling och tjänsteutförande krävs att den som utför det har både mandat och förmåga därtill. Agila metoder bygger på delegering. Lean (när det görs rätt) bygger på delegering. William Demings kvalitetssystem bygger på delegering. Jan Carlzons ("Riv pyramiderna!") och John Seddons (Vanguard) handfasta råd för bra tjänsteutförande bygger på delegering.

Man måste frigöra kraften hos professionen, hos folket på golvet som vet hur man skapar värde.

Tillitsdelegationen arbetar med att försöka utforska hur man kan göra detta inom välfärdssektorn och den offentliga förvaltningen. På så sätt hör de ihop: samma tillitsbaserade styrning och ledning krävs både för att utveckla bra tjänster och för att utföra dem!

Och det är sedan gammalt: Toyotas tankar om smidig produktion är samma som agilisternas tankar om god digitalisering som är desamma som till exempel John Seddons tankar om bra tjänster i offentlig sektor.

Forskningsledaren på Tillitsdelegationen, Louise Bringselius, har i dagarna skrivit en rapport där hon presenterar några begrepp och modeller för hur man kan se på tillitsbaserad styrning och ledning.

Jag har läst den och funderar på vad som står där. Gör det du med!

söndag 5 november 2017

Scrum Hack: Rolling Wave Instead of Sprint

As those of you who have attended my workshop in agile planning know, you can talk about planning in two dimensions:

  1. The percentage of your capacity you want to allocate to planned work.
  2. The planning horizon: how far ahead in time you want to allocate that capacity.

The Scrum Guide implies that a team of developers will allocate 100 percent of its capacity to planned work, divided between implementation of backlog items that the team thinks are ready for development, and refinement activities where the team makes sure that the upcoming backlog items will be ready for development in the future. The planning horizon is a sprint: a regular period of at most one month.

However: the nemesis of all planning is that pesky little thing called reality. During a four week sprint, there are many things that can (and will) happen, so many teams feel that they have to shorten that time. Sprints that are two weeks long have therefore become popular even if it is hard for many to actually deliver value in such short time.

But since reality happens even during two weeks, you might feel the need to replan in the middle of the sprint. And this is where the rolling wave can start to happen if you let it.

When mid-sprint replanning becomes a regular necessity due to circumstances beyond people's control you may ask yourself what planning horizon you should have. Of course you need to replan the rest of the sprint (the last week), but can we say something about the future? The coming sprint?

(The replanning is by the way often conducted directly after daily stand-up monday morning in the second week of a two week sprint.)

The last week we learned that it wasn't wise to allocate 100 percent of our capacity to planned work. Maybe 80 percent is more realistic, so let us do that for this week too. And what do we know about the coming sprint? Maybe we can see the need for like 50 percent? At least for the first week, we know actually very little about the second week of next sprint. Maybe we for the second week of the next sprint can think of work worth about 20 percent of our capacity.

The week passes and it is time for sprint planning for the next sprint. We have already planned for 50 percent of the first week of the next sprint, and 20 percent of the second week. Let's just add some more insights to that plan so that the first week of the sprint becomes planned to 80 percent and the second is filled to 50 percent. (And maybe also look ahead for the coming two weeks after that but not more than like 20 percent of the first week and 10 percent of the second.)

Shouldn't we aim for filling both weeks of the sprint to 80 percent at sprint planning? No, we can't predict the future anyway. Let's keep it planned to 50 percent. We know that we will have a replanning event in a week anyway.

TADAA! The rolling wave is formed. Sprint planning becomes basically an adjustment of the rolling four week forecast that we polish continuously. We can still have our reviews and retrospectives every second, third or fourth week if we want to, but we have a more flexible planning practice in place that in many cases can accommodate the natural variation of development better.

Scrum Hacks: Scrum Buts or Scrum Ands?

There is a tension between the need for adapting a known and proven collaboration framework, and the need for said framework to be allowed to do its job.

I have during my ten years of agile, the last five years as a full time mentor and coach, seen countless of "Scrum" implementations where they had removed everything they found difficult and hard, and therefore didn't achieve what they wanted to achieve.

On the other hand: I have also seen numerous agile collaborations where they applied just the tools they needed at the time, tools that also can be found in different frameworks such as Scrum, but together with other tools and ways of working. And it has been working just fine.

I have during these same years only seen Scrum being run by the book (The Scrum Guide) once. Most of my clients work in environments where the implicit preconditions of Scrum doesn't really apply. So they have to adapt in order to get work done.

Adaptions of Scrum are sometimes called "Scrum Buts" since they are described with the words "We work with Scrum, but...". I think that's appropriate for cases where the organization takes away the things that drive good change and thus never achieves what they have set out to achieve.

I suggest the term "Scrum Ands" for the cases where your situation calls for a slightly different set of tools than what is provided in the Scrum Guide. For when you inspect and adapt the framework, in a way that gives you better outcome than the alternative.

The result of your toolset hacking will not be Scrum, of course. Scrum is defined in the Scrum Guide. Any deviations might be useful, but it will not be Scrum.

However, since Scrum contains most of the elements you need in order to make your collaborations more agile (organizational capability to prioritize, collaborate on value creation in self organizing teams, daily synchronization between people, clarity on what is ready for implementation and what is done, continuous improvement etc.), and since the framework is pretty well known, it can be a good idea to present your ways of working as your own twists to Scrum.

I call them Scrum Hacks. Distinct ways of collaborating that replace or complements existing ways of working in the framework. Like the idea of having retrospectives either more frequent or less frequent than each sprint. Or the idea to plan only one week at a time. Or having an ongoing Scrum meeting in digital channels instead of the daily fifteen minutes standing in front of the sprint backlog.

As soon as you start experimenting with Scrum Hacks, the result isn't Scrum. It can make your outcome worse. But it can also make it better. Reflect on why, and share your favorite hacks with your friends in the community. Let's build a catalog of proven Scrum Hacks that explains under what circumstances they have improved our lives.

What do you think?

lördag 4 november 2017

Nimble Works!

I have started a separate blog for my posts written in English. Read about Scrum Hacks there:

Scrum Hacks: Scrum Buts or Scrum Ands?

onsdag 18 oktober 2017

Effektivisering

På vilket sätt har många verksamheter, i synnerhet offentlig verksamheter, fel om effektivisering? Så här:

Den effekt du vill se är beroende av den struktur du byggt upp. Den värdeskapande strukturen: människorna och tingen och allt de gör, är vad som åstadkommer effekten.

Varje struktur kan bete sig mer eller mindre ändamålsenligt. Samma struktur kan uppvisa lite olika beteenden och på så sätt leverera olika bra effekt.

Så att effektivisera handlar om att människorna inom en struktur utforskar nya beteenden som ger bättre effekt.

Men effektivisering i många verksamheter, i synnerhet offentliga, verkar utgå från motsatsen: att det handlar om att försöka få samma effekt i en förändrad (gärna billigare) struktur.

Det går inte. För i samma stund som du förändrar strukturen kommer förmågan att leverera att minska. Människorna inom strukturen kommer i och för sig att i den nya strukturen utforska olika sätt att återta förmågan, men det kostar på och man kan sällan räkna med att i slutändan få ut samma värde som man fick tidigare.

Några gånger kan det fungera. Under några år kan man kanske lägga ett besparingskrav som visserligen slår sönder förmågor men dessa kan återtas. Men de blir svårare och svårare att återta. Riskerna ökar och marginalerna minskar. Till slut upphör strukturens förmåga att åstadkomma bra effekt (men den kommer fortfarande att kosta).

Istället för att effektivisera har du lagt ett besparingskrav som slår sönder din förmåga att leverera. Gjort dig ineffektiv.

När förmågan att leverera sjunker drastiskt medan kostnaden bara minskar något, då stiger kostnaden per effekt. Fokus på kostnadsminskning har ökat kostnaderna. Detta sker gång på gång och folk blir lika förvånade.

Istället kan man bestämma sig för vilken kostnadskostym man vill ha. Det ger stabilitet.

Man kan slå fast vad det är för effekter man vill uppnå. Vara tydlig med målbilder.

Man kan ge förmågan och mandatet att utforska olika sätt att öka effekten till dem som redan idag vet mest och bäst om hur värdet skapas. Folket på golvet. De som skapar.

Då kommer man att se hur samma struktur levererar mer. Kostnaden per effekt minskar.

Man har effektiviserat.

tisdag 17 oktober 2017

Nådde vi målet?

Fråga 1: Du har ett säljmål på fyra affärer i veckan. Den här veckan drog du in tre. Nådde du målet?

A - Ja.
B - Nej.
C - Det vet vi inte.

Fråga 2: Du har ett säljmål på fyra affärer i veckan. Den här veckan drog du in fem. Nådde du målet?

A - Ja.
B - Nej.
C - Det vet vi inte.

Vi kan förstås på ett ytligt plan svara nej respektive ja på frågan, men påfallande ofta är svaret C: vi vet faktiskt inte! Inte på något meningsfullt sätt.

Det här är en viktig poäng i allt målmedvetet empiriskt kvalitetsarbete, såpass viktig poäng att William Deming gjorde en stor grej av det i sitt "System av grundläggande kunskaper". Många upplever det som lite ointuitivt, men jag ska göra mitt bästa att förklara hur det hänger ihop.

Tänk dig att du har en tidvändare, en mojäng som gör det möjligt för dig att åka tillbaks i tiden precis som i Harry Potter. I Harry Potter (eller i Groundhog Day) var det omgivningen som betedde sig likadant andra gången aktörerna upplevde en viss tidsperiod. Aktörerna kunde däremot agera på ett nytt sätt. Tidvändaren gav dem möjlighet att ändra utfallet genom att ändra sitt eget agerande.

Vår tidvändare fungerar däremot tvärtom, den låser fast oss i vårt beteende: vi kommer att agera exakt som vi gjorde sist det begav sig. Däremot kan omgivningen förändra sitt beteende.

Nu återupplever vi förra veckan, den veckan då vi drog in fem affärer och chefen tyckte att vi nått målet och gav oss veckobonus. Men trots att vi i den här versionen av verkligheten agerar precis som vi gjorde förra gången, så blir utfallet annorlunda. Den här gången blir affärerna bara tre stycken.

Vi har inte ändrat oss. Vad hände?

Det vi råkat ut för är processens naturliga variation.

Utfallet av det vi gör är alltid en kombination av faktorer vi kan kontrollera och faktorer vi inte kan kontrollera. Det finns ett (ofta ganska stort) mått av något som liknar slumpmässighet i vår verklighet. Den vi försökte sälja till kanske hade haft en jobbig natt med en skrikig bäbis som gjort hen på dåligt humör. Bäbisen kanske var skrikig på grund av en förkylning eftersom en hostig tant hamnat bredvid bäbisen på bussen. I den föregående versionen av förra veckan missade däremot tanten bussen på grund av en trafikstockning.

Det bästa vi kan göra är att agera på ett sätt som förbättrar oddsen i vår riktning. Agera på ett sätt som vi, empiriskt, vet ökar chanserna. Mot bäbisförkylning finns det inga hundraprocentiga försäkringar eller motmedel.

Det som gör att vi inte vet är att enstaka utfall är dålig empiri. Vi får ingen meningsfull information av veckans säljmål om säljmålet kan påverkas av en enstaka tants förmåga att hinna med bussen. Bara om vi aggregerar många liknande situationer (många veckor, många säljare, många tanter) och undersöker hur säljarens beteende skiljer sig kan vi dra slutsatser om hur våra gärningar påverkar chansen att göra affärer.

Om vi beter oss på samma sätt vecka efter vecka kan vi titta bakåt i tiden och få reda på vad vår process har för naturlig variation. Nästan alla utfall i vilken process som helst ligger inom tre standardavvikelser från medianvärdet. Så länge som utfallen ligger inom det spannet är det naturliga förändringar som spökar.

Om vi byter beteende och håller fast vid det tillräckligt länge för att vi ska kunna dra några slutsatser av utfallen, då och först då kan vi se om vårt nya beteende har påverkat utfallet på ett meningsfullt sätt. Om vi däremot byter beteende varje gång utfallet varierar (trots att variationen är slumpmässig inom det naturliga spannet) så kommer vi (av statistiska skäl) istället öka variationen och blir ännu sämre på att styra beteendet i riktning mot ökad försäljning.

Detta är ett av skälen till varför vi inom lean och agila metoder är skeptiska till felaktig användning av mätetal. Att sätta kvantitativa mål och följa upp på dem utan att veta om utfallet är inom den naturliga variationen eller ej,

När vi protesterar mot plågsamma KPI-försök får vi ibland höra: "Det är omöjligt att veta om vi faktiskt lyckats om vi inte också mäter!"

Allt vi säger är att det faktiskt ibland är omöjligt att veta om vi lyckats även när vi mäter och att vi måste ha en förståelse för processens variation för att överhuvudtaget kunna uttala oss i frågan.

Eller för att kunna reagera på mätvärdet på ett meningsfullt sätt.

söndag 15 oktober 2017

Räds förtrycket, inte hierarkin

Vi som gillar smidiga arbetssätt och agila organisationer utforskar ofta självorganisation som ett sätt att få till agilare verksamheter. När organisationens olika delar kan agera självständigt på ett produktivt sätt så ökar rörligheten. Om däremot ingen får agera utan centralstyrelsen uttalade beslut blir organisationen oerhört trög.

Det gör att vi ofta ser med misstänksamhet på styrning och ledning som begränsar lokalplanet. Drömmen om det agila arbetslaget utmanas. Vi älskar tanken på att en handfull människor, oberoende av annat än den ständiga dialogen med slutanvändaren, snabbt kan möta behov och skapa värde. Släpp oss bara fria!

Men problemet är att vi oftast inte är oberoende av varandra. Mina handlingar påverkar dig och dina handlingar påverkar mig. Alla verksamheter där den lilla gruppen skapar värde självständigt är antingen väldigt små eller så har man kämpat hårt för att minska den ena gruppens faktiska påverkan på den andra.

Systemtänkaren Donella Meadows pekar på hur system ofta saknar gränser. Vi påverkas och påverkar vår omgivning. Hon var en pionjär med systeminsikter inom miljörörelsen och gjorde analyser på förändringar i hela ekosystem över tid. Miljöpåverkan handlar inte om den omedelbara effekten av ett utsläpp, en kalhuggning eller ett ogräsmedelm utan om hur de komplexa samspelen skiftar som en följd av många olika förändringar.

I ett komplext system där arbetslag påverkar arbetslag får man inte agilitet genom att alla agerar efter eget huvud. När vi helt släpper centralstyret kommer arbetslagen visserligen inte att hindras av chefen, men de kommer istället att hindras av varandra.

Så hur löser vi detta? Ett par knep ur den lean-/agila verktygslådan:

Tydliga överenskommelser om visioner och övergripande mål, så att vi på golvet själva kan räkna ut vart vi ska utan att krocka eller springa åt olika håll.

Synkronisering i rytmer och helhetsbilder. Vi har regelbundna samplaneringar om övergripande konkreta mål. Vi informerar varandra i täta pulsmöten om vad som pågår hos oss. Inte minst lyfter vi alla hinder.

En organisationsförmåga att kunna prioritera. Även i den lilla verksamheten behövs detta, men där kan man lösa det enkelt. I Scrum tillsätter vi en allvis diktator över prioriteringarna (the Product Owner), men har vi minsta komplexitet behöver vi skapa en lite större struktur.

Vi behöver vara beredda att prioritera både vilka större initiativ vi ska starta, men också hur vi ska hantera konflikter under resans gång när behoven inom flera initiativ kolliderar. Småskalig agilitet behöver aldrig hantera det problemet. Där finns det varken stora eller parallella initiativ. Men den lyxen har vi inte i de lite större ekosystemen.

Donella Meadows pekar på hur hierarkier kan skapa resiliens i stora system. Dels genom att den centrala styrfunktionen kan ge delarna så mycket faktiskt oberoende som möjligt, men också genom att synkroniseringen (de gemensamma planerna, informationsspridningen) sker på ett harmoniskt sätt.

En central koordineringsfunktion, en beslutshierarki, krävs om stora system ska agera ändamålsenligt. Men den kan välja att agera på ett sätt som blir förtryckande eller ett sätt som blir frigörande. Att få den att agera frigörande är utmaningen för det agila ledarskapet i ett lite större samarbete.

Bilden föreställer Donella Meadows och publiceras med tillstånd från hennes vänner på (http://donellameadows.org/).