Continuous investment – Agil HR i praktiken

Finns nu i bokform på Leanpub

“Software developers…principal work is human communication to organize the users’ expressions of needs into formal procedure” Tom DeMarco, Peopleware

Detta är den första posten i en serie om agil HR “from the trenches”.

Del 1: Continuous investment
Del 2: Lägg ner utvecklingssamtalen
Del 3: Lön är rättvis ersättning – inte belöning
Del 4: Släng titlarna
Del 5: Ny kunskap – ett gemensamt ansvar, avsnitt 1
Del 6: Hitta rätt folk – släpp dem lös
Del 7: Kontor – låt teamen bestämma
Del 8: Tidredovisning – och andra onödiga system
Del 9: Bortom agile – unmanagement

Continuous investment

Våren 2011 slutade jag med utvecklingssamtal. Jag var då utvecklingschef på ett produktföretag och hade som alla andra chefer i Sverige (och den anglosaxiska världen) ett årligt återkommande samtal med var och en av mina medarbetare där jag – det ingår ju i själva grundidén om utvecklingssamtal – skulle hjälpa dem att utveckla sig i sitt arbete.

Min tanke var att göra som jag så ofta gjort när det handlar om (agil) organisationsförändring: gör ett experiment, mer eller mindre i det tysta, och se hur det går. Nu är just utvecklingssamtal lite svåra att lägga ner i det tysta, och då inte bara för att jag pratade om det på Agila Sverige det året – det var ju inte ett så diskret sätt att göra det på – och inte heller för att det ju blir uppenbart för de som blir av med den enda chansen på året att utvecklas (ironi), men framförallt eftersom det just är en av de ganska få väldefinierade processer som företag normal har. För att lägga ner utvecklingssamtal måste man (oftast) prata åtminstone med HR (och antagligen med ledningsgruppen, så var det i varje fall i mitt fall).

När jag gjorde detta var vi väldigt långt in i en agil transformation. På många sätt hade vi redan tagit någon sorts standard-agile så långt vi kunde komma. Men under flera år av ganska radikala experiment med hur vi organiserade oss hade (faktiskt) det som kallas HR varit lite, till nästan inte alls, involverade i detta. På sätt och vis är det konstigt. Hur kan man i grunden förändra en organisation utan att den del av företaget som är till för att ta hand om och stödja personalen praktiskt och strategiskt är djup involverad?

Jag tror det finns flera svar på den frågan, men en viktig aspekt är att en agil organisation är så fokuserad på själva leveransen, att andra aspekter av organisationen och verksamheten kommer lite i skymundan. Även om det inte är fullt uttalat, handlar exempelvis agila manifestet i första hand om just “delivery”, som man kanske kan sammanfatta i följande slogan: “Together with the customer we are a bunch of people who create working software by interacting and collaborating and thereby are open to change”. I Scrum är det ännu tydligare fokuserat på just det vi med ett begrepp lånat från Lean kunde kalla “värdeströmmen”. Produktägaren står för kundvärdet, “varför” och “vad”, och korsfunktionella och självorganiserande team står för själva leveransen, “hur”.

Det finns en enorm kraft i det här sättet att arbeta. Inte längre är det en linjechef som leder och fördelar arbetet, eller en projektledare som styr över andras bidrag till projektet, i stället tar de som utför arbetet makten över vad som ska göras genom en kombination av fokus på kundvärde (ingen annan behöver tolka kundens behov) och att de tillsammans besitter all kompetens som behövs för att just skapa något som ger värde åt kunden (ingen extern koordinering behövs) och i en takt som de också själva har kontroll över (ingen annan gör tidplaner).

Men vad innebär det i förlängningen att det är självorganiserande team som blir motorn i ett företag eller en organisation? Vad blir chefens roll? Vilken blir HR:s roll? Vad händer med alla processer som vanligen är inriktade på individen och inte teamet (så som löner, utvecklingssamtal, rekrytering och kompetensutveckling, för att nämna några viktiga)?

På många sätt har dessa aspekter varit frånvarande i den agila litteraturen (eller diskursen kanske man lite högtidligt kan kalla den). Ofta – är min känsla – låter man de mer traditionella sätten att se på dessa frågor leva kvar sida vid sida med det nya sättet att leverera. Det skaver en del, men eftersom det inte finns några färdiga svar på hur det annars skulle se ut kan man nästan inte se problemen. Det är som dubbeltydiga bilder. Ibland måste man veta att det finns ett annat mönster i bilden, eller vrida på den, för ett se den andra dimensionen.


