Recensie: ISO 21500 in de praktijk

9789052541563-200x300ISO 21500 in de praktijk. De interne richtlijn voor projectmanagement geschreven door Anton Zandhuis, André Legerman en Rommert Stellingwerf beschrijft in het kort de structuur van de richtlijn inclusief een overzicht van de projectmanagement processen naar proces- en themagroepen en de procesgroep interacties met de belangrijkste input en output. Maar dat is niet het hoofdonderwerp. Dit boek schetst de achtergronden, het belang en de toepassing van ISO 21500. Kort samengevat wat moeten we met deze richtlijn.

Het boek neemt ons mee in de aanleiding voor de standaard. In 2016 word c.a. €22 triljard geïnvesteerd, waarvan veel middels projecten. Alleen al binnen de ICT zijn er een kleine 20 projectmanagement methoden. De ISO 21500 biedt één wereldwijde norm en taal waardoor onderlinge afstemming tussen projecten, ook al gebruiken ze ieder een eigen methode, mogelijk wordt. De basis ligt bij bronnen zoals de ANSI norm (gebaseerd op de PMBoK 3de editie), ICB 3, PRINCE2, en een aantal ISO, DIN en BSI normen. De ISO 21500 is een informatieve norm, een richtlijn en geen normatieve norm en daardoor dus niet bedoeld of geschikt voor certificatiedoeleinden.

Daarnaast wordt ingegaan op het algemeen belang en het belang voor organisaties van de norm en meer specifiek voor rollen binnen een organisatie (management, stuurgroep, opdrachtgever, opdrachtnemer, projectmanager, projectadviseur (PMO), projectteam, programmamanager, portfoliomanager en kwaliteitsmanager.

We krijgen een tien stappen plan en een aantal hints en tips om zelf ISO 21500 te implementeren en een bijbehorend fictief praktijkvoorbeeld.

Het boek wordt afgesloten met een toekomstverwachting van ISO 21500, een doorontwikkeling naar een familie van richtlijnen en een honderdtal vragen en antwoorden over ISO 21500.

Conclusie:Een informatief boekje over het waarom van ISO 21500. Het implementatieplan vraagt echter nog wel wat nadere uitwerking.

Bestellen: ISO 21500 in de praktijk


Review HBR May-June 2018, Agile at scale

HBRIn this interesting article Agile at scale – How to go from a few teams to hundreds the authors Darell K. Rigby, Jeff Sutherland, and Andy Noble give insights in their study of scaling up of agile at hundreds of companies.

Some key take aways:

  • Leading agile by being agile, don’t use top-down plans and directives to scale up
  • Create a taxonomy of teams. Break the taxonomy into three components – customer experience teams, business process teams, and technology teams – and then integrate them (see picture)

HBR Agile at scale

  • Get agile rolling. Launch an initial wave of agile teams, gather data on the value those teams create and the constraints they face, and then decide whether, when, and how to take the next step (test and learn cycle)
  • Sequence the transition. Don’t make the mistake of going for easy wins. You have to create a learning environment or organizational changes necessary to scale dozens or hundreds of teams
  • Big bang transitions are hard. Require total leadership commitment, a receptive culture, enough talented and experienced agile practitioners to staff hundreds of teams without depleting other capabilities, and highly descriptive instruction manuals to align everyone’s approach, a high tolerance of risk along with contingency plans to deal with unexpected breakdowns. It’s often better to roll out agile in sequenced steps, with each unit matching the implementation of opportunities to its capabilities
  • No agile team should be launched unless and until it is ready to begin. The team is:
    • Focused on a major business opportunity with a lot at stake
    • Responsible for specific outcomes
    • Trusted to work autonomously – guided by clear decision rights, properly resourced, and staffed with a small group of multidisciplinary experts who are passionate about the opportunity
    • Committed to apply agile values, principles, and practices
    • Empowered to collaborate closely with customers
    • Able to create rapid prototypes and fast feedback loops
    • Supported by senior executives who will address impediments and drive adoption of the team’s work
  • Master large-scale agile initiatives with teams (of teams) of teams
  • Building agility across the business
    • Not every function needs to be organized into agile teams, but ensure that the functions that don’t operate as agile teams support the ones that do
    • Push for greater change in four areas: agile values and principles (agile and traditional teams), operating architectures (modular approach), talent acquisition and motivation (you need expertise combined with enthusiasm for work on a collaborative team, coaching, public recognition, team reward, …), and annual planning and budgeting cycles (annual cycles constrain innovation and adaptation, view decisions as opportunities to purchase options for further discovery, …).

Review: The DNA of strategy execution

9781119278016-480x600During the PMO 2018 Conference in London, where I was one of the speakers, I met Jack Duggal who wrote the book The DNA of strategy execution – Next generation project management and PMO. Jack gave the opening keynote speech Next-Generation PMO: The Future of the PMO in a DANCE world. During my flight back home I started reading the book.

Jack uses the DANCE acronym to characterize today’s business environment. It is Dynamic and changing, Ambiguous and uncertain, Nonlinear, Complex and Emergent and unpredictable, driven by disruptive factors and shifting stakeholder needs and priorities. DANCE is comparable but broader than VUCA (Volatile, Uncertainty, Complexity and Ambiguity).

The author uses a complexity continuum (simple – complicated, complex – edge of chaos – chaos) where in the simple and complicated domain you can use SPEC (Scope-Plan-Execute-Control) to manage linear, well-defined stable situations and in the other domain you have to manage the unexpected by using an organic approach. You must cultivate skills to Sense, Respond, Adapt and Adjust (SRAA). Note: same domains as we find in Snowden’s Cynefin model.

DNA contains the genetic instructions used in the development and functioning of all known living organisms. Jacks asks and answers the question in this book if you could decode the DNA of effective strategy execution and what this means for project management and the PMO. He sees strategy, execution (the two foundational strands) and governance, connect, measure, change, learn as DNA elements. The context and customer focus is the operating environment in which the DNA thrives. See the Quick Reference Card I created to summarize this book. I added Simplicity as an additional element and each element has its own chapter in the book.

QRC (DNA, 180622) v1.0To download: QRC (DNA, 180622) v1.0

Strategy with strands: Diagnosis the pain, make choices to minimize spending, design the selection and prioritization criteria, decide and commit appropriate action and evolve to adapt and finetune the criteria based on evolving strategy). Where to play, how to win, and what to do and, more importantly, what not to do, then selection and prioritization (based on business fit, strategic fit, rewards, risks and resources) of initiatives and projects in a coherent way. 

Execution with strands: Develop your people‘s talent and skills: artistry, DANCEing, changemaking, connecting, learning, entrepreneurial). You need an adaptive platform of enabling processes, technology as enabler (tools, systems, apps and bots) and work that flows through organizational channels (pooled, sequential, reciprocal and adaptive flow).

Governance with strands: To define and establish you need a steering body, standards are needed to establish a foundation of stability, effective policies/procedures for each of the DNA elements can expedite the flow of execution, use gates as decision points as a project or program progresses, use review/audit to assess the status, you have to be cognizant of the compliancy issues, unclear responsibility and accountability lead to confusion and delays, clear definition and limits of authority is a pillar of sound governance and clear decision rights result in effective actions (recommenders, agreers, performers, input, deciders) and simple rules/guidelines can help to steer in the right direction in complex situations (boundary, prioritizing and stopping rules).

Connect with strands: lists what to connect – customers/stakeholders, silos, business, interfaces & interdependencies – with the how – networks and connections, marketing communications (marcom), relationships, and community and collaboration. The Stakeholder empathy map is a nice tool as a replacement for a stakeholder profile.

