Scaling the agile organization

Transcriptie

1 Scaling the agile organization Januari 2016

2 Colofon Dit is een uitgave van VODW. Heeft u nog vragen of behoefte aan een nadere toelichting op dit document? Neem dan contact op met Michael Klazema van VODW via mklazema@vodw.com of De inhoud van dit document mag niet voor andere doeleinden worden gebruikt, hergebruikt of worden verspreid zonder toestemming van VODW. Copyright VODW Whitepaper januari 2016 VODW

3 Inhoudsopgave 4 Van scrumteam naar agile op schaal 5 De juiste werkvorm selecteren 7 Scrum of Scrums 12 Large Scale Scrum (LeSS) 15 Het Spotify model 19 Scaled Agile Framework (SAFe) 24 Hybride vormen van waterval en agile 26 Conclusie 27 Begrippenlijst Scaling the agile organization Whitepaper januari 2016 VODW 3

4 Van scrumteam naar agile op schaal Agile werken in scrumteams groeide in de afgelopen jaren uit tot een ware hype. In vrijwel iedere organisatie ontstaan kleinschalige teams die los van de bestaande processen opereren en in korte iteraties snel successen laten zien. Een logische stap is om daarna met meer teams op een agile manier te gaan werken. Dit vindt vaak eerst plaats binnen de IT-organisatie, maar in de afgelopen jaren zijn de agile principes ook goed toegepast binnen de marketingorganisatie. Afhankelijk van de organisatieomvang ontstaat bij een groeiend aantal agile teams vaak ook de behoefte of noodzaak de werkzaamheden tussen deze agile teams te coördineren. Dit hele proces noemen we scaling agile : het op grote schaal toepassen van agile principes in een organisatie. Als je agile principes op grote schaal - met meer dan een paar teams - wilt toepassen, levert dit verschillende uitdagingen op. De scrummethodiek, die door veel bedrijven wordt gebruikt om te experimenteren, biedt geen houvast zodra verschillende teams naast elkaar werken aan hetzelfde eindproduct. Door een gebrek aan overkoepelende coördinatie en overleg, ontstaat er al snel frustratie en inefficiëntie. Bedrijven moeten dus op zoek naar een framework om agile op te schalen. Van dit soort frameworks lijkt er iedere dag weer één bij te komen. Een aanpak zoals die van Spotify, initieel niet eens bedoeld als model, gaat door de grote media-aandacht een eigen leven leiden. Daarnaast zijn veel agile coaches of organisatieadviseurs slechts gespecialiseerd in één model. Meer begrip van de mogelijkheden om agile op te schalen zorgt dat je als organisatie de goede keuze maakt. 4 Whitepaper januari 2016 VODW

5 De juiste werkvorm selecteren Een weloverwogen keuze begint bij het beantwoorden van een aantal kernvragen die je een idee geven van welk type werkvorm het best bij jouw organisatie past. Vervolgens is begrip van de verschillende stromingen en een kritische analyse van best practices nodig. In deze whitepaper bespreken we een aantal werkvormen. Deze frameworks vertegenwoordigen de uitersten van alle frameworks om agile op te schalen. Door naar de uitersten te kijken is het makkelijker de verschillen in aanpak te beschrijven. Scrum of Scrums. Large Scale Scrum (LeSS). Scaled Agile Framework (SAFe). Het Spotify model. Hybride vormen van Waterval en Agile. Handvatten bij de selectie van het juiste framework Niet ieder framework is geschikt voor iedere organisatie. Voordat we ingaan op de sterke en zwakke punten van de verschillende frameworks, is het belangrijk te ontdekken aan wat voor type framework de organisatie behoefte heeft. Sommige methoden zijn namelijk bij uitstek geschikt voor grote organisaties, terwijl je andere juist beter in kleinschalige ondernemingen kunt gebruiken. Daarnaast richt het ene framework zich meer op principes, terwijl het andere een volledige blueprint voorlegt en de werkwijze tot in detail beschrijft. Ondanks deze verschillende aanpakken is het wel mogelijk de frameworks op een aantal aspecten met elkaar te vergelijken. Onder andere Ebba Kraemer van Hansoft ontwikkelde hiervoor een model, waarvan de basis bestaat uit een aantal kernvragen. Zijn er veel afhankelijkheden tussen de ontwikkelteams (intradependencies)? Sommige teams zijn bijvoorbeeld afhankelijk van elkaar voor de release van nieuwe concepten of aanpassingen, terwijl andere onafhankelijk van elkaar een release in gang kunnen zetten. Zijn er veel afhankelijkheden tussen de ontwikkelteams en de rest van de organisatie (interdependencies)? Soms zijn teams sterk afhankelijk van de projecten en tijdlijnen van andere delen van de organisatie, bij weinig afhankelijkheden werken zij vaak los van bestaande processen. Scaling the agile organization Whitepaper januari 2016 VODW 5

