Pyttestyrning eller coacha till självstyre?

Du är chef. Du har en gruppering under dig som vill styra mer av sin verksamhet själv. Du låter dem.

Men efter en tid märker du att grupperingen nog lider av problem. Du har inte sett riktigt det resultatet från dem du velat se, och när du betraktar hur gruppen arbetar ser du hur de är lite för splittrade. De skulle nog må bra av lite struktur. Så du överväger att genomföra följande förändringar...

STOPP!

Det spelar ingen roll om det du tänker göra är bra eller inte. Bara det att du intervenerar utan föregående varning förstör precis den förmåga till självstyre du och grupperingen försöker bygga upp.

Gruppen har bestämt sig för ett visst arbetssätt. Det är möjligt att det inte är det bästa sättet, men gruppen upplevde sig ha mandat att bestämma det när de bestämde det.

Varje plötslig inblandning i andra människors ansvarsområden gör att deras upplevelse av att ha mandat förstörs. Det spelar ingen roll om du tycker att interventionen är en engångshändelse på grund av en särskild situation, det alla andra ser är ett slumpmässigt bortryckande av befogenheten att leda och fördela sitt eget arbete.

Och när något sker slumpmässigt finns det ju inga garantier att det inte kan hända igen, eller hur? Känslan av kontrollförlust, förlorad autonomi, skakar folk inte av sig så lätt. Du har just brutit ett förtroende.

Ett bättre sätt att närma sig frågan hade varit att...

• ...möta gruppen (inte enskilda) med observationen och fråga om gruppens syn på saken.
• ...erbjuda hjälp att tillsammans med gruppen lösa de utmaningar de ser. Din intervention blir då en av många möjliga lösningar.
• Och om gruppens resultat eller arbetssätt fortfarande är oacceptabla då (men inte förr) köra över dem och bestämma en ny ram för deras arbete.

Det sistnämnda är viktigt. I en organisation som andra än gruppen äger arbetar alla med andras tillgångar. Som chef är du ansvarig för vad som händer med dessa. Gruppens självorganisation är, precis som ditt chefsjobb, ett förvaltarskap. När som helst kan både din och deras rätt att bestämma försvinna.

Men bara för att du har ansvaret, mandatet och möjligheten att intervenera efter eget godtycke är det inte en bra idé om du vill se självorganisation och bemyndigade medarbetare.

Självstyre inom en maktstruktur där chefer får lov att agera efter eget godtycke är bräckliga saker ur ett psykologiskt perspektiv. Själva möjligheten till chefens godtycke utgör ett stort hot, även om du som chef inte upplever dig som speciellt hotfull.

Om du använder dig av din rätt till vad som kan uppfattas som plötsliga godtyckliga interventioner gentemot självstyrande grupperingar så kommer det att få stora konsekvenser mycket snabbt.

Även om du gör det sällan. Även om du agerar i välvilja. Även om din intervention i grunden är bra och smart.

Skört ledarskap

Det finns ett ledarskapsideal som utmålar chefen som väldigt kraftfull i förhållande till dem hen leder. Chefen ska:

• Sätta målen både för gruppen och för individerna.
• Ge uppföljning och stöttning till varje individ.
• Förse individen med verktygen som krävs för att individen ska göra sitt arbete.
• När det krävs även leda och fördela arbetet.

Det är ett ledarskap som av vissa utmålas som väldigt kraftfullt, men som i själva verket är skört. Framförallt skapar det mycket sköra organisationer.

Skörheten i organisationen syns i de förmågor som en sådan chef måste besitta, förmågor som alltså organisationen inte har etablerat i sig självt:

Veta precis hur ett mål för gruppen på bästa sätt löses genom individernas enskilda måluppfyllelse och veta precis vilka behov av uppföljning och stöd som individerna behöver i varje stund. Kunna rätt bedöma var och ens insats, och vid behov kunna korrigera dem.

Det krävs en mycket djup insikt i arbetets natur för att kunna klara av att göra detta, och inte ens då är det säkert att det går. Många arbeten kan inte på något enkelt sätt fördelas på förhand, utan blir bäst utfört om de som ska utföra det prövar sig fram till vilken arbetsdelning och vilka verktyg de behöver ha.

Och när det gäller uppföljning kan man fråga sig om det verkligen är bäst med chefens subjektiva bedömning, eller om man inte kan göra så att återkopplingen kommer direkt från verkliga data, till exempel ifrån kundernas beteenden. Om vi lyssnar till kunden behövs ingen mellanhand.

En ledare av den här sorten är en person som åtminstone i relation till de övriga människorna har en enastående stor kapacitet att utföra deras arbete. De övriga förblir beroende av centralfigurens närvaro och ständiga ledning, och man kan undra varför det i så fall är nödvändigt. Är de hjälplösa, eller har de gjorts hjälplösa?

Behovet av detta slags ledarskap är ett exempel på failure demand eller onödig efterfrågan. Det är dysfunktioner som skapar behovet:

• att målen och ramarna i organisationen är vagt formulerade,
• att gruppen inte lärt sig fördela, leda och följa upp sitt eget arbete i riktning emot målen,
• att både återkopplingen och prioriteringen mellan behov i organisationen är otydlig och ibland dubbel vilket gör att chefen måste komma med sina ord som då väger tyngst.

Ett lean-/agilt ledarskap arbetar istället för att tydliggöra mål, prioriteringar, ramar och återkopplingen; och med att bygga förmågan till självorganisation. Först då får man starka och resilienta organisationer som förmår skapa värde även i frånvaro av starka centralfigurer.

Det som tolkas som styrka hos den kraftfulla chefen är istället tecken på stor bräcklighet i samspelet. Fragilt är motsatsen till agilt.

Not "Go And See": Come And Listen!

In the world of lean thinking there is a dose of healthy skepticism about numbers and reports. Taiichi Ohno, the most prominent of the creators of the Toyota Production System, was known to put the papers away and instead say: "Let's go and see for ourselves!"

Going down to the shop floor, the gemba, the place where value is created (and sometimes wasted), is to actually grasp the current situation and understand what is going on. Down there, anchored in reality, Ohno-san could tell the people what to do based on what he actually saw happening.

Now, where is the gemba in a knowledge factory, for instance a group who is developing changes in a digital service?

I have seen offices where "lean experts" from the factory floor has tried to apply the tools of the factory on what they believed was the knowledge factory gemba: the desks, the meeting rooms, the copier machines and office supplies.

That is of course ridiculous (and the result more so) since knowledge work isn't about shuffling papers around on a desk or having meetings. Knowledge work happen in and between people's brains. The gemba is the conversations between the people participating in the work of gaining mutual understanding of needs and how to meet them using digital tools.

We sometimes try to adopt the lean principle of visual management when we do service development. Scrum and other agile practices has borrowed the idea of the kan ban, visualizing the workflow maybe on a board so that we can see where we get stuck.

Sometimes managers, in the spirit of Toyota, wants to go and see what is happening on the "factory floor". If there is a kanban-board available, there is where they naturally will go. And sometimes ask: "What does the board tell us?" "Why can't people create visualizations of their so called 'work' so that we understand?" "We need to tell them what to visualize!"

The thing is that the kanban board, or any other visualization tool such as Jira or Trello, is not the gemba!. It is not the place where work happen!

The work happens in people's brains when they have a productive exchange of thoughts. In the conversations. The visual aids we might use are just aids for better conversations and collaborations.

So, if you are a manager assigned to help people doing knowledge work, please understand this:

It is NOT about "go and see"!

It is all about come and listen!

And share. And participate.

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!

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?

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?