Agile delivery: een overzicht van de Agile delivery modellen

Bijgewerkt: feb 4





1. Introductie

De maatschappij, klantbehoeftes en -verwachtingen veranderen voortdurend. Kwaliteit- en veiligheidseisen worden strenger, wet- en regelgeving worden geharmoniseerd, en technologische ontwikkelingen volgen elkaar in rap tempo op. Tegelijkertijd worden de kwantiteit, snelheid en complexiteit van veranderingen steeds groter.


Overheden, onderwijsinstellingen, bedrijven en medewerkers zullen de komende jaren geconfronteerd worden met kleinschalige en grootschalige veranderingen en een omgeving waarin maatschappelijke, economische en technologische veranderingen leiden tot de intrede van nieuwe marktpartijen, nieuwe markt-productcombinaties, innovatieve diensten en verschuiving van bestaande machtsstructuren.


Dit vergt aanpassingsvermogen en vraagt om een sterke klant- en productfocus, flexibiliteit en lenigheid. Om te kunnen overleven dienen organisaties in staat te zijn om effectief en tijdig te reageren op veranderingen, kansen en bedreigingen binnen bestaande en toekomstige markten. In de praktijk blijkt dit vaak een uitdaging en is het voor organisaties lastig om blijvende veranderingen door te voeren. Traditionele programma- en projectmanagement technieken zoals MSP en PRINCE2 blijken niet altijd het gewenste resultaat op te leveren en voldoende uitkomst te bieden.

In reactie hierop zijn vanaf de jaren ‘90 verschillende agile change modellen ontwikkeld waaronder Rational Unified Proces (RUP), Scrum, Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). Dergelijke modellen en methodieken stellen organisaties in staat om tijdig, effectief en efficiënt veranderingen door te voeren door hun lenigheid te vergroten.


Veel organisaties zijn inmiddels overtuigd van het agile gedachtegoed en gestart met het werken volgens de agile en Scrum principes. Bekende voorbeelden zijn Spotify, Coolblue, ING, Eneco en bol.com waar meerdere scrumteams gezamenlijk werken aan de succesvolle introductie van nieuwe producten en diensten om steeds meer toegevoegde waarde te leveren aan hun klanten, stakeholders en eindgebruikers.


Voor veel organisaties is het een uitdaging om de agile principes toe te passen en geleidelijk de transitie te maken naar een volwassen agile organisatie. Daarnaast is het meestal een uitdaging om continu de volwassenheid en effectiviteit van de agile organisatie te verbeteren en met meerdere agile teams tegelijkertijd producten en diensten te ontwikkelen.

In dit artikel wordt een overzicht gegeven van de verschillende agile modellen en frameworks die organisaties kunnen gebruiken om op te schalen, met meerdere agile teams tegelijkertijd te werken en door te ontwikkelen naar een volwassen agile organisatie die in staat is om tijdig veranderingen te signaleren, door te voeren en zichzelf continu te verbeteren.


2. Het Agile Manifesto

In de jaren ‘90 werden organisaties en bedrijven steeds ICT-intensiever en steeds vaker geconfronteerd met technologische veranderingen, veeleisende klanten en een steeds korter wordende time-to-market van producten. Al snel bleek dat traditionele projectmanagement technieken onvoldoende flexibel waren om efficiënt en effectief proces- en systeemwijzigingen door te voeren.


In reactie hierop deden verschillende light-weigth development technieken hun intrede, waaronder Dynamic System Programming Method (DSDM), Extreme Programming (XP), Rapid Application Development (RAD), Feature-driven Development (FDD) en Rational Unified Proces (RUP). De methodieken waren gericht op het incrementeel en iteratief ontwikkelen van software op basis van de behoefte van de klant en hadden een sterke focus op continu verbeteren en kwaliteit.


In 2001 kwamen 17 software-pioniers bij elkaar om de verschillende light-weight software technieken te bespreken en te vergelijken. De uitkomst van de meet-up was het Agile Manifesto waarin de 12 uitgangspunten van agile werken zijn vastgelegd die organisaties kunnen gebruiken om hun lenigheid, flexibiliteit en aanpassingsvermogen te trainen en te vergroten.


1. Customer satisfaction by early and continuous delivery of valuable software

2. Welcome changing requirements, even in late development

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business, people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the principal measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10. Simplicity—the art of maximizing the amount of work not done—is essential

11. Best architectures, requirements, and designs emerge from self-organizing teams

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly


Samenvattend verkiest het Agile Manifesto individuen en interactie boven proces en tooling, werkende software boven documentatie, samenwerking met de klant boven contractonderhandelingen en het reageren op verandering in plaats van het volgen van een plan.


3. Single Team Scrum

Het Agile Manifesto heeft de deur geopend voor nieuwe delivery methoden om in een complexe omgeving veranderingen door te voeren, waaronder Scrum de meest toegepaste en gebruikte methode is. Bedrijven zoals Spotify, Coolblue, ING, Eneco en bol.com maken dankbaar gebruik van Scrum om hun producten en dienstverlening continu te verbeteren.


