Wat is agile coaching?

Agile coaching begeleidt jouw team van projectmanagers bij het kiezen van de meest geschikte agile software ontwikkelingsmethodiek.

Agile coaching gaat heel breed. Men onderscheidt in de literatuur substantiële verschillen tussen agile coaching en agile consulting. Men onderscheidt eveneens het verschil tussen het coachen van een groep, van een bedrijf en het coachen one-on-one.

Consulting is het toepassen van de specifieke agile methodiek. Bijvoorbeeld het op punt zetten van de product backlog. Dat zet het team een stap vooruit, en op die manier ziet het team ook hoe het moet, en kunnen ze het nadien dan zelf doen.

Coaching is meer het begeleiden van het team in de agile methodiek, bijv: waar gaat scrum juist over, wat zijn de achterliggende ideëen, waarom zijn de resultaten niet wat we verwacht hadden?

Voor ons is het niet zo belangrijk het theoretische onderscheid te maken tussen consulting en coaching. Op de vloer moet worden uitgemaakt wat op dat moment nodig is.

Dit was het horizontale aspect van agile coaching.

Coaching

Er is ook een verticaal aspect. Coaching gaat immers van one-on-one, bijvoorbeeld het begeleiden van een scrum master in zijn servant-leadership rol, het precies definiëren van de taken van een release train engineer in SAFe, of nog het duidelijk maken van het belang aan een DevOps-engineer waarom continuous deployment zo belangrijk kan zijn en dat de voordelen opwegen tegenover de nadelen, over het coachen van het team door de departementen Development en Operations te integreren in één geheel, tot het coachen van de hele onderneming: de verschillende development afdelingen moeten geïntegreerd worden en misschien dat ook de boekhoudingafdeling baat kan hebben bij een paar DevOps technieken of het onderhoud in sprints kan worden georganiseerd.

HET AGILE LANDSCHAP

Het agile landschap

Het agile framework bestaat uit een waaier van technieken die en sterke evolutie heeft doorgemaakt over de jaren heen, zoals Scrum of Kanban.

Er bestaat zoiets als het Agile Manifesto. Dat is een charter, opgesteld en ondertekend door een aantal belangrijke corifeëen binnen de ontwikkelmethoden, zoals Ken Schwaber van Scrum.

Het charter is redelijk kort en bevat een aantal principes waar een agile methodiek aan moet beantwoorden. Verder staat het iedere methodiek vrij om uit te vinden wat ze willen, als die principes maar worden onderschreven.

Vanuit die optiek, bijvoorbeeld, is het bekende Lean geen agile methodiek. Lean wordt wel vaak opgenomen bij bestaande wèl agile zijnde methodieken, zoals Lean Six Sigma.

Niet iedere agile methodiek behandelt overigens dezelfde problematiek. Het zuivere software bouwen wordt behandeld door Scrum en XP, alsook in partiële mate door Kanban. Maar DevOps kijkt meer naar het deployen van de software, en Nexus of LeSS kijken naar hoe je verschillende ontwikkelteams kan combineren en interageren met mekaar.

De agile wereld is ook niet op één dag ontstaan, maar constant in beweging en ontwikkeling. Dertig jaar terug was men erg blij met Scrum. Nu scrum hoge populariteit geniet, en een ontwikkelteam door scrum is gelimiteerd tot 9 mensen, ontstaat dan meteen de vraag hoe het dan moet met verschillende projecten, of een project dat te groot is? Daardoor zijn dan Nexus, Less en SAFe ontstaan. Scrum zegt zeer weinig over deployment.

Volgens scrum gebeurt dat gewoon. Dat lijkt in de praktijk anders te lopen, en dus zijn DevOps en DAD gegroeid, alsook Safe die met hun release train concept ook hard hebben nagedacht over deployment.

De constante evolutie zien we ook bij DAD – disciplined agile Delivery- dat een methodiek voorstelt hoe goed te kiezen uit de andere technieken, maar tevens een onderdeel vormt van DAF – Disciplined Agile Framework. Dit framework heeft ook ambities op interproject (portfolio) en enterprise niveau, maar die modules moeten nog uitontwikkeld worden.

