Opleiding Scale up to an Agile Enterprise

Veel organisaties gebruiken tegenwoordig Scrum voor IT-projecten, maar veel werk wordt nog op een traditionele manier gedaan:
Inkoop wil exacte en gedetailleerde specificaties van het product waar gewerkt wordt en de juridische afdeling wil een precieze omschrijving van de verantwoordelijkheden.
Compliancy wil er zeker van zijn dat alle regels en voorschriften worden nageleefd, waarvoor controles worden uitgevoerd die zijn opgesteld voor een traditionele werkwijze.
Ten slotte wil het management de prestaties van de projectorganisatie kunnen bepalen aan de hand van budget en KPI’s.
Agile werkt anders en de verschillen tussen werkwijzen binnen een organisatie zorgen ervoor dat een organisatie niet Agile kan worden.

Maak kennis met verschillende Agile manieren van werken en schalen!

De nieuwe Agile enterprise is een organisatie die gebaseerd is op nauwe samenwerking met alle stakeholders, ook met de medewerkers. Continue feedback, verbetering van het systeem en gebruiken maken van nieuwe technologie zijn sleutelfactoren. Een nieuwe mindset, een nieuwe managementstijl en een nieuwe organisatiestructuur zijn noodzakelijk. 

Inhoud en programma

Dag 1, deel 1 - Recap essentials en When / why Scaling

Om echt agile te zijn is het belangrijk dat de principes en waarden goed begrepen worden. Vaak worden paradigma’s doorbroken en/of lijkt het contra-intuïtief. Agile werken wijkt voor velen sterk af van wat men gewend is en soms lijkt het ‘te mooi om waar te zijn’. De eerste module staat in het teken van principes en achtergronden van agile en gerelateerde practices. Voorbeelden zijn Scrum, XP, RUP, DevOps, Continuous Integration, Continuous Delivery, Test Driven Development, Lean (WIP limit / Pull / Poka Yoke “Never break the build” / Kaizen “Inspect & Adapt” / Just in Time principles “Architectural runway”) en Kanban. 

Het afsluitende deel van deze module gaat in op de keuze voor ‘scaled agile’. Wanneer wordt scaling nuttig of zelfs nodig? Welke factoren zijn van invloed en welke (waardes van) indicatoren wijzen daarop? Zoals complexiteit, volume, (in)flexibiliteit, aantallen programma’s en projecten, DevOps, Continuous Delivery & releaseproblematiek.

Dag 1, deel 2 - Business & Portfolio

In deze module maken we de eerste stap naar scaling agile. We bekijken hoe een portfolio van agile projecten vormgegeven en bestuurd kan worden. Hoe ervoor te zorgen dat vanuit een gezamenlijke visie afwegingen gemaakt worden op portfolioniveau. En hoe deze afwegingen, die op een incrementele en iteratieve wijze tot stand komen door voortdurend wijzigende omgevingsvariabelen, recht te laten doen aan de belangen van de business en de mogelijkheden van IT. Afwegingen die tot een juiste balans in time-to-market, efficiency en flexibiliteit leiden, zodat maximaal waarde gecreëerd wordt voor de business.

Dag 2, deel 1 - Programma’s & Projecten

In traditionele omgevingen maken programmamanagers en projectleiders de vertaalslag van portfoliokeuzes naar programma’s en projecten. Deze rollen bestaan in een agile omgeving niet meer als zodanig, maar deze vaardigheid blijft nodig. Wat moet er gebeuren om bijvoorbeeld een Scrum traject succesvol te laten zijn? Je leert hierin meer over retrospectives (leren en verbeteren), leiderschap, verandermanagement en technieken als Value Stream Mapping.

Uiteindelijk gaat het om de maximale opbrengst van agile werken in het portfolio. Belangrijke aspecten zijn daar de coördinatie van afhankelijkheden en de invloeden van (her)prioritering, naast de afwegingen tussen business functionaliteiten en IT-architectuurontwikkelingen.

Dag 2, deel 2 - Scaling Agile

Er zijn meerdere raamwerken en best practices voor het opschalen van agile werken van teamniveau naar een organisatie brede werkcultuur. Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Scrum of Scrums (SoS), Large Scale Scrum (LeSS), Scaling Agile @ Spotify (SA@S), Agility Path / Evidence Based Management (EBMgt) en Enterprise Transition Framework (ETF) worden toegelicht en met elkaar vergeleken.

Er wordt ook specifiek aandacht besteed aan hoe je de balans kunt vinden tussen werken vanuit een portfolio en de, vaak autonome, uitvoering op teamniveau. Hoe communiceer je transparant, van portfolio naar programma’s en projecten, van programma’s en projecten naar de uitvoerende teams en vanuit de teams naar de beoogde (eind)gebruikers voor de onderlinge afstemming? En dan zodanig zodat je flexibel kunt (bij)sturen, wijzigingen niet als hinderlijk ervaren worden en de samenwerking over verschillende lagen in de organisatie wordt bevorderd?

Dag 3, deel 1 –Transformatie

Met alle theorie bekend resteert de vraag hoe je de omslag kunt maken van een organisatie waar (ook) agile gewerkt wordt naar een agile organisatie. Hoe geef je richting aan verandering? Hoe stuur je daar op, hoe organiseer je dat? Welke skills zijn nodig om een dergelijke transformatie tot een goed einde te brengen?

We kijken hierbij naar enkele typische voorbeelden, waarbij best practices aan bod komen om veel voorkomende valkuilen en blokkades te vermijden. Daarbij besteden we aandacht aan zowel top-down als bottom-up activiteiten en interventies.

Dag 3, deel 2 - De omgeving moet mee

Aandacht voor ‘de periferie’. De overgang naar Agility (meestal gefocust op software-ontwikkeling) vraagt ook aanpassing in en aandacht voor andere organisatorische onderdelen en aangelegenheden, zoals:

• HRM: functiegebouw, competenties, beoordeling, motivatie en leiderschap.
• Financiën: waar voor mijn geld (capaciteit versus resultaat), kapitalisatie en investeringsbeslissingen.
• Marketing: invloed van variabele scope en ‘fixed’ date.
• Contracting: prestatie of product, continuïteit en partnerschap, “Money for Nothing” & “Change for Free”.
• Sourcing: co-location, cultuur- en tijdverschillen, stand-ups, check out – check in.
• Architectuur: emerging (lean) architecture versus lange termijn keuzes en investeringen.
• Security: borging van kwaliteit en veiligheid in een agile omgeving.
• Hardware ontwikkeling: agility en hardware ontwikkeling (als geïntegreerd product met software).
• De (externe) klant: hoeveel wijzigingen (in de tijd) kan de klant aan? Hoeveel onzekerheid m.b.t. scope en functionaliteiten wil de klant accepteren? Hoeveel inspanning kan/wil de (externe) klant steken in continue prioritering en ‘refinement’, waar ligt de grens van de betrokkenheid?