måndag 30 november 2015

Möten?

Läser denna bok om hur man faciliterar distansmöten och påminns om att aldrig ha ett möte utan att veta syftet.

Utmärkande för smidiga metoder är att vi oftast har väldigt strukturerade möten. Det beror på att varje möte ingår i en process med ett tydligt ingångstillstånd och ett tydligt mål. Inför arbetsplaneringsmöten vet vi prioriteringen bland arbetspaketen och vi vet hur mycket vi kommer att kunna arbeta under den närmaste perioden. Inför arbetsuppföljningen vet vi hur det gick under perioden och mötet handlar om hur vi ska agera på informationen. På ett förbättringsmöte använder vi strukturerade verktyg för att hitta vilka problem vi ska attackera och hur vi ska göra det.

På ett möte diskuterar man ibland saker, alltså belyser en fråga. Då använder vi verktyg som stöttar diskussionen, till exempel skapar ett faktaträd för att slå fast kända sakförhållanden eller visa på att ett sakförhållande är okänt, och så kan vi blottlägga och argumentera för våra värderingar och på det sättet skilja dem åt.

På ett möte innoverar man ibland. Då använder vi verktyg som stöttar innovation, till exempel verktyg som får oss att tänka stort och nytt och verktyg som får oss att smalna av och konkretisera och pröva värdet av de nya idéerna.

På ett möte beslutar man ibland saker. Då använder vi verktyg som stöttar beslutsfattande, på det sätt som vi vill att beslutsfattande ska ske, givet de maktstrukturer vi har och vill använda oss av.

Vad vi helst inte vill göra på ett möte: sitta ner och prata och bestämma sig ad hoc. Ad hoc-processer är alldeles för tyngda av dolda maktspel och oklara tankestrukturer. Dessutom tar de en förfärligt lång tid. Mötesverktyg snabbar upp processen eftersom de aktiverar hjärnorna på rätt sätt.

Det som krävs är tydlig facilitering, alltså att någon tar på sig att leda mötet med hjälp av de överenskomna verktygen utan att för den sakens skull kunna påverka utfallet mer än någon annan. Det är en lite klurig konst, men tack vare verktygen är den inte omöjlig och jag önskade verkligen att fler började använda dem. Alltför många klagar på tyngden av alla möten utan att göra något åt den.

söndag 29 november 2015

SAFe "Feature" och Jira

I den lilla världen kan ett ensamt team leverera färdiga funktioner med bara några veckors (en sprints) mellanrum. Eftersom en funktion kan beskrivas i en sk "User Story" har man kallat de saker som ett team levererar under en sprint för just en "user story". Flera funktioner som hör ihop brukar kallas för en "epic".

Backloggverktyget Jira låter därför scrumteam hantera krav i ärenden av typen "Jira User Story", och flera sådana hanteras av den samlande ärendetypen "Jira Epic". I ärendetypen "Jira Epic" kan man följa upp hur varje ingående "Jira User Story" färdigställs.

Men om man måste skala upp det här? Om man inte kan leverera en funktion under en sprint utan behöver flera sprintar? Om det är mer än ett team som ska jobba med samma funktion? Alltså om arbetet med samma funktion måste delas upp mellan flera team och/eller delas upp över tid?

I Dean Leffingwells fyrdelade modell för en systemutvecklingsbacklogg (från Agile Software Requirements 2008, som senare blev ramverket SAFe) inför han därför en ärendetyp mellan user story och epic: en sk "feature". Tanken är att man på en övergripande nivå kommer fram till vilka funktioner man vill leverera, fångar var och en i en feature, och sedan bryts varje feature upp i mindre skivor av ett eller flera team och hamnar på deras respektive team-backloggar. På så sätt kan teamen följa upp hur de levererar en hel funktion även om de måste dela upp arbetet i delmål.

De sprintbara delmålen som hamnar på varje utvecklingsteams backlogg heter även i Leffingwells modell "user story". Så förhållandet i Leffingwells modell mellan "SAFe User Story" och "SAFe Feature" är precis densamma som i Jiras modell mellan "Jira User Story" och "Jira Epic". En "Jira Epic" delas upp i flera "Jira User Stories" på samma sätt som en "SAFe Feature" delas upp i flera "SAFe User Stories".

Samtidigt innehåller som sagt Leffingwells modell fortfarande begreppet "epic" ("SAFe Business Epic" samt "SAFe Architectural Epic"), och detta skapar förvirring när folk vill använda Jira för att hantera SAFe:s modell av backloggen. En "epic" i Leffingwells modell består av flera "SAFe Features" som i sin tyr består av flera "SAFe User Stories". En "epic" i Jiras värld består av flera "Jira User Stories" och det är allt.

