Agile Transformatie: een kwestie van doen!

26 Januari 2017
Categorie:
  • Subject matter

Webinar Agile Transformatie Annerieke Bosman Milan Drop

Agile is ‘top of mind’ voor veel organisaties én hun medewerkers! Er wordt wel gezegd dat we in een verandering van tijdperk leven en Agile speelt daar een grote rol in. Op het moment wordt er veel over gesproken in allerlei wisselende contexten, maar wat is het nu echt? Hoe kun je als organisatie transformeren om wendbaarder en effectiever te worden (want dat is het doel van Agile)?

 

In dit webinar leer je heel kort de theorie rond Agile en welke stappen je kunt nemen om te transformeren naar Agile.  We nemen je mee naar situaties die zich bij eigenlijk elke Agile transformatie voordoen en geven je handvatten om deze te hanteren.

 

Webinar 'Agile Transformatie: kwestie van doen!'

 

 

Annerieke Bosman webinar Agile Transformatie

Annerieke Bosman, trainer en coach Personal Skills bij Capgemini Academy.

Ik ben Annerieke Bosman en ik richt mij op medewerkerontwikkeling en organisatieontwikkeling. Het Agile denken past hier goed bij. Medewerkers ontlenen binnen de groot geformuleerde organisatiedoelen motivatie aan haalbare stappen, die tot resultaat leiden. Natuurlijk roept een Agile transformatie weerstand op, het zou vreemd zijn als dat niet zo was. Ik zet graag mijn ervaring als consultant, trainer en coach in om medewerkers te ondersteunen bij de omslag in denken en werken die van ze wordt gevraagd.

 

 

Milan Drop Webinar Agile Transformatie

 

Milan Drop, Afstudeerder master Innovation Management Technische Universiteit Eindhoven

 

Mijn naam is Milan Drop en ik doe onderzoek naar de uitdagingen en succesfactoren in Agile transformaties. In mijn onderzoek leg ik een verbinding tussen literatuur en praktijk. Dit onderzoek wordt uitgevoerd in opdracht van Capgemini en is tevens mijn thesis voor de master Innovation Management aan de Technische Universiteit Eindhoven.

 

Hoewel elke organisatie anders is, zie je een herkenbare dynamiek ontstaan als de bestaande structuur niet meer blijkt te voldoen. Graag deel ik de inzichten en ervaringen die ik tot dusver heb opgedaan.

 

Vragen & antwoorden

  • Hoe kan je testen of de mindset veranderd is? 
    Deze vraag wordt tijdens het webinar beantwoord. Zie: 10:45.

 

 

  • Bij het veranderen van de mindset. Gaat het hierbij om die van de teamleden of om die van de klant?
    Deze vraag wordt tijdens het webinar beantwoord. Zie: 14:30.

 

 

  • Hoe moeten we de vier Values lezen als het in het werk niet om software gaat?
    Deze vraag wordt tijdens het webinar beantwoord. Zie: 24:00.

 

 

  • Welke (scrum)rol/wie is verantwoordelijk voor (of stuwt) de (noodzakeljke) verandering van de mindset?
    Deze vraag wordt tijdens het webinar beantwoord. Zie: 26:30.

 

 

  • Het nieuwe werken is ook populair. Hoe gaat scrummen en nieuw werken samen?​
    Deze vraag en de mogelijke varianten worden tijdens het webinar beantwoord. Zie: 27:31.

 

 

  • Als face to face communicatie een eis is, is het dan mogelijk om agile teams te hebben met mensen op verschillende locaties, of mensen die parttime een inzet hebben en niet altijd aanwezig zijn?
    Deze vraag en de mogelijke varianten worden tijdens het webinar beantwoord. Zie: 28:30.

 

 

  • Duurt de doorloop dan niet langer? als je fouten mag maken etc (slide 12)
    Deze vraag wordt tijdens het webinar beantwoord. Zie: 31:53.

 

 

