Digitale Agile Tooling – Collaboratie

Jouw team bestaat uit een stel slimme mensen die meer dan in staat moeten zijn om met behulp van Scrum keer op keer een product succesvol live te zetten. Wat zie je daarentegen steeds gebeuren: oplevering vertraagt, lanceren gaat fout, tijd raakt verloren door uitzoekwerk bij incidenten, kennishouders vallen weg waardoor er nog meer vertraging plaatsvindt. Sounds familiar? Dit zijn symptomen van geen of foutief gebruik van Collaboratie tools. Doordat teams niet in staat zijn om inzichten tijdig te delen en vast te leggen, kunnen ze de spreekwoordelijke ezel, die zich geen tweemaal stoot aan dezelfde steen, het flink laten afzien. Teams gaan namelijk keer op keer dezelfde fouten maken. Wil je hier een stokje voor steken? Lees even door om het daadwerkelijke probleem te begrijpen en concrete handvatten te krijgen om dit op te lossen.

Documentatie binnen Agile?

Je vraagt je vast af wat voor wondermiddel dan dit soort symptomen aanpakt? Je hebt het misschien niet door, maar vaak heb je dergelijke tooling al in huis: Sharepoint, Microsoft Teams, OneNote, JIRA Confluence en Skype Whiteboards zijn maar enkele voorbeelden van tooling waarin je inzichten kan vastleggen en delen in de vorm van documentatie. Nu is documentatie vaak een eng woord binnen Agile organisaties. “Working Software over Comprehensive Documentation”, toch? Voordat we verder gaan wil ik verduidelijken dat onderaan het Agile Manifesto nog een zin staat:

“That is, while there is value in the items on
the right, we value the items on the left more.”

Documentatie is niet verboden binnen Agile. Maar, vrij vertaald, moet het altijd ondersteunend zijn aan de items aan de linkerkant, in plaats van de bovenhand voeren. Documentatie is dus prima, maar in veel gevallen is het ook overbodig.

Collaboratie tools moeten een team helpen om de volgende drie soorten documentatie vast te leggen die wél vaak nodig zijn:

  • Ontwikkelstandaarden
  • Borging voor toekomstige audits
  • Kennisdeling

Hoe pak ik dan de problemen aan?

Er bestaan verschillende soorten tooling voor verschillende problemen en daarom wil je niet de verkeerde keuze maken.

Wat je ziet gebeuren bij distributed teams, flexwerkplek teams of thuiswerk teams is dat er meer documentatie moet worden vastgelegd dan fysiek samenwerkende teams. In beide gevallen kan digitale Agile tooling helpen om de samenwerking effectiever te maken, maar het is goed om te begrijpen dat de context waarin de teams samenwerken ook invloed moet hebben op de intensiviteit waarmee zij tooling gebruiken. Makkelijker gezegd en een stelregel: een team dat fysiek samen zit heeft minder digitale Agile tooling nodig dan een team dat vanaf meerdere locaties samenwerkt.

Ontwikkelstandaarden

Een team dat producten ontwikkelt moet waarborgen dat deze ontwikkeling zich aan bepaalde kwaliteitsstandaarden keer op keer voldoet, bij elke oplevering. Wat gebeurt er als we niet goed testen, of shortcuts nemen? Dan krijg je fouten en dat willen we met kwaliteitsstandaarden voorkomen. Binnen Scrum is dit de Definition of Done, maar de kern hiervan is dat we kwaliteit borgen. Tooling die daarbij kan helpen is tooling waarin je dergelijke standaarden transparant, begrijpelijk en beschikbaar voor iedereen hebt staan en bij voorkeur zelfs kan inbouwen. Daarbij helpt het ontzettend om tooling te hebben die ook al eens synergy heeft met jouw ontwikkelomgeving. Of in het beste geval zelfs dezelfde tooling is! Een mooi voorbeeld hiervan is Azure DevOps, waarbij Microsoft teams de mogelijkheid biedt om zowel hun ontwikkelstraat als hun Agile planning en proces in één tool borgt.

Een goede check die je kan doen om te bepalen of een tool de juiste keuze is om de volgende vragen te beantwoorden:

  • “Hoe kan het team nu bij haar kwaliteitsstandaarden?”
  • “Hoe kunnen stakeholders deze standaarden inzien?”
  • “Hoe kunnen teamleden deze standaarden beïnvloeden?”
  • “Hoe kunnen stakeholders deze standaarden beïnvloeden?”

Als deze vragen allemaal een simpel en duidelijk antwoord krijgen dan zal de tool een bijdrage kunnen leveren aan ontwikkelstandaarden, zo niet, dan wil je misschien wel nadenken over hier afspraken over maken, of een tool te implementeren die dit versimpelt.

Borging voor toekomstige audits

Vaak zijn logging en documentatie wat betreft configuratie voor audits met name in de IT de belangrijkste deliverables. Inzicht in wie, wanneer, wat heeft gedaan in een systeem. Vanwege de zelforganiserende eigenschappen van Agile teams kan je als organisatie de valkuil instappen door elk team zelf te laten sturen op hoe ze deze gegevens vastleggen en aanleveren. Dat kan betekenen dat audits nogal eens een lang en zwaar proces wordt door de grote hoeveelheid uitzoekwerk. Dit kan je met de juiste digitale Agile tooling standaardiseren en automatiseren. Tooling van Atlassian als JIRA Confluence, en tooling van Microsoft als Sharepoint Online en OneDrive for Business hebben meer beheer mogelijkheden dan bijvoorbeeld een Microsoft Teams Wiki pagina of een gedeelde OneNote pagina.