Hur gör man? Tänker man uppifrån och ner så är det frestande att att beskriva "SAFe Business Epic" och "SAFe Architectural Epic" med hjälp av "Jira Epic". Det blir då på samma sätt frestande att använda en "Jira User Story" för att beskriva en "SAFe Feature". Men då orsakar man en massa svårigheter för alla andra i samarbetet.

En "SAFe Feature" ska inte ligga på ett enskilt utvecklingsteams backlogg utan på en sk "Program Backlog" för att hanteras på en överordnad nivå. En "Jira User Story" ska däremot handhas av ett team.

En "SAFe Feature" ska inte vara bunden till en viss sprint. I Jiras sprintplaneringsverktyg ska "Jira User Stories" bindas till en viss sprint.

En "SAFe Feature" ska kunna delas in (av teamen) i flera "SAFe User Stories", och varje "SAFe User Story" ska kunna estimeras och planeras och utvecklas av ett team för sig. Men om vi använt "Jira User Story" för att beskriva en "SAFe Feature", vad ska teamen använda för att kunna hantera sina "SAFe User Stories"? Hur ska de kunna göra sitt jobb om vi tagit verktyget från dem och använt det till annat?

Dessutom är det så att Jiras styrka är möjligheten att bringa ordning i en mängd arbetspaket och hur de förhåller sig till varandra. Det finns altid många fler "SAFe User Stories" än "SAFe Features", och många fler "SAFe Features" än "SAFe Epics". Det verkar vara dumt att slösa ärendetyper i Jira på att hantera ett fåtal saker som dessutom sällan förändras. Effektmålen och förutsättningarna för varje epic tenderar att vara stabila, det är informationen om hur epicen ska implementeras (vilket fångas i features och user stories) som förändras ofta och kräver verktygsstöd.

Så det rimliga är såvitt jag har sett att använda "Jira User Story" för att fånga en "SAFe User Story", och använda "Jira Epic" för att fånga en "SAFe Feature". Jag har sett konsekvenserna både av att använda Jira Epic för epic och för feature, och det blir oerhört trassligt för teamen att kunna koordinera sitt arbete om de inte får använda Jira User Stories för sina teambackloggar.

Vad ska man använda för att fånga sina "SAFe Epics" då? Man kan använda "Jira Epics" och länka till andra "Jira Epics" som fångar features. Man kan använda ett annat verktyg. Jag har goda erfarenheter av antingen en mapp i ett filarkiv (under versionskontroll), eller en wikisida per epic (kanske i Confluence, Jiras syskon som är en wiki). Låt sedan de "SAFe Features" som tillhör denna epic peka ut länken eller sökvägen dit. Sätt en "label" på din "Jira Epic" (="SAFe Feature") som beskriver vilken epic det rör sig om. Ha ett prefix i namnet på varje "SAFe Feature" som pekar ut vilken epic det rör sig om.

Det enda argumentet som jag tycker håller emot tanken att använda "Jira Epic" för att hantera en "SAFe Feature" är att man tyvärr inte kan ordna sina "Jira Epics" i en sträng ordning. Man kan alltså inte prioritera sina "SAFe Features", sin "Program Backlog", på samma sätt som andra backloggar. Men i praktiken har jag sett att det inte är något problem. På epicnivå handlar det inte så mycket om att prioritera "SAFe Features" löpande, utan om att bestämma vilka som ingår i en viss epic och vilka som inte gör det. Behovet av att dra-och-släpp-sortera sin programbacklogg är långt mindre än behovet av att dra-och-släpp-sortera teambackloggarna. Det är teamen som har det största behovet av "Jira User Stories", så låt dem använda dem till sina "SAFe User Stories".

När man skapar ett smidigt lean/agilt flöde börjar man från flaskhalsarna och arbetar sig bakåt. Eftersom utvecklingsteamen är den trånga sektorn behöver vi uppfylla deras behov av smidigt verktygsstöd först. Fungerar inte golvet smidigt kommer ingenting att fungera smidigt.

lördag 28 november 2015

Kniberg om storskalighet

Henrik Kniberg gav ett föredrag om storskalig agil utveckling nyligen, och av döma av sammanfattningen på InfoQ (se länken) så var det ett bra föredrag med observationer som är helt i samklang med mina.

Jag gillar särskilt att han trycker på att man måste förstå varför man skalar. Storskalig agil utveckling är inget eftersträvansvärt. Om en liten grupp människor oberoende av omgivningen kontinuerligt kan leverera nyttigheter som möter människors behov så är det att föredra. De storskaliga teknikerna tar vi till när vi måste koordinera fler än en handfull personers arbete och/eller nyttigheterna tar lång tid att leverera.

