Schalen: alignment en autonomie

Na het beschrijven van de noodzaak van een leren organisatie hebben we inzicht gegeven over de basisingredienten van een snelle en wendbare organisatie. Vanuit daar hebben we eerst gekeken hoe we vanuit een visie komen tot het ontwikkelen van een product en vervolgens hoe we producten snel(ler) voor de gebruikers beschikbaar krijgen. In dit en het volgende artikel gaan we in op de essentiële ingrediënten voor het creëren van alignment en autonomie van teams in de organisatie: doelen en kaders. 

In het spreekwoordelijke gezegde “Alleen ga je sneller, samen kom je verder” zitten twee duidelijke effecten. De eerst is dat het toevoegen van mensen aan je groep een negatieve effect heeft op de snelheid die je als groep kunt maken. De tweede is dat het toevoegen van mensen aan je groep een positief effect heeft op het resultaat dat je met deze groep kunt bereiken. Dat er een optimum groepsgrootte is ontstaat doordat het positieve effect van het toevoegen van een persoon lineair verloopt en het negatieve effect van het toevoegen van een persoon exponentieel verloopt. Wat bedoelen we hiermee?

Doet ie ’t?

Doet ie ’t?

In het initiële artikel “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. In het artikel “Van Visie naar Product” hebben we gekeken hoe je van een visie tot een goed geprioriteerde en gebalanceerde product backlog komt. In het artikel “Release early, release often” hebben we gekeken hoe we zorgen dat een product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd? In dit artikel kijken we naar het vraagstuk hoe we bepalen of we de juiste dingen hebben ontwikkeld en of we die dingen op de juiste manier hebben ontwikkeld. 

De focus van veel Scrum teams richt zich op het snel produceren van IT producten op basis van de vraag. Onze aandacht richt zich vaak op de opgeleverde functionaliteit en niet tot nauwelijks naar de mate waarin de behoefte van de gebruikers en/of stakeholders worden ingevuld. In de praktijk zien we hierbij dat de verschillende rollen zich in de uitvoering druk maken over precies die zaken die niet tot hun verantwoordelijkheid behoren. Het is tijd om dat te veranderen. 

DevOps integeren om te kunnen integreren

In de blogpost “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. In de vorige blogposts hebben we de focus gelegd op de uitdaging: “Hoe zorg je dat het product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”. Daarin constateerde we dat release early, release often niet alleen wenselijk maar ook noodzakelijk is en dat er niet een eenduidige definitie is van DevOps. In deze blogpost gaan we in op de integratie van DevOps in het voortbrengingsproces om de lerende organisatie mogelijk te maken.

Zoals we hebben gezien bevat de DevOps beweging een groot scala aan verschillende aspecten. DevOps “omarmen” is om die reden ook meer een reis dan een eindbestemming. Specifiek in het voortbrengingsproces zijn er een drietal aspecten van belang om de stap van het leveren van een potentieel releasebaar product increment naar het nemen van de volledige verantwoordelijkheid voor het product increment te kunnen realiseren.

DevOps to the rescue

In de blogpost “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. In de vorige blogpost hebben we de focus gelegd op de uitdaging: “Hoe zorg je dat het product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”. Daarin constateerde we dat release early, release often niet alleen wenselijk maar ook noodzakelijk is in een lerende organisatie. In deze blogpost gaan we in op de bewegingen binnen het IT-werkveld die onder de noemer van DevOps worden geschaard.

De centrale vraag die binnen het werkveld van software ontwikkeling steeds prominenter werd gesteld is of er een manier bestaat om deze werelden samen te brengen. Kunnen we meer voorspelbaarheid en stabiliteit creëren door sneller en vaker te releasen? Het antwoord hierop heeft geleidt tot iets wat we “DevOps” noemen. Niet één framework maar een beweging die zich richt op het benadrukken van automatisering en monitoring in alle onderdelen bij het bouwen van software, van integratie, testen, release tot deployment en infrastructuurmanagement. Een beweging die zich richt op het in lijn brengen van de werelden van development en operations door een sterke focus op aspecten als cultuur, automatisering, lean, meten en delen. En een beweging die probeert te komen tot kortere ontwikkelcycli, een verhoogde frequentie van oplevering en een meer betrouwbare oplevering.

Release early, release often

In de blogpost “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. Daarbij zijn we twee grote uitdagingen tegen gekomen. De eerste hebben we in de vorige blogpost behandeld waarbij we dieper in zijn gegaan op het onderwerp “Hoe kom je tot een goed geprioriteerde en gebalanceerde product backlog?” In deze blogpost leggen we de focus op de tweede uitdaging: “Hoe zorg je dat het product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”

Als je aan een Scrum team vraagt: “Wanneer is het werk af?”, wordt hopelijk een antwoord gegeven in de strekking van “Wanneer we aan het eind van de Sprint een bruikbaar en potentieel uitleverbaar product increment hebben opgeleverd. Hoewel dit al een stap voorwaarts is vanuit de situatie waarin we pas aan het eind van een langdurig project een bruikbaar en uitleverbaar product opleveren, vormt dit slechts de helft van de uitdaging. De andere helft van de uitdaging is het aangepast product increment ook snel genoeg aan de gebruikers te kunnen leveren.

Van Visie naar Product

In de voorgaande blogpost “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. Daarbij zijn we twee grote uitdagingen tegen gekomen: “Hoe kom je tot een goed geprioriteerde en gebalanceerde product backlog?” en “Hoe zorg je dat product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”. In deze blogpost gaan we dieper in op de eerste uitdaging: “Hoe kom je van een visie tot een goed geprioriteerde en gebalanceerde product backlog?”

Goed product ownerschap is van essentieel belang om tot een goed onderbouwde, op waarde gesorteerde en incrementeel uitleverbare product backlog te komen. Ondanks het feit dat de Scrum guide een goed beeld geeft van de opzet en werking van een product backlog, wordt aan de wijze waarop deze backlog tot stand komt nauwelijks aandacht besteed. Veel product owners lopen dan ook met de vraag rond wat er op de product backlog moet komen te staan, hoe ver deze uitgewerkt moet worden, wat het juist balanceren van een backlog betekent, hoe de waarde en daarmee de prioriteit van product backlog items moet worden bepaald en hoe je overzicht houdt over de complexiteit die product ontwikkeling met zich mee brengt.

Een goed onderbouwde, op waarde gesorteerde en incrementeel uitleverbare product backlog is niet het begin van Scrum maar het eindresultaat van een voortdurend en iteratief proces van product verkenning en ontwikkeling. Dit proces begint bij met neerzetten van een heldere, duidelijke visie voor het te realiseren product of doel, waarna in verschillende stappen en activiteiten de mate van detaillering, prioriteitstelling en waarde worden uitgewerkt op basis van de ervaringen die met het product in de praktijk wordt opgedaan. Met het ontbreken van een duidelijke visie is de kans op een stuurloos Scrum team erg groot, er is immers geen stip op de horizon waar het team zich op kan richten. Helaas komen we in de praktijk regelmatig Scrum teams tegen zonder visie, een onbekende visie of een zeer onduidelijke visie.

Back to Basics

In de eerdere blogpost “De noodzaak van een lerende organisatie” hebben we geconstateerd dat door middel van het verrijken van de Plan – Do mindset met concepten als Iteraties en Inspect & Adapt organisaties zich langzaam transformeren naar lerende organisaties. In deze blogpost kijken we naar de complexiteit van het toevoegen van Inspect & Adapt binnen bestaande organisaties en gaan we daarom terug naar de absolute basis van een lerende organisatie.

Het klinkt zo eenvoudig: werk in kortere iteraties en voeg Inspect & Adapt toe om een lerende organisatie te creëren. De praktijk is echter weerbarstiger en leidt tot veel nieuwe uitdagingen waar we mee te maken krijgen. Bijvoorbeeld, wanneer is een product (voldoende) klaar als we daar in een continue flow van iteraties steeds aanpassen? Wanneer gaan we over van Change the Business naar Run the Business? Hoeveel budget hebben we nodig als we niet exact kunnen bepalen hoe het eindproduct er uit ziet? Hoe bepalen we of nieuwe ontwikkelingen nog in de scope van onze originele business case vallen? En als we continu opnieuw afwegen of verdere ontwikkeling de investering waard is hebben business cases dan überhaupt nog waarde?

De noodzaak van een lerende organisatie

De noodzaak om een lerende organisatie te worden lijkt onvermijdbaar. Organisaties die niet actief leren van en over hun klanten, de economie, hun medewerkers, technologische innovaties, etc. zijn niet in staat zich voldoende snel aan te passen aan de veranderende omstandigheden waarin zij opereren. Organisaties die moeite hebben om te leren hebben hierdoor een steeds grotere uitdaging om relevant te blijven ten opzichte van hun concurrentie. Herbert Spencer, een Brits socioloog, filosoof en antropoloog vatte een gelijksoortige observatie samen in de term: “Survival of the fittest”, oftewel degene die zich het best aan de omstandigheden kan aanpassen heeft de grootste kans om te overleven.

“Onzin! Alsof de klant precies weet wat hij nodig heeft!” hoor ik een voormalig topmanager nog zeggen, gevolgd met het citeren van de welbekende quote van de Amerikaanse industrieel Henry Ford: “If I had asked them what they wanted they would have said a faster horse.” Hiermee suggererend dat een productontwikkelaar precies weet wat zijn klant nodig heeft en een gedegen implementatieplan nodig heeft om dit product te realiseren. Dit werkt echter alleen wanneer het eindproduct in alle details te beschrijven is én wanneer de gewenste toekomstige situatie in de periode van planvorming tot realisatie niet aan wijzigingen onderhevig is.

Het is precies deze benadering die zich het best laat omschrijven als Plan – Execute. Deze stijl kenmerkt zich door twee opeenvolgende activiteiten. De Plan activiteit, waarin we het verschil tussen de huidige situatie en de gewenste situatie grondig analyseren en een uitgebreid plan formuleren die ons van de huidige naar de toekomstige situatie brengt. En de Execute activiteit, waarin we – veelal door andere personen – het ontwikkelde plan zo goed als mogelijk uitvoeren.

Effectief meten van Agile teams – deel 2: de ‘how’

In het eerste deel van onze blog lag de focus op “waarom” teams inzicht willen geven in hun Agile volwassenheid. We hebben daarbij zowel gekeken vanuit het gezichtspunt van de organisatie als het gezichtspunt van de teams zelf. En de aspecten die een goed self assessment nodig heeft om de juiste acties te stimuleren en de typische valkuilen van (self) assessments daarbij zoveel mogelijk te voorkomen. In dit vervolg gaan we, op basis van deze eerdere verkenning, in op een model dat zoveel mogelijk de genoemde aspecten in zich heeft en daarmee antwoord geeft op de vraag “hoe” teams een goed inzicht kunnen geven in hun volwassenheid.

Wat is de kern van een Agile volwassen team? In onze ogen is dat een Agile team dat zo snel mogelijk waarde levert voor de business, zonder daarbij in te leveren op kwaliteit. Daarbij neemt het regelmatig de tijd om te verbeteren op basis van ingerichte feedbackcycli. Zowel het Agile Manifesto als de Scrum Guide staan in het teken van deze drie-eenheid en Hendrik Kniberg gaat in zijn onofficiële Scrum checklist zelfs zover om te stellen dat wanneer je proces prima is wanneer je deze drie aspecten hebt gerealiseerd.

Zo snel mogelijk waarde leveren voor de business realiseert een Scrum team door elke sprint een werkend product op te leveren dat de – voor dat moment – hoogste business waarde voor de business in zich heeft. Hoewel dit de primaire verantwoordelijkheid is van de Product Owner, maken zowel Agile als Scrum principes dit ook echt mogelijk. Denk hierbij aan de nauwe samenwerking met de klant, het mogelijk maken om laat in het proces wijzigingen door te kunnen voeren (die een hogere business waarde genereren) en best practices als het inzicht geven in het langetermijndoel middels een vision board of product canvas.

Effectief meten van Agile teams – deel 1: de ‘why’

Als het gaat om het inzichtelijk maken van de volwassenheid van Agile teams, zitten Agile coaches veelal tussen twee vuren ingesloten. Aan de ene kant hebben zij “de organisatie” die graag wil weten hoe hun Agile teams het doen en aan de andere kant “de Agile teams” die zelf verantwoordelijk zouden moeten zijn voor hun continue verbetering. Ook in het land van Agile coaches en consultants zijn de meningen over dit onderwerp sterk verdeelt met vurige flamewars tot gevolg. Waarom is het meten belangrijk voor Agile teams? Wat moeten de resultaten weergeven? En hoe meten we dan op effectieve wijze?

De opdracht van Agile coaches en consultants vanuit hun opdrachtgever is om de Agile volwassenheid van teams naar een hoger niveau te krijgen. Deze opdracht impliceert een aantal dingen. Enerzijds betekent dat de Agile volwassenheid iets is wat gemeten kan worden en anderzijds dat externe factoren (in dit geval de inspanning van een coach) direct invloed kunnen hebben op deze volwassenheid. De uitdaging hierin is dat een belangrijk onderdeel van Agile volwassenheid juist gaat om het feit dat teams in staat zijn zichzelf te organiseren en verbeteren.