De enge kijk van SAFe op projecten, portfolio’s en operational excellence

Begin januari 2020 heb ik me ingelezen in versie 5.0 van het populaire Scaled Agile Framework (SAFe) van Dean Leffingwell c.s. Om mezelf Safe 5.0 Agilist te mogen noemen en mijn in 2017 behaalde certificaat te vernieuwen naar de nieuwste inzichten, moest ik flink wat uren zelfstudie in de SAFe 5 Certified Member Upgrade (5.0) training en daarna een online Leading SAFe examen doen. De kijk in het raamwerk op projecten, portfolio’s en operational excellence valt me op en ik kan er niet in meegaan. Ik leg uit wat ik bedoel met een te nauw blikveld op de werkelijkheid buiten organizational agility volgens SAFe valt.

Waar halen de SAFe schrijvers hun inspiratie vandaan?

Bij elk raamwerk is het zaak de onderliggende paradigma’s en inspiratiebronnen te kennen. Bij de ontwerpers van SAFe staan deze deels als recommended reading, deels als bronnen bij de artikelen achter de SAFe Big Picture genoemde werken in de boekenkast:

Sterke punten van SAFe

Het amalgaam van Lean, Agile Manifesto, Scrum, Change management, The Lean Startup, portfoliomanagement, Systems thinking en Design Thinking is sterk op vlakken als:

  • gedrag, de principes en de waarden die nodig zijn voor een agile transformatie voorbeeldig uitleven als leiders en medewerkers in een organisatie.
  • klantgerichtheid.
  • DevOps praktijken als continuous exploration, continuous integration en continuous deployment.
  • portfoliomanagement.
  • verankering van veranderingen in de strategie van de organisatie zonder wendbaarheid en bottom-up innovatie in de weg te zitten.
  • Lean principes toepassen.

SAFe en projecten

Net als veel andere Agile frameworks die zichzelf willen bewijzen hét middel om organisaties te laten overleven in de snel veranderende wereld, zetten de schrijvers zich op allerlei plekken in het materiaal af tegen hoe zij projecten en projectmanagement percipiëren.

In de uitleg over de functie en het doel van epics (over het algemeen zit een epic in de hiërarchie van backlog management tussen themes en features en stories in met minimaal een kwartaal werk voor meer dan één squad in meer dan één applicatie), stelt SAFe: “It’s important to note that epics are not merely a synonym for projects; they operate quite differently, as the Figure highlights. SAFe generally discourages using the project funding model (refer to the Lean Portfolio Management article). Instead, the funding to implement epics is allocated directly to the value streams within a portfolio. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup cycle.” Functie en financiering worden hier op één hoop gegooid. Dat komt de helderheid niet ten goede.

Alleen met de eerste regel in de tabel ben ik het eens.

#2 Een vaste doorlooptijd en scope?

Stellen dat projecten, zonder uitzondering, een vaste doorlooptijd en scope hebben die volledig geïmplementeerd moet worden, gaat voorbij aan het besef dat er gedurende het hele project (on)geplande veranderingen kunnen optreden die onder meer de scope beïnvloeden en de keuzevrijheid die je in projecten hebt om scope (functionaliteit), tijd, geld (kosten, budget), kwaliteit, baten en risico’s vast danwel (gedeeltelijk) variabel te houden en met toleranties (vrijheidsgraden, bewegingsruimte) te werken.

#3 Afgeronde taken als maatstaf voor voortgang?

De projectmanagement methode PRINCE2 is hierover kristalhelder, net als over de stellingname in de derde regel. Task completion zegt niets over voortgang. Opgeleverde producten die geaccepteerd zijn door de klant of eindgebruiker tellen. In PRINCE2 gelden de principes productgericht plannen en voortgaande zakelijke rechtvaardiging. The Standard for Project Management stelt: “Value, including value from the perspective of the customer, is the ultimate success  indicator and driver of projects. (…) To support value realization from projects, teams shift focus from deliverables to outcomes. (…) Project teams evaluate progress and adapt to ensure the expected value can be realized.”

“Definitive start and end date” in regel 2 van de tabel impliceert dat er niet aan getornd kan worden. The Standard for Project Management stelt daarentegen: “The temporary nature of projects indicates a beginning and an end to the project work. A project ends in one of two ways:

  • The project objectives have been met.
  • The project is terminated because its objectives will not or cannot be met, the cost to deliver exceeds the expected value, or there is no longer a need for the project.”

#4 Altijd een gedetailleerde, kwantitatieve business case?

In de vierde regel worden projecten nagegeven te werken met een “overly detailed business case, based on speculative ROI.” Hoe gedetailleerd een business case (document) moet zijn uitgewerkt, is een kwestie van afspreken. Er zijn zat projecten waarbij de zakelijke rechtvaardiging ook zonder uitgebreide berekeningen met x cijfers achter de komma vast te stellen is. Het rendement (return on investment) is overigens geen input, zoals het figuur in SAFe stelt, maar een mogelijk resultaat van een kwantitatieve business case. Het is aan het bedrijf of de organisatie waar je als projectmanager werkt om te bepalen of levensvatbaarheid wordt bepaald op basis van rendement, netto contante waarde of terugverdientijd, welke rentepercentages en drempels voor terugverdientijd en rendement worden gebruikt en welke kostenposten tegen welke tarieven meegenomen moeten worden in de berekening.