Det kluriga är alltså hur teamen kan hålla sig i synk med varandra och hålla ordning på beroendena mellan dem. Henrik pratade om tre grundläggande frågeställningar man behöver ha svaren på:

  1. Hur man bryter ner det arbete man ska göra ("slicing the elephant").
  2. Hur man bör organisera arbetslagen (ta reda på vilka människor som bör göra vad).
  3. Vilka återkopplingar ("feedback loops") som behöver finnas för att koordinera arbetet.

Det är en konkret lista som matchar observationen att man först behöver ta reda på vad man ska göra innan man börjar fundera på organisationsformer och samarbetsmetoder (se Jim Womacks 3P).

Kruxet när man hanterar skalning är att det hela tiden är fråga om avvägningar, något som Henrik också trycker på. Om vi organiserar arbetslagen på ett sätt kommer behovet av återkopplingarna bli ett. Om vi organiserar arbetslagen på ett annat sätt kommer behovet av återkoppling bli ett annat.

Henrik påmminer om att det alltså därför inte kan finnas något rätt eller fel, utan varje organisation måste hitta sina avvägningar utifrån sina behov. Man kan inte hitta ritningar som automatiskt passar flera.

Det jag stannar upp inför är den svåra frågan om hur man fördelar ansvar mellan team. Man kan organisera sig utifrån lösningens bakomliggande komponentstruktur, men det betyder att varje levererad nytta (som ju sker i ett samspel mellan lösningens komponenter) kräver stor koordination mellan komponentteamen. Det är min och hela branschens observation att om det är möjligt ska man istället skapa team som inom sig själva kan leverera hela nyttor (sk "feature teams").

Men i organisationer som har en tillräckligt komplex miljö går det inte att sätta samman team som klarar av att leverera hela nyttor. I de enkla fallen, som i Henriks exempel med en trelagersarkitektur (klient, server, databas) är det förstås möjligt. Men om plattformen är krångligare än så? Teamen blir då antingen för stora, eller så blir de inte stabila utan behöver göras om inför varje ny nytta.

Vi kan sikta på att hålla nere antalet team som krävs per nytta, men det kommer ändå att uppstå ett behov av att för varje sak man gör koordinera mellan åtminstone två team, dvs situationen blir precis som den som Henrik varnar för (se bilden med det ledsna ansiktet vid "Coupled teams"). Det är trögt att få till agilitet i den situationen.

Men det går! Man kan använda smidiga synkroniseringstekniker som gör ansiktena betydligt mindre ledsna, och i de organisationer där jag har ramlat på den här situation har vi använt dem med någorlunda framgång. På samma sätt som smidiga tekniker får individer att jobba bra ihop i team kan smidiga tekniker få team att jobba bra ihop i olika och växlande konstellationer.

En del av de teknikerna utgår från det som Henrik visar i bilden om hur team kan synka med varandra. Organiserar man sig utifrån mönstret "Team of small teams" man man skapa stabila samverkansformer mellan teamen som tar bort en del av synkroniseringssmärtorna. Min erfarenhet är att samma tekniker med framgång kan användas om man organiserar sig i "Team of team of small teams" eller "Web of team of small teams". Det som krävs är en synkronisering på övergripande nivå där organisationen kan ge klara besked om syfte och prioriteringar, så att alla teamen vet vad de ska sträva efter.

tisdag 24 november 2015

Agility - ny plansch

I mina kursmaterial finns det översiktsbilder som förklarar olika koncept. Ny har jag börjat bryta ut dessa ur dokumentationen och publicera dem som separata PDF:er.

PDF med grundläggande information om agilitet.

Disciplin

Agila metoder erbjuder lättnad för hårt ansatta arbetslag. Otydlighet försvinner, vi tvingar omvärlden att fatta prioriteringsbeslut, vi hålls inte längre ansvariga för osäkra estimat, ledningen tvingas anpassa sin karta efter den faktiska terrängen, vi får styra över vår tid själva, med mera.

Men för att detta ska fungera krävs disciplin i arbetslaget. I samma sekund vi märker att vi inte kommer att uppfylla förväntningarna på oss måste vi larma intressenterna. Har vi en överenskommelse om klarkriterium för olika arbetspaket och leveranser, så ser vi till att vi håller de överenskommelserna. Eller så rapporterar vi avvikelsen. Vi låter inte strukturella problem kvarstå utan arbetar med rotorsaksanalys och ständigt förbättrade arbetssätt för att ta bort dem

Omgivningen kan lita på ett agilt självorganiserande arbetslag. Laget måste inom sig själva ha den förmågan att hantera sig själv, annars fungerar inte självorganisationen.

De 12 agila principerna bakom det agila manifestet slår fast att ett agilt arbetslag strävar efter excellens i leveransen. Exakt vad det innebär kommer man fram till genom bra samtal med sina intressenter, och det man kommer fram till, det håller man.