6 In welke mate is het noodzakelijk dat de ontwikkelteams zelf een hoge mate van creativiteit toevoegen aan de oplossing(en)? Dit heeft betrekking op de vrijheid en verantwoordelijkheid die het ontwikkelteam krijgt. Naast deze drie aspecten zien we ook grote verschillen in de mate waarin het framework goed past binnen zeer grote organisaties, zoals banken, verzekeraars, energiebedrijven en telecomproviders. Sommige modellen geven wel antwoord op de vraag hoe een aantal teams samen kunnen werken als ze aan één product werken, maar bieden geen houvast als een organisatie gelijktijdig in meerdere markten actief is met een groot aantal producten of diensten. Tot slot is ook de complexiteit van het product bepalend voor het framework. Soms zijn bepaalde kernproducten of -diensten heel complex of juist niet; de organisatievorm zou zich daarbij aan moeten sluiten. Er ontwikkelen zich continu nieuwe frameworks om agile op te schalen. Dit maakt het lastig een goede vergelijking te kunnen maken. We analyseren een aantal bekende frameworks op de volgende onderdelen: Belangrijkste doel. Kerncomponenten en -proces(sen). Hoe scoort het framework op de criteria intradepencies, interdependencies, benodigde creatieve input, organisatiegrootte en complexiteit van het product. Zeer geschikt voor situaties waarin Minder geschikt voor situaties waarin 6 Whitepaper januari 2016 VODW

7 Analyse van vijf frameworks 1. Scrum of Scrums Scrum is de meest gebruikte methodiek voor individuele teams in agile georiënteerde ontwikkelorganisaties. Als meerdere teams in dezelfde organisatie scrum gaan gebruiken en deze teams groter worden dan negen personen, moeten ze worden gesplitst in meerdere scrumteams. Een logische stap is om zaken tussen de teams te coördineren. Een Scrum of Scrums is dan vaak de meest logische keuze: een dagelijkse of wekelijkse meeting waarin de team leads van de verschillende scrumteams werkzaamheden met elkaar afstemmen. Wat is scrum? Scrum is een van de meest gebruikte methodes waarmee je agile principes kunt toepassen in de projecten waaraan je werkt. Scrummen is werken in kleine team s van drie tot negen mensen, die met verschillende vaardigheden in korte periodes steeds nieuwe werkende tussenproducten afleveren en daar feedback op organiseren, tot je samen met de klant opgewekt beslist dat je bij het eindproduct bent (NRC Handelsblad, 2015). Scope Time Cost Agile Waterval Plan Driven Value & Vision Driven Time Cost Scope In tegenstelling tot de watervalmethode staan bij scrum de hoeveelheid tijd en het budget vast, maar is de scope (uitkomst) variabel. Scrum focust zich op het creëren van waarde in kleine stappen en brokken, waarbij voor de efficiëntie van het team geen veranderingen plaatsvinden in het doel van een sprint als deze eenmaal begonnen is. Scaling the agile organization Whitepaper januari 2016 VODW 7

8 Owner Backlog Team Sprint Backlog Input from end-users, customers, team and other stakeholders Team selects how much to commit to do by sprint s end Sprint planning meeting. Backlog Refinement Scrum Master manages sprint progress Daily Scrum Standup SPRINT 1-4 weeks Review with Owner No Changes in duration of goal Potentially Shippable Increment Retrospective Kerncomponenten en processen Er zijn een aantal essentiële personen en componenten in het scrumproces. Voordat teams beginnen met scrummen worden het doel en de bijbehorende randvoorwaarden bepaald waar het eindproduct aan moet voldoen. Het scrumteam moet bestaan uit mensen met verschillende expertises zoals marketeers, IT ers, analisten en UX-designers; afhankelijk van de expertise die nodig is om het doel van het team te behalen. De product owner is verantwoordelijk voor wat het team doet. Hij beheert de takenlijst (backlog) en stelt per sprint de prioriteiten in een sprintplanning. Een sprint is een korte periode van ongeveer één tot vier weken, waarin het team naar een concreet, vooraf gedefinieerd resultaat of tussenproduct werkt. De scrummaster zorgt dat iedereen de manier van werken begrijpt en omarmt. Zijn taak is ondersteunend en niet sturend zoals een manager. De scrummaster helpt bijvoorbeeld bij het oplossen van blokkades die zorgen dat een teamlid niet productief is en maakt hier eventueel een lijst 8 Whitepaper januari 2016 VODW