Measure with strands: You have to know how to define success. Objectives help to define success and key results help to measure it (are you a Ben or BoB, Ben stands for Benefit: measure output and Bob stands for Benefit of the Benefit: measure outcome). How do we report (present and communicate) the measures and metrics to influence desired action, and are we learning and adjusting (double-loop learning).

Change with strandsAwareness helps to better sense and prepare for the consequences of the change. Anticipation takes it further to develop capabilities to anticipate what we cannot see currently, particularly the unintended consequences of the DANCE – dynamic, emergent, and unpredictable changes. The PMO must do enough to assess and prepare for change readiness and the absorption of the change. Execution or implementation alone is not enough. Without adoption, implementation has no value. We should start by understanding the customer? What does the customer need? What do they like and dislike? What motivates them? The choices that you provide to the customer help in paving the path and help to design the structure toward desired outcomes. Structured checklists can also help to pave the path toward greater adoption. To connect you need to frame memorable and sticky messaging and communicate it in a relevant way. When a senior leader have to start something new or any kind of change, the cannot do it on their own. They need the connectors, many agents at different levels that are infecting other and spreading the positive virus.

Learn with strands: Making failure acceptable and learning from it is easier said than done; it is a cultural issue. Curiosity is essential to remove the blinders. Knowledge management, document repositories, and collaboration tools to capture project artifacts are a foundational aspect, but not enough. You need feedback loops, feed-forward, retrospectives, pre-mortem, storytelling, and the learning question. All of this is only possible if employees feel they are part of a meaningful community. The PMO can be the curator to identify, organize, and share lessons, ideas, best practices, tools, and apps. There is a tendency to overestimate the role of planning beforehand, and underestimate the role of correction, after kick-off. In a constantly changing and disruptive world, continuous improvement is like running better and faster, just to stay in the same place, whereas continuous innovation is a double loop, where you learn and evolve to create something new and better.

Simplicity: Simplicity is difficult to practice. Start by understanding and applying the following principles of simplicity: from whose perspective, minimalism – less is more, scalable, self-eliminating, desire lines and simple rules (10 laws of simplicity: Reduce, Organise, Time, Learn, Differences, Context, Emotion, Trust, Failure and The one). Build a Department of Simplicity and develop simplify intelligence.

Conclusion: A book that helps to shape your mind and provides direction when looking at the fact that more and more organizations put agility as one of their themes to survive and you want to know what this means for your PMO if you want to continue to add value by your next generation PMO to your customer and thus your organization. Every DNA element is explained by using leading questions, decomposed into strands, accommodated by many examples, techniques, a checklist and key takeaways. There are not that many books on PMO’s so this one is a must read if you are a PMO manager. In the appendix you can find an overview of PMO functions and activities organized by DNA elements and strands.

To order: The DNA of strategy execution – Next generation project management and PMO

Recensie: Kanban in de praktijk

9789492790095-200x300Regelmatig loop ik tegen een stukje onbegrip over Kanban aan. Kanban wordt dan gezien als een hulpmiddel (bord) om visueel te maken waar men mee bezig, wat nog opgepakt moet gaan worden en wat al af is. Dit is ontegenzeggelijk een onderdeel van Kanban maar Kanban is veel meer. Sam Laing en Karen Greaves geven in hun boekje Kanban in de praktijk een helder overzicht wat Kanban nu precies inhoudt.

Het vlot leesbare boekje is in minder dan een uur uit te lezen. De auteurs stellen echter voor dat je het boekje in een aantal iteraties tot je neemt, er mee aan de slag gaat en verbeteringen in je eigen Kanban doorvoert en dan weer verder leest.

Het is dus een praktijkboekje dat je helpt om met je eigen team Kanban te kunnen toepassen. Als rode draad wordt het hoveniersbedrijf Growing Gardens opgevoerd dat een klein boekje over tuinieren gaat schrijven ter promotie van hun bedrijf.

De auteurs gaan uit van vijf Kanban principes of uitgangspunten die ieder in een eigen hoofdstuk uitgewerkt worden.