Utan denna disciplin och förmåga till självstyre fungerar inte de tekniker vi vanligen använder för att få till mer smidighet.

måndag 23 november 2015

Resiliens

Beteendeförändring med agila metoder driver som sagt kulturförändring, men det krävs att man inte gör avkall på vissa hygienfaktorer.

När man startar förändringen behöver den grupp som förändringen startar i få ett skydd mot blockerande faktorer. De får inte utsättas för osäkerhet: antingen är deras arbetsuppgifter och omständigheterna för dem kända på förhand, eller så ska det finnas en tydlig process för hur de hanterar plötsliga förändringar i målbilden.

De får inte heller vara osäkra på vilka mandat de har, och de ska ha mandaten i praktiken och inte bara i teorin. Har de rätt att bestämma en viss sak ska inte deras beslut plötsligt överprövas. Var mandatfördelningen ett misstag kan man alltid ta upp det och justera den, men det ska inte ske ad hoc utan i den vanliga strukturerade förbättringsprocessen (för en sådan har ni väl?).

I de fall där jag får lov att vara med och leda själva förändringen följer jag alltid inflödet av arbetsuppgifter (målbilden) långt utanför gruppen. Ju längre "uppströms" jag kommer och fortfarande ha inflytande över flödet, desto stabilare flöde kan jag etablera. I värsta fall är hela omgivningen runt teamet skakig, och man får införa de stabiliserande verktygen i själva teamet. I en mer mogen organisation är omgivningen runt teamet villig att påverka sina egna arbetsrutiner för att inte skapa onödig ryckighet i beställningsflödena.

På samma sätt utforskar jag linjeorganisationen runt teamet: vilka mandat och förmågor har man, och vilka av dem är man villig att delegera till teamet? I värsta fall har man ingetdera, och då får man istället skapa synlighet i hur det dåliga arbetsresultatet beror på avsaknaden av möjligheter.

Det viktiga är att eliminera osäkerheten. Otydligheten.

Osäkerhet på vad man förväntas leverera och osäkerhet på vilka medel man har, det skapar en stress som triggar defensiva beteenden hos alla inblandade. Precis alla beteenden vi önskar i en agil transformation (till exempel lättrörlighet, påhittighet, samarbete, frihet från skuld och skam, synlighet) blockeras av defensiva beteenden.

Många har genom åren blivit förvånade över att jag inte börjar förändringen i teamet utan istället tittar på teamets miljö, men det är alltså för att se om det går att göra något åt miljön. Kan man påverka mijön direkt slipper vi hjälpa teamet att använda tekniker avsedda för att få ett team att förbli någorlunda produktiva i en destruktiv miljö. Att organisationen lägger resurser dels på att skapa en dålig miljö och sedan på att skydda teamen ifrån dem är rent slöseri.

Kultur är konkret

"Agilt är en mental beredskap att hantera förändring!" "Agilt bygger på tillit och engagemang!" "För att få agilt att fungera behöver du en kultur som inte går ut på att skuldbelägga!"

Så kan det låta. Och det är sant. Det krävs ofta ett kulturskifte för att få större organisationsagilitet. Och folk är ganska ofta medvetna om att kulturen behöver ses över. Men jag vet inte hur många gånger jag sett att man försöker sig på resan mot större agilitet utan att samtidigt ge förutsättningar för kulturskiftet.

Man stöter ibland på uppfattningen att kultur är något svårgripbart, men att man automatiskt förändrar den om man bara vet om att den behöver förändras och pratar riktigt mycket om förändringen. Men det stämmer inte.

Om vi tänker på kultur som de grundläggande förväntningar vi har på vårt eget och andras beteende inom ett sammanhang, så förstår vi att vi kan påverka kultur på precis samma sätt som vi kan påverka förväntningar överhuvudtaget. Hur vi talar om saker och ting spelar förstås roll, till exempel om vi ens har begrepp för viktiga saker. Det är svårt att skapa en mer empatisk kultur om inte människorna däri har tillgång till ord som beskriver hur vi känner oss och hur det påverkar.

Men den starkaste kulturbäraren är summan av alla faktiska beteenden. Det är hur vi själva och andra faktiskt agerar som bestämmer våra förväntningar. Det är därför folk har fel som påstår att man inte kan skapa ett kulturellt skifte genom att byta arbetssätt. Det är just genom att byta arbetssätt som det kulturella skiftet sker.

I de fall där ett utbytt arbetssätt inte lyckats förändra någon kultur finns det ofta tre bakomliggande skäl:

Ytlig förändring - Det nya arbetssättet har inte utmanat de befintliga kulturbärande praktikerna. Man kan till exempel ändra vilka som är med på vissa möten, men om man inte ser över själva beslutsmakten också kommer mötesnärvaron inte att göra någon större skillnad. Man kan byta begreppsapparat, men så länge som det inte medför någon förändring i beteendet spelar bytet ingen roll.

