Agile laten werken met metagility (met David Bishop van Agile Worx)

Lees het transcript:

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typfouten; de bot is niet altijd 100% correct.

Ben Aston: Laat me raden: je deed alles volgens de Watervalmethode, dat werkte niet, en daarna probeerde je Agile, maar dat werkt ook niet echt.

Dus nu combineer je verschillende aanpakken. Je hebt een schep Agile en een schep Waterval en probeert er nog wat versiering bovenop te doen. Blijf luisteren naar de podcast van vandaag over metagility. Misschien leer je wel het een en ander over hoe een Agile-playbook kan worden gebruikt om het beste van beide werelden te combineren.

Bedankt dat je luistert. Ik ben Ben Aston, oprichter van The Digital Project Manager. Welkom bij de DPM-podcast. We zetten ons in om projectmanagers te helpen slagen en om mensen die projecten beheren te helpen betere resultaten te leveren. We helpen je om je vaardigheden op het gebied van projecten naar een hoger niveau te tillen. Kijk op thedigitalprojectmanager.com voor meer informatie over de trainingen en hulpmiddelen die we via het lidmaatschap aanbieden. Deze podcast wordt aangeboden door Clarizen, de leider in software voor enterpriseproject- en portfoliomanagement. Ga naar Clarizen.com voor meer informatie.

Vandaag spreek ik met David Bishop. Dr. David Bishop is technoloog, consultant, onderzoeks­ondernemer en docent, met meer dan 25 jaar ervaring in telecom, transport, overheid en nutsbedrijven. Hij is CEO en oprichter van Agile Worx, LLC. Je kunt daar meer over lezen op Agile-worx.com. Het bedrijf levert softwaretools voor programma- en projectbeheer, trainingen en adviesdiensten. Hij is ook de auteur van Metagility: Managing Agile Development for Competitive Advantage. Bedankt dat je vandaag bij ons bent, David.

David Bishop: Bedankt voor de uitnodiging.

Ben Aston: Ik wil dieper ingaan op het idee om vanaf nul een raamwerk op te bouwen. Kun je iets vertellen over je achtergrond en hoe je besloot dat de wereld een nieuw raamwerk nodig had? Welke ervaringen hebben je naar dat punt geleid?

David Bishop: Ik werk nu ongeveer 25 jaar in technologieontwikkeling, voornamelijk als systeemarchitect en systeemingenieur, waarbij ik oplossingen met nieuwe technologieën ontwikkel. Ongeveer tien jaar geleden begon ik te werken bij een bedrijf dat zich sterk bezighield met het industriële internet der dingen. Een van de dingen die het bedrijf dringend probeerde te doen, was het invoeren van Agile-methodologieën.

De reden daarvoor was dat klanten erom vroegen. Het bedrijf bevond zich in een relatief nieuwe technologische markt en probeerde nieuwe technologie in die sector te integreren. Er waren veel concurrenten die nieuwe slimme-netwerktechnologie ontwikkelden met allerlei verschillende RF-communicatie.

Het bedrijf probeerde meerdere keren Agile in te voeren, omdat het van cruciaal belang was om producten zo snel mogelijk op de markt te brengen. Er werden goedbetaalde consultants ingeschakeld, maar de pogingen mislukten keer op keer. Ik hielp deze organisatie de producten te ontwikkelen en tegelijkertijd Agile in te voeren. Uiteindelijk dacht ik: dit moet anders kunnen.

Agile heeft veel succes gehad en is zeker een goed idee, maar het kent ook tekortkomingen. Gedistribueerde teams, grote teams, zeer complexe ontwikkelomgevingen en ingewikkelde producten kunnen grote uitdagingen vormen voor organisaties die Agile in zijn puurste vorm proberen toe te passen.

Ben Aston: Dat herken ik. Kun je iets meer vertellen over je ervaring binnen die projecten? Wat zag je in de dagelijkse praktijk? Welke waarschuwingssignalen lieten zien dat er iets niet klopte?

David Bishop: Er was enorme weerstand bij sommige teams. Het ging niet om lichte weerstand; het was harde weerstand en er waren klachten dat het proces simpelweg niet werkte en nooit zou kunnen werken. De omgeving bestond uit embedded systemen. De producten waren niet alleen software, maar apparaten. Apparaten bestaan doorgaans uit embedded systemen waarin hardware, firmware en software door verschillende teams, afdelingen of soms bedrijven worden ontwikkeld.

Op een bepaald moment moeten alle drie de onderdelen echter als één samenhangend product worden getest en uitgebracht. Softwareteams werkten bijvoorbeeld in sprints van twee weken en hielden dagelijkse stand-ups, terwijl hardwareteams dat tempo niet konden volgen. Hun producten hadden vaak een releasecyclus van twaalf tot achttien maanden.

Dat verschil in tempo is een van de belangrijkste redenen waarom complexe organisaties moeite hebben met Agile. Hardware moet worden geïntegreerd, grondig getest en vaak aan veel strengere regelgeving en kwaliteitsnormen voldoen. Denk aan slimme meters, slimme auto’s of avionicasystemen. De gevolgen van fouten zijn daar veel groter dan bij een gewone softwareapplicatie of e-commercesite.

Ben Aston: Als je meer wilt lezen over het ontstaan van Metagility, kijk dan op thedigitalprojectmanager.com. Laten we nu dieper ingaan op het raamwerk zelf en kijken welke onderdelen we op onze eigen projecten kunnen toepassen.

Agile-methodologieën zijn populair en worden breed geaccepteerd als een goede manier om softwareontwikkeling te beheren. Toch is de betekenis van Agile in de praktijk voor interpretatie vatbaar. Daarom kiezen veel organisaties uiteindelijk voor een hybride aanpak waarin verschillende raamwerken en werkwijzen worden gecombineerd met de beperkingen van de organisatie.

David Bishop: Metagility is een raamwerk. Het helpt je eerst bepalen welk type Agile-aanpassing je nodig hebt: een zuivere Agile-aanpak, een hybride aanpak of in sommige gevallen een Watervalaanpak. Die keuze moet gebaseerd zijn op onderzoek naar de complexiteit van je product, de onderlinge afhankelijkheden en de omvang van je teams.

Bij embedded systemen, waar producten complex zijn en teams groot en verspreid zijn, werkt een volledig zuivere Agile-aanpak meestal niet. Een doelbewust ontworpen hybride aanpak kan daar uitstekende resultaten opleveren. Softwareteams kunnen bijvoorbeeld sprints van twee weken gebruiken, middlewareteams een ander ritme hanteren en hardwareteams een langere cyclus volgen. Het doel is de doorstroming door het hele proces te behouden.

Metagility beschrijft ook hoe verschillende teams Agile- of Watervalconcepten kunnen toepassen en hoe fasepoorten binnen een hybride aanpak als controlemechanisme kunnen dienen. Daarnaast bevat het raamwerk richtlijnen voor meetgegevens en zes duidelijk gedefinieerde categorieën van interacties, gebaseerd op succesvolle praktijkvoorbeelden. Daardoor wordt het een gedetailleerd playbook voor het beheren van een hybride Agile-implementatie.

Ben Aston: Hoe bepaal je de juiste combinatie van Agile-eigenschappen? En hoe weet je of de bestaande situatie acceptabel is of dat er evolutie of een radicale verandering nodig is?

David Bishop: Je krijgt het beste antwoord door wetenschappelijke methodologie en praktijkgericht onderzoek te gebruiken. Wat bij het ene bedrijf werkt, werkt niet automatisch overal. ICT-omgevingen zijn sterk afhankelijk van de context. Door bijvoorbeeld interpretatieve casestudy’s en etnografisch onderzoek toe te passen, kun je bepalen welke inzichten overdraagbaar zijn van de ene organisatie naar de andere.

Metagility is daarom geen one-size-fits-all-raamwerk. Het is aanpasbaar. Het bevat bovendien de theorie van Agile-vorticiteit, waarmee je kunt meten hoe Agile een organisatie werkelijk is en welke vooruitgang nog mogelijk is.

Ben Aston: Welke impact heb je gezien bij organisaties die dit raamwerk hebben toegepast?

David Bishop: Veel van onze casestudy’s vonden plaats in de markt voor embedded systemen. Organisaties die metagility-concepten toepasten, werden in veel gevallen marktleider of kwamen daar dicht bij in de buurt. Ze verkortten hun cyclustijden, behielden de gewenste kwaliteit en klanttevredenheid en brachten innovatieve producten sneller op de markt.

Ben Aston: Waar gaat de implementatie mis als Metagility niet werkt?

David Bishop: Er zijn twee belangrijke oorzaken. Ten eerste is steun van de directie essentieel. Elke transformatie begint aan de top en leidinggevenden moeten begrijpen welk bedrijfsdoel je probeert te bereiken. Ten tweede is slecht requirementsmanagement een groot probleem. In een Agile omgeving verzamel je requirements niet alleen; je ontwikkelt ze samen met de klant. Als businessanalisten requirements blijven brainstormen en steeds meer functies toevoegen, worden releases overvol, raken functies onderbenut en loopt de technische schuld uit de hand.

Ben Aston: Wat is een goede eerste stap voor een organisatie die Metagility wil toepassen?

David Bishop: Bouw nieuwe klantrelaties op. Klant­samenwerking en contractonderhandeling zijn in werkelijkheid onderdeel van hetzelfde doorlopende proces. Je moet samenwerken met klanten die bereid zijn deel te nemen aan het testen en ontwikkelen van het product. De meest succesvolle organisaties hebben een duidelijke visie en kiezen bewust met welke klanten ze wel en niet samenwerken.

Ben Aston: Dat zijn waardevolle adviezen. Als we echte waarde willen leveren aan eindgebruikers en klanten, hebben we een samenwerkingsmodel nodig dat die aanpak ondersteunt. Bedankt, David, dat je vandaag met ons over Metagility hebt gesproken.

David Bishop: Heel erg bedankt.

Ben Aston: Ik hoor graag wat jij ervan vindt. Heb je het boek metagility gelezen? Laat het ons weten in de reacties. Als je meer wilt weten over Metagility en Davids boek, bezoek dan Agileworx.com. Daar vind je ook informatie over trainingen en cursussen.

Als je meer wilt leren en vooruit wilt komen in je werk, word dan lid van onze DPM-community via thedigitalprojectmanager.com/membership. Je krijgt toegang tot ons Slack-team, sjablonen, workshops, AMA-sessies, spreekuren, e-books en meer. Vond je deze aflevering interessant? Abonneer je dan en blijf op de hoogte via thedigitalprojectmanager.com. Tot de volgende keer, en bedankt voor het luisteren.