Scrum is in de jaren ‘90 bedacht door Ken Schwaber en Jeff Sutherland met als doel om op een efficiënte en effectieve manier software te ontwikkelen. De term Scrum is afkomstig uit de rugbywereld en is een proces framework dat gebruikt wordt om complexe producten en software te ontwikkelen in een continu veranderende omgeving.


Het framework is gebaseerd op teamwork. Het Scrum Team bestaat uit een Product Owner, Scrum Master en Development Team en is gezamenlijk verantwoordelijk voor het realiseren van werkende producten en software die voldoen aan de wensen van de klant. Om de kwaliteit van de producten en software te borgen stelt het team een Definition of Done (DoD) op. In de DoD beschrijft het team de eisen waaraan producten en software moeten voldoen voordat ze in gebruik kunnen worden genomen. Hierbij kan gedacht worden aan de uitvoering van testwerkzaamheden, het documenteren van functionaliteiten en het voldoen aan interne security richtlijnen van de organisatie.


Het Scrum Team is zelf-organiserend, werkt iteratief, incrementeel en levert volgens een vast ritme, de sprint, een werkend product en werkende software op. De sprint is fixed en mag niet meer dan maximaal 4 weken duren. Transparantie, observeren en aanpassen vormen tijdens de sprint de kernwaarden van het team.


Binnen het Scrum Team is de Product Owner verantwoordelijk voor het inventariseren en prioriteren van de te realiseren producten en wijzigingen. De producten en wijzigingen worden centraal vastgelegd op een prioriteitenlijst de Product Backlog genaamd. In overleg met de omgeving en betrokken stakeholders bepaalt de Product Owner in welke volgorde de producten en wijzigingen door het team worden opgepakt. De Scrum Master ondersteunt de Product Owner in zijn rol en is verantwoordelijk voor het wegnemen van issues en het ondersteunen en coachen van het team.


Aan het begin van elke sprint vindt er een Sprint Planning plaats. In dit overleg worden de richting en focus van de sprint bepaald en stelt het team een sprintdoel op. Daarnaast wordt de lijst met geprioriteerde producten en wijzigingen besproken en bepaald wat het team gaat oppakken in de sprint. Vervolgens wordt besproken hoe de wijzigingen worden opgepakt.

De uitkomst van dit overleg is de Sprint Backlog: een korte lijst met geprioriteerde wijzigingen en taken op basis waarvan het team start met de realisatie van de producten en wijzigingen. De Sprint Backlog is eigendom van het Development Team en kan tijdens de sprint niet gewijzigd worden door de Product Owner.

Gedurende de sprint wordt dagelijks de voortgang besproken in een Daily Scrum aan de hand van drie vragen:


1. Wat heb je gister gedaan?;

2.Wat ga je vandaag doen?;

3. Welke issues heb je?


Aan het eind van elke sprint worden tijdens de Sprint Review de producten en wijzigingen getoond aan de klant, stakeholders en eindgebruikers, en wordt de sprint afgesloten met een Sprint Retrospective. In dit overleg wordt de sprint door het team geëvalueerd en worden verbeterpunten benoemd die worden meegenomen in de volgende sprint. Op deze wijze kan het team zich continu verbeteren.


4. Multiple Team Scrum

Het agile gedachtengoed wordt inmiddels door veel organisaties omarmd en Scrum wordt in veel organisaties succesvol toegepast. Het op korte termijn starten met agile en Scrum blijkt in de praktijk voor organisaties relatief snel veel voordelen op te leveren ten opzichte van traditionele projectmanagement- en delivery technieken, waaronder het gericht en regelmatig opleveren van werkende software.


Het succes van Scrum heeft geleid tot een toename van het aantal Scrum Teams binnen tal van organisaties en de behoefte om tegelijkertijd met meerdere Scrum Teams producten en software te ontwikkelen. In de praktijk is echter gebleken dat het niet zonder meer mogelijk is om op te schalen en de uitgangspunten van het Agile Manifesto tezamen met de spelregels van Scrum niet altijd voldoende uitkomst bieden.


In reactie hierop zijn de afgelopen jaren in korte tijd een aantal agile frameworks ontwikkeld waaronder Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). De frameworks zijn bedoeld om organisaties handvatten te bieden voor het opschalen en doorontwikkelen naar een volwassen agile organisatie die in staat is om met meerdere teams tegelijkertijd agile te kunnen werken en producten te ontwikkelen.


De modellen zijn complex, omvangrijk en de uitdaging voor organisaties is om het juiste model of gedeeltes van de modellen geleidelijk te implementeren.


4.1 Nexus


Het Nexus Framework is afkomstig van www.scrum.org


Het Nexus framework is het nieuwe wapenfeit van Ken Schwaber en een reactie op de verschillende agile frameworks die de afgelopen jaren zijn ontwikkeld. Het raamwerk, exoskeleton, van Nexus is bedoeld om met 3-9 Scrum Teams op basis van één Product Backlog te werken aan een geïntegreerd product.


