Een duidelijk mandaat aan de teams om zelf keuzes te kunnen maken die binnen dat mandaat vallen zijn belangrijk voor de het functioneren van de teams. Teams kunnen dan zonder (tijdrovend-) overleg met leidinggevende zelf bijsturen waar nodig. Het leidinggevend management toont het vertrouwen in de teams om de juiste beslissingen te nemen. Het management draagt dat uit in de organisatie en de klantomgeving. En kan de inhoud loslaten die belegd is bij de teams. Stelt heldere doelen en kaders vast.

Een Agile mindset kenmerkt zich door een open cultuur waarin veel interactie tussen mensen plaatsvindt. Waar voortschrijdend inzicht wordt verwelkomd en die door korte feedbackloops tot continue verbetering leidt. Zowel in de ontwikkeling van het product als de team(s). Dat zie je terug in het gedrag van de organisatie als geheel.

Een dienst of product is vaak dermate complex dat er door meerdere teams aan gewerkt wordt, ieder met een eigen afgebakende bijdrage. Om sprintsgewijs werkende resultaten op te leveren is vanwege de onderlinge afhankelijkheden en gezamenlijke doelen intensieve samenwerking tussen de teams nodig. Hiervoor zijn verschillende methodieken zoals Scrum of scrums (SoS)- en Productowner syncs/standups.

Nemen de teams in de praktijk ook werkelijk de ruimte die gegeven is door het management? Zijn de teamleden in staat elkaar regelmatig feedback te geven over het functioneren als team? Is er dan ook voldoende ruimte om als team te groeien?

Zowel reactief als proactief. Is er een duidelijke strategie, visie en doel van de opdracht zodat de aanpassing altijd ten dienste staat van de oorspronkelijke doelstelling (stop het sprint/project als het doel niet meer valide is).

Agile structuren en processen kennen een beperkte maar heldere hiërarchie. Het is duidelijk wie waar over gaat. Er is continu interactie om die afbakening helder te maken en te houden. Een Agile organisatie kent geen verlammende vergadercultuur of gedetailleerde jaarplannen die leidend zijn. Er wordt continu en transparant gereflecteerd over de wijze waarop de gestelde doelen behaald kunnen worden. Iedereen in de organisatie kan zich hierin kwetsbaar opstellen.

Agile werken leer je niet uit een boekje. Dat leer je door te doen. Ervaren coaches zijn nodig om dat leren te stimuleren en kunnen indien gewenst daarbij geïntegreerd worden in diverse functies zoals scrum master, release train engineer (RTE), architect en dergelijke.

Met het opbouwen van nieuwe werkmethodieken wordt er ook voldoende aandacht besteed aan het afbouwen van hiërarchische structuren die deze in de weg zitten. Dat zie je terug in de wijze van leidinggeven. Een hiërarchische besturing maakt plaats voor faciliterend leiderschap. Allesomvattende gedetailleerde jaarplanningen worden vervangen door heldere teamdoelen, kwartaaldoelen, sprintdoelen en sprintplanningen. Er is een backlog die regelmatig met de klant en klantomgeving geprioriteerd wordt. Zorg tegelijkertijd dat je aandacht blijft houden voor kwaliteitsprocessen (zoals voldoen aan de BIO, AVG, etc.)

Naast retrospectives worden er ook andere feedbackloops georganiseerd. Per sprint wordt er feedback opgehaald bij de klant en de eindgebruiker. Men toont zich in staat om die feedback ook gevolg te geven.

Ieder goed functionerend team kenmerkt zich door stabiliteit en eensgezindheid over de wijze van werken. Agile is een heel breed begrip waar de invulling naar methodieken nogal kan verschillen. Onboarding van nieuwe medewerkers, opleidingen en certificering, trainingen van en door collega's zijn continu nodig om op dezelfde manier te (blijven) werken. Vergeet hier ook het management en de klantomgeving niet.

Denk hierbij aan tools zoals Jira, Miro, en software voor portfolio management. Er moet duidelijkheid zijn over welke tools beschikbaar zijn en of ze effectief worden ingezet.

Het doel is om Continuous Integration (CI) en Continuous Delivery (CD) te implementeren, zodat software op elk moment gereed is om naar productie te gaan. Dit verbetert de release-snelheid en -betrouwbaarheid.

Dit houdt in dat er (automatische) ketentests zijn, duidelijke afspraken over gegevensuitwisseling zijn, er samenwerking met inkopers is en er sprake is van LCM (Life Cycle Management) om zodoende een naadloze werking van systemen te garanderen.

Het is belangrijk dat de gebruikte tools toegankelijk zijn voor iedereen die ze nodig heeft. Dit kan bijvoorbeeld betekenen dat het management op elk gewenst moment inzicht heeft in de voortgang.

Zorg ervoor dat alle medewerkers tijdens hun onboarding worden getraind in de belangrijkste tools, zoals Jira, om hun productiviteit en efficiëntie te waarborgen.

