Agila metoder för vanliga kontor

Sådär, då var en ny utbildning iordninggjord.

Många i olika kontorsjobb har sett folk använda den agila metoden Scrum och blivit inspirerade. Scrum är gjort för ett arbetslag som utvecklar mjukvara, men jag har varit med och utbildat i Scrum ett antal gånger för folk som inte alls sysslar med IT utan sysslar med försäljning, kommunikation, administrativa uppgifter, och annat vanligt kontorsarbete.

När jag inte bara fått utbilda utan även varit med och hjälpt till i införandet har jag hela tiden fått påminna om att deras situation inte alls liknar ett systemutvecklarlags:

"Nej, ni kanske inte ska ha sprintar (=tidsperioder då kravbilden ligger still) på två-tre veckor. Ni behöver nog jobba polyrytmiskt veckovis och månadsvis."

Nej, ni kan nog inte i dagsläget låta en hel grupp svärma runt samma ärende. Kan ni bilda par först och främst?"

"Leta inte efter en enda Scrum Product Owner (person som tar helhetsansvar för lagets prioriteringar). Tydliggör istället hur ni tänker ta ansvar för prioriteringen, och förankra den processen hos era intressenter inklusive er chef."

Resten av pusselbitarna i både Scrum och Kanban (en annan populär agil metod): förtydliga arbetsuppgiften innan man tar sig an den, coachande ledarskap utan mandat, synliggöra allt arbete på en tavla, dagliga synkmöten, gemensam snabb planering och uppföljning, förbättringsmöte där man tillsammans förändrar sin arbetsprocess, realistiska prognoser baserade på mätetal, minska samtidigt arbete för att öka genomströmningshastigheten, korta och väldigt effektiva möten som ersätter de långa och ineffektiva mötena, fokus på gruppens värdeutflöde snarare än beläggningsgrad, och alla andra små tekniker, DE är fortfarande relevanta.

Nu har jag alltså satt ihop en endagsutbildning i allt detta. Ett arbetslag som går utbildningen ska kunna komma igång. Jag har ännu inte bestämt några datum, men vill börja med att kolla hurpass stort intresset är. Vad säger ni?

Flödesekonomi 1A

Det var en gång ett stort börsnoterat bolag som fick sina intäkter genom att tillhandahålla en IT-baserad tjänst för konsumentmarknaden. Problemet var att man inte längre var ensamma på marknaden, utan flera nya uppstickare utmanade bolaget. Dessa nya uppstickare lyckades leverera nya efterfrågade funktioner i snabb takt, medan bolaget fick allt svårare och svårare att hänga med.

"Agilt!" sade ledningen. "De nya bolagen jobbar agilt! Då går det snabbt! Det ska vi också göra!"

Sagt och gjort: man tog in vägvisare som hjälpte dem att hyfsa till organisationen. Istället för att projekten segade sig emellan kompetensspecifika avdelningar skapades tvärfunktionella självorganiserade team. Istället för att olika projektbudgetar krävde uppmärksamhet samtidigt, så utsågs produktägare med ansvar att prioritera det viktigaste för varje team. Och eftersom arkitekturen var mycket komplex så skapades ett brett men effektivt koordineringsteam som kunde ta det övergripande prioriteringsansvaret.

Nu vände det. Man lyckades börja leverera funktioner i nästan samma takt som konkurrenterna. Flaskhalsen var nu inte längre projekten utan den gamla arkitekturen. Man började planera för refaktorering.

Men då drog ledningen öronen till sig. Refaktorering? Prioritera plattformsarbete när man kan prioritera funktioner? Det måste vi sätta stopp för! Inte bara det: när ledningen tittade närmare på hur var och en i teamen arbetade såg de att flera personer inte kunde kallas hundraprocentigt belagda. Här fanns alltså en outnyttjad kapacitet som skulle kunna användas för att äntligen komma ikapp och förbi konkurrenterna. Det blev ganska många procent när man räknade på det!

Genom att bromsa fokuset på plattformsarbetet och kommendera in lite fler parallella initiativ, samtidigt som man klubbade igenom en mer aggressivt releaseplan, så fick man upp beläggningen till hundra procent. Totalt tjänade man in femton procent, så man förväntade sig en hastighetsökning i funktionstillväxten på lika mycket.

Resultatet blev (förstås) en omedelbar sänkning av utflödet med 20 %. När trycket ökade inom organisationen fastnade arbetspaket vid olika flaskhalsar i flödet, vilket fördröjde processen så att utflödet sjönk. Mycket snart märktes också effekten av att var och en på grund av förseningarna tvingades arbeta med flera saker samtidigt vilket sänkte utflödet ytterligare.