9 van (impediment list). Deze blokkades worden bespreekbaar gemaakt in een (daily) standup. Dit is een korte bijeenkomst, waarbij ieder teamlid aangeeft welke taken hij (die dag) gaat uitvoeren en wat zijn blokkades zijn. De status van de taken die de teamleden tijdens een sprint uitvoeren staat op het scrumboard. Voordat iemand aan een taak begint, moet duidelijk zijn wat de taak inhoudt. Het scrumteam controleert de taken hierop en scherpt ze aan. Dit noemen we een product backlog refinement. Na het uitvoeren van de taak is er een verschil tussen ready en done. Een taak is ready als deze helder, uitvoerbaar en testbaar is en done als deze getest is en goedgekeurd door de product owner. Alle taken die nog moeten worden uitgevoerd voordat het eindproduct klaar is, staan op de product backlog. De burndown chart geeft visueel aan hoeveel tijd er nog over is, afgezet tegen het werk dat nog gedaan moet worden. Het eindproduct noemen we ook wel Potentially Shippable Increment. Dit moet een zichtbare, concrete verbetering van een product of dienst zijn. Het lanceren van tussenproducten noemen we een (product) release. Na iedere release vindt er een feedbackmoment plaats, ook wel de sprint review genoemd. Het team laat een demo zien waar iedereen op kan reageren. Meestal direct na de sprint review vindt er nog een retrospective plaats, waarin het team terugkijkt op zijn prestaties en nadenkt over manieren om te verbeteren. Doel Het doel van Scrum of Scrums is het managen van de werkzaamheden van meerdere scrumteams vanuit een integraal perspectief. Het zorgt voor een gezamenlijke visie op het product waaraan gewerkt wordt. Daarnaast voorkomt het dubbele werkzaamheden (twee teams die werken aan dezelfde user stories) en verbetert het de integratie van functionaliteiten die in verschillende teams worden ontwikkeld. Zo voorkomt Scrum of Scrums silovorming en zorgt het voor synergie door deling van kennis tussen de verschillende teams. Een online marketingteam kan bijvoorbeeld Scrum of Scrums inzetten om de werkzaamheden van de scrumteams te coördineren die verantwoordelijk zijn voor de verschillende digitale momenten in de customer journey: de site, de verschillende apps, de selfcare omgevingen, et cetera. Scrum of Scrums zorgt hierbij voor waarborging van een integrale, digitale customer experience over de verschillende touchpoints die door de afzonderlijke teams worden ontwikkeld. Daarnaast zorgt Scrum of Scrums overleg voor een hogere teamproductiviteit doordat de teams learnings met elkaar delen. Kerncomponenten en -processen Per scrum wordt een lead aangewezen die deelneemt aan de coördinerende meeting. Deze lead kan een technisch expert zijn, een product owner, maar ook een scrummaster. Dit is afhankelijk van de context waarin een project zich bevindt en de uitdagingen die spelen. De frequentie van de Scrum of Scrums meeting kan wekelijks zijn, maar kan ook dagelijks plaatsvinden. De frequentie is hierbij sterk afhankelijk van de mate van afhankelijkheid en daarbij benodigde afstemming tussen de teams. Scaling the agile organization Whitepaper januari 2016 VODW 9

10 Scrum of Scrums Scrum team 1 Scrum team 2 Scrum team 3 Inhoudelijk wordt tijdens een Scrum of Scrums hetzelfde proces gehanteerd als bij een reguliere dagelijkse bespreking die ieder scrumteam normaal gesproken voert. Per team wordt gerapporteerd op afgeronde, lopende en nog te starten taken en op afhankelijkheden. Hierbij wordt gefocust op het oplossen van de onderlinge afhankelijkheden tussen de teams en de gezamenlijke afhankelijkheid van andere organisatieonderdelen. De Scrum of Scrums meeting is nadrukkelijk geen bespreking van scrummasters om te praten over de manier om het agile of scrumproces te verbeteren. Hoe past Scrum of Scrums bij de volgende criteria 1. Afhankelijkheden tussen teams 2. Afhankelijkheden tussen team en de organisatie 3. Benodigde creatieve input 4. Organisatiegrootte 5. Complexiteit van het product KLEIN KLEIN GROOT GROOT Zeer geschikt voor situaties waarin De organisatie al bekend is met de scrummethodiek. Scrum of Scrums is dan een logische vervolgstap. Het aantal scrumteams dat werkt aan een grotere, gezamenlijke visie/product beperkt is (maximaal negen teams met onderlinge afhankelijkheid). Wanneer sprake is van meer dan negen teams die onderling moeten afstemmen, wordt de Scrum of Scrums opgesplitst en wordt gewerkt met een scrum-of-scrums-of-scrums voor coördinatie tussen de Scrum of Scrums. 10 Whitepaper januari 2016 VODW

11 Minder geschikt voor situaties waarin Je behoefte hebt aan uitspraken over organisatiestructuur, processen, rollen en verantwoordelijkheden. Een echt framework voor scaling agile kan je Scrum of Scrums namelijk niet noemen, aangezien het eigenlijk niet meer is dan een set van coördinerende besprekingen. Het is daarom ook geen basis voor echte agile organisatietransformatie. (In lijn met voorgaande) organisaties waar grote aantallen scrumteams werken en de teams sterke onderlinge afhankelijkheden kennen. Voor coördinatie vanuit een centraal gedefinieerde concernstrategie volstaat het enkel hanteren van een Scrum of Scrums hierbij niet. Wel kan een dergelijk overleg een belangrijk instrument in een groter framework zijn. Meer weten over Scrum of Scrums? Lees verder op de website van Agile Alliance. Scaling the agile organization Whitepaper januari 2016 VODW 11

