De manier waarop we onze producten ontwikkelen en samenwerken is gebaseerd op het Scaled Agile Framework (SAFe) maar aangepast om beter te werken met de ABB Digiteam manier om dingen te doen en het aantal mensen in ons team.

Agile ontwikkelen! Waarom?

Grote uitdagingen worden in kleine, concrete stappen ontwikkeld. Zo ontstaat er een constante flow en zien we het geheel groeien.

• Transparant overzicht houden op het werk

• Werken in behapbare blokken

• Voldoende en flexibel plannen

• Verantwoordelijkheden op de juiste plaats

Vaste cadans op drie niveaus

• Rollende roadmap die minstens één jaar vooruit kijkt.

• Groeispurts van 10 weken eindigend met een Centrale Planningsdag.

• Iedere Spurt bestaat uit vier sprints en één IPI.

Roadmap

We gebruiken een vrij uitgebreide roadmap. Daarbij vinden we het belangrijk dat we concreet definiëren voor welke doelgroep de desbetreffende functionaliteit meerwaarde oplevert. Deze bijgewerkte roadmap op middellange termijn vind je in onze online-tool die gelinkt is aan de JIRA-tool die het hele productteam gebruikt voor de planning en opvolging van de sprints & spurts in de scaled agile werking.

Het opstellen en bijsturen van de roadmap is een continue gegeven: deze wordt elke groeispurt bijgestuurd in functie van de resultaten en ervaringen van de afgelopen groeispurt en eventuele bijkomende doelen of gewijzigde prioriteiten.

Spurten en Sprinten?

Groeispurt

Een groeispurt heeft steeds een duur van 10 weken. Het omvat vier reguliere (ontwikkel)sprints en een Innovatie en Planning Iteratie (IPI). In de laatste week van een groeispurt/ IPI is er een Centrale Planningsdag (CPD) waar de doelen voor de volgende groeispurt wordt vastgelegd.

Door in periodes van 10 weken te werken is er voldoende focus om stappen te zetten maar niet te veel rigiditeit om met een steeds veranderende context om te gaan. Het geeft de ontwikkelteams een duidelijke focus voor 10 weken maar wel de mogelijkheid om met de volgende groeispurt in te spelen op (veranderde) prioriteiten uit de organisatie.

(Ontwikkel) Sprint

Een sprint is een afgebakende periode van twee weken waarin een productteam aan de slag gaat om een duidelijk sprintdoel te bereiken. Sprints volgen elkaar steeds direct op en hebben een aantal vaste elementen/rituelen:

• Sprintplanning

• Backlog Refinement Meeting (BRM)

• (Daily) stand-up

• Sprint demo (review)

• Sprintrapportering op Solution Stand-up

Innovatie en Planning Iteratie (IPI)

Naast het ontwikkelen van functionaliteiten is er ook nood aan andere activiteiten om een product(team) verder te laten groeien. Daarom zijn de laatste twee weken van een groeispurt steeds speciaal omdat het expliciet ruimte biedt voor ...

• Innovatie en experimenten

• Training

• Planningsactiviteiten voor volgende groeispurt

Wanneer? De Innovatie en Planning (IPI) iteratie gebeurt steeds op het einde van een Spurt.

Aan het werken in sprints - als onderdeel van een groeispurt- zijn bij ABB, zoals klassiek in de sprintwerking, een aantal vaste ceremonies verbonden.

In deze rubriek beschrijven we hoe de teams deze ceremonies invullen en wie er aan deel neemt.

Op deze pagina vind je meer info over het verloop en de praktische invulling van een groeispurt bij Digiteam ABB

Een groeispurt heeft steeds een duur van 10 weken. Het omvat vier ontwikkelsprints en een Innovatie en Planning Iteratie. In de laatste week van de een groeispurt is er een Centrale Planningsdag (CPD) waar de doelen voor de volgende groeispurt wordt vastgelegd.

Door in periodes van 10 weken te werken is er voldoende focus om stappen te zetten maar niet te veel rigiditeit om met een steeds veranderende context om te gaan. Het geeft de ontwikkelteams een duidelijke focus voor 10 weken maar wel de mogelijkheid om met de volgende groeispurt in te spelen op (veranderde) prioriteiten uit de organisatie.