Jaardoelen zijn nog heel abstract. Kwartaaldoelen worden concreter. Beide worden beschreven vanuit het perspectief van de gebruiker. Wat de gebruiker ermee kan. Een sprint vooruit gepland door het team zelf. Het ritme en planningsregime is vast en daarmee voorspelbaar. Wanneer er met wie de planactiviteiten worden uitgevoerd is voor iedereen helder en daar wordt niet van afgeweken. Wordt de sprintplanning of Planning Interval (PI) op vaste tijdstippen gehouden? Is op elk niveau - epic, functionaliteit, user story en taak - duidelijk wat de status is? Neemt iedereen zijn verantwoordelijkheid en geeft ieder commitment af?

Voor alle betrokkenen van klant, gebruiker, manager tot individueel teamlid is inzicht in de voortgang van de planning essentieel om vertrouwen te hebben en te houden in de werkwijze. Kent iedereen de status van -epic, functionaliteit, user story en taak? Is dat makkelijk inzichtelijk en toegankelijk (lees begrijpelijk) voor iedereen?

Planning in iteraties kent een grote mate van flexibiliteit. Echter op een lopende sprint wordt zelden "ingebroken". Inbreken op een lopende sprint resulteert in werk zonder resultaat, dus weggegooid geld. Wordt de sprint onderbroken - dan neemt de PO zijn of haar verantwoordelijkheid. Veranderende eisen en scope worden dan ook bij voorkeur in de komende sprints pas ingepland. Die flexibiliteit moet er nadrukkelijk wel zijn.

Het identificeren en afhandelen van risico's, kansen en bedreigingen is een doorlopend proces waarbij het gehele team betrokken is. Als voorbereiding op iedere sprint wordt dat gesprek gevoerd. Het hele team neemt hiervoor verantwoordelijkheid doordat iedereen individueel zijn/haar commitment en vertrouwen uitspreekt. Planningpoker is een goed instrument om tot een gedeeld beeld te komen van de opgave, risico's en onzekerheden.

Een goed op elkaar ingespeeld team kan goed schatten en daarmee wordt de leverbetrouwbaarheid vergroot. Het team houdt eigen prestaties bij in bijvoorbeeld een burndown chart/velocity meting en is in staat eigen voorspelbaarheid continu te verbeteren.

De ideale omvang van een team is rond de 9 mensen die samen over alle benodigde vaardigheden beschikken en individueel breed ontwikkeld zijn zodat men elkaars taken kan overnemen. Heeft het team alle disciplines in huis? (software architectuur, development, testautomatisering, testen, security etc).

Een team moet zo samengesteld zijn dat het autonoom haar taak (lees teamdoel en sprintdoelen) kan uitvoeren. Echter in een complexe omgeving is men vaak afhankelijk van andere teams. Een autonoom team is dan in staat om samen met de scrum masters en product owners van de andere teams zonder bemoeienis van management deze samenwerking vorm te geven.

Wie doet wat? Heeft het team een duidelijk teamdoel in de vorm van een teamvisie statement, afgebakende taakstelling, focus en stakeholdergroep. Een scrum- of DevOps team kent geen hiërarchie. Elke rol is even belangrijk ook die van de ondersteunde rollen zoals architecten of business analisten. Het gaat hier om productverantwoordelijkheden, niet om P-verantwoordelijkheden. Elke rol is even belangrijk ook die van de ondersteunde rollen zoals architecten of business analisten. Het gaat hier om productverantwoordelijkheden, niet om P-verantwoordelijkheden.

Wordt er gestuurd op dagelijkse standups, retrospectives etc.. Het team haalt regelmatig feedback op bij klant of eindgebruiker zodat ieder teamlid de behoeftes van de klant voldoende kent. Teams die afhankelijk zijn van elkaar communiceren dagelijks via scrum master en of product owner en hebben iedere sprint of iteratie fysieke meetings.

Een volwassen team communiceert onderling goed, is op de hoogte van ieders specialiteit en kan elkaar vervangen waar nodig. Een groep mensen is niet zomaar een team. Ook agile teams beginnen als individuen: ze hebben tijd nodig om te groeien. Onderken de fasen van groepsvorming van Tuckman. Agile teams gaan door vier belangrijke fasen naarmate ze zich ontwikkelen. Zodra een team de prestatiefase heeft bereikt wordt ontwikkeling optimaal. Leden vertrouwen elkaar, kennen elkaars sterke punten en gebruiken die kennis om de manier waarop ze software maken te optimaliseren. Let op dat er stabiliteit is in de teamsamenstelling. Zodra er een wisseling in het team is wordt de samenwerking en voorspelbaarheid verstoord.

