För en sann agilist är drömmen alltid att glömma allt vad projekt och ”vattenfall” heter, helst även helt ignorera alla företagshierarkier med kontrollerande chefer, styltiga budgetprocesser, treårsplaner och internpolitik. Men i verkligheten kommer man inte undan allt detta. I den stora vida verkligheten är fortfarande agilt tankesätt en marginalföreteelse som ”dom där på IT verkar gilla”. Hur övertygad man än är av förträffligheten i Scrum och agila metoder så behöver man förhålla sig till den större företagsvärlden. Och där pratar man projekt. Det finns utvecklingsbudgetar, lönsamhetskrav, strategiska planer och man styr fördelningen av resurser till nya initiativ med hjälp av projekt. Går det kombinera projektstyrning med agila team? Kombinera projektbudget med flexibelt scope? Projektledare med Produktägare? Projekt med produkt? Absolut!

Alla organisationer kommer med sina unika förutsättningar, så hur bra och på vilket sätt man kan kombinera agilt och projekt kommer att variera. Om man vill ha mer djupgående kunskap i ämnet så rekommenderar vi vår kurs ”Att kombinera agilt och projekt”. Men här i denna text försöker vi ge tips kring vissa utmaningar när man vill jobba agilt inom projekt.

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Erbjudande!
Pris: 11 000 SEK  8 800 kr (20% rabatt)
Datum: 11 okt 2023, 5 dec 2023

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Erbjudande!
Pris: 11 000 SEK  8 800 kr (20% rabatt)
Datum: 11 okt 2023, 5 dec 2023

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Erbjudande!
Pris: 11 000 SEK  8 800 kr (20% rabatt)
Datum: 11 okt 2023, 5 dec 2023

Rollen agil Produktägare (PO) ska enligt den agila metodiken representera sina intressenters och slutkunders intressen och prioriteringar i det agila teamet. Han/hon är ansvarig för att säkerställa att teamet jobbar med rätt saker och att maximera värdet för verksamhet och kunder. Detta inom ramen för sin produkt, kan vara värt att tillägga. Det skulle kunna bli hur bra som helst förutsatt att Produktägaren har mandat för sin produkt och att alla runt omkring förstår och respekterar det agila förhållningssättet, men så är det ju inte i många organisationer. Ibland befinner sig det agila teamet i en egen liten bubbla där produktion, ekonomi, marknad, sälj, ledning m.m. fortfarande jobbar traditionellt och enligt gamla strukturer. Hur kan man som Produktägare förhålla sig till det?

Om verksamheten inte är agil – hur agerar vi då?

Dialogen, kontaktytor och förväntningar mellan det agila teamet och övriga delar i verksamheten kan många gånger vara otydlig, och som en följd av det börjar det skava. Stakeholders som inte förstår vad produktägaren har för roll, projektledare som kräver datum och aktivitetsplaner eller frustrerade initiativtagare som avbryter teamet med nya idéer och förväntar sig att de blir utförda. Det kan såklart kännas motigt emellanåt men ett par tips är:

• Välj att vara positiv och entusiastisk! Din attityd kommer med stor sannolikhet att smitta av sig.
• Identifiera vilka som är med på tåget och som du kan kroka arm med. Lägg merparten av din energi på dem som hjälper er framåt och inte på undantagen som inte är intresserade (än). De hoppar kanske på vid nästa station?
• Agilt har inget egensyfte. Det finns stora fördelar för verksamheten att vinna och som kan visas på, t.ex. mer förutsägbara leveranser eller ökad transparens.
• Finns det några lågt hängande frukter att leverera för att visa på fördelar med det agila arbetssättet?
• Etablera iterativa och regelbundna mötesforum med dina stakeholders för att få in dem i samma kadens, t.ex. demos och refinement.
• Var tydlig och transparent. Se till att kunna motivera dina prioriteringar mot tydlig produktvision och affärsresultat.
• Erkänn och lär av dina misstag. Detta skapar tillit både till dig som person och till din roll.