Men den stora sänkningen av hastighet kom när man på grund av den aggressiva planen var tvungen att produktionssätta flera utlovade funktioner innan de blivit genomtestade. Detta resulterade i ett massivt inflöde av felrapporter. Alla arbetade för högtryck med en genomsnittslig övertid på sju procent, men majoriteten av tiden gick åt till att hantera fel, växla mellan olika uppdrag, skyffla information om beroenden, och förstås också skapa nya fel. Utflödet var nu 30 % av vad det varit tidigare.

Man gjorde ett kortlivat försök att återta förlorad tid genom att outsourca en del av utvecklingen, men detta resulterade i en ännu större sänkning av utflödet då alla dessutom var tvungna att förhålla sig till utvecklingsteam i olika länder, som allesammans skulle ner och gräva i samma kodbas samtidigt.

- "Jag förstår inte detta!" tänkte den i ledningsgruppen som varit mest pådrivande i ökningen av beläggningsgraden, när hen satt i bilkön på väg hem från jobbet. "Det är som om hastigheten i vår utveckling sänks ju mer vi jobbar! Hur kan det bli så?" tänkte hen, samtidigt som hastigheten på motorvägen hastigt sjönk mot noll i takt med att fler bilar och fler bilar körde där.

ALMA: Features And Packages

Condition

When you need to specify what changes a service needs and don't know how to sort them out.

Solution

Identify changes to distinct features:

A feature is a user facing capability of a service that is:

• Triggered by the user.
• Returns a valuable result to the user.

Identify what changes should go together in meaninful packages.

Description

A feature could be a baggage check-in at the airport, or a search in a web service. You approach the baggage check-in counter, leave your baggage, and receives a ticket. You surf to the search page, enter some terms, and receives a result list.

Note that the valuable result doesn't have to meet the user's need in full. A baggage check-in is part of a trip. A search result is part of whatever you want to do with the resulting items.

That is the idea behind packages. A package is a set of changes to a number of features. The changes won't meet a person's needs if they aren't in total deployed to the service.

There might be changes in the baggage check-in feature that needs to be in sync with other changes in the baggage flow. And maybe can you say the same about the search result. These changes must be identified and grouped in packages.

History

Constructs like these are common in service design, and have different names: user stories within epics, capabilities within delivery packages, etc.

(ALMA: Agile Lifecycle Management Anatomy)

Workplace Management - Taiichi Ohno (kap 25-27)

Kapitel 25: Arbete är en klipskhetstävling med de underställda

Försök inte få folk att arbeta genom att ge order hela tiden. Utmana tänkandet istället: hur ska vi lösa problemet? Vilka lösningar kan ni se, vilka lösningar kan jag se? Låt arbetet bli en tävling i uppfinningsrikedom.

Man bör sätta sig in i de underställdas situation och försöka bli en chef som folk väljer att följa. Det är svårt eftersom folk har olika behov. Men det handlar, återigen, om att gå till golvet - till gemban - och förstå vad som faktiskt sker.

Kapitel 26: Det finns inga förmän på den administrativa gemban

På kontoret ("den administrativa gemban") finns inga förmän ("supervisors") på samma sätt som i fabriken. Förmannens jobb i Toyotasystemet är att titta på arbetet. Men kontorschefen tittar på sin höjd på arbetarna. Man premierar flit, även om fliten handlar om att göra onödigt arbete ("transportation"). Vi ska inte låta oss luras av att en massa saker ser ut som nyttigt arbete, men som kanske inte alls är det viktigaste att göra just nu. Du säger att de jobbar bra? Jag säger att det enda jag ser är flinka fingrar!

Här krävs förbättring. Kontoret behöver en förman som själv kan se vilket arbete som är nyttigt och vilket som inte är det, och som också kan lära ut den konsten. Dvs precis det leancoachande förhållningssätt som krävs av en Toyota-förman på fabriksgolvet. Detta gäller även kontoret där cheferna jobbar. Också management behöver förmän som kan lära dem skilja sitt nyttiga arbete från spill de genererar.

Värdesätt resultatet av arbetet. Pröva nya sätt att arbeta på. Den som är förman måste förstå systemet, och förstå att det inte hjälper om man skäller ut individer. Att själv ha arbetat i systemet kan hjälpa, men det är inte säkert.

Mät förbättring på den administrativa gemban (kontoret) genom att se om ni inte kan uppnå samma resultat med färre antal människor.