12 Analyse van vijf frameworks 2. Large Scale Scrum (LeSS) In de basis is LeSS het Scrum framework toegepast op organisaties met meer dan één scrumteam. LeSS combineert 10 basisprincipes met een aantal regels voor de structuur van teams en coördinatie tussen de teams. Een van de meest kenmerkende regels is dat ondanks dat er meerdere teams zijn, er maar één product owner is die de visie neerzet voor het gehele product. LeSS is bedacht door Craig Larman en Bas Vodde en biedt niet één maar twee agile scaling frameworks; één voor organisaties met minder dan acht teams en een aangepaste versie voor organisaties die met meer dan acht teams werken. Doel Het bieden van een scrummethodiek aan teams die werken aan productontwikkeling op grotere schaal dan een enkel scrumteam. Hierbij werken individuele teams niet onafhankelijk aan een eigen product, maar richten zich gecoördineerd op een gezamenlijk eindresultaat voor de klant. Kerncomponenten en -processen Net als bij een enkel scrumteam behoudt ook de met LeSS werkende organisatie één backlog voor alle teams en aan het einde van de sprint één concreet en tastbaar resultaat dat indien gewenst direct ingezet kan worden. Terwijl bij scrum de product owner zich actief richt op zowel het vullen en prioriteren van de backlog alsmede de verduidelijking van de user stories voor het team, ligt bij LeSS vooral de nadruk op het prioriteren. Voor de verduidelijking van de user stories is de product owner geen intermediair meer naar de markt en de klant, maar faciliteert hij het directe contact tussen het team en de echte klanten. Daardoor heeft hij meer tijd om het overzicht te bewaren. Zo wordt het team gedwongen echt samen met klanten te werken en met begrip voor klanten een oplossing te ontwikkelen. Craig Larman en Bas Vodde hebben als onderdeel van het LeSS framework ook het principe van feature teams geïntroduceerd. Waar in traditionele organisaties vaak gewerkt wordt met component teams met een focus op individuele specialismen, zijn feature teams multidisciplinair samengesteld zodat ze een compleet klantgericht product van start tot finish kunnen opleveren. De mensen in deze teams zitten daarom ook altijd bewust bij elkaar in de buurt, zijn voor 100% van hun tijd bezig in een team en het team is niet op projectbasis, maar permanent bij elkaar. 12 Whitepaper januari 2016 VODW

13 Owner Backlog Previous Sprint Sprint Planning 1 Sprint Planning 2 Sprint Backlog Feature Team Daily Scrum Scrum Master Coördination Sprint Backlog Feature Team Sprint Backlog Feature Team Daily Scrum Scrum Master Coördination Print review with Owner Sprint Backlog Feature Team two weeks two weeks Potentially Shippable Increment Retrospective Overall Retrospective Scaling the agile organization Whitepaper januari 2016 VODW 13

14 Hoe past LeSS bij de volgende criteria 1. Afhankelijkheden tussen teams 2. Afhankelijkheden tussen team en de organisatie 3. Benodigde creatieve input 4. Organisatiegrootte 5. Complexiteit van het product KLEIN KLEIN GROOT GROOT Zeer geschikt in situaties waarin Veel flexibiliteit en agility nodig is bij grote projecten. LeSS streeft namelijk een veel frequentere communicatie met afvaardigingen van de verschillende teams na dan bijvoorbeeld het SAFe framework. Minder geschikt in situaties waarin De organisatie tegelijkertijd aan meerdere producten werkt, waarbij coördinatie tussen die producten nodig is. De technische architectuur en het platform dat implementatie na één sprint kan waarmaken ontbreekt. LeSS focust namelijk op één tastbaar resultaat dat direct te gebruiken is en dat voortvloeit uit de gezamenlijke teams. Ondanks de redelijk uitgebreid beschreven principes en organisatiestructuur hangt LeSS sterk op elementen uit de scrummethodiek en lijkt het in de praktijk daardoor sterk op een pure vorm van scrum. Meer weten over LeSS? Bekijk dan de website. 14 Whitepaper januari 2016 VODW

