Tag Archives: Agile

AgileSHIFT an overarching agile framework

AgileSHIFTcoverMany organizations are struggling to implement agile delivery frameworks to increase their level of agility, and many organizations fail. One of the reasons is the culture clash between a traditional organization and the agile culture. Only implementing agile delivery frameworks in e.g. your IT department is not enough.

AXELOS has developed a framework (see attached Quick Reference Card/QRC AgileSHIFT) 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. Now called, in this framework, Run the Organization and Change the Organization. Everyone is a change-enabler, encouraged and empowered to make change happen.

AgileSHIFT (QRC, 181012) v1.0To download: AgileSHIFT (QRC, 181012) v1.0

The AgileSHIFT framework explains why we need enterprise agility. There is an increasing pace of change (VUCA: volatility, Uncertainty, Complexity, Ambiguity), the role of technology (from technology supported, via technology enabled towards technology centric), the delta between the current and target state of your organization and disruptive influences by enablers (as the gig economy, remote working, cloud storage and online presence), inefficient markets and black swan events.

To accommodate what we have to do the AgileSHIFT framework defines enterprise agility, principles and practices. Enterprise agility is the ability of an organization to move and adapt quickly in response to shifting customer and market needs. The five principles are: Change will happen so embrace the status quo, challenge the status quo, develop an environment where everybody adds value, focus on the co-creation of customer value and tailor your approach. The five practices are: Plan to be flexible and adaptable, engage stakeholders, build collaborative teams, focus on the co-creation of customer value and measure value.

The how (corresponds with the AgileSHIFT delivery approach) is expressed in the AgileSHIFT framework by the roles, the AgileSHIFT workflow and an iteration and by tools and techniques. There are three roles: the AgileSHIFT team, sponsor and coach. A simple iteration approach is explained but depending on the situation you have to choose the right approach. Tools and techniques include: customer stories and epics, relative estimating and story points, AgileSHIFT task list and roadmap, swarm, kanban, canvasses and agendas. For the last two there will downloads available.

To show your understanding of AgileSHIFT, foundation and practitioner certification will be possible.

In the next picture, I have positioned AgileSHIFT.Grasp session (Scaling Agile, 180526) v1.1

Advertisements

The P3M3 maturity model with an agile extension (P4M3)

Introduction

As HWP Consulting, we introduced in 2014 a Project Success Scan and we collected data points of more than 200 companies (see Project Success Scan). In 2017 we became an accredited AXELOS Consulting Partner for the P3M3 Maturity Model.

Many organizations are using traditional project management as well as agile delivery frameworks and in my opinion it’s not that black or white, you have to choose, depending on the change initiative, the right framework to make the change happen and that can contain traditional as well as agile flavors. When we look at the current P3M3 v3 model, I have problems to incorporate the agile way of working. E.g. how to cope with a permanent agile team?

In this article, I am proposing an extension of the P3M3 model to incorporate this agile way of working and I am looking forward to your feedback. At the end of the article there is a link to a very small questionnaire, which I hope you can complete.

Before I go into my proposal a short overview of the existing P3M3.

P3M3

At this moment AXELOS offers P3M3 version 3.

Dia067

To download: P3M3 V3 (QRC, 171205) v1.0

P3M3 version 3 contains three models, reflecting portfolio (PfM3), Programme (PgM3) and Project (PjM3) Management. We see seven perspectives applicable within each of the models:

  • Organizational Governance: Why we want to do what projects / programmes / portfolios
  • Management Control: Verifying that projects / programmes / portfolios progress as planned and within their authority
  • Benefits Management: Ensuring / proving our projects / programmes / portfolios are / were worthwhile doing in the eyes of the stakeholders
  • Financial Management: Getting and managing the money to do it
  • Stakeholder Management: Involving those who care and those who need to care
  • Risk Management: Managing uncertainty
  • Resource Management: Making sure we have the capacity to deliver

P3M3 can be used independently of your chosen project, programme or portfolio management method or framework.

The model is based on the five known maturity levels:

  • Level 1 : Awareness of process
  • Level 2 : Repeatable process
  • Level 3 : Defined process
  • Level 4 : Managed process
  • Level 5 : Optimized process

When answering questions you have the option to answer level 0: Unaware too.

