Omöjligt att kombinera agilt arbetssätt med pm3

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

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;

  1. Verksamheten vet alltid vad den vill ha
  2. IT vet hur det ska realiseras
  3. Verkligheten står still i dessa 1,5 år

Naturligtvis är det inte så, snarare så här:

  1. Verksamheten upptäcker vad den behöver efter hand
  2. IT inser efter hand hur det ska realiseras
  3. 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.

image00

pm3:s förvaltningsmodell

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.

image02

Produktägaren faciliterar kommunikationen mellan verksamhet och IT

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:

  1. http://www.cafe-encounter.net/p1183/it-success-and-failure-the-chaos-report-factors#gsc.tab=0
  2. http://www.projectsmart.co.uk/docs/chaos-report.pdf

34 Comments

  • 1
    Håkan Rydman
    2015-08-15 - 19:27 | Permalink

    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?

  • 3
    Tor Ganslandt
    2015-08-17 - 08:56 | Permalink

    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.

    • 4
      2015-08-17 - 20:34 | Permalink

      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.

  • 5
    2015-08-17 - 10:00 | Permalink

    […] kollegor publicerade ett blogginlägg för en tid sedan om att det är omöjligt att kombinera agilt arbetssätt med PM3, vilket är en populär förvaltningsmodell. Mina kollegors poäng är att PM3 och Agile har två […]

  • 6
    Alex
    2015-08-20 - 19:58 | Permalink

    Hi auch a shame that I can not understand it because it is not English. Please keep on sharing knowledge in English! Thx

    • 7
      2015-08-24 - 09:14 | Permalink

      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

      • 8
        Alexander Hedlund
        2015-08-25 - 12:01 | Permalink

        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.

        • 9
          2015-08-25 - 14:04 | Permalink

          Oops, sorry Alexander, hadn’t realized that.

          • 10
            Anders Hagman
            2015-09-29 - 15:42 | Permalink

            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.

          • 11
            2015-09-29 - 16:32 | Permalink

            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

  • 12
    Gunnar Björkman
    2015-08-22 - 14:58 | Permalink

    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.

    • 13
      2015-08-24 - 09:28 | Permalink

      Tack för din kommentar Gunnar,
      och jag kan bara hålla med. Det stämmer väl med våra erfarenheter också.

  • 14
    Henrik Modig
    2015-08-27 - 16:21 | Permalink

    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

    • 15
      Susanna Hammelev Jörgensen
      2015-08-28 - 15:02 | Permalink

      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.

      • 16
        2015-08-28 - 16:28 | Permalink

        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 http://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.

  • 17
    Susanna Hammelev Jörgensen
    2015-08-28 - 12:33 | Permalink

    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 ;)?

    • 18
      Per Lundholm
      2015-10-20 - 17:28 | Permalink

      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.

  • 19
    Bill Lundgern
    2015-08-28 - 12:56 | Permalink

    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.

    • 20
      2015-08-28 - 16:42 | Permalink

      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.

  • 21
    Nils Weinander
    2015-08-28 - 13:52 | Permalink

    En annan källa till missmatchning är att PM3 gör en (artificiell) uppdelning mellan utveckling och förvaltning.

  • 22
    Bror Svenson
    2015-10-14 - 20:56 | Permalink

    Agil utveckling och kostnad ?
    Vad kostar den agila utvecklingen vs ” fasta” budgeten? Och vad får man för pengarna

    • 23
      2015-10-15 - 14:34 | Permalink

      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.

  • 24
    Berra
    2015-10-27 - 19:01 | Permalink

    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.

  • 26
    Mattias Hedman
    2015-11-17 - 09:42 | Permalink

    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!

    • 27
      2015-11-17 - 10:52 | Permalink

      Tack för din kommentar Mattias, kul att höra att inlägget har hjälpt dig!

  • 28
    peter brandström
    2015-12-10 - 22:47 | Permalink

    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.

    • 29
      2015-12-11 - 13:28 | Permalink

      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.

    • 30
      2015-12-12 - 15:05 | Permalink

      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.

  • 31
    Dennis Liljedahl
    2016-11-23 - 15:33 | Permalink

    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).

    • 32
      2016-11-24 - 22:29 | Permalink

      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.

      • 33
        Dennis Liljedahl
        2016-11-28 - 16:18 | Permalink

        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.

        • 34
          Per Lundholm
          2016-11-28 - 22:38 | Permalink

          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.

  • Leave a Reply

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