15 Analyse van vijf frameworks 3. Het Spotify model Spotify s aanpak om agile te schalen was nooit bedoeld als framework en meer als een set van principes, maar kreeg wereldwijde bekendheid door de diepgaande beschrijving van Kniberg en Ivarsson. Een van de belangrijkste waarden in het model is de mate van decentralisatie en het extreem grote vertrouwen dat wordt gesteld in het team, dat bij Spotify een squad heet. Dit vertrouwen wordt in de aanpak van Spotify direct vertaald naar gedelegeerde verantwoordelijk met zeer weinig aan- of bijsturing van hogerhand. Een squad is een zelfsturend team dat verantwoordelijk is voor een stukje van het totale eindproduct. De teams bestaan uit mensen met verschillende expertises, zoals marketeers, data-analisten, IT ers, UX-designers, et cetera. De samenstelling is afhankelijk van het doel van het team. Door op deze manier te werken heeft Spotify, ondanks haar explosieve groei haar aanpassingsvermogen en innovatiekracht behouden. Doel Snelheid van innovatie en klantgerichte productontwikkeling bij Spotify. Kerncomponenten en -processen In eerste instantie gebruikte Spotify voor de beschrijving van haar aanpak vaak de metafoor van de mini startup, maar nu verschuift ze de nadruk naar aligned autonomy. Doordat de nadruk op cultuur ligt, wordt bijvoorbeeld ook de keuze van agile methodieken zoals scrum, Kanban of LeSS overgelaten aan iedere squad. Daarnaast zijn typische managementverantwoordelijkheden verdeeld over de rollen van squad, tribe, chapter en guild lead. Voor traditionele managers kan deze manier van werken beangstigend zijn, omdat ze hierdoor grip verliezen op het proces en niet meer exact kunnen voorschrijven wat er moet gebeuren. Er zijn parallellen te trekken tussen het Spotify model en het LeSS framework, maar Spotify heeft het model wel flink aangepast aan de eigen organisatie. Kopieer dus nooit zomaar een populaire best practice zonder verdere analyse. Het implementeren van een framework dat op de uitgangspunten van Spotify is gebaseerd kun je dus het beste iteratief uitrollen met als uitgangspunt dat je zeer waarschijnlijk aanpassingen moet maken. Scaling the agile organization Whitepaper januari 2016 VODW 15

16 Wat betekent Spotify in het kader van scaling agile? Net als bij scrum werkt Spotify met een product owner die verantwoordelijk is voor wat het team doet. Deze persoon beheert de product backlog en stelt de prioriteiten. Een team bestaat uit vier tot negen mensen, die verantwoordelijk zijn voor het realiseren van een vooraf vastgestelde (klantgerichte) missie. Een squad is opgebouwd uit mensen met verschillende expertises, zoals IT ers, marketeers, data-analisten en UX-designers. Tribe Tribe Tribe lead Owner Owner Owner Owner Tribe lead Owner Owner Owner Owner Chapter Chapter Chapter lead Chapter Guild Chapter Guild lead Als squads aan gerelateerde of dezelfde elementen van een systeem of product werken dan vormen ze vaak tribes. Een tribe bestaat uit verschillende squads die doelen hebben die elkaar raken en zorgt voor overleg tussen deze squads. Een tribe bestaat nooit uit meer dan 150 mensen. Een tribe lead zorgt dat kennis en inzichten tussen squads gedeeld worden, stelt prioriteiten en alloceert de budgetten. Ook is deze persoon het gezicht van de tribe naar andere tribes in de organisatie. Bij Spotify is het delen van leerervaringen en stimuleren van innovatie over de squads heen geregeld in informele groepen genaamd chapters en guilds, die zich vormen rondom bepaalde specialismes (zoals testers) of thema s. Een chapter is een groep waarin mensen uit verschillende squads, maar met dezelfde expertise (bijvoorbeeld data-analyse) bij elkaar komen om van elkaar te leren hoe ze met bepaalde uitdagingen omgaan. De chapter lead van bijvoorbeeld de chapter data-analyse is verantwoordelijk voor de persoonlijke ontwikkeling, coaching en performance van de data-analisten. Als laatste zijn er guilds: dit is een groep mensen met verschillende interesses en expertises uit verschillende tribes. Deze groepen stimuleren de samenwerking en het uitwisselen van best practices tussen de tribes. 16 Whitepaper januari 2016 VODW

17 Hoe past Spotify bij de volgende criteria 1. Afhankelijkheden tussen teams 2. Afhankelijkheden tussen team en de organisatie 3. Benodigde creatieve input 4. Organisatiegrootte 5. Complexiteit van het product KLEIN KLEIN GROOT GROOT Zeer geschikt voor Culturen waarin initiatief en zelf verantwoordelijkheid nemen al is ingebed. Organisaties (of onderdelen ervan) die (functioneel) redelijk ontbundeld zijn. Marktsituaties waarbij reageren op diverse consumentenbehoeften belangrijk is. Minder geschikt in situaties waarin Je behoefte hebt aan een duidelijk uitgeschreven framework wat je op jouw organisatie kunt toepassen. Net als Lean is Spotify s aanpak niet in eerste instantie gericht op het beschrijven van processen en structuren, maar meer op cultuur. Hierdoor wordt het moeilijker het model te kopiëren. De onderwerpen waar de squads zich mee bezighouden met elkaar verweven zijn of producten gebundeld zijn. Dit kan bij een complexere, omnichannel klantreis resulteren in een inconsistente klantervaring, omdat veel squads werken aan ervaringen in dezelfde klantreis. Bij Spotify gebruiken ze dan ook maar een beperkt aantal kanalen. De organisatiecultuur nu ver afstaat van de vertrekpunten van agile. Deze organisaties zullen veel moeite hebben zich aan te passen aan een Spotify model. Bij de aanpak van Spotify kun je zeker parallellen zien met het LeSS framework, maar het is aangepast aan de specifieke behoefte van de Spotify engineering organisatie. Voor meer informatie kun je naast de eerder genoemde beschrijving ook de recent gepubliceerde tweedelige interactieve beschrijving van de engineer cultuur bekijken. Scaling the agile organization Whitepaper januari 2016 VODW 17