Kvarvarande blockeringar - Även när man låter det nya arbetssättet gå på djupet måste man också se till att kvarvarande blockeringar faktiskt upphävs. Man kan till exempel införa en planeringsrutin som optimerar på att ärenden ska handläggas snabbt, men om det finns kvar en uppföljning som optimerar på beläggningsgrad per handläggare är risken stor att beläggningsgraden bedöms vara viktigare än snabbheten, och förändringen får ingen effekt.

Ingen ståndaktighet - Ett skifte i beteende som på allvar utmanar den befintliga kulturen kommer att möta motstånd. Inte nödvändigtvis på grund av att människor vill göra motstånd, utan på grund av tusen små inbyggda skäl i den befintliga organisationen. En förändring i beteendet som är i samklang med den befintliga kulturen, i samklang med vad som uppfattas som naturligt, den sätter sig mycket fort. En förändring som utmanar den befintliga kulturen tar mycket längre tid på sig att sätta sig. Man behöver alltså tvinga sig till det nya sättet att agera på under mycket längre tid, om det nya sättet på allvar driver kulturförändring.

Det är här många tar miste. De erfar motståndet, och så drar de slutsatsen att det inte går att genomföra förändringen om man inte först förändrar kulturen, och lägger ner precis den förändring som hade åstadkommit ett kulturskifte om de bara orkat hänga kvar och hålla i.

Det här betyder inte att motstånd betyder att du är på rätt väg. Den förändring du vill genomföra kanske är till det sämre? Du kanske möter motstånd på goda grunder? All förändring är inte till det bättre. Men antag att det du vill åstadkomma är det? Motstånd är naturligt. Om du vill skapa den förändring i kultur som krävs för att organisationen ska bli mer agil så behöver du hålla fast vid de nya beteenden som speglar den nya kulturen. Och de beteendena kommer att skava, tills den kulturella förändringen har satt sig.

torsdag 19 november 2015

Tre kärnprocesser

Det finns många processer inom förvaltningsramverk. När folk skapar processramverk börjar de med de viktigaste processerna. Sedan lägger de på fler och fler tills de ser att allt som krävs är på plats. Problemet uppstår för folk som sedan ska börja tillämpa ramverken. Hur ska de kunna identifiera kärnprocesserna? Kunna skilja det viktiga från det oviktiga?

Det finns tre processer som är särskilt centrala i tjänsteförvaltningen, eftersom de direkt styr över hur tjänsten ser ut:

  1. Förändringshantering (Change Management) - hur vi ska förändra tjänsten.
  2. Incidenthantering (Incident Management) - hur vi hanterar avbrott och störningar i tjänsten.
  3. Problemhantering (Problem Management) - hur vi hanterar de bakomliggande orsakerna till avbrotten och störningarna.

Dessa tre hänger intimt samman. Det är förändringarna som vi genomfört som ger upphov till incidenterna, och de bakomliggande problemen behöver en förändring för att kunna lösas. Samtidigt är bandbredden i utvecklings- och förvaltningsorganisationen ofta stabil och ändrar sig inte så ofta, så vi måste hela tiden bestämma oss för om vi ska använda tiden till grundligt problemlösningsarbete eller till att täcka över bristerna med snabba fixar under tiden vi försöker fokusera på en större förändring som förhoppningsvis får incidenterna att sluta.

I organisationer där man försöker separera dessa tre processer får man problem. Separationen är ett sätt att dölja den starka kopplingen. Vill man istället behålla förvaltningen agil kan man centralisera besluten till en och samma gruppering som prioriterar det som behöver göras genom att bestömma över behovslistan och vara de som ytterst godkänner det sätt som den operativa personalen hanterar och värderar incidenter på.

[En liten observation från ITIL: Den förändringshanering (Change management) jag pratar om här är större än CM-processen i ITIL. Den innefattar hela förändringens livscykel från förslag till driftsättning. Tänk också på att ITIL på oklara grunder har förlagt Application Development till transitionsfasen istället för att se det som en del av tjänstedesignen. Om vi tänker på transitionen enbart som utrullning av implementerade förändringar och låter designfasen innefatta allt som har att göra med utvecklingen av dem, så blir det mer logiskt givet hur utveckling fungerar (utveckling är design) och mer kompatibelt med de agila arbetssättens prövande iterativa metoder.]

En projektskeptikers bekännelser

Jag har på sistone varit inblandad i en del diskussioner om projekt. Dels i de uppdrag jag har, dels i flera diskussioner på konferenser och på nätet. Jag menar ju att projekt ofta innebär stora hinder för agilitet i organisationer, om vi med projekt menar ett arbete av tillfällig karaktär i en tillfällig organisation, mot ett fast mål till en fast tid och kostnad.