Als team werken we dag in dag uit aan het versterken van onze democratie door burgers en bedrijven actief te informeren en te betrekken bij (lokale) besluitvorming. Daarnaast streven wij ernaar de digitale dienstverlening te vereenvoudigen door informatie efficiënt te onderhouden en te hergebruiken via één digitale invoer.

Lees hier meer over in onderstaand document waarin onze visie en missie worden beschreven, over onze waarden als organisatie:

Of bekijk onderstaand filmpje waarin onze Missie en Visie meer in detail wordt uitgelegd:

De sprint review of sprint demo meeting aan het einde van elke sprint gehouden. Deze informele bijeenkomst is bedoeld om terug te kijken op wat er behaald is en waar nodig de Product Backlog aan te passen. Bij deze meeting zijn ook alle belanghebbenden van het project aanwezig, die hier de kans hebben om feedback te geven. De sprint demo wordt elke laatste vrijdagnamiddag van de sprint gehouden en dit per product. De organisatie en moderatie is in handen van de scrum master.

Deelnemers aan de sprint demo zijn in essentie iedereen die bij de ontwikkeling van het product - als onderdeel van een of meerdere oplossingen - betrokken is. Dit betekent dus niet alleen de leden van het scrum team (developers, designer, analist, product owner en product manager, scrum master) maar ook product managers en product owners van andere producten, gebruikers van het product, business stakeholders, leden van het architectuurteam welkom zijn op de tweewekelijkse sprintdemo.

De sprintplanning is de eerste ceremonie van een sprint en vindt plaats op de eerste (werk)dag van een nieuwe sprint. Tijdens de sprintplanningsmeeting plant het scrum team samen met de scrum master en de product owner de aankomende sprint door de stories op de backlog (in Jira) te bespreken en in te schatten. Indien nodig licht de product owner items op de product backlog nog toe zodat iedereen deze begrijpt. (let wel: voorafgaandelijke kan er een backlog refinement gebeurd zijn met het team en kan het zijn dat de inhoud van de hoogst geprioriteerde user stories nog fris in het hoofd zit van de deelnemers en dus weinig extra uitleg behoeft).

De leden van het scrum team (designers, analisten, developers) stellen op basis van hun capaciteit en de prestaties in vorige sprints vast welke user stories zij oppakken. De lijst met geselecteerde user stories vormt de sprint backlog. Vervolgens formuleert het scrum team gezamenlijk een definitief sprintdoel dat een duidelijk antwoord geeft op de vraag: voor welke doelstellingen engageren we ons met het team tijdens de komende sprint?

Deelnemers aan de sprintplanning zijn (minimaal) de product owner - (lead) developers - designer - analist- scrum master.

Elke eerste maandag van een sprint rapporteert de product owner/ product manager over het verloop van de vorige sprint op de Solution Stand-up. De rapportering wordt gedaan aan de hand van een status slide in een bepaalde template. Er wordt gerapporteerd over:

• is het sprintdoel gerealiseerd?

• zijn we nog on track om het groeispurt doel te realiseren?

• welke belangrijke inhoudelijke realisaties zijn er in de voorbije sprint (afgewerkt en begonnen maar niet afgewerkt)

• hoe zag de sprint burndown eruit en hoeveel story points werden gerealiseerd versus hoeveel waren er gepland?

• zijn er bepaalde issues of risico's waar de collega PM's en de Solution Stand-Up van op de hoogte moeten zijn?

De rapportering op de Solution Stand-up wordt in een plenaire sessie gedaan om iedereen zoveel mogelijk geinformeerd te houden. Meer en meer producten dragen samen bij aan een of meerdere waardestromen en de informatie uitwisseling tijdens een sprintrapportering is hier een belangrijke drijvende factor in.

Hoe?

Het doel van de backlog Refinement Meeting is om de hoogste prioriteit items in de product backlog te ontleden in user stories die geschikt zijn voor opname in de volgende sprint. Tijdens deze bijeenkomst neemt het team gezamenlijk de items bovenaan de product backlog en ontleedt ze in ‘goede’ user stories. Tijdens de backlog refinement vergadering bekijkt het team elk item om de beurt en bespreekt of het haalbaar is om in de volgende sprint op te nemen of dat het verder moet worden opgesplitst en/of verfijnd om het uitvoerbaar te maken in de volgende sprint.