Als audits op documentatie een pijnlijk onderwerp is binnen jouw teams dan kan je overwegen om bijvoorbeeld een Sharepoint Online oplossing aan te bieden voor documentatie voor de teams. Door beheer op dit soort diensten met duidelijke kaders te implementeren haal je een hoop overhead weg bij dit soort teams en maak je het de auditors makkelijker. Het keyword is hierbij wel “kaders”. Zelforganiserende teams hebben deze kaders nodig, in tegenstelling tot zelfsturende teams, zodat we wel met eenzelfde visie op documentatie ons werk doen.

De vraag die je beantwoord zou willen hebben is: “wat is de simpelste manier om in het geval van een audit de juiste data te kunnen leveren?” om vanuit dat antwoord de tooling in te richten.

Kennisdeling

Het hele team zit te wachten totdat Harry terug van vakantie is, omdat hij het enige teamlid is dat de juiste rechten en kennis heeft om een cruciaal stuk van het product te bouwen. We hebben keer op keer incidenten en Piet is elke keer de sigaar in het weekend omdat hij de enige kennishouder is op dit stuk van ons systeem. Tijdens het werk is 90% van de taken voor Sara, omdat zij degene is die het systeem heeft gebouwd. Dit zijn situaties waar veel teams zich in bevinden en ondanks veel pogingen tot oplossen van deze bottlenecks blijven ze bestaan. Zelfs als dure seniors worden ingehuurd lukt het ze maar niet om de “tweede Sara” te worden zoals het ooit is bedacht toen er een vacature is uitgezet. De pijn zit hem niet in de onwil van mensen, of hun technische capaciteit, maar juist in de informatiebeschikbaarheid die nodig is om voldoende van de onbekende systemen en processen te weten zodat ze effectief ermee kunnen werken.

Dit probleem komt vaker voor bij gedistribueerde teams omdat kennisdeling hier nog minder intuïtief gaat dan fysiek. Practices als pair programming en peer reviews, waarbij collega’s samen het werk doen of nakijken, wordt complexer als het team op afstand moet communiceren met elkaar. Daarom moet het team compenseren op het verminderd voorkomen van directe kennisoverdracht door actief aan het beschikbaar stellen van kennis te doen. Gedistribueerde teams zullen in hun kwaliteitsstandaarden ook een zekere mate van kennisdeling moeten borgen, als ze willen voorkomen dat deze “single points of knowledge” blijven bestaan. Dat houdt vaak concreet in dat teams elke Sprint bestaande documentatie en instructies updaten en toevoegen aan een bestaande kennis repository.

Hier zit wel de grootste valkuil van alle drie de soorten documentatie: Goldplating van documentatie als designdocumenten en instructies. Om dit te voorkomen wil je teams hier juist de vrijheid in geven om zelf te bepalen wat “just enough” documentatie is voor kennisoverdracht binnen het team en focussen op het oplossen van ongewenste situaties waarin ze op dit moment kritische kennishouders zien. Tooling die daarbij helpt geeft het team ruimte om dit zelf in te delen. JIRA Confluence en  Microsoft Teams Wiki hebben een open structuur om zelf kennis vast te leggen in een Wikipedia achtig format. Anderzijds gebruiken teams OneNote om meer in eigen structuur documentatie vast te kunnen leggen. De keuze hiervoor ligt hem in hoeverre mate de structuur van kennisvastlegging belangrijk is voor het team en de organisatie. Is het de bedoeling dat het team ook kennis naar buiten brengt richting andere teams? Dan helpt een meer gestandaardiseerde aanpak via Confluence of Teams Wiki wellicht beter.

Conclusie

Zoals je kan lezen, ligt de keuze niet altijd voor de hand, maar afhankelijk van jouw situatie en het antwoord op de juiste vragen kan je een grote stap zetten richting de juiste tooling keuze. De keuze hiervoor kan je na het lezen van deze blog wat beter maken door te kijken naar wat voor jou belangrijke elementen zijn in de antwoorden op de vragen en op basis daarvan de juiste tooling te bepalen. Als straks de blogs voor elk kwadrant van het model online staan, zal ik ook frequent reviews van tooling gaan delen met jou om te helpen bij de juiste keuze. Ondertussen kan je ook hieronder in de comments reageren. Heb je namelijk nog vragen of een aanvulling voor het lijstje vragen dat je met het team kan bespreken? Reageer dan hier in de comments waarin ik antwoord zal proberen te geven op jullie vragen of tijdens mijn workshop Digital Agile Tooling. Tijdens deze workshop gaan we een dag lang door alle vier de categorieën. Ik deel mijn concrete ervaringen (positief en negatief) met verscheidene digitale Agile tooling en laat jou ook ervaren wat de voor- en nadelen zijn van tooling door exercises en cases te behandelen! Je zal na de workshop weglopen met een duidelijk beeld wat voor tooling wel en niet gaat werken voor jouw organisatie en een concreet actieplan om een implementatie te doen die jouw teams wél effectiever maakt. Interesse? Je kan je inschrijven via Agile Academy.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*