Een organisatie was al jaren bezig met een project om een oud systeem te vervangen door een nieuw systeem dat future proof moet zijn. Met meer dan 50 man werd er hard gewerkt. In de loop der tijd zijn er veel projectleden gewisseld, waaronder ook meerdere keren de projectmanager.De huidige projectmanager besloot om te voorkomen dat hem hetzelfde zou overkomen, dus koos hij een drastisch andere aanpak. Hij richtte het project zo dat het als het ware een nieuw project was. De startarchitectuur werd nieuw opgezet en een Scrum manier van werken werd gekozen. Bijgestaan door experts op dat gebied maakte hij een voorstel over de nieuwe manier van werken. Teams van maximaal 9 mensen werden vervolgens samengesteld die elk de verantwoording van een deel van het systeem kregen. Elk team kreeg een eigen Team Product Owner en Scrum Master. Daarnaast was er een Chief Product Owner die de formele interface met de business afdekte. De project manager bewaakte de afstemming met de (traditionele) stuurgroep en zorgde dat integratoren en beheerders op tijd aan boord waren.
Er werden sprints van twee weken afgesproken, waarin er een increment werd opgeleverd die goed genoeg was voor deployment. De resultaten werden elke sprint gedemonstreerd aan alle stakeholders. Dat bleek elke keer beter te gaan en iedereen was trots.
Wekelijks stemden de product owners samen met een technisch verantwoordelijke uit elk team af welke features er door welk team werden opgepakt in de komende sprints. Alle features stonden in een gezamenlijk product backlog. Overkoepelende technische belemmeringen werden in dit gremium besproken en resulteerden eventueel in backlog items. Planning poker kaarten werden gebruikt om de backlog te ordenen en in te schatten, zodat duidelijk werd wat de eerstkomende features zouden zijn om uitgewerkt te worden.
De kwaliteit werd steeds beter, omdat iedereen de scope van zijn deel kon overzien en kon inschatten wat de impact van zijn activiteiten zouden zijn. Het grote project werd een groot succes.
Wat kunnen we hiervan leren?
Scrum is ontworpen om te werken in teams tot maximaal 9 mensen. Zolang de scope van het werk binnen een team afgehandeld kan worden, kan Scrum dan ook heel goed werken. Door meerdere teams in te zetten en op elkaar af te stemmen, kan je toch grote projecten aan.
Bij veel organisaties is het een utopie om te denken dat de teams zelfstandig hun gang kunnen gaan (autonomie). Sterker nog, er is altijd een grotere scope, dus zal er afstemming nodig zijn. Daarom is het belangrijk om alignment tussen Business en IT te optimaliseren. Evenals de samenwerking tussen development en operations. In de bovenstaande case leerde de organisatie autonomie en alignment snel in balans te krijgen. Hier zijn overigens verschillende gestandaardiseerde aanpakken voor.
Standaard oplossing
Aangezien het alignment probleem niet uniek is, zijn er meerdere initiatieven om tot een standaard oplossing te komen. Zie bijvoorbeeld agilescaling.com voor een overzicht.
Bovenstaand plaatje geeft een overzicht van een agile framework op enterprise niveau (zie ook scaledagileframework.com). Dat kan als hulpmiddel gebruikt worden om de eigen organisatie op te spiegelen. In het framework is de rol van projectmanager niet aanwezig. Gelukkig zijn er wel rollen nodig waarbij projectmanagement skills hard nodig zijn, zoals de Release Train Engineer, Product Owner, Scrum/Agile Master en Epic Owner. Let wel; het framework is een hulpmiddel, geen doel.
Weerstand overwinnen
Om zover te komen is wel enige tijd nodig en zal enige weerstand overwonnen moeten worden. Zie het overzicht van Shore en Larsen. Er is geen eenduidige persoon die de schuld kan krijgen voor het falen, maar het is juist een gezamenlijk succes. De voetbaltrainer is dus niet degene die autonoom alles bepaald, maar hij is onderdeel van het systeem. Voor management voelt dat ongemakkelijk. Van command en control naar dienend leiderschap. Van werkgericht naar resultaatgericht.De meeste mensen die gewend zijn aan de nieuwe situatie willen niet meer terug. Dat geldt voor zowel de medewerkers uit de IT als de business, maar ook het management. Zelfs de meest sceptische mensen gaan snel om nadat ze de aanpak hebben uitgeprobeerd.