(Min reflektion: Här tror jag att Ohno inte ska följas. Naturligtvis finns det mycket onödigt arbete i administrationen som inte ska göras. Administration för att kunna skapa värde är i sig inte värdeskapande. Men om vi mäter effektiviteten i administrationen genom att räkna antalet människor är risken stor att vi försöker utföra samma arbete (inklusive det onyttiga arbetet) med färre personer. Resultatet blir överlast, och att även det nyttiga arbetet försenas, vilket leder till ytterligare slöserier.

Grundproblemet ligger i det som Ohno nämnde i början av kapitlet: På ett kontor kan det vara svårt att se vad som är värdeskapande. Det är därför svårt att avgöra vilket arbete som är onödigt och bör tas bort. Man kan inte ställa sig på kontoret och se arbetet flöda, eftersom det mesta värdeskapandet äger rum inuti folks hjärnor. Här tar många fabriksorienterade leanvägvisare miste. De försöker rationalisera det de ser, men de ser inte arbetet så de rationaliserar bort viktiga värdeskapande moment.

Vi som arbetar specialiserat med lean inom kunskapsarbete brukar därför fokusera på att först försöka visualisera värdeskapandet, och sedan lära folk att själva se vad som är spill och inte. Det är ju deras egna hjärnor som är gemban, så de är bara de själva som har möjlighet att faktiskt gå och se.

Notera att när Ohno i tidagre kapitel pratat om fabriksarbetet så pratar han om att inte försöka få ner antalet människor som arbetar, utan att i stället öka värdet på det de gör. Det rimliga är att tillämpa precis samma tänkande på kontoret: mät inte framgång i att ni blir färre, utan i att ni skapar mer nytta.)

Kapitel 27: Vi kan göra mycket mer kaizen

De första förbättringsinitiativen är de mest effektiva. Med tiden kan det bli svårt att vinna ens en ynka procents förbättring. Där Ohno befann sig nu handlade det mycket om att få till en jämn produktion av bildelar så att man inte hade för mycket eller för lite av någon viss del (att producera i "sets").

Han konstaterar att det alltid finns något att göra, och att man på den administrativa sidan kan göra mycket.

Autokratin är problemet

Jag fortsätter reflektionen runt ledarskapets ansvar för mental/social arbetsmiljö.

När vi bygger kärnkraftverk är det inte Rörmäster som med sitt erfarna öga tittar på konstruktionen och berättar vilka dimensioner som ska användas. Vi har ingenjörer som med kunskap om fysikaliska lagar räknar ut vad som behövs. De fysikaliska lagarna är framforskade och validerade och inte beroende av Mästers dagsform.

När vi styr länder är det inte byhövdingen som ensam, eller möjligen med hjälp av en lagman, avgör tvister mellan byns invånare. Istället har vi maktdelning med överenskomna lagar som upprätthålls av professionella jurister och poliser.

Vi har helt enkelt övergivit autokratin, att en person ges självsvåldig makt, inom flera av samhällets sektorer. Inte i första hand av rättviseskäl, utan av effektivitetsskäl. Professionalismen fungerar bättre.

Utom i ledarskapet av arbetsplatser. Där är vi ofta fast i den primitiva och spontana ordningen där enstaka individer utväljs på magkänsla och ges stor makt över andra som arbetar där, utan att bli hjälpta av genomtänkta metoder för hur ledarskapet ska fungera.

Den spontana ordningen i utväljandet av ledargestalter i människoflockarna tenderar att selektera narcissistiska män framför andra kandidater. Väl på plats kan många av dem uppvisa dysfunktionella ledarbeteenden, beteenden som inte sällan leder till ohälsa hos personalen. I och med den individuella chefens starka ställning finns det få personer som vågar utmana dysfunktionerna, och de som ändå gör det bärs av väldigt bräckliga hjälpande strukturer om sådana alls finns.

Att utmana dysfunktioner i en dysfunktionell organisation leder till opposition och konflikt. Att utmana dysfunktioner i en välfungerande organisation leder däremot till ökat tillitsfullt samarbete (själva den förmågan är en effekt av den goda funktionen). Givet den definitionen kan man fundera över hur många organisationer som är välfungerande egentligen.

För att få organisationen att bli välfungerande på det sättet behövs det ett geni som både kan klättra mot toppen på ett aplikt sätt, och sedan använda den positionen för att ensam driva förändringen med all den psykologiska insikt och effektiva verktyg som krävs. Geniet måste i sig själv skydda sig både mot maktberusning och mot att helt enkelt svara upp mot folks förväntan på hur en ledare ska vara.

Eller så inser vi att själva idén om autokraten, Organisationsmäster, företagshövdingen, är problematisk i sig. Vi inför professionalism även här, och gör medvetet ledarskap och organisationsutveckling till en integrerad del av verksamheten. För den illvilliga autokraten innebär det en effektivt detroniserande. För den välvilliga autokraten innebär det att äntligen få ett fullgott stöd i form av verktyg och modeller som stöttar och blockerar dysfunktion.