Een belangrijke verantwoordelijkheid rust bij de Product Owner en de Scrum Master om als voorbereiding op deze vergadering - de backlog in juiste orde te zetten. Uiteraard kan vanuit het scrum team ook - voorafgaandelijk - backlog items klaargezet worden om te bespreken samen met de items bovenaan de backlog.

Deelnemers aan de backlog refinement meeting zijn - minimaal - de product owner, de (lead) developer(s), de designer en de scrum master.

De stand-up is een korte bijeenkomst (virtueel of fysiek) tijdens de lopende sprint op frequente basis (dagelijks tot enkele keren per sprint) waarin de deelnemers op beknopte wijze een antwoord geven op de volgende 3 vragen:

• Wat heb je sinds de vorige stand-up gedaan?

• Wat ga je doen tegen de volgende stand-up?

• Heb je vragen of problemen bij het uitvoeren je werk tijdens de sprint?

Tijdens de stand-up wordt in Jira het actieve sprintbord gebruikt.

Deelnemers aan de stand-up zijn minimaal de product owner, de (lead)developers, de designer, de analist en de scrum master. Bijkomend is het nuttig dat op bepaalde momenten ook de tester en de product manager deelnemen.

De verschillende product teams van het Digiteam ABB vullen de Daily Stand-up routine momenteel bewust op een andere manier in:

• Organisatieportaal: elke dag een stand-up, behalve op vrijdag, van 11:45 - 12:00

• Kalliope: elke woensdag en elke eerste vrijdag van de sprint is er een stand-up van 30 minuten

• Loket, Gelinkt Notuleren, Architectuurteam: de stand-up wordt samen met de backlog refinement gehouden op de eerste vrijdag van de sprint

Naast het ontwikkelen van functionaliteiten is er ook nood aan andere activiteiten om een product(team) verder te laten groeien. Daarom zijn de laatste twee weken van een groeispurt steeds speciaal omdat het expliciet ruimte biedt voor ...

• Innovatie en experimenten

• Training

• Planningsactiviteiten voor volgende groeispurt

Wanneer? De Innovatie en Planning (IPI) iteratie gebeurt steeds op het einde van een Spurt.

Stramien voor de invulling van de IPI bij Digiteam ABB

Om de activiteiten die typisch in de IPI plaatsvinden te kunnen organiseren werd een kalender opgemaakt waarin elk van de noodzakelijke activiteiten een plaats kreeg. Bij het uitzetten van de activiteiten hebben we rekening gehouden met enkele voorkeuren van het team met betrekking tot vergaderdagen en hebben we geprobeerd de innovatie-activiteiten als één blok te groeperen om focusverschuiving tussen innovatie en planningsvergaderingen te voorkomen. Deze kalender wordt gebruikt om bij de betrokken teams placeholders in de agenda te zetten zodat de nodige tijd wordt gevrijwaard in elke IPI.

Voorbeeldactiviteiten: testen nieuwe technologieën, breder delen van nieuwe functionaliteiten, kennisoverdracht, scoping sessies & brainstormen, retrospectieves, manier van werken herbekijken, ...

Deze kalender ziet er momenteel zo uit:

WEEK 1 IPI: FOCUS op sprintplanning IPI - Innovatie - Inspect and adapt

WEEK 2 IPI: Focus op Groeispurtplanning - Retrospectieve en Sprintdemo IPI

Centrale Planningsdag - CPD

De centrale planningsdag is een essentieel terugblikmoment om terug te kijken naar de Groeispurt die eindigt en te plannen voor de volgende Groeispurt. Daarom vindt deze plaats tussen twee groeispurten in.

Het geeft tijd aan alle actoren in onze agile productontwikkeling om ...

• Delen van gerealiseerde oplossingen a.h.v. demo’s in een plenaire sessie.

• Plannen van de volgende Spurt o.b.v. de voorbereiding die vooraf gemaakt werd tijdens de IPI. Epics (productfunctionaliteiten) worden gepland om uit te voeren. Hun implementatie draagt uiteindelijk bij tot oplossingen waaraan ze gelinkt zijn.

• Afstemming tussen verschillende producten om tot gedeelde oplossingen te komen

