Agile AIM – Agile Way of Working Strategische afstemming & transparantie Versie /03/2015
© Fedict All rights reserved | p. 2 Midden 2014 werd, onder leiding van Programma Manager Luc Van Tilborgh, het initiatief opgestart om op een agile wijze met de leveranciers samen te werken. Het doel was, en blijft nog steeds, om een nauwere én betere samenwerking tussen alle partijen te bekomen. In eerste instantie werd er een pilot-project uitgevoerd met de leverancier die het FSB platform uitbaat. Na een positieve ontvangst bij zowel de leverancier, als bij de medewerkers van het AIM programma, werd er eind 2014 beslist om de agile werkwijze uit te breiden naar de andere leveranciers Context Strategische alignering van de operationele werking zorgt ervoor dat het AIM programma zijn objectieven bereikt, zoals gespecifieerd binnen de programma strategie. Een verbeterde transparantie & communicatie naar stakeholders (zowel naar externe partijen, als interne medewerkers die geen deel uit maken van de operationele sprintwerking) maakt dat gezamenlijke en individuele doelen duidelijk zijn en dat deze vlotter bereikt worden. Het kaderen van de service management interacties binnen de agile werking van het programma moet ervoor zorgen dat de ontwikkeling van webservices en het ondersteunend platform vlotter zal verlopen (en vice-versa). Strategische alignering Transparantie & communicatie Interactie met service management Verbeterpunten Vandaag is de Agile AIM (“Agile Way of Working”) doorheen het AIM programma ingeburgerd, maar aangezien elke werkwijze evolueert en zich dient aan te passen aan wijzigende omstandigheden, blijft de noodzaak tot continue verbetering. Zo identificeren we vandaag de volgende verbeterpunten: Interactie met kwaliteits- verzekering Het verduidelijken van de kwaliteitsverzekeringsactiviteiten binnen de agile werking van het programma, zorgt ervoor dat iedereen op de hoogte is van welke controles zullen ingebouwd opdat de kwaliteit van het programma en zijn opleveringen wordt bewaakt. Interactie tussen verschillende backlogs Het verbeteren van de interactie tussen de verschillende product backlogs zal ervoor zorgen dat onderlinge afhankelijkheden beter worden beheerd.
Strategisch Tactisch Operationeel © Fedict All rights reserved | p. 3 De uitbreiding van AIM’s AWoW is géén integrale implementatie van het SAFe raamwerk, maar laat zich inspireren door bepaalde beste praktijken uit het SAFe raamwerk en tracht deze te vertalen naar de realiteit van het programma. Uitbreiding van de Agile werking – SAFe AIM AIM Portfolio AIM Program backlog AIM Program Increment AIM Roadmap AIM Sprintwerking AIM Product backlogs Strategische alignering Transparantie & communicatie Interactie met service management Focus van SAFe AIM Interactie met kwaliteits- verzekering Interactie tussen verschillende backlogs
1. Strategisch: AIM Portfolio Strategisch niveau Gestructureerd via KanBan, geprioriteerd via WSJF, opgesplitst per type: integratie & orchestratieKanBanWSJF Bestaande uit business epics en architectural epics, met elk een epic ownerbusiness epics architectural epicsepic owner KanBan structuur = “In > Qualify > Ready > Execute > Done” Periodiek opnieuw geprioriteerd via WSJF Verantwoordelijke voor het beheer van de AIM portfolio: PMT, onder leiding van de programma sponsor Selectie & prioritering © Fedict All rights reserved | p. 4 “integratie” “orchestratie”
1. Strategisch: AIM Portfolio (vervolg) Strategisch niveau Binnen het portfolio beheer is er ruimte om de epics verder te verfijnen (kwalificeren en kwantificeren) tijdens de “Qualify” fase, gebruikmakende van een ‘lightweight business case’.lightweight business case © Fedict All rights reserved | p. 5 1.“In” - Alle epics (business of architecture) komen hierin terecht, onder een minimale idee-vorm. Deze fase vormt de eerste catch-all van alle nieuwe ideeën. Alle programmaleden kunnen, via het PMT, epics identificeren ter opname in de portfolio. 2.“Qualify” - Om in de “qualify” fase terecht te komen, dient de forward-looking statement (FLS) te worden ingevuld door de respectievelijke epic owner. Op periodieke basis worden deze items geprioriteerd via WSJF. Een selectie van hoogst geprioriteerde epics wordt verder geanalyseerd en verfijnd (eventueel via een ‘lightweight business case’). Na een positieve beslissing van het PMT, kan een epic ter uitvoering naar de volgende fase worden overgeplaatst. 3.“Ready” – Dit is de verzameling van epics die klaar zijn voor uitvoering. Deze worden samen met de epics in uitvoering (“execute”), periodiek geprioriteerd via WSJF. 4.“Execute” - De epics met de hoogste prioriteit worden uitgewerkt binnen de agile werking van het programma, rekening houdende met de beschikbare capaciteit. 5.“Done” - Een epic is maar afgerond als het PMT beslist dat alle benodigde opleveringen werden geaccepteerd, of wanneer –indien nog niet alle features behorende tot dit epic werden afgewerkt- het PMT beslist dit epic stop te zetten en af te sluiten. Light- weight business case
2. Tactisch: AIM Program backlog De Program backlog bestaat uit “features” komende van de epics uit de Portfolio backlog, alsook via een instroom op het tactisch niveau* (bijvoorbeeld via New Service Requests [NSR] van consumers)Program backlog features Het is de verantwoordelijkheid van de desbetreffende epic owner (of service owner) om de vertaalslag te maken van epic of NSR naar een feature. Dit kan waar nodig in samenwerking met betrokkene programma leden. Elke feature zal nadien worden opgesplitst in user stories via een grooming session. Dit wordt in de volgende slides behandeld. De aanwezigen op de prioriteringsmeeting (PMT m.u.v. de sponsor) zijn verantwoordelijk voor het beheer en het periodiek prioriteren van de Program backlog Program backlog Feature Program backlog Feature 1. Vertaling naar features © Fedict All rights reserved | p. 6 Tactisch niveau Feature Service owners 1 Feature 2. Prioritering van features (*) De lange termijn evolutie van de PersonService & EnterpriseService wordt wel behandeld binnen de AIM portfolio
Program backlog 2. Tactisch: Grooming session De Grooming session heeft als objectief om: de prioritaire features uit de program backlog te vertalen naar user stories de verschillende user stories in te schatten naar werklast (via story points) de verschillende teams –via delegatie*- een beslissing te laten nemen i.v.m. de planning voor de eerst volgende Program Increment (=3 sprints of 9 weken) potentiële afhankelijkheden tussen features en user stories te identificeren en af te stemmen Feature User story Estimate © Fedict All rights reserved | p. 7 Tactisch niveau Feature User story Estimate User story Estimate Scrum Master Product Owner Service Owner Specialist (opt.) Grooming session Estimate Product backlogs User Story PLAT Meest prioritaire features worden geselecteerd ter vertaling in user stories 2.Elke feature wordt uitgesplitst in user stories + ingeschat qua inspanning (som van story points) 3.Elke user story wordt ondergebracht in een product backlog (PLAT of WS). 4.Obv de ingeschatte inspanning per feature & toegewezen prioriteit, wordt deze ingepland in de komende program increments Program Increment (PI) F FF 4 (*) Om praktische redenen werd er geopteerd om via delegatie tot een planning te komen i.p.v. met het voltallige team Feature User story Estimate Feature 1 F Product backlogs User Story WS
Program Increment (PI) JanuariMaart Mei Roadmap Afnemende zekerheid: hoe verder in de tijd, hoe onzekerder over de oplevering van bepaalde features 2. Tactisch: Program Increments & AIM Roadmap Program Increment (PI) Feature 1 PI = 3 sprints of 9 weken Een Program Increment (“PI”) overspant 3 sprints (in totaal 9 weken) van de verschillende agile teams en bestaat uit de oplevering van een bepaalde set features uit de AIM Program backlogProgram Increment features Feature De AIM Roadmap geeft een overzicht weer van de geplande features in de lopende en toekomstige program increments. De roadmap wordt regelmatig (na elke Program Increment) aangepast.AIM Roadmap © Fedict All rights reserved | p. 8 Tactisch niveau Feature 1 Feature 2 Feature 3 Feature 5 Feature 6 Feature 7 Feature 4
2. Tactisch: Communicatie prioriteiten De uitkomst van de grooming session zal gezamenlijk door de product owners gecommuniceerd worden naar de leden van de platform en webservice backlog via een afzonderlijke infosessie (inclusief communicatie via Confluence). Program Increment (PI) FF F © Fedict All rights reserved | p. 9 Tactisch niveau Communication Product owners 1.Communicatie van de prioritaire epics uit de Portfolio backlog 2.Communicatie van de prioritaire features uit de Program backlog 3.Communicatie van de gerelateerde user stories uit beide Product backlogs 4.Communicatie van de planning voor de komende program increment 5.Identificeren van potentiële afhankelijkheden of blokkerende issues Program backlog Feature Product backlogs User Story PLAT 3 Product backlogs User Story WS
3. Operationeel: Sprintwerking Elke sprint of iteratie zal meerdere user stories implementereniteratie Product backlogs worden niet enkel gevoed door user stories uit features, maar ook met user stories vanuit Service management (bv. wijzigingen komende uit problem management). Dit betreft de operationele instroom van user stories (zie volgende slide “Interactie service management) Program Increment (PI) Feature User story Estimate 2 Product backlogs: Agile meetings: Sprint planning meeting Sprint review meeting Sprint retrospective meeting Daily stand-up meeting Sprint planning meeting Sprint review meeting Sprint retrospective meeting Daily stand-up meeting Estimate Story points © Fedict All rights reserved | p. 10 Operationeel niveau Product backlogs User Story PLAT Product backlogs User Story WS
User Story Product backlog User Story Platform (PLAT) Product backlog User Story Webservices (WS) 3. Operationeel: interactie service management Product backlogs worden niet enkel gevoed door user stories uit features, maar ook met user stories vanuit service management, zoals bv. problem management, availability & capacity management,... Concrete voorbeelden hiervan zijn wijzigingen komende uit bugs/issues/problemen, gerelateerd aan webservices of platform componenten. Het is aan de desbetreffende product owners en waar nodig, de betrokken service owners om binnen de voorziene marges een balans te vinden tussen beide types van user stories o.b.v. prioriteit & capaciteit Product development (Agile AIM) + Service management (ITIL) Operationeel niveau Event Incident Ticket Work- around Problem Record Bv. Problem management Resolution / Change © Fedict All rights reserved | p. 11
4. Overzicht Binnen Safe AIM identificeren we 3 niveaus, namelijk: strategisch, tactisch en operationeel elk met hun eigen instrumenten – Medium – en verantwoordelijke © Fedict All rights reserved | p. 12 InstrumentMediumVerantwoordelijken Strategisch AIM Portfolio Portfolio backlog Lightweight business case Epic PMT Epic owner Tactisch Program backlog AIM Roadmap Feature Epic owner Service owner Prioriteringsmeeting Grooming session Operationeel Product backlog Sprint backlog User story Product owner Scrum coach Sprintmeetings
4. Overzicht (vervolg) Elk niveau heeft zijn eigen ‘instrumenten’ (epic / feature / user story) én beschikt over een ‘eigen’ intake kanaal: © Fedict All rights reserved | p. 13 Strategisch Tactisch Operationeel Portfolio backlog = Epics Program backlog = Features Cascade Intake Bijvoorbeeld ontwikkeling van nieuwe component Intake Bijvoorbeeld NSR Product backlog = User stories Product backlog = User stories Cascade Intake Bijvoorbeeld Bugs
5. Extra: Rapportering Agile & SAFe geven aan dat werkende software nog steeds het beste bewijs is qua vooruitgang & waarde creatie, doch dit neemt de nood aan gedegen rapportering niet weg. Rapportering laat toe om alle betrokken een correct en adequaat overzicht te geven van de status/voortgang van werkzaamheden.rapportering Agile AIM – AWoW laat toe om op elk niveau (strategisch, tactisch en adequaat), waar nodig een degelijke rapportering op te zetten. Hiervoor zal geopteerd worden om zoveel mogelijke de bestaande Jira rapportering te hanteren. Voorbeeld “Feature progress report” Story points © Fedict All rights reserved | p. 14
© Fedict All rights reserved | p. 15 De uitgevoerde kwaliteitsverzekeringsactiviteiten zullen erover waken dat de levenscyclus van epics adequaat wordt beheerd op zowel strategisch, als tactisch en operationeel niveau. Concreet kan het QA team de volgende activiteiten uitvoeren: o Nazicht van de identificatie, kwalificatie & prioritering van epics in de AIM portfolio; o Nazicht van de vertaling van een selectie prioritaire epics naar features en user stories; o Nazicht van de prioritering van features in de program backlog; o Nazicht van het document beheer (Confluence) doorheen de beheerscyclus van bovenstaande items; o Nazicht van de betrokken sprintwerking (via bijwonen sprint planning, sprint review & sprint retrospective + steekproef van daily stand-ups); o Nazicht van het deployment proces o Nazicht van de test aanpak. 5. Extra: kwaliteitsverzekering (QA)
© Fedict All rights reserved | p Verklarende woordenlijst EpicEpics zijn initiatieven van een relatief grote omvang die alvorens uitgevoerd te worden, verder dienen te worden geanalyseerd. Er wordt een onderscheid gemaakt tussen business epics en architectuur epics. Business epics bieden een antwoord op een welbepaalde “business” nood van een klant of eindgebruiker. Architecture epics zijn voornamelijk technologisch van aard, d.w.z. zij vormen vaak de noodzakelijke onderbouw van één of meerdere business epics. FeatureFeatures zijn items die een bepaalde toegevoegde waarde bieden aan een eindgebruiker. Zij vormen altijd een onderdeel van een welbepaald epic. Ze bevinden zich logisch gezien qua implementatie grootte orde tussen epics en user stories. Epics zijn groter in omvang daar ze één of meerdere PI’s kunnen overspannen, terwijl user stories dan weer zo worden opgesteld dat ze binnen één sprint kunnen worden uitgewerkt. PortfolioDe portfolio is het instrument dat via KANBAN alle integratie en orchestratie epics groepeert op AIM programma niveau. Portfolio backlogDe portfolio backlog bevat alle goedgekeurde epics (d.w.z. waarvan het PMT heeft beslist om deze uit te voeren). Van hieruit worden portfolio epics door de epic owner later opgesplitst naar features. PrioriteringsmeetingTijdens de prioriteringsmeeting wordt er op tactisch niveau beslist, door het PMT m.u.v. de sponsor, over de prioriteit van de features. Product backlogDe product backlog bevat alle user stories gerelateerd aan zowel de te ontwikkelen features voor de huidige en toekomstige sprints, alsook user stories komende vanuit het service management (bugfixes,...) en de interne team context (bv. n.a.v. een sprint retrospective) Program backlogDe program backlog bevat alle features die zijn goedgekeurd ter uitvoering door het PMT. Er is een instroom vanuit zowel de portfolio, als van een lokale intake op tactisch niveau. Deze features worden op hun beurt geprioriteerd op de prioriteringsmeeting Grooming sessionDe Grooming session heeft als objectieven: de prioritaire features uit de program backlog te vertalen naar user stories, de verschillende user stories in te schatten naar werklast en tenslotte de verschillende teams – via delegatie- een beslissing te laten nemen i.v.m. de planning voor de eerst volgende Program Increment
© Fedict All rights reserved | p Verklarende woordenlijst (vervolg) RoadmapDe roadmap geeft een overzicht weer van de geplande features in de lopende en toekomstige program increments en releases. Deze wordt periodiek aangepast i.h.k.v. elke grooming session. SprintEen sprint of iteratie bestaat uit het opleveren van een bepaalde toegevoegde waarde onder de vorm van werkende software, door het agile team. Een sprint binnen agile AIM duurt 3 weken. Sprint backlogDe sprint backlog omvat het werk voor de komende sprint en bestaat uit een selectie user stories komende uit de product backlog. User storyEen user story bevat het gedetailleerde implementatie aspect van bepaalde functionele of non-functionele vereisten (= groepering van een aantal taken). Typisch aan een user story is dat deze kan uitgevoerd worden binnen één sprint.