Det är inte så att det inte finns kunskap om hur mänskliga samspel fungerar som bäst. Däremot är kunskapen dåligt spridd, och verktygen underutnyttjade. Det kan en ökad professionalisering av ledarskapsstrukturerna råda bot på.

Arbetsgivarens ansvar för organisatorisk och social arbetsmiljö

Arbetsmiljöverket släppte precis en ny föreskrift som förtydligar arbetsgivarens ansvar för den organisatoriska och sociala arbetsmiljön. Detta med bakgrund av att just psykosociala faktorer står för en ökande del av sjuktalen, som jag skrev om här.

Föreskrften siktar in sig bland annat på belastningsbördan, nåbarhetskravet, och på kränkande behandling. Jag säger inte att agila metoder är lösningen på dessa problem, men nog innehåller de en hel del hygienfaktorer som möjliggör lite sundare arbetsliv även för kontorsarbetare.

Vi jobbar dragande. Eftersom ingen tilldelar uppgifter åt någon annan minskar vi risken för att bli överlastade. När man tilldelar uppgifter åt någon annan är annars risken stor att man tror att man tilldelat lagom mycket för en viss tidsperiod. Risken är dock stor att man misslyckas och istället tilldelar för lite eller, vilket är mycket mer kostsamt, orsakar kaos genom att tilldela för mycket. Med ett dragande system uppstår sällan överlast. Istället får man flödeseffektivitet.

Vi svärmar runt uppgifterna. Eftersom arbetsuppgifterna inte är individuella utan hanteras av arbetslag där man sprider kompetens och ansvar så kan man organisera arbetet så att enskilda individer inte behöver vara nåbara hela tiden.

Vi arbetar i trygga arbetslag. Metoderna innehåller handgrepp för att säkerställa att arbetslagen är sunda och trygga. Väldigt mycket av teknikerna i de agila metoderna handlar om att synliggöra och blockera individer som försöker sig på att bete sig narcissistiskt, överföra skuld och skam, agera i det fördolda, eller på andra sätt förstöra för verksamheten.

Med detta sagt innebär inte införande av agila metoder några garantier. Det finns mängder med införanden därute där man ignorerat både dragande system, lagarbete, eller sund teambuilding. Vill man ha den goda effekten av de agila metoderna behöver man också se till att faktiskt tillämpa dem. Så nog finns det verktyg och impulser att hämta för den chef som vill ta sitt arbetsmiljöansvar.

Däremot kan det vara värt att reflektera över en sak som jag ofta ser bli bortglömt. Fokuset på arbetslaget gör att individen ibland glöms bort. Många individer kan fara illa i en agil transformation. Ett välfungerande team kan bli destruktivt när de plötsligt får svårigheter och väljer att rikta sin besvikelse på en gruppmedlem. Den ökade transparensen kan blottlägga individuella svagheter, och människonaturen är ibland inte nådig mot svaghet.

Som chef har du ett ansvar för varje människa. Medan du kan delegera mycket av ansvaret åt de självstyrande grupperna, så behöver du vara uppmärksam på varje individ. Använd de agila metoderna för att skapa en bra och produktiv miljö åt majoriteten av dina medarbetare, och använd din unika roll som chef för att ta hand om dem som faller utanför. Och var inte rädd utan beredd, när de agila metoderna visar för dig att du har haft ledarbeteenden som kanske bidragit till ohälsa. Det är mycket vanligt att man bidragit till detta utan att riktigt veta om det. Metodernas kraft ligger mycket i att skapa större synlighet runt just konsekvenser av olika beteenden.

Agility is an ability

"Let's become agile!" I often hear it at the different consultancy assignments that I have, and it really is a good thing. But unfortunately it is often the case that the people saying it doesn't intend to become agile. Instead they intend to start using collaboration methods they have heard are "agile". Agility is something they intend to do rather than intend to be. They believe that agility are a number of collaboration patterns and methods, such as Scrum.

But that isn't how things actually work. Scrum isn't very agile for instance. Most of the techniques we use in order to become more agile are in themselves very rigid and inflexible. But when we start to apply them, we get a slightly better chance to actually increase the amount of agility in our collaborations.

Agility is the ability of a collaboration, a small group or a whole organisation, to swiftly change direction as needed. Sometimes we uncover new needs in a technical platform we work with: the agile methods first surfaced among system developers. Sometimes it is the people in the market that understand that they have new needs, so we need to restructure our ways of production.

