Tag Archives: frameworks

Review Praxis Framework – De handleiding voor Foundation

Praxis CoverWim Leenders en Wijand Lens hebben het boek Praxis Framework – De handleiding voor Foundation geschreven en mij toegestuurd. Ik was heel benieuwd omdat de website een grote wiki met hyperlinks en een grote navigatiebalk is.  Ik heb het lastig gevonden om op basis van de website een helder en compact beeld te krijgen wat Praxis nu precies inhoudt. Gaat deze handleiding mij daarmee helpen?

Praxis is een vrij beschikbaar framework waarin verschillende methoden zoals bijvoorbeeld PRINCE2, MSP, MoP maar ook de PMBoK en de ICB (IPMA) en P3M3 en OPM3 bij elkaar gebracht zijn en voorzien zijn van gelijke terminologie en insteek. De makers van de genoemde frameworks hebben hier echter niet in geparticipeerd.

Het Praxis framework bestaat uit vijf samenhangende onderdelen (secties)

  • Kennis (context en managementfuncties)
  • Methode (project- en programma- en portfolioprocessen en documentatie)
  • Competentie (management en proces)
  • Volwassenheid (vaardigheid en volwassenheid)
  • Bibliotheek (encyclopedie).

In totaal negen aandachtsvelden (verwarrend dat de omschrijvingen management en volwassenheid twee keer voorkomen).

Het boek is onderverdeeld in 6 delen:

  • Deel 1: Kennissectie onderdeel context
  • Deel 2: Kennissectie onderdeel integratiemanagement
  • Deel 3: Kennissectie onderdeel opleveringsfuncties
  • Deel 4A: Methodesectie onderdeel proces voor projecten en programma
  • Deel 4B: Methodesectie onderdeel proces voor portfolio
  • Deel 5: Kennissectie onderdeel persoonlijke vaardigheden
  • Deel 6: competentie & volwassenheid sectie

Deze zes delen beschrijven samen met bijlage A documenten en bijlage B rollen de negen aandachtsvelden waarbij sommige aandachtsvelden weer verder uit elkaar zijn getrokken en in verschillende delen zijn weergegeven. Aan de Praxis bibliotheek of encyclopedie wordt verder geen aandacht besteed, behalve de opmerking dat het de andere vier secties aanvult met extra details en denkprovocerend debat(?).

In het eerste deel wordt de organisatieomgeving geschetst waarbinnen projecten, programma’s en portfolio’s zich bevinden. De besturing komt aan bod en vervolgens verschillende uitingen van programma en project levenscycli (seriematig, parallel, iteratief) en de portfolio-levenscyclus. Er wordt verder kort ingegaan op de rol van sponsor en ondersteuning. Het deel wordt afgesloten met een hoofdstuk over professionalisme waarin onder andere aspecten zoals vakgroepen en ethiek aan bod komen.

Deel 2 gaat over integratiemanagement waarbij de integratiefuncties plannen, business case, beheersing, informatie, organisatie, stakeholders en borging worden afgezet tegen de onderdelen van oplevering zoals scope, planning, financiën, risico, verandering en resource (de integratiematrix). De verschillende integratiefuncties worden verder uitgewerkt waaronder de verschillende organisatiestructuren voor project, programma en portfoliomanagement. Op het niveau van de stuurgroep wordt de sponsor gepositioneerd. Een nadere uitwerking van een stuurgroep ontbreekt. Bij het plannen komen de bekende zeven vragen aan de orde: waarom, wat, hoe, wie, wanneer, waar en hoeveel?

Deel 3 beschrijft de zes onderdelen van oplevering. Binnen scopemanagement komen vervolgens requirementsmanagement, oplossingsontwikkeling, batenmanagement, configuratiemanagement, configuratiemanagement en wijzigingsbeheer aan bod. Planningsmanagement omvat product definitie (decompositie) technieken, tijdsplanningstechnieken en resourcemanagement. Financieel management gaat in op de investeringsbegroting, financiering en de begroting en kostenbeheersing. Bij risicomanagement komen verschillende risicotechnieken en maatregelen en de risicomentaliteit en risicobereidheid aan bod. Vervolgens wordt verandermanagement en resourcemanagement behandeld. Resourcemanagement omvat onder andere inkoop, contractmanagement en mobilisatie.

