Många organisationer utmanas idag att tänka “Allt eller inget”. Ramverk som SAFe menar att PI-planering är det som är bäst för att hantera beroenden. Men, hur hanterar vi alla de fall där det saknas beroenden till andra? Och, kan detta leda till att man väljer att INTE alls hantera sina beroenden? Jag ska här nedan försöka reda ut begreppen, och förhoppningsvis ge dig några alternativ – som kan passa er organisation bättre.
När används PI-planering och vad vill man åstadkomma med det?
Under en PI – Planering så pratar man om det som ska göras så att alla har samma bild, tydliggör guidelines att arbeta efter, reder ut beroenden till varandra, funderar i vilken ordning saker bör göras för att få ihop en helhet så smidigt som möjligt o s v. Detta är förstås jättebra eftersom det förenklar, MEN – det viktigaste man kan göra är att sluta hålla kvar i en organisation som består till största delen av komponentteam där det inte är möjligt att ha en helhetsbild.
Vanligt är att team som inte har beroenden, undrar varför de ska lägga värdefull tid på att delta på en PI – planering istället för att jobba. De som har beroenden får en PI-planering istället för att deras problem löses långsiktigt. Inga är nöjda! Det var helt säkert inte så att PI-planering var tänkt att bidra till ett permanent tillstånd av onödiga beroenden och låg processeffektivitet. Snarare ett sätt att hantera nuläget medan man arbetar bort beroenden.
Bild från Ivar Jacobson International som visar ett vanligt sätt att visualisera beroenden mellan team
Många och onödiga överlämningar skadar effektiviteten och skapar stress
Jag tror att flera organisationer glömmer bort vikten av att ha rätt sorts team uppsatta i organisationen. Beroende på hur team sätts upp sker inga, tiotals eller hundratals överlämningar. När en massa överlämningar sker, kan processeffektiviteten bli så låg som runt 10% i många fall. Själva arbetstiden kan vara 5 månader, medan väntetiden är 3 år och 3 månader. Det här är tyvärr inte ett undantag i organisationer idag, utan en realitet.
Att få möjlighet att göra klart saker istället för att starta upp en massa saker och aldrig få avsluta dem, men samtidigt tvingas hålla allt i huvudet skapar förutom ineffektivitet, stress hos de anställda. Sedan kan det dessutom vara lätt att skylla på de anställda att de inte är tillräckligt stresståliga, när det är systemet som är felaktigt uppsatt.
Skillnader mellan olika teamkonstellationer
Jag nämnde tidigare komponentteam. De har och kan inte ha helhetsansvar för kundupplevelsen mellan system och plattformar, utan de levererar funktioner på uppdrag av andra team. Det här skapar ofta en massa beroenden team emellan, många olika beställningar, från många olika produktägare, och dessutom har ett komponentteam svårt att se helheten av produkten eftersom de endast är delaktiga i delarna.
När en organisation består av många komponentteam är det lätt att ta till PI-planering som verktyg och fokusera på hur en PI – planering går till, istället för att se till att bygga bort beroenden. Organisationer med många komponentteam hamnar ofta i att de blir en sk. “Feature Factory” (som producerar produkter som kanske behövs, men ingen vet) istället för att säkerställa att det man levererar uppfyller ett behov kunden har.
Ett produktteam har helhetsansvaret för produkten, att alla delar i produkten hänger ihop, fungerar. Produktteamen kan även ha ansvar för försäljningen av produkten. Visst kan även de få beställningar från andra team, men det är mycket mer sällsynt än för ett komponentteam. Här sitter tex. både frontend och backend tillsammans i samma team för att ha möjlighet att ta helhetsansvar för produkten.
Ett produktteam har EN produktägare vilket gör det enklare med prioriteringar. Det som är bra när det gäller produktteam är att man kan lägga affärsansvar på det teamet och tex skapa strategiska teman för det man vill åstadkomma, och sedan kan teamet sköta resten själva. Detta är ett bra sätt att komma ifrån att vara en Feature Factory och att istället öka kund- och affärsvärdet.
Serviceteam har som fokus att öka förmågan hos övriga team. Deras uppdrag är ofta att möjliggöra detta genom självservice, mentorera, utbilda osv. Ofta vill man att andra team inte ska behöva dem i framtiden, även om det också kan finnas bestående serviceteam inom vissa delar i vissa organisationer.
Kundreseteam levererar på strategiska mål kopplat till kundresan. Deras fokus är ofta att öka antalet aktiva kunder, konverteringsoptimering, öka användandet av någonting (tex att använda webbplatsen istället för att ringa) och även att se till att kunder känner igen sig oavsett vilken digital produkt de använder. De ansvarar för själva kundupplevelsen som helhet, i bland i digitala kanaler, ibland även i de analoga.
Ett plattformsteam levererar funktionalitet i den tekniska plattformen för att stödja de andra teamens behov. De bygger förmågor för andra team, men kan även ha egna produkter. Det kan t ex röra sig om designsystem, initiera verktyg, ramverk, skapa pipelines eller andra saker som gör det enklare för andra team. Det handlar ofta om sådant andra team behöver använda, men som kräver unik teknisk kunskap som inte alla nödvändigt behöver ha.
Utmaningen för dessa team kan många gånger vara att de andra teamen ska acceptera och förstå tekniken de levererar. Produktägaren är ofta en teknisk person och det finns en risk när teamet bestämmer vad de tror att andra behöver om inte ledningsstrukturerna är tydliga, man har inte tagit in användarnas perspektiv och behov eller inte heller landat i hur teamen ska arbeta (kundcentrerat).
Så, vilken struktur passar vår organisation bäst?
Att förstå vad just din organisation behöver är grunden för att bygga bort beroenden, minska överlämningar, köbildning av arbete, task-switching, variationer i tex arbetsmängd, flaskhalsar och annat. Många organisationer behöver bygga upp en välfungerande produktstyrd organisation idag, men det är omöjligt om man inte förstår vilka behov man ska tillgodose åt kunden.
Många utgår inte från kunder och rätt produkter utan utgår istället från arkitektur, sätt att arbeta på eller den organisationsstruktur man har idag. Och det fungerar sällan, i princip aldrig. Grunden är alltid kundens behov och rätt produkter för kunden. Sedan kan man titta på vilken arkitektur man behöver för att leverera dessa tjänster och produkter och skapa arbetssätt som möjliggör löpande leveranser av kund och affärsvärde. För att sedan organisera och styra utifrån vilka som behöver samarbeta för att skapa värde för era kunder. Inte tvärtom!
Det verkliga värdet ligger i att minimera beroenden
PI-planering bör absolut finnas kvar om det inte finns beroenden som kan arbetas bort. Men börja med att hantera beroenden först. Arbeta bort dem i så stor utsträckning ni kan och leta nya angreppssätt på det här allt eftersom. Det går att göra mycket, jag lovar! Men förvänta dig ingen högre processeffektivitet av en PI-planering, den är bara till för att försöka förhindra att beroenden upptäcks för sent och att alla ska ha samma bild av saker. Det verkliga värdet uppstår när ni arbetar bort beroenden. Det är då ni kommer öka processeffektiviteten till oanade siffror.
Stort tack till Mia Kolmodin för grafik.
