Overslaan en naar de inhoud gaan

agile

Uitdagingen in de kansspelmarkt: Een blik op heden en toekomst
Inhoud De dynamiek van de kansspelmarkt heeft de laatste jaren een constante stroom van verandering en aanpassing gekend. Echter, de afgelopen jaren hebben we een ongekende versnelling van verschuivingen en uitdagingen gezien die de industrie op haar grondvesten hebben doen schudden. Vanuit het perspectief van de bedrijven in deze branche zijn er hordes genomen, maar er blijven ook nieuwe uitdagingen opdoemen die aandacht en voorbereiding vergen. De aankondiging van het verbod op ongerichte gokreclames en sponsoring, welke inging in juli 2023, markeerde een significante omwenteling. Het jaar 2023 bracht een nieuwe realiteit voor kansspelaanbieders, waarin het beperken van reclames voor risicovolle online kansspelen en het geleidelijk uitfaseren van sponsormogelijkheden centraal staan. Dit heeft de manier waarop bedrijven hun merk en aanbod presenteren ingrijpend veranderd. Hoewel deze maatregelen gericht zijn op het beschermen van kwetsbare groepen, hebben ze bedrijven ertoe gedwongen hun marketingstrategieën opnieuw te evalueren en creatieve manieren te vinden om zich te onderscheiden binnen de nieuwe grenzen.   Legaal De legalisatie van online kansspelen bracht nieuwe kansen met zich mee, maar bracht ook nieuwe verantwoordelijkheden voor bedrijven in de branche. Het vinden van de juiste balans tussen het aantrekkelijk maken van legale aanbiedingen en het voorkomen van ongezond speelgedrag is een continue uitdaging geworden. Hoewel deze balans cruciaal is voor het succes van bedrijven, blijft het een uitdaging om innovatieve manieren te vinden om spelers te betrekken zonder hen aan te hoge risico's bloot te stellen. Naast de huidige uitdagingen is het belangrijk om te anticiperen op wat nog kan komen. Een van de urgente kwesties is het verkrijgen van nauwkeurige identificatiegegevens van spelers. Het ontbreken van een wettelijke basis voor toegang tot deze gegevens bemoeilijkt effectief toezicht en handhaving. Dit kan bedrijven blootstellen aan risico's en het vermogen van toezichthouders om illegale activiteiten tegen te gaan beperken.   Verslaving Het CRUKS, bedoeld om kansspelverslaving tegen te gaan, heeft niet het gewenste effect gehad vanwege het lage aantal onvrijwillig ingeschreven personen. Bedrijven in de branche moeten samenwerken met toezichthouders om dit instrument effectiever te maken en te voldoen aan de behoeften van degenen die risico lopen. Offline kansspelen blijven ook een focuspunt, aangezien veranderende omstandigheden en technologische ontwikkelingen de behoefte aan een modernere aanpak aantonen. Herstructurering van de huidige regelgeving is aannemelijk om effectief toezicht te kunnen houden en tegelijkertijd beleidsveranderingen te weerspiegelen. Als we vooruitkijken, zien we een complex landschap van uitdagingen en kansen voor bedrijven in de kansspelmarkt. Het is cruciaal dat bedrijven proactief samenwerken met toezichthouders en beleidsmakers om een veilige, eerlijke en verantwoordelijke omgeving te creëren. De evolutie van de industrie zal doorgaan en bedrijven moeten zich aanpassen, innoveren en blijven leren om succesvol te blijven opereren. In deze tijd van verandering kunnen bedrijven in de kansspelmarkt een positieve impact hebben door samen te werken aan duurzame groei en het bevorderen van verantwoord spelen. Alleen door gezamenlijke inspanningen kunnen we een omgeving creëren waarin de belangen van alle belanghebbenden worden gerespecteerd en beschermd. Benieuwd naar wat Mavim voor jouw organisatie kan betekenen bij het voldoen aan de Wet op de Kansspelen? Lees er hier meer over! Door: Ramon Bruijnesteijn, Business Development Representative bij Mavim
Agile werken? Maar dan wel ‘all the way’!
Inhoud Voorheen betekende ‘technology push’ dat de techniek vooropliep en de klant of gebruiker het nauwelijks kon bijbenen: hij remde de snelheid van de ontwikkelingen omdat zijn adoptievermogen te gering was. Tegenwoordig is het omgekeerde aan de orde: nieuwe technologie maakt de klant of gebruiker nog hongeriger, hij adopteert snel en wakkert de push verder aan. Zie hier de uitdaging voor het management, dat moet acteren in deze dynamische context waarin snelheid en innovatie het verschil maken. Bovendien heeft het management intern te maken met de nodige uitdagingen (tijd, geld, bestaande infrastructuur, verandervermogen) die nopen tot het maken van keuzes en stellen van prioriteiten. Om aan te sluiten op almaar versnellende ontwikkelingen is het noodzakelijk de planningshorizon op strategisch niveau hierop aan te passen. Agile is het sleutelwoord. ICT speelt in de dynamiek een cruciale rol. Op het gebied van functionaliteit, snelheid en integriteit. Maar ook de ontwikkelingen voor de techniek onder de motorkap gaan snel en hebben veel impact (bijvoorbeeld cloudtechnologie of security). Genoeg reden om de besturing van groei en innovatie aan te laten sluiten bij de voorlopersrol die ICT hierin met agile voortbrengingsmethoden heeft opgeëist. Agile betekent wendbaar en deze duiding is de spijker op z’n kop. De meeste agile methoden zijn het bekendst vanwege hun toepassing binnen applicatieen softwareontwikkeling. Er wordt gewerkt met iteraties, kleine opzichzelfstaande projecten die steeds iets bruikbaars opleveren. Teams zijn multidisciplinair en het eigenaarschap is geborgd in de rol van de product owner. Voorbeelden van agile methoden zijn kanban, scrum en het Scaled Agile Framework.   ICT-besturing Veel organisaties hanteren – nog steeds – voor het besturen van ICT het robuuste negenvlaksmodel (van Rik Maes) of varianten daarop. Het model lijkt vanwege zijn eenvoud en praktische bruikbaarheid de tand des tijds glansrijk te doorstaan. Het kent drie lagen en drie kolommen waardoor negen vlakken ontstaan. De lagen betreffen strategie (richten, scope 3 tot 5 jaren), tactiek (inrichten, scope 1 tot 3 jaren) en operatie (verrichten, scope tot 1 jaar). De drie kolommen representeren het businessdomein, het informatievoorzieningsdomein en het technologiedomein. Maar hoe bruikbaar is het model nu nog, gelet op de eerder beschreven uitdagingen waar bedrijven voor staan? Past een strategische scope van 3 tot 5 jaar, of een tactische planningshorizon van 1 tot 3 jaar nog wel? De indeling in de drie genoemde horizontale lagen roept associaties op met de bekende watervalmethode. Op strategisch niveau worden voor een langere termijn domeinen benoemd, die ‘onomkeerbaar’ zijn en dus rigide worden doorgegeven aan het tactische niveau, de waterval volgend. Op dit niveau worden vervolgens nieuwe applicaties ontwikkeld die passen binnen de strategische domeinen. Ook applicatieontwikkeling zelf is veelal langs de route van de waterval gelopen. Als reactie op deze traagheid en onomkeerbaarheid zijn agile methoden zoals bekend tegenwoordig gemeengoed geworden.   Agile en het negenvlaksmodel Als we de agile methoden projecteren op het negenvlaksmodel dan zien we in eerste instantie toepassing binnen vlak 5, waar softwareontwikkeling plaatsvindt. De tactische planningshorizon verkleint hierdoor sterk: van 1 tot 3 jaar naar maximaal 3 maanden of zelfs 3 weken of 3 dagen! Multidisciplinaire teams met vertegenwoordigers uit de business, klanten en ICT-specialisten doen de agile-olievlek uitbreiden naar vakken 4 en 6 op tactisch niveau. Wie het boek The Phoenix project door Gene Kim, Kevin Behr en George Spafford heeft gelezen begrijpt dat iteraties ook direct en snel in productie genomen kunnen worden. Er zijn bedrijven die duizenden ‘deployments’ per dag realiseren. Vertaald naar het negenvlaksmodel betekent dit een uitbreiding van de agile-olievlek naar het operationele niveau, vlakken 7, 8 en 9. De agile-benadering neemt snel toe en werpt zijn vruchten af. Het lijkt erop dat alleen de strategische, richtende laag zich nog aan dit agile-geweld moet aanpassen.   Agile werken in de strategische, richtende laag De traditionele strategische planningscyclus voor bedrijfs-, informatievoorzieningsen ICT-strategie past niet meer bij de tijdshorizon op inrichtend en verrichtend niveau. Strategieontwikkeling wordt kortcyclischer: herijking en bijsturing eens per 3 maanden is eerder aan de orde. Natuurlijk is er een richtpunt op de meerjarenhorizon maar ook die is ernstig aan verandering onderhevig. Dit betekent een aanpassing in het strategisch planningsproces voor organisatie en instrumentarium. Een goede en bewezen aanpak om dit te organiseren is een of meerdere ‘radarteams’ te vormen. Radarteams zijn multidisciplinaire teams die voortdurend de markt van technologie-aanbod, de klantbehoeften en gedrag van concurrentie scannen. In ‘sprints’ van 3 maanden doen ze aanbevelingen over het implementeren van nieuwe toepassingen. Zowel waar het digitaliseren van het primaire en ondersteunende processen betreft, maar ook aangaande toepassing van nieuwe ICT-technologie onder de motorkap. Ook het instrumentarium op het strategisch kortcyclisch niveau zal veranderen. Zo bieden geavanceerde simulatietechnieken de mogelijkheid om effecten van toepassing van digitalisering te voorspellen en te kwantificeren. Bijvoorbeeld: hoeveel extra callcentercapaciteit is er nodig na de introductie van een app voor het afsluiten van een autoverzekering? Een ander instrument is het zogeheten digitaliseringsambitie-grid. Dit grid is het resultaat van een per sprint uit te voeren scan en is vooral bedoeld om de gehele organisatie betrokken te houden bij de ontwikkelingen. De scan speelt in op het feit dat, ingegeven door snelle ontwikkelingen, de digitaliseringsgraad en prioriteiten voortdurend verschuiven. In het grid worden, als uitkomst van interviews en workshops, alle primaire en ondersteunende processen geplot in een diagram met op de assen de digitaliseringsgraad en prioriteit. Idealiter zijn deze in lijn met elkaar op de diagonale as. Met name voor de processen in het vierde kwadrant rechtsonder (hoge prioriteit, lage digitaliseringsgraad) is er werk aan winkel. De resultaten uit de scan zijn dan richtinggevend voor de opdrachten aan product owners in het tactisch en operationele domein.   Van langetermijnbeleidsplan naar kwartaaldashboard Het negenvlaksmodel blijft als ordeningskader prima bruikbaar voor ICT-besturing. Door toepassing van agile methoden, in eerste instantie op de tactische en operationele lagen, wordt wel de cyclustijd drastisch verkort. Daarnaast is het traditionele onderscheid tussen business en IT aan het verdwijnen. Dit vereist vervolgens aanpassing van de werkwijze op strategisch niveau, door ook hier agility te introduceren. Door op dit niveau voortdurend de markt te scannen op de bruikbaarheid en toepasbaarheid van technologische ontwikkelingen en hierover met een kwartaalfrequentie aanbevelingen en implementatievoorstellen te doen wordt strategievorming agile. Het strategisch denken wordt sneller en kortcyclischer, maar ook spannender met een grotere kans op fouten of verkeerde inschattingen. Echter, waar staat geschreven dat management en directies geen fouten mogen maken? Drie jaren wachten tot een volgende strategische herorie?ntatie of een strategieontwikkeling met een doorlooptijd van 6 maanden zijn echt geen optie meer. Management zou zich daarmee loskoppelen van de tactische en operationele agile werkelijkheid. Bij dezen nemen we dus afscheid van documenten getiteld ‘Informatiebeleidsplan 2016 – 2019’ en omarmen het digitale en dynamische dashboard ‘Q3 -2016: implementatieaanbevelingen radarteam digitale trends en ontwikkelingen’.Auteurs: Henk Stienstra en Remko ZuidgeestMeer weten over agile werken? Lees hier meer over 'de weg naar continue verbetering'
De schone schijn van documentatie
Inhoud Agile wordt vaak gezien als alleen maar programmeren en niets documenteren. Documentatie lijkt het ondergeschoven kindje. Onterecht, zeggen Nicole de Swart en Rini van Solingen. De rol van documentatie verandert, maar zij is niet overbodig. Vijf misverstanden over agile en documentatie. Veel organisaties stappen over op agile systeemontwikkeling om sneller software te kunnen ontwikkelen en sneller te kunnen reageren op nieuwe vragen uit de markt. Snelheid en wendbaarheid worden gezien als cruciale randvoorwaarden voor de toekomst. Kort-cyclisch leveren van werkende en geteste software staat daarbij centraal. Documentatie lijkt dan al snel het kind van de rekening te worden. Voor je het weet start de volgende sprint en is er geen tijd om te documenteren wat er in de vorige is opgeleverd. Dit voedt het misverstand dat het in agile alleen maar gaat om programmeren zonder te documenteren (zie kader). Dit vooroordeel lijkt ook bevestigd te worden door de tweede regel van het Agile Manifest, waarin werkende software boven uitgebreide documentatie wordt gesteld. De waarheid is genuanceerder. Ja, agile stuurt meer op directe resultaten en producten dan op tussenresultaten en documenten. Ja, documentatie wordt gezien als ondersteunend en niet als leidend. Ja, met een agile werkwijze is doorgaans minder documentatie nodig. Maar nee, agile betekent niet alleen maar programmeren en niets documenteren. Agile is focussen op het leveren van zoveel mogelijk waarde, iedere sprint opnieuw. Ook ten aanzien van documentatie wordt daarom een kritische houding verwacht. Niet als vanzelfsprekend alles documenteren, maar bewust afvragen waarvoor die documentatie nodig is en of er geen betere alternatieven zijn.   Twee soorten documentatie De behoefte aan documentatie verandert bij agile werken. Om dit toe te lichten is het nodig onderscheid te maken tussen documentatie ten behoeve van het voortbrengingsproces (vooraf nodig voor het bouwen van de juiste software) en systeemdocumentatie (die achteraf samen met de software wordt opgeleverd). In agile wordt de eerste soort documentatie, voor het voortbrengen van de software, voor een belangrijk deel vervangen door rechtstreekse interactie tussen het ontwikkelteam en de gebruikers. Alle betrokkenen zijn hierbij aanwezig en er worden alleen korte statements, via user stories, vastgelegd als geheugensteun. Daarnaast is in agile via intensieve samenwerking binnen multidisciplinaire teams de informatieoverdracht tussen de teamleden geregeld. Hierdoor is er tijdens het voortbrengingsproces ook minder behoefte aan documentatie. Een duidelijk voorbeeld van documentatie ten behoeve van het voortbrengingsproces is requirementsdocumentatie. Traditioneel werd die documentatie regelmatig ook gebruikt als systeemdocumentatie, die beschrijft wat er is gemaakt. Dat lijkt efficiënt, maar hoe gedetailleerd de requirementsspecificaties ook zijn, het wil niet zeggen dat de uiteindelijke software er ook aan voldoet. Het gevolg is dat de documentatie later weer aangepast moet worden. Dat is niet alleen dubbelwerk, maar ook foutgevoelig en bovendien is er aan het einde van het project meestal te weinig tijd. Kortom de betrouwbaarheid liet nog al eens te wensen over. Systeemdocumentatie blijft echter ook bij agile belangrijk. Deze documentatie wordt alleen niet eenmalig aan het einde gemaakt, zoals we dat traditioneel gewend waren, maar iteratief opgeleverd. Elke twee weken als er een nieuwe versie van het systeem uitkomt, is er ook een bijgewerkte set van de systeemdocumentatie. En hoeveel werk kan dat zijn, als het maar over twee weken gaat? Daarnaast kan de systeemdocumentatie ook minder uitgebreid zijn dan in traditionele projecten. Dat komt door de stabiele samenstelling van agile teams. Ze blijven namelijk langer bij elkaar dan alleen de duur van een project. Een dergelijk team ontwikkelt niet alleen nieuwe software maar blijft deze ook zelf onderhouden. Uiteindelijk stelt zo’n team de systeemdocumentatie dus voor zichzelf op. En niet, zoals we traditioneel gewend waren, voor anderen die het systeem in beheer nemen en die niet bij de ontwikkeling betrokken waren.   Toegevoegde waarde De toegevoegde waarde van documentatie zit hem in het overbruggen van tijd (dingen onthouden) en/of het overdragen van informatie aan mensen die niet aanwezig waren. Het gaat dus om kennisborging. Vaak wordt vergeten dat documentatie niet de enige manier is om kennis te borgen. Men gaat er impliciet vanuit dat als iets niet gedocumenteerd is dat dat dan tevens betekent dat die kennis verloren gaat. Maar dat is niet waar. Kennis zit immers in de hoofden van mensen en niet in documenten. Kortom, door agile werken verdwijnt de toegevoegde waarde van (traditionele) documentatie voor een belangrijk deel. De beweging naar multidisciplinaire en stabiele agile teams zorgt ervoor dat kennisoverdracht minder via documenten verloopt. Maar eigenlijk was dat altijd al een misverstand. De gedachte dat wanneer iets ‘op papier’ staat, gelijk zou staan aan ‘in de hoofden van mensen zitten’, was altijd al schone schijn. We zien in de praktijk, dat ondanks de populariteit en successen met agile werken, er tegenkrachten ontstaan die juist sterk sturen en leunen op documentatie. SLA’s, uitbestedingscontracten op basis van fixed scope, outsourcingspartners die alleen bouwen op basis van specificaties, beheerafdelingen die uitgebreide documentatie eisen, voorbereidingsteams die zeer ver vooruitlopen op de agile teams, een ‘uw vraagt/wij draaien houding’ bij ontwikkelteams, RFC-processen et cetera. Vooralsnog ligt het punt waarop alles en iedereen agile werkt nog ver in de toekomst. In de tussentijd zal er nog steeds behoefte zijn aan (te) veel documentatie.Auteurs: Nicole de Swart & Rini van Solingen, Automatiseringsgids
Agile op grote schaal: hoe minder hoe beter
Inhoud Agile en Scrum zijn gemeengoed. Zelfs multinationals stappen erop over. Maar past dat wel? Agile is toch juist bedoeld voor kleine organisaties? Volgens Henk Jan Huizer, Martin Vodegel en Rini van Solingen wordt het schalen van agile vaak verkeerd begrepen. Zij beschrijven acht aandachtspunten om agile toe te passen op grote schaal. Scrum toepassen is niet meer bijzonder. Agile als begrip en Scrum als meest gebruikte aanpak zijn inmiddels mainstream. Ook grote organisaties gaan volop met agile aan de slag. Soms in een enkel project of met een paar teams, maar tegenwoordig veel vaker op grote schaal. De vraag hoe je agile doet op grote schaal is daarom erg actueel en wordt steeds vaker gesteld. Agility op grote schaal is een systematische en gestructureerde poging om een groot aantal teams agile met elkaar te laten samenwerken. Natuurlijk volgens dezelfde principes die aan de basis liggen van agile in die team. Veel Scrum-teams hebben, wil dus helemaal niet zeggen dat er op grote schaal agile wordt gewerkt. Als het namelijk op overkoepelende schaal niet goed is geregeld, dan komen de resultaten niet sneller en wordt het geheel niet beter. En het gaat uiteindelijk om die snelheid en wendbaarheid voor de klant. Sommige organisaties spreken zich bijvoorbeeld trots uit dat ze meer dan 250 Scrum-teams hebben. Als die teams niet goed op elkaar zijn afgestemd, dan blijft de impact van deze teams voor de klant beperkt. Er zijn misschien wel 200 teams te veel.   Integratie De eerste vraag in grote organisaties is hoe men de teams zodanig inricht dat ze zelfstandig kunnen werken. Doordat het bestaande IT-landschap vaak sterk verzuild is en bestaat uit vele losse applocaties, is de eerste neiging om de nieuwe agile teams te plotten op de bestaande systemen. Een enkel team krijgt dan de verantwoordelijkheid over één enkele applicatie of één component. Een team kan dan zelfstandig de planning en uitvoering doen op die applicatie, en de product-owner prioriteert het werk voor dat team. Zodoende is agile opschalen in grote organisaties vaak het verdelen van teams over systemen. Echter, de waarde voor de klant zit in de combinatie van deze systemen. Zodoende is men vaak zonder het door te hebben, een waterval van procesfasen aan het vervangen door een waterval van teams. En dan duurt het nog steeds maanden voor een nieuwe dienst of feature bij de uiteindelijke klant terechtkomt. En hoe agile is dat? Het is van het grootste belang bij agile op grote schaal vanaf de allereerste dag de focus te leggen op het integratievraagstuk over teams heen: om zo kort mogelijke ketens van teams te maken die warde leveren voor de eindklanten. Het concept van 'end-to-end value' en 'value streams' helpt daarbij. Oook schalingsraamwerken kunnen helpen. Zo introducteert SAFe (Scaled agile Framework) bijvoorbeeld het concept 'release train'. Daarin zit het zelfstandig en snel leveren van waarde aan eindklanten door een beperkte hoeveelheid teams geborgd. Dit vereist wel aanpassingen in de organisatie die verder gaan dan bestaande teams met Scrum te laten werken.   "Vaak vervangt men een waterval van procesfasen door een waterval van teams"   Ontschalen Men is al snel aan het schalen. De dynamiek van schaling treedt al op als je met een paar agile teams aan de slag bent. Zeker in grote organisaties waar veel afhankelijkheden aanwezig zijn. Agile werken 'verknipt' namelijk een organisatie in kleine zelfstandige teams. Daardoor is het noodzakelijk om actie te ondernemen: om planning en resultaten weer bij elkaar te brengen. Wat het meest essentiële is, klinkt heel tegenstrijdig: 'ontschaling'. Ontschaling is een doorlopend streven om de behoefte aan agile op grote schaal te voorkomen. De complexiteit in het IT-landschap moet daarom omlaag. Alleen dan kan een situatie tot stand komen waarin een beperkt aantal teams gezamenlijk, elke twee weken, waarde voor de klant kan opleveren. Agile op grote schaal vraagt dus feitelijk niet om opschalen maar om ontschalen. Hoe moeilijk dat ook is. Alleen wanneer grote organisaties in staat zijn om, ondanks hun omvang, zeer frequent software te releasen, pas dan is agile op grote schaal echt gelukt.   Aandachtspunten bij het schalen van agile Schaal door focus te leggen op directe klantwaarde. Voorkom een focus op interne processen en interne bijdragen van teams. Neem daartoe value streams als uitgangspunt. Dat is namelijk de dimensie waarlangs klanten merken dat er iets verandert. Laat product-owners vanuit de business helpen bij het definiëren en prioriteren van de value streams. Zij hebben namelijk vaak het beste inzicht. Vereenvoudig het IT-landschap. Het opzetten van complexe schalingsconstructies met veel rollen en processen komt vaak door het omzeilen van het echte probleem: de noodzakelijke versimpeling van een complex IT-landschap. Een belangrijke reden voor het gebrek aan snelheid zit vaak in een sterk versnipperd IT-landschap vol afhankelijkheden. Dat is op zichzelf niet zo verrassend: Conway's law uit 1967 leerde ons reeds dat de architectuur van een IT-systeem een afspiegeling is van de organisatiestructuur. Sterk verzuilde organisaties hebben zodoende ook de neiging om sterk verzuilde IT-landschappen voort te brengen. En die zijn doorgaans niet erg wendbaar. Een vereenvoudiging van het IT-landschap begint vaak bij een vereenvoudiging van de organisatie zelf. Start met continuous delivery vanaf het begin. Bij agility op grote schaal heeft men vaak de neiging om het integratievraagstuk uit te stellen vanwege de complexiteit. Men begint dan met agile werken op teamniveau, waarbij elk team deelproducten oplevert maar de integratie over de teams niet of laat gebeurt. Continuous delivery zorgt ervoor dat integratie vroeg en vaak plaatsvindt. Continuous delivery is voorwaardelijk om met agile op schaal te kunnen werken. Elke ontwikkelaar moet binnen een uur feedback vanuit een automatische integratietest krijgen om integratieproblemen vroegtijdig te kunnen oplossen. Daarnaast is de continuous delivery een katalysator voor eenvoud. Het is namelijk ondoenlijk om sterk verkleefde en complexe oplossingen met continuous delivery aan te pakken. Tijdens de implementatie van continuous delivery gaan teams automatisch aan de slag met vereenvoudiging van de architectuur. Gebruik een schalingsaanpak niet als blauwdruk. Pas bijvoorbeeld SAFe niet klakkeloos toe. Maak liefst een eigen schalingsmodel dat past bij de eigen situatie, de klanten, systemen en bekende knelpunten. Het Spotify-model werkt perfect voor Spotify. Het kopiëren van de schalingsoplossing van een ander werkt alleen als het probleem en de context identiek zijn en dat helaas maar zelden het geval. Maak ook niet de fout om denken en doen te scheiden. Als bijvoorbeeld SAFe wordt gebruikt, zorg er dan nog steeds voor dat de experts uit de teams meedoen op programma- en portfolioniveau. Zorg dat de basis op orde is. Als teams veel onderlinge afhankelijkheden hebben, is het zaak dat teams betrouwbaar opleveren. In een keten van bijvoorbeeld vijf teams, waarbij elk team 80% van de planning haalt, bestaat de kans dat de keten niets oplevert. Bij elke sprint kan er namelijk één team zijn dat een cruciaal onderdeel niet op tijd klaar heeft, waardoor het eindresultaat niet werkt. Teams moeten dus in een schalende organisatie sterk voorslebaar zijn en proactief afstemming zoeken. Daartoe is het cruciaal om product-backlogmanagement goed op orde te hebben. Het is namelijk in de praktijk gebleken dat de meest voorkomende bron achter onvoorspelbare teams ligt in het ontbreken van een goed uitgekristalliseerde product-backlog. Maak onderscheid tussen waarde- en componententeams. In de ideale situatie is elk team in staat om zelfstandig waarde voor de klanten op te leveren. Dan beslaat het team een complete value stream. In veel gevallen lukt dit echter niet en wordt om uiteenlopende redenen gewerkt met teams die een of meerdere componenten onderhouden en ontwikkelen. En al die componenten moeten dan weer geïntegreerd worden. Maak onderscheid tussen twee soorten teams: waarde/featuretemas en ondersteunende/componentteams. De eerste teams ondersteunen een value stream of een feature voor klanten. Zij leveren dus zelfstandig klantwaarde. Daarnaast kunnen er ook ondersteunende- of componentteams zijn. Zij zetten componenten of applicaties klaar die door de waarde/featureteams gebruikt kunnen worden. Vergeet niet de governance aan te passen. De aanwezige governance past zelden bij grootschalig agile werken. Deze governance is namelijk een verankering van de oude verzuilde organisatie. Als een organisatie agile op grote schaal wil toepassen, dan moet de governance worden aangepast. Meestal vraagt dit om rigoureuze aanpassingen, die niet op voorhand helder zijn. Het is daarom raadzaam de governance stap voor stap te (her)ijken. Installeer een 'Scaling Master'. Voorkom grote discussies en variëteit aan oplossingsvarianten. Maak iemand verantwoordelijk om het opschalen van agile te leiden. Dit is een tijdelijke rol gedurende het inrichten van grootschalig agile werken. Het invullen van die rol helpt bij het maken van een keuze en het snel doorvoeren van de benodigde veranderingen. Deze Scaling Master moet natuurlijk wel een expert zijn op het gebied van agile op grote schaal, hij moet alle boeken hebben gelezen en alle trainingen hebben gevolgd.       Auteurs: Hank Jan Huizer, Martin Vodegel en Rini van Solingen

Copyright © 2024 Mavim B.V.