Deel 4A beschrijft een generiek procesmodel voor zowel programma’s als projecten. In dit model komen de volgende processen aanbod (hierbij herkennen we de verschillende processen van PRINCE2 en MSP):

  • Identificatieproces (Voorbereiding van een project- of programmavoorstel)
  • Sponsorschapproces (formele go/no go beslissingen bij faseovergangen en escalaties en ad-hoc ondersteuning).
  • Definitieproces (definitieve beoordeling of het project of programma gerechtvaardigd is aan de hand van een gedetailleerd beeld van en hoe het werk wordt gemanaged).
  • Opleverproces (de dagdagelijkse werkzaamheden van de project- of programmamanager).
  • Overgangsproces (afsluiten voorgaande fase en plannen van volgende fase).
  • Ontwikkelproces (de daadwerkelijke realisatie van de (deel)producten of services).
  • Afsluitingsproces (gepland of vroegtijdig afsluiten van het project of programma en eventuele lessen vaststellen).
  • Batenrealisatieproces (voorbereiden en uitvoeren van de transitie en baten oogsten).

Deel 4B gaat in op het portfolioprocesmodel. In dit model zien we de volgende processen:

  • Initiatieproces (ontwerpen, voorbereiden en invoeren van portfoliomanagement). Een programma op zichzelf.
  • Besturingsproces (ondersteunen van het portfolio, vakgebied en specialisme)
  • Managementproces (vgl. de definitiecyclus van MoP. Selecteren, categoriseren, prioriteren en balanceren).
  • Coördinatieproces (dagelijkse coördinatie).

Deel 5 beschrijft en aantal persoonlijke vaardigheden zoals communicatie, leiderschap, delegeren, teamwork, conflicthantering, onderhandelen, beïnvloeden.

Deel 6 behandelt de inrichting van de competentiesectie en volwassenheidssectie op de website, inhoudelijk wordt er niet op ingegaan.

Bijlage A beschrijft de te hanteren documenten, onderverdeeld in managementplannen (besturing), scopedocumenten en opleverdocumenten. Documenten ter ondersteuning van portfoliomanagement ontbreken zowel in het boek als op de website.

Bijlage B geeft een opsomming van Praxis rolbenamingen en overeenkomstige benamingen zoals die gehanteerd worden binnen PRINCE2, MSP, MoP, PMBoK en IPMA.

Conclusie:  Persoonlijk vind ik het jammer dat de structuur van de website is aangehouden en dat de teksten veelal 1 op 1 in het boek zijn overgenomen. Dit boek was een mooie kans geweest om een andere doorsnede te maken en daar de tekst op af te stemmen. Bijvoorbeeld. Ik ben een projectmanager en wat betekent dat, hoe ga ik te werk, met welke context moet ik rekening houden, welke competenties heb ik nodig, welke technieken kunnen mij daarbij helpen, hoe weet ik dat ik het goed doe? Dit is waarschijnlijk mede ingegeven door mijn afkeer tegen het onderscheid in Praxis Foundation en Practitioner. Ik zie de doelgroep niet. Ik denk dat een insteek vanuit een project of programma of portfolio rol een veel betere is. Stel je bent als projectmanager bezig, je wil je kwalificeren maar je moet je nu ook in de details van programma- en portfoliomanagement verdiepen om je te kunnen certificeren. Ik heb mijn twijfels of dit dus werkt. Kijk ik naar portfoliomanagement, dan wordt dat wel heel beperkt behandeld. Ook op de website staat geen extra informatie waardoor het erg kort door de bocht is dat Praxis frameworks als MoP of de Standard for Portfolio Management vervangt. Om met portfoliomanagement aan de gang te willen gaan heb je toch echt meer nodig.

Ik heb ook een overzicht van de belangrijkste rollen met bijbehorende taken en bevoegdheden gemist.

Lezing en heen en weer springen naar de website heeft in ieder geval mijn beeld bevestigd dat Praxis geen volledige vervanging is van PRINCE2, MSP en MoP en de technieken uit de PMBoK en IPMA-competenties en volwassenheid volgens P3M3. Agile werken zoals beschreven in PRINCE2 Agile of AgilePM vind ik verder slechts summier terug in een paar artikelen op de website. Ook de bij de genoemde frameworks gehanteerde principes heb ik gemist. Praxis zal ik persoonlijk dan ook niet snel aanbevelen.