Till att börja med håller jag med att om arbetet verkligen är tillfälligt, som en enstaka förändring inom ett område där verksamheten normalt inte förändrar sig, så är det nog projektarbete som krävs. Ett projekt är som en byggnadsställning av tillfällig organisation, planering, resursförsörjning, och styrning. Vi tar till det när vi gör vår ombyggnad, men annars inte. Men projektet kräver att den ordinarie verksamheten släpper till och underordnar sig projektets plan och behov. Annars får vi förseningar och målkonflikter och andra stora strukturella kostnader.

Hade projekten bara dykt upp i de sammanhangen hade jag inte haft så mycket emot dem. Men jag ser organisation efter organisation som kör flera projekt, både efter varandra och parallellt, och ofta utan att kunna leda och styra dem i förhållande till varandra. Vilket inte är så underligt, jag har ännu inte sett en projektmodell som bygger på konstant anpassning av den egna planen i förhållande till alla andras planer. Tvärtom verkar de projektmodeller som finns vara byggda för att driva den egna agendan främst. De är inte gjorda för att köras parallellt med hänsyn till varandra, utan de inkräktar snarare på varandras resurser och bemanning.

Portföljstyrningsmodellerna jag sett har inte heller varit inriktade på att styra projekten smidigt mot varandra, utan handlar om att starta och följa upp projekten som vore varje projekt oberoende av det andra.

När man sedan ser till innehållet i projekten kan man ifrågasätta hurpass tillfälliga de är. Det är sant att just den här genomgripande förändringen av våra datasystem varken har skett förr eller kommer att se senare. Men nästa kvartal har vi en ny förändring, och kvartalet därefter har vi ännu en förändring. Att förändra datasystemen är helt enkelt en del av vår verksamhet. Ja, att implementera just detta EU-direktiv i förvaltningen är säkert en engångsföreteelse. Men nya EU-direktiv dyker upp regelbundet. Att implementera dem är vårt jobb. Att utveckla nya bilmodeller är vårt jobb. Och så vidare.

Projekt är disruptiva i sin natur, och tanken är att vi ska ta till dem när vi ska vara disruptiva. Men disruption har en oerhört hög kostnad. När vi dessutom släpper lösa flera parallella disruptioner ska vi kanske inte bli förvånade om vårt värdeutflöde i organisationen blir väldigt lågt, eller om projekten börjar lägga krokben för varandra. Naturligtvis oavsiktligt, det här är ett systematiskt problem och inte resultatet av någon människas illvilja eller inkompetens.

En av projektmetodernas styrkor är att man sätter samman en tillfällig organisation som ofta blir mer tvärfunktionell än vad den befintliga linjen är. När en linjeorganisation i sig själv saknar förmåga att agera effektivt tvärfunktionellt så erbjuder projektmetoderna ett sätt att frigöra kraft och planera och leverera. Men då finns det ett alternativ som innehåller fördelarna från projektarbetet men utan flera av dess nackdelar, nämligen att ge linjen den planerings- och leveransförmågan. Istället för att tillfälligt åtgärda linjens brist på kompetens med en tillfällig organisation, så angriper vi rotorsaken och förändrar linjen. Det är här flera av teknikerna i lean och den agila traditionen hjälper. Vi identifierar värdeströmmar, och ger linjen förmågan att svärma runt värdeströmmarna och att förändra sig dynamiskt när värdeströmmarna förändrar sig.

Det tar tid för en organisation att sätta sig och börja leverera. Att betrakta organisationer som tillfälliga strider emot det vi vet om människors behov av stabila sociala sammanhang för att kunna arbeta effektivt i team. Det hade kunnat fungera om deltagarna i projekten fått lov att fokusera på ett och samma projekt. Men i den stund vi låter olika personer ingå i olika tillfälliga projektkonstellationer så får inte längre dessa människor ett gemensamt syfte. Och det som driver den mänskliga grupputvecklingen är just samlingen runt det gemensamma syftet.

När vi inför lean och agila metoder försöker vi i görligaste mån undvika omorganisation och disruptiva ändringar i arbetssätt. Man kommer av och till att behöva disruption, men grundläget är att i den befintliga organisationen börja med ständig förbättring och skapa en linje som har förmåga att förändra sig själv. Organisatonsförändring är i lean inget avslutat utan en ständigt pågående process. Man startar resan, men det finns inget slutdatum. Det gör att även om vägvisarens närvaro är tillfällig, så är inte förändringen ett avslutningsbart projekt. Det börjar, och fortsätter, och fortsätter.