http://www.levandehistoria.se/files/Hur%20man%20ser%20saker%20p%C3%A5%20olika%20s%C3%A4tt.pdf

I en spännande artikel om hur Spotify organiserat sin utveckling i något som liknar en matris synliggör Henrik Kniberg och Anders Ivarsson en viktig dimension vid sidan av leverans: att upprätthålla själva kapaciteten att leverera. Vad menas med det?

Låt oss ta en väg som metafor. För de flesta människor är vägen ett medel för att ta sig fram till ett mål. Om man samtidigt som man strävar mellan punkt A och B måste skapa och underhålla också vägen dit kommer det förstås bli mer besvärligt att ta sig fram. Därför är det lönsamt att ha människor som ägnar sig åt att bygga vägen. På samma sätt är det ofta i organisationer. Vi har roller som mer eller mindre på heltid ägnar sig åt själva organiserandet i stället för leveransen. De asfalterar vägen som de som levererar åker på.

I traditionella industriföretag handlade och handlar detta i första hand om investering i maskiner (nya och underhåll), därmed inte sagt att personalen inte är viktig, bara att kapitalet till övervägande delen består av döda ting (som du kan äga). Men i många kunskapsbaserade företag (och ännu viktigare i dag, i innovationsbaserade företag) är maskinerna en marginell del av verksamheten, i stället är personalen (som du inte kan äga) kapitalet.

Att investera i något man äger är hyggligt säkert, att investera i något som mer eller mindre över en natt kan försvinna är belagt med betydligt högre risk. Eftersom du måste investera (asfaltera) i din organisation (alltså i de som arbetar där) är det också bäst att du ser till att de trivs att vara på arbetsplatsen. Kvar vid sidan av leveransdimensionen finns således det som förr kallades personalfrågor, i dag HR.

Egentligen kan man antagligen tala om flera dimensioner, och jag känner till företag som medvetet arbetat med att skapa en mångdimensionell matrisorganisation utifrån agila principer, där varje dimension i matrisen är en egen process. Vad är det egentligen som säger att till exempel linjechefen måste ta ansvar för saker som kompetensutveckling, individuell coaching, verktyg eller robusta system? Kanske kan de vara självständiga processer eller tjänster med utspritt ägandeskap?

När jag själv mer seriöst började att operativt införa en agil organisering av produktutveckling framstod just matrismodellen som en vettig formel att begripa organisationen utifrån. I stället för att vara uppdelade efter olika arkitekturkomponenter i produkten (expertområden) ville vi ändra fokus till att kunna leverera ett knippe kundtillvänd funktionalitet . Det innebar att varje team behövde innehålla all kompetens som krävdes för att leverera en komplett feature. Å andra sidan ville vi inte att den unika expertkompetensen skulle försvinna. Därför fick de mest seniora inom de olika lagren i uppgift att hålla ihop ett slags virtuellt experteam inom varje lager. Vid sidan av leveransdimensionen fick vi således en sorts kompetensdimension.

Som man kan se från denna nu (2012) fem år gamla bild var det fortfarande en organisation som lyfte fram individuellt ansvar. Team leddes av någon, vare sig de var leverans- eller kompetensteam. Med tiden ändrades detta. Ju mer leveransteamen arbetade tillsammmans, desto mindre blev behovet både av att ha utpekade individer i teamen som agerade ledare och atti ha utpekade personer som ansvarade för olika aspekter av produkten.

Vi var i och för sig ganska lyckligt lottade. Vi blev aldrig fler än 20 personer. Vi arbetade i en homogen kodbas. Alla programmerare kunde täcka hela kedjan från idé, arkitektur, design, implementaion, test, verifikation och leverans. Faktum är att alla dessa aktiviteter ganska snart smälte samman till något vi bara benämnde programmering; ungefär som man i hantverk inte skiljer på den som designar något och den som tillverkar det, eftersom det är samma sak.

Men att domän- eller kompetensdimensionen inte längre blev så viktig hos oss innebar ju inte att de andra dimensionerna av organisationen försvann, så som personalutveckling, lönesättning eller kompetensutveckling. Med tiden blev emellertid något av ett dilemma synlig: den agila verktygslådan hade gett oss stor hjälp i att förändra vårt sätt att leverera, men de där andra aspekterna av att arbeta i ett företag hade inte ändrats särskilt mycket.

