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.