De auteurs hebben middels hun Praxis Framework Compact model een totaaloverzicht willen geven. Een figuur die in het inleidende hoofdstuk wordt uitgelegd en bij ieder deel weer terugkomt om dat deel te positioneren (m.u.v. Deel 1 Kennissectie Onderdeel context). Wat mij betreft een lastig te lezen figuur. Te kleine letters, te grote letters, door het figuur verticaal af te drukken staan een aantal omschrijvingen op zijn kop en bevatten spelfouten. Daarnaast ontbreekt het portfoliomanagementproces. Ook het geforceerd blijven vasthouden aan de navigatie van de website maakt het lastig lezen. Bijvoorbeeld een pijl met daarin de tekst Competentie: Mgmt: Oplevering. Wat bedoeld wordt zijn Oplevercompetenties.

Een ander punt betreft de Nederlandse taal. Zoals gezegd, vaak rechtstreeks overgenomen van de site maar het zijn vaak ‘Google translate’ zinnen met uiteindelijk ‘tenenkrommend’ Nederlands. Zinnen worden niet altijd afgesloten met een punt, enkelvoud of meervoud wordt niet toegepast (heeft of hebben) en een spellingchecker had wellicht ook handig geweest. Verder is er een inconsequent gebruik van hoofd- en kleine letters. Daar de teksten veelal rechtstreeks van de website zijn overgenomen door de auteurs kan je ze dat enerzijds niet direct aanrekenen, maar aan de andere kant, als je er een boek van maakt, dan heb je de plicht om een redactionele toetsing te laten plaatsvinden. Het boek is in eigen beheer uitgegeven dus ik vermoed dat dat achterwege is gebleven. Om de leesbaarheid te vergroten had ik voor de gehele tekst in het boek voor een iets groter font gekozen. Er staat nu wel heel veel tekst op een bladzijde. Eigenlijk ben ik al afgehaakt bij de inleiding van deel 1. Achter iedere zin plaatste ik voor mijzelf de opmerking “ik snap niet wat hier wordt bedoeld?”.

Wat mij betreft is dit boek het stadium van concept nog niet voorbij en dus nog niet rijp voor publicatie. Als de auteurs een volgende versie maken dan zou ik daar ook veel voorbeelden aan toevoegen zodat dit boek een duidelijke meerwaarde heeft t.o.v. de website.

Reactie auteurs op deze recensie:

“Beste Henny

Bedankt voor de mogelijkheid om te reageren op jouw recensie.

Wij willen beginnen met te benadrukken dat het boek opgezet is om een samenvatting van de Praxis website te maken; vandaar dat de tekst bijna 100% gelijk is aan de website. Het boek is bedoeld voor beginnende P3 managers die niet de verschillende aparte methoden willen leren, maar een geïntegreerd geheel met daarbij een verwijzing naar persoonlijke vaardigheden en competenties. Maar ook voor meer ervaren managers binnen project-, programma- of portfoliomanagement zie zich willen verbreden. Daarnaast kan het boek dienen als ondersteuning voor het Foundation examen.

Het is de bedoeling dat na de zomer een boek verschijnt waarin het Praxis Framework praktisch wordt toegelicht. Daarin worden m.b.v. diverse scenario’s de theorie toegelicht (zoals ook in de conclusie aanbevolen wordt). Ook willen we daarbij dieper ingaan op het traject voor de Praxis processen: hoe komt een projectmandaat tot stand.
Omdat dat te ver in de toekomst ligt wilden we alvast een samenvatting maken. Dat geeft ook een verklaring van de beperkte behandeling van portfoliomanagement. En het ontbreken van de bijbehorende taken en bevoegdheden.

Het boek is een samenvatting van de huidige website. Praxis Framework is community driven en nog steeds in ontwikkeling; het is niet af. Vandaar dat op de website en in het boek diverse aspecten summier zijn dan wel ontbreken.