De vijf principes:

  • kanban in de praktijkVisualiseer je werk
  • Beperk de hoeveelheid onderhanden werk en maak het mogelijk dat teamleden werk naar zich toe trekken
  • Zorg voor doorstroom
  • Maak afspraken expliciet
  • Verbeter samen

Visualiseer je werk: Hier krijgen we een eerste opzet te zien van het bord dat de drie medewerkers van Growing Gardens gaan gebruiken met daarop de uit te voeren stappen/kolommen (te doen, schrijven, tekeningen, redactie en klaar). Onder te doen staan de taken (ieder hoofdstuk is een taak. En zo’n taak(kaartje) verschuift op het bord van links naar rechts). Vervolgens komen een serie tips aan bod m.b.t. het bord zelf maar ook het zichtbaar maken van de voortgang (wel opgepakt maar geen voortgang: een rode stip), een avatar om aan te geven wie aan welke taak werkt en wat per taak op een taakkaartje (of post-it) minimaal vermeld moet worden (beschrijving, startdatum, datum gereed). Afsluitend krijgen we een paragraaf met daarin een checklist die je zelf kan hanteren bij het toepassen van Kanban binnen je eigen team. Ook in de overige hoofdstukken wordt deze indeling van case, tips en eigen praktijk gehanteerd.

Beperk de hoeveelheid onderhanden werk en maak het mogelijk dat teamleden werk naar zich toe trekken: Als het schrijven van een hoofdstuk klaar is maar de volgende stap is nog niet begonnen dan kan je dat niet zien. Binnen Growing Gardens splitsen ze daarom de kolom schrijven in bezig en klaar voor tekeningen. Pas als daadwerkelijk begonnen kan worden met het maken van een tekening voor het betreffende hoofdstuk verschuift het kaartje naar de kolom tekeningen (Pull). Ook wordt onderkend dat het onhandig is als men met teveel taken tegelijkertijd bezig is. Door het aantal taken waaraan je werkt te verkleinen kan de doorstroom groter worden. Men noemt dat de Work-In-Progress (WIP) Limit per processtap. Verder worden begrippen als cyclusduur, levertijd en faalratio behandeld.

Zorg voor doorstroom: Binnen Growing Gardens liep men tegen vertraging aan. Niet iedereen had evenveel tijd beschikbaar, ook het maken van tekeningen duurde veel langer dan gedacht. Door de stap redactie naar voren te halen was tijdwinst te behalen. Daarnaast kun je ook expliciet maken dat een taak geblokkeerd is zodat dat voor iedereen zichtbaar is dat er wat moet gebeuren. Ter ondersteuning worden hier verder het gebruik van een dagelijkse standupmeeting en het toepassen van buffers op het bord besproken.

Maak afspraken expliciet: Binnen Growing Gardens stagneerde het werk. Werkzaamheden aan het boek werden steeds naar achteren geschoven. Door expliciet af te spreken dat er altijd een persoon minimaal twee uur per dag aan het boek te laten werken kwam er weer beweging in. Dit werken aan andere activiteiten is ook op het bord visueel te maken door daarvoor een eigen baan te creëren (swimlane) en afspraken te maken hoeveel tijd/werk per baan besteed mag worden. Verder zijn er afspraken te maken over hoe om te gaan met spoedgevallen, wanneer is iets ‘klaar’ (Definition of Done) et cetera.

Verbeter samen: Growing Gardens had haar boek afgerond en men bleef een bord gebruiken voor hun dagelijkse werkzaamheden. Duidelijk was dat ook dit bord regelmatig aangepast zou moeten worden en men sprak af om een keer per maand de werkwijze te evalueren (retrospective).

In bijlagen krijgen we uitleg over Personal Kanban en het vliegtuigspel om het effect van de WIP te kunnen ervaren.

