Låt oss säga det direkt: att kombinera pm³ och någon agil metod, som t ex Scrum, är en dålig idé. Varför?
Därför att du kommer inte kunna dra nytta av det agila arbetssättet. pm³ är baserat på en helt annan världsbild. pm³ bygger på årsplaner och att verksamheten beställer från en leverantör, typiskt den egna IT-avdelningen. Agilt har som en grundläggande värdering att reagera på förändringar i stället för att följa en plan. Det agila arbetssättet drivs proaktivt genom utforskande i motsats till att vara en mottagare av beställningar.
Vi har sett flera försök att implementera pm³ och de har ofta misslyckats på grund av att pm³ bygger på tankar om att verkligheten kan förutsägas 18 månader i förväg, att användarna vet vad de vill ha och att det är viktigt att ha en skarp linje mellan verksamhet och IT. Vi hävdar (och flera med oss törs vi lova) att inget av detta är varken sant eller bra.
Kan framtiden förutsägas?
De implementationer av pm³ vi har sett bygger alla på årsplaner. Verksamheten förväntas skriva en förvaltningsplan där de förändringar de vill ha i sin verksamhet och sitt IT-stöd ska beskrivas. Eftersom detta ska gå i symbios med en budgetprocess där pengar ska äskas till dessa förändringar, krävs det att man börjar arbeta med planen i god tid. Man måste ju tänka efter ordentligt när man ska göra en plan! Detta leder ofta till att planeringsarbetet påbörjas direkt efter sommarsemestrar om planen ska vara klar till årsskiftet.
Det ironiska i det här arbetssättet är att för att kunna få till en vettig plan för förändring av IT-stöd måste IT-avdelningen blandas in, vilket tar tid från den förra planens planerade initiativ. Så då måste det ingå planering i planen. Det blir en negativ spiral.
Men det stora problemet med det här arbetssättet är inte lustifikationer i planeringen, utan att ens tro att det går att förutsäga framtiden ett och ett halvt år i förväg. För att det ska fungera måste tre hypoteser stämma;
- Verksamheten vet alltid vad den vill ha
- IT vet hur det ska realiseras
- Verkligheten står still i dessa 1,5 år
Naturligtvis är det inte så, snarare så här:
- Verksamheten upptäcker vad den behöver efter hand
- IT inser efter hand hur det ska realiseras
- Mycket händer i verksamheten på 1,5 år
Det här är en av orsakerna att agila arbetssätt har utvecklats. När vi jobbar agilt så gör vi en ansats, realiserar den, mäter och utvärderar (vad verksamheten tycker), och tar sedan hänsyn till resultatet och integrerar det i nästa ansats.
Istället för att först göra all planering och sedan all implementation, så delar vi upp planeringen och implementationen i små, hanterbara bitar, och ser till att mäta och utvärdera resultatet däremellan.
En skarp linje mellan verksamhet och IT
Ett införande av pm³ i din organisation leder till en tydlig separation mellan verksamheten och IT, beställare och leverantör (se bild nedan). Den inför också en dubblerad hierarki i din verksamhet och din IT-avdelning.
Inom agilt arbete strävar man istället efter att överbrygga alla kommunikationshinder och föra verksamhet och IT närmare varandra. Förändringar i IT-system förändrar verksamheten som i sin tur förändrar behoven av IT-stöd i en ständigt pågående symbios. Standish Group har sedan 1994 publicerat sin CHAOS report2. I den presenteras framgångsfaktorer för att IT-projekt ska lyckas. Varje rapport sedan 1994 har haft “User Involvement” på första eller andra plats1.
En agil produktägare står inte mellan intressenter och utvecklare, en produktägare faciliterar kommunikationen så att den blir så direkt som det går utan att störa. Genom ständiga utvärderingar så formas det agila arbetssättet så att det passar just den organisation där den verkar.
Scrum löser inte alla problem
Vi vet att agila metoder inte löser alla problem. T ex så är Scrumguiden bara på 16 sidor och beskriver bl. a. inte hur man gör när man har många team, eller om ett team har många produkter. Men det är inte heller meningen. Meningen är att man kontinuerligt ska jobba vidare med sin process för att skapa den process man behöver. Detta då till skillnad från färdiga hyllprodukter som t ex pm³, där man ska anpassa sin organisation efter processen.
Kan man inte ta det bästa av båda världar då? Vi hävdar att det inte går och det beror på de grundläggande värderingar skiljer sig åt.
Agila värderingar |
pm³ |
Individer och interaktioner framför processer och verktyg |
Färdiga processer och struktur i upphovsrättsskyddade manualer |
Fungerande programvara framför omfattande dokumentation |
Överlämning mellan IT och verksamhet med dokument |
Kundsamarbete framför kontraktsförhandling |
“Affärsmässig” förvaltning |
Anpassning till förändring framför att följa en plan |
Förvaltningsplaner på årsbasis |
Gillar du pm³ så kör på det, gillar du agilt så kör på det, men kombinera inte de två.
Kom dock ihåg att all information om agilt arbetssätt är öppen och tillgänglig medan pm³ är en proprietär produkt som du betalar licens för.
Referenser:
Intressant artikel. Det är ju flera stora organisationer, inte minst myndigheter, som jobbar (eller har jobbat) med PM3, som förvaltningsmodell.
Har du några praktiska exempel på att det inte har fungerat, eller är resonemanget i artikeln baserad på teorierna?
Det är baserat på observationer inifrån 3 och utifrån 1 företag i privat och offentlig sektor. Mer kan vi inte säga.
Det kan vara så att en organisation har inte insett att det inte fungerar eftersom de inte vet tillräckligt om agile. Om saker och inte ter sig särskilt annorlunda har man antagligen bara tagit in agila ceremonier utan att ta in värderingarna.
Se https://blog.crisp.se/2015/01/12/tomasbjorkholm/the-house-of-agile-a-visualisation-of-the-core-of-agile
Eller https://youtu.be/pfNRIHrs8xQ
Jag är inte benägen att hålla med. Att med så absoluta termer säga att två ramverk inte går att kombinera finner jag svårt att acceptera.
I tidigare debatter har man kunnat läsa hur RUP inte gick att kombinera med agila metoder och att ITIL inte gick att kombinera med agila metoder. Att projektledningsmodeller inte längre var adekvata eftersom agila metoder tagit över. Det krävs ett utforskande och ett metodiskt tillvägagångssätt för att få ramverken att samverka. Och ja, det behövs en planeringshorisont också annars vet vi inte var företaget har för riktning.
Det som ofta kommer på skam när man pratar om Scrum är att man fullkomligt negligerar “sakerna till höger” i det agila manifestet, dvs. det som har med processer och dokumentation att göra. Detta är fullkomligt felaktigt och det bekräftas i den sista satsen. Läs den! Det krävs en mognad för att köra Scrum. Kodbasen måste fortfarande versionshanteras och testerna måste dokumenteras med buggrapportering etc. Utan detta faller även Scrum ihop som ett korthus. Mognaden i teamet och processerna bakom är en förutsättning för att kunna samverka agilt, inte något att ignorera.
PM3 är en förvaltning och planeringsmodell som ur ett beslutsperspektiv ligger över det agila arbetssättet. Visionerna måste finnas även för Scrum, målsättningarna måste finnas även för Scrum. Det är i detaljerna som man utforskar möjligheterna och hittar nya vägar. Kommer det fram att strategin bör ändra kurs, då planerar man om. Planer är inget, att planera är allt, för att citera Eisenhower. Scrum och agila arbetssätt skall växelverka med PM3, det skall inte ses som två olika saker och de två skall aldrig mötas. Det är människorna bakom metoderna som ser till att de två möts. Det är människor som utför arbetet. Det är mycket ihålliga och svepande påstående i denna artikel. Bristande erfarenhet? Troligtvis.
Jag vill tillägga att ofta så har produktägaren bristande kunskap om sin roll eller att ledning och chefsnivåer inte förstår omfattningen av mandat en produktägare måste ha. Här brister det oftast vad beträffar implementationen av Scrum.
Jag skulle akta mig från att komma med sådana svepande påståenden om hur metoder står emot varandra för det är helt enkelt inte sant.
Hej Tor och tack för din kommentar. Jag har sett att du har skrivit samma inlägg i NEA-gruppen på linkedIn. Där finns ett längre svar, men jag ger ett kortare svar här också 🙂 Genom diskussioner lär vi oss och blir duktigare, det gillar vi!
Hur man än ser på saken så är blogginlägget det jag och Per har upplevt hos fler än en kund. Det är verkligheten vi har sett och arbetat i. Vi har även pratat med ytterligare organisationer som upplever liknande problem och frågeställningar.
Jag håller med dig om att det är meningen att pm3 och agilt arbetssätt ska mötas. Men det vi menar i vår artikel är dock att det är hart när omöjligt. Vi är bland annat tveksamma till en hierarkisk struktur, med en tydlig separation mellan beställare och leverantör samt olika beslutsnivåer och mandat. Hierarkiska strukturer ger sällan lättrörlighet. Men som vi skriver i inlägget så har inte Scrum svaren på alla frågor. Scrumguiden säger t ex inget om hur man ska prioritera eller synkronisera över många team. Det är dock avsiktligt. Agila metoder är anpassningsbara och anpassas till den organisation de verkar i. Det är inte din organisation som ska anpassas till den färdiga hyllprodukten. Induviduals and interactions over processes and tools. Inte tvärsom.
Hi auch a shame that I can not understand it because it is not English. Please keep on sharing knowledge in English! Thx
Sorry Alex, but this post is about a method only used in Sweden, so it wouldn’t make much sense in english either 😉
Best – Mikael
Mikael,
pm3 model and methodology is available in english as well as in swedish.
This applies for both licensed and openly published material.
It is in use in several english speaking countries.
See http://www.pm3.se for more information.
Oops, sorry Alexander, hadn’t realized that.
Mikael: I have to report that we use the model across the pm3 model across the nordics and globally in larger scale, in english and in supporting combination with agile. Contact me if you want to see how this is done in practice to your personal experiences.
Anders,
thanks for your comment! We are about to translate this post into english as well.
Your experiences definitely sounds interesting. I’ll mail you and we’ll see if we can share experiences. Thank you for wanting to share!
Best – Mikael
Jag håller med artikelförfattarna. Det blir en klar krock när man försöker tillämpa agila modeller i en PM3 förvaltning. Roller och ansvar blir svåra att hantera (PO vs OÄ/FL/styrgrupper). Lägg till ytterligare en dimension med projekt som skall lämna över till PM3 förvaltning som drivs som vattenfall enligt en standardiserad projektmodell men innehåller systemutveckling så blir det ännu svårare att hålla en agil arbetsmetodik. Som beskrivs kan inte verksamheten gissa vad som egentligen behövs under förvaltningsplansperioden. Det blir alltid en drift och ett delta som måste hanteras. Vissa saker blir inte alls gjorda trots att dom är prioriterade, vissa saker kommer in från vänster. Min erfarenhet är att man sällan är villig att redigera mycket i en fastställd FV plan, utan den divergerar mer och mer från det aktuella läget under perioden.
Tack för din kommentar Gunnar,
och jag kan bara hålla med. Det stämmer väl med våra erfarenheter också.
Hej!
Tack för en intressant artikel. Den frågan som inte besvaras i er artikel är då hur en organisation som har implementerat PM3 i hela verksamheten ska hantera en mjukvaruutvecklingsdel som arbetar enligt agila-metoder?
Att bara slänga ut 3-4 års arbete kring PM3 är svårt att sälja in till organisationen.
Hur tänker ni kring det?
Mvh Henrik
Om jag får kommentera ditt inlägg så tycker jag att det beror på om det handlar om nyutveckling eller vidareutveckling. Inom ramen för pm3 så talar man endast om vidareutveckling på befintlig tjänst/system/applikation. Nyutveckling faller inom ramen för projekt och oftast (dock inte alltid!) utanför förvaltning. Jag antar att mjukvaruutvecklingsdelen du syftar på är vidareutveckling. Så detta hanteras av pm3 alldeles utmärkt. Utan att veta så anar jag att problemet ligger på en helt annan nivå eller i “ett annat segment”. Den agila metoden förutsätter att verksamheten är mycket duktiga beställare alt det finns en roll som är duktig “översättare”; att utvecklare och beställare har täta och snabba avstämningar kring uppkomna issues; att utvecklare får möjlighet att få ut sin kod i produktion på ett tidigt stadium, att användare ger snabba feedback mm. Själv upplever jag att det är här det brister alltför ofta. Det är det jag menar i mitt inlägg med att vara samspelta. Pm3 kan kanske uppfattas som en modell som “trögar ner” utvecklingsflödet. Min åsikt är att det har inte med utvecklingsflödet att göra; pm3 modellen lägger sig inte i detta.
Susanna,
Vad som är nyutveckling och vad som vidareutveckling är egentligen inte intressant. Egentligen är du alltid i ett förvaltningsläge av ett system. Så fort du har skrivit första kodraden, eller första dokumentet, så måste du i praktiken förvalta det. Att hantera nyutveckling och vidareutveckling på olika sätt är onödigt svårt och dyrt.
Nya företag gör inte skillnad på nyutveckling och förvaltning. Man jobbar i förvaltning (eller vidareutveckling) hela tiden. Det sker kontinuerlig prioritering om det är viktigare att lägga till en ny funktion eller förbättra en existerande. Detta är något som jag försöker beskriva i inlägget https://blog.crisp.se/2015/01/19/mikaelbrodd/agile-maintenance
Jag skulle också vilja påstå att det agila arbetssättet är som klippt och skuret för att hantera ovana beställare av IT. Korta utvecklingscykler där man kontinuerligt visar upp vad man byggt gör att även beställare kan få insikter om sin egen produkt och får en möjlighet att förändra produktens riktning. De som jobbar agilt välkomnar förändrade krav.
Det är när man jobbar årsbaserat som det blir svårt, speciellt för ovana beställare. Att mer än ett år i förväg (budget- och förvaltningsplansarbete sker ju innan verksamhetsåret startar i de fall vi har sett) kunna lista ut vad det kan uppstå för behov är inte en enkel sak.
Jag lever i det dagliga arbetet med både pm3 och det agila arbetssättet. Svårigheten i att få dessa två att samspela ligger i att det handlar om processer som ännu inte är på plats. Det agila förutsätter att de som är medspelare är samspelta till 100% och att processer som underlättar för snabba åtgärder ändå ut i produktion är redan på plats. Pm3 i sin tur kräver att verksamhet och IT är samspelta. Jag är benägen att hålla med Ola Berg här: http://smidigt.blogspot.se/2015/08/utveckling-ar-bara-en-liten-del.html att det behövs en omformulering av förvaltningsmodellen med fokus på det lättrörliga. Det är iaf ett mycket intressant ämne att diskutera där mycket i grund och botten handlar om att beställa rätt, leverera snabbt, förvalta stabilt och att nyttan ska bli (helst) 100% bland användarna. Är det någon som har svaret på det ;)?
Sluta tänk “beställa”, det medför ett reaktivt synsätt på verksamheten.
Användare vet inte vad de vill ha. För lyckad utveckling krävs en innovativ organisation som upptäcker vad som behövs.
Jag har, precis som Tor, svårt att förstå resonemanget i artikeln. Jag känner att man läser in hierarkier och ledtider m m i PM3 som inte finns där och samtidigt nämner man hur lätt scrum är fast det i slutändan kräver samma dokumentation för att en leverantör av systemutveckling ska vara seriös i ett tänk att vi ska förvalta ett system även i framtiden.
I den värld jag lever, lite större företag alltså, så är snarare problemet att verksamheterna förväntas lägga prognoser/budgetar för en framtid de inte fullt ut känner till. Den förväntas de sedan hålla sig till möjligen med avvikelser som uppstår p g a lag och regelkrav eller IT-säkerhetskrav. Att i en PM3-organisation med en tydlig kostnadsram bedriva agil utveckling är i sig inte svårare än med andra organisationstyper. PM3 har tydliga eskaleringsvägar men på varje nivå har t ex IT-personen möjlighet att samverka med sin medspelare på verksamhetssidan direkt. Det är mer frågan om hur bemannad verksamheterna är, om de har en bemanning som har möjlighet att agera agilt och svara upp mot den modellens tanke om att alltid kunna ändra om prioritering utifrån vad som har hänt och vad man ser är på gång. Det är också en fråga om IT har förmågan att presentera sina delresultat eller kommande tekniska förändringar så att verksamheten har en rimlig möjlighet att göra denna prioritering. Jobbar man t ex som vi med outsourcad IT-utveckling offshore så får vi ytterligare en dimension med att de som ska föreslå oss tekniska ändringar faktiskt är en leverantör som ju självklart har sin egen agenda avseende merförsäljning, detta inte sagt som kritik till dem utan som ett konstaterande om sakens natur.
Kort sagt, agilt arbetssätt och PM3 är sannolikt inte oförenliga utan problemet ligger på andra plan för att genomdriva agilt arbetssätt/scrum.
Bill,
De hierarkier som vi beskriver i inlägget är faktiska implementationer av pm3 som vi har sett och arbetat i.
Jag håller helt med dig om problemet med prognoser och budgetar som ska formuleras. Det är precis vad vi också har upplevt. Det blir ännu svårare när man också ska planera vilken utveckling av IT-systemen man ska få för dessa pengar långt i förväg.
Håller också med dig om att outsourcad IT-utveckling lägger på ytterligare komplexitet, speciellt om de leverantörerna inte är agila, och ni som beställare vill vara agila. Om beställaren inte har något intresse av att vara agil, ja då går det förstås bra med en outsourcingpartner som inte heller är det.
Ett tips till dig skulle kunna vara att titta på agila kontrakt. Titta gärna på http://agilakontrakt.se/ för inspiration.
En annan källa till missmatchning är att PM3 gör en (artificiell) uppdelning mellan utveckling och förvaltning.
Agil utveckling och kostnad ?
Vad kostar den agila utvecklingen vs ” fasta” budgeten? Och vad får man för pengarna
Hej Bror,
man kan tänka så här – kostnaden för ett team är linjär. Du summerar lönekostnader, konsultkostnader, licenser, hårdvara, lokaler, HR osv och slår ut det per team. Det ger dig en löpande kostnad.
Vad du får för den kostnaden är upp till verksamhetens prioriteringar. En av de agila principerna är att vi gör våra kunder nöjda genom att ofta leverera körbar kod. Ju oftare du kan göra det, desto oftare har verksamheten möjlighet att påverka vad som ska byggas härnäst, dvs vad som just i det ögonblicket ger mest ”bang for the buck”, som man brukar säga.
Jag håller med helt och hållet. Efter att ha spenderat drygt tre år i en myndighet som “missbrukat” PM3 anser jag att modellen i sig uppmuntrar till hierarkier, rörtänk och suboptimering. Det läggs alldeles för mycket tid (och pengar) på att planera saker som ingen vet om det ska göras, eller kommer att bli gjort eller som man ens vet är viktigt. Jag har ingen tilltro alls till PM3. Ska man lyfta fram något som är positivt är det det nära samarbetet med verksamheten, och att vara partners i ett arbete. Det har dock de agila arbetssätten också, dessutom utan hierarkier.
Det intressanta och utmanande i hela konceptet är att få ledningen att våga släppa det traditionella budgettänket, och att de behöver förstå varför de ska prioritera löpande.
Gärna mer inlägg kring det 🙂 Den sista kommentaren om teamets linjära kostnad var riktigt bra! Tack.
Tack Berra!
Tack för inlägget, jag håller precis på att försöka förstå varför ett företag krashat med Scrum. Jag har anat att det har att göra med hierarkier och chefer som har svårt att släppa taget.
När jag läser inlägget får jag en uppenbarelse! Nu vet jag hur jag ska gå vidare. Tack!
Tack för din kommentar Mattias, kul att höra att inlägget har hjälpt dig!
Jag gillade uppställningen av värderingar, det var ett bra försök till jämförelse! Jag jobbar med IT och vi kör pm3 och agilt och så här tycker jag.
pm3: Färdiga processer och struktur i upphovsrättsskyddade manualer
Jag tycker pm3 är rätt tunt, så mycket färdigt finns inte. Jag uppfattar det som en enkel nybörjarmodell om man inte vet var man ska börja.
pm3: Överlämning mellan IT och verksamhet med dokument
Det här känner jag delvis igen. Vår verksamhet är humanistisk och kan ofta inte konkretisera behov eller krav på egen hand även om det blivit mycket bättre. Så det är ganska tacksamt att diskutera fram lösningar, det blir mest irritation över dåliga specar annars. Vi har alltså fått ta fram arbetssätt som inte bygger på överlämning eftersom det inte fungerar.
pm3: “Affärsmässig” förvaltning
Jag tolkar citationstecknen som något negativt? Det är lite otydligt. Vi har lagt ned mycket möda på att ta fram arbetssätt där vi tillsammans konkretiserar vad som ska göras. Om det negativa med affärsmässighet är man kör “blame game” så har vi det ibland men oftast är verksamheten högst delaktig i arbetet hela vägen och så var det redan innan vi började slänga oss med ordet agilt.
pm3: Förvaltningsplaner på årsbasis
Det här har vi verkligen synnerliga svårigheter att komma ifrån. Det tas alldeles för mycket hänsyn till hur ekonomin styrs på bekostnad av enkelhet och snabbhet.
Sen var det “nyutveckling och vidareutveckling”. Otroligt mycket tid har ödslats till ingen nytta på att skilja på dessa. Vi håller fortfarande på. Jag önskar man tog tjänstebegreppet från ITIL och såg det som ett sammanhängande flöde där man tar fram en tjänst, sjösätter, underhåller och avvecklar.
Det där med “skarp linje mellan IT och verksamhet” vet jag inte om jag håller med om. Vi har tvärtom haft så starka band mellan tex FL och FLIT att man haft svårt att påverka utifrån, ett FO har tidvis haft mycket makt och det har lett till suboptimering och silos. Det beror antagligen helt på hur man tolkar och implementerar pm3.
Hos oss är pm3 definitivt på fallrepet, vi har vuxit ur modellen tror jag. Jag tror också den fått klä skott för alla möjliga problem, det är praktiskt att ha något att skylla på. Någon tydlig ersättare finns inte.
Hej Peter och tack för din kommentar!
Hur går det för er att kombinera pm3 och agilt arbete? Jag kunde inte riktigt uttolka det från din kommentar.
Det här med “affärsmässig” inom citationstecken så satte vi det inom citationstecken för att vi tycker det är en inställning som leder till negativa effekter genom en ökad separation mellan verksamhet och IT, något som jag tolkar att du själv inte tycker är så bra.
Det är ju bra att er uppsättning av FL och FL-IT har fallit väl ut, men just den uppdelningen är också någon vi menar driver separationen mellan verksamhet och IT. I agile, t ex Scrum, har produktägaren uppgiften att överbrygga gapet mellan IT och verksamhet, just eftersom det är så tydligt att verksamhet och IT måste samverka för att det ska bli bra produkter åt verksamheten.
Som vi ser det behöver ni inte ersätta pm3 med något, om ni arbetar agilt. Fortsätt med det, nyttja era retrospektiv till att verkligen förbättra er existerande process, istället för att trycka på ännu mer process.
Jag vill också tacka dig Peter för att du delar med dig av dina erfarenheter.
Vi har även erfarenhet av ITIL och sett att det skapar överlämningar mellan utveckling och drift som kostar oerhört mycket varje år.
Ett modernare sätt att arbeta innebär att man kontinuerligt driftsätter ändringar. Då blir de som utvecklar systemet samtidigt också ansvariga för driften. Kanske inte hela vägen ner till järnet men ur ett applikationsperspektiv. Skapar ett incitament för att bygga system som är enkla att drifta.
Jag är väl inget fan av PM3, men jag har hjälpt en kund som kör PM3 att bli agila. Jag har inte upplevt PM3 som ett större hinder, men det kan bero på att jag inte kan PM3 tillräckligt bra för att inse vilket eventuellt våld vi fört på det. Men jag känner att med några ganska små (men också betydande) förändringar, så går det att få PM3 och agilt att funka med varandra.
Vi har lyckats hantera budgetfrågan genom att styra om detaljerade årsplaner till att visa en backlog (som oftast är kortare än ett år) och därigenom motivera budget för ett team för året, istället för budget för specifika funktioner. Backloggen prioriterar vi löpande om, och lägger till och tar bort items.
Jag har inte heller upplevt att det behöver vara en skarp linje mellan verksamhet och IT. PM3:s modell går i och för sig lätt att tolka så, men det finns väl egentligen inget som hindrar att man upplöser den linjen. Vi ser FL som Product Owner och FL IT som Scrum Master, och jobbar löpande med dialog framför dokument som kommunikationsform.
En fördel med PM3 är ju att den vill bygga en virtuell organisation för leveransen, ovanpå den faktiska organisationen. Det har hjälpt oss att (delvis) komma ifrån de silos som den faktiska organisationen består av och gå mot korsfunktionella team med större fokus på ledtid från idé till värde.
Nån som kan PM3 bättre än mig kanske säger att det inte är PM3 längre med de förändringar vi gjort, och då håller väl tesen att PM3 och agil inte går att kombinera. Men om det kan ses som att vi fortfarande kör PM3 (vilket folk här verkar tycka) så tycker jag att de går att kombinera. Jag är fortfarande inget PM3 fan, men tycker att det kan finnas viss styrka i att PM3 vill sätta en virtuell leveransorganisation och att det finns en utpekad Product Owner (i form av FL).
Jag skulle nog säga att det där är inte PM3. Du säger inte hur förvaltningsobjekten definieras men om det inte är system som förvaltas utan värdeströmmar så har du gjort ett bra jobb men det är inte PM3. Ni verkar ha skippat planeringen av årets innehåll genom att se personalen som en fast kostnad som också är bra fast inte PM3. Ni har inte gjort en förvaltningsplan utan bara lagt upp en backlog för närmaste tiden och sedan motiverat att det ska finnas ett team ett helt år. Snyggt, men inte PM3.
Sedan handlar det om individer. Ordet FL andas ju någon som tar emot beställningar från intressenter medan PO är någon som proaktivt utvecklar en produkt som skapar värde, är användbar och tekniskt väl utformad. Men även med en etikett i pannan så kan man ju agera som man vore något annat.
Hoppas din kund inte betalar för något de inte använder.
Vet inte hur det här gick till, men helt plötsligt så känns det som att jag förespråkar PM3, och det trodde jag aldrig skulle hända… 😉
Jag är som sagt ingen PM3 expert, och har egentligen bara stött på det ordentligt hos en kund. Jag har inte gått nån PM3 kurs och kan inte mallarna, men har läst in mig på PÅ:s dokument “Grunderna i PM3” och “PM3 och agila metoder”.
Problemet tycker jag verkar vara att företag ofta har tolkat PM3 för hårt / fel (med utgångspunkt i gammalt hierarkiskt och silo betonat tänk).
Några exempel:
——————————————————————-
Förvaltningsobjekt ska ju utgå från objektverksamheten (verksamheten). Dvs ett förvaltningsobjekt utgår inte från ett IT-system, avdelning etc, utan är kanske mer som en värdeström. Här tror jag dock att många PM3 användare gör fel och låter förvaltningsobjekten utgå från system eller avdelningar. Men det ser jag inte som PM3:s fel, utan att organisationer sitter fast i silo-tänk.
Tycker även att PM3 uppmanar till nära samarbete och kommunikation mellan IT och verksamhet, även om de organisatoriska skisserna de presenterar för ett förvaltningsobjekts organisation antyder uppdelning och hierarki. Om man ändå fastnar i en tydlig uppdelning mellan verksamhet och IT samt tydliga hierarkier tror jag det till stor del kan bero på gamla invanda mönster, inte nödvändigtvis PM3. Och även om det finns en hierarki (vilket det ju i stort sett alltid finns) så handlar det ju mer om hur personen en nivå upp agerar. Är det någon som pekar med hela handen och ger skuld, eller mer lyssnar på teamet och låter dem ta självorganisera.
Om man på en övergripande nivå tittar på vad en förvaltningsplan ska innehålla så fokuserar den inte på att vare en detaljerad plan för året:
– Objektbeskrivning: Kanske som beskrivning av en värdeström, ingen krock med agilt.
– Förvaltningens huvudaktiviteter: Tolkar jag som lite mer detaljer vad som ingår i objektet.
– Mål och budget för perioden: Känns rimligt. Vilket mål/vision fokuserar vi på under året och vilken budget har vi.
– Bemannad förvaltningsorganisation: Lite stelt, men vilka som ingår är väl rimligt.
– Beslut- och arbetsform: Bör väl kunna vara att man följer agila värderingar och principer.
PM3 säger också “Förvaltningsplanen är ett taktiskt styrdokument. För att omsätta den i det dagliga förvaltningsarbetet krävs en nedbrytning i t ex aktivitetslistor och tidsplaner.” Aktivitetslistor kan väl vara att löpande arbeta med en backlog.
PM3 säger även “En vanlig fallgrop är att förvaltningsplanen upprättas som en aktivitetslista istället för att förvaltningsuppdraget målformuleras.” Är det en missuppfattning att PM3 kräver en exakt plan för året?
Om rollen FL säger PM3 “Förvaltningsledaren ansvarar för verksamhetsnytta genom att bevaka verksamhetsperspektivet av förvaltningsobjektet”. Om än lite inåtvänt, så ungefär som en Product Owner.
——————————————————————-
Det jag vill komma till är inte att säga att PM3 är bra. Men om en organisation kör PM3 så vill jag hitta vägar in med agilt, inte skapa ett hinder och säga att först måste ni kasta ut PM3. Det tror jag istället kommer hindra många organisation från att prova agilt.
Men när man går kurser i PM3 och lär sig detaljerna så kanske det tolkningsutrymme som jag använt ovan stängs så att det inte går att kombinera PM3 och agilt.
Jag har inga djupgående studier i den teori som PM3 har utan har helt tittat på hur effekterna blivit när de som gått kursen tillämpar PM3. The proof of the pudding is in the eating.
Du har hittat en annan bild och det är intressant och hoppfullt. Man kan också hitta många exempel där man försökt introducera agilt tänk men bara installerat JIRA. Man är fast i befintliga strukturer och värderingar.
Jag förstår att du inte är en förespråkare av PM3, jag hör vad du säger.
Du kan nog ta nästan vad som helst i processmodeller och ge det ett nacksving så att det blir agilt. Men modellerna skapar strukturer mentalt och organisatoriskt som leder vilse. Centrala principer som ständig förbättring försvinner när pusslet ligger färdiglagt.
Man lever så länge man lär och om inte det är inbyggt i processen så lever man inte så länge. Se på LeSS som förordnar ett antal experiment.
Jag vet inte om jag förstått hela betydelsen i blogginlägget men förespråkas det en agil förvaltningsmodell, en agil förvaltningsorganisation också? Eller är det företeelser som försvinner när man börjar jobba agilt?
Hur hanteras backlog/den funktionstillväxt som verksamheten redan uttryckt behov av, plattformsbyten, applikationsuppgraderingar eller avveckling av systemet i den agila miljö som ni verkar förespråka – utan planering?
Mvh
Nu har jag läst igenom blogginlägget och svaren en gång till. Jag tycker att det är väldigt spännande tankar som förs fram.
Och ni verkar väldigt insatt i respektive kunskapsdomän.
Så jag tänkte få testa ett scenario med er, inte helt sant men inte heller helt orealistiskt. Säg att Enok är FL/PO/”någon annan roll” för ett verksamhetssystem på en lite större svensk myndighet, säg ett system för bidragshantering med ca 2000 handläggare på 20 orter. Idag fick Enok tre mejl:
1. Generaldirektören vidarebefordrade ett mail från departementet, en ny bidragsform skall införas senast 2019 vilket kräver anpassning av vårt verksamhetssystem för den nya Delprocessen.
2. Verksjuristen har skickat instruktion till samtliga i samma roll som Enok där det framgår att myndigheten skall anpassa alla sina system för ett införande av GDPR senast i maj 2018. Samtliga system skall anpassa sig för att kunna skicka handlingar till vårt gemensamma e-arkiv för att minska hanteringen av personuppgifter i verksamhetsapplikationerna.
3. Inom ramen för myndighetens arbete med “ständig förbättring” har processägaren för den aktuella processen genomfört Workshoppar med olika användarkategorier och kommit fram till att en integration med myndighetens ekonomisystem skulle kunna reducera manuella arbetsmoment motsvarande 20 årsarbetare.
Tyvärr är myndighetens resurser lite begränsade. Utan att göra något detaljerat lösningsförslag för något av alternativen så inses att myndigheten inte klarar av alla tre projekten samtidigt, vare sig finansiellt eller ex. Test. Om förvaltningsanslaget skall utökas kräver nuvarande budgetprocess att departementet måste skjuta till pengar. Beställningar av resurser från företaget som levererar ekonomisystemet måste beställas minst sex månader i förväg.
Hur hantera detta i er genomagila miljö, utan planer på övergripande nivå? Som sträcker sig åtminstone två-tre år framåt i tiden?
Vem får bära hundhuvudet när medborgarna inte kan få tillgång till det av regeringen beslutade bidraget? Eller förklarar för användarna, dvs handläggarna att de måste fortsätta mata in betalningsuppgifter manuellt i systemet, trots att de redan finns i Ekonomisystemet? Eller slantar upp 20Msek Euro när en grupp rättshaverister stämmer myndigheten – och får rätt – för sättet man hanterar personuppgifter på i det aktuella verksamhetssystemet?
Enok?
Mvh
Tack för dina kommentarer, Per Åke
Först vill jag säga att du ger oss är ett mycket bra exempel på problem som man har i all förvaltning av system, kort sagt fler krav än man har resurser att bemöta.
Med det sagt så är inlägget en polemik mot uppfattningen att man kan kombinera pm3 med agilt arbetssätt och din kommentar är lite mer om förvaltning och Agile i allmänhet.
En av mina erfarenheter av pm3 är just att planering blev väldigt svårt för IT-avdelningen eftersom man inte hade tillräckligt med budget när det var verksamheten som satt på pengarna.
Men låt oss återvända till ditt exempel. Planering är centralt inom Agile. Scrum, den mest populära tillämpningen, har planering varje dag och varje sprint inskrivet i sina ceremonier. Vidare förväntas PO ha en planering på längre, strategisk, sikt. Det som är skillnaden mot stora projekt med en fastställd plan från början (när man vet minst) är att vi har en värdering som säger att det är viktigare att reagera på förändringar än att följa planen. Få planer överlever kontakt med verkligheten.
För att upptäcka om vi är på rätt väg så strävar vi efter att få snabbt en återkoppling på allt vi gör. Det bästa är att få ut det vi gör i skarp användning och följa upp effekterna. Blir det inte bra, har vi gjort så pass lite att vi kan ta lärdomen och snabbt förbättra.
Så för att ta ditt exempel så skulle jag som PO försöka dela ner alla tre behoven i små värdefulla delar (“slicing”) och prioritera mellan dem. Som sagt skulle jag ha en strategi och hela tiden vara beredd på ändra mig. Jag vill undvika att hamna i “allt måste ändå göras och det blir billigare om man gör allt på en gång”. Den attityden betyder att man tror sig veta vad “allt” är och tror att man kan göra rätt från början. Så är det inte men man kan kanske med den strategin få det att drabba någon annans budget inom organisationen.
Att få tre stora behov på halsen kan förstås ge en närmast förlamande känsla men om man delar ner problemen och ser vad det minsta är som man leverera för att bemöta lagkrav och vad det är som skulle ge mest för pengarna när man tittar på handläggarnas situation, då har man vunnit mycket.
Man kan vara säker på att det dyker nya behov också under de närmaste åren. Detta hanteras på samma sätt, dela ner, skapa snabb återkoppling, utvärdera och återmata in i planen.
Det där med vem som ska bära hundhuvudet är svårt att svara på men jag hoppas att myndigheten inte har en skamkultur och resonerar att det som är problem är i första hand besluts- och kommunikationstrukturer än individer.
Hoppas det var ett svar som gav dig något.
Ett inlägg som Mikael gjort tidigare om förvaltning hittar du här: https://blog.crisp.se/2015/01/19/mikaelbrodd/agile-maintenance
Hej!
Hur ser ni på systemägarens roll. Det blir alltså product owner? Om det fortfarande är så att man levererar “system av sammansatt hårdvara och mjukvara” som produkt, är det POn som hanterar compliance och ackreditering? Jämför med: https://www.sciencedirect.com/topics/computer-science/information-system-owner
Hur är betraktar PO i relation till Product Management i SAFe?
Även informationsägaren tänker jag på. Den som äger informationen och förväntas göra en klassning av olika anledningar. Referens: https://klassa-info.skl.se/useklassa/page/Roller
Tack Richard för dina frågor.
Jag ska försöka svara efter bästa förmåga.
Först vill jag säga att jag noterat att många blandar ihop “system”, i teknisk mening, med “produkt”. Så den som är systemägare kanske inte alls är lämplig att ta ansvar för en produkt som i stort sett lutar sig mot ett system. Produktägaren har ansvar för att produkten lyckas, oavsett vilka system som gör produkten möjlig.
Eftersom jag har erfarenhet av en utveckling inom områden där certifiering krävs (sjukvård och spel) så skulle jag uttrycka att den som är PO har ansvar för att förstå vikten av att produkten är certifierad och se till att det händer. De som bygger det som ska certifieras behöver också ha ingående förståelse för vad certifieringen innebär annars lär det ta många rundor innan man klarar certifieringen.
Tack Per!
Så om jag förstår dig rätt så finns en poäng att särskilja system (typ instanser av produkter som hanterar information) och produkt. Det innebär att det finns en roll att fylla som systemägare, isåfall vad? Men inte i linje med den traditionella PM3 modellen där denne ofta beskrivs som en beställare? Eller ska PO även fylla de ansvarsområden som beskrivs för en systemägare? Vem är PO:ns “uppdragsgivare”? Allt detta tycker jag är lite otydligt i t ex “Scrum and XP from the Trenches”. Dvs rollerna utifrån ett IT/Governance/Security perspektiv. Tycker inte heller SAFe hanterar frågan. DA beskriver lite: https://disciplinedagiledelivery.com/agility-at-scale/it-operations/
När det gäller boken “Scrum and XP from the Trenches” av vår kollega Henrik Kniberg, så ska man minnas att det är menat som en individs erfarenheter. Han har flera gånger sagt till mig att han är förvånad över hur många som uppfattar den som ett slags facit. Han är givetvis själaglad över mottagandet världen över.
Facit borde vara den officiella Scrum-guiden som du säkert känner till. Du kommer nog inte hitta alla dina svar där. Ambitionen är att bara ge några ramar att hålla sig inom för att sedan bedriva ett kontinuerligt förbättringsarbete.
Det är ju en grundläggande värdering att individer och interaktioner är viktigare än processer och verktyg. Att ge ut en tjock bok med detaljerade rollbeskrivningar och organisationsstrukturer vore att motsäga den värderingen.
Alla verksamheter har olika utmaningar så det är ju finessen. En värdering i Scrum är kurage, så vi ska ta våra erfarenheter till bordet och fråga högt, hur löser vi det här? Vi vänder oss i rummet och tittar på varandra. Vi är självorganiserade, det är bara vi som kan lösa problemen och har vi inte kompetensen kan inga processer hjälpa oss.
Hej Richard,
dina frågor behöver kontextualiseras, dvs vårt svar kommer vara olika beroende på organisation, dess nuläge och historik, mm, precis som Per svarar. Det gäller att hitta ett svar på dessa frågor i den situation som de befinner sig i. Om jag tittar tillbaka på de kunder jag haft genom åren så har svaret på just det här sett olika ut.
Men om jag ska försöka att generalisera lite så;
Ja, det finns en poäng att särskilja system från produkt (eller tjänst). Framförallt är det inte samma sak 🙂 Väldigt sällan realiseras en produkt/tjänst med hjälpen av bara ett system. Möjligtvis i en startup i sin linda, men även där landar man snabbt i att man behöver flera system för att hålla reda på saker o ting. Dessutom ändrar också en micro service arkitektur också synen på vad som utgör ett system.
En systemägare har ju ofta rollen av den som ska se till att systemet mår bra. Det ska uppgraderas, patchas, mm. Men i en värld av både devops och micro services så suddas dessa gränser ut mer och mer. Så det här beror mycket på hur organisationen är organiserad.
PO:ns uppdragsgivare är någon slags produktorganisation. I den absolut enklaste formen så är PO:n sin egen uppdragsgivare. Men har man mer komplexa produkter där fler personer är inblandade i besluten om vad som är vettigast att göra nu, så kan det finnas hierarkier av produktägande också. Samlas ofta i någon slags Product Management.
Hoppas det hjälpte lite 🙂
Vet inte om jag kan bidra med något efter 5 år samt att jag har inte lusläst varenda kommentar.
Men en reflektion över konversationerna är att pm3 ses som något som ska ”anpassas” efter befintlig styrning, befintlig hierarkin eller befintliga strukturer.
Jag påstår att pm3 är bara ett arbetssätt att prioritera eller omprioritera initiativ. Tillsammans utifrån verksamheter.
Scrum funkar utmärkt med pm3, om ni väljer att prioritera via scrum mindre uppgifter så är jag säker på att styrgruppen med chefer gärna slipper detaljfrågor.
Däremot om resurser behöver omprioriteras så är det knappst scrum som ni behöver.
Eller såhär, två helt olika initiativ kan köras i ega scrum-team men vad händer om dessa utvecklingar får gemensamma beroenden. Då kan ni inte prioriterar i separata scrum-teams.
Har ni en enda mottagare så behövs inte pm3 men har ni flera olika mottagare som ska prioritera er utveckling så är pm3 ett utmärkt verktyg
Vad jag sett så har varken pm3 eller Scrum gett något stöd till att prioritera vad som ska göras. Scrum är dock väldigt tydligt med att det är produktägaren som gör prioriteringen, dock inte hur den går till. Nu var det länge sedan jag arbetade med pm3 men som jag minns det så saknades den tydligheten. Det var mest två parallella hierarkier utan ett tydligt ansvar.
Det är teamet som tar “detaljerna” i Scrum, självständiga och självorganiserande team är centralt i Scrum. Jag upplever inte att pm3 har en sådan värdering utan tänker mer i styrning uppifrån.
Produktägare prioriterar alltså sin produkt, vilket kan vara ett eller flera system och väljer hur samtliga intressenters behov ska vägas in i utvecklingen. Det är alltså inget problem med “flera mottagare”, det är ett grundantagande.
Det är också viktigt att prioriteringen sker med nära kontakt med de som utför arbetet, det är så pass komplext. I pm3 verkar en del ligga hos verksamheten. Ungefär som att ICA-handlaren måste invänta kundernas beslut innan denne vet vad som ska stå på hyllorna.
Jag vet inte vad du tänker på när du säger “prioritera om resurser”. Men om du kallar människor för resurser så kontrar jag med att arbetsuppgifter kan man flytta mellan människor men man ska inte flytta runt människor. Det är välkänt inom gruppsykologin att stabila grupper presterar bäst.
Bonuskommentar:
Om en styrmodell ska ”tryckas in” efter befintlig styrning så kan man fundera på om det är verkligen styrning man är ute efter att ändra/förbättra..
Hej
Nu är det en gammal artikel men behöver ändå påtala författarnas okunskap kring förvaltningsområdet tyvärr.
Jag har ansvarat för införande av både agil systemutveckling (Scrum/devops etc) och pm3 samt under många år styrt verksamheter där vi haft båda förhållningssätten. Ofta är det utvecklare som har denna syn men som också saknar kunskap om komplexiteten och sambanden som finns på en mer övergripande nivå. På konsultsidan är det behovet av att hitta nya modeller och där med nya affärsmöjligheter som driver på.
Ofta handlar det om att arbetssättet inte är förankrat i den egna organisationen och att man håller i sina processer (oavsett vilka det är), man behöver även förvalta arbetssättet och förfina och förändra löpande. Detta är en större utmaning än Scrum-teamens retrospektiv 🙂
Väver man in allt i sin helhet blir det tydligt, anpassningsbart, snabbt och långsiktigt.
Jo nog är det så att pm3 är en del av ett företags affärsmodell. Scrum är dock helt gratis även om förståelse av ett agilt arbetssätt inte är något man tillägna sig enbart genom att läsa en bok.
Fördelen med ett agilt tankesätt är att man hela tiden arbetar med förbättringar av arbetssättet, Scrum har teamets retrospektiv som en del i det.
Att utvecklare för fram krav på arbeta agilt kanske inte är så konstigt eftersom de är de som drabbas av tröga organisationer. En av saker med att vara utvecklare är just att man via systemen som man utvecklare får en ganska god bild av hur organisationen egentligen fungerar.
Håller inte med om att pm3 skulle vara ett hinder för att arbeta agilt eller att det skulle förstärka hierarkier. Jag arbetar med systemförvaltning enligt pm3 och det som varit den stora stötestenen är att pm3 inte blivit etablerat utan förkastas i sin helst till förmån för scrum som inte löser de problem som finns utan istället bygger in en tröghet i systemet. Idag i de verksamheter vi har objektspecialister/systemspecialister, komplett systemdokumentation och produktdokumentation där arbetas det väldigt agilt med dynamiska ärendelistor där ärendena prioriteras och driver utvecklingsarbetet. Regelbundna möten hålls med verksamhet, förvaltning, ledning och leverantörer för att driva arbetet framåt. Men i de verksamheter där det aldrig samlats in dokumentation eller funnits några objektspecialister/systemspecialister där har systemen eroderats utan vidmakthållande åtgärder. Just jag ansvarar för dussintalet system vilka är etablerade till olika grad,. Något som efter hårt arbete var på väg att förändras. Nu ska dessa system bakas ihop i ett team som kommer att få över 40 system att ta hand om. Det kommer inte att vara möjligt att vara så insatt i varje system att det kommer att gå att säkerställa en fortsatt säker drift om focus hamnar på utveckling av produkter, produkter som de flesta fall vi inte äger utan endast betalar licenskostnader för. Brandkårsutryckningar kommer att bli det nya normala med scrum då det långsiktiga nödvändiga strategier för att vidmakthålla enorma systems dagliga funktion kommer att konkurreras ut av utveckling. Vilket är sekundärt i frågan om system som sjunger på sista versen pga bristande budgetmedel eller resursbrist inte tillåtit att de nödvändiga åtgärder kunna utföras för att vidmakthålla systemet. Så vilken nytta har en jätteavancerad superutvecklad produkt om systemet inte klarar av att hantera den?
Det är förstås svårt att kommentera det som är i pm3 idag, fem år efter att vi skrivit ett inlägg som baserat på erfarenheter som är ännu äldre. Kanske har pm3 utvecklats och tagit intryck av agila vörderingar?
Jag uppfattar att din erfarenhet av agilt arbetssätt i form av Scrum har resulterat i att man eftersatt dokumentation av de system man byggt. Det är en vanlig missuppfattning att agilt arbetssätt innebär att man inte ska dokumentera men givetvis är det inte så. Däremot är det en av värderingarna att fungerande programvara är mer värd än omfattande dokumentation. Framförallt är det en reaktion mot projektstyrningsmodeller och processramverk där ifyllandet av en dokumentmall har ett egenvärde. Inte för att jag menar att ni tänker så.
Jag skulle säga att produkter är det som företaget/organisationen erbjuder och skapar värde medan system är det som möjliggör detta. För att bygga system krävs kompetens inom det området, oavsett allt processtänk kring detta. Att bygga stabila system som är enkla att underhålla kan inte åstadkommas enbart med vare sig Scrum, RUP eller pm3.
En annan agil värdering är att interaktion mellan individer är viktigare än processer och verktyg vilket, ironiskt nog, rycker undan mattan för Scrum, SAFe, pm3 och RUP. Det är viktigare att observera hur vi faktiskt beter oss än vad som står i en manual och vilka roller man fått på tallriken.
Så frågan är då om pm3 förhindrar snabb återkoppling och omställning av arbetet när verkligheten förändras och vi dessutom får nya insikter? Är tidshorisonten så långt bort att det sänker en konkurrensutsatt verksamhet eftersom den kan inte svara snabbt på förändringar? Leder det till en organisationsstruktur där många möten är fyllda av personer som inte utför ett arbete på mötet utan är där för att hålla sig informerade? Eller att syftet med möten är att koordinera för att så snart något ska göras så slår det mot stora delar av organisationen? “Low coupling – high cohesion”, säger alltid systemdesignerns men det är bra även för organisationer.
Det här är några av de frågor som jag tycker är viktiga när man funderar på arbetssätt.
Alla som erbjuder processramverk, agila eller inte, vill säga att just deras ramverk kommer att lösa alla problem, bara vi anpassar det och ser till att följa det noga. Men efter 4 decennier i branschen kan jag nog säga att det inte är så. Det är individerna och vilka möjligheter de har att utvecklas och påverka sitt arbete, som är det enda viktiga.