Jouw conclusie dat Praxis geen volledige vervanging is van PRINCE2, MSP, MoP en dergelijke, is waar en is ook logisch. Immers in de oude gedachtegang is er een methode nodig voor projectmanagement, programmamanagement en portfoliomanagement. Praxis Framework gaat echter uit van de gedachte dat een initiatief wordt gerealiseerd met aansturing door een P3 manager en de aansturingswijze wordt bepaald door de complexiteit van scope en omgeving. Hierdoor heb je geen aparte beroepsgroep meer en dus ook geen aparte methode.

De opmerking m.b.t. de figuur en de Nederlandse taal nemen we ter harte. We gaan er beter naar kijken en zullen dit aanpassen.
Er zijn in het algemeen opmerkingen m.b.t. de navigatie en inzicht in de Praxis website. Wij waren misschien te eager en te snel om een samenvatting te publiceren als ondersteuning bij de Praxis Framework foundation training

Je geeft aan dat “Wat mij betreft is dit boek het stadium van concept nog niet voorbij en dus nog niet rijp voor publicatie“. Dat is heel jammer, en we zullen dit met het vertaalteam bespreken. Zeker m.b.t. de opmerking over de inleiding van deel 1: die tekst is afkomstig van de webpagina’s “Overzicht” en “Context” aan het begin van het kennissectie-menu.

Aan het begin stel je de vraag “Ik heb het lastig gevonden om op basis van de website een helder en compact beeld te krijgen wat Praxis nu precies inhoudt. Gaat deze handleiding mij daarmee helpen?” Gezien de recensie die verdeeld is in een inventarisatie en een conclusie zou ik zeggen dat het wel gelukt is om dit beeld te krijgen en weer te geven. Dat het beeld dat daaruit naar voren komt voor jou negatief is, is jammer en voor ons als samenstellers en lid van het vertaalteam een duidelijk signaal wat we op moeten pakken.”

Advertisements

A birds eye view on the agile frameworks forest

Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?” Now we know there is more flesh on the bones. At this moment there are more than fifty known and less known agile frameworks available. To get a first impression of the different frameworks, I try to bring some structure in the jungle to methods and frameworks. In Figure 1, I position the best-known agile frameworks in a structure. The frameworks are positioned within the ‘One-time programs / projects’ sections or within ‘Business as usual’ / indefinite, or both.

Grasp session (Scaling Agile T-Mobile, 2019 Q1) v0.1Fig. 1 Overview agile framework[1]

On the other side the frameworks are clustered around team, product or programme and portfolio level. In the dark blue boxes in Figure 1 we see agile frameworks that are only applicable in IT-focused organizations. All other frameworks can be used within IT and non-IT-oriented organizations (light blue coloured). I haven’t mapped all the known frameworks in this figure, and to be honest, I think there is a lot of duplication and probably commercial drivers play a role too to ‘develop’ the next kid on the block without added value in comparison with the existing frameworks.

The team level, including Scrum and Kanban, is applicable in both IT-oriented and non-IT-oriented products and services development and operations. The engineering level focuses specifically on IT-oriented product development. The one-time, temporary projects and programme frameworks are suitable for both IT and non-IT. The permanent umbrella frameworks (both product-targeted and team-targeted) focus specifically on IT and product development and the business-targeted frameworks help organisations to increase their agility.

Teamlevel

If we start at the team level in Figure 1, then we see of course Scrum as described by Ken Schwaber and Jeff Sutherland in their Scrum Guide. In addition, you will see frameworks such as Kanban (as described in the Kanban Guide for Scrum Teams), Scrumban and DevOps or BusDevOps. The team level can be used both within the IT environment and the non-IT environment. At this team level we can position the following IT frameworks too: Crystal family (developed by Alistair Cockburn with Crystal Clear and Crystal Yellow, Orange, Orange Web, Red, Maroon, Diamond, and Sapphire), Rapid Application Development (RAD developed by James Martin), Adaptive Software Development (ASD by Jim Highsmith, Sam Bayer), Agile Unified Process (AUP) as a simplified version of Rational Unified Process (RUP) which was superseded by Disciplined Agile Development (DAD) which was superseded by Disciplined Agile (DA). If you want to deliver quality as a team within the IT world, only following these frameworks is not enough. To improve quality and minimize technical debt (e.g., inefficient code due to many iterative adjustments), you could make use of eXtreme Programming (XP, developed by Kent Beck, Ward Cunningham, and Rom Jeffries) with Pair Programming, Acceptance Test Driven Development (ATDD), Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Example Driven development (EDD), User Experience (UX) Design, Continuous Integration and Continuous Deployment. AgileBA delivers the techniques to perform business analysis.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project. There are several core practices: documentation, document continuously, document late, executable specifications, single-source information, active stakeholder participation, architecture envisioning, inclusive tools, iteration modeling, just barely good enough (JBGE), look-ahead modeling, model storming, multiple models, prioritized requirements, requirements envisioning.

 Scrum or Kanban?