Conclusie: Een vlot leesbaar, handig praktijkboekje voor diegenen die nog geen kennis van Kanban hebben en willen weten wat het is of beter nog ermee aan de slag willen gaan.

Bestellen: Kanban in de praktijk

Review: Leading Teams – Setting the stage for great performances

leadingIf I see how agile teams perform you can ask yourself why is this the case, what is needed that these teams become much more effective? J. Richard Hackman wrote in 2002 the book Leading Teams – Setting the stage for great performances and this book still gives a lot of answers and directions how to look at those less effective agile teams.

The book is divided in three parts. In part I we get two examples of how senior leaders at two different airlines structured and supported teams of flight attendants. One airline achieved a great deal of control over flight attendant behavior, but at a considerable cost in motivation and creativity. The other airline achieved nearly the opposite outcomes. Throughout the book we will get a lot of references to these two teams and other examples too.

Part II is the core of the book and focusses on the conditions that foster team effectiveness reflected in products, services or decisions that are acceptable to the clients. That the team becomes more capable as a performing unit over time and that the individual members learn. The following five conditions must be put in place and stay there:

  • Having a real team
  • A compelling direction
  • An enabling team structure
  • A supportive organizational context
  • Expert team coaching

Part III Opportunities, discusses imperatives for leaders (and their execution skills) and how to think differently about teams within an operating environment (who decides? authority structure, who is responsible? work structure, who gains? reward structure, who learns? opportunity structure).

QRC (Leading teams, 180611) v1.0To download: QRC (Leading teams, 180611) v1.0

The five conditions:

A real team is the prerequisite for the other conditions. The task actually is appropriate for teamwork and it requires members to work together independently. It means establishing clear but moderately permeable membership boundaries. It means providing the team with substantial but clearly delimited authority for managing its work. And finally it means ensuring that the team will be reasonably stable over time as members carry out that work.

Providing a compelling direction that energizes, orients and engages teams is an important ingredient in setting the stage for great performances.

An enabling team structure is based on the design of the work that the team performs, the core norms of conduct that guide and constrain team behavior, and the composition of the team. Autonomy gives teams room to excel … but autonomous teams gone bad and can do real damage. Also virtual teams become more popular but it is much harder to create the previously mentioned conditions in virtual teams.

An unsupportive organizational context limit the performance of even a well-designed work team. The following three systems have particularly high leverage in supporting teamwork: the reward system (to provide recognition and reinforcement contingent on excellent team performance), the information system (to provide teams, at their own initiative whenever possible, the data and projections that members need to competently plan and execute their work) and the educational system (to make training and technical assistance available to work teams for any aspects of the work in which members are not already sufficiently knowledgeable or skilled).

The last condition, expert coaching, can significantly enhance team performance processes as managing member effort, selecting and implementing its task performance strategies and in utilizing members’ talents. What can coaches do and when can they do it to help a work team manage the three key performance processes efficiently and well.

Conclusion: A must read for (tribe) leaders, sponsors, (project and programme) managers and agile coaches. To be honest it’s not an easy read. There is a lot of text in the chapters and you get sometimes lost (maybe some white between paragraphs and the use of numbered sections would have helped).

To order: Leading Teams – Setting the stage for great performances

Recensie NR. 4 – 2018 Vakblad Projectmanagement


Dit weekend nummer 4 van het Vakblad Projectmanagement – voor projectmanagers, door projectmanagers uitgegeven door KWD Resultaatmanagement gelezen. Wederom een scala aan interessante artikelen en columns.

Het hoofdartikel (Remmelt van der Wal) beschrijft hoe de projectmanager weerstand bij projecten begrijpt, herkent en er op een adequate manier mee omgaat. We krijgen een overzicht van verschillende oorzaken van weerstand inclusief de dominante driver (ratio of emotie), een drie-stappen model: waarnemen (symptomen van weerstand), analyseren (per fase oorzaken van weerstand) en vertalen (aanpak weerstand). Ook wordt een eenvoudige vragenlijst geboden om de weerstand te kunnen doorgronden.