Men, ju mer vi betonade de agila värdena, ju viktigare teamens och medarbetarnas autonomi blev, desto större glapp blev det mellan det nya sättet att arbeta och våra gamla processer. Medarbetarna förväntades ta (nästan) allt ansvar för vår relation till kunderna, men de förväntades inte att kunna sköta sina egna mål eller kompetensutveckling. I vår leveransprocess sa vi en sak (agile), men i våra personalprocesser gjorde vi en annan sak (kontroll).

Till slut blev det hög tid att verkligen på allvar ta effekterna av den självorganisering som är så viktig i agile. Kunde vi låta de agila värderna ockå vara vägledande i våra andra personalprocesser? Kunde synen på utveckling, löner, anställning och kompetensutveckling också präglas av värden som dessa:

  • Teamen tar gemensamt ansvar
  • Människor drivs av inre motivation
  • Vi vill hela tiden förstå effekterna av det vi gör genom korta feebackloopar
  • Vi gör bara saker när de ger ett värde och vid behov (pull)
  • Kontinuerligt försöker vi förbättra sättet vi arbetar på
  • Det är i första hand systemet som påverkar utkomsten av vårt sätt att arbeta, inte individen

Med hjälp av agila principer och verktyg (och en hel gnutta lean) lyckas vi ofta skapa något vi brukar benämna “continuous delivery”: sprint efter sprint förmår vi leverera användbara saker (ibland pratar vi också om “continuous discovery”, men jag ser det som en del av leveransprocessen). Om det jag skildrat ovan är korrekt behövs det emellertid ytterligare en dimension som också äger rum hela tiden. Låt oss kalla den för “continuous investment”: vår förmåga att kontinuerligt arbeta med och förbättra kapaciteten att leverera.

I några följande bloggposter kommer jag berätta om lite olika upplägg och experiment vi utförde för att också göra denna dimension lite mer agil.

Läs mer

Calle Blomberg har skapat bloggen agilhr.se. Här finns tonvis med bra pekare och bloginlägg om kombinationen agilt och HR.

Själv har mycket att mitt skrivande de senaste åren cirkulerat runt managementaspekten av agile. Se särskilt Lägg ner utvecklingssamtalen och Till min efterträdare

Anders Laestadius på Crisp har skrivit intressant om Happiness metrics och löner.

