lördag 25 februari 2017

The Benefit of Management by Fear

In general, the possibility to avoid threats and pain is a stronger motivator than the possibility to gain something pleasant. This is true for most organisms where you can talk about motivation at all. Responding to threats with fear and avoidance is apparently a good survival tactic.

And like all creatures that are dependent on groups to survive, we are particularly fearful of rejection, that the group will reject us and leave us alone in the wild. Which the group will do if the most influential individual in the group tells it to.

This is why management by fear is such an effective strategy for motivating people to work. If you have the mandate to reject people and make their peers reject them as well, you can make them do anything.

Or, not really. There are a few things that the fearful brain is incapable of doing. So if you are planning to use management by fear there are a couple of things you need to be prepared to handle yourself.

You need to define the tasks for your subordinates since their fearful brains won't be able to come up with the tasks themselves.

The tasks need to be perfectly thought out because your people will perform them even though everyone can see that the result is flawed. A fearful brain doesn't dare to criticize your orders.

You need to increase the checks and controls. If subordinates fears showing you mistakes that has been made you need to find other ways bringing them into the light.

(Extensive checks are also important for linking the necessary punishment to bad behaviour. A small part of uncertainty whether or not you will be punished will strengthen the fear, but uncertainty is a strong demotivator. Most punishment should come as a logical consequence of past outcome.)

The responsibility for planning and follow-up if things are going according to plan or not from now one resides with you.

You must handle all the external relations. Fearful brains will focus on pleasing you and not your customers.

From now on you have to do all innovation. A fearful brain is incapable of experimenting.

Given that you are willing to assume these responsibilities, management by fear can be a great tool for your organization. The alternative is to create an organization of customer-focused, innovative responsible adults that can manage their own work according to the goals you set together. That will also require a lot from you as their manager, but it is a different set of tools.

lördag 11 februari 2017

Kvalitet OCH snabbhet

Den falska motsättningen mellan hög kvalitet och snabb leverans är en tankekonstruktion som verkar vara väldigt svår att göra sig av med.

Det kan ha att göra med dessa två kopplingar: slarvig leverans ger låg kvalitet, samtidigt som slarvig leverans utan större ansträning kan snabbas upp.

Så det går att få snabbhet i leveransen genom att slarva, med du kommer då att få låg kvalitet. Men du måste då också vara beredd på fortsättningen: låg kvalitet ger sedan långsam leverans. Defekterna som slarvet orsakade behöver tas om hand. Det du inte säkerställde igår poppar upp idag och rör till allting för er.

Den snabba leveransen sker inte på bekostnad av kvaliteten utan på bekostnad av framtida snabbhet. Snabbt slarv är ett lån från framtiden.

Det finns en mytisk modell inom projektledningen som kallas "projektpyramiden". Den ställer projektets omfång, tid, budget, och kvalitet mot varandra och vill påstå att man genom att vilja ha det ena måste ge avkall på det andra. Den bilden är falsk när den leder folk till att tro att det går att leverera ett visst omfång på en viss tid inom en viss budget om man bara får lov att tumma på kvaliteten. Istället är variablerna bundna vid varandra så att du så snart du sänker kvaliteten får en dramatisk höjning på tid och kostnad för det omfång du bestämt dig för.

Projektpyramiden ger en falsk bild av verkligheten, åtminstone i många producerande och tjänsteutvecklande verksamheter.

Produktivitetsökning kräver ordning och reda. Kräver att det inte finns så mycket okontrollerad varians i systemet. Det är därför som ett fokus på systematiskt kvalitetsarbete i förlängningen ger högre produktivitet (mer, bättre, snabbare och billigare). Men nyckelordet är systematiskt. Det handlar inte om kvalitet genom att individer sliter hårdare eller tar mer tid på sig och dubbel- och trippelkollar allt arbete. Eller genom att man gör väldigt mycket och sedan inspekterar fram den lilla del av produktionen som råkar blir bra. Det handlar om metodik.

Tricket från metodiskt kvalitetsarbete, det som lean och agila metoder använder, är att man gör god kvalitet billigt. Förtydligar kvalitetskraven så att de är otvetydiga och låter de som ska utföra arbetet och de som ska ta emot det utförda arbetet tillsammans avgöra om kravet är tvetydigt eller ej (i Scrum genom redokriteriet och klarkriteriet). Rapporterar blixtsnabbt så snart man ser att en avvikelse från överenskommelserna är på gång att inträffa och får snabba beslut om hur man ska göra. Bokför de avvikelser man av olika skäl inte kan hantera så att man alltid har med dem i beräkningen.