New, in comparison with the previous version, are the max. 13 threads: Asset Management, Assurance, Behaviors, Commercial Commissioner, Commercial Deliverer, Information and Knowledge Management, Infrastructure and Tools, Model Integration, Organization, Planning, Process, Standards and Techniques. The most detailed questions are now the diagnostic attribute statements.

You can perform, by yourself, a Standard self-assessment or Enhanced self-assessment (subscription). The latter offers you on top of the standard self-assessment a maturity tracker, detailed results and a benchmark.

It is also possible, via an accredited consulting organization (e.g. HWP Consulting) to perform a full accreditation assessment resulting in your maturity level based on P3M3 or a full further diagnostic assessment including an improvement plan to achieve the next maturity level.

Agile extension

 Additional model: Permanent agile team

If you are using permanent agile teams (e.g. in your Software development department) the model will not help you to measure the maturity of these teams. Within the P3M3 model we have PfM3 for portfolio management (permanent organization), PgM3 for programme management (temporary organization) and PjM3 for project management (temporary organization). I added a fourth model PtM3 for Permanent agile teams.

P4M3 basisAs the three other models, this PtM3 model uses the same five levels. These five levels can be described as follows:

Dia126

In the current P3M3 model we have seven perspectives. If your organization is using an agile way of working this will have consequences for your assessment of portfolio, programme and project management too. To cover this, I added an eighth perspective: Agility.

Additional perspective: Agility

Dia127

At portfolio level your strategy must show agility, at programme level you must have agility within the strategic objective, at project level you must have agility at the project product level and within the permanent agile team you must have agility at product level (satisfy customer, prioritization, maximizing the amount of work not done).

The three tables provide an overview of the high level descriptions for the Agilty perspective in the three Management Maturity Models.

Dia128Dia129

Dia130

The next table provides an overview of the high level descriptions for all eight perspectives in the new Permanent agile team Maturity Model.

PtM3To download: PtM3

Additional thread: Product

P3M3 V3 (Intro training 180616) v1.1To download: P4M3 overview

To emphasize the importance of the product, I added an additional thread: Product. In this thread the maturity of the following attributes will be measured (source: Agile enterprise agility): Shippable, Cycle time, Product vision, Stories INVEST compliant, Definition of Ready (DoR), Definition of done (DoD), Story size, Backlog refinement, Slicing, and WIP.

Dia141

To download: Thread product

Closure

HWP Consulting, as an Accredited P3M3 Consulting Organization can help you in performing a P3M3 full accreditation assessment or full further diagnostic assessment including an improvement plan based on your own objectives. To avoid bias we can facilitate your self-assessment as well. For the agile extension we developed the 3 reflective statements (organization, process, performance) for each of the eight perspectives within the Permanent agile team Maturity Model too. Feel free to get in contact.

Please fill in this simple questionnaire to help me to improve this P3M3 Agile extension.

Recensie: Het tijdperk van agile

9789492790149-480x600Stephen Denning schreef een zeer interessant en inspirerend boek Het tijdperk van agile – Hoe slimme bedrijven hun manier van werken transformeren. Geen boek over agile frameworks, maar wat het werkelijk inhoudt om als organisatie meer wendbaar te worden.

Het boek bestaat uit twee delen. Het eerste deel concentreert zich op agile management, wetten, een case study om agile op grote schaal te implementeren (Microsoft), en te evolueren naar strategische wendbaarheid en de organisatiecultuur te veranderen. Het tweede deel plaatst verschillende managementvalkuilen in de schijnwerpers. Bijv. aandeelhouderswaarde, inkoop van eigen aandelen, kostengerichte benadering en de valkuil van een achteromkijkende strategie.