When teams start working with Agile, Scrum is often chosen. An obvious choice, but the question is whether this is always the right choice. In a Roman Pichler[2] blog the link was made with the life phase of a product. During the first phase of a commercial product lifecycle, in which the commercial product is finally put on the market for the first time, the uncertainty is high, and the focus is on on-time delivery of the first market-ready product. A deadline has been set and that date must be met. During this phase, the focus of the entire team is on delivering a commercially marketable product. This development is perfect for Scrum with its iterative approach, being able to deal with uncertainty and working together on the result (the commercial product). Optionally, a second launch can take place with a next set of important functionalities, so that eventually a mature product is put on the market. During the further course of the product lifecycle, we see the amount of uncertainty and requested changes decrease. At this moment you can make good use of Kanban. In a continuous flow, User Stories can be picked up, developed and deployed one by one by individual team members.

If one looks at the often difficult transfer to production environments, the time-to-market can be shortened by properly arranging the transfer and reducing the number of transfer errors when development and production teams are merged, and the integration testing and deployment are automated (Continuous Integration and Continuous Deployment CI/CD). In this way a DevOps team is created.

Scrumban is the combination of Scrum and Kanban. In the first instance it was intended as a transitional model to switch from Scrum to Kanban and let the team experience Lean- and Kanban concepts. Nowadays it is an approach in which the team has chosen to work according to Scrum with Sprints, but to use the Kanban system to continually view and improve its working method to optimize the flow of units of work (e.g. User Stories).

Scaling up towards product- or program level

In order to be able to use an agile way of working in an organization of some size, just having individual agile teams is not enough. The agile way of working needs to be scaled up and where possible the overarching alignment needs to be institutionalized.

To institutionalize coordination, management of dependencies and integration between the different permanent agile teams within ‘the run-the-business’ / ‘business-as-usual’ side there are various frameworks available, including:

  • Nexus, as described in The Nexus Guide, is a framework for developing product or software development initiatives with three to nine Scrum Teams, in Sprints of up to thirty days. Nexus is the answer of Ken Schwaber, one of the founding fathers of Scrum, to the scalability of Scrum. It requires more than just the will and the agile behaviour of the different Scrum Teams to work together to deliver an integrated product. Nexus is based and builds on Scrum and the rules and roles formulated in The Scrum Guide. We can position Nexus over the team and program levels of SAFe, but it does not offer provisions on portfolio level.
  • Scrum at Scale (S@S, developed by Jeff Sutherland and Alex Brown) is a modular framework. The starting point at S@S is that an all-encompassing one-size-fits-all framework is not possible, but that every time we have to look at scaling of the underlying Scrum principles. The framework can be tailored for your own organization by adding the needed S@S modules. S@S builds on the well-known Scrum framework. By analogy with Nexus you could therefore say that S@S is the answer from Jeff Sutherland, next to Ken Schwaber, the other founding father of Scrum, on the scalability of Scrum.
  • Large-Scale Scrum (LeSS, developed by Craig Larman and Bas Vodde) is an agile framework with rules, based on principles and doing experiments. The LeSS Company offers a freely accessible knowledge base (less.works) containing the integrated approach, principles, process descriptions, definitions, roles, examples, et cetera, for large-scale, mainly IT-related, product development. Transparency is also a key concept within LeSS. The first version dates from 2005 and since then, work is constantly being done on the use and further development of LeSS.
  • Scaled Agile Framework (SAFe, developed by Dean Leaffingwell) is a framework to enable scaling up of agile teams in order to create better systems, create higher employee engagement and make use of correct cost considerations. This is the mission of the scaled agile organization and of the founder of SAFe, Dean Leffingwell. The scaled agile organization offers a knowledge base that is freely accessible to everyone (www.scaledagileframework.com) with an integrated approach in the form of process descriptions, definitions, roles, examples, etc. for Lean / Agile product development. SAFe is based on five core competences: Lean-Agile Leadership, Team and Technical Agility, DevOps and Release on Demands, Business Solutions and Lean Systems and Lean Portfolio management.