Mitt största argument för att projekt är oagila i sig själva gäller synen på planer och genomförande. Även när arbetet verkligen är tillfälligt så att ett projekt borde vara det bästa, så är det många sorters arbete som inte är förutsägbara. Varken mål, tid, eller kostnad kan slås fast på förhand. Vi vet inte exakt vilka aktiviteter som krävs. Vi vet inte vad som kommer att hända. Här brukar projektvänner protestera och mena att det ju visst går att genomföra projekt utan att veta allt detta. Hela tanken med agila projekt är att användas i dessa lägen, säger de.

Problemet är att jag har ännu inte sett en projektmodell som accepterar förutsättningarna att varken mål, tid, eller kostnad kan slås fast. Finns en sådan modell? Använder folk sådana modeller? Får jag komma och titta på och lära mig mer om agila projekt?

Samtliga projektmodeller jag sett, från de etablerade Props och Pejl till olika sorters hemmabyggen, bygger på att man efter en förstudie har en uppsättning aktiviteter som ska utföras i sekvens, i enlighet med en tidplan man tar fram. Jag förstår att man i teorin kan driva projekt agilt, i betydelsen använda samarbetsteknikerna i den agila traditionen inom en tillfällig organisation, och jag har sett det göras, men då har det skett genom kraftiga avsteg från de regler man normalt har om på förhand fastslagen budget och uppföljning på aktivitetsnivå.

Beställare och styrgrupp har ofta upplevt den situationen som oerhört obehaglig. De har inte kunnat få några leveransplaner eller realistiska kostnadsindikationer eller någonting sådant de behöver för att kunna styra projektet. Men styra behöver de, eftersom det agila arbetssättet kräver en ständig omplanering och omprioritering. Men vilka parametrar ska de styra efter?

I en agil linjeorganisation klarar du av ett agilt arbetssätt, för där finns hela tiden en upparbetad struktur som ger dig indikation om leveranskapaciteter och flödeshastigheter. Lärdomarna och insikterna återförs kontinuerligt, samarbetena är upparbetade och vana, larmvillkoren tydliga, processen för att kontinuerligt bryta ner långsiktiga planer till kortsiktiga delmål är på plats och fungerar, och du vet vilka effektmål du hela tiden ska styra efter.

Utan stödet från en agil linje blir det agila arbetssättet oerhört skört. Jag skulle inte våga tillämpa agila arbetssätt i en projektkontext om inte projektet var såpass stort så att det hann etablera alla dessa strukturer innan det var dags att avsluta det. Och när en organisation har tagit den investeringen i strukturerna, varför ska den egentligen riva upp dem? Kan inte strukturerna finnas kvar och fortsätta leverera värde?

Observera att detta inte är en kritik mot projektledare. Själva koordineringsarbetet som projektledare är duktiga på behövs i hög grad inom en agil organisation. De projektledare som är vana vid att detaljstyra individer på timnivå behöver ta ett par steg tillbaks och börja sätta upp mål för team på veckonivå istället, men förmågan att planera och koordinera är ännu viktigare i en agil linje där vi omplanerar och omformar oss regelbundet. Det är de inbyggda strukturella effekterna av projektarbete jag vänder mig emot (utom i specialfallet jag nämnde inledningsvis), och jag hoppas att fler organisationer inser att det finns alternativ som har förmågan att hantera en föränderlig omvärld över tid istället för tillfälligtvis.

Läs mer om vad jag tänkt om projekt.

onsdag 11 november 2015

Övervakning är slöseri

Att övervaka en process är slöseri.

Övervakning är att flytta information. Information kan bara flyttas från en hjärna till en annan, och även i de bästa informationstransporteringsmetoderna försvinner mängder med information i själva flytten. Även värdefull informationsförflyttning lider av spill, eftersom vår förmåga att rätt förstå varandra är så bräcklig.

Att övervaka en process som fungerar är uppenbart slöseri. Det som sker det sker, och att en eller flera människor tittar på höjer inte värdet. Att övervaka en process som inte fungerar är lika mycket slöseri. Att se saker fallera höjer inte heller värdet.

Övervakning kan vara ett nödvändigt slöseri (necessary waste). Om risken att något förbises är 10 %, så sänks risken till 1 % vid dubbelkontroll. Kostnaden för en defekt kan vara så stor att övervakning (sk framfiltrerad kvalitet) är billigare än alternativen just nu. Men det är likväl ett slöseri, och lösningen är att ta bort själva behovet av övervakningen.

John Seddon lanserade begreppen felbehov (eller falskt behov) och värdebehov ("failure demand" och "value demand"). Ett felbehov är behov av att vi gör något på grund av att något blivit fel. Att behöva torka upp en massa spilld färg för att vi varit oförsiktiga när vi målade om till exempel, eller att behöva gå efter med en pensel för att fylla i allt det vi missade första gången. Det ser ut som värdeskapande eftersom vi sänker värdet om vi inte gör det, men det är i grunden ett onödigt jobb om vi hade kunnat göra det rätt första gången.

