Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Deze pagina is nog in opbouw. Lees je iets raar? Vraag er even naar! david.suijkerbuijk@vlaanderen.be
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
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.
Het releasen van ontwikkelingen is niet per definitie gekoppeld aan de cadans.
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.
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.
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
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.
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
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?
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.
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.
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
De capaciteit van de IPI mag niet worden ingecalculeerd voor het halen van de Spurt-doelen. Het is niet gewoon een 'extra' sprint.
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.
Wat? | Doel | Aanwezigen | |
---|---|---|---|
Day/Part
Maandag
Dinsdag
Woensdag
Donderdag
Vrijdag
AM
Sprintplanning IPI
Innovation
Innovation
Innovation
Inspect and Adapt
AM
(Retrospectieve)
Capacity check DEV + Design
PM
Innovation
Innovation
Innovation
Innovation
Inspect and Adapt
PM
(Retrospective)
Dag/Deel
Maandag
Dinsdag
Woensdag
Donderdag
Vrijdag
AM
Impact Mapping
Impact Mapping
Story Mapping
CPD
Retrospective
AM
Story Mapping
Story Mapping
Impact Mapping
PM
Impact Mapping
Impact Mapping
Capacity Check PM's ifv planning
CPD
Sprintdemo IPI
PM
Story Mapping
Story Mapping
Prepare backlog for sprint 1
Vooraf
Impactmapping per waardestroom
Overzicht van mogelijke deliverables
PM's & PO's,
Solution niveau
Designers
Business Analisten
Business-personen
Vooraf
Retrospectieve per productteam
Terugkijken en leren op het ontwikkelproces
Alle teamleden van een productteam
Vooraf
Voorbereiding CPD per productteam
Bekijken wat realistisch is om in de volgende groeispurt op te nemen. - Storymapping - Planning op CPD-bord
PM en PO
Development leads
Vooraf
Capaciteitsinschatting - sync met dev's en designers
Vraag naar dev's en designers in overeenstemming brengen met beschikbaarheid
RedPencil
Hannes
Veronique
Vooraf
Capaciteitsinschatting - sync met PO's en PM's
Feedback aan PM's en PO's over beschikbaarheid dev's en designers voor hun producten voor de volgende groeispurt
PO's
PM's
Veronique
9h00 - 9h15
Introductie door
IT-directeur (en Manager Digitale Oplossingen)
Verwelkoming
PM's & PO's
Productteams
Business-personen
Solution niveau
9h15 - 10h30
Demo's gekoppeld aan de waardestromen
Tonen wat er in de voorbije groeispurt werd ontwikkeld per waardestroom.
PM's & PO's
Productteams
Business-personen
Solution niveau
10h30 - 15h00
Break-outsessies per waardestroom
Finaal overlopen van de planning voor die waardestroom over de producten heen.
PM's & PO's
Relevante productteams
Business-personen
15h00 - 15h30
Planning finaliseren per product
Moment voor de PM's en PO's om hun planning af te werken vooraleer te presenteren op de plenaire sessie.
PM's & PO's
15h30-16h30
Presentatie van sprintplanning en sprintdoelen per product
Presentatie eindresultaten van de planning per productteam. De presentatie van de planning houdt een 'impliciete confidence vote' in van de betrokken teams.
PM's & PO's
Productteams
Business-personen
Solution niveau
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.
De impact mapping wordt minstens 1 keer per groeispurt gedaan en ten laatste tijdens de IPI. Het is een interactieve manier om voor een bepaalde waardeketens de meest impactvolle en dus belangrijkste product prioriteiten voor de volgende groeispurt te bepalen. Deelnemers aan de impact mapping zijn het product team (PM, PO, architect, developer, designer, tester) en een breed publiek aan betrokken stakeholders. De eigenaar van de waardeketen leidt de sessie.
Onze impact mappings worden gemaakt en bijgewerkt in Miro. Ze worden traditioneel bijgewerkt tijdens de tweede week van de IPI (Innovatie en Planning Iteratie) en zijn te vinden op het CPD-bord onder Solution. Impact mappings van voorbije groeispurten worden doorgaans mee gearchiveerd en zijn bereikbaar via het overzicht naar de voorbije groeispurten als een van de eerste frames van het CPD-bord onder Solution.
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.
Een user story mapping helpt je om user stories te ordenen in een zinvol model of patroon en om zodoende de functionaliteit van een systeem te begrijpen, en eventuele gebreken in de product functionaliteiten/ product backlog te achterhalen en daarna effectief releases te plannen die op het moment van release de best mogelijke waarde opleveren voor gebruikers. Het is met andere woorden een slimme techniek om hoofd-van bijzaak te onderscheiden in de productlog en op het juiste moment het best mogelijk in te spelen op gebruikersnoden.
User Story Mapping is de voorbije jaren een populaire techniek geworden voor het beheren van user stories dankzij de inspanningen van pionier Jeff Patton. Met de techniek kan je meerdere niveaus en dimensies voor een product backlog vastleggen ondermeer door de gebruikersbehoeften uit te splitsen als (gebruikersactiviteiten, gebruikerstaken), epics en user stories. Bij ABB wordt user story mapping doorgaans toegepast na de impact mapping en in voorbereiding van de planning op de Centrale Planningsdag. Het moet helpen om - binnen de beschikbare capaciteit voor de groeispurt en sprints - de meest waardevolle dingen te bouwen.
De story mapping wordt minstens 1 keer per groeispurt gedaan, ten laatste tijdens de IPI als voorbereiding van de volgende groeispurt en na de impact mapping. Deelnemers aan de story mapping zijn de product teams (PM, PO, Architect, Developer, Designer). Geinteresseerde business stakeholders zijn ook uitgenodigd om deel te nemen. De PM of PO (volgens afspraak in het product team) leidt de sessie.
Een van de pijlers van de SAFe Lean-Agile Mindset is innovatie, maar het kan moeilijk zijn om tijd te vinden voor ideeën en verandering te midden van de drukte in de reguliere sprints. Daarom gebruiken we bij Digiteam - zoals veel organisaties die de SAFe structuur volgen - IP-iteraties voor onderzoeks- en ontwerpactiviteiten zoals hackathons. Er zijn twee eenvoudige regels voor hackathons: we werken bij voorkeur aan eenzelfde thema met verschillende groepen samengesteld uit leden van verschillende teams (cross-team). De teams demonstreren hun werk aan anderen aan het einde van de hackathon.
De capaciteitscheck(s) die tijdens het IPI worden uitgevoerd, zijn een moment om informatie te verzamelen over de beschikbaarheid van teamleden tijdens de komende groeispurt. De check is nodig om te voorkomen dat teamleden "overgepland" worden in één of meerdere productteams waardoor frustratie ontstaat en uiteindelijk sprintdoelen niet worden gehaald. Een capaciteitscheck met de ontwikkelaars, ontwerpers en analisten wordt gevolgd door een capaciteitscheck met Product Managers en Product Owners op de dag voor de CPD. De uitkomst van de check is een overzicht van de beschikbare mandagen per teamlid per sprint. Deze info wordt vervolgens gebruikt om werkzaamheden te plannen tijdens de planningssessie van de CPD.
Voor de capaciteitscheck - georganiseerd door het solution niveau van Digiteam - bellen de PM's en/of PO's in om te overleggen met leden van het solution niveau. Zij deden voorafgaand met alle leveranciers (ontwikkelaars, designers, testers, ...) een check op beschikbaarheid/ budget voor de volgende groeispurt.
De Inspect and Adapt workshop uit de Scaled agile methode is voor het ABB Digiteam momenteel een nieuwe, nog niet toegepaste, manier om de kwaliteit van de toepassing op het moment van de workshop te evalueren met de teams die betrokken zijn bij de 'release' van de toepassing. Volgens het Scaled Agile Framework bestaat het Inspect and Adapt evenement uit 3 delen:
PI-systeemdemo
Kwantitatieve en kwalitatieve meting
Retrospectieve en probleemoplossende workshop
Het uiteindelijke doel van de Inspect and Adapt workshop is om een routine aan te kweken waarbij de belangrijkste gebreken aan de toepassing via een verbeterstory de weg vinden naar de backlog voor de volgende groeispurt(s).
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.
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.
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.
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.
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.