Figure 1 (see the ‘Business as usual’ / indefinite block), makes use of a division between product and team targets, namely on the basis of cooperation, if necessary, of teams or not. Or with other words, can the individual teams work autonomous (team focus) or do they have to work together to deliver a new or modified product (product focus). The fore mentioned frameworks all relate to examples where multiple teams work on a single complex product or value stream (product targeted frameworks). Not visual in the figure several frameworks make a distinction between products where you are working together in with a maximum of nine teams (in total the team of teams must not exceed the Dunbar number of 125-150 people) and a team of teams of teams (e.g. SAFe large solutions, Nexus+, LeSS Huge).

The other group concerns frameworks to support IT departments that have to maintain dozens or hundreds of applications or services, whereby the dependencies between the teams are minimal (multiple team targeted frameworks). Here the Spotify model (developed by Henrik Kniberg, Anders Ivarsson and Joakim Sundén) can be positioned, but also Scaled Agile Lean Development (ScALeD, developed by Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock and Andreas Schliep). For both groups, there are essential interfaces between the teams in areas such as data integrity, security and architecture that may not or sometimes will ask for coordination when implementing changes.

In addition, there are many, less known, frameworks that can offer support at the product level, including Agile Integration Framework (AIF), Agile Team Portfolio Management (AgileTPM), AgilePath, Continuous Agile, Disciplined Agile (DA), Enterprise Scrum, Enterprise Agility, FAST Agile, RAGE, Surge, XSCALE, Industrial XP, and AgileDS.

On the left side of figure 1 we see the one-time projects and programs as part of ‘change the business’. Here a distinction is made between projects and programs. Within the project block we see three frameworks and/or methods, all three of which are a further development of the more traditional project management frameworks:

  • Agile Project Management (AgilePM, which is derived from DSDM);
  • PRINCE2 Agile (derived from PRINCE2 from AXELOS)
  • PMI-ACP (in addition to the PMBoK Guide of PMI)
  • Project Half Double (Project Half Double is run by a community of dedicated project management practitioners who are passionate about what they do)
  • Agile Project Management (APM), not mentioned in the figure, can be positioned here too.

On the program side we see:

  • Managing Successful Programs (MSP from AXELOS) that is very agile in itself with the step-by-step growth (via tranches) towards the intended goal (and connects to PRINCE2 (Agile)) and
  • AgilePgM (Agile Program Management of Agile Business Consortium) that connects with AgilePM on the one hand and is comparable with MSP on the other hand.

Praxis covered the portfolio, programme and team levels. Praxis is a free framework for the management of projects, programmes and portfolios (based on PRINCE2, MSP, MoP, AgilePM and other frameworks). It includes a body of knowledge, methodology, competency framework and capability maturity model. The framework is supported by a knowledgebase of resources and an encyclopaedia.

Disciplined Agile (DA) covers both one-time projects and programs as well as business as usual product development. The DA toolkit is a process decision toolkit that describes how agile software development, DevOps, IT, and business teams work in enterprise-class settings.

Portfolio management level

Traditional portfolio management focuses on ‘change the business’. In the previous chapters it has become clear that more and more changes are being handled by the line organization, that is to say: by the permanent agile teams. This means that portfolio management must now also provide an overview of what takes place in ‘run the business’ / ‘business as usual’ for to be implemented change initiatives. Existing portfolio frameworks such as Management or Portfolios (MoP from AXELOS) and Standard for Portfolio Management (SfPfM from PMI) only cover the change-the-business part. Agile Portfolio Management (AgilePfM from ABC) covers ‘run the business’ / ‘business as usual’ as well as ‘change the business’.

