Betekenis geven aan de Agilerituelen is een van de belangrijke taken die een scrum master en RTE hebben. Wanneer je dit niet doet is het directe gevolg dat mensen zich hardop afvragen waarom hun aanwezigheid gewenst is. Indirect is de schade echter nog veel groter: de rituelen verliezen hun kracht om veranderingen en productrealisatie effectief te sturen. Een van die aspecten waar een Scum Master of RTE tijdens de PI planning betekenis aan moet geven, is het coachen van de Agile Release Train en de Business Owner op het samen vaststellen van goede Business Objectives.
Het hebben van goede en goed gedragen business objectives leidt tot focus en de juiste gesprekken of binnen de ART tijdens de increment de juiste dingen gedaan worden. Het niet hebben van goede en goed gedragen business objectives leidt er bijna altijd toe dat de verwachtingen van de business owner en de stakeholders afwijken van wat de Agile Release Train werkelijk oplevert. Met alle teleurstelling die daarbij hoort.
Onvoldoende betrokkenheid van Business Owners leidt tot teleurstelling over opgeleverde resultaten.
Na de overgang naar het SAFe werken en een Agiletransformatie, ervaren veel organisaties een nieuwe structuur van Agile Release Trains, Program Increments (PI) en PI planningen. Ondanks de voortgang in het transformeren naar een agile organisatie, blijft de snelheid en invulling van strategische doelstellingen vaak achter. Business Owners zijn vaak nog niet voldoende betrokken en hebben daardoor geen duidelijk beeld van wat ze kunnen verwachten. Dit resulteert regelmatig in teleurstelling over opgeleverde resultaten. Zelfs als er een goed draaiende ART is, dragen de opgeleverde Features mogelijk beperkt bij aan de hogere organisatiedoelen. Een gesprek tussen de Business Owner en de ART over PI Objectives kan deze uitdagingen aanpakken.
Toch zal niet elke organisatie dit herkennen en worstelt men in het begin geregeld met het vertalen van de strategie in goede PI Features. Of er zijn juist zoveel Features dat men door de bomen het bos niet meer ziet. Met PI objectives kun je de focus houden op wat echt belangrijk is en die Features die het meeste bijdragen aan de strategische doelen voorrang geven. Hieronder lees je wat dit zijn en hoe je ze gebruikt.
PI planning: de magie van het framework
Eerst even terug naar de basis: waarom kiezen organisaties voor een PI-cadans met PI planning-events? Volgens de SAFe-auteurs bestaat er geen SAFe zonder PI planning. Sterker nog: zij noemen de PI planning de magie van het framework. De kracht van het event zit erin om in een 2-daagse sessie van strategie tot realisatieplanning te komen. In het event zit een feedbackloop verweven die de problemen van de teams expliciet op de tafel van de beslissers legt. Zo kan een team dat een nieuw product ontwikkelt er tijdens het plannen van de Features erachter komen dat er specifieke kennis nodig is van buiten het team. Er kan dan diezelfde dag nog door de directie besloten worden om een expert daarvoor vrij te maken. Door het transparant maken van wat er nodig is om tot resultaten te komen wordt het eenvoudig om hiervoor de juiste beslissingen te nemen.
PI objectives beschrijven wat er bereikt zal zijn als het PI succesvol is; Wat kan de organisatie na de realisatie gedurende een increment dat het voorheen nog niet kon? PI objectives zijn in de basis simpel: een lijstje bulletpoints met 7-10 concrete doelen voor het komende Program Increment, doorgaans 8 tot 12 weken. Deze doelen moeten realistisch en haalbaar zijn en duidelijk bijdragen aan de doelen van de organisatie waar een ART deel van uitmaakt. Goede vragen om jezelf te stellen bij het opstellen van de PI objectives zijn: -Welke functionaliteit is gereleased?; -Hoeveel extra gebruikers zijn bereikt?; -Welke kosten zijn bespaard? Voorbeelden zijn: “Eerste product verkocht in de app” of “Een werkende feedbackknop op de website”.
PI Objectives laten stakeholders de waarde herkennen zonder alle Feature-details te begrijpen, tonen afhankelijkheden, en hoe stakeholders kunnen bijdragen aan de doelen.
Belangrijk voor PI Objectives is dat de stakeholders van de ART de waarde ook eenvoudig herkennen. Het geeft ze daarmee een goed beeld van wat ze kunnen verwachten zonder elke Feature te moeten begrijpen. Daarnaast maakt het afhankelijkheden inzichtelijk en toont het hoe stakeholders kunnen helpen om de gestelde doelen te realiseren. Een voorbeeld: “Om een product te kunnen verkopen in de app is nodig dat Finance het facturatieproces ondersteunt”. Dat geeft de Finance stakeholder een duidelijke taak mee voor het PI.
Door de PI Objectives te scoren en ordenen maak je helder van welke objective je de grootste bijdrage verwacht aan de organisatiedoelen.
Hoe stel je goede PI Objectives op?
Volg het stappenplan hieronder:
De Product manager(s) stelt (stellen) een eerste versie van PI Objectives op, vanuit de productdoelen en Features voor het PI. Wat zijn de belangrijkste doelen voor dit PI?
Op het PI plannen de teams Features in en wordt duidelijk wat wel en niet gepland kan worden.
De ART teams bepalen hun doelen op teamniveau, gebaseerd op Features die ze dit PI plannen. Deze Teamobjectives geven aan welke hogere doelen het team met deze Features wil bereiken. Een goede checkvraag hierbij is: wanneer heeft het team een succesvol PI? Belangrijk om deze doelen SMART te maken, zodat het team hier tijdens het PI op kan sturen.
Op basis van de eerste versie van de geplande Features en teamobjectives stelt de Product manager de PI Objectives op.
De Release Train Engineer toetst de Objectives bij de teams op haalbaarheid zodat zij zich eraan kunnen committeren.
Wanneer de PI Objectives definitief zijn kan de Product Manager deze scoren van 1-10 op waarde.
De Product Manager deelt de PI Objectives met de ART en haar stakeholders. Door ze transparant te maken en gedurende het PI als referentie te gebruiken blijft de ART de belangrijkste doelen in het vizier houden. Dit start bij de PI confidencevote en loopt door in PO Syncs en Sprint Reviews tot de afsluitende Inspect & Adapt sessie.
Geef betekenis aan Business Objectives om het SAFe-model effectief te gebruiken en te sturen op waarde in plaats van opgeleverde Features
Naast de gecommiteerde PI Objectives kan de ART ook niet-gecommitteerde objectives opnemen. Dit zijn doelen die wel waardevol zijn, maar waaraan de teams zich niet met zekerheid kunnen committeren dat ze deze kunnen afronden binnen het PI. Oorzaken hiervan zijn externe afhankelijkheden, of er is nog grote onzekerheid in de exacte uitkomst van wat er gebouwd wordt, of nog onvoldoende kennis van de tool waarmee gewerkt wordt. Door deze objectives wel te benoemen en ervoor te plannen, maar niet op te committeren verhoog je de betrouwbaarheid van de ART. De business owner weet nu waar zeker op gerekend mag worden en wat op basis van best effort gedaan wordt.
Door te werken met PI Objectives zijn de doelen samengevat in voor iedereen begrijpbare taal. Succescriteria zijn expliciet, concreet én hebben commitment van de teams. Business Owners hoeven zich niet volledig te verdiepen op alle features en stories en snappen direct waar de ART zich op richt, maar belangrijker: op welke prestatie van de ART ze mogen rekenen. Door met elkaar de juiste betekenis te geven aan Business Objectives kun je het SAFe-model effectief inzetten waar het voor bedoeld is, namelijk het sturen op waarde (outcome) in plaats van opgeleverde Features (output).
Heb je ook een uitdaging om businessdoelstellingen te bereiken in een agile omgeving? Wil je meer weten over het gebruik van PI Objectives? Neem dan contact op via info@towson.nl en één van onze consultants helpt je graag verder!
Wanneer je gaat veranderen ga je een onzeker traject in. Wat doet zo’n verandering van de situatie met jou? Hoe kun je je hier goed op aanpassen? En als het niet zo gaat als je vooraf dacht, wat dan? Vanuit een heel herkenbare situatie schrijft Remco Klompmaker over zijn bijdrage aan de energietransitie en hoe zijn aanpassingsvermogen (en dat van zijn gezin) werd getest.
De wereld om ons heen verandert constant: kijk naar de klimaatverandering en de energietransitie die daaruit voortvloeit, of de oorlog in Oekraïne die hier, maar ook op andere ambities, direct impact op heeft. Kortom: we zijn constant onderdeel van een transformatie of organiseren, binnen een verandering, onze eigen transformatie.
In het kader van de energietransitie vertel ik je over een experiment als de start van een persoonlijke transformatie, en wat mijn ervaring hierin was. Ondanks dat dit een overzichtelijk experiment was als start van een verandering, verschilt het proces niet zoveel van de veranderingen die we op grote schaal doen.
Mijn transitie
Onlangs was het weer tijd om een nieuwe leasewagen te kiezen en wat kies je dan? Elektrisch, fossiel of hybride aangedreven auto?
De eerste vragen waren er direct:
Wat gaat dit mij extra kosten?
En heb ik dat ervoor over?
Wat voor impact heeft dat op mijn woon/werk verkeer.
Wat voor impact heeft dat op mijn privésituatie?
Allemaal vragen waar je voor jezelf een antwoord op moet vinden in combinatie met hoe je tegen de benodigde verandering aan kijkt. En dán loop je vervolgens nog aan tegen vragen als: Hoeveel heb je er dan voor over, hoeveel ben je bereid zelf te investeren?
Ik heb de keus gemaakt om vanuit mijn motivatie een bijdrage te willen doen aan de klimaatverandering en heb daar iets extra’s voor over gehad. Met de levering van de wagen bleek dit echt, want het rijden in een elektrische auto vereist een andere houding.
Voor mij is de transitie de nieuwe auto en de transformatie dat ik anders moet rijden met deze auto en anders mijn routes ga plannen om efficiënt met de laadtijd om te gaan. Ineens moet ik nadenken wanneer ik ga laden en hoe groot mijn bereik is. Kortom, om de auto optimaal te kunnen gebruiken zal ik mijn oude gewoontes moeten afleren of bijstellen.
Wat is er veranderd dan?
Ik hoef in Nederland niet meer naar een tankstation. Ik laad de auto thuis op.
De auto rijdt anders en als ik snel rij heeft dat direct veel meer impact op mijn bereik dan een benzineauto en daarmee de afstand die ik kan afleggen. Met harder rijden moet ik toch nog een extra pauze inlassen om even bij te laden. Wil ik een extra stop of rij ik langzamer en ben ik dan sneller thuis? Ik kwam er al snel achter dat mijn rijgedrag aangepast moest worden.
Het experiment:
De eerste vakantie, een reisje naar Frankrijk, werd echt een uitdaging. Ik was nieuwsgierig naar het experiment en heb mijn familie weten te overtuigen om dit met de nieuwe elektrische wagen te gaan ondernemen. Na hun goedkeuring konden we gaan plannen.
Ik noem het een experiment omdat ik nog erg onbekend ben met het rijden van een heel lange afstand en tegen welke uitdagingen je dan werkelijk aanloopt. Hoe gaat de familie daarmee om? En wordt het een succes en willen we het na deze reis ooit nog eens proberen of blijft het bij deze ene keer?
Behalve de onzekerheid en het ongemakkelijke ben ik natuurlijk ook benieuwd wat voor positieve dingen het brengt. Het kan zomaar lukken en een groot succes zijn.
Het doel:
Het doel is gekozen: “Toulouse bij vrienden in huis”. De onzekerheid voor de eindstop en tijdig moeten arriveren was daarmee weggenomen. En de Franse familie hadden we al een tijdje niet gezien, dus dat was een leuk vooruitzicht.
De heenreis:
Daar waar ik normaal gesproken met de maximum toegestane snelheid zeer efficiënt naar het zuiden van Frankrijk reed en met 1 tankbeurt al op locatie aan kom moest ik het nu anders gaan aanpakken.
Internet was (nog niet) mijn beste vriend. Er stond al wel veel geschreven maar toch was ik er niet gerust op. Er was nog veel onzekerheid over de laadpalen, hoe te betalen, snelheid van het laden in combinatie met mijn rijgedrag en de buitentemperatuur. Oh ja… die buitentemperatuur heeft dus ook ineens invloed op mijn rijafstand. Dat was ik niet gewend!
Voor de zekerheid heb ik extra pasjes gekocht naast de laadpas die ik bij de auto meegeleverd heb gekregen. Dat was een goede tip die mij al veel problemen heeft bespaard. Ik heb een route gepland met de laadpunten die ik nodig had om op de plaats van bestemming te komen.
Ik had gelezen dat de Tesla superchargers ook voor niet-Tesla’s waren opengesteld maar kon geen ervaringen terugvinden op internet. Ik heb 20 apps gedownload die aangaven te weten waar alle laadpalen stonden. Na er 15 weer verwijderd te hebben heb ik de meest betrouwbare laten staan, hopende dat ze tijdens de reis nog konden helpen als het fout ging.
Ok, route bepaald en laadpunten in Google Maps geplaatst om te gebruiken met Carplay. Ook voor de zekerheid in de navigatie van de auto gezet. Tijdstip vertrek 7:00 uur in de ochtend en uitgerekende aankomst om 20:00 uur inclusief 5 stops om te kunnen laden.
Daar reden we weg om 7:15, beginnend met een achterstand op het schema van 15 minuten. Met een 100% volle accu ben ik gestart met een snelheid van 100 km per uur zodat ik een langere range had. Het had gevroren dus ik merkte al snel op dat, als ik harder ging rijden dan 100km per uur, de ingeplande reserve van 100 km accu slonk naar 90km. Maar vanwege de onzekerheid wilden we die 100km reserve wel hebben. Stèl dat een laadstation niet werkt dan sta je stil. Een extra kannetje met benzine gaat hier niet lukken en ook mijn accu van de telefoon zal de auto niet verder brengen.
2e oponthoud was de ochtendspits bij Antwerpen. Die was te verwachten en hadden we met de conventionele wagen ook gehad.
Daar kwam de eerste stop aan. Ik had als eerste laadpunt gekozen voor een Tesla supercharger die sinds kort ook in het buitenland beschikbaar waren voor niet-Tesla’s. Maar eenmaal op locatie bleek dat deze dus niet voor mij beschikbaar was. De reden voor het Tesla laadstation te kiezen is dat er veel laadpalen zijn en ze altijd werken. Dus als eerste maar ervaring opdoen met deze laadlocaties zodat ik er later voordeel uit kon halen.
Dus: op zoek naar een andere laadlocatie. Dit heeft ons zeker 30-45 minuten extra tijd gekost.
De 2e stop was in de binnenring van Parijs bij een Tesla snellaadstation bij een winkelcentrum. Eindelijk! Dat ging goed en het was erg gezellig. We hadden immers tijd om even samen rond te kijken.
Gedurende de dag kwamen we er al achter dat het langzamer ging dan gedacht: 2/3e van de dag voorbij en nog niet eens op de helft van de route. En het volgende laadstation werkte niet. Ook hier weer op zoek naar een andere. Deze andere lag in de buurt maar was geen supercharger. Dus geen 30 minuten laden maar 1 uur. Dus gelijk maar wat eten want het was inmiddels 18:00 uur, zodat we dat niet meer hoefden te doen.
Gelukkig ging het daarna wat sneller en naarmate ik ervaring kreeg met het laden, en omdat de buitentemperatuur was opgelopen naar 17 graden, kon ik ook harder gaan rijden zonder in te boeten op reserve. 110 – 120 was een mooie snelheid en bleek voldoende reserveaccu over te houden.
Om 23:30 kwamen we aan op ons adres in Toulouse en werden we welkom geheten met een lekkere Franse wijn en kaas.
De terugreis
Met de ervaring van de heenreis werd het plannen al simpeler. Ik wist welke laadpalen wel en niet werkten en hoe ik dat kon zien in de apps. Ook wist ik welke laadpassen wel werkten en welke niet.
Hiermee ging de terugreis al een stuk sneller.
Alle geplande laadpunten werkten en we hoefden niet meer te zoeken naar een alternatief. Ik heb de hele terugreis 110-120 km per uur gereden waardoor ik ook al beter opschoot.
Tja… En dan kom je weer in Parijs, maar nu tijdens de spits. Dat was niet geheel onverwacht en ik heb bewust gekozen voor een laadbeurt tijdens de spits. Na het vertrek hadden we toch nog een staartje van de spits wat met een conventionele auto hetzelfde was geweest.
Met een vertrek van 9:15 en aankomst om 23:45 uur hebben we het een stuk efficiënter gedaan dan de heenreis.
Reflectie op mijn experiment
Dit verhaal brengt me weer terug bij de vragen over Transitie en het managen van verandering: “Hoe organiseer je dat?” en “Is daar een draaiboek voor dat je uitrolt?”.
De transitie was bij mij de nieuwe auto die anders was dan een conventionele fossiele brandstofaangedreven wagen. De Transformatie was voor mij het feit dat ik de dingen anders moest gaan doen, zoals laden, rijden, en plannen van mijn rit.
Ik ben me bewust geworden dat de transitie erg veel onzekerheid met zich meegebracht waar ik opties open moest laten om eventueel met het geleerde bij te kunnen sturen.
De verandering zorgt dat je moet transformeren om je doelen te kunnen behalen.
Transformatie betekent verandering van mindset en skills naar een nieuwe mindset en skills die je nog niet hebt ervaren en waarvan je niet weet hoe die er precies uit gaat zien. Dat moet je immers nog gaan ervaren en van gaan leren. Het leren zal in kleine stapjes gaan. De ene keer gaat het goed en de andere keer fout waardoor je het anders moet doen.
Er is geen draaiboek dat je 1:1 kunt uitrollen; daarvoor zit er teveel onzekerheid in omdat je het nog nooit eerder hebt ervaren. Een plan maken blijkt nog steeds verstandig om de risico’s te identificeren en ruimte in te bouwen voor de opties als het anders gaat dan verwacht.
Accepteer en calculeer in dat je plan niet loopt zoals gepland en dat je dat weer snel kunt bijsturen met de opgedane ervaring of experimenten.
Communiceer het met je collega’s zoals ik mijn familie in het plan heb meegenomen zodat het niet alleen mijn experiment is.
Als laatste te beantwoorden vraag: “Wat voor positieve elementen heb ik eraan overgehouden?”.
Als gezin kwamen we erachter- doordat we rekening hadden gehouden met vertraging- dat niemand heeft geklaagd tijdens de heen- en terugreis. Het was zelfs ontspannener dan de traditionele gehaaste reizen die we voorheen hebben gemaakt.
We hebben beide reisdagen als gezellig ervaren omdat we tijd hadden voor elkaar en om even te ontspannen.
Ik hoop dat mijn relaas je heeft kunnen aanzetten tot denken en doen. Mocht je meer willen weten, of hulp nodig hebben: laat het mij vooral weten: stuur een mail naar info@towson.nl of neem telefonisch contact op: 085 877 0180.
…en het positieve effect op resultaat en voorspelbaarheid
door Peter Turien
Wanneer ik bij opdrachtgevers te gast ben, hoor ik nog steeds met grote regelmaat de verzuchting dat teams in deze organisaties niet de verwachtte of nodig geachte resultaten leveren. De oorzaak van het niet betrouwbaar leveren van de teams wordt dan bijna altijd binnen deze teams gezocht. De oorzaak kan echter ook voor een groot deel in de verhouding en samenwerking tussen het managementteam en de organisatie liggen. De effectiviteit van de organisatie wordt mede bepaald door de opstelling van de leiders. Deze kant van het “leveringsprobleem” wordt regelmatig onderbelicht.
Omdat de oorzaak in eerste aanleg bij de leverende teams zelf wordt gezocht, wordt er teamcoaching ingezet. Coaches gaan dan met deze teams aan de slag met bijvoorbeeld de piramide van Lencioni om vanuit vertrouwen naar resultaat te komen. Nu ben ik een warm voorstander van de inzet van teamcoaching (en ook van Lencioni), maar dit lost alleen het probleem op wanneer de oorzaak van het probleem daadwerkelijk in de teams zit.
Wanneer teamcoaching niet de gewenste resultaten oplevert is het tijd om ook eens heel goed naar de leiders van een organisatie te kijken en naar hun manier van aansturing. Want de oorzaak van onvoorspelbare teams en lage kwaliteit leveren kan ook een leiderschapprobleem zijn, doordat de leiders van een organisatie een managementteam vormen in plaats van een leadershipteam.
Om aan te geven hoe ik het verschil zie tussen een managementteam en een leadershipteam: Een managementteam streeft een resultaat na, deelt dit doel en geeft de organisatie aan welke bijdrage ze verwacht. De bijdrage wordt gemeten om te zien of de organisatie daadwerkelijk het resultaat haalt, en er wordt indien nodig bijgestuurd.
Een leadershipteam streeft een resultaat na, vraagt de organisatie welke bijdrage ze hieraan kan leveren, en wat er nodig is om samen het doel te behalen.
Het verschil zit in de kunst van het loslaten door de leiders en de juiste ruimte te geven. Alleen wanneer de leiders van een organisatie medewerkers de juiste ruimte geven, zullen medewerkers verantwoordelijkheid nemen en zich kunnen committeren aan een resultaat.
In mijn voorbeeld van een managementteam, neemt dit team alle verantwoordelijkheid voor het resultaat en sluit de rest van de organisatie bijna automatisch aan op basis van “best effort”. Teams en medewerkers kunnen geen eigenaarschap nemen voor commitments die door anderen zijn beschreven.
In mijn voorbeeld van een leadershipteam worden de teams uitgenodigd om gezamenlijk verantwoordelijkheid te nemen. De teams kunnen aangeven wat ze haalbaar achten en kunnen daarmee ook verantwoordelijkheid nemen voor hun werk. Hierdoor wordt het doel dat een organisatie probeert te behalen, een gezamenlijk doel. Daarmee zijn organisaties met leadershipteams waar de verantwoordelijkheid voor het resultaat laag in de organisatie genomen wordt, naar mijn mening, op de langere termijn gemeten effectiever dan organisaties waar een managementteam resultaatverantwoordelijkheid neemt.
Kortom, investeren in zelfsturende teams is goed, maar niet voldoende. Organisaties moeten ook investeren in de transformatie van managementteams naar leadershipteams. De kunst van het juist loslaten wordt verzilveringsmiddel op voorspelbaarheid en de kwaliteit van de te leveren producten.
Om als managementteam een leadershipteam te worden is de Piramide van Lencioni een effectieve leidraad om de relatie met de teams te herdefiniëren. Echter: in plaats van bij “vertrouwen” te beginnen en ons een weg door de piramide naar boven te werken naar “resultaat”, is het in dit geval effectiever om te beginnen bij het niveau resultaat.
Door als leadershipteam goed te articuleren wat de missie en visie van de organisatie zijn en welke resultaten behaald moeten worden, weten de teams in de organisatie waar ze zich op dienen te concentreren. Het gesprek tussen het leadershipteam en de organisatie kan dan gaan over hoe we herkennen dat resultaten behaald worden. Het voeren van het gesprek langs de as van duidelijk uitgesproken doelen en gewenste resultaten is de basis voor de leadershipteams om te vragen welke bijdrage de teams kunnen leveren. Door de mate van de bijdrage door de teams te laten bepalen, wordt teams de ruimte geboden om verantwoordelijkheid te nemen.
De cynische manager zegt nu: “Als ik het aan de teams overlaat krijg ik nooit wat ik wil”.
De praktijk heeft echter bewezen dat de mensen in een organisatie die geen manager zijn wel degelijk naar het werk komen om de beste bijdrage te leveren.
Het kan natuurlijk zo zijn dat de ambitie van de organisatie niet alligned is met waar de teams verantwoordelijkheid voor kunnen nemen. En dit is precies het cruciale moment waar leadershipteams zich onderscheiden van managementteams en de betrokkenheid bij de teams tonen.
Dit kan enerzijds door de teams te vragen of er een ondersteuning mogelijk is waarmee de teams de verantwoordelijkheid wel kunnen nemen voor de ambitie die het leadershipteam geuit heeft. En vervolgens aan de andere kant het te accepteren wanneer de teams aangeven dat ze, ondanks het aanbod voor hulp, niet meer verantwoordelijkheid kunnen nemen. Dit is in het begin zeker even wennen, maar als leadershipteams dit kunnen en durven accepteren, zit juist in dit punt voor de organisatie een enorm geschenk verscholen. Een organisatie weet nu al heel vroeg dat een bepaalde ambitie niet of later waargemaakt kan worden. Hierdoor kan er heel vroeg actief verwachtingsmanagement gedaan worden en aan mogelijke alternatieven gewerkt worden; in tegenstelling tot de “gemanagete” organisaties waar het doel toch opgelegd wordt en het moment van niet kunnen waarmaken van de ambities pas laat in het proces duidelijk wordt. Voor het managementteam rest alleen nog damagecontrol als optie.
Wanneer de relatie tussen het leadershipteam en de teams al zo gezond is dat er ruimte is voor het nemen van verantwoordelijkheid van de teams, en de leadershipteams zich niet meer bezighouden met de “hoe” vraag, dan is de basis gelegd voor een open en gelijkwaardig gesprek. De organisatie komt nu al tot op het niveau van de “constructieve conflicten”. Dit is heel waardevol omdat leadershipteams die dit niveau bereiken relevante informatie tijdig krijgen. Dit zijn de middelen om bij te sturen én effectief verwachtings- en stakeholdermanagement te doen, kortom: de middelen om als leadershipteam zelf eigenaarschap over de situatie te kunnen nemen en betrouwbaar naar de stakeholders te zijn.
Wat dan nog overblijft is het niveau “vertrouwen”. Dit ontstaat, bijzonder genoeg, op heel korte termijn op basis van het doorlopen van de vorige niveaus. De mate en het vast kunnen houden van vertrouwen worden bepaald door als leadershipteam koersvast te blijven en de organisatie te blijven faciliteren, en niet alsnog namens de teams te gaan denken wanneer de situatie lastiger is. Vooral leadershipteams die niet terugvallen in oude gewoontes, geven een enorme boost in het vertrouwen van de teams, en daarmee grote stimulans voor teams om er alles aan te doen om effectief en voorspelbaar te blijven.
Wil je hierover verder praten met mij, of met een van onze coaches? Neem dan contact op met ons: stuur een mail naar info@towson.nl of neem telefonisch contact op: 085 877 0180.
Onze Teamtraining Lencioni en DISC besteedt uitgebreid aandacht aan leiderschap en samenwerking. Wil je meer weten over deze teamtraining, klik dan hier.
Iedereen kent de Scrum Master, maar bestaat er ook zoiets als de Scrum Grandmaster? Iemand die excelleert in het Scrum Master vak en als inspiratiebron dient voor andere Scrum Masters. Iemand waarbij je misschien in de leer kunt gaan net zoals vroeger ambachtslieden ook in de leer gingen bij een grootmeester. En als deze Scrum Grandmaster al bestaat, hoe zou je hem of haar kunnen herkennen? Waar zou deze dan in uitblinken? Om die vraag te kunnen beantwoorden moet je eerst iets van een meetlat hebben. Maar naar welke aspecten kun je dan kijken? Dit zijn sowieso goede vragen. Want hoe trek je eigenlijk een nieuwe Scrum Master aan in je organisatie? Op welke onderdelen kun je een Scrum Master toetsen tijdens een intake?
In mijn zoektocht naar een geschikte meetlat stuitte ik al snel op het ACI’s Agile Coach Competency Framework uit 2011. Dit framework onderscheidt de acht competenties en coaching stances van een Agile Coach. In 2019 heeft Jonathan Kessel-Fell een waardevolle bijdrage geleverd en het framework verder uitgebouwd. Dit framework bestaat nu uit in totaal tien competenties en coaching stances. In een volgende blog leg ik uit hoe je dit framework kunt gebruiken. Voor nu hebben we genoeg aan de competenties en stances.
Zoals je ziet bestaat dit framework uit de volgende tien competenties en stances:
Agile Lean: Kennis van Kanban, Scrum, XP, DevOps en Lean-Agile principes, alsook van Scaling frameworks zoals Less, SAFe en DA. Maar ook hoe je deze kennis als Scrum Master in de praktijk kunt inzetten.
Mindset & Behaviour: Als Scrum Master ben je een levend voorbeeld van Servant Leadership en leef je naar de waarden en principes die horen bij een Agile-mindset.
People and Influence: Hier komen de soft-skills om de hoek kijken. Een Scrum master weet wanneer hij of zij deze in welke situatie het beste in kan zetten. Bij deze competentie draait het om de vaardigheid om mensen of situaties positief te beïnvloeden en zo blijvende verandering te bewerkstelligen.
Coaching: Bij professionele coaching draait het om onpartijdig te zijn van het doel. Je gelooft in de mensen of in het team. Je werkt als coach met ze samen en helpt daarbij om problemen op te lossen door middel van hun eigen kennis en vaardigheden. Je zorgt er voor dat mensen en teams om je heen het beste in zichzelf naar boven laten komen.
Facilitating: Je helpt als Scrum Master teams met het faciliteren van verschillende activiteiten zoals bijvoorbeeld een retrospective of een Inspect & Adapt event. Hierbij ben je zelf onpartijdig. Je hebt dus van te voren geen vastgesteld verwacht resultaat.
Teaching: De vaardigheid van een Scrum Master om door middel van lesgeven kennis over te brengen op andere mensen. Denk hierbij aan het lesgeven over hoe een Sprint Planning werkt.
Mentoring: Ook bij deze competentie draait het om het overbrengen van kennis, alleen op een veel subtielere manier. Je gebruikt als Scrum Master bijvoorbeeld vaak de zin “In mijn ervaring… heb ik dit en dit geprobeerd”. Ook breng je deze kennis 1 op 1 over in plaats van op grote groepen mensen.
Technical Mastery: Ervaring in het organiseren van technische activiteiten op het gebied van bijvoorbeeld architecture, design, coding en test engineering en de daarbij behorende tooling. Deze kennis en vaardigheden kun je als Scrum Master gebruiken om kwaliteit standaarden te promoten. Deze technische ervaring strekt zich ook uit tot Scaling en DevOps.
Business Mastery: Vaardigheden in het toepassen van business strategy en change leadership om Agile en Lean als concurrentievoordeel in te zetten. Denk hierbij ook aan ervaring met technieken als Lean Start-up, design thinking, product innovatie, flow-based business process management en andere technieken die betrekking hebben op innovatie en samenwerking binnen de organisatie.
Tranformation Mastery: De vaardigheid om organisatieverandering en transformatie op gang te brengen. Denk hierbij ook aan verandering van cultuur, organisatiestructuur, transformation leadership, system thinking en andere gedragswetenschappen.
Voor het aantrekken van nieuwe Scrum Masters is deze lijst met competenties sowieso al heel waardevol. Zo heeft een organisatie die net begonnen is met het introduceren van Scrum waarschijnlijk veel meer behoefte aan een Scrum Master die goed is in het overbrengen van kennis en ervaring. Anderzijds heeft een organisatie die al langer scrumt waarschijnlijk behoefte aan een Scrum Master die de teams of zelfs de complete organisatie coacht en zo het beste in haar mensen naar boven haalt.
Nu rijst bij mij wederom de vraag: bestaat er dan een Scrum Grandmaster die op al deze gebieden uitblinkt? Of zou een Scrum Grandmaster juist op slechts 1 van deze competenties uitblinken en zo het voorbeeld kunnen zijn voor alle andere Scrum Masters?
In een reeks van korte blogs, interviews en video’s neem ik jullie mee in mijn zoektocht naar de Scrum Grandmaster en alles wat ik daarbij ontdek.
Wordt vervolgd…
Mocht je een keer met William willen sparren over dit, of een ander, onderwerp, dan kun je contact met hem opnemen, een e-mail sturen naar info@towson.nl of telefonisch contact met ons opnemen: 085 877 0180.
Vind je dit een nuttig artikel, dan is onze SAFe Advanced Scrum Master training zeker iets voor jou. Wil je meer weten over deze training, klik dan hier.
In dit artikel over duurzame inzetbaarheid gaat Marlies Kreukniet in op het investeren in persoonlijke ontwikkeling. Hoe je dit voor jezelf kan doen, maar ook hoe je vanuit goed werkgeverschap namens je werkgever kan ondersteunen. Het artikel sluit uitstekend aan bij het artikel dat Orpheo Ormskerk onlangs over de “growth mindset” heeft geschreven.
Toen ik ruim 5 jaar geleden bij een grote (IT)opleider kwam te werken had ik nog nooit dit begrip gehoord. Naar mate ik meer ervaring op deed, kwam dit fenomeen steeds meer naar voren in de gesprekken die ik voerde met werknemers en bedrijven. Toen ik 2,5 jaar geleden startte in een leidinggevende functie, kwamen ook de HR-workshops over hoe ik mijn team, mensen van millenials tot 50-plussers, op een duurzame manier kon laten ontwikkelen.
Met de constante en steeds snellere veranderingen wordt er steeds meer gevraagd van de werknemer. De scheidslijn tussen IT-bedrijven en traditionele organisaties wordt steeds vager en zal op den duur waarschijnlijk helemaal verdwijnen. Immers elk bedrijf, klein of groot, heeft tegenwoordig te maken met IT en bijbehorende kennis en processen. (Bij)scholing in IT is al lang niet meer voor de beroeps IT ’er, maar voor iedereen die in zijn of haar werk met IT te maken heeft. Nu ik zelf bij een Agile consultancy practice werk, zie ik ook juist veel opdrachtgevers die niet van origine IT-bedrijven zijn. Juist zij omarmen het Agile werken om de vele nieuwe mogelijkheden die het biedt voor de organisatie en de mensen die er werkzaam zijn.
Daarnaast wordt er gelukkig ook steeds meer aandacht besteed aan de persoonlijke ontwikkeling van de werknemer. Samenwerking, zelfreflectie en feedback geven zijn zaken waar organisaties steeds meer belang aan hechten. En terecht ook, is mijn mening. De beste prestaties behaal je als je vertrouwen hebt in jezelf en in je team en er een transparante en veilige werkcultuur heerst. Dit houdt echter wel in dat je als werknemer dus over de as van de vak inhoud, de techniek en persoonlijke groei moet blijven ontwikkelen.
Er is hier alleen 1 ‘probleempje’….
Volgens Prof. dr. Kim Putters, Directeur Sociaal en Cultureel Planbureau, laat onderzoek zien dat veel werkenden geen duidelijk beeld hebben van de veranderingen op de middellange termijn in hun werk, en wat die voor hun eigen competenties betekenen. Zij voelen geen urgentie om te blijven leren. Vaak besluiten zij pas om zich verder te scholen wanneer zij concreet uitzicht hebben op ander werk, of wanneer zij de overstap naar een andere baan al hebben gemaakt. Tegelijkertijd maakt het onderzoek duidelijk dat een deel van de werkenden wel degelijk belemmeringen ervaart voor het blijven leren. Voor het zich een leven lang ontwikkelen dient er tijd en geld beschikbaar te zijn, evenals maatwerk in scholingsvoorzieningen.
[1] Uit ditzelfde onderzoekt blijkt dat maar een kleine 19% van de Nederlandse beroepsbevolking deelneemt aan een opleiding of cursus. Dit is weliswaar ruim boven de EU-norm, we zitten bij de top-5 landen, maar toch bekruipt mij hier het gevoel dat we er nog lang niet alles uithalen. Het AWVN heeft namelijk in 2018 al onderzoek gedaan
[2] waaruit blijkt dat in 5 jaar tijd het budget wat vanuit werkgevers beschikbaar wordt gesteld voor scholing (volgens cao-afspraken), gestegen is van 1 miljoen werknemers naar 2,3 miljoen. En er zijn nog duizenden bedrijven die hierover afspraken hebben vastgelegd buiten de CAO’s om. Kortom, er liggen dus miljarden euro’s op de plank die ingezet kunnen worden door de werknemers zelf om zich over de technische, inhoudelijke of persoonlijke as verder te ontwikkelen.‘Makkelijk op te lossen, de werknemer moet hier dus gewoon zijn eigen verantwoordelijkheid in nemen’ zou je nu kunnen roepen. En deels is dit ook zo, maar veel mensen ervaren van nature weerstand om zaken anders aan te pakken dan dat ze altijd gedaan hebben. Ook vinden velen het gewoonweg spannend om met de werkgever om tafel te gaan en het over hun ontwikkeling met de bijbehorende budgetten te hebben. Anderzijds willen veel bedrijven ook graag verder ontwikkelen, maar lopen ze nog vast hoe ze de werknemers op een duurzame en positieve manier mee kunnen nemen in impactvolle veranderingen zoals een Agile transformatie.
Mijn conclusie is dan ook dat we vooral met elkaar in gesprek moeten blijven over duurzame oplossingen en de hulpvraag moeten blijven durven stellen. Stel bijvoorbeeld als werknemer eens de vraag aan je werkgever hoe hij jou kan ondersteunen in de veranderingen binnen jouw afdeling. Of stel als werkgever eens de vraag wat je werknemer van jou nodig heeft om mee te kunnen in de visie van de organisatie. En ga vooral ook vrijblijvend in gesprek met organisaties die jullie hierbij kunnen helpen.
Nu het einde van het jaar nadert, is dit de uitgelezen kans voor zo’n gesprek. Want uit onderzoek van Springest blijkt dat bijna de helft (!) van het jaarlijkse opleidingsbudget wat werknemers hebben onbenut blijft. Meer dan 1 miljoen werknemers en duizenden werkgevers, en waarschijnlijk nog veel meer, laten hun kans op duurzame ontwikkeling hier liggen. En het zou toch zonde zijn als jij dit jaar één van hen bent.
Wil je als werkgever of als werknemer eens sparren hoe je in kunt spelen op veranderingen die over de technische (IT) as gaan, bijvoorbeeld m.b.t. Agile werken? Maar ook hoe je hier als team of als management mee om moet gaan? En ben je benieuwd hoe je jouw organisatie-of persoonlijk budget hiervoor kan inzetten?
Neem dan contact op met ons via 085 877 0180 of mail naar peter.turien@towson.nl. Ik ben benieuwd naar jullie vraag en ga graag met jullie in gesprek.
Wanneer je rolomschrijvingen en vacatureteksten van de Scrum Master en Agile Coach leest, dan valt het op dat die nogal verschillen van elkaar. Toch is er in de praktijk veel overlap in de rollen binnen een organisatie. Kevin Roberts deelt in dit artikel zijn visie.
Steeds meer organisaties willen hun wendbaarheid vergroten. Logisch, want we leven in een tijd waarin digitale innovaties elkaar in een rap tempo opvolgen en markt- en klantbehoeften continu veranderen. Agile werken biedt een uitstekende basis om je organisatie snel toe te rusten op de uitdagingen van nu en morgen.
De Scrum Master en Agile Coach zijn twee personen die een belangrijke rol spelen binnen deze werkwijze. Het succes van een Scrum-project blijkt telkens grotendeels af te hangen van de samenwerking tussen deze twee professionals. Maar wat doen deze Scrum Master en Agile Coach? En welke methoden en tools gebruiken ze om een project te doen slagen en managers te betrekken bij het Scrumproces? Lees verder om erachter te komen.
Wat is een Scrum Master?
De Scrum Master zorgt ervoor dat het team met volle focus kan werken aan de afgesproken doelen en heeft als lid van een Scrumteam een voortrekkersrol binnen dit gezelschap. Hij/zij is verantwoordelijk voor het aansturen van het team en is dagelijks op de werkvloer aanwezig. De Scrum Master streeft ernaar om alle ins en outs van een team en project te kennen.
Concrete taken van de Scrum Master zijn onder meer:
Erop toezien dat een team en organisatie werken volgens de principes en spelregels van Scrum.
Het regelen van allerlei praktische zaken. Denk bijvoorbeeld aan het inplannen van vergaderingen, sprintplanningen en brainstormsessies en het zoeken naar procesverbeteringen.
Het tackelen van problemen die het Scrumteam zelf niet kan oplossen.
Een Scrum Master moet ook de rol van ‘change agent’ kunnen invullen. Een change agent is iemand die een leidende rol speelt bij het doorvoeren van een veranderingstraject binnen een organisatie. Dit betekent dat de Scrum Master een gidsende en faciliterende rol heeft en teams in beweging zet. Dat doet hij door:
kennisdeling binnen de organisatie te stimuleren en faciliteren;
besluitvorming inzichtelijk te (laten) maken;
en een duidelijke visie met bijbehorende doelstellingen op te (laten) stellen.
De Scrum Master faciliteert dus in de breedste zin van het woord de processen die digitale transformatie versnellen en jouw organisatie flexibeler maken.
Wat is een Agile Coach?
De rol van een Agile Coach heeft wel raakvlakken met die van een Scrum Master, maar is toch net iets anders. De Agile Coach is geen vast lid van een Scrumteam. Hij heeft een onafhankelijke rol en coacht meerdere teams en het management. Bovendien is de Agile Coach vaak iemand die niet zozeer gericht is op de inhoud van een Scrumproject, maar vooral ook bezig is met het proces.
Agile Coach is binnen Scrum geen officiële functie. De Scrum Guide noemt haar bijvoorbeeld niet. Het ontbreken van een officiële definitie betekent dan ook dat organisaties de positie van Agile Coach in de praktijk vaak op verschillende manieren invullen.
Toch zijn er wel een aantal taken binnen een Scrumproject die meestal op het bord van de Agile Coach belanden. Denk bijvoorbeeld aan de onderstaande verantwoordelijkheden.
Teams en medewerkers bewust maken van hun sterke punten en minder sterke kanten. Het doel daarvan? Ervoor zorgen dat zowel de organisatie als individuele medewerkers zich kunnen ontwikkelen richting een agile-mindset en -werkwijze.
Het creëren en borgen van een gezonde en goede groepsdynamiek. Dit doet de Agile Coach door medewerkers de juiste tools en technieken aan te reiken en geregeld de samenwerking te evalueren.
Individuen en teams ondersteunen met behulp van mentoring, coaching en teaching.
Twee worden één
Managers en organisaties maken nogal eens een onderscheid tussen de rollen van Scrum Master en Agile Coach. De Scrum Master wordt dan voorgesteld als iemand die alleen verstand heeft van Scrum, terwijl de Agile Coach over een groter kennisreservoir en uitgebreidere toolkit zou beschikken. De Scrum Master is volgens die visie eigenlijk een ‘junior Agile Coach’.
In werkelijkheid is het onderscheid tussen de twee niet zo scherp en zeker niet zo hiërarchisch. Vergelijk het met twee flessen cola van een verschillend merk: het etiket is anders en de smaak verschilt enigszins, maar in de basis zijn er meer overeenkomsten dan verschillen. In de praktijk versmelten de rollen van Scrum Master en Agile Coach steeds meer. Traditioneel leeft vaak het idee dat de Scrum Master alleen actief is op het teamniveau en de Agile Coach vooral op enterprise-niveau.
Hoewel het klopt dat de Scrum Master vaak begint op teamniveau, evolueert hij vaak mee met de organisatie naarmate die beter wordt in het adopteren en toepassen van Scrum en andere agile-methodieken. Hierdoor werkt hij ook steeds vaker direct samen met de hogere echelons binnen een organisatie.
De les: dek alle competenties goed af
Of je nu kiest voor een Scrum Master en een aparte Agile Coach of beide functies samenbrengt in een en dezelfde persoon: zorg er in elk geval voor dat alle kennisgebieden en praktische onderdelen van Scrum goed zijn afgedekt. Dit betekent dat je niet alleen de juiste kennis in huis hebt, maar ook op het vlak van communicatie, motivatie en taakafstemming alles goed op orde hebt.
Deze week een mooie bijdrage van mijn collega Lotte Coosen. Lotte is namens Towson Scrum Master en Coach bij de gemeente Rotterdam. In haar blog vraagt ze zich af hoe het toch komt dat transformaties die met de beste bedoelingen beginnen maar niet echt breed landen in de organisatie wat beginnen te stropen en verzanden…
Om een Agile transitie in gang te zetten wordt er vaak verwezen naar een belangrijke voorwaarde: het bereiken van het ‘tipping point’. Er moet een reden zijn om te veranderen en die moet collectief gevoeld worden; men moet het er met elkaar eens zijn dat de huidige manier van werken niet de gewenste resultaten oplevert. Maar is het niet vaak zo dat dit alleen in de hogere lagen van de organisatie gevoeld wordt? En dat er vervolgens voor de uitvoerende lagen besloten wordt dat zij Agile gaan werken? Hoe zorg je dan dat de urgentie om te veranderen ook daar gevoeld wordt? En welke rol speel je daar als Agile Coach in?
Als beginnend Agile Coach ben ik ook in de valkuil gestapt om maar zoveel mogelijk uit te leggen wat Agile is, wat scrum is, wat SAFe is en hoe dat binnen een organisatie toegepast kan worden. En natuurlijk is die theorie nodig, moet men de spelregels verkennen met elkaar. Maar tezamen met een mooie zeepkistsessie van de CTO over de ‘need to change’ bleken mensen toch echt niet altijd in beweging te komen. Waarom gebeurde er nou niets? De reden voor verandering is toch duidelijk, de spelregels zijn uitgelegd, de teams zijn gevormd. Gaan met die banaan zou je zeggen.
Misschien was het naïef, misschien had ik er zelf ook gewoon wat langer de tijd voor nodig voor ik het zag, maar inmiddels is mij duidelijk dat niet iedereen elke ochtend inlogt om bij te dragen aan de visie en missie van een bedrijf. Ondanks dat hij of zij er ooit heel bewust voor heeft gekozen om daar te gaan werken. Bij sommige mensen is die connectie met het bedrijf inmiddels verdwenen, bij anderen is hij er misschien nooit zo sterk geweest. Uiteraard en gelukkig zijn er ook genoeg mensen die wel tot in hun kern verbinding voelen met het bedrijf waarvoor ze werken, alles in het werk stellen om bij te dragen aan goede resultaten en een mooi product, en van daaruit de nut en noodzaak van een transitie inzien. Maar juist die paar mensen die die verbinding niet zo voelen, of die gewoon bang zijn voor verandering, dát zijn de mensen die een transitie en de vorming van een team aardig in de weg kunnen zitten.
Het artikel van mijn collega Marjolein van Gelderen gaf al een mooie inkijk in hoe je zo’n team recht kunt trekken. Daarnaast helpt het om steeds stil te staan bij de persoonlijke motivatie van een teamlid of medewerker. Bij iedereen is wel een ‘tipping point’ te vinden, maar dat zal voor iedereen anders zijn. Net zoals dat van bedrijf tot bedrijf verschilt. Bij het ene bedrijf zal het de behoefte zijn om van waterval af te stappen, bij het andere bedrijf wil men structuur aanbrengen in het ad-hoc werken, etc. Zo zijn er bij teamleden ook verschillende redenen om wel mee te gaan in een agile transitie. Behoefte aan transparantie, aan regie, aan een sterke teamdynamiek, plichtsgetrouwheid en zo zijn er nog veel meer redenen. Wanneer en waarmee bereikt iemand zijn of haar tipping point? Of komt dat misschien wel nooit (ook goed om te weten)? Daar kom je alleen achter door als coach in gesprek te blijven en wellicht eens te vragen naar iemands verleden.
Niet zo lang geleden viel bij mij ineens de vergelijking met de klasgenoten van vroeger. Er zijn er altijd een paar die weken van tevoren gaan leren voor een toets en je hebt er ook een aantal die pas de dag van tevoren hun boeken openslaan. Dat kan te maken hebben met iemands leervermogen. Maar dat kan ook te maken hebben met de urgentie die iemand moet voelen om aan de slag te gaan. Dat is bij een Agile transitie niet anders; je hebt medewerkers die er gewoon in meegaan omdat ze het grotere belang ervan inzien, en je hebt medewerkers die pas in beweging komen als de voordelen voor hen persoonlijk duidelijk zijn. Dus vraag als coach eens wat voor leerling iemand vroeger was. En dan is het hopen dat niet al te veel mensen zullen antwoorden dat ze helemaal niet leerden, en gewoon op goed geluk naar het examen gingen.
Scrum teams hebben net als traditionele waterval teams te maken met deadlines. Om diverse redenen kan het voorkomen dat nieuwe functionaliteiten niet op tijd gereleased worden. Dat is zuur. Zeker omdat de volgende wijzigingen vaak al in de planning zijn opgenomen.
2. Combineren van releases
Een voor de hand liggende oplossing lijkt het combineren van de verschillende releases. Dan kun je bijvoorbeeld alle testen combineren en hoef je alles maar 1x te testen. Hierdoor creëer je tijdwinst en kom je de eerstvolgende release weer in de normale heartbeat (cadans).
Het tegendeel is echter waar. Het samenvoegen van releases levert geen tijdwinst op. Het kost zelfs meer tijd. Veel meer tijd.
Oorzaken zijn onder andere:
– Door meer te wijzigen wordt de scope vergroot en neemt de kans op defects toe. Blijft het aantal ontwikkelaars gelijk dan ontstaat er een defect queue (bottleneck). Testen staan hierdoor stil totdat fixes worden opgeleverd. Een grotere scope leidt tot een exponentieel grotere defect queue.
– De development- en testinfrastructuur blijft hetzelfde. Hierdoor ontstaat wachttijd (waste). Zo kunnen sommige testen bijvoorbeeld niet parallel uitgevoerd worden op dezelfde testomgeving waardoor ze op elkaar moeten wachten.
– De coördinatie en afstemming tussen teams en afdelingen neemt exponentieel toe.
– Omschakeltijd. Schakelen tussen verschillende activiteiten kost tijd. Voorbeeld: Een teamlid stuit tijdens het testen op een blokkerend defect en wil hierdoor een andere test opstarten. Hiervoor moet eerst nieuwe testdata klaargezet worden, ingelogd worden met een ander gebruikersaccount, etc.
– Scopecreep. Hoe langer een release onderhanden is, hoe meer “extra functionaliteiten” van alle kanten toegevoegd worden. Denk hierbij bijvoorbeeld aan hotfixes.
Kortom: Het vergroten van de scope zal dus door verschillende oorzaken exponentieel toenemen.
3. Release early, release often
In plaats van de scope te vergroten door releases te combineren adviseer ik met klem het tegenovergestelde. Maak de scope juist kleiner zoals het Agile Manifesto ook voorschrijft en release vaker.
De volgende technieken kunnen helpen bij het verkleinen van de scope:
– Dark Launches: Release van code naar productie waarbij de functionaliteit niet beschikbaar/zichtbaar is voor de eindgebruiker.
– Feature toggles: Een techniek waarbij je gebruik maakt van Dark Launches waarbij je de mogelijkheid inbouwt om de functionaliteit op een later tijdstip alsnog aan/uit te zetten.
– Canary release: Een techniek waarbij je de functionaliteit alleen beschikbaar maakt voor een selecte groep gebruikers. Vervolgens meet je de feedback en kun je er voor kiezen om op een later tijdstip de functionaliteit alsnog te releasen naar meer gebruikers.
– Decouple release elements: Een release kan in de regel opgeknipt worden naar kleinere elementen die apart van elkaar live gebracht kunnen worden.
De maatschappij, klantbehoeftes en -verwachtingen veranderen voortdurend. Kwaliteit- en veiligheidseisen worden strenger, wet- en regelgeving worden geharmoniseerd, en technologische ontwikkelingen volgen elkaar in rap tempo op. Tegelijkertijd worden de kwantiteit, snelheid en complexiteit van veranderingen steeds groter.
Overheden, onderwijsinstellingen, bedrijven en medewerkers zullen de komende jaren geconfronteerd worden met kleinschalige en grootschalige veranderingen en een omgeving waarin maatschappelijke, economische en technologische veranderingen leiden tot de intrede van nieuwe marktpartijen, nieuwe markt-productcombinaties, innovatieve diensten en verschuiving van bestaande machtsstructuren.
Dit vergt aanpassingsvermogen en vraagt om een sterke klant- en productfocus, flexibiliteit en lenigheid. Om te kunnen overleven dienen organisaties in staat te zijn om effectief en tijdig te reageren op veranderingen, kansen en bedreigingen binnen bestaande en toekomstige markten. In de praktijk blijkt dit vaak een uitdaging en is het voor organisaties lastig om blijvende veranderingen door te voeren. Traditionele programma- en projectmanagement technieken zoals MSP en PRINCE2 blijken niet altijd het gewenste resultaat op te leveren en voldoende uitkomst te bieden.
Agile change en delivery modellen
In reactie hierop zijn vanaf de jaren ‘90 verschillende agile change modellen ontwikkeld waaronder Rational Unified Proces (RUP), Scrum, Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). Dergelijke modellen en methodieken stellen organisaties in staat om tijdig, effectief en efficiënt veranderingen door te voeren door hun lenigheid te vergroten.
Veel organisaties zijn inmiddels overtuigd van het agile gedachtegoed en gestart met het werken volgens de agile en Scrum principes. Bekende voorbeelden zijn Spotify, Coolblue, ING, Eneco en bol.com waar meerdere scrumteams gezamenlijk werken aan de succesvolle introductie van nieuwe producten en diensten om steeds meer toegevoegde waarde te leveren aan hun klanten, stakeholders en eindgebruikers.
Voor veel organisaties is het een uitdaging om de agile principes toe te passen en geleidelijk de transitie te maken naar een volwassen agile organisatie. Daarnaast is het meestal een uitdaging om continu de volwassenheid en effectiviteit van de agile organisatie te verbeteren en met meerdere agile teams tegelijkertijd producten en diensten te ontwikkelen.
In dit artikel wordt een overzicht gegeven van de verschillende agile modellen en frameworks die organisaties kunnen gebruiken om op te schalen, met meerdere agile teams tegelijkertijd te werken en door te ontwikkelen naar een volwassen agile organisatie die in staat is om tijdig veranderingen te signaleren, door te voeren en zichzelf continu te verbeteren.
2. Het Agile Manifesto
In de jaren ‘90 werden organisaties en bedrijven steeds ICT-intensiever en steeds vaker geconfronteerd met technologische veranderingen, veeleisende klanten en een steeds korter wordende time-to-market van producten. Al snel bleek dat traditionele projectmanagement technieken onvoldoende flexibel waren om efficiënt en effectief proces- en systeemwijzigingen door te voeren.
In reactie hierop deden verschillende light-weigth development technieken hun intrede, waaronder Dynamic System Programming Method (DSDM), Extreme Programming (XP), Rapid Application Development (RAD), Feature-driven Development (FDD) en Rational Unified Proces (RUP). De methodieken waren gericht op het incrementeel en iteratief ontwikkelen van software op basis van de behoefte van de klant en hadden een sterke focus op continu verbeteren en kwaliteit.
In 2001 kwamen 17 software-pioniers bij elkaar om de verschillende light-weight software technieken te bespreken en te vergelijken. De uitkomst van de meet-up was het Agile Manifesto waarin de 12 uitgangspunten van agile werken zijn vastgelegd die organisaties kunnen gebruiken om hun lenigheid, flexibiliteit en aanpassingsvermogen te trainen en te vergroten.
Customer satisfaction by early and continuous delivery of valuable software
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business, people, and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Best architectures, requirements, and designs emerge from self-organizing teams
Regularly, the team reflects on how to become more effective, and adjusts accordingly
Samenvattend verkiest het Agile Manifesto individuen en interactie boven proces en tooling, werkende software boven documentatie, samenwerking met de klant boven contractonderhandelingen en het reageren op verandering in plaats van het volgen van een plan.
3. Single Team Scrum
Het Agile Manifesto heeft de deur geopend voor nieuwe delivery methoden om in een complexe omgeving veranderingen door te voeren, waaronder Scrum de meest toegepaste en gebruikte methode is. Bedrijven zoals Spotify, Coolblue, ING, Eneco en bol.com maken dankbaar gebruik van Scrum om hun producten en dienstverlening continu te verbeteren.
Scrum is in de jaren ‘90 bedacht door Ken Schwaber en Jeff Sutherland met als doel om op een efficiënte en effectieve manier software te ontwikkelen. De term Scrum is afkomstig uit de rugbywereld en is een proces framework dat gebruikt wordt om complexe producten en software te ontwikkelen in een continu veranderende omgeving.
Het framework is gebaseerd op teamwork. Het Scrum Team bestaat uit een Product Owner, Scrum Master en Development Team en is gezamenlijk verantwoordelijk voor het realiseren van werkende producten en software die voldoen aan de wensen van de klant. Om de kwaliteit van de producten en software te borgen stelt het team een Definition of Done (DoD) op. In de DoD beschrijft het team de eisen waaraan producten en software moeten voldoen voordat ze in gebruik kunnen worden genomen. Hierbij kan gedacht worden aan de uitvoering van testwerkzaamheden, het documenteren van functionaliteiten en het voldoen aan interne security richtlijnen van de organisatie.
Het Scrum Team is zelf-organiserend, werkt iteratief, incrementeel en levert volgens een vast ritme, de sprint, een werkend product en werkende software op. De sprint is fixed en mag niet meer dan maximaal 4 weken duren. Transparantie, observeren en aanpassen vormen tijdens de sprint de kernwaarden van het team.
Binnen het Scrum Team is de Product Owner verantwoordelijk voor het inventariseren en prioriteren van de te realiseren producten en wijzigingen. De producten en wijzigingen worden centraal vastgelegd op een prioriteitenlijst de Product Backlog genaamd. In overleg met de omgeving en betrokken stakeholders bepaalt de Product Owner in welke volgorde de producten en wijzigingen door het team worden opgepakt. De Scrum Master ondersteunt de Product Owner in zijn rol en is verantwoordelijk voor het wegnemen van issues en het ondersteunen en coachen van het team.
Aan het begin van elke sprint vindt er een Sprint Planning plaats. In dit overleg worden de richting en focus van de sprint bepaald en stelt het team een sprintdoel op. Daarnaast wordt de lijst met geprioriteerde producten en wijzigingen besproken en bepaald wat het team gaat oppakken in de sprint. Vervolgens wordt besproken hoe de wijzigingen worden opgepakt.
De uitkomst van dit overleg is de Sprint Backlog: een korte lijst met geprioriteerde wijzigingen en taken op basis waarvan het team start met de realisatie van de producten en wijzigingen. De Sprint Backlog is eigendom van het Development Team en kan tijdens de sprint niet gewijzigd worden door de Product Owner.
Gedurende de sprint wordt dagelijks de voortgang besproken in een Daily Scrum aan de hand van drie vragen:
Wat heb je gister gedaan?
Wat ga je vandaag doen?
Welke issues heb je?
Aan het eind van elke sprint worden tijdens de Sprint Review de producten en wijzigingen getoond aan de klant, stakeholders en eindgebruikers, en wordt de sprint afgesloten met een Sprint Retrospective. In dit overleg wordt de sprint door het team geëvalueerd en worden verbeterpunten benoemd die worden meegenomen in de volgende sprint. Op deze wijze kan het team zich continu verbeteren.
4. Multiple Team Scrum
Het agile gedachtengoed wordt inmiddels door veel organisaties omarmd en Scrum wordt in veel organisaties succesvol toegepast. Het op korte termijn starten met agile en Scrum blijkt in de praktijk voor organisaties relatief snel veel voordelen op te leveren ten opzichte van traditionele projectmanagement- en delivery technieken, waaronder het gericht en regelmatig opleveren van werkende software.
Het succes van Scrum heeft geleid tot een toename van het aantal Scrum Teams binnen tal van organisaties en de behoefte om tegelijkertijd met meerdere Scrum Teams producten en software te ontwikkelen. In de praktijk is echter gebleken dat het niet zonder meer mogelijk is om op te schalen en de uitgangspunten van het Agile Manifesto tezamen met de spelregels van Scrum niet altijd voldoende uitkomst bieden.
In reactie hierop zijn de afgelopen jaren in korte tijd een aantal agile frameworks ontwikkeld waaronder Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). De frameworks zijn bedoeld om organisaties handvatten te bieden voor het opschalen en doorontwikkelen naar een volwassen agile organisatie die in staat is om met meerdere teams tegelijkertijd agile te kunnen werken en producten te ontwikkelen.
De modellen zijn complex, omvangrijk en de uitdaging voor organisaties is om het juiste model of gedeeltes van de modellen geleidelijk te implementeren.
4.1 Nexus
Het Nexus Framework is afkomstig van www.scrum.org
Het Nexus framework is het nieuwe wapenfeit van Ken Schwaber en een reactie op de verschillende agile frameworks die de afgelopen jaren zijn ontwikkeld. Het raamwerk, exoskeleton, van Nexus is bedoeld om met 3-9 Scrum Teams op basis van één Product Backlog te werken aan een geïntegreerd product.
De agile en Scrum principes vormen de basis van het framework waarbij de focus ligt op het verbeteren van de onderlinge samenwerking tussen de teams en de integratie van de te realiseren producten en oplossingen. Om dit te bewerkstelligen wordt naast de scrum teams een apart Scrum Team ingericht: het Nexus Integration Team.
Het Nexus Integration Team bestaat dus uit een Product Owner, Scrum Master en leden afkomstig uit de overige Scrum Teams. De Product Owner is verantwoordelijk voor het vaststellen en prioriteren van de Backlog en de Scrum Master helpt de Scrum Teams de Nexus principes correct toe te passen. De teamleden van het Nexus team kunnen tevens onderdeel uitmaken van en participeren in andere Scrum Teams. Het team werkt volgens een vast ritme en is verantwoordelijk voor het afstemmen en mitigeren van de onderlinge afhankelijkheden tussen de teams en het integreren van de eindoplossing.
De sprintvergaderingen van het Nexus team zijn leidend en worden zoveel mogelijk geïntegreerd in de vergaderingen van de afzonderlijke Scrum Teams. Vertegenwoordigers vanuit de overige Scrum Teams worden uitgenodigd om deel te nemen aan het Nexus teamoverleg.
Het samenspel van het Nexus team en de overige Scrum Teams start met een Nexus Sprint Planning waarin het doel van de sprint wordt vastgesteld en wordt bepaald welke producten, oplossingen en wijzigingen worden opgepakt. De Backlog items vormen input voor de Sprint Planning van de individuele teams. Daarnaast vindt er een dagelijks overleg, de Nexus Daily Scrum, plaats waarin de onderlinge afhankelijkheden en integratie issues worden geïdentificeerd die worden besproken in de Daily Scrums van de overige teams.
Aan het eind van elke sprint wordt een Nexus Sprint Review georganiseerd waarin het geïntegreerde product getoond wordt aan de omgeving en volgt een Nexus en Sprint Retrospective. In de Retrospective wordt de sprint geëvalueerd en worden verbeteracties vastgesteld.
4.2 Large Scale Scrum (LeSS)
Het LeSS Framework is afkomstig van www.less.works.
Het LeSS framework is bedacht door Craig Larman en Bas Vodde en is bedoeld voor organisaties die met meerdere teams tegelijk willen scrummen. Inmiddels hebben onder andere BMW, Thales, Port of Rotterdam en Ericsson het framework geadopteerd.
Het framework heeft een sterke klant- en productfocus, omarmt lean- en systems thinking en doet nadrukkelijk afstand van tayloristische opvattingen, organogrammen en het denken in lokale optimalisatie. Onderstaand een overzicht van de belangrijkste principes.
Large-scale scrum is scrum – Multiple team Scrum versus multiple Scrum Teams
Customer Centric – Focus op klant en klantbehoefte vormt basis voor productontwikkeling
Whole product focus – Focus op product en toegevoegde waarde voor de klant
Lean Thinking – Creëer flow, vermijd rijen en verwijder de 7 verspillingen
System Thinking – Denk in systemen in plaats van oorzaak gevolg
Empirical process control – Inspecteer, observeer en pas aan op basis van bevindingen
Queuing theory – Reduceer en beperk rijen, work in progress, multi-tasking en variatie
Transparency – Creëer transparantie en geef inzicht in de voortgang en complexiteit van werkzaamheden
More with LeSS – Bouw een agile organisatie bottom-up en niet top-down met behulp van management
Continuous Improvement – Verbeter continu het proces van product delivery
LeSS is gebaseerd op multiple team scrum en gaat in tegenstelling tot het Scaled Agile Framework (SAFe) uit van één groot Scrum Team, bestaande uit meerdere teams die gezamenlijk producten realiseren op basis van één centrale Product Backlog. SAFe daarentegen gaat uit van een agile team dat bestaat uit meerdere afzonderlijke Scrum Teams met elk een eigen Product Owner en Product Backlog. Binnen het framework wordt een onderscheid gemaakt tussen LeSS (< 9 teams) en LeSS Huge (> 9 teams).
Het LeSS Scrum Team bestaat uit zelforganiserende cross-functional feature teams. Feature teams zijn multidisciplinaire teams die in staat zijn om ketenwijzigingen en component overstijgende producten te ontwikkelen. Het team beschikt over één productowner en meerdere Scrum Masters, waarbij de Scrum Masters verantwoordelijk zijn voor de LeSS adoption van de organisatie en de ondersteuning van de teams. In de praktijk vervult een Scrum Master vaak voor drie Scrum Teams tegelijk de rol van Scrum Master.
In het geval van LeSS Huge worden de teams vaak gekoppeld aan een area. Een area is een cluster van functionaliteiten of een gedeelte van een product dat seperaat waarde toevoegt voor de klant. De indeling in areas wordt gebruikt om focus aan te brengen in de productontwikkeling. Een area staat niet gelijk aan een SAFe valuestream, maar bewerkstelligt hetzelfde doel. Ter ondersteuning van de Product Owner wordt er vaak per area een Area Product Owner aangesteld die samen met de Product Owner een team vormt en de Product Owner ondersteunt bij het opstellen en prioriteren van de Backlog.
Overeenkomstig ‘single’ team Scrum start de realisatie met een overall Sprint Planning waarbij alle Scrum Teams aanwezig zijn en bepaald wordt wat er in de sprint wordt opgepakt. Vervolgens wordt in de teams afzonderlijk bepaald hoe de userstories worden opgepakt en gestart met de sprint.
Aan het einde van de sprint vindt er een gezamenlijke overall Sprint Review plaats, waarin de gerealiseerde producten en software worden getoond aan de betrokken stakeholders. Tot slot wordt er een overall Sprint Retrospective en Sprint Retrospective op teamniveau georganiseerd, waarin de sprint gezamenlijk en afzonderlijk door de teams wordt geëvalueerd.
4.3 Scaled Agile Framework (SAFe)
Het SAFe 4.0 framework is afkomstig van www.scaledagileframework.com
Het Scaled Agile Framework (SAFe) is een bekend agile framework dat is bedacht door Dean Leffingwel. SAFe is een framework dat organisaties helpt om met meerdere Scrum Teams tegelijkertijd veranderingen door te voeren. Inmiddels hebben grote bedrijven zoals onder andere TomTom, Lego en Intell het SAFe framework geadopteerd en toegepast.
Het framework is gebaseerd op lean principes en probeert alignment te creëren tussen de strategie van een organisatie en de daadwerkelijke realisatie van producten en diensten door agile Scrum Teams. SAFe maakt in tegenstelling tot LeSS hierbij gebruik van bestaande governance- en programmastructuren zoals het strategische portfolio overleg dat veel gebruikt wordt binnen organisaties om de prioriteit van veranderingen te bepalen.
Take an economic view – Change op basis van economische afwegingen (cost of delay)
Apply systems thinking – Optimaliseer ketens in plaats van (stand alone) componenten
Assume variability, preserve options – Ga uit van variëteit, wees flexibel en beschik over alternatieven
Build incrementally with fast, integrated learning cycles – Gebruik iteraties, test en evalueer periodiek (PDCA)
Base milestones on objective evaluation of working systems – Stel realistische doelen en vermijd tolgates
Visualize and limit WIP, reduce batch sizes, and manage queue lengths – Creëer flow en monitor work in progress
Apply cadence, synchronize with cross-domain planning – Hanteer een vast ritme, synchroniseer en plan delivery
Unlock the intrinsic motivation of knowledge workers – Motiveer en activeer intrinsieke motivatie
Decentralize decision making – Decentraliseer zoveel mogelijk de besluitvorming
SAFe onderkent respectievelijk vier niveaus: het portfolio-, value stream-, programma- en teamniveau. Op portfolio niveau worden door de directie de strategische thema’s gedefinieerd die richting geven aan de gewenste verandering. Daarnaast worden op dit niveau de belangrijkste value streams (waardeketens) geïdentificeerd waarbinnen de veranderingen plaats dienen te vinden.
De strategische thema’s worden gekoppeld aan de value streams en per waardeketen wordt een veranderbudget toegekend. Vervolgens worden de strategische thema’s per value stream op programma niveau vertaald in hapklare brokken en wijzigingen, de epics, die vastgelegd worden op een programma backlog.
Tegelijkertijd wordt er per value stream een Release Train ingericht. Een Release Train is een agile team bestaande uit meerdere Scrum Teams die gezamenlijk verantwoordelijk zijn voor het ontwikkelen van werkende producten en software binnen een waardeketen. Elk team binnen de Release Train beschikt over een afzonderlijke Product Backlog, Product Owner en Scrum Master en werkt overeenkomstig de principes van agile Scrum.
De programma backlog wordt vervolgens verder opgeknipt en vertaald in een Product Backlog op basis waarvan de Scrum Teams binnen een Release Train kunnen starten met de realisatie. Om de onderlinge samenwerking en alignment tussen te teams te vergroten wordt er gemiddeld één keer in de 10 weken een Release Planning georganiseerd. Het overleg duurt vaak twee dagen. Bij dit overleg zijn het management en alle teams aanwezig, en worden gezamenlijk de doelstellingen en de inhoud van de eerst komende sprints bepaald. Daarnaast worden in de vergadering de belangrijkste afhankelijkheden en risico’s tussen de teams afgestemd.
Tot slot benoemd het SAFe framework in tegenstelling tot LeSS verschillende ondersteunende rollen die de productontwikkeling en het voortbrengingsproces binnen het framework en de teams ondersteunen. Voorbeelden van rollen zijn de Agile Release Train Engineer, het Release Management en Enterprise Architecten. Rollen die sterke overeenkomst vertonen met leidinggevende functies in niet agile organisaties.
4.4 Disciplined Agile Delivery (DaD)
Het DaD framework is afkomstig van www.disciplinedagiledelivery.com
De ontwikkeling van het Disciplined Agile Delivery framework is in 2009 gestart door IBM onder leiding van Scott Ambler en Mark Lines. Het framework is bedoeld voor organisaties die op grote schaal lean-agile willen werken. DaD onderscheidt zich van LeSS en SAFe door de procesgerichte benadering van delivery, de focus op een werkbare oplossing, een significant andere teamsamenstelling en een sterke focus op de omgeving.
Het framework is een lean-agile hybride model en is gebaseerd op het Agile Manifesto dat de bedenkers hebben aangescherpt en vertaald in het Disciplined Agile Manifesto bestaande uit 15 simpele uitgangspunten waarin de focus ligt op het realiseren van werkbare oplossingen voor stakeholders in plaats van producten voor de klant.
In het framework zijn duidelijk invloeden van Scrum, Extreme Programming, XP, Kanban, ITIL, SAFe en Agile Modeling terug te vinden. Maar bovenal is DaD een procesgericht framework met een duidelijke focus op de interactie tussen personen en de brede omgeving van een organisatie.
Producten, oplossingen en software worden op basis van heldere doelstellingen overeenkomstig een vast delivery proces gerealiseerd. De basis Delivery Lifecycle van DaD bestaat uit 5 fasen: concept, inception, construction, transitie en productiefase. In de concept- en inceptionfase worden de visie, roadmap en doelarchitectuur opgesteld die richting geven aan de realisatie van de oplossing. Vervolgens wordt in de constructionfase gestart met de realisatie van de oplossing die in de transitiefase wordt gedeployed en in de productiefase in gebruik wordt genomen door de stakeholders voor wie de oplossing wordt gerealiseerd.
Gedurende dit proces is het DaD team, evenals een traditioneel Scrum Team, gezamenlijk verantwoordelijk voor de realisatie van de oplossing. De samenstelling van het team verschilt echter aanzienlijk van de samenstelling van traditionele Scrum Teams. Binnen het team wordt namelijk een onderscheid gemaakt tussen primaire en secundaire rollen. Een DaD team bestaat uit een Team Lead, Product Owner, Architectuur Owner, team members en vaak maken stakeholders ook onderdeel uit van het team. Daarnaast wordt het team aangevuld met secundaire rollen, waaronder proces-, systeem en technische experts, testers en integrators. Allen zijn volgens het framework noodzakelijk om een werkbare oplossing te realiseren en de interactie tussen het team en de omgeving succesvol te laten verlopen.
Bij de start van de realisatie wordt door het team overeenkomstig de Scrum principes een Iteration Planning georganiseerd, waarin bepaald wordt met welke oplossingen gestart zal worden. In de dagelijkse Coordination Planning wordt de voortgang besproken. Aan het eind van de sprint wordt in de Iteration Review de oplossing getoond aan de omgeving en wordt er afgesloten met een Retrospective waarin de sprint wordt geëvalueerd.
5. De agile organisatie
De maatschappij, klantbehoeftes en verwachtingen veranderen voortdurend. Kwaliteit- en veiligheidseisen worden strenger, wet- en regelgeving worden geharmoniseerd, en technologische ontwikkelingen volgen elkaar in rap tempo op. Tegelijkertijd worden de kwantiteit, snelheid en complexiteit van veranderingen steeds groter.
Om tijdig in te spelen op deze veranderingen zijn in de afgelopen jaren verschillende agile delivery modellen ontwikkeld, waaronder Scrum, Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). De modellen en methoden zijn gebaseerd op het Agile Manifesto en hebben allen als doel om gericht, iteratief, incrementeel werkende producten, oplossingen en software te realiseren die voldoen aan de wensen van de klant.
Daarnaast proberen de modellen organisaties handvatten te geven om de transitie te maken naar een volwassen, effectieve agile organisatie die in staat is om tijdig in te spelen op veranderende marktomstandigheden en efficiënt en effectief veranderingen kan doorvoeren.
Welk model het beste past bij een organisatie is afhankelijk van het type, de governance en het volwassenheidsniveau van de organisatie, maar de praktijk heeft inmiddels voldoende aangetoond dat de agile principes en frameworks werken.
Ben je na het lezen van dit artikel geïnteresseerd geraakt? Neem gerust contact met ons op: info@towson.nl.
Scaledagile.com heeft enige dagen geleden de verwachte update van SAFe 4.6 naar SAFe 5.0 aangekondigd. Het gaat bij deze update om een grote aanvulling op het model. Nieuw is bijvoorbeeld de nadrukkelijkere aandacht voor het centraal stellen van de klant binnen organisaties. Hiervoor is zelfs een extra “business agility” poster ontwikkeld.
Omdat het bij nieuwe versies van SAFe altijd om uitbreiding op de bestaande basis gaat, is je kennis die je in eerdere trainingen hebt opgedaan nog altijd even valide en toepasbaar.
Met de toevoeging van Business Agility worden organisaties die zich door SAFe laten ondersteunen nog beter in staat gesteld om op de snel veranderende markt in te spelen met innovatieve oplossingen.
Om alles wat in SAFe 5.0 nieuw is goed tot je te nemen, organiseren wij een update workshop. In 4 uur tijd nemen we je door de nieuwe big picture inclusief de bijbehorende business agility poster.
Deze workshop is een uitstekende basis voor iedereen die een geldig SAFe Agilist badge heeft en gebruik wil maken van de mogelijkheid om deze te vernieuwen naar SAFe 5.0.
Maar ook als je geen geldige SAFe 5.0 badge meer hebt is het natuurlijk een uitstekende manier om bij te blijven met de ontwikkeling van Scaledagile.com
De kosten voor deze workshop, inclusief SAFe Big picture op A0 formaat, waren slechts € 250,- ex. BTW. De workshops werden gegeven op 10 en 24 januari*.