#5 Waterval?

Op één of andere manier is binnen de Agile community het denken over projecten als synoniem voor sequentieel en ‘waterval’ niet weg te branden. De watervalmethode is een sequentiële systeemontwikkelmethode met terugkoppeling in elke fase. Lees de geschiedenis van de in 1970 door W.W. Royce beschreven schets eens rustig door op Wikipedia en trek dan je conclusies. Ook moderne systeemontwikkelmethoden als RAD, RUP, DSDM en andere binnen Agile zijn nog altijd gebaseerd op de volgorde der dingen. Ook in SAFe vind je de artikelen met uitleg over mini-watervallen en V-model. Een systeemontwikkelingsmethode is echter geen projectmanagementmethode. Het ene project is het andere niet! Pas dus op met kwalificaties als Big Design Upfront als enige mogelijkheid, bedenk dat Agile aanpakken van pas komen in een bewegelijke, sterk competitieve wereld vol onzekerheden (VUCA). De bouw van de tunnel in de N377 in Balkbrug vanaf dit voorjaar na jarenlang ontwerpen, vergunningen verkrijgen, aanbesteden en draagvlak creëren in de samenleving, het organiseren van een feest voor mijn 50e verjaardag in juni of onze zomervakantie verlopen niet SAFe.

#6 Commitment voor het hele project?

Deze stelling is in tegenspraak met de veronderstelling dat alle projecten een stage – gate aanpak volgen. In de PRINCE2 trainingen geef ik altijd aan, dat de projectmanager in deze methode beter fasemanager kunnen heten, omdat er voor één fase tegelijk mandaat, budget en een gedetailleerd plan wordt gegeven met toleranties. Met mijn commentaar op regel 2 in het achterhoofd, zie ik lang niet altijd de noodzaak voor commitment voor een heel project.

En wat is de waarde van een commitment als de plannen niet deugen en het niet realistisch (meer) is binnen de kaders van beheersingsaspecten als tijd, geld, risico’s, kwaliteit, baten en scope te blijven? Stop het project, adviseert PRINCE2 dan in plaats van je project als bodemloze put voor (gemeenschaps)geld te behandelen.

Gedreven door welke waarde?

SAFe heeft nu in de versie 5.0 het 10e principe Organize around value toegevoegd. De exposure draft van de 7e editie van The Standard for Project Management opent op de eerste pagina met “The standard describes the Value Delivery System, of which projects are a fundamental component. The standard identifies principles that guide the practice of project
management practitioners, project team members, and other stakeholders who work on or who are engaged with projects. The principles support achievement of the intended outcomes that ultimately deliver value to organizations and stakeholders.”
Value is niet gedefinieerd in SAFe, wel in The Standard for Project Management: “the net tangible or intangible result of realized benefits less the cost of achieving those benefits.” en “The evolution of business and the interplay of various environmental forces drive the practice of project management toward a value-based system. The value-based system is a framework for optimizing outcomes by balancing elements such as cost, quality, risk, stakeholder interests, and resources.”

SAFe en portfolio’s

Hoewel SAFe al jaren over program en portfolio laag spreekt, zijn de begrippen zelf niet gedefinieerd in het raamwerk. Aangezien projecten niet bestaan in SAFe, zal de definitie in The Standard for Portfolio Management – Fourth Edition niet opgaan. Daarin is een portfolio: “a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.”

Wel is er in SAFe (terecht) aandacht voor Lean Portfolio Management en Lean Budget Guardrails. Portfolio management in SAFe rond Solution Trains, Agile Release Trains, Solutions and Program Increments om een Portfolio Vision te realiseren is echter wat anders dan een set aan projecten, programma’s, andere portfolio’s en operationele werkzaamheden die gezamenlijk strategische doelstellingen nastreven. Doel is wellicht hetzelfde, bouwstenen zijn anders.

SAFe en operational excellence

Ik heb moeite met de relatie tussen SAFe en operational excellence die in Lean Portfolio Management (LPM) gelegd wordt via de dimensie Agile Portfolio Operations. De rollen die SAFe in deze dimensie ziet acteren, zijn Agile Program Management Office/Lean-Agile Center of Excellence (APMO/LACE) en Communities of Practice (CoPs) for Release Train Engineers (RTEs) en Scrum Masters.

SAFe ziet zichzelf echter als tweede besturingsysteem van een organisatie, om het netwerk van stakeholders met een virtuele organisatie zo te bedienen dat waarde voor klanten wordt geleverd met passende producten en diensten (waarbij het gaat om snelheid van innoveren) zonder de hiërarchie (staande organisatie, gericht op efficiëntie en stabiliteit) te moeten veranderen, of geheel overnieuw te beginnen.