Och det ständigt pågående förbättringsarbetet. Vi dokumenterar hur vi arbetar idag. Vi analyserar vad som hindrar oss från att ta nästa steg mot större kvalitet och snabbare feedbackloopar (där leverans till människor som använder det vi producerar och deras användande är den viktigaste feedbackloopen). Vi experimenterar med vårt arbetssätt. Vi förenklar, arbetar i team, bryter ner i mindre delar, har snabb omplanering, automatiserar så många rutiner som möjligt som har med felsäkring att göra, och så vidare.

Det kräver ganska stora frihetsgrader för arbetsgrupperna för att de ska kunna arbeta med metodiskt kvalitetsarbete. Det kräver å andra sidan av grupperna att de hela tiden arbetar under stor transparens så att alla ser vad som händer, och att de arbetar med ständig riskreducering så att utforskandet av arbetssätten blir säkra och trygga.

När arbetsgrupper börjar använda lean och agila metoder utmanas de befintliga strukturerna. Myter i organisationen, som till exempel projekttriangeln eller tron på planerbarhet i komplexa miljöer, eller tron att effektivitetsförbättring i alla verksamhetens delar innebär effektivitetsförbättring på hela flödet, riskerar att avslöjas när verkliga mätdata synliggörs av de som arbetar nära det direkta värdeskapandet.

Personer som har sin yrkesroll och identitet baserad på att upprätthålla myterna blir hotade av det nya arbetssättet. Detta gäller inte minst många chefer som tillsatts för att bevara och förstärka en struktur som inte längre kan sägas vara hjälpsam. Det gör att förändringsarbete som syftar till att få både kvalitet och snabbhet förhindras av ett uteblivet skifte i tankesätt och kultur.

Samtidigt är det ofta dessa chefer som äger frågan om både kvalitet och snabbhet. De är tillsatta för att få till precis det de själva förhindrar, så länge de inte inser att det krävs ett nytt tankesätt och ett nytt beteende från deras sida. Att arbeta i det spänningsfältet utgör större delen av mitt arbete att stötta organisationen i förändringen. Det är väldigt intressant och väldigt utmanande.

lördag 4 februari 2017

When you can't iNvEsT

In agile development we have a backlog: a list of needs that we want to fulfill in a certain order. We also try to have a cross functional small team that take care of meeting the needs without having to handover stuff that must happen to other people. In certain agile frameworks (such as Scrum) the team shouldn't even have to interact with others when meeting the need so that they are able to independently take responsibility for a couple of weeks worth of work.

That means that each work item that meets a need (is valuable) also has to be small. We also want each item to be independent of the others so that we can give our primary stakeholder (for example the Product Owner role in Scrum) the opportunity to pick and choose any of the items in the backlog to be fulfilled.