18 18 Whitepaper januari 2016 VODW

19 Analyse van vijf frameworks 4. Scaled Agile Framework (SAFe) SAFe is wellicht het meest bekende en meest gestructureerde framework voor het inzetten van agile op grote schaal. Het framework gaat uit van drie organisatieniveaus: portfolio, program en team. Het beschrijft voor ieder niveau rollen en processen. Daarnaast is het framework van SAFe constant in ontwikkeling. Versie 4.0 ging op 3 januari dit jaar live en de vijfde SAFe iteratie zal ongetwijfeld binnenkort weer starten. Doel De nadruk ligt in eerste instantie op samenwerking en afstemming op enterpriseniveau, met als belangrijkste onderdeel een bedrijfsbrede, meerdaagse release planningsessie die veelal ieder kwartaal plaatsvindt. Dit is het antwoord van SAFe op een van de kernvraagstukken van scaling agile: hoe stem je in een organisatie met veel agile werkende teams de afhankelijkheden tussen verschillende teams af? En hoe zorg je vervolgens voor de aansluiting met de business strategie? Deze planningsessie is een soort Scrum of Scrums, alleen dan met alle teamleden en met meer centrale regie over welke teams welke prioriteiten oppakken. Kerncomponenten en -processen In SAFe wordt op het hoogste niveau (portfolio) gerelateerd werk samengevoegd onder bepaalde strategische thema s. Aan die thema s worden twee typen projecten, epics genoemd, gekoppeld die concrete invulling geven aan die thema s. Business epics zijn klantgeoriënteerde initiatieven, zoals de lancering van een nieuw product. Architectuur epics zijn bedrijfsbrede technologie-initiatieven zoals het openstellen van functionaliteit via API s. Samen vormen deze epics de portfolio backlog. Op het middelste niveau (program) wordt bepaald wat de functionele componenten zijn van de releases. Op operationeel niveau (team) wordt ten slotte gewerkt aan user stories, backlog beheer en het implementeren van nieuwe functionaliteit. Scaling the agile organization Whitepaper januari 2016 VODW 19

20 Agile release train 1. Program Backlog 2. Kwartaal release planning Roadmap Vision Management Functional experts Management Epics Business Owners Owner Scrum/Agile Master 3. Team Backlog 4. Gezamenlijke release Features Owner 1. Pr Ba Functional experts Agile Team Scrum/Agile Master Business Owners Roadmap Vision Features Functional experts Owner Scrum/Agile Master Management E Agile Team 3. Team Backlog Features Owner Functional experts Scrum/Agile Master Agile Team Features Features 20 Whitepaper januari 2016 VODW Features

21 Portfolio Portfolio vision Strategic Themes Kanban Portfolio Backlog Program portfolio management Epic owners Portfolio Metrics Enterprise architect Budgets Program Backlog Business Epic Architectual Epic Business Epic Agile release train Epics Agile release train Epics Agile release train Epics Value Streams deliver solutions Scaling the agile organization Whitepaper januari 2016 VODW 21

22 Hoe past SAFe bij de volgende criteria 1. Afhankelijkheden tussen teams 2. Afhankelijkheden tussen team en de organisatie 3. Benodigde creatieve input 4. Organisatiegrootte 5. Complexiteit van het product KLEIN KLEIN GROOT GROOT Zeer geschikt in situaties waarin Scrum of Scrums in combinatie met één product owner niet meer volstaat. SAFe biedt structuur bij het opschalen van de agile organisatie, met name als het de IT organisatie overstijgt. Dit framework geeft bovendien meer houvast op het niveau van programmamanagement dan LeSS of Spotify. Er behoefte is aan een betere voorspelbaarheid met betrekking tot de inhoud van releases. Ieder team neemt namelijk voor een aantal sprints een deel van de backlog voor zijn rekening en in principe is de scope van de release daarmee vastgezet. Er behoefte is aan een geleidelijke invoer van het model. Anders dan het LeSS of Spotify model start SAFe namelijk vaak met een enkel strategisch speerpunt van de organisatie. Nu nog erg in silo s wordt gewerkt. Deze aanpak past dus vaak goed bij grote, meer traditionele organisaties. De organisatie nu nog moeite heeft twee keer per jaar een substantiële verbetering van producten of diensten in de markt te lanceren. Minder geschikt in situaties waarin Er behoefte is aan agility van de organisatie en de teams. Een deel van de agility gaat namelijk verloren, omdat voor een aantal sprints wordt vastgelegd welk team verantwoordelijk wordt voor een aantal items op de backlog. Zaken die af zijn, gaan minder vaak dan bij andere werkvormen onmiddellijk live, maar wachten vaak tot de lancering die elk kwartaal staat gepland. Dat betekent niet dat geen continuous delivery mogelijk is (IT-taal voor continue verbetering aan de site maken) of plaatsvindt binnen SAFe, maar meer dat er voor bepaalde features of user stories afhankelijkheden kunnen zijn waardoor iets moet wachten tot het einde van de release. De organisatie al in staat is om minimaal maandelijks nieuwe software of online systeemcomponenten te lanceren. Het gaat hier dan niet om cosmetische verbeteringen aan de user interface, maar daadwerkelijk nieuwe functionaliteit. Dan biedt SAFe misschien teveel structuur. 22 Whitepaper januari 2016 VODW