Om ledningen inte är agil – hur agerar vi då?

Det är vanligt att ledningen fattar beslutet om att en organisation ska bli agil. Det är inte lika vanligt att det beslutet på ett tydligt sätt förankras genom hela organisationen, tillsammans med svaret på varför och vilka effekter som vi önskar uppnå efter en agil transformation. Vad innebär det beslutet i praktiken? Vad vill vi ska bli bättre? Varför gör vi detta? Många gånger ser vi att ledningen fortsätter göra uppföljningar på samma sätt som tidigare, vill ha samma kontroll samt har utmaningar i att delegera ansvar. Vad kan vi göra då?

• Fortsätter det komma detaljerade krav och direktiv från ledningen – våga utmana dem! Kom med förslag på alternativa lösningar. Kanske i form av delleveranser för snabbare feedback?
• Ta, tillsammans med ditt team, ansvar för roadmap och vision. Visa ledningen att de kan lita på att ni som team kan ta ett helhetsansvar för er produkt.
• Som Produktägare är du säljare för din produkt – sälj in den i organisationen.
• Har du teammedlemmar som ingår i flera team, eller är utspridda av andra anledningar, uppmärksamma vikten av beständiga team och visa på att context switching ger minskad effektivitet och produktivitet.
• Visualisera pågående arbete/WIP. Är du i en organisation där allt är prioriterat och det ständigt startas upp nya initiativ? Visa på att det inte kan aktiveras mer arbete samtidigt än vad det finns kapacitet för och att för många samtida pågående initiativ också ger ett resultat av minskad produktivitet.
• Uppmuntra ledningen till att lära sig mer om agila metoder, vad det innebär i förhållande till ansvar samt vilka krav det ställer på ledarskapet.

Agil transformation – hur gör vi det?

Resan att ställa om från traditionellt till agilt är inte en lång raksträcka. Det är ett arbete som kräver stor förändring på flera nivåer – det tar tid. Agila arbetssätt är inte för alla organisationer. Det finns heller inget som säger att det måste vara antingen eller, vissa organisationer har hybridlösningar. Ett par tips är:

• Budskapet kring varför och vad man vill uppnå med en agil transformation bör vara förankrat genom organisationen för att ge förutsättningar till en gemensam förflyttning.
• Inför agila team genom projekt. Genomför implementationen av en ny tjänst först och låt sedan teamet finnas kvar och fortsätta med inkrementella förbättringar.
• Ha ödmjukhet inför att det tar tid att ställa om! Här kan du även läsa om tips för snabb förändring.

Vi hjälper dig gärna!

Produktägarens kompetenser

En av de första frågor vi på Onbird ställer när vi ska hjälpa en organisation i en agil förändringsresa är ”Och hur ser produktägarrollen ut hos er?”. Svarets art brukar vara ganska talande för hur arbetet ska börja. Ofta är det dessutom en av underliggande anledningar till att vi över huvud taget är där.

Typiska svar på frågan brukar vara något i stil med följande:

• ”Produktägaren är den som ska se till att IT utför det som verksamheten beställer.”
• ”Produktägare? De ser till att tidrapporterna går till rätt projekt och att IT följer projektplan och budget.”
• ”Produktägaren har full koll på sin produkt och sitt team. Däremot är det inte alla i organisationen som respekterar sprintarna.”
• ”Våra produktägare är ansvariga för systemen och så svarar de mot projektledaren för respektive projekt.”
• ”Vi har en produktägare för verksamheten och en för tekniken, det är bättre att man får ansvara för en grej bara..”

Sammanfattningsvis: det är ofta tydligt att rollen inte är solklar. Dessutom skiljer sig svaren och definitionerna ibland åt beroende på vilken del av organisationen vi frågar. Summa summarum, behöver vi helt enkelt bli tydligare i vad rollen innebär och vilka produktägarens kompetenser behöver vara. Fortsätt läsa för att nå ”Produktägarens 7 budord”, som sammanfattar både produktägarens kompetenser och inom vilka områden hen ska verka.