In addition, there are a number of agile frameworks that also include a portfolio management component:

  • SAFe offers a portfolio management layer to control ‘run the business’ / ‘business as usual’ permanent team(s) of teams.
  • Disciplined Agile (DA) offers a portfolio process in which, in addition to projects, a number of ‘run-the-business’ / ‘business-as-usual’ aspects are taken into account, such as the permanent teams and the operational management of existing IT solutions.
  • Scrum @ Scale contains modules Strategic vision and Organizational development to which portfolio management can be related.
  • Spotify also provides its own portfolio management approach with its strategic planning.
  • AgilePfM use some basic concepts of an innovation hub, an agile portfolio process, maturity of the initiatives within the portfolio as well as horizons for an agile portfolio.

At the moment (Jan’ 2019) there are no mature portfolio management frameworks that include ‘change the business’ as well as ‘run the business’ / ‘business as usual’. AgilePfM was launched by the Agile Business Consortium (previously DSDM Consortium) as part of their Agile Business Change Framework. However, it is becoming increasingly clear that the overarching agile portfolio management principles are based on frameworks like SAFe, Agile PfM and Disciplined Agile.

Business level

The culture targeted block provides frameworks to increase business agility by changing the mindset of all staff in the organisation. What does it mean to work in an agile way? How can we make sure that the Agile Manifesto values and principles are understand and applied, and the Scrum values (courage, focus, commitment, respect and openness) are part of what we are doing? If the right mindset is in place it makes it much easier to implement an agile framework. In figure 1 the following frameworks are mentioned:

  • Open Space Agility (OSA) is a safe, pragmatic and repeatable technique for getting a rapid and lasting Agile adoption. It works with the framework you are currently using, and OSA can be added at any time. OSA is used to actively engage as many employees as possible in your Agile program.
  • AgileSHIFT (developed byAXELOS) is a framework that prepares people for transformational change by creating a culture of enterprise agility. The AgileSHIFT framework helps organizations to undergo a transformational change, to adopt a ‘survive, compete and thrive’ mindset. It will help to bridge the gap between the current and the target state (the Delta in AgileSHIFT) by embracing a range of agile, structured and hybrid approaches across the organization. The existing severe split between ‘run the business’ and ‘change the business’ will vanish.
  • Agility scales (developed by Jurgen Appelo) helps organizations achieve agility at scale from the bottom up – with measurable evidence of organizational transformation.
  • Lean Startup (developed by Eric Ries) is a methodology for developing businesses and products, which aims to shorten product development cycles and rapidly discover if a proposed business model is viable; this is achieved by adopting a combination of business-hypothesis-driven experimentation, by using a minimum viable product (MVP), iterative product releases, and validated learning.
  • Holacracy (developed by Ternary founder Brian Robertson) is a method of decentralized management and organizational governance, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy.

Not mentioned in the figure:

  • Goal Driven Agile (GDA) rests on three main pillars: autonomy, alignment and structured improvement. It’s a very simple framework and consists of only one base structure, the diamond, five roles and ten building blocks.

Already more than 50 agile frameworks and it’s still growing. The figure can help you in your agile framework selection process, but it cannot be said often enough, do not act dogmatically, see a framework not as a panacea that can be implemented out of the box. Common sense helps too to achieve more agility and probably the best route to become more agile is dividing your products and services into smaller autonomous parts and have them supported by an individual team.

To download this article: A birds eye view on the agile frameworks forest v1.3

[1] This picture is based on a simpler version in the book Scaling Agile in organizaties (Portman, 2017)
[2] Pichler, Roman, ‘Is Scrum right for your product?’, 19 september 2016, see: www.romanpichler.com

Boek launch: Scaling agile in organisaties – Wegwijzer voor projectmanagers en agile leads

Tijdens het 20ste BPUG seminar vond ook de launch van mijn nieuwe boek plaats. Altijd leuk zo’n mijlpaal en ondertussen al vele enthousiaste reacties ontvangen. Ook hebben wij, Bert Hedeman, Hajati Wieferink en ik van de gelegenheid gebruik gemaakt om de nieuwe naam van onze organisatie wereldkundig te maken. Het is geen Hedeman Consulting meer maar HWP Consulting om daarmee de complementaire kennis en ervaringen van ons drieën te benadrukken.

20170613_133950

Boek preview

Scaling agile in organisaties gaat over organisaties die stappen willen zetten om teams meer autonomie te geven door besluitvorming decentraal neer te leggen en managementlagen en managers weg te halen om de teams zelforganiserend te laten optreden.