Organisaties die wendbaarheid omarmd hebben, onderschrijven de volgende wetten:

  • De wet van het kleine team.“Het is de gedachte dat grote, ingewikkelde problemen in eenVUCA (volatility, uncertainty, complexity and ambiguity) wereld zo veel mogelijk moeten worden opgesplitst om te worden toevertrouwd aan kleine, autonome, multifunctionele teams die iteratief en in korte cycli werken en daardoor in een flow komen met snelle feedback van klanten en eindgebruikers.”
  • De wet van de klant.“vereist dus dat de cultuur, interne processen en warden voortdurend ondergeschikt worden gemaakt aan en gevormd worden door de noodzaak om waarde te leveren aan de klant.”
  • De wet van het netwerk.een netwerk is een groep of system van onderling verbonden mensen of zaken. Een organisatorisch netwerk bestaat uit teams die interactie hebben en samenwerken met andere teams met dezelfde mate van connectiviteit, interactie en passie die kleine teams kenmerken. Zo’n netwerk is gebaseerd op de Wet van het kleine team, maar er is meer voor nodig. Elk team moet verder kijken dan zijn eigen doelstellingen en zijn werk zien als onderdeel van de grotere missie van het collectief.

Dia1Veel gebruikte technieken van kleine agile teams:

  • Ze werken met kleine batches
  • Kleine, multidisciplinaire teams
  • Onderhanden werk limiteren
  • Autonome teams
  • De klus klaren
  • Werken zonder onderbreking
  • Dagelijkse stand-ups
  • Radicale transparantie
  • Feedback van de klant in elke cyclus
  • Retrospectieve evaluatie.

Dia2Methoden van de wet van de klant:

  • Doelgroep
  • Experimenteer voortdurend
  • Werk samen met start-ups
  • Maak je product kneedbaar
  • Focus
  • Innoveer stapsgewijs
  • Evalueer
  • Je moet bereid zijn om mensen teleur te stellen
  • Lever sneller waarde
  • Houd rekening met individuele wensen.

Dia3Enkele hypotheses over wat er nodig is om netwerken goed te laten werken:

  • Het netwerk heeft een meeslepend doel
  • Het netwerk bestaat uit kleine groepen
  • De groepen zijn daadgericht
  • Het netwerk is de som van de kleine groepen
  • Het juridisch kader van het netwerk blijft op de achtergrond.

De Microsoft-casestudy laat zien hoe Microsoft agile op grote schaal implementeert en biedt nuttige elementen die nodig zijn om als organisatie op grote schaal wendbaarder te worden:

  • Vind het juiste evenwicht tussen overeenstemming en autonomie (Als er teveel controle wordt uitgeoefend, wordt er niets gedaan. Maar te weinig controle leidt tot chaos)
  • Krijg de rol van agile manager onder de knie
  • Handel onderlinge afhankelijkheden af op teamniveau
  • Zorg voor continue integratie
  • Laat de technische problemen zich niet opstapelen
  • Verwelkom DevOps en continue integratie
  • Houd de vooruitgang voortdurend bij
  • Luister naar wat klanten willen, maar maak wat ze nodig hebben
  • Geen inmenging van boven
  • Gebruik zelfvormende teams om eigenaarschap te stimuleren
  • Onderken dat het team het product is
  • Werk vanaf het begin aan kwaliteit
  • Ga zorgvuldig om met training en coaching
  • Zorg voor steun van de top.

De laatste twee hoofdstukken van het eerste deel beschrijven wat het betekent om over te schakelen van operationele naar strategische agility. Innovaties genereren die volledig nieuwe markten creëren door niet-klanten klanten te maken. Strategische behendigheid is de volgende grens van agile management. Begin met markt creërende waarde propositie op basis van vier fundamentele componenten: behoefte, aanpak, kostenbatenanalyse en concurrentie.

In het tweede deel kijkt de auteur naar organisaties die zich voornamelijk richten op het verdedigen van de status-quo en het beschermen van hun bestaande bedrijf. Ze evolueren niet naar operationele en strategische agility. Ze worden geblokkeerd door valkuilen van aandeelhouderswaarde, inkoop van eigen aandelen, kostengerichte benadering en een achteromkijkende strategie.

  • De valkuil van aandeelhouderswaarde. Het maximaliseren van de aandeelhouderswaarde betekent top-down command-en-control-management met als gevolg gedemotiveerde medewerkers, minder betrokkenheid, minder innovatie, …
  • De valkuil van het inkopen van aandelen. Winst maken (‘bedrijfscocaïne’), zelfs als het stelselmatig zijn eigen verdiencapaciteit vernietigt door middelen aan de aandeelhouders over te dragen zodat er onvoldoende middelen zijn om investeringen en innovatie te ondersteunen
  • De valkuil van de kostengerichte benadering. Verlaging van kosten kan leiden tot permanent verlies van expertise. Klantwaarde realiseren tegen lagere kosten is veel belangrijker
  • De valkuil van een achteromkijkende strategie. Deze strategieën zijn achteraf 100 procent accuraat, maar voor voorspellingen moet je ook kennis hebben van het onverwachte en het onvoorziene.