Crowdsourcade budord

Produktägarforumet som nämns ovan har hjälpt till sina deltagare i det dagliga och gjort rollen lite bättre. Dessutom sammanställdes för några år sedan världens första (tror vi) crowdsourcade checklista för produktägare i just detta PO-forum!

Det är i denna crowdsourcade checklista vi finner våra budord. Dessa är ett resultat av en hel drös produktägare från många olika branscher och organisationer, som tillsammans stött och blött innehållet. Det som tagit mest tid är troligtvis att minska mängden ord, för att göra den enkel och snabbläst. Sammantaget blir det en listning över de kompetenser och drivkrafter produktägaren bör ha.

Innehållet

Checklistan består av dels en generell definition och dels sju fördjupningar på detaljnivå.

Den generella definitionen lyder som följer.

”Som produktägare är jag ansvarig för att maximera utkomsten från min produkt. Jag säkerställer detta genom att ständigt underhålla och prioritera mitt primära verktyg: produktbackloggen.”

Denna ”trossats” (eller vad det ska kallas) ger oss mycket foder för diskussion och inlärning om vi bara kikar lite närmare på den. Exempelvis nämner vi ordet ”utkomsten”. Här åsyftas alltså att det man levererar inte är det viktiga utan den effekt som uppstår av leveransen. För att uppnå detta krävs förstås att produktägaren har koll på både intressenter, användning, kommunikation och affärsmodeller. Och vad syftar ”mitt primära verktyg: produktbackloggen” på? Är en produktbackloggen verkligen ett verktyg?

Om du vill fortsätta djupdyka i ovanstående, tveka inte att höra av dig, så kan vi räta ut frågetecken över en kopp kaffe!

Produktägarens 7 budord (nåja – områden i alla fall)

Det finns många olika aspekter som en produktägare behöver ha i åtanke i sitt arbete med en produkt. Dels ska hen förstås veta hur produkten levererar värde till sina kunder just nu. Men det ingår också att skapa möjlighet att snabbt kunna leverera värde även i framtiden. I diskussionerna som föranledde detta dokument blev det tydligt att områden skiljer sig åt i viktighet och lättillgänglighet mellan olika organisationer. Detta gäller både produktägarens önskade kompetenser och faktiska mandat. I konklusion sammanställde vi sju områden. Bland dessa finns säkert aspekter och detaljer som motiverar fler områden, så tveka inte att återkomma med feedback om du upplever att dessa områden inte stämmer!

De sju områden vi fokuserar på i vår sammanställning är följande:

• Produktvision (mall för produktvision)
• Kommunikation
• Intressenter (mall för intressentanalys)
• Produktbacklog
• Teamet
• Ceremonier
• Organisation

Avslutningsvis

Läs mer om vad inom varje område som en produktägare bör bemästra genom att ladda ned Produktägarens 7 budord nedan.

Sist men inte minst: samtliga dessa områden (och förstås ännu mer verktyg, tips och tricks) är del av kursen ”Certifierad Produktägare”. Läs mer om den kursen och kurstillfällen här.

Agilitet har länge varit förknippat med startups och mindre organisationer medan de större bolagen förknippas med långa beslutsvägar och en svårighet att dra nytta av nya möjligheter som uppenbarar sig. De är helt enkelt för långsamma på bollen och har inte möjlighet att reagera tillräckligt fort för att hinna med i alla svängarna. Vi ser dock att allt fler större företag och organisationer väljer att anamma de agila arbetsmetoderna i förhoppning om att bli mer lättrörliga. Men med en stor organisation kommer ökad komplexitet; större projekt, organisatoriska hierarkier och sammanvävda arkitekturer. Att applicera agila metoder såsom Scrum i dessa typer av bolag är ofta inte tillräckligt för att nå ända fram, då det i och med detta dyker upp andra problem. Till exempel koordinering av team som i större produkter har beroenden mellan varandra. Ett sätt att tackla detta är genom att föra in det skalade agila ramverket SAFe.

