ALMA - Gemba World View

The Agile Lifecycle Management Anatomy borrows an important concept from the thinking behind effective management in Japan: The primary point of view should be the view from the gemba. "Gemba" is a Japanese word that means something along the lines of "the place where the action is". A TV reporter from a crime scene would say: "I am standing here right at the gemba...", and when Toyota's Taiichi Ohno went down to the factory floor to see for himself what was actually happening, he would say: "Let's go to the gemba!"

The "gemba" is the place where the value is created. Everything important in the organization depends on what happens on the gemba. This world view has some implications:

Transparency - Everyone needs to see reality as it is. This trumps people's wish for controlling information in their part of the organization (unless secrecy is motivated by the work where it must be clearly stated and regulated by transparent principles). Transparency is the nervous system of the organization, and must be supported by the tools and the ways of working. This enables all decisions being made based on empiricism: data and validated hypotheses.

Empowerment - If the value is created on the gemba it is important that the people working closest to the value creation are empowered to also control it. Like in all collaborations, the control is always bounded: the direction you as an organization is heading must be agreed upon, and you must know the limits for what you can do without asking anybody else.

You need mandate in order to be empowered. But you also need the resources: time, tools, and abilities (which can be provided to you by friends). Without the resources it is not possible to do anything useful of your mandate. Everybody in the organization needs to be embedded in a governance structure that can provide guidance on direction and limits, as well as the time and the tools and the other resources. This governance structure can be flat or hierarchical, based on individuals or on teams, and delegate much or little decision power.

Experience has shown that hierarchies based on individuals that perform top-down management is superior to having no management, but that flat team-based organizations where people have a lot of decision power is superior to top-down hierarchical management when there is competence to act in that environment.

An agile environment often falls somewhere in between while aiming to continuously become more team based, flat and empowered.

ALMA - Core Processes

Borrowing from a popular framework for managing IT services, ALMA defines three core processes:

Operation, which is when we deliver the service.

Design, which is when we think about how the service should evolve in order to meet human needs better.

Transition, which is when we make the new design become the new normal.

Each of these processes has their own focuses:

Operation is about consistency within the limits the service is designed for. Manufacturing operation often try to minimize variation in order to produce consistent products. Personal assistants often try to maximize the ability to handle variation in order to meet different needs. Most operations are somewhere in between. We try to optimize the allowed variation. The thing is that everyone involved in a service should know what they provide and under what conditions, and what to do when the the conditions doesn't apply such as when the limits of acceptable variation are violated.

Design is about being sensitive about needs not currently met properly by the service, and inventive about possibilities to meet those needs. This is an ongoing process that involves everyone. The collection of ideas and the possibility to try them out should be built into the daily operations process.

Transition is about being gentle when changing. We avoid scary big bang changes and instead aim for continuous evolution. Services are constructed by different kinds of parts: humans in functions, digital components, infrastructure, facilities, other assets etc, and each part requires a certain kind of care when changing.

There are other processes as well, but these three are the main ones and many of the tools and techniques in ALMA are meant to be used within one of them.

ALMA - The Service Perspective

ALMA is not centered around projects. Not even around products. In ALMA the focus is around services. What is a service? A famous IT service model defines a service as:

a means of delivering value to customers
by facilitating outcomes customers want to achieve
without the ownership of specific costs and risks

A core assumption in ALMA is that anything worth doing in organizations can be seen as either providing a service or making an existing service better. This is in line with this definition of what a service is. Let's have a look at some central themes:

Delivering value. If we are not generating value, the effort is worthless. Value is about meeting human needs. The human can be a paying customer, or otherwise in the position of receiving the great things we provide. The service perspective is equally valid whether we work in a private enterprise or are parts of a non-profit or an organization within the public sector or the government.

Facilitating outcomes. In order to be valuable you need to make a difference. Being just a hand in the middle is waste. We contribute by facilitating outcomes, that is making a certain outcome more probable than otherwise. We matter!

Without the ownership. We own the service. The receiver of our delivery may or may not own the result of our service. But even if we are creating and delivering physical products, what we provide (product development, manufacturing, and shipment) are services to the customer who doesn't have to take the risk of development and manufacturing themselves. They may own the result, but our organization owns the process.