Een aantal andere artikelen die hiermee in verband gebracht kunnen worden, betreffen Een dilemma voor projectmanagers – En je moet kiezen (Saskia Giebels) waarin je voor de keuze wordt gezet of de relatie of het resultaat belangrijker is of zijn er win-win situaties te vinden? Een volgend artikel Hoe om te gaan met dilemma’s (Peter M. Storm) laat zien dat er meerdere wegen zijn om met een dilemma om te gaan. Hoe karakteriseer je die wegen en onder welke omstandigheden is een bepaalde weg wel of niet geschikt. En het artikel Help, ik moet snel besluiten (Remmelt van der Wal) beschrijft het dilemma van de tijd nemen om een op feiten gebaseerd besluit te kunnen nemen versus het snel nemen van een besluit.

We krijgen ook deel 1 van een artikelenreeks over agile contracten (ook in nr. 2 stond een artikel over agile contracten). Dit artikel Agile contracteren – Hoe doe je dat? (Neeltje van der Veeken, Lammert Vinke en Erik van Daalen) geeft, gezien vanuit de leverancier, een aantal handreikingen die het agile contracteringsproces ondersteunen en die agile contracten verbeteren (Nb. PRINCE2 Agile en SAFe bieden beiden ook een aantal handvatten ter ondersteuning bij het opstellen van agile contracten).

Tenslotte nog een artikel (Luuk Ketel) hoe KWD omgaat met het Professionaliseren van projectmanagement. (Ps. Ik zou verwijzen naar de ICB4 i.p.v. NCB3) en een artikel Snel of zuinig (Peter M. Storm) waarin tijd en middel gedreven projecten met elkaar worden vergeleken.

We vinden ook een oproep om mee te werken aan een onderzoek naar agile team performance. Is agile softwareontwikkeling vaak minimaal 30% duurder dan traditioneel ontwikkelen, maar levert wel beter geaccepteerde software op?

De drie columns zijn zoals we gewend zijn weer ‘food for thought’. Peter Storm geeft het vervolg op zijn vorige column de toegevoegde waarde van de projectmanager en licht zijn standpunt – het gaat om synergie – nader toe. Ben Berndt brengt een nieuw begrip over het voetlicht: fairagile op basis waarvan hij de beschrijving van agile leiderschap uitbreidt met je houden aan afspraken, leren, je durven uiten ook wanneer je een fout maakt, de groep betrekken, de mening van eenieder horen en geen vooringenomenheid tonen maar wel respect. Tenslotte vraagt John Hermarij in zijn column Over veranderaars zich af of hij door de bomen het bos nog wel ziet. Agile heeft niets met agile te maken en projectmanagement niets met projectmanagement! Schieten we nu ook niet enorm door met agile zoals we dat in het verleden met projectmanagement gedaan hebben?

Het laatste onderdeel betreft het boek van het kwartaal waar ik zelf de inhoud voor mag aanleveren, maar om mijn eigen recensie te recenseren gaat toch wat te ver, dat laat ik graag aan anderen over.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het een kwestie van abonneren. Zie: KWD Resultaatmanagement.

Recensie: Dit is agile – Van introductie tot implementatie

9789043025324-480x600Recentelijk heb ik een volwassenheidsnulmeting bij een financiële instelling uitgevoerd. Tijdens de interviews werd verwezen naar een, mij onbekend boek, ‘Dit is agile – Van introductie tot implementatie’, dat deze organisatie als leidraad gebruikt had bij het invoeren van agile. Uiteraard kon ik het niet laten om dit door Sander Hoogendoorn geschreven boek te recenseren.

Het boek beslaat tien hoofdstukken waarbij ik het in drie stukken heb opgedeeld.