Varför skala agilitet?

Organisationer som har jobbat med agila förhållningssätt en stund, upptäcker ofta att det saknas en entydig struktur för hur man får flera team att arbeta mot samma mål, produkt eller riktning. Man upptäcker också att det skulle finnas en fördel med att kunna fokusera utvecklingsriktningen med kraften från flera team samtidigt, istället för isolerat arbete från de enskilda och självstyrande team man redan har. Under årens lopp har flera sådana behov definierats och flera ramverk för så kallad skalad agilitet har dykt upp på marknaden som stöttar och försöker lösa dessa problem.

Dock: den första regeln inom skalad agilitet är ”Don´t scale agile”! Hur paradoxalt detta än låter så är denna regel till för att påminna oss om att de agila arbetssätten inte bara är ännu ett sätt att skapa komplexa strukturer. Utan tvärt om verkar för att mota bort komplexiteten, bland annat genom skapandet av självstyrande team. Den första regeln finns då till för att påminna oss om att skala på rätt sätt, alltså där det är möjligt och där det finns behov. Något vi på Onbird ofta trycker på är att man bör ha något att skala innan man skalar. Börja alltså litet och se till att du har en fungerande agilitet på teamnivå innan du börjar skala upp det hela.

Ramverk för att skala det agila arbetssättet

För att hantera den komplexitet som kommer med stora organisationer och fortfarande dra nytta av de agila metoderna har flera ramverk tagits fram som stödjer skalad agilitet. Bland dessa ramverk hittar vi SAFe; Scaled Agile Framework, som ett av de mest populära och implementerade. Bland dess ramverkssyskon finns bland annat LeSS, Nexus, Scrum@scale samt fler.

Vad är SAFe?

SAFe är ett öppet ramverk som strävar efter att ge företag och organisationer en holistisk syn på agilt arbete där hela eller valda delar av organisationen får plats under dess paraply. SAFe kombinerar värderingar och principer från både Lean och Agile med hierarkiska nivåer för att bättre passa större organisationers behov.

Här kommer en kort-kort introduktion till de tre olika nivåerna där flödet från affärsstrategiskt beslut till implementering beskrivs:

Portfolio management nivå

Låter bekant? SAFe bygger på den typiska PMO-infrastrukturen men gör det på ett sätt som stödjer dess Lean-Agila praxis. Det är i denna nivå som affärsstrategiska beslut tydliggörs genom värderade och prioriterade teman som sätter riktning för produkterna och förmågorna. Teamet på denna portfolionivå är ansvariga för att underhålla en prioriterad backlogg bestående av affärs-epics som stödjer företagets strategiska plan.

Programnivå

I programnivån plockas de affärs-epics som skapades i portfolionivån för att här bli nedbrutna till features/funktioner som kommer att utvecklas under det som SAFe kallar Program Increment (PI). Det är en iterativ större cykel som innehåller ett bestämt antal scrum-sprintar för de olika team som arbetar inom samma produkt/värdeström. Detta är även den nivå som definierar det de flesta kan om SAFe: Releasetågen (ART).

Teamnivå

Teamen inom ett releasetåg arbetar såsom det är föreskrivet i ramverket för Scrum och inför starten av ett nytt Program increment mikroplanerar respektive team sina sprintar utefter den plan som uppstod inom programnivåns planeringsarbete.

Frågor att ställa sig innan man skalar

1. Vilket problem löser vi genom att skala?

2. Vad kommer vi åstadkomma genom att skala?

Att svara på ovanstående frågeställningar ger en god grund för att ta reda på om den skalade versionen av agilitet passar ert företag/organisation.