Övervakning är failure demand. Vi behöver den bara om vi inte kan lita på en process. Men vad säger att vi kan lita på övervakningen? Om processer behöver övervakas och övervakning är en process, vilka ska då övervaka övervakarna? Och om övervakningen är en mer felfri process än den övervakade processen, hur kom det sig? Kan vi använda samma tekniker för att felsäkra den övervakade processen till att börja med?

Övervakning har alltid en kostnad. Förutom kostnaden för själva övervakningen i tid och material så kostar det i uteblivna möjligheter. Vi kan ju använda tiden till något annat. Men dessutom för övervakningen med sig en massa systemkostnader. Nyckeltal riskerar att missförstås och driva felaktiga beteenden. Vi bygger bort tilliten. Övervakningen ger en falsk känsla av säkerhet.

Den enligt mig värsta systemeffekten är denna: om arbetsprocessen är fastlåst i en överbyggnad som övervakar alla dess delar så blir arbetsprocessen väldigt svår att förändra lokalt på den nivå där man tydligast ser bristerna. Övervakningen gör det alltså svårare att undvika defekter och avvikelser. Gör det väldigt svårt att arbeta med ständig förbättring.

Vad är alternativen till övervakning? Arbeta med inbyggd kvalitet istället för framfiltrerad. Arbeta med att felsäkra processen, alltså att göra det svårt att göra fel. Att istället för generell övervakning låta människor närmast felkällorna hålla ordning på ett fåtal viktiga larmindikationer och ha en överenskommen process för hur man reagerar på avvikelserna. Använd naturliga och smidiga informationsspridare istället för krav på rapportering.

Här vilar ansvaret på er som beslutar om arbetssätt och processer och verktyg. Känner ni till den samlade effekten av kontrollsystemen? Kan ni minimera behovet av informationsförflyttning genom att använda spridare? Har ni en handlingsplan i era ledningssystem för hur ni ska agera på varenda en av datapunkterna? Kan ni delegera ansvar närmare golvet för att göra återkopplingslooparna kortare och slippa agera själva? Det finns metoder för att ta sig ur den här situationen. Övervakning är hursomhelst slöseri och väldigt sällan svaret.

Läs gärna också denna lilla artikel om byråkrati versus professionalism i ideella organisationer. Det mesta i artikeln är tillämplig på alla organisationer.

måndag 9 november 2015

ALMA: Two levels of governance

Condition

When you want to govern a service, or a group of services, through the life cycle, but you don't want to be overburdened by bureaucracy.

Solution

Put together a central cross functional service management team. This team should be broad enough to have all relevant competences and perspectives to answer all questions about what is the most meaningful to happen with the service.

The service management team doesn't need to have the competence to actually realize it. For that you put together service maintenance teams (for instance service desks, service development teams or service operation teams, or combinations thereof). The maintenance teams should have all needed competences to realize what the management team prioritize. In order to avoid handovers, and to keep a broad and deep knowledge level in the management team, representatives from the maintenance teams must be parts of the service management team.

Description

While the identification of several roles and different groups in life cycle management frameworks such as ITIL or PM3 is important, it is also observed that this can lead to unnecessary organizational complexity.

There are basically four responsibilities when taking care of a service: managing capacity/capabilities and changes thereof, and when things go wrong: managing the incidents and solving the underlying problems. Instead of appointing different managers for these processes you can put together a single management team (of maximum 9-10 persons ideally) that is capable of making all decisions regarding resource allocation, policies, and prioritization. Then let the team sort out how they distribute responsibility among themselves, or if they should delegate some of it to others.

The management team should work closely with the maintenance teams, having representatives present when the maintenance team plans and follow up on their own activity, and having representatives from the maintenance teams in the management team. In order to keep it agile we must minimize handovers, align the mandates with the abilities, and always make our decisions based on empirical evidence and deep understanding of what is happening on the floor, close to the customer. Both the management team and the maintenance teams are regarded as governance teams that collaborate in governing the services.

All common agile principles about transparency and self-organization apply here.

The management team should maintain the vision and the plan. The plan should be continuously updated with correct data about velocities so that forecasts, if you need them, are kept accurate. Experience has shown that this can be accomplished if the management team meets regularily 1-4 times a month.

History

Groups like the management group are prescribed in a lot of frameworks. What we've done in order to keep it agile is basically to merge all these groups into one. The idea of assigning responsibilities and accountability to a group, and then let the group sort out how they distribute the responsibility, is a common organizational pattern in team focused lean and agile. Having mutual representation between two groups is used in sociocracy, a governance system based on self organization. Emphasis on cross-functionality of the teams in order to reduce handovers and improve lead time is a common Scrum construct.