Het voorbeeld van DAD brengt ons naadloos op een ander aspect van agile, de meeste methodieken zijn van mekaar op de hoogte. DevOps, bijvoorbeeld, verwijst naar Scrum en Kanban. “Voor het gedeelte ontwikkeling gebruikt U naar believen Scrum of Kanban. En dan gaan we nu over naar het gedeelte operations…” waar nog een boek lang zal worden over uitgeweid.

Andere technieken zijn minder populair of al wat verouderd, zoals DSDM, Agile methods, Crystal en UP. Maar kunnen nog steeds een meerwaarde hebben in sommige situaties.

Mijn persoonlijke toets

Bij heel dat agile geweld, wil ik graag toch een aantal kanttekeningen plaatsen. Men vergeet soms nog te programmeren. Gezien het bouwen van software niet tot het onderwerp behoort van de agile techniek, maar wel het beheer van de softwarebouw, wordt het bouwen van de software een beetje stiefmoederlijk behandeld. Het bouwen van software is niet van de poes, kan behoorlijk wat moeilijkheden inhouden, en vraagt tijd.

Door de jaren heen wordt software ook almaar complexer. We denken nu in three-tier tot 7-tier, we hebben nu clients in de vorm van smartphones op Android, Tablets, en dedicated professionele apparatuur zoals barcodelezers.

Ook servers worden almaar complexer. Wat je vandaag allemaal met een Oracle server kan doen, staat niet in verhouding met de database server van 15 jaar terug. Men lijkt dat te vergeten, in de verschillende agile methoden.

Vroeger was het deployen ook eenvoudig. De programmeur kopieerde regelrecht van zijn ontwikkelcomputer de software op het productieplatform. Ik herinner mij nog discussies in 2009 met ingehuurde professionals die het tijdverlies vonden dat ze moesten ontwikkelen op een ontwikkelplatform, waarna het de testomgeving inging, om dan een maand later op het productieplatform te belanden. Rechtstreeks in productie ontwikkelen was veel makkelijker.

Gelukkig zijn ontwikkelstraten nu mainstream geworden. Als je scrum wil toepassen, dan mag je maximaal sprints van een maand organiseren, en die sprint moet dan een “potentially releasable increment of product” opleveren: volledig afgewerkte functionaliteit die volledig doorgetest is tot op productiekwaliteit. En dat dan allemaal op een paar weken tijd. Vanuit het concept van scrum, is dat aanvaardbaar, maar vanuit de praktijk, eigenlijk niet. En het is jammer dat scrum daar weinig lijkt aan te doen.

Agile coaching is vakwerk en moet op maat worden toegepast.

En dat brengt me dan naadloos op een ander aspect van agile methoden. Ik zie op heel wat fora managers worstelen met de implementatie van agile technieken. Ze zijn bereid om hun process om te gooien, en allerhande kunstgrepen uit te proberen om toch maar binnen het concept van bijvoorbeeld scrum te blijven.

Het concept van scrum is dat iedereen die je nodig hebt voor de ontwikkeling van de code in een ontwikkelteam hebt verzameld. Op die manier kan dat ontwikkelteam ongestoord ontwikkelen, en als er hindernissen zijn, dan dient de scrummaster die hindernissen te overbruggen.

De klassieker is als er moet geïnterfaced worden met andere legacy software. Die legacy software wordt beheerd door een ander team, vaak van niet eens dezelfde firma.

Wendel Van Hespen – Zaakvoerder

Men zegt dan om in zo’n geval het team van de legacy software lid te laten worden van het ontwikkelteam. Tja, dat is mooi als dat kan, maar juridisch houdt het geen steek, en meestal organisatorisch ook niet. Als dat legacy team geen zin heeft om zich te houden aan de deadlines van jouw sprints, geen zin heeft in stand-up meetings, en geen zin heeft om zich 2000 km te verplaatsen voor jouw feedback meeting, wat doe je daar dan aan?

Welnu, bedrijven zijn geen universiteiten. Er wordt geen geld verdiend met de mooiste of beste implementatie van scrum. De implementatie is niet belangrijker dan het eindresultaat. Het beheermodel staat ter beschikking, en niet omgekeerd. Als de implementatie van scrum niet helpt, maar eerder tegenwerkt, dan moet er gezocht worden naar een andere methode, die wel helpt. Hoewel een doorlichting van het ontwikkel process altijd interessant is. Als een onwikkelmethode niet helpt, kan dat er ook op wijzen dat het ontwikkelprocess niet goed is gestreamlined.