This service perspective, focused on meeting human needs, is crucial for making ALMA work. Everybody needs to lift their eyes and focus on the purpose of why we collaborate. This little meditation may help:

Instead of work, think project. It is not about the effort but about the outcome.

Instead of project, think product. Projects are temporary, we need to focus on continuity.

Instead of product, think service. Products are just, at best, containers of value.

Instead of service, think needs. Our service may shift, but meeting needs is the eternal purpose.

ALMA - Agile Lifecycle Management Anatomy

So, I will try to collect and present what has been written by me here on the blog and elsewhere on how to achieve organizational agility by practicing agile life-cycle management of services and products. An agile organization is like a fit body, and here is a description of its anatomy.

The anatomy points at a structure. There are certain functions you need to have in place in order to make the body move, and it might be that your current organization need to adjust a bit in order to make it work, but it is not an organizational chart per se. You can make it work in a lot of different organizational structures.

The anatomy is founded on a certain set of lean and agile values and principles. Body structure is one thing, it is how you decide to move the body that will make it fit. And decisions on action comes from what you, as a group, value and what guiding principles you are used to.

Organizational agility has during history been improved in lots of environments, using many different techniques. Some of the techniques are very domain specific, such as extreme reducing of variation in a manufacturing environment, while others, such as self organized teams, can be applied almost anywhere. Agile life-cycle management is therefore not one single set of techniques, but rather a toolbox, used within a context of agile thinking around value, service, and product. The anatomy and the values and principles gives the people guidance on when and where one should use a particular tool.

I would like to describe how to make this work, and I hope that you can find guidance on how to transform a bit of your world into becoming more agile.

En svensk agil pionjär ur tiden

De agila metoderna som växte fram under nittiotalet kom inte med något nytt, utan var i mångt och mycket destillat av goda idéer från förr. Att iterativ utveckling var det rätta för datorsystem visste man redan 1968 och vikten av medarbetardriven ständig förbättring lärde man sig av Toyotas 50- och 60-tal. Från denna tid härstammar också insikten om att i många yrken, och särskilt då i serviceyrken, är det viktigt för kvaliteten att den som är närmast golvet också har stor frihet i arbetets utformning. Att låsa fast servicepersonal i trånga riktlinjer och förbud att improvisera gör bara att jag som kund får ett sämre bemötande.

I Sverige har vi haft två företagsledare som blivit världsberömda på att delegera mycket makt ner till golven. Naturligtvis Jan Carlzon på SAS vars bok "Riv pyramiderna!" från 80-talet fortfarande används som lärobok i chefsutbildningar världen över, men också Handelsbankens förre VD Jan Wallander som nu i början av september gick ur tiden 96 år gammal. När Handelsbanken i slutet av 60-talet upplevede en kris, i mångt och mycket orsakad av toppstyre och av en ledning som förlorat markkontakten, och sökte efter en ny VD så anmälde Wallander sig på villkor att han fick lov att vända upp och ner på hierarkierna, ungefär som han hade gjort på Sundsvallsbanken tidigare.

Det visade sig vara lönsamt med delegering. Om folket på golvet, nära kunden, får lov att fatta beslut så blir besluten mer verklighetsförankrade. En organisation med makten i fingerspetsarna är känslig för folks behov och har förmågan att lättrörligt anpassa sig efter en föränderlig marknad. Men det krävs även en annan sak för att uppnå organisationsagilitet, och det är frånvaron av blockerande övergripande strukturer. Här gjorde Wallander något som fick många att lyfta på ögonbrynen: han avskaffade årsbudgetarna.

Många associerar en avskaffad budget med avskaffad kontroll, men det är det inte fråga om. Däremot att man inte tror sig kunna styra över hela år i taget, utan att man är beredd att skifta fokus löpande. Kontroll på kostnader och uppföljning av vart pengarna går har man fortfarande. Wallander blev därmed en pionjär för det som idag kallas för "beyond budgeting" vilket är ett agilt sätt att hantera intäkts- och utgiftsströmmar på. När Bjarte Bogsnes ("Beyond Budgeting") och Jurgen Appelo ("Management 3.0") talar om organisationer som gått före på resan mot större agilitet så nämner de därför Handelsbanken med aktning.