23 Ondanks de uitwerking van het framework op drie niveaus is SAFe nadrukkelijk ontwikkeld als antwoord op de problematiek van zeer grote organisaties bij het inzetten van agile en dus minder geschikt voor kleinere organisaties met een beperkt aantal teams. Een van de belangrijkste zichtbare verschillen is dat SAFe echt gericht is op periodiek face-to-face overleg met alle leden van alle teams te faciliteren, terwijl LeSS een veel frequentere communicatie met afvaardigingen van de verschillende teams nastreeft. LeSS zou daardoor misschien iets beter passen in een omgeving waar veel flexibiliteit (en agility) nodig is en SAFe iets beter bij grotere traditionele organisaties met meer legacy systemen die langzaam veranderen en meer afstemming noodzakelijk maken. Meer informatie over SAFe vind je hier. Scaling the agile organization Whitepaper januari 2016 VODW 23

24 Analyse van vijf frameworks 5. Hybride vormen van waterval en agile Naast de verschillende methodieken en frameworks om agile op grote schaal in te zetten is het belangrijk te onderkennen dat sommige organisaties onbewust of bewust soms ook met hybride vormen van agile en traditionele watervalaanpakken werken. De literatuur praat dan over wet agile, the agile waterfall en the agile waterfall hybrid. De puristen vinden dergelijke combinaties controversieel en niet passen, maar er zijn situaties te bedenken waarbij het de beste oplossing kan zijn. Bijvoorbeeld bij bedrijven die zowel software en hardware ontwikkelen in een product- of dienstenconcept. Of bedrijven die bepaalde fasen in een proces op een watervalmanier willen aanpakken en andere meer iteratief... Een goed gedocumenteerde case is in 2013 beschreven door Erick Bergmann en Andy Hamilton over Schneider Electric. Bij Schneider Electric werken de softwareteams volgens agile principes en de hardware-ontwikkelingsteams en het gehele productmanagementteam volgens watervalaanpak. De agile softwareontwikkeling vindt nog steeds iteratief plaats, van conceptontwikkeling en feasibility studies tot aan validatie en productie. Afstemming met de product roadmap en hardware development teams is veelvuldig, zowel bij het opstellen van requirements tot aan integratietesten tussen hardware en software. Het nadeel is natuurlijk dat de softwareteams zich moeten houden aan de harde deadlines uit het projectplan, maar dat de gehele organisatie wel sneller een beter product in de markt kan zetten omdat de software iteratief wordt ontwikkeld. Doel Organisaties die bewust langdurig een hybride structuur kiezen hebben meestal als doel meer efficiëntie en slagkracht te creëren voor onderdelen van de organisatie die met kortere iteraties en hogere innovatiesnelheid willen opereren en tegelijkertijd de voordelen van de watervalmethode behouden voor andere organisatieonderdelen. 24 Whitepaper januari 2016 VODW

25 Hoe past de hybride vorm bij de volgende criteria 1. Intradepencies 2. Interdependencies 3. Benodigde creatieve input 4. Organisatiegrootte 5. Complexiteit van het product KLEIN KLEIN GROOT GROOT Zeer geschikt in situaties waarin Organisaties zowel aan hardware als software werken. Software wordt ontwikkeld die niet of niet makkelijk via continuous delivery aan klanten kan worden gegeven en waarbij dus veel planning vooraf nodig is. Requirements moeten worden goedgekeurd door externe partijen, zoals overheidsinstanties. Minder geschikt in situaties waarin De overgrote meerderheid van de ontwikkelteams hoofdzakelijk aan online systemen zoals websites en mobile apps werkt. De marktsituatie snelle en veelvuldige aanpassing van het product of de dienst vereist. Scaling the agile organization Whitepaper januari 2016 VODW 25