Filosofie, methode en framework

Agile coaching helpt een onderscheid te maken tussen filosofieën en methodologieën, om zo een specifiek agile framework toe te passen bij het implementeren van agile software ontwikkeling technieken.

Nog een klein woordje over de termen filosofie, methode en raamwerk (framework). In bovenstaande tekst gebruik ik termen als agile methoden, agile technieken, enz. door mekaar. Daarmee doe ik iedere techniek apart oneer aan.

Scrum, bijvoorbeeld, is een raamwerk, en geen methode. Het biedt een kader aan waarbinnen kan gewerkt worden, wat dan uiteindelijk zal leiden tot een concrete methode binnen dat ontwikkelteam, maar een ander ontwikkelteam kan een andere methode hebben uitgewerkt, en toch perfect resideren binnen het scrum-raamwerk.

DevOps

DevOps, of Lean, is meer een filosofie. Ze reiken ideeën aan, maar hoe je die dan implementeert, dat zeggen ze niet. Er is dan wel een hele reeks aan bedrijven die methoden hebben gezocht en gevonden om tot een implementatie van die ideeën te komen, en veel andere bedrijven volgen die dan ook, maar aan de basis is het sturende en dus het theoretische deel een filosofie.

Kanban is dan weer een filosofie èn een methode. Met hun kaartensysteem, hun Kanban bord en hun wiskundige berekenigsmethoden om tot een gelimiteerde WIP (Work in Progress) te komen, bieden ze wel degelijk een methode aan. Ook al kan je ervoor kiezen om het kanbanbord te implementeren als een whiteboard aan de muur, een krijtbord, een houten bord met post-its of een website op de computer, de verschijningsvorm is verschillend, de werking ervan niet en best goed omlijnd. Nochtans is heel dat system gebaseerd op een filosofie vanuit het Toyota productiesysteem.

Als we iedere agile methodiek apart bespreken, dan respecteren we de eigenheid van de methodiek. Maar als we verwijzen naar de agile methodieken als groep, dan is dat erg onpraktisch en dus permitteren we ons een beetje oneerbiedig misschien het gebruik van termen als methodieken of technieken.

DELICAAT OF HET BELANG VAN HET JUISTE TOEPASSEN

Delicaat of het belang van het juiste toepassen.

Scrum stelt duidelijk dat het niet is toegestaan om bepaalde modaliteiten van scrum aan te passen of te veranderen aan hun scrum framework.

Dat leidt in de praktijk vaak tot het toevoegen van story points en poker planning aan scrum. Maar deze onderdelen zijn niet scrum, en werden ontwikkeld voor XP. Velen weten dat niet, en het lijkt of dat storypoints altijd deel uitmaken van scrum. Dit is echter niet het geval, je zou ook kunnen werken bijvoorbeeld met “Ideal days”, zoals de directeur van Mountaingoat software Mike Cohn het voorstelt.

Men zegt dat als scrum niet goed wordt toegepast, dan garandeert scrum niet de heilzame werking van scrum. Na de studie van de “Scrum Guide”, ben je daar nog niet zo van overtuigd, maar na het lezen van een boek als “Software in 30 dagen” van oprichter Ken Schwaber komt dat begrip wèl. En daar valt wat voor te zeggen want scrum bestaat al tientallen jaren en is daardoor door de wol geverfd geraakt. Men mag wel wat respect opbrengen voor de carrière die scrum heeft doorgemaakt en de populariteit die het vandaag geniet.

En dat brengt me tot het predicaat “delicaat” in verband met agile. Het juiste toepassen is van groot belang, en zal anders inderdaad geen of minder succes oogsten. Dat juiste toepassen luistert nogal nauw. Sommige dingen zijn minder belangrijk dan andere, maar omdat dat niet altijd eenvoudig valt uit te maken, is het inderdaad geen slecht advies om te zeggen, “blijft ervan af”. Pas het juist toe, en de resultaten zullen zeker komen.

Dat geldt voor scrum, maar minstens evengoed voor alle andere agile technieken.

implementation

Een goede omkadering met uitleg, doet vaak wonderen om het stringente karakter van zo’n methode begrijpbaar en draaglijker te maken, waardoor de garantie op ondersteuning veel groter wordt.