In 2003 Bill Wake suggested that these three characteristics (I for "independent", V for "valuable" and S for "small") of a good product backlog item should be combined with the characteristics negotiable (in agile, a requirement is the starting point of a conversation and not the end of a discussion), estimable (just enough so that stakeholders can decide if it is worth it), and testable (if we can't test if a need is fulfilled or not, the need was probably not expressed clearly enough). And thus the acronym INVEST (independent, negotiable, valuable, estimable, small and testable) was born.

Now, while INVEST can be an ideal (since if we manage to make all of our items on the list INVEST compliant it is really easy to increase the agility in our development) many have found it hard, if not impossible, to achieve. So what should we do then? Abandon the whole idea? No. But think a bit. And know how to work with it.

The thing is that three of the letters in the acronym has everything to do with the organization. Why isn't the items negotiable? Why can't you reach a consensus on them? There is almost always a destructive power game present when people doesn't understand why the items on the backlog isn't the last word on how to meet a need or what the need is about.

Why isn't the item estimable? Are there hidden complexities that you haven't explored yet? Don't you have sound practices around refinement so that you know what it would take? And why isn't the item testable? Haven't you had all the required conversations yet? Doesn't people know what they want? Do you let people who know how to test things step up and participate in the item generation?

The N, the E, and the T are typically things that an agile transformation address, and it goes typically very well. It isn't that hard to create an environment where we collaborate on the items, negotiates what we would like to see done, make forecasts, and thinking about their testability. The problem usually resides with the other three.

Things can be cut into small partial targets. But in many environments, they are not valuable. Due to inherited complexity in the technical environment things cannot be small and valuable at the same time. They might be able to, later on, but not now. So we might have to slice down a valuable feature into smaller pieces, starting with a primitive version of the feature and improving it over the course of a few sprints. In the same manner, features may be dependent of each other and implemented and released in a certain order within a releasable package.

It is for circumstances like these a backlog split in three levels, as Dean Leffingwell suggests, is constructed. Closest to the team are the sprintable items that they can plan for and implement. A group such of sprintables is needed to implement a feature (the second level), and packages of related features that are needed together in order to generate business value (Leffingwell calls these packages Business Epics) constitutes the third.

The three tier backlog has its place when the items cannot be small, valuable and independent at the same time. It has been criticized for introducing complexity, but the idea is not to introduce complexity but to mirror the actual complexity we actually have to deal with. Then we can start to manage the complexity and hopefully work in order to reduce it.

Related: The SMIDIGT! module about the three tier backlog: documentation-the-backlog.pdf

söndag 22 januari 2017

När system krackelerar

Just nu (januari 2017) i Sverige är det några viktiga samhällssystem som verkar krackelera. Det finns många politiska reflektioner man kan göra runt det, vilket jag inte tänker ägna mig åt på den här bloggen, men det finns också ett antal reflektioner som definitivt har koppling till lean och andra smidiga samarbetssätt. Särskilt på att man så tydligt kan se sprickorna på systemnivå. Flera sanningar från systemtänkandet blir tydliga.

Störningar uppstår på en plats och syns på en annan. Just nu har akutsjukvården kris. Väntetiderna springer iväg och tangerar livsfarliga nivåer. Frågar man folket på golvet, på gemban, till exempel sjuksköterskorna, om orsakerna så är ett av de stora hindren för effektiv akutsjukvård att det inte går att skicka sjuka vidare till vårdplatser längre bak i sjukhuset. Bristen där slår igenom på akuten. Att fixa akutens problem handlar bland annat om att fixa vårdavdelningarnas problem.

Störningar smetas inte jämnt över flödet utan drabbar det sköraste området. Man hade med sig kanariefåglar ner i gruvor för att känna av problem med farliga gruvgaser. Innan halterna blev farliga för människorna tuppade kanariefågeln av och man kunde utrymma gruvan i god tid. Fåglarna var skörare än människorna och gav tydliga indikationer på en ohållbar situation.

Detta är ju en god lösning så länge som kanariefåglar anses vara mindre viktiga än människor. Problemet uppstår när det sköraste området samtidigt är ett av de viktigaste. Att låta akutavdelningar agera indikatorer på vårdavdelningarnas problem är kanske många kan hålla med om är mindre lämpligt.

Det går fort när det vacklar. Effekten av störningarna är inte linjära mot mängden. Alla system "buffrar", dvs kan härbärgera variation, upp till en viss gräns. Man märker alltså inte alltid när man närmar sig olika kapacitetstak med hög hastighet. När man närmar sig taken blir däremot effekterna ganska stora, och en systeminfarkt (att flödet helt kleggar igen) kommer snabbt.

Orsak och verkan kan vara åtskilt i tiden. En annan effekt av buffringen är att det kan ta tid innan man ser konsekvenserna av en systemhändelse. Och de aggregerade konsekvenserna av beteenden under många år kan drabba flödet under ganska kort tid. En skuld uppbyggd under flera decennier kan behöva amorteras av på ett halvår.

Det är alltid flera orsaker. System uppvisar oftast komplexa beteenden. Du kan nästan aldrig hitta en rak orsakskedja där en sak leder till en annan och så vidare. Det är nästan alltid fråga om flera saker som samverkar på flera sätt, ungefär som vädret.

System är oförutsägbara. Vi kan se att systemet beter sig skakigt, men vi kan inte förutse när i tiden något rasar eller kostnaden för konsekvenserna.

Våra intutioner är på många sätt inte lämpade för systemtänkande. Vi tror att problem uppstår där de syns så vi skjuter budbäraren eller försöker lösa fel problem. Vi fastnar för den första rimliga orsaksförklaringen och går inte vidare för att ta in den större bilden. Vi tror att saker som händer i snabb följd också har orsakssamband. När ett beteende inte omedelbart möter motstånd tror vi att det inte innebär någon fara på längre sikt. När systemet skakar tror vi att den första lösningen måste vara att tillföra mer resurser där det skakar istället för att utjämna varians och se om det är några andra delar som ska förstärkas. Och vi tror att den som pekar ut oförutsägbarheten inte har förstått systemet, vi tror nämligen att saker i princip är förutsägbara och planerbara om man bara försöker tillräckligt hårt och är duktig.

Men intuitionerna kan inte skydda oss från de verkliga systembeteendena. Det vill alltså till att vi allesammans tar fram systemglasögonen och de verktyg som faktiskt finns för att lösa systemiska problem. Allt detta är lösbart, om vi vill.

söndag 15 januari 2017

Satisficing

I am reading up on Satisficing, a decision making strategy that aims at satisfying a need but just sufficiently. It seems like we, when making decisions, often go through a list of options until we see one that we believe meets our needs, given our mental models about needs and how the options will work out. We simply tend pick the first match.

Evaluation of options is hard mental work, and making decisions takes a toll on our psychological motivation. Therefore there will be fewer people who opt for trying to analyze all available options before making a decision (as a believer of rational choice theory would assume they do), and more people who are seeking an easier way out by evaluating as few options as possible (a behavior more in line with what proponents of choice theories of psychological realism believe).

We also have the systemic effect of weeding out those who tries to analyze every option when there is no complete list of options to choose from. They will never be included in the count of decision makers since they are stuck with analyzing. So when we are dependent on other people making a decision, we can expect that they for the most part are using a satisficing strategy.

What does that teach us?

First of all the importance of mental models when understanding your own needs and how they might be met. People will pick the first option that they believe will fix things according to their understanding of the situation. The way we talk about things, frame situations, use illustrations and parables will totally determine what options we pick. Make sure that the mental models reflect the actual situation.

Then that the order of presentation is very important. Any option higher up in the list will have a higher chance of being chosen, regardless of its effectiveness compared to the other options further down. So if we want to increase the chance of picking an effective solution to a problem we have, we should first try to quantify, or at least rank, the effectiveness of them before picking one.

And last but not least: since we use this and other decision making strategies that works against making optional choices, we can assume that our decisions will be bad. We can try to become better at it, but we must realize that we will make the wrong choices from time to time. So we have to employ strategies that reduce the bad consequences of a bad decision.

Here the preferences from agile decision making comes handy!

In agile, we try to make it small before making it big. Everything should be seen as an experiment that we run for a limited time, and then we can make a better decision whether we should continue or not. Is this good enough for now, and is it safe enough to try?

We will also try to optimize for options when we decide. Given two paths, if we chose the one that has many branches ahead we can always change course as we learn more about our goal and how the reality works. Making definitive decisions early on when we have access to very little information may sound cool and you feel like a Powerful Leader when you do it, but it isn't really the most effective thing to do. Maintain your flexibility at all times.

The journey to value creation is a journey of insights. What we grow together is the body of knowledge. When we investigate our options we should look out for the options that gives us the most learning opportunities. If it is impossible to be sure that we have picked the right option, it becomes very important to quickly learn if our chosen path was the wrong one to take. That will increase the chance of making the next step on the journey better.

And when evaluating and learning, remember the words of Deming: "Without data you're just another person with an opinion". But also from the same man: "The most important things cannot be measured", and "The most important figures that one needs for management are unknown or unknowable".

Happy decision making!

tisdag 3 januari 2017

Man måste avveckla också

Vad händer om en ledning tror att IT alltid är något man inför, och lägger all krut på dyra utvecklingsprojekt? Man får ett växande beroende till ett myller av applikationer och tjänster. Till slut kan man inte förändra någonting, och hela ens digitaliseringssatsning riskerar att bli ett haveri. IDG skriver om det idag, och Jonas Söderström har varit inne på det flera gånger.

Man måste avveckla systemen också! Eller rättare: Ta ett livscykelansvar. Införa en tjänst när den behövs, ändra på tjänsten när det behövs, och ta bort tjänsten när den börjar göra mer skada än nytta.

Det finns tusen och ett skäl till att detta inte görs. Det är sällan någon annan än VD:n som äger frågan om helheten, och få VD:ar förstår sig på hur man äger en flora av digitala tjänster. Man kan ha konstiga ekonomiska ramverk på plats som ser funktionstillväxt som värdeskapande och funktionsavveckling som att man förstör värden, trots att det i verkligheten kan vara precis tvärtom: när funktionstillväxten sänker värdet på anläggningen och renodling och avveckling av funktioner ökar det.

Vi har förstås även vår instinktiva rädsla för att välja bort. Fear of missing out, eller loss aversion som är den etablerade termen inom psykologiforskningen. Det är alltid lättare att säga "ja" och lägga till något än att säga "nej" och ta risken att välja bort något mycket värdefullt. Att säga "ja" till en avdelning som ber om mer är också psykologiskt enklare än att säga "nej" till folk.

Ändå är det ofta rätt sak att göra. Men det krävs mod. En av de första sakerna som Steve Jobs gjorde när han kom tillbaks till Apple var att våga slakta en uppsjö av varianter och modeller som var och en var ekonomiskt motiverad och hade sin lilla roll att spela i ett mycket litet ekosystem men som sammantaget bidrog till att skapa en sämre helhet.

Man måste säga nej till även bra affärer, bra digitala tjänster, bra stödsystem, för att orka satsa på de som är bäst: både bra och i linje med ens strategi. Hur kan lean och agila metoder hjälpa?

I en organisationsgemensam behovslista (backlog) ser man hur fokus på färre saker kortar ledtiderna i värdeskapandet. När alla i organisationen känner till spillkällor och har förmåga och mandat att arbeta med ständig förbättring på helheterna så föds insikterna om behovet av avveckling naturligt. Genom att tydliggöra produktägarskapet för helheten, till exempel i form av en uttalad produktägarperson i en liten organisation eller en gruppering i en större. Genom att fokusera på tjänstestrategin och visionen.

Och inte minst genom att ha ett ekonomiskt ramverk för beslut runt tjänstefloran som optimerar på värdeskapande. Till exempel genom att bygga på några av de principer som den amerikanska ekonomiprofessorn Donald Reinertsen listar i sin bok "Flow". Alla beslut kan inte alltid räknas ut, men man kan se till att de beslut man fattar inte är ekonomiskt oförsvarbara.

Om tjänsteperspektivet är det första man behöver tillskansa sig när man vill syssla med digitalisering så är detta, livscykelperspektivet, det andra. Och då använda sig av de verktyg som finns som stöder det.

söndag 1 januari 2017

Scaling Agile Capabilities

It is my experience that people who think about how to achieve more organizational agility benefits from looking at things from a business capability viewpoint before thinking about organization, tools, and what agile frameworks to experiment with.

A business capability is the ability for a part of the organization to meet a need, internally or externally. The capability could be translated into an expectation of what a part of the organization can provide rather than how it is achieved. For instance the capability to create an increment of valuable deliverables at regular intervals, or the capability to provide a clear answer on what the most important thing is right now.

Methods, frameworks, collaboration techniques, particular roles et cetera is on the other hand totally focused on the how. The capability to create a valuable increment at regular intervals has to be performed by a single cross functional team according to some, the capability to answer on the organizational priorities has to be performed by a single person whose name will be "Product Owner", and so on.

The methods holds a promise: follow me and the capability will emerge! And it is true that these tested techniques often delivers. During my last ten years of experimenting with agility I have tried many of the techniques others have used and written about, and we have achieved pretty good results with them.

But it is also true that we have applied the same techniques in other places and seen things become worse. So it is clearly not the techniques themselves that generates the outcome, but the application of them in environments where also other factors contribute to the result. Of course. Collaborations are complex systems. You can never attribute success to only one thing. Every situation is different and small changes in the circumstances have a huge impact on the result.

Controlling the outcome in a complex environment requires tweaking. We need to steer the system empirically: inspecting the situation and the desired outcome, adapt the action, inspect the result of the adaption, and so on. This is the very heartbeat of anything lean and agile.

Focusing on the desired business capabilities gives you a view on the outcome. What is it that you want to achieve? What is the need?

In some environments it takes a couple of specialized teams to create value. It is as of now impossible for a single team to do this in isolation. So you need the capability for teams to plan, execute, and follow up together, just as they do as individual teams. You could use the Nexus collaboration patterns for this, or organize into a release train as SAFe describes, or trying something else, but it is the capability of many teams acting as one that we need.

In some environments it is hard to create value in chunks that are independent, valuable, and small at the same time. In those environments it can be helpful to think about independent business epics, valuable features, and small slices, as three separate things to manage in different levels of the backlog. Because we may need the capability to divide, explore, and prioritize epics, features, and slices in different ways using different cycles (not all information flows at the same rate).

This is a way of thinking and discussing needs and how to meet them. It lifts us above meaningless quarrels on what processes and tools we should use and instead helps us focus on the good interactions between people. Talking about business capabilities, thinking like agile business architects, is a way of dealing with systemic needs and the different ways of meeting them.

I have found the perspective quite helpful.