Nu är det upp till oss som fortfarande lever att fortsätta förvandla organisationerna i mer rimlig riktning. Tack, Jan Wallander, för ditt bidrag!

Tio steg till organisationsagilitet

Organisationsagilitet har beskrivits som den tredje vågen inom lättrörlighet och smidighet. Den första vågen var när man började skapa små agila bubblor i annars väldigt trögrörliga och stela organisationer, och mycket av råden till agilister från den tiden handlade om hur man skulle skydda teamen och möjliggöra agilitet trots att verksamheten ville annorlunda. Den andra vågen handlade om hur man kunde synkronisera flera team att samarbeta på ett mer lättrörligt sätt, och idag är detta ett i huvudsak löst problem med väl beprövade ramverk och tricks. Den organisation som vill få storskalig agilitet att fungera kan få det på mella sex och tolv månader om de bara är villiga att göra som expertisen inom området säger.

Men både första och andra vågen handlade bara om en sak: hur man utvecklar tjänster, i synnerhet IT-baserade tjänster. Men utveckling är bara en liten del av en tjänsts livscykel, och tjänsteperspektivet är långt mer vittgående än IT. Det börjar gå upp för fler och fler organisationer att hela deras värde i nuet består i förmågan att möta människors olika behov, men deras värde över tid består i förmågan att kontinuerligt vidareutveckla tjänsteförmågan. Folks behov skiftar.

Och det är här organisationerna har utmaningen idag. För att kunna lyckas med att skapa en tjänsteinnovationsfabrik behövs organisationsagilitet och det är något som på många håll kräver ganska vittgående förändringar.

Det första som måste ryka är projekten. De har aldrig tjänat oss väl, och för kontinuerlig tjänsteutveckling är de rent destruktiva. Projekt betyder välplanerade tillfälliga arbeten i tillfälliga organisationer, och kontinuerlig tjänsteutveckling är tvärtom: ständig förbättring i den fasta organisationen på ett sätt som inte kan planeras på förhand. Istället för projekt behöver vi bygga in tjänstutvecklingskapaciteten i själva linjeorganisationen.

Det andra som måste ryka är årsbudgetar där man på förhand har beslutat om till vad man ska allokera hundra procent av sin förändringsförmåga under ett kalenderår. Den som har begått det misstaget får vänta till minst årsskiftet för att få igenom en förändring när de ser en möjlighet uppenbara sig. Istället behöver man allokera medel löpande inom de ramar man satt. Kostnadsmassan i organisationen är ganska stabil, det är vad organisationen ska lägga sin energi på som behöver kunna vara rörligt.

Det tredje som måste ryka är tron att man med en omorganisation kan anpassa linjeorganisationen efter värdeströmmen. Det går inte. Värdeströmmarna i tjänsteorganisationer (utom de allra enklaste) är komplexa och korsar organisatoriska gränser. Istället bör man låta organisationen så långt det går vara ifred så att den kan bygga kapacitet att hantera strömmarna på tvärs genom avdelningsgränserna. Omorganisation kan behövas för att slå sönder hinder men den bygger aldrig upp. För att bygga upp kapacitet i en organisation behöver organisationen tvärtom stabilitet.

Det fjärde som måste ryka är målstyrning på utfallsmått (management by objectives). Det felaktiga bakom denna styrfilosofi har varit känd sedan femtiotalet: utfallet är beroende både av faktorer som kan kontrolleras av de som arbetar och faktorer som inte kan kontrolleras. Om man arbetar metodiskt med förbättring kommer utfallet att bli bättre, men att styra på utfallsmått som i sig innehåller varians ökar variansen. Ersätt management by objectives med ledarskap.

Det femte som måste ryka är tron att viktiga nyckeltal också är styrtal. I samma stund som ett relevant nyckeltal behandlas som ett styrtal så upphör det att vara ett relevant nyckeltal (Goodharts lag).