Zowel met de klant als met het team zijn afspraken nodig over de kaders waarbinnen de oplossing gerealiseerd kan of moet worden. Er is een Project Start Architectuur (PSA). Rijksbrede kaders, -richtlijnen en -standaarden worden in de opdracht aan het team nadrukkelijk meegegeven. Denk hierbij aan BIO, NORA, Privacy by Design etc. Zowel de product owner als opdrachtgever of eigenaar van de voorziening neemt hier verantwoordelijkheid voor.

Functionele en niet-functionele eisen dienen zowel voor de klant als voor het team helder te zijn. Op alle niveaus: epic, functionaliteit, user story en taak. Op ieder niveau wordt de impact ervan ingeschat zodat via portfolio management keuzes gemaakt kunnen worden. Worden deze regelmatig afgestemd met de gebruikers en overige stakeholders? Toont het team aan hieraan te voldoen? Heeft het team de eisen voldoende uitgewerkt en vastgelegd? Voldoet het team hier iedere sprintoplevering aan?

Er zijn meerdere manieren om kwaliteit en werking te toetsen. Meerdere vormen worden toegepast tijdens de ontwikkeling: vier ogen principe, pair programming en testautomatisering. Kwaliteit komt tot uiting in de reikwijdte van de tests en de mate van automatisering ervan. Keten- en gebruikerstesten dienen ook iedere sprint uitgevoerd te worden.

Kwaliteitsborging voorkomt verrassingen bij de klant en eindgebruiker door regelmatig met de gebruikers te testen. Die weet waar die aan toe is (op basis van de Definition of Ready) en wat deze krijgt (op basis van de Definition of Done). Kent ieder teamlid deze, en kennen de teams deze van elkaar? Zijn deze afgestemd tussen de teams?

De Product Owner moet de ICT-taal beheersen en voldoende kennis en ervaring met ICT hebben om effectief te communiceren tussen de organisatie en het ontwikkelteam om zodoende de technische implicaties van beslissingen te begrijpen.

De Product Owner dient regelmatig en duidelijk te communiceren over beslissingen, voortgang en eventuele knelpunten, zodat de stakeholders goed geïnformeerd zijn.

De Product Owner moet aantoonbare kennis hebben van de organisatie en de gebruikers en de bijbehorende werkprocessen, zodat hij/zij de juiste prioriteiten kan stellen en beslissingen kan nemen die in lijn zijn met organisatiebehoeften.

De Product Owner moet duidelijk gedefinieerde verantwoordelijkheden en de nodige autoriteit hebben om beslissingen te nemen die de voortgang van de productontwikkeling ondersteunen, zonder afhankelijk te zijn van externe goedkeuringen.

De Product Owner moet actief zijn/haar invloed gebruiken om de productontwikkeling richting te geven, waarbij hij/zij de stakeholders effectief betrekt en communiceert.

De Product Owner moet in staat zijn om lange termijn doelen op te splitsen in behapbare stukken werk die snel waarde leveren aan de klant, met de focus op het realiseren van een MVP.

De Product Owner moet zelfstandig prioriteiten kunnen stellen die passen bij de strategische doelen van de organisatie, met flexibiliteit om te reageren op veranderende omstandigheden.

De Product Owner dient transparant te rapporteren over de voortgang richting de gestelde doelen, bijvoorbeeld via Jira of andere rapportagetools, en dient hierin feedback van stakeholders mee te nemen.

Het is belangrijk om vast te stellen wanneer doelen zijn behaald en waarde is geleverd aan de organisatie, om zo de impact van het werk te kunnen evalueren.

Gebruikersfeedback moet vroeg en regelmatig in het proces worden meegenomen, om te garanderen dat het geleverde product voldoet aan hun behoeften en verwachtingen.

Op elk niveau moet de backlog regelmatig worden geprioriteerd op basis van strategische en operationele overwegingen door het juiste niveau, bijvoorbeeld de portfolio backlog door het DT of MT. De Product Owner moet zorgen voor regelmatige en effectieve prioritering van de sprint- en product-backlog. De gemaakt keuzes moeten hierna worden gecommuniceerd aan de organisatie.

Regelmatige afstemming met alle relevante stakeholders is noodzakelijk om te verzekeren dat de backlog continu aansluit bij de veranderende behoeften en prioriteiten van de stakeholders.

De Product Owner moet ervoor zorgen dat er heldere criteria zijn voor wanneer werk kan worden gestart (DoR) en wanneer het als voltooid kan worden beschouwd (DoD). De gebruikers moeten hiervan op de hoogte zijn.

De Product Owner moet regelmatig tijd vrijmaken voor backlog refinement met het ontwikkelteam om ervoor te zorgen dat de backlog voldoende gedetailleerd en up-to-date is om effectief werk te kunnen plannen.

De Product Owner moet samenwerken met relevante afdelingen (zoals Architectuur of Security) om ervoor te zorgen dat alle belangrijke non-functionele eisen zijn opgenomen in de backlog.