The only thing the "agile" methods can do is to make the structural impediments to agility visible, and at times provide tools to remove some of them. It is not a magical oil that will provide agility even when you have decided to keep all the impediments. Rather, they act like a magnifying glass that makes radical inspection of the impediments possible, and like an axe to remove them.

The tools are painful to use. Radical transparency leads to everybody being immediately aware of the effects of desicions made. When you move around mandates and increases the capability to act at all levels, more people will be held accountable for the status quo. It hurts. The agility and flexibility of a dancer's body doesn't come without pain. If you want that flexibility in your organisation, you will need to do some tough exercises.

On the other hand: it will probably be worth it! The pain you experience in an agile awakening is nothing compared to the constant pain people feel in a organisation that cannot move due to lack of transparency and where they have no way to act. Achieving more agility isn't a walk in the park. On the other hand: it will take you to a much better place, should you decide to invest in it.

Agilitet är ett tillstånd

"Nu ska vi ju bli agila!" hör jag ibland sägas på mina uppdrag, och det är ju bra. Men jag inser snart att de som säger så tyvärr inte menar att det ska bli agila, utan att de ska börja samarbeta enligt metoder som de hört sägas ska vara agila. Agilitet är i deras ögon något man gör. En uppsättning samarbetsmönster, till exempel som i Scrum.

Men det är inte så det fungerar. Scrum är inte en speciellt agil metod till exempel. De flesta tekniker vi använder för att uppnå agilitet är i själva verket ganska rigida och oflexibla. Men de har den egenskapen att när vi börjar tillämpa dem på våra samarbeten, då ökar vi chansen för att vi ska få lite mer agilitet.

Agilitet är förmågan för ett samarbete, en grupp eller en hel organisation, att snabbt och smidigt byta riktning så snart det behövs. Ibland för att man plötsligt upptäcker nya behov i en komplex teknisk plattform man arbetar med, agila metoder växte ju fram inom systemutveckling. Ibland för att folk inom en marknad plötsligt upptäcker att de har nya behov, och den egna organisationen därför snabbt behöver ställa om sin produktion.

Agilitet är ett tillstånd i organisationen. Det enda de "agila" metoderna kan göra är att synliggöra de strukturella hinder för agilitet ni redan har, och ibland ge verktyg för att ta bort vissa av dem. Det är inte en salva som gör att man på ett magiskt sätt uppnår agilitet även om man bestämt sig för att behålla alla hindren. Snarare är agila metoder ett mycket starkt förstoringsglas för att skärskåda bristerna av idag, och en såg, yxa, mejsel och ett sandpapper för att ta bort dem.

Det är ganska smärtsamma verktyg. Den radikalt ökade transparensen som gör att effekten av alla beslut snabbt blir synliga för alla. Omflyttningen av mandat och nya förmågor att hantera situationer på, vilket gör att ansvarsutkrävandet blir mycket större. Det gör ont. Smidigheten hos en dansare kommer inte av att dansaren låter bli att utmana sin kropp. Vill du ha smidighet, i kroppen eller organisationen, krävs det ibland ganska tuffa övningar.

Ändå är det nästan alltid värt det. Smärtan i det agila uppvaknandet är inget emot den ständiga molvärk som människor upplever i en trögrörlig organisation som saknar transparens och där de saknar makt att påverka. Att uppnå lite större agilitet i organisationen är ingen enkel promenadrunda, utan en ganska utmanande fotvandring. Men å andra sidan kommer den att ta er till en bättre plats.

ALMA: Three lifecycle phases

Condition

When you need to take responsibility for a service during its full life cycle:

Solution

Clearly recognize two distinct phases in the life-cycle of a service: implementation of a number of changes (also known as development or design), and the service being in operation. Also recognize an intermediate state: deployment, a transitional phase when the service is put into operation.

Description

Service design (or development), service transition (or deployment), and service operation, have distinct needs. For service design, it is important to have a solid understanding of the problem domain and what solutions that meet the needs within that domain. For service operation, it is important to have stability so that people can rely on the service being there.

Since the best understanding of needs occurs when a person actually use a service, the chances of meeting them increase when we can develop features and put them into operation continuously. For that we need to design a deployment process that is fast, stable, and predictable.

Note that these three processes are run in parallel and in a flow. Needs are met when they are quickly identified, and solutions are quickly being designed to meet them, and the solution is quickly brought into flawless operation. We need to optimize the correctness and speed of this flow, while understanding that development, deployment, and operation are three distinct phases with different requirements.

History

This is basically the notion of "Service Design", "Service Transition", and "Service Operation" from ITIL.

(ALMA: Agile Lifecycle Management Anatomy)