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.

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.

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.

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.

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.