De grote broek die het raamwerk aantrekt om operational excellence aan te jagen, is: “Operational excellence is a process that focuses on continually improving efficiency, practices, and results to optimize business performance. The LPM function plays a leadership role in operational excellence, helping the organization achieve its business goals relentlessly. The LACE, which may be a standalone group or part of the APMO, is often responsible for leading operational excellence. In either case, the LACE becomes a continuous source of energy to power the enterprise through the necessary organizational changes.”

Het begrip operational excellence staat centraal in de afweging van strategieën in het boek De discipline van marktleiders van Traecey & Wiersema. Product leadership en customer intimacy zijn de twee andere, waarvan er traditioneel één tiptop geregeld moest zijn om onderscheidend te zijn en de andere minimaal on par om mee te kunnen met de concurrent. Voor de digitale economie, handel in elektronische producten of gegevens, zoals Uber, Airbnb, Google, Facebook, Spotify, etc. is cost efficiency snel vertaald als operational excellence en wordt gesteld, dat kiezen tussen de strategieën niet (meer) nodig is. Dat is natuurlijk kort door de bocht, aangezien de efficiënte organisatie niet uit de lucht komt vallen en je prima kunt redeneren, dat ingezet wordt op product leadership (gemak, beschikbaarheid, toegankelijkheid, belevingseconomie) en customer intimacy (klant aan de knoppen, de extreme gevoeligheid voor Net Promotor Score en feedback).

De filosofie Lean en zeer kwantitatief ingestoken empirische methode Lean Six Sigma zijn voortgekomen uit de drang om productieprocessen zo licht en efficiënt mogelijk te maken (Lean Manufactoring) door zes vormen van verspilling tegen te gaan (Six Sigma). Motorola wilde met deze combinatie in 1986 in de Verenigde Staten een alternatief hebben voor het Japanse Kaizen model Japan. Grappig, want Lean consultants organiseren nog weleens een Kaizen meeting.

De gestandaardiseerde productie van auto’s (Toyota Production System) is één van de omgevingen waar Lean Manufacturing (afgekort tot Lean) is ontstaan. Als je Lean, dat ook de basis vormt voor SAFe (vergelijk de afbeelding van de Lean Manufactory met het SAFe House of Lean) zomaar koppelt aan operational excellence in de context van SAFe, maak je (onbedoeld) wel een paar gedachtensprongen:

  • Agile aanpakken zoals Scrum, op teamniveau ook de basis van SAFe, zijn bedoeld voor een , context van productontwikkeling met veel onzekerheden.
  • Kanban is in de oorspronkelijke context van het al genoemde Toyota Production System een signaleringskaart om (lopende band)medewekers te wijzen op een probleem ergens in de productielijn. Met z’n allen dat knelpunt zo snel mogelijk wegnemen en de flow herstellen is dan de vervolgactie.
  • Operational excellence bereiken door de knelpunten in de bestaande productielijnen weg te halen (tegenwoordig met procesinterventies van Lean consultants, een opvallende verschuiving ten opzichte van de zeforganiserende productieploeg die echt weet hoe de machines in elkaar zitten), verspilling tegen te gaan, een pull (jouw auto wordt gemaakt, als jij de bestelling plaatst) in plaats van push mechanisme (iedereen een zwarte T-Ford) hanteren en Just In Time aanlevering van grondstoffen en halffabrikaten nastreven, kan maar zo een heel andere context zijn dan met grof geschut (Agile Program Management Office/Lean-Agile Center of Excellence (APMO/LACE) en Communities of Practice (CoPs) for Release Train Engineers (RTEs) en Scrum Masters) vanuit het ‘network operating model’ onder de duiven te schieten van de staande organisatie (hiërarchie) die voor de bestaande voortbrengingsprocessen verbeteringen zoekt.
  • Als ook de operations in een Agile Release Train is ondergebracht, of in DevOps, een wat eenvoudiger model, kun je wat makkelijker bijsturen dan wanneer je parallel aan de staande organisatie werkt.

Conclusie

Met het aanvullen van het Scaled Agile Framework dreigt een collectieve ontkenning van de wortels van het raamwerk en de werkelijkheid buiten het eigen speelveld met rollen, rituelen, spelregels en patronen. Door begrippen te gebruiken die buiten SAFe wel of een andere definitie of betekenis hebben, wordt spraakverwarring in de hand gewerkt. Met de toch al enorme uitdaging om honderden medewerkers als een aantal soepel rijdende treinen volgens dienstregeling en binnen budget te blijven en gebruikers (klanten) tevreden te stellen, moeten ook (productie)processen, projecten, programma’s en portfolio’s, elk met good practices uit het eigen vakgebied ingericht (kunnen) worden. Een enkel raamwerk is geen panacea.