Het programma van een CPD is gebaseerd op de onderdelen van het standaardprogramma dat binnen het Scaled Agile Framework wordt beschreven maar de activiteiten worden doorheen de volledige IPI verspreid. De belangrijkste finale afstemming gebeurt op een één dag.

Wanneer? De Centrale Planningsdag (CPD) gebeurt steeds tijdens de IPI op laatste donderdag van een Spurt.

De techniek van Impact mapping helpt de productteams bij Digiteam ABB en hun belanghebbenden niet alleen om de product roadmaps te visualiseren, maar ook om uit te leggen hoe ‘deliverables’ aansluiten op de behoeften van gebruikers, en om te communiceren hoe gebruikersresultaten zich verhouden tot oplossingen op hoger niveau en waardeketens.

Voor deze oefening gebruiken we een techniek van impact maping, beschreven door Neuri Consulting LLP. Bij het maken en bijwerken van de impactmappings van een waardeketens denken de teams na over gedragsveranderingen die een grote impact zouden hebben op de gebruikers van de in de waardeketen betrokken product of producten. Vervolgens schrijven we ze op in de impactmap en groeperen we de impacts op actoren, persona's of gebruikerscategorieën met behulp van vertakkingen. Vervolgens voegen we per tak (impact per groep) deliverables toe die die gedragsveranderingen kunnen ondersteunen en streefdata die we nastreven om de impact te realiseren. Vervolgens nemen we de organisatiedoelen die door die impacts worden ondersteund op in de mindmap.

Waar vind je onze impact mappings?

Hoe een impact mapping maken?

Vertrek steeds vanuit een meetbare doelstelling voor de creatie van waarde. Vertak vervolgens naar de actoren die we moeten bereiken (en beinvloeden) om de doelstelling te realiseren. Schrijf vervolgens per actor op aparte vertakkingen uit welke impact we precies moeten bereiken om onze doelstelling te halen. Tenslotte bepalen we per impact concrete 'deliverables' die we moeten realiseren om de impact ook effectief te kunnen realiseren.

De sprint retrospective is een terugkerende bijeenkomst aan het einde van een Groeispurt en wordt gebruikt om te bespreken wat er goed en/of fout ging tijdens de vorige Groeispurt-cyclus en wat er verbeterd kan worden in de volgende Groeispurt. De sprint retrospective is een essentieel onderdeel van de (scaled) agile manier van werken. Bij Digiteam ABB hebben we afgesproken om een retrospective te doen aan het einde van vier sprints en niet aan het einde van elke sprint. Problemen die tijdens de sprint ontstaan en die een (zware) impact hebben op de samenwerking van de productteams of op hun efficiëntie worden uiteraard direct opgepakt door het team en de scrummaster(s) en wachten niet tot de retrospective bij de einde van de Groeispurt. Bijgevolg is ad hoc retrospective mogelijk.

Stappen in onze retrospectives

Stap 1: "Set the stage". Een retrospectieve is het meest effectief als iedereen in het team eerlijk is over wat goed ging en ook wat niet. Maak duidelijk waar de terugblik over gaat en hoe de retrospective praktisch zal verlopen.

(Stap 2: Opwarmen). Gebruik een kleine oefening om ervoor te zorgen dat iedereen minstens één ding zegt om op te warmen. bijv. Vertel wat je als ontbijt hebt gehad Vertel wat je favoriete vakantiebestemming is Beschrijf de laatste iteratie in slechts 3 woorden Stap 2: Verzamel gegevens via een sjabloon. Er zijn veel retrospectieve sjablonen beschikbaar op internet. Kies er een om de gegevensverzameling te structureren. bijv.

Vervolgens krijgt elke deelnemer de tijd om virtueel of fysiek post its te schrijven en op te plakken. We doen dit in real time zodat anderen kunnen zien wat er geplakt werd. Zo raken mensen met weinig inspiratie wellicht toch geinspireerd om gedachten te formuleren. Elk idee of elke gedachte is een post-it.

Stap 3: Inzichten genereren met de hele groep is de volgende stap. Begin met het identificeren van groepen en duplicaten, praat over wat er naar voren komt en wat kan helpen om het te verbeteren of te verhelpen.

Stap 4: Bepaal wat je moet doen door een korte lijst te maken met dingen om in gedachten te houden tijdens hun volgende sprint.