De agile en Scrum principes vormen de basis van het framework waarbij de focus ligt op het verbeteren van de onderlinge samenwerking tussen de teams en de integratie van de te realiseren producten en oplossingen. Om dit te bewerkstelligen wordt naast de scrum teams een apart Scrum Team ingericht: het Nexus Integration Team.


Het Nexus Integration Team bestaat dus uit een Product Owner, Scrum Master en leden afkomstig uit de overige Scrum Teams. De Product Owner is verantwoordelijk voor het vaststellen en prioriteren van de Backlog en de Scrum Master helpt de Scrum Teams de Nexus principes correct toe te passen. De teamleden van het Nexus team kunnen tevens onderdeel uitmaken van en participeren in andere Scrum Teams. Het team werkt volgens een vast ritme en is verantwoordelijk voor het afstemmen en mitigeren van de onderlinge afhankelijkheden tussen de teams en het integreren van de eindoplossing.


De sprintvergaderingen van het Nexus team zijn leidend en worden zoveel mogelijk geïntegreerd in de vergaderingen van de afzonderlijke Scrum Teams. Vertegenwoordigers vanuit de overige Scrum Teams worden uitgenodigd om deel te nemen aan het Nexus teamoverleg.


Het samenspel van het Nexus team en de overige Scrum Teams start met een Nexus Sprint Planning waarin het doel van de sprint wordt vastgesteld en wordt bepaald welke producten, oplossingen en wijzigingen worden opgepakt. De Backlog items vormen input voor de Sprint Planning van de individuele teams. Daarnaast vindt er een dagelijks overleg, de Nexus Daily Scrum, plaats waarin de onderlinge afhankelijkheden en integratie issues worden geïdentificeerd die worden besproken in de Daily Scrums van de overige teams.


Aan het eind van elke sprint wordt een Nexus Sprint Review georganiseerd waarin het geïntegreerde product getoond wordt aan de omgeving en volgt een Nexus en Sprint Retrospective. In de Retrospective wordt de sprint geëvalueerd en worden verbeteracties vastgesteld.


4.2 Large Scale Scrum (LeSS)



Het LeSS Framework is afkomstig van www.less.works.


Het LeSS framework is bedacht door Craig Larman en Bas Vodde en is bedoeld voor organisaties die met meerdere  teams tegelijk willen scrummen. Inmiddels hebben onder andere BMW, Thales, Port of Rotterdam en Ericsson het framework geadopteerd.


Het framework heeft een sterke klant- en productfocus, omarmt lean- en systems thinking en doet nadrukkelijk afstand van tayloristische opvattingen, organogrammen en het denken in lokale optimalisatie. Onderstaand een overzicht van de belangrijkste principes.


1. Large-scale scrum is scrum – Multiple team Scrum versus multiple Scrum Teams

2. Customer Centric – Focus op klant en klantbehoefte vormt basis voor productontwikkeling

3. Whole product focus – Focus op product en toegevoegde waarde voor de klant

4. Lean Thinking – Creëer flow, vermijd rijen en verwijder de 7 verspillingen

5. System Thinking – Denk in systemen in plaats van oorzaak gevolg

6. Emperical proces control – Inspecteer, observeer en pas aan op basis van bevindingen

7. Queing theory – Reduceer en beperk rijen, work in progress, multi-tasking en variatie

8. Transparancy – Creëer transparantie en geef inzicht in de voortgang en complexiteit van werkzaamheden

9. More with LeSS – Bouw een agile organisatie bottom-up en niet top-down met behulp van management

10. Continuous Improvement – Verbeter continu het proces van product delivery


LeSS is gebaseerd op multiple team scrum en gaat in tegenstelling tot het Scaled Agile Framework (SAFe) uit van één groot Scrum Team, bestaande uit meerdere teams die gezamenlijk producten realiseren op basis van één centrale Product Backlog. SAFe daarentegen gaat uit van een agile team dat bestaat uit meerdere afzonderlijke Scrum Teams met elk een eigen Product Owner en Product Backlog. Binnen het framework wordt een onderscheid gemaakt tussen LeSS (< 9 teams) en LeSS Huge (> 9 teams).


Het LeSS Scrum Team bestaat uit zelforganiserende cross-functional feature teams. Feature teams zijn multidisciplinaire teams die in staat zijn om ketenwijzigingen en component overstijgende producten te ontwikkelen. Het team beschikt over één productowner en meerdere Scrum Masters, waarbij de Scrum Masters verantwoordelijk zijn voor de LeSS adoption van de organisatie en de ondersteuning van de teams. In de praktijk vervult een Scrum Master vaak voor drie Scrum Teams tegelijk de rol van Scrum Master.


In het geval van LeSS Huge worden de teams vaak gekoppeld aan een area. Een area is een cluster van functionaliteiten of een gedeelte van een product dat seperaat waarde toevoegt voor de klant. De indeling in areas wordt gebruikt om focus aan te brengen in de productontwikkeling. Een area staat niet gelijk aan een SAFe valuestream, maar bewerkstelligt hetzelfde doel. Ter ondersteuning van de Produc