11 responses on “Continuous investment – Agil HR i praktiken

  1. Jag gillart Peter. För mig som hållit på mycket med Scrum ser jag just det ramverket som ett sätt att bygga två saker samtidigt: dels en produkt, dels organisationens förmåga. Det betyder inte att man inte kan knycka och låna sig fram till många förbättringar, men att om man förväntar sig att en metod ska lösa alla ens problem, då blir man snabbt besviken. Installera lärande! Lärande = ny kunskap + nytt beteende.

  2. Tobias, jag både håller med och är lite emot 😉 Ju mer jag arbetar med Scrum desto mer förstår man magin i detta enkla verktyg. Så många aspekter som de rollerna, mötena och artifakterna faktiskt hjälper till att få på plats.

    Dock: ur leveranspersektiv “tvingas” man in i ett bra beteende, men på samma sätt är det inte med organisationens förmåga. Självorganiserande team är disruptiva, och coaching (SM) kan ses ur capability-perspektivet, men linjeaspekterna saknas helt. Som jag skrivit om tidigare förtvinar linjeansvaret allt mer när de självorganiserande teamen blir kärnan i verksamheten. Trots det är management eller som jag valde att kalla det, “continuous investment”, lite av ett vitt territorium inom Scrum (och Agile).

  3. Väldigt intressant artikel. De värden du nämner, så som att teamen tar gemensamt ansvar etc. tror jag inte bara är främjande för produktiviteten men även för kreativiteten. Dock så är jag inte av uppfattningen att användare av lean och agila principer ofta har nått till Continuous Delivery, det är otroligt få som idag nått dit enligt min erfarenhet. Man bör vara försiktig med att generalisera termen Continous Delivery (CD) överlag. CD syftar till att ha en helt automatiserad leveranspipeline, där varje förändring i systemet byggs, testas, deployas till testmiljöer etc ända till produktion, helt automatiserat. Det ska egentligen bara finnas ett enda manuellt steg i kedjan, vilket är en knapp för att kunna godkänna att en förändring skickas ut i produktion. Det är för luddigt att säga att CD innebär att det finns nya features tillgängliga efter en sprint.

  4. Tommy, jag håller med dig, det är möjligen lite slarvig att använda Continuous Delivery på detta sätt. Tycker väl iofs att CD är förmågan att utan stopp leverera slutprodukten i just din värdekedja; om det är en produkt är CD en release, om det är en tjänst så är det skarp deployment, jag brukar kalla det Continuous Deployment för att specificera närmare.

  5. Hej Peter!

    Jag gillar som vanligt det du skriver. Gillar framför allt din ambitiösa ansats. Sex delar utlovade redan i del 1 hade jag aldrig vågat. Har du för mycket tid? 🙂

    Undrar lite vad som skiljer “Continuous investment” från “Continuous improvement”? Du verkar definiera det som “förbättra kapaciteten att leverera”, vilket låter synonymt. Samma sak?

    Håller med Tommy att du missbrukar CD lite grann, men det är en mindre sak.

    Det som kanske är mest kontroversiellt i din post är dina sex punkter som du kallar “agila värderingar”. Alla är bra saker, men kanske bara två av dem är _egentligen_ att kalla agila (nr 3 och 5). Övriga kommer från Lean, systemtänkande, grupp- och motivationspsykologi. Relaterade ämnen, men inte samma sak. Många tror att team är inbyggt i agila metoder, men det stämmer inte. Mer leaninspirerade, agila arbetssätt tonar ofta ner behovet av team.

    En reflektion som jag gör är att man hade kunnat titta åt samma håll och hitta _andra_ punkter som är minst lika relevanta för HR, kanske mer. Exempel kan vara “Respekt för människor”, “Enkelhet är essentiellt”, “Skapa värde för din kund”, “Eliminera slöseri” osv osv. Vad får dig att tro att det är just dessa punkter som är mest relevanta eller värdefulla för HR idag?

    Ser fram emot kommande delar!

    1. Hej Joakim,
      tack för din skarpa feedback.

      Först tänkte jag skriva allt jag planerat innan publicering, men sedan kom de agila värdena (SIC!) i kapp mig och jag bestämde mig för release early, release often (OSS också) och publicerade första delen. Risken är ju förstås att allt inte helt hänger ihop från början och möjligtvis har jag slarvat lite med vad “agila värden” egentligen står för. Strikt sett skriver jag inte att min punktlista är just agila värden, men det ligger nära till hans att tolka att jag menar att de är viktiga i en organisation präglad av agila värderingar (vilket jag tycker). Jag ska se över mina syftningar och fundera en sväng på vad som verkligen är värden (agile, scrum, xp, lean och dyligt – det är så lätt att slarva och säga värden om principer och praktiker).

      Jag tycker inte heller att jag säger att dess är de enda eller viktigaste värden inom en organisation inspirerad av agila idéer. Visst är de du nämner också viktiga (och kanske i någon mån viktigare). Just punkterna i inlägget är från mitt föredrag om utvecklingssamtal och laddar så att säga för nästa inlägg 😉 Point taken.

      Hur brett agile går och bör användas kan alltid diskuteras. Kan man säga att de finns värden och principer bakom agile som kan kallas agila? Kan man säga att värden och principer som inte finns uttryckta i agila manifester men i olika agila metoder är agile? Kan man därmed bredda agile utan att den förlorar mening? Ja, på alla dessa frågor tror jag man kan svara. Vad tror/tycker du?

      Så till några sakfrågor:
      1. I kontinuerlig förbättring ingår t.ex. borttagning av slöserier, jag ser inte detta som investeringar. Att betona investering handlar om att odla/bygga kapital. Men – jag provar hur termen flyger. Vi får se.
      2. Jag anser att en kärna i agile/scrum/lean är kontinuerlig och uthållig leverans av kundvärde end-to-end. Hur denna end-to-end ser ut varierar. Continuous Delivery är därför en del av agile, som många misslyckas med.
      3. Jag är helt öppen för att kalla en organisation som inte betonar team (t.ex. kanban- eller OSS-inspirerad) agil, men jag tycker nog ändå manifester betonar team väldigt mycket, som i “The best architectures, requirements, and designs emerge from self-organizing teams”. En mening så djup av filosofiska, vetenskapliga och empiriska insikter, kunskaper och förutsägelser.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.