26 Conclusie Door in iets meer detail de doelen en kernprocessen van de verschillende frameworks te analyseren en ze te vergelijken op basis van een aantal criteria zoals intradepencies, interdependencies, benodigde creatieve input, organisatiegrootte en complexiteit van het product wordt het duidelijker dat de keuze van een framework organisatiespecifiek is. Daarnaast spelen de huidige en gewenste organisatievorm en de processen een rol. Te denken valt aan het aantal teams en hun locatie (verspreid of allemaal in één gebouw), de frequentie waarmee nu en idealiter in de toekomst aanpassingen moeten worden uitgevoerd en de behoefte en noodzaak aan centrale aansturing. Uiteraard kan ook de huidige (marketing)technologiearchitectuur een beperkende factor vormen. Is het nu überhaupt mogelijk snel een verbetering in productie te nemen, of vergt dat afstemming met andere afdelingen en teams en een planning van maanden? Bovendien is het goed te beseffen dat op papier je best veel verschillen kan vinden in de verschillende frameworks, maar dat in de realiteit organisaties die bijvoorbeeld LeSS of SAFe gebruiken veel overeenkomsten vertonen. Bijvoorbeeld door het gebruik van een mix van feature en component teams. Deze whitepaper is een introductie op de theorie achter scaling agile met handvatten om het juiste model te selecteren. Met deze inzichten en het overzicht van de agile scaling frameworks kunnen de meeste organisaties wel concluderen dat één van de reeds gedefinieerde modellen goed bij hun situatie past. Als we vasthouden aan de agile filosofie dan is het ook goed mogelijk om iteratief op een model verder te ontwikkelen. Los van bovenstaande vijf frameworks, zijn er nog vele andere methodes en principes voor het schalen van agile. DAD, RAGE, Scrum at Scale, Scaled Professional Scrum, DSDM, Enterprise Scrum en XSCALE worden niet in deze whitepaper besproken, maar zijn wel de moeite waard om te analyseren. 26 Whitepaper januari 2016 VODW

27 Begrippenlijst Burndown chart: grafiek die aangeeft hoeveel tijd er nog over is afgezet tegen het werk wat nog gedaan moet worden. Chapter: groep waarin mensen uit verschillende squads, maar met dezelfde expertise (bijvoorbeeld data-analyse) bij elkaar komen om van elkaar te leren hoe ze met bepaalde uitdagingen omgaan. Scrummaster: zorgt dat iedereen de manier van werken begrijpt en omarmt. Zijn taak is ondersteunend en niet sturend zoals een manager. De scrummaster helpt bijvoorbeeld bij het oplossen van blokkades die zorgen dat een teamlid niet productief is en maakt hier eventueel een lijst van (impediment list). De scrummaster is geen project manager met managementautoriteit. Chapter lead: persoon die verantwoordelijk is voor de persoonlijke ontwikkeling en coaching bij problemen waar experts tegenaan lopen en performance van squadleden. (Daily) standup: korte bijeenkomst waarbij ieder teamlid aangeeft welke taken hij (die dag) gaat uitvoeren en wat zijn blokkades zijn. owner: persoon die verantwoordelijk is voor wat een scrum team of squad doet. Deze persoon beheert de product backlog en stelt de prioriteiten op basis van de visie en doelstellingen van het team, zodat het team maximale waarde creëert voor de volgende release. Potentially shippable product increment: het product dat een scrumteam oplevert. (/sprint) backlog: to do lijst met alle taken die nog gedaan moeten worden om het vastgestelde doel te bereiken. backlog refinement: aanscherping van taken zodat deze duidelijk genoeg zijn om mee te beginnen. Scrumteam: multidisciplinair team dat bestaat uit mensen met verschillende expertises, zoals marketeers, IT ers, analisten en UX-designers, die samen toewerken naar een gezamenlijk einddoel. Sprint: korte periode van ongeveer één tot vier weken, waarin het team naar een concreet, vooraf gedefinieerd resultaat of tussenproduct werkt. Sprint review: feedbackmoment waarbij een team de output van de sprint presenteert in een demo en beoordeelt. Squad: team dat bestaat uit vier tot negen mensen, die end-to-end verantwoordelijk zijn voor het realiseren van een vooraf vastgesteld (klantgericht) doel. Een squad is opgebouwd uit mensen met verschillende expertises, zoals IT ers, marketeers, data-analisten en UX-designers. Tribe: groep die bestaat uit verschillende squads die doelen (purposes) hebben die elkaar raken en zorgt voor overleg tussen deze squads. Een tribe bestaat nooit uit meer dan 150 mensen. () release: het lanceren van (tussen)producten om te testen, zodat het team gericht verbeteringen kan doen en prioriteiten kan stellen voor de volgende sprint. Retrospective: terugblik van het team op zijn prestaties, waarbij de teamleden nadenken over hoe zij dingen in de volgende sprint anders of beter kunnen doen. Scrumboard: bord waar alle taken en de bijbehorende status op staan. Tribe lead: persoon die zorgt dat kennis en inzichten tussen squads gedeeld worden, stelt prioriteiten en alloceert de budgetten. Ook is deze persoon het gezicht van de tribe naar andere tribes toe. User story: beschrijven van een product- of dienstkenmerk vanuit het perspectief van de eindgebruiker, bestaande uit het type gebruiker, wat hij wil en waarom. Scaling the agile organization Whitepaper januari 2016 VODW 27

28 Vragen of opmerkingen over dit document? Of wil je weten welk framework het best bij jouw organisatie past? Neem dan contact op via onderstaande gegevens. Michael Klazema in/klazema Margot Schreuders in/margotscheuders