OMS_SCALING_AGILE_v6Business agility (oftewel de vraag: hoe wendbaar is je organisatie) is meer en meer onlosmakelijk verbonden met het bestaansrecht van organisaties. Het snel en accuraat kunnen inspelen op consument- of klantbehoeftes is van levensbelang. Iteratief en incrementeel ontwikkelen biedt betere oplossingen en waarborgen om producten fit-for-purpose te laten aansluiten bij de eisen van klanten; beter dan een watervalaanpak waarbij alle eisen al aan de start gedefinieerd worden en gedurende het ontwikkelproces in principe bevroren blijven.

Vele organisaties hebben stappen gezet om teams meer autonomie te geven door besluitvorming te decentraliseren. Ze hebben managementlagen en managers weggehaald om de teams zelforganiserend te laten optreden. In dit eerste deel komen enkele agile aanpakken van het eerste uur aan bod. Dit betreft agile aanpakken op teamniveau. Daarnaast beschrijf ik wat het betekent als er meerdere teams met elkaar moeten samenwerken.

Kijkend naar zo’n agile team, werkend met Scrum (met voorgeschreven rollen) of Kanban (zonder voorgeschreven rollen), komen de vragen op of er in zo’n constructie met een ontwikkelteam en Product Owner (typische Scrum-rol) nog wel sprake is van een project en of er dus nog wel plaats is voor een projectmanager. Een project is een tijdelijke multifunctionele organisatie, werkend met een start- en einddatum, opgezet om een uniek product of unieke dienst of release van een product of dienst op te leveren, rekening houdend met onzekerheid en onderbouwd door een businesscase, waarbij de juiste mensen voor het projectteam worden gezocht. Er zijn ondertussen verschillende cases bekend van organisaties die alle project- en programmamanagers hebben laten afvloeien en hiervoor in de plaats zijn gaan werken met Product Owners en Scrum Masters.

Zelf ben ik van mening dat het compleet afbouwen van alle project- en programmamanagers een brug te ver is. Wel geloof ik dat het aantal project- en programmamanagers bij veel organisaties sterk kan afnemen, maar er zullen situaties zijn waar toch een beroep op project- en/of programmamanagers gedaan moet worden. Wellicht worden ze dan anders genoemd, maar de rolinvulling zal veel gelijkenis vertonen met die van de project- of programmamanager. Ondertussen word ik gesterkt in dit idee door het feit dat ik organisaties in Nederland toch weer project- en/of programmamanagers zie aantrekken. Hierbij moet ik wel de kanttekening maken dat de opnieuw aangetrokken of overgebleven project- en programmamanagers veel vaker op de relatie zitten (stakeholdermanagement) en dat ze om zaken voor elkaar te krijgen invloed moeten uitoefenen zonder macht te kunnen hanteren.

Dit boek kan dus ook gebruikt worden door meer traditionele projectmanagers die zich een beeld willen vormen wat business agility gaat betekenen voor hun eigen rol. Blijven er traditionele of hybride projecten bestaan (projecten waarbij gebruikgemaakt wordt van zowel tijdelijke als permanente ontwikkelteams en waarbinnen gebruikgemaakt wordt van zowel agile als meer traditionele aanpakken) waarbinnen zij een projectmanagerrol kunnen blijven vervullen? Of is het zinvol dat zij zich binnen de lijnorganisatie meer gaan ontwikkelen in de richting van portfoliomanager, Agile Leader, Integration Manager, Roadmap Manager of Roadmanager, Release Train Engineer, Scrum Master, Agile Coach of Product Owner?

Ik ga in op verschillende agile frameworks die het op organisatiebrede schaal agile gaan werken ondersteunen. Ik schets eerst een handvat om de verschillende agile aanpakken mee te positioneren en vervolgens ga ik in detail in op een aantal van de meest gebruikte frameworks en geef ik een korte introductie van enkele minder gebruikte en minder bekende frameworks.

Ten slotte vergelijk ik verschillende frameworks en sluit ik af met een aantal, soms aan een specifiek framework gerelateerde, aanpakken om een agile framework te implementeren. Verder krijgt u mogelijke valkuilen waar u bij het implementeren van een agile aanpak rekening mee moet houden en antipatronen waar u tegenaan kunt lopen bij het gebruik van een agile framework.

BestellenScaling agile in organisaties