De vragen die niet tijdens het webinar zijn beantwoord.

 

  • Het versturen van een mail zorgt er wel voor dat hetgeen er wordt afgesproken ook wordt vastgelegd. Hoe doe je dat als alles mondeling wordt afgestemd?
    Binnen een agile team draait het allemaal om duidelijk, eenduidig en continu communiceren. Voor “vastlegging” wordt onder andere het Scrumboard gebruikt. Maar belangrijkste is dat het team op elkaar kan vertrouwen. Als dat er niet is en dingen moeten vastgelegd worden om opgevolgd te worden, werkt agile niet.

 

 

  • Wat is nu verschil tussen het 3-focus model en de Agilometer?

    De Agilometer is een assessment tool dat onderdeel is van PRINCE2 Agile. Het dient om aan het begin en gaandeweg een project in te schatten waar de risico’s van een agile aanpak liggen. DSDM Agile Project Management heeft een vergelijkbaar assessment tool: de Project Approach Questionnaire. Deze laatste gaat uit van 17 stellingen die je op een vijfpuntsschaal kunt scoren. Bij de Agilometer zijn deze aspecten samengevat in 6 ‘sliders’, die je eveneens op een vijfpuntsschaal kunt scoren. Zowel PRINCE2 Agile als DSDM Agile Project Management geven tips over acties die je kunt nemen op die aspecten waar je laag scoort.

     

    Er is geen directe relatie tussen het 3-focus model en de Agilometer. Maar in een organisatie die al voor een groot deel een agile transitie heeft doorgemaakt, ligt het wel voor de hand dat je hoog scoort op de sliders “Advantageous environmental conditions” en “Acceptance of agile”.

    Meer informatie over de Agilometer staat hier.

    Meer informatie over de DSDM Project Approach Questionnaire vind je hier.

 

 

  • Hoe zien jullie de accountability: budget vs hetgeen daadwerkelijk is opgeleverd door het team? (dus niet opgeleverde waarde, maar businesscase vs actuals)

    Wanneer een organisatie op een agile manier ingericht is en op een agile manier gaat werken, dan is dat in principe gekoppeld aan het concept “werk naar mensen brengen”. Oftewel: we gaan werken met vaste teams, rondom producten, diensten of ketens. Daarbij heeft elk team of elk team van teams altijd een werkvoorraad (backlog) die we continu prioriteren. In deze situatie worden zaken als budget en business case veel minder belangrijk: we zorgen er gewoon voor dat de teams continu aan die zaken werken die we nu belangrijk vinden. Vandaar dat een framework als Scrum ook niets zegt over budget en business case.

     

    Wanneer je agile gaat opschalen en daarbij bijvoorbeeld het Scale Agile Framework (SAFe) gebruikt, dan vind je daarin wel enkele proven patterns op dit gebied, zoals de light weight business case en de rol van de productmanager als budgethouder.

     

    Dit ligt overigens anders wanneer je projectmatig werkt, dus daar waar je mensen naar het werk brengt in plaats van werk naar de mensen. Ook bij projecten die je op een agile manier in een agile omgeving uitvoert zijn zaken als budget en business case uiteraard belangrijk en zowel in PRINCE2 Agile als DSDM Agile Project Management is de accountability hieromtrent belegd bij daartoe gedefinieerde rollen.

 

 

  • Hoe kun je je als klant van vendors zoals Capgemini voorbereiden op de komst van Agile ontwikkelteams. Welke mindset/randvoorwaarden moet je als klant zeker geregeld hebben?

    Het is lastig hier een uitputtende / minimale lijst te geven, maar enkele zaken die belangrijk zijn:

     

    Een goed begrip van wat agile denken en werken is (conform het agile manifesto en de 12 principes) bij iedere betrokkene: van raad van bestuur en directie tot op de werkvloer en alle lagen er tussen in

     

    Inclusief de daarbij behorende stijlen van leidinggeven

     

    En het besef dat we geen glazen bol van de toekomst hebben en dat (met name IT-) werk onvoorspelbaar is

     

    Zodat de klant niet precies van te voren hoeft te zeggen, en kan zeggen, wat de vendor op moet leveren, en dat de vendor niet precies van tevoren kan zeggen wat ze in detail gaan maken en wanneer dat gereed is

     

    En waarschijnlijk een nieuwe focus op meten en rapporteren: een verschuiving van tijd en geld naar opgeleverd product

     

    Met de goede faciliteiten, zoals teamruimtes en tools

     

    Het besef dat we samen op willen trekken, zeker ook als er lastige situaties ontstaan, en niet tegenover elkaar willen staan

     

    Dus zorgen dat je elkaar goed kent en vertrouwt, we weten dat dit allemaal niet van te voren geregeld kan zijn, Agile is ook al doende leren. Daarmee het laatste punt: de bereidheid om te beginnen en samen te leren van fouten.

 

 

  • Hebben jullie ook ervaring bij het invoeren van Agile in een beheerorganisatie / -afdeling? Er wordt dus geen product opgeleverd. Met welke aspecten zou je bijvoorbeeld rekening moeten / kunnen houden?

    Agile werken kun je ook prima toepassen binnen een beheersomgeving. Want ook daar doe je uiteindelijk aan productontwikkeling en kun je je richten naar de 12 principes achter het Agile Manifesto. Het werk zal waarschijnlijk minder goed van tevoren planbaar zijn. Vandaar dat beheerteams meestal niet Scrum als teamframework gebruiken, maar Kanban. Kijk ook eens op 'Agile beheer'.

     

    Als we kijken naar de teams, dan zien we steeds meer DEVOPs, wat inhoudt dat mensen van operations samen met mensen van development aan de slag gaan.

     

    De intentie is goed, wel lijkt dat de waarde en normen van developers afwijken van operation mensen die veelal uit zijn op stabiliteit en elke verandering is in principe een bedreiging van die stabiliteit.  Dus gedragsaspecten zijn cruciaal. Verder: werk van een ander lijkt altijd simpel, simpelweg omdat je het zelf nooit doet en dus ook niet weet wat er allemaal speelt. Dus onbegrip naar beiden kanten. Juist door in een team samen te werken kan dat ombegrijp verdwijnen, maar bij aanvang is dat zeker aanwezig.

 

 

  • Is prince 2 overbodig met Agile?
    Niet alle situaties zijn geschikt om met een Agile aanpak op te pakken. Het is belangrijk om de juiste keuze te maken voor de methodiek die je gebruikt. PRINCE2 kan voor bepaalde situaties de juiste methodiek zijn, soms is er behoefte aan hybride methodieken als PRINCE2-Agile of DSDM Agile Project Management en soms is Scrum of een andere vorm van “pure” Agile het beste.

 

 

  • Bij "projecten" met meerdere scrum teams heb je iemand nodig die sturing geeft en management activiteiten uitvoert, het geheel overziet, risico's etc. Dus volgens mij blijven rollen die "managen" echt nodig. de teams zijn niet helemaal self-organising.
    Er zijn verschillende methodieken en frameworks die hierbij kunnen helpen. Denk aan SAFe (Scaled Agile Framework), maar ook DSDM Agile Project Management. Dit is situatie afhankelijk.

 

 

  • Hoe belangrijk zijn de inhoudelijke vaardigheden van mensen in een multidsciplinair team, of kun je ook met jonge onervaren mensen teams formeren?

    Ook jonge onervaren mensen kunnen prima meedraaien in een Agile team. Sterker nog: het ‘ideale’ team bevat een mix van senior, medior en junior teamleden. Waarbij de senior leden het ‘moeilijke’ werk kunnen oppakken, maar meteen ook de medior en junior mensen kunnen helpen en ondersteunen. Dat biedt de medior en junior mensen dan weer de mogelijkheid om zich te ontwikkelen en bij te leren. En laten nu zowel het helpen van anderen, als het continu kunnen leren en verbeteren, factoren zijn die bij uitstek bijdragen aan motivatie!

     

    Veel jonge mensen met geen ervaring, maar wel een frisse blik en niet beladen door historie zou best wel eens kunnen werken. Een wat ervaren iemand die ook het gehele kan overzien en wat kan relativeren is ook niet verkeerd. Waardering voor ieders inbreng is dan wel cruciaal.

     

    Een team met alleen jonge, onervaren mensen biedt dus wel een risico: het gebrek aan inhoudelijke kennis en vaardigheden. De Scrum Master zou de teamleden moeten stimuleren hier oplossingen voor te zoeken en alert te zijn op een respectvolle omgang met elkaar.

 

 

  • Wat zou je adviseren om een andere mindset bij het management te creeren ten aanzien van bijvoorbeeld deadlines en planning?

    Dé tip is om het complete management (van de directie en de raad van bestuur tot en met de teamleiders en alle lagen daartussen) in een training/workshop/simulatie te laten ervaren wat een agile manier van werken vraagt op het gebied van leiderschap en het verschuiven van de focus op tijd en geld naar een focus op opgeleverde waarde.

     

    Realiseer je dat dit een goede start is, maar zeker niet voldoende. Het is lastig om je manier van denken en werken werkelijk te veranderen. Het heeft tijd nodig, en geduld van degenen (Scrum Master, Agile coach) die zich bezighouden met de Agile Transformatie.

     

    Een confronterende aanpak werkt goed: ‘vroeger’ leek het of het management controle had, maar werden deadlines en budgetten gehaald? Kregen ze dan kwaliteit?

    Het antwoord hierop is eigenlijk altijd: “Nee”. En dan kan je weer verder praten over wat Agile werken biedt.

 

 

  • Hoe zie je de rol van architect, die vaak een big picture in de gaten moet houden? Waarschijnlijk een kwestie van UFD (up-front design), Big of 'Dun'-BUFD of DUFD.

    Ook bij Agile werken, en misschien wel juist bij Agile werken, is het belangrijk om de ‘grote lijn’ in de gaten te houden, zowel op business als technisch gebied. Waarbij er dus nog steeds een rol is weggelegd voor architecten. Met waarschijnlijk wel twee verschillen met hoe het ‘vroeger’ vaak ging. Ten eerste vinden we het belangrijk dat de architect die de grote lijn uitzet dat niet solo doet, maar vooral in samenwerking met de agile teams.

     

    En ten tweede dat we ons niet in detail moeten proberen vast te leggen voor de verre toekomst. Dus ook de grote lijn ontstaat iteratief en incrementeel.

     

    Binnen het Scaled Agile Framework (SAFe) is dit mooi gevisualiseerd en beschreven met het fenomeen van de Architectural Runway.

     

    We zien dat de architect zijn rol vaak moet bevechten in het Agile team, hij heeft een andere invalshoek, andere scope en soms ook een manier van communiceren die moeilijk aansluit bij het Agile team. Zaken als een backlog, sprint backlog etc. verhouden zich vaak lastig tot datgene waar de architect voor staat. Toch zou het Agile werken, met de nadruk op leren van elkaar en leren van fouten, hier stapsgewijs oplossingen voor moeten vinden.

 

 

  • Hoe kan je Agile werken samen met de klant als de tools die gebruikt worden nog ITIL gebaseerd zijn en afspraken van opleveren in SLA's zijn vastgelegd?

    Probleem zit hem niet in ITIL, maar in de manier waarop we SLA’s gebruiken. SLA’s zijn juist gericht op het hebben van een focus, maar helaas is het in de praktijk een juridisch document met allerlei clausules. Ook een SLA zou indicatief moeten zijn ipv allesbepalend.

     

    ITIL zelf staat Agile werken niet in de weg. In tegendeel zelfs. Processen zoals problem management moet je juist met een Agile team oppakken. Idem voor de processen die in Service Design zijn opgenomen.

 

 

  • In welke situaties hebben jullie gezien dat Agile ongeschikt is? (maw wat zijn de grenzen van Agile werken?)

    Agile werken betekent dat je het gedachtegoed en de principes van LEAN toepast op productontwikkeling. Agile komt het beste tot zijn recht bij productontwikkeling waarbij er onzekerheid, onvoorspelbaarheid is. Hetzij op het ‘wat’ (de requirements), of het ‘hoe’ (de technologie), of een combinatie daarvan.

     

    Dit betekent dat er ook situaties zijn waarbij Agile niet zo’n zinvolle aanpak is. Met name daar waar je:

     

    niet aan productontwikkeling doet;

    neem bijvoorbeeld medewerkers die in een call center de hele dag telefoontjes beantwoorden; ik zou die niet in Scrum-teams zetten en op een agile manier laten werken, omdat ze niet aan productontwikkeling doen; uiteraard kun je ook in deze situatie aan continue verbetering werken, maar richt je dan op LAEN.

     

    wel aan productontwikkeling doet, maar waarbij het ‘wat’ en het ‘hoe’ erg voorspelbaar zijn (b.v. het bouwen van een rijtjeshuis).

     

    Agile is dus geen silver / magic bullet die al onze problemen oplost

 

 

  • Sinds wanneer bestaat Agile al? En wat is de meest recente, opvallende vernieuwing?
    Agile bestaat al heel lang, maar de term Agile is voor het eerst officieel gekoppeld aan software ontwikkeling, in 2001, toen het Agile Manifesto is opgesteld. Meest opvallende ontwikkeling betreft het ontstaan van de grotere frameworks als SAFe en dergelijke.

 

Linkjes

Tijdens het webinar zijn meerdere linkjes naar voren gekomen. Hieronder hebben wij voor jou de linkjes op een rij gezet: