Waar we ons als Agile community lekker konden afzetten tegen al die vastgeroeste waterval collega’s, doen we nu vaak weer vrolijk mee. Zonder nadenken kopiëren we het gedrag van anderen, gewoon omdat iedereen het doet. Of zoals mijn leidinggevende ooit tegen me zei toen ik vroeg waarom we nog een prikklok hadden: “Zo doen we dat hier nu eenmaal, jongeman.”

De anekdote van apen en bananen

Een van de anekdotes die lange tijd populair was in de Agile community, is het verhaal over een groep apen in een hok met ergens bovenin een lekkere banaan. Zodra een aap deze wil gaan pakken, gaat de brandslang erop. Ook de anderen krijgen een portie koud water over zich heen. Apen houden niet van koud water en dus haalt niemand het daarna nog in zijn hoofd om die banaan te gaan pakken. In het vervolg van het experiment worden één voor één de apen geruild voor een ander exemplaar. Na iedere ruil doet de nieuweling weer een poging om de banaan te pakken, maar wordt hij fanatiek tegengehouden door de anderen. De groep corrigeert zichzelf steeds weer zonder dat er nog een waterstraal aan te pas komt. Uiteindelijk zit er geen enkele aap meer in het hok, die zelf ooit is nat gespoten. Toch blijft de banaan hangen. Niemand weet waarom. Het is nu eenmaal zo.

In 1996 werd voor het eerst geschreven over dit experiment door Hamel en Prahalad in hun boek Competing for the Future. Zij halen hierin overigens de resultaten van dit experiment aan zonder daarbij een bron te vermelden. Het experiment schijnt nooit uitgevoerd te zijn en blijkt dus een broodje-aap-verhaal te zijn. Toch wordt het veel gebruikt als we het over cultuur hebben. En laten we eerlijk zijn. Het is natuurlijk een prachtig verhaal waar we onszelf lekker mee kunnen spiegelen.

Een voorbeeld uit de praktijk

Wat dacht je van synchrone sprints ofwel dat alle scrum teams dezelfde cadans moeten hebben? Als je het waagt om te zeggen dat je er met je team niet aan meedoet dan is een verbaasde blik nog het minst erge dat je kunt verwachten. Waarschijnlijk wordt je door een agile coach, manager of release train engineer tot de orde geroepen en wordt er van je verwacht dat je netjes mee hobbelt in de corporate policy.

Waarom dan?

Als je naar het waarom vraagt dan komen de meesten niet verder dan dat je dan beter afhankelijkheden tussen teams kunt managen. Ik vraag me dan af waarom er zoveel afhankelijkheden zijn tussen teams. En gaat dat echt wel beter als we allemaal op dinsdag beginnen? Als ik iets halverwege jouw sprint oplever en je kunt er nog mee aan de slag dan kan dat toch ook best handig zijn?

Een ander veel gebruikt argument is dat je met de vaste cadans complexiteit verminderd. Inderdaad, het spoorboekje met begin en einddatums van alle teams ziet er een stuk eenvoudiger uit. Maar op andere vlakken vergroot je de complexiteit juist en introduceer je allerlei vormen van verspilling. Niet echt lean dus. Ik zal er een paar noemen.

1. Overlapping van benodigde middelen

Als alle teams in dezelfde cadans aan hun sprints werken, kan er op bepaalde momenten een tekort aan benodigde middelen ontstaan, denk bijvoorbeeld aan vergaderruimtes. Er ontstaat piekbelasting op sprintwisseldagen met wachtrijen tot gevolg. Dit kan leiden tot conflicten en het vertragen van het werk. Door de start- en einddatums van de sprints van elkaar te laten verschillen, kunnen deze middelen beter worden verdeeld en kan het werk efficiënter en sneller worden uitgevoerd.

2. Afhankelijkheden en integratie

Als de teams afhankelijk zijn van elkaars werk, kun je door de sprints te spreiden, de teams de tijd en ruimte geven om hun werk te voltooien en eventuele integratieproblemen oplossen voordat andere teams met jouw stuk verder gaan. Dit vermindert de kans op vertragingen en fouten. Je hoeft in scrum niet te wachten met opleveren tot het eind van de sprint, maar de sprint review meeting zit toch echt wel aan het eind.

3. Flexibiliteit en aanpassingsvermogen

Scrum is gebaseerd op het Agile-principe van het omarmen van verandering. Als de teams niet gebonden zijn aan vaste start- en einddatums, kunnen ze flexibeler reageren op veranderingen. Wat doe je bijvoorbeeld als een product owner een sprint heeft afgebroken omdat het sprintdoel niet meer opportuun is? Ga je wachten met de volgende sprint totdat je weer in het juiste ritme zit? Dat is pure verspilling.

4. Continu leren

Scrum is gebaseerd op empirisme. Teamleden kunnen door sprint review sessies van andere teams te bezoeken een hoop leren en waardevolle feedback geven. Die mogelijkheid wil je elkaar toch niet onthouden terwijl je wel met z’n allen aan hetzelfde  product werkt met ook nog eens veel afhankelijkheden? Het is niet erg bevordelijk voor de pijlers inspect en adapt.

5. Planning

Het kan zelfs eenvoudiger zijn om de planning en coördinatie van meerdere teams te beheren als ze niet allemaal op hetzelfde moment hun sprints starten en eindigen. Het helpt bij het voorkomen van overbelasting van de scrum master of product owner, omdat ze beter in staat zijn om hun aandacht te verdelen en de voortgang van elk team te volgen. Als er bijvoorbeeld meerdere teams aan hetzelfde product werken, delen ze één product owner. Die kan zich niet opsplitsen over de scrum events van de verschillende teams heen en zal dus (verplichte!) meetings in scrum moeten laten schieten. Een oplossing hiervoor is meerdere product owners aanstellen, maar dan voldoe je toch echt niet meer aan de scrum guide.

Wel of geen cadans

Al met al kan het gelijktijdig starten en eindigen van sprints voor samenwerkende scrum teams leiden tot inefficiëntie, conflicten en problemen. Door de sprints verspreid te laten plaatsvinden, kunnen teams beter samenwerken en het beste uit hun gezamenlijke inspanningen halen.

Laat je dus niet verleiden om alle teams in dezelfde cadans te laten werken omdat het  nu eenmaal zo moet. Scrum teams zijn zelf-organiserend en moeten dus ook de vrijheid krijgen om hun eigen cadans te vinden. En als ze er dan achter komen dat het toch beter is om synchroon te werken dan is dat prima. Niet omdat iemand vind dat het nu eenmaal zo moet, maar omdat erover is nagedacht.

Het is een droom die met enige regelmaat terugkeert. Ik probeer ergens voor te vluchten – geen idee waarvoor maar het is bedreigend. Iets houdt me tegen, beperkt me in mijn bewegingen. Ik ren, maar in slow motion. Ik beweeg, maar als in een zee van stroop. Dat is geen droom, bedenk ik nu, maar eerder een nachtmerrie. Ongetwijfeld bestaat er een uitleg voor deze nachtmerrie. Anderen hebben hem ook. Nieuw is dat ook hele teams deze ervaring hebben, maar dan in de praktijk van alledag! Een dagmerrie.

Voorspelbaarheid en responsiviteit

Mijn collega’s en ik worden vaak betrokken bij agile transities die al enige tijd onderweg zijn maar die lijken te stokken. Het team of de afdeling wil een beweging maken van een traditionele manier van samenwerken naar een meer wendbare werkwijze. Ze hebben al enkele stappen gezet maar lopen tegen een muur op en komen niet verder. Wat is die barrière en kun je deze slechten?

Een deel van die barrière ligt binnen het team of de afdeling zelf. De mensen doen agile, maar zijn het niet. Nadat ze op cursus zijn geweest maken ze gebruik van allerlei technieken van Scrum. Er zijn product backlogs, stories en burndown charts. Er wordt planning poker gespeeld en ze houden de velocity bij. Maar uit de gesprekken kun je afleiden dat de technieken slechts instrumenteel worden ingezet. Voorspelbaarheid en kosten efficiëntie blijven de dominerende thema’s terwijl waardecreatie en het responsieve element – reageren of anticiperen op ontwikkelingen in de binnen- en de buitenwereld – nauwelijks een rol spelen. Kun je hen dit kwalijk nemen? Ze opereren immers binnen een organisatiecontext die nog traditioneel samenwerkt. Dat is het tweede deel van de barrière. Een organisatiecontext die zich manifesteert als een stel breinaalden die dwars door de afdeling of het team heen prikken.

Prikkende breinaalden vormen een plafond voor wendbaarheid

Iedere organisatie van enige omvang heeft bepaalde bedrijfsfuncties centraal georganiseerd met al dan niet een lokale vertegenwoordiging. Denk aan functies als personeelsmanagement, inkoop en financieel management. Aan hen wordt zelden gedacht als organisaties besluiten meer wendbaar te gaan worden. Dit betekent dat het werk van deze bedrijfsfuncties blijft rusten op de centrale gedachte van voorspelbaarheid en kosten efficiëntie en moet worden gevolgd in de decentrale component van die bedrijfsfuncties. De afdeling of het team moet de input voor het jaarplan opleveren, rapporteren over de uitnutting van het budget en de realisatie van producten in overeenstemming met het plan, aangeven wie in aanmerking komt voor de titel ‘medewerker van de maand’, en ondersteunende tools aanschaffen via een uitvoerig en vooral langdurend inkooptraject. Allemaal activiteiten die een belemmerend effect hebben op de waardecreatie en de responsiviteit van de afdeling of het team.

De tweede barrière – volgend uit de kenmerken van een organisatiestructuur die is gebaseerd op het verlangen naar voorspelbaarheid en kosten efficiëntie – versterkt de eerste. De afdeling of het team komt niet verder in haar reis naar waardecreatie en responsiviteit. Haar wenbaarheid heeft een plafond bereikt.

Het verhogen van het plafond vergt een systemische benadering

Werkelijke wendbaarheid vergt een systemische benadering. Dit begint met de erkenning dat de keuze voor voorspelbaarheid en kosten-efficiëntie moet worden vervangen door een keuze voor waardecreatie en responsiviteit. Dit moet het leidende beginsel worden in het organiseren van werkzaamheden[1]. Narayan (2015) gaat hier uitvoerig op in. Ik noem enkele consequenties.

1.      Teams kunnen en willen outcome produceren

Een eerste belemmering in het snel reageren op veranderingen is het aantal overdrachtsmomenten van team naar team. Een manier om deze belemmering weg te nemen is het wijzigen van de teamsamenstelling. Een vast, multidisciplinair team kan onafhankelijk van andere organisatieonderdelen klantwaarde creëren. Een tweede belemmering is onduidelijkheid over wie waarover besluiten mag nemen – bevoegdheden. Het mandaat moet duidelijke en voldoende ruim zijn. Je wilt niet jan en allemaal moeten betrekken bij iedere keuze. Een derde punt, dat hiermee samenhangt, is wie kan worden aangesproken op de waardcreatie – verantwoordelijkheden. Door dit bij een vertegenwoordiging van het team te leggen creëer je eigenaarschap voor de dingen die ertoe doen.

2.      Budgetteren voor capabilities

Het op voorhand kunnen aangeven wat de opbrengsten van een project zullen zijn is een hele tak van sport geworden. De financiële afdeling heeft business cases nodig, anders kunnen er geen besluiten worden genomen over de toekenning van schaarse middelen. We weten al decennia dat het schier onmogelijk is om business cases te maken voor softwareontwikkeling, maar dat heeft ons er niet van weerhouden om het te blijven proberen. Hoe zou het zijn als we zouden kiezen voor een vast budget – we weten immers wat een team gedurende een jaar kost – en de belangrijkste dingen gaan doen? Als we goed luisteren kan onze klant ons vast wel vertellen wat hij het meest waardeert.

3.      Competenties in de diepte en de breedte

Een deel van onze mogelijkheden om te reageren of anticiperen op ontwikkelingen ontlenen we aan onze competenties. Het is goed om specialisten te hebben, maar het zou nog mooier zijn als deze specialisten over een tweede of zelfs derde competentie beschikken die zij kunnen inzetten op het moment dat dit nodig is. Zij hoeven hier niet in te excelleren; goed is goed genoeg. Responsiviteit is gebaat bij T-shaped profielen. Dat wil zeggen, als zij fulltime beschikbaar zijn. De noodzaak tot team-hoppen – een maatregel die vaak voortkomt uit kostenoverwegingen – leidt tot context wisselingen die voortdurend herstel vragen.

Het transformeren van een traditioneel georiënteerde organisatie in een meer wendbare organisatie vraagt om een systemische aanpak. Dat is nogal wat. Het begint met een wisseling van paradigma. Van voorspelbaarheid en kosten efficiëntie als leidende principes naar waardecreatie en responsiviteit. Als dit goed wordt begrepen door het senior management volgt de organisatie-inrichting hier logisch uit. Dit is niet eenvoudig, maar het kan wel. En laat dit niet doen door een groepje hobbyisten maar integreer het in de bestaande overlegstructuur waardoor je toegang krijgt tot het intellectuele kapitaal van de gehele organisatie. Onderschat dit niet. Je hebt meer in huis dan je denkt. Verander de dagmerrie in een droom, en verwezenlijk de droom in je nieuwe werkelijkheid.

[1] Gebaseerd op Agile IT Organization Design van Sriram Narayan (2015)

De Definition of Done is een essentieel onderdeel van scrum. Ieder zichzelf respecterend scrum team heeft er een, maar er zijn maar weinig scrum teams die de Definition of Done ook echt serieus nemen. Meestal is het een wassen neus, een document voor de bühne of in het beste geval een checklist waar je best van mag afwijken als je maar een beetje een plausibele uitleg hebt.

Een limiet is er om je er aan te houden

In de Definition of Done staan de kwaliteitscriteria waar ieder opgeleverd product aan moet voldoen. Het is voor het scrum team de meetlat die bepaalt of je iets af hebt of nog niet. Deze meetlat is zo strikt dat als je er niet aan voldoet, je het betreffende item niet mag opleveren. Formeel mag je het resultaat niet eens laten zien tijdens de sprint review meeting. Dat vinden de meeste teams wel heel erg spannend en daarom wordt de Definition of Done lekker vaag gehouden, zodat je er in de meeste gevallen wel mee weg komt als de kwaliteit even wat minder is.

Wat telt is het resultaat, niet jouw inzet

Een paar maanden geleden schreef ik een blog waarin ik ervoor pleitte om procesafspraken uit de Definition of Done te halen. Van die lekker vage afspraken, dat er een peer review moet plaats vinden of dat alle testen moeten zijn uitgevoerd. Het zijn afspraken waar je alle kanten mee op kan en die je met een beetje verhaal altijd kunt afvinken. Ze zeggen echter niets concreets over de geleverde kwaliteit en daardoor geven ze ook geen enkel aanknopingspunt om te verbeteren. Dat komt omdat ze gaan over inzet en niet over resultaat, maar ook omdat ze vaak niet SMART(Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden) zijn geformuleerd.

De Olympische limiet ligt wel heel erg hoog

Als je de stap gemaakt hebt om procesafspraken uit je Definition of Done te schrappen en het is gelukt om de vaagheid eruit te krijgen, dan is er nog het gevaar van de Olympische lat. President Xi van China heeft in Peking de Olympische winterspelen geopend en de komende weken kan de hele wereld weer genieten van sporters die het beste willen laten zien van wat ze in huis hebben. Het motto van de olympische spelen is citius altius fortius en dit sneller, hoger, sterker moet de deelnemers motiveren om iedere keer weer een beetje beter te presteren. Het gaat in de topsport echter al lang niet meer om alleen maar het meedoen. Er moeten medailles gewonnen worden en het liefst een paar meer dan 4 jaar geleden. Als je mee wilt doen dan zul je moeten voldoen aan de Olympische limiet. Haal je die niet, dan doe je niet mee.

Voor veel teams wordt een kwaliteitslimiet in de Definition of Done opgesteld die op het allerhoogste Olympische niveau ligt. Een limiet waar normale stervelingen onmogelijk aan kunnen voldoen. Het is meer een Definition of Perfect. Er zijn naast de afnemers van het product namelijk nog veel meer partijen die belang hebben bij een hoge kwaliteit. Ze stellen eisen aan beveiliging, bruikbaarheid, beschikbaarheid of andere niet-functionele kenmerken. De lat wordt vaak nog een beetje hoger gelegd vanwege imago en reputatie. Eisen die vaak worden gesteld door management, ondersteunende afdelingen of de maatschappij. Denk bij het laatste bijvoorbeeld aan wet- en regelgeving. Alle eisen worden vaak met de beste bedoelingen opgesteld en aan de Definition of Done toegevoegd. En zo wordt de stapel eisen waar een team aan moet voldoen steeds maar hoger en hoger. En uiteindelijk ligt de limiet zo hoog dat alleen de allerbesten er nog aan kunnen voldoen. En dan nog alleen als de omstandigheden perfect zijn en de druk niet al te hoog is.

Nog veel belangrijker dan kwaliteit is vaak de druk op de hoeveelheid die opgeleverd moet worden. Veel organisaties verwachten van hun teams dat ze steeds een beetje beter worden en dat zich dat vertaalt in nog meer opgeleverde functionaliteit. Natuurlijk is er niets mis met beter worden waardoor je met dezelfde inspanning meer waarde kunt leveren. In de praktijk is de druk om meer te leveren echter vaak groter dan wat de teams aan kunnen en wordt de prijs betaald door consessies te doen aan de kwaliteit of, erger nog, wordt roofbouw gepleegd op de medewerkers. Teams vinden allerlei manieren om niet aan deze enorme berg eisen te hoeven voldoen. Dat gaat van negeren, de schuld afschuiven en wegredeneren tot aan verdoezelen, creatief omgaan met de regels en manipuleren aan toe. De hele trukendoos wordt open getrokken.

Iedereen wil meebeslissen

De oorzaak dat er teveel aan wishful thinking wordt gedaan, is niet de enige reden dat de Definition of Done niet de plek krijgt die hij verdient. Een andere belangrijke oorzaak is dat de eisen voor de Definition of Done van buitenaf worden opgelegd. Belanghebbenden leveren hun lijstjes in bij het team met de mededeling dat dit de eisen zijn waar ze aan moeten voldoen. Vervolgens verwachten ze dat het team wel even regelt dat ze er aan zullen voldoen. Ze houden er geen rekening mee dat iedere toevoeging of wijziging aan de Definition of Done impact heeft voor het team. Het levert extra werk op in de vorm van controles, rework of extra functionaliteit. Teams zouden dit niet zomaar mogen accepteren. Het extern opleggen van allerlei dwingende eisen aan het team is een aantasting van hun autonomie met als gevolg dat het team zich geen eigenaar voelt. Het is dan ook volstrekt logisch dat ze zichzelf daartegen beschermen door de rol van de Definition of Done te minimaliseren.

Handige tips voor een praktisch toepasbare Definition of Done

Om een goede start te maken zouden teams eerst moeten inventariseren wat het concrete huidige kwaliteitsniveau is. Leg dit niveau vast in de Definition of Done. Als meerdere teams aan hetzelfde product werken dan geldt het niveau van het minst presterende team. Dat is namelijk het niveau dat je als klant of belanghebbende minimaal mag verwachten en dat zal ongetwijfeld lager zijn dan wat de meesten ervan verwachten. Dit is een realistische start, want de teams hebben immers aangetoond dat ze dit kunnen halen. Van daaruit leggen de teams in gezamenlijk overleg de lat iedere keer een beetje hoger. De retrospective is de belangrijkste meeting die hiervoor wordt gebruikt, maar gebruik ook de sprint review meeting om de wensen en verwachtingen van belanghebbenden te achterhalen en met ze te bespreken. Iedere keer als je de lat een beetje hoger legt kun je bedenken wat de consequenties voor het team zijn, maar het is ook vooral een kwestie van gewoon doen. Ga iedere sprint een nieuw experimentje aan. Als het een keer niet lukt dan is dat niet erg. Je kunt immers altijd terugvallen op de vorige versie.

Zorg dat je de regie houdt en als je dit lang genoeg vol houdt kom je vanzelf weer op dat olympische niveau terecht, maar dan weet je ook zeker dat je het waar kunt maken.

Alles draait om efficiëntie

We schrijven 1911. Frederick Taylor publiceert zijn baanbrekende werk ‘The Principles of Scientific Management’ dat de komende honderd jaar het management denken zal beheersen. Stel je eens voor dat je in die tijd met hem in gesprek had kunnen gaan over een Agile transitie. Hoe zou dat gesprek er dan uit gezien hebben?

Taylor zou gezegd kunnen hebben dat een Agile transitie een complex proces is, maar dat je toch een aantal onderdelen kunt onderscheiden die altijd aandacht vragen. Het is een mindset en hij zal je dat aan de hand van zijn 4 principes toelichten. Zijn 4 principes zijn universeel en bedoeld om 3 dingen aan te tonen:

• het is cruciaal om verspilling te elimineren;
• de oplossing hiervoor ligt in systematisch management en niet in het vinden van de ideale medewerker;
• de basis hiervoor ligt in de wetenschap, gebaseerd op duidelijk gedefinieerde wetten, regels en principes.

Uitgangspunt is dat dit alles gericht is op het maximaliseren van voorspoed voor zowel de werknemer als de werkgever. Deze twee zijn niet tegengesteld aan elkaar, omdat voor beiden geldt dat maximale voorspoed in zijn ogen gelijk is aan maximale productiviteit. Dat was in zijn tijd een vernieuwend inzicht, omdat veel arbeiders en vakbonden de overtuiging hadden dat door het vergroten van efficiëntie banen op de tocht kwamen te staan. Werk dus vooral niet te hard, want dan zijn er minder mensen nodig en worden er collega’s ontslagen. Medewerkers hoeven volgens Taylor echter niet te vrezen voor hun baan als ze efficiënter worden, omdat daardoor producten goedkoper worden en dat leidt weer tot een groei van de vraag waardoor je juist meer mensen nodig hebt. Win win dus.

Hoe kun je zijn vier principes vertalen naar een Agile organisatie?

1. Analyseer werkprocessen

Bedenk voor iedere stap in het proces wat de beste methode is om deze uit te voeren. Bepaal wie de klant is en hoe zijn processen eruit zien. Een beproefde methode is het definiëren van waardestromen. Bepaal vervolgens wat de beste manier is om scrum teams hieraan te koppelen, zodat ze hun ​​taak zo efficient mogelijk kunnen uitvoeren. Je kunt nog met andere methoden zoals Kanban experimenteren om erachter te komen met welke methode het team het snelste is en de beste kwaliteit levert. Je kunt met één team starten en later andere teams toevoegen, zodat zij gebruik kunnen maken van de ervaringen en lessen van het eerste team.

Nog een tip van Frederick: standaardiseer onderdelen voor een efficiënte samenwerking, zoals programmeerstandaarden, het sprint ritme, architectuur uitgangspunten, de administratie in Jira etc, waarbij medewerkers zo goed mogelijk worden bijgeschoold om deze standaarden te kunnen opvolgen.

2. Het juiste team voor de juiste taak

Veel organisaties zijn te complex om alles door één team te laten doen. Definieer daarom onderdelen die ondersteunend zijn voor het team of die onafhankelijk van het team kunnen worden uitgevoerd en breng dit onder in aparte teams, zoals bijvoorbeeld de infrastructuur, financiën, opleidingen etc. Op deze manier reduceer je de complexiteit, houdt het team focus en kunnen ze zich op hun vakgebied specialiseren. Zorg daarom ook voor gerichte opleiding, training en coaching. Kan het werk niet door één team gedaan worden, creëer dan meerdere scrum teams die iedere voor hun eigen afgebakende stuk verantwoordelijk zijn. Deel het proces in kleine stukjes op, zodat ieder team focus kan houden. Door deze focus en omdat een team langere tijd bij elkaar blijft kan het een zeer efficiënt high performing team worden.

3. Gebruik de vaardigheden van medewerkers en vier successen

Streef er bij de teamindeling naar om de vaardigheden van werknemers te erkennen en ze werk te laten doen dat het beste bij hun ambities past, zodat ze zo productief mogelijk kunnen zijn. Vier successen met teams als ze resultaten consequent halen of overtreffen of als ze substantiële verbeteringen hebben doorgevoerd. Een extra beloning voor de beste teams is een mooie erkenning van hun prestaties. Evalueer de werkwijze, de gebruikte methodes en de resultaten op een wetenschappelijke manier en geef constructieve feedback voor verbeteringen.

4. Breng een professionele organisatiestructuur tot stand

Door ervoor te zorgen dat elk team begrijpt wat er van hen wordt verwacht kun je duidelijke afspraken maken over de benodigde communicatie. Als je bijvoorbeeld met epics en features werkt die door meerdere teams worden uitgevoerd, dan kun je de teams vragen bij te houden hoe het er voor staat met risico’s en voortgang, zodat de opdrachtgever (bijvoorbeeld een business owner) altijd op de hoogte is van de status. Product owners en managers kunnen terugkoppeling geven aan de strategische laag binnen het bedrijf om te kijken wat de voortgang is op de strategische doelen. De primaire rol van managers is tweeledig. Ze zorgen ervoor dat er duidelijk kaders en richtlijnen zijn en ze besteden aandacht aan de professionele ontwikkeling van werknemers. Ze monitoren de voortgang, geven terugkoppeling voor verbeteringen en ze zorgen dat men leert door te experimenteren.

Klinkt je dit allemaal best wel bekend in de oren en vind je het een logisch verhaal? Heb ik je in de war gebracht of voel je lichte irritatie of verbazing opkomen? Ik heet je in ieder geval van harte welkom in het 1911 van Frederick Winslow Taylor.

De Agile mindset

Ik ben voor deze mindfuck wel zo vrij geweest om hier en daar wat modern woordgebruik te kiezen. Natuurlijk kende men in die tijd de Agile, Scrum en Lean terminologie nog niet en ook de 4 principes formuleerde Taylor net even iets anders, maar ik heb de essentie niet veranderd. Die essentie, dat is de mindset waar we het altijd over hebben. Zo heb ik hiërarchie vervangen door structuur, talenten door ambities, rapporteren door terugkoppeling en individuen door teams, maar wordt het verhaal daardoor nou echt zo anders? Ik denk eerlijk gezegd dat hij het niet met me eens zou zijn om op team niveau te kijken, maar de andere wijzigingen zijn niet heel ingrijpend.

Wat maakt agile dan zo revolutionair anders? Het gedachtengoed van Taylor wordt volop bekritiseerd, maar moeten we ons er niet eens wat beter in verdiepen? In mijn volgende blog zal ik daar dieper op ingaan, maar ondertussen ben ik wel heel benieuwd naar jullie mening, inzichten en ideeën. Want wat is nou eigenlijk die agile mindset waar we allemaal zo vol van zijn en waarom is deze toch echt heel anders dan de mindset van Taylor?