Det sjätte som måste ryka är resursoptimering, tron att organisationen presterar mest värde när resurserna är maximalt utnyttjade. Det är en intuition som är matematiskt felaktig. Optimering på flöde betyder en viss överkapacitet i varje del av värdeströmmen vilket kan kännas lite dyrt, men eftersom flödet är bättre hinner fler värdeenheter levereras per tidsenhet vilket gör att kostnaden per värdeenhet går ner. Flödesoptimering är ett exempel på systemtänkande. Det finns fler.

Det sjunde som måste ryka är idén att chefer leder och fördelar arbetet. De som förstår arbetet bäst är de som befinner sig allra närmast värdeskapandet. De ser värdet, och de ser spillet uppstå, särskilt om de tränas i förmågan att se spill. Det kan hända att cheferna är bättre på att planera arbetet än vad folket närmast arbetet är. Då löser man det genom att lära dem planera och följa upp sitt eget arbete. Chefer ska ge förutsättningarna (mål, ramar, verktyg) för självorganisation om organisationen ska ha en chans att bli lättrörlig.

Det åttonde som måste ryka är idén att förbättringsarbetet är chefernas ansvar. Även den ständiga förbättringen behöver utföras av dem som är närmast värdeskapandet. Och den ska vara metodisk vilket kräver utbildning och coachning, regelbunden vilket kräver avsatt tid, och baserad på empiri vilket kräver stor transparens i organisationen.

Det nionde som måste ryka är tanken att narcissism är en god ledaregenskap. När vi rekryterar ledare på magkänsla tenderar vi att gynna stora egon. Dessa kommer att blockera sund grupputveckling, som ju är ett måste för att få breda och välfungerande arbetsgrupper, vilket är ett måste för att få organisationsagilitet. En organisation designar sitt ledarskap genom att besätta positioner på ett medvetet sätt.

Det tionde som måste ryka är den falska bilden av människan som en varelse utan psykologiska behov. Behov finns, och behöver tas hänsyn till, annars fungerar inte människan optimalt och organisationen fungerar dåligt. Den agila organisationen vet vad människor behöver och aagerar med hänsyn till dessa.

Vi som varit inblandade i första och andra vågens agilitet kan berätta att dessa tio saker måste städas bort från organisationerna om vi ska få smidighet i dem. Vi kan också berätta om hur man gör för att styra, leda, planera och följa upp på ett sätt som gör organisationen agil. Men orkar organisationen lyssna till budskapet?

Jag är på plats under hela Almedalsveckan 2017 och deltar gärna i flera samtal runt de här frågorna.

Allt hänger ihop

Det jag hoppas kunna visa med Smidigt!-programmet är hur allt hänger ihop. Ett av våra problem är att vi delat upp verksamheternas aspekter i en massa småavdelningar med stängda dörrar emellan sig. Ledningar vimsar i den här miljön runt och försöker att med olika omorganisationer kunna skapa smartare indelning av avdelningarna som bättre följer värdeströmmarna, men det fungerar inte.

Har man lite komplexitet i verksamheten kommer alltid värdeskapandet att korsa avdelningsgränserna. Det är själva indelandet som är problemet, medan samarbetsformer som öppnar dörrarna på ett ordnat sätt är en del av lösningen.

Om allt hänger ihop är det naturligtvis svårt med överblicken, och det är precis det som Smidigt!-programmet är: en överblick över just en massa samarbetsformer som syftar till att koppla ihop alla olika avdelningar och perspektiv till en helhet. När jag håller kurs brukar jag likna Smidigt!-programmet vid en karta där de olika modulerna i programmet är platser vi kan utforska, och den app jag skriver på just nu kallar jag för "Smidgt! Atlas". Ett verktyg som ska ge överblick. De smidiga samarbetsformerna handlar ju om allt från budgetstyrning till omsorg om människor och maskiner till ledarskap och gruppsykologi. Det är ett integrerat synsätt som spänner över många fält, och sådana kan vara väldigt svåra att överblicka om man inte har en bra kartbok.

Här på bloggen finns redan en massa inlägg som handlar om gränsöverskridandet:

Att riva gränserna mellan "IT" och "verksamhet" (en indelning som vi lyckligtvis snart kommer att lägga på skräphögen) handlar dessa inlägg om: Vi bygger broar om att vi måste samsas om samma värdeström, Beställare och utförare om att beställar/utförar-perspektivet gör att det ser ut som att alla problem finns innanför "utförarnas" dörrar, men att det i själva verket handlar om bristande djup kommunikation dem emellan. Ett anspråkslöst förslag handlar om ett konkret verktyg: att "beställningar" läggs som en väldigt tunn idébeskrivning av vad man vill uppnå, och så kan "beställare" och "utförare" tillsammans utforska de bakomliggande behoven oxh möjliga lösningarna.

För att öppna dörrarna, eller hellre riva väggarna, och sätta sig vid samma bord behöver man en gemensam bild av vad som händer. Ett klassiskt sätt ifrån lean och Toyota är att gemensamt titta på värdeflödesperspektivet. Om detta har jag skrivit en hel serie inlägg som länkas till ifrån Den livsviktiga flödessynen. Hur blir folk glada? Vilka behov möter vi? För att se det kan man ha en workshop för att Leta värden tillsammans. För värde är mänskliga behov.

Ett tidigt försök att överbrygga avdelningsgränser var projekt. Nu har projekt enorma svårigheter av lite olika skäl. Ett skäl är att ett projekt per definition är tillfälliga arbeten i tillfälliga organisationer till en fast tid, kostnad och kvalitet. Det är ju inte tillfällighet vi behöver utan ett konstant värdeskapande. Och problemet med värdeskapande är att det bygger på utforskande, vilket gör det i princip oplanerbart (på det sätt som projekt definierar planerbarhet): Oplanerbara projekt? Istället utgår smidiga samarbetsmetoder från ett tjänsteperspektiv: värde levereras i form av tjänster, och tjänster måste betraktas utifrån hela sin livscykel. Där är utvecklingen bara en liten del. Här finns även början till det som blivit ALMA: The Agile Lifecycle Management Anatomy.

Det här helhetsperspektivet tror jag är viktig för både myndigheter och företag i ljuset av digitaliseringen. Jag sammanfattar i Samtiden och framtiden vad jag tror kommer att krävas. Dels att en massa strukturer rivs upp som i dagsläget mäter fel saker och på fel sätt. Just mätetal har jag bloggat en hel serie om. Särskilt skriver jag om Mätetal som kan vara relevanta i smidiga samarbeten.

Alla måste uppvisa ledarskap i smidiga samarbeten. Det ligger i själva det sätt som vi betraktar organisationer på. Så för den som har ett särskilt ansvar för ledarskapet är det extra viktigt att tänka över sitt ledarskap. Särskilt gäller det att förstå att ens roll i digitaliseringen handlar om att leda för förändring, inte för stillastående. Till din hjälp finns dock ett antal väl beprövade principer.

Om allt detta handlar Smidigt!-programmet. En massa moduler med kunskaper och gruppfärdighetsträningar som ska hjälpa samarbeten att bli mer smidiga. Det bygger på en massa erfarenhet, men också på en massa teoretisk kunskap från olika fält. Bland annat från dessa böcker. Fast det som jag försökt göra är att lägga ihop allt så att det blir både begripligt och möjligt att agera på. Kunskap i sig förändrar ingenting. Förändring förändrar, och att få bidra till förändring som gör jobb trygga och meningsfulla och produktiva är litegrann mitt livsmål. Jag hoppas så innerligt att du kan hitta något du har användning för genom det jag försöker göra.

Infographic: Kanban Board

Next infographic from the SMIDIGT! modules: suggestions how to set up and handle a kanban board in order to track your work and improve the flow.

Download the infographic here: infographic-kanban-board.pdf

Infographic: Scrum Board

The updating of the SMIDIGT! course and coaching material continues. Here is an infographic from the course module "The Daily Meeting": a collection of facts and suggestions regarding how to use and set up a scrum board.

Download the infographic here: infographic-scrum-board.pdf