In het januarinummer van AG connect is mijn artikel over de evolutie van agile raamwerken geplaatst. Zie:
ER ZIJN NAAR SCHATTING MINSTENS HONDERD AGILE PROJECT-, PROGRAMMA- EN PORTFOLIOMANAGE- MENT-RAAMWERKEN. Ik heb de ontwikkeling van agile raamwerken de afgelopen jaren op de voet gevolgd en mijn ‘Bird’s eye view on the agile forest’ (zie figuur)[1] opgebouwd. Binnen dat raamwerk herken ik een evolutie:
Pilotfase: raamwerken ter ondersteuning van één team.
Engineering-fase: focus op vaardigheden binnen een team.
Opschaling naar meerdere teams.
Opschaling naar organisatie: portfoliomanagement-raamwerken.
Herstelfase: raamwerken met focus opde agile mindset, de agile cultuur.
Dit is de tweede blog uit een nieuwe serie die Björn Prevaas en ik maken in het kader van onze training agile programmamanagement en leiderschap.
Als je een programma op een wendbare manier wil inrichten (bijvoorbeeld omdat de context snel verandert, de behoeften van de belanghebbenden op voorhand nog niet helemaal helder zijn of de mogelijke oplossingen voor het vraagstuk nog onduidelijk zijn), is het belangrijk om het leren een goede plek te geven. En om dat in een balans te brengen met het realiseren. Niet alleen maar pushen op oplevering van resultaten en impact proberen te maken, maar ook ruimte scheppen om met elkaar te groeien in de aanpak.
Dat klinkt natuurlijk als een open deur. En toch is dat niet zo eenvoudig en voor de hand liggend. Als het programma eenmaal is gestart (en dat kan menig opdrachtgever niet snel genoeg gaan), gaat de aandacht vooral uit naar meters maken. Dat geeft vaak ook de meeste voldoening. Lukt dat niet of gaan er dingen mis, dan ligt de kaart met de schuldvraag al snel op tafel, zeker in politiek-bestuurlijk gevoelige opgaven die onder tijdsdruk staan. In zo’n context is het een flinke uitdaging om er een lerend programma van te maken.
In mijn optiek heeft de programmamanager een belangrijke rol om dit vraagstuk vroegtijdig op tafel te leggen, in ieder geval in het gesprek met de opdrachtgever en de bateneigenaren. Hoe kijken we naar deze opgave en hoe ziet dan de verhouding tussen leren en realiseren eruit? Wat betekent het eigenlijk als we het leren een plek willen geven in de aanpak van deze opgave? Welke zaken vragen dan aandacht, wie heeft daarin welke rol, wat zetten we daarop in? En wat vraagt het van het gedrag van ons als dragers van de opgave?
Een aantal perspectieven kan hierbij helpen. Wat ik erg behulpzaam vind, is dat van het opgavegerichte teamleren, beschreven door Manon Ruijters, Bob Houtkamp en Cees-Anton de Vries. Hierin komen verschillende aangrijpingspunten aan de orde om het leren in een programma vorm te geven: het impliciete leren, het collectieve leren, het ervaringsleren, het onderzoekende leren, het generatieve leren en het transformatieve leren. Goed gecomponeerd kun je hiermee een programmateam omvormen tot een lerend team.
Een ander perspectief komt van Victoria Marsick en Karen Watkins. Zij hebben een kader ontwikkeld voor de lerende organisatie, met zeven hefbomen. Vrij vertaald: resonerende visie, individueel leren, leidinggeven aan leren, teamleren, ondersteunende systemen, onderzoek & dialoog en verbinding met buiten. Daarmee kun je zowel naar de organisatie(s) kijken waarin het programma plaatsvindt als naar de programmaorganisatie zelf. Hoe zijn de condities qua lerende organisatie en wat vraagt dan extra aandacht?
Een van de hefbomen van Marsick & Watkins is leidinggeven aan leren. En dan zijn we terug bij de programmamanager zelf (en natuurlijk ook bij de andere belangrijke rollen). Hoe lerend ga je zelf eigenlijk te werk? Heb je meer een fixed mindset of een growth mindset (Carol Dweck)? Wat betekent het maken van fouten voor jou? En hoe beïnvloedt je eigen manier van leren de manier waarop je leidinggeeft aan het programma? Onderschat niet de impact hiervan op de mate waarin het programma lerend te werk gaat.
In de meest recente update heeft MSP het leren ook meer plek gegeven. In de kennis- en leerbenadering worden de vragen geschetst waarop de programmastrategie minimaal betrekking moet hebben. De aanpak omvat de organisatie en het beheer van kennis en de wijze waarop lering wordt getrokken uit ervaringen en verbetering wordt aangebracht naarmate het programma vordert. Welke kennis uit het verleden gebruiken we, welke nieuwe kennis zal ontstaan, hoe wordt expliciete kennis vastgelegd? Hoe zal het programma een cultuur van kennisdeling en reflectie aanmoedigen om lessen te leren? Hoe zal het programma een cultuur van voortdurende verbetering stimuleren?
Binnen agile programmamanagement spelen experimenten en het toetsen van aannames en hypotheses een belangrijke rol, bijvoorbeeld door het werken met minimum viable products (MVP’s) en het uitvoeren van retrospectives. Kortom, allerlei bouwstenen om handen en voeten te geven aan lerende programma’s die passen bij een omgeving in verandering.
Deze manier van kijken en hoe dat praktisch te maken, komt aan bod binnen onze training agile programmamanagement en leiderschap. Wil je meer weten over deze training, zie: training-agile-programmamanagement. Je bent van harte welkom!
Dit is de eerste blog uit een nieuwe serie die Björn Prevaas en ik maken in het kader van onze training agile programmamanagement en leiderschap.
Vaak horen wij zeggen dat ‘programma’s per definitie wendbaar (moeten) zijn’. Wat dan onder meer wordt bedoeld, is dat het plan steeds kan worden bijgesteld op basis van veranderende inzichten (en wat leidt tot matig doordachte en uitgewerkte plannen, want ‘het gaat weer toch veranderen’). In de optiek van Björn Prevaas en mij hoeven programma’s echter niet altijd wendbaar (agile) te zijn. Vraagt het om zorgvuldige afweging hoe wendbaar een specifiek programma moet zijn én waarom. En is er meer nodig om die wendbaarheid vorm te geven dan zeggen dat het plan niet in beton gegoten is.
Een agile programma levert wat nodig is en wanneer het nodig is – niet meer en niet minder – om de belanghebbenden te helpen die vermogens te ontwikkelen die nodig zijn om de visie van het programma te verwezenlijken. Deze filosofie is door te vertalen in een aantal uitgangspunten en manieren van werken, die bepaald niet vanzelf tot stand komen door te zeggen dat het programma flexibel is. Daar zul je gericht aandacht aan moeten schenken om ze tot leven te wekken en goed werkend te krijgen:
Om te leveren wat de organisatie of de belanghebbenden nodig hebben, moet het programma voortdurend afgestemd worden op de actuele organisatiedoelen en zal het programma moeten anticiperen en reageren op (verwachte) veranderingen in de organisatie en de omgeving. Een wendbaar programma is vooral zinvol in omgevingen met veel dynamiek en waarin belanghebbenden op voorhand nog niet goed weten wat ze willen of nodig hebben. Een agile programmamanager besteedt daarom veel tijd en energie aan het achterhalen wat bepalend is voor de dynamiek in die veranderende omgeving, wat belanghebbenden nodig hebben van het programma en hoe het programma hierop in kan spelen.
Om dit voor elkaar te krijgen, zijn eigenaarschap van de belanghebbenden en rijke communicatie cruciaal. Het vraagt onder meer om het stevig invullen van de rol van bateneigenaar (of business change owner). Een rol met een naam die in veel organisaties de wenkbrauwen nog altijd doet fronsen. Een bateneigenaar is iemand die verantwoordelijkheid neemt voor een of meer gewenste effecten van het programma (bijvoorbeeld ingevuld door een lijnmanager). Als die rol niet goed wordt ingevuld, is het gevolg vaak dat het programma aanbodgericht in plaats van vraaggericht te werk gaat en de opbrengsten niet goed landen in de organisatie. Een agile programmamanager helpt de organisatie die rol te ontwikkelen.
Om te leveren wat nodig is én wanneer het nodig is, wordt in wendbare programma’s gebruik gemaakt van iteratieve en incrementele ontwikkeling en oplevering van hoogwaardige vermogens die bijdragen aan de programmavisie. Dat betekent dat je stapsgewijs opbouwt en uitbouwt wat de belanghebbenden nodig hebben om de baten (gewenste effecten) te kunnen realiseren en daarbij steeds opnieuw prioriteert. Niet alles in één keer (aan het eind) opleveren, niet alles vooraf bedenken en ook niet overal ‘ja’ tegen zeggen, maar steeds zorgvuldig afwegen: hebben we dit nu echt nodig om in staat te zijn de baten te realiseren? Een agile programmamanager laat zich dus niet verleiden tot ‘groots en meeslepend’, maar focust op klein, praktisch, haalbaar en wenselijk.
Belangrijk hierbij is dat beslissingen op tijd genomen worden. De doorlooptijd om tot beslissingen te komen wordt gezien als een van de belangrijkste oorzaken voor uitloop van projecten en programma’s (decision latency). Een besturingsmodel waarbinnen de meest geschikte personen de beslissingen kunnen nemen, draagt hier positief aan bij. Vertrekpunt daarbij is ‘zo laag mogelijk’. Wat een agile programmamanager dus doet, is de organisatie helpen in de manier waarop beslissingen worden genomen en daarbij de besluitvaardigheid en beslisruimte te ontwikkelen bij de professionals die het echte werk doen.
Om niet meer en niet minder te leveren dan nodig is, kan dit principe uit het Agile Manifesto als leidraad worden gebruikt: ‘Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel’. Dat zorgt ervoor dat het programma geen platina oplossingen levert die veel te veel tijd en geld kosten. Onderzoek heeft namelijk laten zien dat 40-60% van wat wordt opgeleverd niet of bijna nooit wordt gebruikt (Standish Group). Een agile programmamanager is dus niet blij met elke extra vraag, omdat hij zichzelf daarmee aan het werk kan houden, maar focust steeds op datgene wat echt waarde toevoegt.
Deze filosofie komt aan bod binnen onze training agile programmamanagement en leiderschap. Wil je meer weten over deze training, zie:training-agile-programmamanagement. Je bent van harte welkom!
Happy to see that one of my articles regarding the evolution of agile frameworks is now available in Portugese too. It is published in Project Design Management (MundoPM) no 107 – Nov 2022
Agile by Rini van Solingen and Maarten Kossen was originally published in Dutch. This first English version could be seen as a third edition (see below for the differences between this and the second Dutch edition).
The book starts with a warning that agile is more than a mindset, it is a philosophy, followed by 22 chapters, in which the authors show that it is easy to understand, but very difficult to apply at first.
In ‘The why, what when and how of agile’, we immediately encounter the beautiful submarine-dolphin metaphor (waterfall versus agile). Furthermore, several fundamental fallacies that agile solves. Agile is a mindset elaborated in 4 values and defined by 12 principles and made practical in dozens of approaches and implemented through infinite practices. Finally, using the Stacey matrix, we gain insight into when you should or should not adopt agile working.
‘Are we heading in the right direction’ offers seven questions to see how agile one is and also the usefulness of metrics such as velocity, happiness, value, energy, productivity, autonomy and focus.
In ‘Agile by finishing’, we get six practical measures to speed up work: make finishing central, cut up and detach, many and small releases, automate everything, utter independence and measure impact and returns.
In ‘Dangers of agile’, we are presented with eight dangers of agile working including agile working is harder than it looks and the requirements for a product owner are unrealistic. Seven misconceptions about agile are also elaborated such as, for example, documentation is no longer needed in agile and agile teams do not need management.
‘Scrum or agile?’ describes Scrum and brief explanations of Kanban, Scrumban, Scrum/XP.
‘Quality of agile’ gives seven reasons why agile enforces quality: rhythm and regularity, quality is explicit and fixed, continuous learning process, value as a steering instrument, no more big projects, automation of quality and autonomous teams. Furthermore, the authors explain the importance of the Definition of Done.
‘Agile transformations’ offers eight well-proven steps in practice: run an initial assessment, formulate the why and the urgency, work out a blueprint, determine the change strategy, create a transformation roadmap, execute the roadmap iteratively in sprints, meet and revise the roadmap and, as a final step, integrate through governance and culture and the paradox of controlled flexibility.
‘Pitfalls of agile transformations’ describes seven pitfalls including the importance of a new rhythm is not understood, fear of failure reigns and there is only attention for process.
‘Agile Culture’ offers seven measures to create an agile culture: focus on the why, change the context, put self-managing teams first, make culture explicit, be the culture yourself, work according to a fixed rhythm and stimulate servant leadership. How you can make your agile culture measurable is the last topic in this chapter
‘Agile leadership’ is about the ownership model with the two dimensions freedom and maturity and seven steps to create your own ownership model. We also find here a summary of Rini’s business novel The Beekeeper.
‘Management teams and agile’ answers the question what will change for management teams if they themselves switch to agile working too. The focus switches to prioritizing at strategic portfolio level, purpose- and mission-oriented positioning of the teams and implementing systemic improvements. What does that mean for all existing scheduled meetings? Several topics will disappear from the agenda and replaced by other tasks.
In ‘Agile governance’ you can find seven measures for agile governance such as work with stable teams and short iterations and plan the work not the people
‘Agile strategy and portfolio management’ describes that true agility also requires agile at a strategic and portfolio level. Seven recommendations for agile strategy and eight measures for agile portfolio management are given: set up short-cycled portfolio management, reduce the number of parallel initiatives, shift portfolio control to delivered value, express choices in terms of possible scenarios, options, and hypotheses.
‘Product ownerschip’ presents nine pitfalls for product owners such as wanting to do everything themselves, assuming mandate and saying ‘yes’ to everything. Furthermore, eight attitudes that successful product owners distinguish themselves from a their less successful colleagues.
‘Agile coaches’ gives answers which coach fits best in your organization depending on the need, the phase of the transformation, issues, and the corporate culture. Get clear what needs are in play, draw up a coach profile and determine which type of coach fits best. The author gives seven types of coaches: the artist, the evangelist, the Viking, the mediator, the professor, the networker, and the innovator.
‘Quality through autonomy’ explains seven measures to increase quality in agile such as automate all quality checks and remove third party dependences.
‘Agile at scale’ highlights seven focus points for scaling agile and explains SAFe including SAFe PI planning and its seven-step preparation. It includes brief paragraphs on Srum@Scale, Spotify and Enterprise Scrum too.
‘Large scale agile challenge’ gives seven root causes of failing agile and ten interventions to add control to large scale agile.
‘Agile sourcing and contracts’ offers eight questions about agile sourcing and six principles for agile structures in contracts as well as how these principles have been implemented at a software vendor CALVI. It ends with an explanation how to do an agile tender.
‘Agile and fixed price’ discusses whether agile can also be fixed-price and four associated measures for fixed-price agile are given.
The final chapter ‘agile estimating and planning poker’ explains how planning poker works and gives ten tips for planning poker.
Conclusion Beautifully formatted, calm soft colors and beautiful photos. Agile is a mindset and a philosophy and that splashes off the pages! The book is peppered with listings of pitfalls, roadmaps, thinking errors, reasons preconditions and dangers that greatly increase the practical applicability of this book. The descriptions of cases at bol.com, ANWB, Eneco consumers and software vendor CALVI help. If you are thinking of or just started an agile transition, this is a perfect book to be read by all involved. Of course, it is also excellent for learning about the agile mindset and philosophy.
Changes in comparison with the Dutch second edition:
The book now starts with a warning that agile is more than a mindset, it is a philosophy
Brief explanations of additional frameworks besides Scrum: Kanban, Scrumban, Scrum/XP
New chapter ‘Management teams and agile’ What will change for management teams if they themselves switch to agile working too? The focus switches to prioritizing at strategic portfolio level, purpose- and mission-oriented positioning of the teams and implementing systemic improvements. What does that mean for all existing scheduled meetings? Several topics will disappear from the agenda and replaced by other tasks.
Chapter about ‘Agile strategy’ is adjusted to include portfolio management too. Eight measures for agile portfolio management are discussed.
New chapter ‘Value steering for product owners’ What is value and eight measures to make steering on value concrete.
The chapter ‘Agile at scale’ describing SAFe now includes brief paragraphs on Srum@Scale, Spotify and Enterprise Scrum too.
The chapter ‘Agile opdrachtgeverschap’ is replaced by ‘Large scale agile challenges’ (seven root causes of failing agile at scale and ten interventions to add control to large scale agile)
The chapter ‘Agile contracts’ is expanded. It’s now called ‘Agile sourcing and contracts’. Two additional paragraphs with ‘Eight questions about agile sourcing’ and ‘How do you do an agile tender (derived from the removed ‘Agile opdrachtgeverschap’ chapter) are added’.
Het wiel van de product owner – out of the box – 40 practische en inspirerende kaarten is geschreven/gemaakt door Bas van Amersfoort en Henny van Silfhout. Met de woorden van de auteurs “Scrum-boeken en trainingen zijn meestal gericht op scrum masters, soms op ontwikkelaars, maar bijna nooit op product owners. Het wiel van de product owner moet dat hiaat invullen.”
Meestal recenseer ik boeken maar deze keer zijn het kaarten. Ik ben benieuwd of de auteurs het genoemde ‘hiaat’ hiermee kunnen invullen. Het wiel van de product owner geeft een overzicht in vijf stappen waar je rol om draait en wat je wanneer doet:
Inspireren met een visie
Plannen met een roadmap
Ordenen met een product backlog
Garanderen met een definition of done
Leren in een review.
40 mooi geplastificeerde kaarten voor de beginnende product owner. Kijkend naar de inhoud kunnen we er direct 6 apart leggen. Dat zijn lege kaarten waar je zelf aantekeningen op kan maken. Blijven er 34 over waarvan er 19 over Agile, Scrum en de rol van de product owner gaan. De laatste 15 gaan in op onderwerpen van het wiel van de product owner (visie, roadmap, product, definition, review). Naast de kaarten krijg je een folder met daarin een toelichting en een hele summiere beschrijving van de kaarten.
Zitten we hierop te wachten? Een aantal kaarten zijn wel heel simpel. Ik mis kaarten over story mapping, het schrijven van stories, kleiner maken van stories, het beschrijven van acceptatiecriteria, et cetera. Voor een prijs van €37,50 had ik veel meer verwacht. Om te beginnen had ik de achterkant van de kaarten gebruikt om een toelichting bij de voorkant te zetten. Om de kaarten te kunnen gebruiken zal je eerst een boek of training over de product owner gelezen of gevolgd moeten hebben. Nu heb je slechts een aantal geplastificeerde powerpointslides waarbij het verhaal ontbreekt. In de lovende recensies in de folder kan ik mij dan ook niet in vinden.
Met het boek Natuurlijk Agile – De verborgen wortels van wendbaarheid heeft Paul Takken een inspirerend boek geschreven dat ons aan het denken zet hoe wij omgaan met agile. En is een antwoord op de vraag waarom er zoveel agile transformaties mislukken. Agile heeft zich te veel aangepast aan zijn koude zakelijke omgeving en is als het ware bevroren. In zijn huidige vorm is agile vrij passief.
Agile heeft in zijn huidige vorm een groot gebrek aan empathisch vermogen. Agile is in de optiek van de schrijver nooit een doel op zichzelf. Het moet passen binnen de natuurlijke behoefte en de beleveniswereld van een organisatie. De vijf basiselementen, de Godai, in de Japanse boeddhistische filosofie zal je ook in je dagelijkse agile praktijk moeten herkennen en gebruiken zodat er meer balans en energie binnen je organisatie ontstaat:
aarde (chi): de basis van agile werken. Een goede en gedisciplineerde uitvoering van de oorspronkelijke agile practices, principes en waarden (stabiliteit)
water (sui): natuurlijk meebewegen met de organisatie (wendbaarheid)
vuur (ka): natuurlijk leiderschap (energie)
wind (fu): een andere wind laten waaien (veerkracht)
leegte (ku): leegte ervaren – slow down to speed up (intuïtie)
Voor het mislukken van agile transformaties worden de volgende redenen aangedragen:
Agile organisaties staan zowel fysiek als mentaal steeds minder in verbinding met hun klanten en medewerkers
Bij verdere doorontwikkeling van Agile zijn er verwarrende interpretatieverschillen ontstaan (wendbaarheid versus verhoogde waarde creatie)
De methodische kant van Agile is dominant geworden ten koste van de achterliggende filosofie die zich richt op harmonie, verbinding en flow
Niet alles is maakbaar. Wij plaatsen ons boven het ecosysteem, in plaats van er integraal deel van uit te willen maken.
In het boek worden zeven hardnekkige valkuilen besproken die verhinderen dat organisaties zich verder kunnen ontwikkelen met methodische Agile transformaties. Vervolgens komen de principes van natuurlijk Agile aan bod (de wortels van Agile): evolutie, ritme, diversiteit en sensitiviteit.
Conclusie:Natuurlijk Agile is een beknopt, vlot lezend en inspirerend boek. Natuurlijk agile gebaseerd op principes evolutie, ritme, diversiteit en sensitiviteit als antwoord op vele mislukte agile transformaties. Wat mij betreft vertalen we dit boek in een vijfde waarde binnen het Agile Manifesto: Maatschappelijk en ecologisch belang boven het belang van de organisatie. Een absolute aanrader.
Nice to see that the Finnish magazine PROJEKTI Maailma 2 2022 posted my article The evolution of agile frameworks. The article reflects the keynote speech during 3PMO-tapahtuma 8.6.2022
The professional agile leader – The leader’s journey toward growing mature agile teams and organizations by Ron Eringa, Kurt Bittner and Laurens Bonnema provides a detailed understanding of the leader’s role in an agile transformation.
When talking about reasons why so many agile transformations fail, I often show a picture of two rhinos colliding, and saying that this is the reason why. Next, I add two text boxes over the rhinos with company culture and agile culture. I can now refer to this book if you want an in-depth explanation of this clash.
The book is divided in eight chapters. the first chapter zooms in on the situation where you see yourself as an organization being overtaken by competitors. You may be very efficient but too unwieldy to respond quickly to the many changes that come your way. One solution is to take over another company that is already much more agile. This is also the case in the book where Reliable Energy takes over Energy Bridge and we follow the CEO who wants to make her organization more agile.
The second chapter shows what it means to form empowering cross-functional teams who discovered their purpose and the role of the leader. Key is that the teams must form themselves and that this takes time.
In the third chapter the emphasis is on the impact. Forget output but focus on the impact by framing goals in terms of customer outcomes instead of things that are produces. From plan-driven goals to goal-driven planning (tactical – intermediate – strategic goals).
Chapter four shows how teams and their leaders are changing by becoming more feedback driven. This is all about decision latency, levels of delegation, decentralized decision-making, and intrinsic motivation.
In chapter five we see the issues leaders are facing when they are halfway their agile transformation. This refers back to the clash between the rhinos at the start of this review. The original way of working with checks and balances versus the agile mind mindset and what that means to the people involved. Self-managing teams require leaders with a catalytic leadership style (collective focus: sharing, enabling, diversity, acceptance and supportive).
Chapter six shows that in an agile organization less and less hierarchical leaders are needed but all the more agile leaders. Where leadership should be seen as an activity and not a role. How to grow new leaders, how to grow mature teams and to escape the silos by breaking them down.
In chapter seven the authors explain that Kotter’s dual operating system cannot be used for ever. At a certain point you must decide to fully go for the agile way otherwise you will fall back to the old ways of working. I am not sure if this is what Kotter has in mind with his dual operating system.
The final chapter puts the agile culture in the spotlights. The social behavior and norms that people in the organization exhibit, including their beliefs and habits. Without this agile culture your agile transformation will fail and be aware this transformation will never end.
Conclusion
a compact and easy to read book that explains the role of a leader in an agile transformation in a clear, straightforward, and practical way. the case used of a merger of two companies as a common thread makes very clear the issues and friction a leader faces in an agile transformation.
I missed the agile leader’s role in sharing knowledge and lessons learnt by setting up communities of practice (CoPs), chapters, guilds et cetera. The issues and what to do about them when multiple teams are necessary to work on a single product are presented very simplistically but this is probably beyond the scope of this book.
In my opinion an absolute must read if you are in the middle of or want to start an agile transformation.
Ed Schouten heeft met het boek Projectmanagement en agile in de praktijk – Het beste van twee werelden, het zoveelste boek over projectmanagement en agile geschreven. Te weinig vernieuwend wat mij betreft.
Het boek bestaat uit vier, eigenlijk vijf delen. Eerst wordt de wereld van projecten verkend en worden de tien meest bekende faalfactoren van projecten besproken. Daarna komen de vier delen aan bod.
Het eerste deel beschrijft het scannen, focussen en vormen om te komen tot een effectieve aanpak waarmee je het project opzet, uitvoert en afrondt.
Deel II beschrijft de meer traditionele projectmanagementaanpak waarbij vooral gebruik gemaakt wordt van PRINCE2 en de fasering van het projectmodel van de ICB4 (projectvoorbereidingsfase, projectdefinitiefase, projectuitvoering en projectafsluiting).
Het derde deel beschrijft de agile aanpak in zijn algemeenheid en meer in bijzonder een aantal agile raamwerken zoals Scrum, LeSS, Nexus, spotify-model, SAFe, AgilePM en PRINCE2 Agile (Nb. Dank voor de verwijzing naar mijn eigen boek Scaling Agile in organisaties waarin ik onder andere deze methoden uitgebreid beschrijf).
In dit deel ook een paar pagina’s over de best of both worlds. Gegeven de ondertitel van het boek had ik hier een volledig deel over verwacht en dat had het boek onderscheidend kunnen maken.
Het laatste deel gaat over sociale vaardigheden voor projecten zoals communiceren, presenteren, overleggen en beslissen, leidinggeven en motiveren, samenwerken in een topteam, omgaan met tegengestelde belangen en het effectief omgaan met je tijd. Superbelangrijk als je een goed resultaat wilt neerzetten maar ook hierover is al zoveel geschreven.
Kortom te weinig vernieuwend, een gemiste kans om het beste van twee werelden handen en voeten te geven. Daarnaast heb ik een aantal keren mijn wenkbrauwen gefronst. Klopt het wel wat er staat. Een paar voorbeelden. Er worden een aantal faseringsmodellen gegeven waarbij de kwaliteit van de plaatjes ontoereikend is. Het figuur parallelle fasering is het verkeerde plaatje (kopie van lineaire fasering). Het plaatje versiefasering en de tekst sluiten niet op elkaar aan en het timeboxing plaatje suggereert dat je in een timebox eerst alles ontwerpt, vervolgens realiseert en uiteindelijk test. In de praktijk lever je op deze manier niets op. Het iteratieve van kleine stukjes ontwerpen, realiseren en testen ontbreekt in dit plaatje. Ook staat een aantal keer in het boek dat iedere sprint een Minimum Viable Product (MVP) oplevert. Dit is onjuist!
Henny Portman's Blog 