In het eerste stuk, de eerste twee hoofdstukken, neemt de auteur ons mee in de wereld van niet werkende waterval projecten en hoe dat in een agile wereld zou verlopen. Wat zijn kenmerken van waterval projecten (aan de hand van Winston Royce’s whitepaper Managing the Development of Large Software Systems) en wat zijn de meest voorkomende problemen met waterval. In het tweede hoofdstuk krijgen we een beschrijving van agile. Wat betekenen de vier statements in het Agile Manifesto. Vervolgens gaat de auteur in op de kenmerken die een project agile maken en beschrijft agile in een notendop.

Het tweede deel omvat de kern van het boek en beschrijft in detail een aantal aspecten van agile:

  • Korte iteraties: de opbouw, het waarom en het nut van een vaste lengte voor de iteraties (heart beat).
  • Samenwerken in teams: kenmerken team: multidisciplinair, compact, meerdere teams, verantwoordelijk, zelfsturend, transparant, co-locatie? en meetings en technieken voor samenwerken: kick-off, daily stand-up, evaluatie, workshop, pair programming, side-by-side programming en pair testing.
  • Samenwerkende rollen: welke rollen? Elk project vraagt om: expertise, generaliserende specialisten, stabiliteit, balans en specialisten. De verantwoordelijkheden van klanten bij agile projecten worden belegd bij de projectsponsor, Product Owner (één, want meerdere product owners verwarren het team), gebruikers en domein experts. Het is het team dat het project uitvoert, de faciliterende projectmanager en de agile coach.
  • Agile requirements: welke eenheid van werk is de juiste, aan welke criteria moet zo’n eenheid voldoen (vgl. INVEST)? User Stories, Use Cases en Smart Use Cases (zie voor een toelichting onderaan deze post) worden beschreven als werkwijze om een requirement te beschrijven.
  • Schatten: schatten is van levensbelang voor projecten maar is heel moeilijk. De auteur geeft een veelvoud aan oorzaken waarom dit zo moeilijk is. Verder krijg je een uitleg wat het betekent als je in uren schat (absoluut) of in punten (relatief), hoe je de snelheid waarmee punten worden gerealiseerd kan meten en vaststellen (meten is weten).
  • Plannen: adaptief plannen, het gebruik van een project of product backlog en een iteratie backlog en het prioriteren. Verder komt het beheren van de backlog en het gebruik van dashboards, burn-down en burn-up charts.

Het laatste afsluitende deel pakt het implementeren van agile op aan de hand van verschillende licht- en middelgewicht aanpakken, zoals XP, Scrum, DSDM (nu AgilePM genoemd), Smart en Kanban en beschrijft de mogelijke hobbels en kuilen die overwonnen moeten worden. Denk hierbij aan: big up-front design of geen design, agile als excuus, dood door dogma, een groot project als pilot, re-architecting, one-size-fits-all agile, reverse enginering, death by planning, reviews, kind en badwater, monodisciplinaire teams, parttime agile en het handboek agile.

Conclusie. Het is al een wat gedateerd boek (eerste druk 2012) en dat verklaart m.i. waarom in het boek meer recentere agile aspecten niet of onderbelicht worden. Over het belang van kernwaarden, denk bijvoorbeeld aan de scrum waarden, wordt niet gesproken maar ook ontwikkelingen zoals DevOps en het schalen van agile en gebruik van scaling raamwerken komen niet bod. Verder jammer dat de auteur het belang van het agile principe: Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel niet beschrijft (wetende dat de Standish Group laat zien dat meer dan 60% van de opgeleverde functionaliteit niet of bijna nooit wordt gebruikt) en het gebruik van dit principe het succes van een project kan vergroten i.p.v. iteraties toevoegen om alle requirements op te leveren.

Neemt niet weg dat het boek een goed inzicht geeft hoe een agile software project kan werken en daarmee nog steeds de moeite van het lezen waard is.

Bestellen: Dit is agile – Van introductie tot implementatie

Mochten smart use cases onbekend zijn, zie hier een toelichting: