SCRUM maar dan wel beheersbaar graag

Samenvatting

Scrum neemt een grote vlucht en dat is niet voor niets. Een groot voordeel is dat personen uit de business direct betrokken zijn bij de ontwikkeling van de geautomatiseerde ondersteuning. Op deze wijze is er een grotere zekerheid dat de functionaliteit werkt zoals beoogd “fit for purpose” en worden er sneller zichtbare resultaten geboekt dan bij watervaltrajecten.

Toch leidt scrum vooral bij de invoering hiervan in grote organisaties tot “koudwatervrees”, want onbekend maakt onbemind. Daarnaast is het van belang dat het scrum proces nauw aansluit bij planningsprocessen die de organisatie gewend is toe te passen. In de praktijk levert dit frictie op, want scrum stelt een ander soort eisen aan de omgeving dan waterval(achtige) trajecten die veel meer top down zijn georganiseerd.

Het goede nieuws is dat de standaard raamwerken die worden gebruikt voor de voortbrenging van ICT steeds beter op elkaar aansluiten om op basis van scrum te gaan werken. In onderstaande toelichting wordt dit nader uiteen gezet.

Implementatie van scrum vraagt echter aanpassing van het tactische planningsproces, waarbij er zal worden gepland in kleinere brokstukken. Ook heeft scrum een grote impact op de organisatiecultuur, kennis en gewenste houding van medewerkers van uw organisatie. Vertonen de medewerkers van uw organisatie nu nog te veel passief gedrag? Dan is nu het moment aangebroken om uit de luie stoel te komen en (pro)actief gedrag te gaan vertonen. Kern van deze benadering is dat opdrachtgever en opdrachtnemer samen de schouders er onder zetten op basis van een intensieve samenwerking.

Toelichting

Je zou kunnen stellen dat indien een organisatie volgens scrum gaat ontwikkelen, de aanpalende architectuur en planningsprocessen ook vanuit een scrum mindset dienen te gaan werken. Dit kan ook consequenties hebben voor de organisatiecultuur en de taakopvatting van functionarissen in de voortbrenging. Ik heb al eerder een artikel gewijd aan de impact van scrum op het gedrag en de vaardigheden van de “command & control” architect.

Een extra uitdaging vormen de Europese Aanbestedingen. Daar wordt door de regelgever geëist dat het doel duidelijk wordt omschreven. Het gaandeweg definiëren van het einddoel is daarmee problematisch. Wellicht dat de concurrentiegerichte dialoog in dit verband meer openingen biedt om gezamenlijk de schouders er onder te zetten en gezamenlijk het risico te delen. Dit is namelijk de kern van scrum, de opdrachtgever en opdrachtnemer committeren zich samen aan een eindresultaat dat gaandeweg vorm krijgt tijdens het scrumproces.

Ook zie je in de praktijk dat de publieke sector minder genegen is om een scrumtraject in te gaan dan de private sector. Daar staat men meer open voor samenwerking , om zo het eigen bedrijfsbelang in te brengen. Ook is het voor de publieke sector vaak moeilijk om zo snel besluiten te nemen als scrum vraagt.

“Koudwatervrees” bij business vertegenwoordigers

Een belangrijke oorzaak van de frictie in de organisatie bij de invoering van scrum is dat business mensen geen absolute zekerheid hebben dat de gevraagde functionaliteit binnen de gestelde termijn zal zijn gerealiseerd. Zeker in een context waaraan voldoen aan wet- en regelgeving een vereiste is, kan dit als een probleem worden ervaren. Natuurlijk stelt de Scrum Product Owner de prioriteiten, maar daarmee is er op het bestuurlijke niveau nog geen absolute zekerheid dat bijtijds en volledig aan wet- en regelgeving kan worden voldaan.

Een manier om de hierboven beschreven “koudwatervrees” te adresseren is het aanbrengen van een tactisch planningsproces, dat wordt gevoed met informatie uit het architectuur management proces. Het doet een beetje denken aan de techniek “Capability Based Planning” die bekend is vanuit TOGAF. Als trendy term poneer ik hiervoor “Agile Capability Based Planning” (ACBP). Deze term is op het moment van schrijven van dit artikel nog niet te vinden op internet, dus enige toelichting is hier op zijn plaats.

Voor de positionering van ACBP denk ik voor de eenvoud aan een drielagenmodel, dat erg lijkt op de indeling van het Scaled Agile Framework (SAFe)

• Laag 1 (Portfolio): De architectuur context en doelstellingen van de verandering (denk aan een Project Start Architectuur (PSA) op hoofdlijnen in presentatievorm). Dus geen dikke onleesbare documenten maar een duidelijk inzicht in de informatieketens en een uitwerking van de Enterprise Architectuur;
• Laag 2 (Program): Agile Capability Based Planning (zie een verdere uitleg hieronder);
• Laag 3 (Teams): Het standaard Scrum Proces.

Agile Capability Based Planning (ACBP), nadere toelichting van laag 2

Kern van dit proces is een geprioriteerde lijst met “Business Capability Increments” (BCI) die door alle betrokken stakeholders worden gedeeld en begrepen. Een BCI is hierbij gedefinieerd als de concrete verbetering in de mogelijkheden vanuit het perspectief van de business vertegenwoordiger. De traditionele projectmanager herkent hier wellicht een projectfasering in, echter de BCI’s zijn verfijnder op basis van inzichten uit het architectuurproces.

Iedere BCI kent hierbij in begrijpelijke termen minimaal de volgende zaken:

• Een heldere beschrijving van de verbeterstap inclusief ondersteunende praatplaten en verbindingen met de omgeving. Deze zijn relevant voor de beheersing van de informatieketens. Ik spreek in dit verband niet over koppelvlakken maar  ontkoppelvlakken.
• Een beschrijving en inschatting van de business voordelen van de verbeterstap. Opmerking: inTOGAF wordt in fase F per project een kosten-batenanalyse gedaan. Dit heeft als nadeel dat een project op zich soms een negatieve business case heeft, maar het is randvoorwaardelijk voor het realiseren van andere projecten en daarom toch noodzakelijk. Wanneer je in plaats van een business case per project een business case per BCI maakt, ben je van dat probleem af.
• Een schatting van de kosten en een beschrijving van de benodigde inspanning, COPAFIJTH breed.
• Een inschatting van de complexiteit van de gerelateerde werkprocessen (moeilijk / makkelijk te automatiseren, moeilijk / makkelijk handmatig uit te voeren).
• Een beschrijving en inschatting van de kansen die mogelijk kunnen worden benut indien deze verbetering tot stand wordt gebracht.
• Een beschrijving en inschatting van de risico’s die deze veranderstap met zich meebrengt. Zeker omdat de wereld steeds verder aan het digitaliseren is moeten we veranderingen tegemoet treden met een gezonde dosis “bon risk appetite”.

Deze benadering stelt echter wel eisen aan de wendbaarheid van de architectuur van de informatievoorziening en van de architecten(!). Op deze wijze gaan wendbaarheid en (bijvoorbeeld) cyber security hand in hand. Eigenaarschap, beheer en afstemming is geborgd in relatie met het project- en portfoliomanagement.

Hierbij is het belangrijk dat de omslag wordt gemaakt van watervalachtig werken naar agile werken en in de tussentijd dienen beide manieren van werken te worden gecombineerd. Zie in dit verband de relatie met het artikel “Uitdagingen van hybride portfolio management” gepubliceerd in het IPMA Projectie Magazine, geschreven door Lia de Zoete en Yves Vervloesem.

De relatie met het Scaled Agile Framework (SAFe)

Naast de overeenkomst van de drie lagen zijn er nog andere overeenkomsten met SAFe te noemen:

• De BCI’s zijn het beste te vergelijken met Business Epics en Architectural Epics die zich op het top niveau (portfolio) van SAFe bevinden;
• SAFe stelt dat je voor elke epic (Business en Architectural) een Epic Value Statement maakt om het belang van de epic en wat je ermee wilt breed onder de aandacht te brengen;
• Voor elke (geselecteerde) epic stel je vervolgens, na een analyse, een light weight business case op, met daarin de uitkomsten van de analyse, een meer gedetailleerde beschrijving,  de succesfactoren, risico's, schattingen voor implementatie, kostenplaatjes, impact voor een programma (op het volgende lagere niveau in SAFe);   
• Op het tweede niveau (programme) van SAFe worden de epics met uitgewerkte business cases gecombineerd en vanuit een program backlog geprioriteerd en opgepakt;
• Vanuit een release planning worden de program backlog items (de zogenaamde features) geselecteerd, die middels een Agile Release Train mechanisme worden bestuurd;
• Op het laagste niveau (team) worden de features, verder gedetailleerd in (user) stories,  'spikes' en 'refactors' en vervolgens vanuit de team backlog (de product backlog) in sprints gerealiseerd.

Hoe nu verder?

Aan de hand van dit artikel en de verwijzingen naar TOGAF, SAFe en het artikel “Uitdagingen van hybride portfolio management” laat ik zien dat de beelden van de Business Owner, Enterprise/Business Architect, Portfolio Manager, Informatiemanager en Scrum master aan het convergeren zijn. Een essentiële verandering die ik zie in de praktijk is dat het scrum denken, afkomstig uit de IT-organisatie, zich langzaam maar zeker naar het business- en informatiemanagement niveau in de organisatie verplaatst.

Uit ervaring kan ik melden dat sinds ik als business architect aan dergelijke trajecten deelneem, mijn inbox explodeert met e-mail berichten tussen alle betrokken stakeholders. Mogelijke verklaring is dat iedereen nu veel intensiever betrokken is geraakt bij het beoogde eindresultaat. Op zich een goede verandering, maar wie verzint er even een agile oplossing voor het elimineren van al deze e-mails bij het volledig integraal agile werken van het business tot en met het IT-niveau. Mogelijk is dit nog een gat in de markt?

Met dank aan

Aan dit artikel hebben de volgende collega’s actief bijgedragen:

• Mieke Mahakena (Business Architect, Trainer en Workforce Transformation Consultant);
• Bert  Schaapsmeerders (Enterprise Architect, Architecture trainer);
• Ben Kooistra (Business Architect, Scrum Consultant);
• Erik van den Berg (Informatiearchitect).
• Noud van Schrojenstein Lantman (sr. Business Analyst, SharePoint consultant);
• Michail Theuns (Business Analyst, Cyber Security Consultant);
• Klaas Zondervan (sr. Informatie Architect);
• Pieter de Beijer (Trainer Agile - Scrum).