Het boek eindigt met de epiloog waarin de geschiedenis van gouden eeuwen en nucleaire winters, beginnend in 1790 met de kanalen, via spoorwegen, staal en massaproductie en eindigend in het tijdperk van computers en communicatie, wordt besproken. We krijgen een overzicht van verschillende rollen (van CEO’s tot toonaangevende denkers (thought leaders) en de media en nog veel meer) en wat ze moeten doen om organisaties wendbaarder te laten functioneren.

Conclusie: Fantastische casestudy’s om te begrijpen waarom we de drie wetten van de klant, het kleine team en het netwerk nodig hebben. Een must voor diegenen die een verandering naar meer wendbaarheid willen maken.

In lijn met het agile manifest en het samenvatten van het tweede deel van het boek zou ik zeggen:

  • Klantwaarde boven aandeelhouderswaarde
  • Klantwaarde boven organisatie efficiency
  • Waarde gedreven perspectief boven kostenoriëntatie

Bestellen: Het tijdperk van agile

A new kid on the agile block: Agile Digital Services (AgileDS)

Last week I followed an APMG ATO / trainer briefing regarding Agile digital Services.

This agile framework, developed by Agile Business Consortium, focusses on building and delivery of digital services. The AgileDS framework will help organizations to develop a consistent agile approach, a common language and a skilled workforce regarding digital services. It uses the same terminology as other agile frameworks. It is based on the GDS lifecycle (Government Digital Service, UK), themes and responsibilities have evolved from the roles and responsibilities in AgilePM and its agile practices come from other existing frameworks (e.g. WSJF from SAFe).

AgileDS (QRC, 180718) v1.0To create this quick reference Card I used the handbook that is available for feedback (beta phase). To download the QRC: AgileDS (QRC, 180718) v1.0

Generic and governance principles

The ten generic principles are:

  1. Start with needs
  2. Do less
  3. Design with data
  4. Do the hard work to make it simple
  5. Then iterate again
  6. This is for everyone
  7. Understand context
  8. Build digital services, not websites
  9. Be consistent, not uniform
  10. Make things open: it makes things better

The six governance principles are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself (GEMBA)
  5. Only do it if it adds value
  6. Trust and verify

Service Lifecycle

There are five phases discovery, alpha, beta (privat and public), life and service retirement which can be tailored to meet the needs of different organizations. The aim is to deliver  incrementally within each phase with a significant delivery at the end of a phase.

Products

The following products are described (purpose, when created, updated, needed): Terms of Reference, Business Case, Backlog, Roadmap, Service Architecture Definition, Development Approach Definition, Management Approach Definition, Delivery Plan, Service Lifecycle Transition Report.

Themes and responsibilities

AgileDS defines a set of responsibilities that are collected into simple themes. All responsibilities must be covered and it’s vital that the team acts as a collaborative and effective whole, with clarity about individual responsibilities. Within the Service Delivery Team the following responsibilities must be covered: service ownership, delivery management, product management, business analysis, service development, user research, technical design, service assurance, service design and service deployment.

When needed specialist guidance should be available: assisted digital guidance, accessibility guidance, performance analysis and agile coaching.

Within Steering and Leadership we encounter the following responsibilities: business sponsorship, service ownership, technical leadership and change coordination (in case of multiple service delivery teams).

Techniques

Several techniques are explained: Kano method, relative prioritization, stack ranking, MoSCow prioritization, WSJF, iterative development and incremental delivery, MVP and MMP, requirements and user stories, user research and personas, timeboxes and sprints.

Conclusion

Where AgilePM is there for the delivery of a product or service (temporary agile project, using a project lifcycle), AgileDS is there for the delivery and the continuous operations, support and maintenance of that service (permanent agile delivery team, using the product/service lifecycle). There will be a foundation and a practitioner certification in line with other APMG certifications.

In the next picture I have positioned AgileDS.Grasp session (Scaling Agile, 180526) v1.1

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

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

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: