Regelmaat en orde met duidelijke processen

Regelmaat en orde met duidelijke processen

Wanneer er een chaotische werkomgeving is, is er meestal een gebrek aan duidelijke processen. De grote uitdaging is om dit te herkennen. In de afgelopen jaren heb ik veel teams ontmoet die worstelden met onduidelijkheid en niet wisten hoe ze hiermee om moesten gaan. Deze teams begonnen met het implementeren van frameworks zoals Scrum, of ze begonnen met het stellen van duidelijke doelen met Objectives en Key Results. En er is niets mis met die frameworks, ze lossen alleen de problemen die de teams tegenkomen niet op.

Het echte probleem is meestal dat er geen duidelijk proces is. Hoewel frameworks zoals Scrum wat grenzen stellen, vertellen ze niet hoe het werk gedaan moet worden. En dat is het ontbrekende onderdeel waar de meeste teams mee worstelen.

In deze post vertel ik je over een echte situatie die ik had met een klant. Ik vertel je over hun achtergrond en welke stappen we genomen hebben om het team te helpen groeien en de resultaten te behalen die ze voor ogen hadden. Laten we bij het begin beginnen.

De implementatie van een ticketsysteem

Met een sterke achtergrond in softwareontwikkeling - ik ben daar al meer dan 20 jaar bij betrokken - heb ik een sterke band met die branche opgebouwd. Een softwarebedrijf was net begonnen met het Scrum-framework en liep tegen een probleem aan: als klanten bugs of onverwacht gedrag van de software meldden, duurde het te lang voordat die problemen werden opgelost.

De agile coach stelde een ticketsysteem voor. Klanten hoeven alleen maar een formulier op de website in te vullen en het team krijgt een melding op hun sprint backlog. Dit zorgt ervoor dat het team die bugs direct ziet op het moment dat de klant ze instuurt!

Maar er was geen verbetering voor de klant. Ze moesten nog steeds lang wachten voordat ze antwoord kregen. Ze moesten nog steeds bellen om een statusupdate te krijgen. Eigenlijk maakte het hele ticketsysteem de klantervaring slechter. Minder persoonlijk contact en nog steeds geen antwoorden.

De manager belde me. Hij las een bericht over het SOPHIA Framework en wilde eens zien of dat wel zou helpen. “Ik kan je alles vertellen over wat er is gebeurd, hoe we werken en wat er mis is”, zei hij in het gesprek. “Ik wil dat je me vertelt wat we moeten doen om deze situatie op te lossen.”

Ik legde hem uit dat het oplossen van de situatie alleen mogelijk is door het team zelf. Het ticketsysteem werd geïmplementeerd door het managementteam, maar het ontwikkelteam was er niet bij betrokken. Het resultaat was dat het ontwikkelteam zich niet had aangepast aan het ticketsysteem. Ik stelde voor om een workshop van 2 uur te houden met het ontwikkelteam. “Na die workshop weet ik precies wat het echte probleem is, hoe het opgelost kan worden en misschien heb ik zelfs wat oplossingen in gang gezet.”

De manager was bekend met het concept van workshops en ging akkoord.

Een uur vol verbazing

We verzamelden ons in een van de vergaderruimtes op kantoor. Na een korte check-in vroeg ik het team om me uit te leggen hoe ze werkten. Natuurlijk legden ze het hele Scrum-framework tot in detail uit. Vanaf dat moment wist ik dat de Agile coach fantastisch werk had geleverd. Het hele team wist alles over Scrum wat ze moesten weten.

Ik vroeg ze om het proces op het whiteboard aan de muur te tekenen. Binnen 5 minuten, na wat discussie en gelach, was het plaatje van het Scrum-framework op het whiteboard getekend. Inclusief gebeurtenissen, rollen en artefacten. Scrum.org had dit niet beter kunnen doen.

Ik complimenteerde het team en de Agile coach voor deze geweldige oefening en vroeg het team om een beetje in te zoomen. “Het Scrum-framework is de ideale situatie. Maar wat gebeurt er als een klant een bug vindt of iets wat niet aan de specificatie voldoet? Wat gebeurt er als er iets direct moet worden opgelost?”

Een van de teamleden sprong er meteen in: “We stoppen met werken aan wat we aan het doen zijn en beginnen het op te lossen! Als er brand is, moet je niet wachten om het te blussen!”

Ik vroeg het team om het proces voor de uitzondering op het Scrumproces te tekenen. Op het whiteboard ontstond een behoorlijk vereenvoudiging van het proces:

En ja, ik weet het, dit is echt een vereenvoudiging van een proces. Maar eerlijk gezegd was ik een beetje verbaasd dat ze zover kwamen! Dus ik stelde ze een paar vragen:

  • Wie beslist dat een bug zo belangrijk is dat deze meteen moet worden opgepakt?
  • Wat gebeurt er als die persoon beslist dat het niet zo belangrijk is?
  • Wat gebeurt er met de items die je hebt gecommitteerd voor deze sprint? Wat als je de commitment niet meer kunt waarmaken?
  • Wie is verantwoordelijk voor het updaten van de status naar de klant?
  • Wanneer en met welke frequentie wordt de klant geüpdatet?

Nadat ik deze vragen had gesteld, werd de kamer gevuld met stilte. Niemand lijkt deze antwoorden te kennen. Niemand lijkt te weten wie verantwoordelijk was voor bepaalde acties.

Eén uur oplossingen

In het tweede uur begonnen we met het tekenen van het nieuwe ‘bug-proces’. We begonnen met het vereenvoudigen van de vragen. Bijvoorbeeld: “Wie beslist dat een bug zo belangrijk is dat deze direct moet worden opgepakt?” werd vertaald naar “Is deze bug belangrijk genoeg om direct op te pakken?”. Dit ontkoppelde het proces van de verantwoordelijke personen.

We vonden een paar beslissingspunten in onze processtroom. De laatste stap die we in deze workshop deden, was het definiëren van rollen voor die besluitvormers.

Aan het einde van deze workshop hadden we:

  1. Een duidelijke visualisatie van het ‘Bug-proces’.
  2. Een duidelijke lijst met beslissingspunten.
  3. Een duidelijke lijst met rollen voor verantwoording.

Ik maakte een document van die bevindingen en presenteerde die terug aan de manager. “Er is maar één ding dat we moeten doen”, vertelde ik hem, “geef het team mandaat om die rollen toe te wijzen aan teamleden. En voordat je ja zegt, wil ik duidelijk maken dat dit betekent dat het teamlid, met de toegewezen rol, bevoegd is om de beslissingen te nemen.”

Hij knikte en machtigde me om nog een sessie met het team te doen om de rollen toe te wijzen. Na die sessie was het hele proces, inclusief verantwoording, verantwoordelijkheid en duidelijk.

Het team begon met de implementatie van het proces en na 2 maanden daalde de doorlooptijd van bugs met bijna 20%. Maar nog belangrijker, de klanttevredenheid steeg met meer dan 30%! Daarnaast werd het team productiever. Ze hebben een duidelijk begrip van het werk en het proces. Dat verbetert hun planning en geeft ze meer rust om in alle rust te ontwikkelen aan de software.

Maak het niet te ingewikkeld

Als je wilt beginnen met het schetsen van je eigen processen, kun je natuurlijk naar Google gaan. En ja, eerlijk gezegd is dat een geweldige plek om te beginnen. Maar … dat geeft je ook een overload aan mogelijkheden. Er zijn heel veel symbolen die je kunt gebruiken, verschillende stijlen en verschillende software. Daarom geef ik je de 4 meest voorkomende en waardevolle symbolen om mee te beginnen. Met deze symbolen kun je 95% van alle processen tekenen.

Het ovaal

Het ovale symbool wordt gebruikt om het begin en einde van je proces te tekenen. In dat symbool kun je iets schrijven als “Start Bug Process” en “End Bug Process”. Dit symbool toont de invoer en de uitvoer van het volledige proces.

Het vierkant

Het vierkant symboliseert een taak of activiteit. Goed om te vermelden, deze gaan niet over mensen of tools. Je kunt iets schrijven als “Klant op de hoogte stellen”, maar niet “James stelt de klant op de hoogte” of “Klant op de hoogte stellen door een e-mail te sturen”. Je beschrijft wat er gebeurt, niet hoe of door wie het gebeurt.

De diamant

Een beslissing wordt weergegeven door een diamant symbool. Binnen de diamant schrijf je de vraag die je wilt beantwoorden. In dit geval schreven we “Is deze bug belangrijk genoeg om meteen op te pakken?”. Je gebruikt een van de hoeken van de diamant als invoer, de andere hoeken zijn de antwoorden die je kunt geven. Er is geen maximum, naast dat meer antwoorden meer complexiteit toevoegen. Aan de andere kant is er een minimum van twee antwoorden. Er is ten minste een “ja” en een “nee” als optie.

Het omkaderde vierkant

Het omkaderde vierkant vertegenwoordigt een subproces. Als iemand in de bovenstaande casus besluit dat de bug niet relevant genoeg is om direct op te pikken, kunnen er talloze stappen zijn om met de klant te communiceren. Dat proces is te groot en geeft te veel ruis om op hetzelfde diagram te plaatsen als het “Bug-proces”. In dat geval gebruik je het omkaderde vierkant symbool en schrijf je de naam van het subproces erin.

Zoals ik al zei, maak het niet te ingewikkeld. Begin met deze vier symbolen, een whiteboard en wat whiteboardstiften. Je hoeft niet te investeren in dure software om er een digitale versie van te maken. Je kunt deze symbolen vinden in tools die je waarschijnlijk al hebt, zoals PowerPoint, Google Document of Canva.

Uiteindelijk is het veel belangrijker om het proces en de verantwoordelijkheden te bespreken dan te zoeken naar de beste tools en symbolen om het proces te beschrijven.


Wil je meer leren?

De aanpak die ik in dit artikel beschrijf, gebruik ik zelf vanuit het SOPHIA Framework. Een eenvoudig te begrijpen en te implementeren framework gebaseerd op eenvoud en tools die gewoon werken.

Inmiddels heb ik hier verschillende bedrijven in mogen begeleiden en heb ik de kennis, vaardigheden en ervaring omgezet in een 2-daagse training. Op 5 en 6 maart verzorg ik de eerste live training in Utrecht waarin ik je leer:

  • Hoe je inzicht en grip krijgt op processen.
  • Hoe je de werkdruk van je teams kunt verlagen.
  • Hoe je jouw team betrokkener en meer resultaatgericht maakt.
  • Hoe je de SOPHIA tools en technieken inzet om de operatie soepel te laten verlopen.
  • Hoe je een actieplan opstelt waar je direct mee aan de slag kunt.

Dit is de allereerste keer dat ik deze training ga verzorgen, daarom heb ik een speciale pilotprijs voor deze eerste training. Een mooie kans dus om je 2 dagen te verdiepen in de kracht van SOPHIA en jouw teams te versterken.

Wil je meer weten en inschrijven? Kijk dan snel op: https://deorganisatieveranderaars.nl/grip-op-processen-rust-in-je-hoofd/#cursus-kalender

Geschreven door: Bob Kosse
Gepubliceerd op: January 20, 2025
Leestijd: 9 minuten

Sluit je aan bij de community

Sluit je aan bij een netwerk van ondernemers, hr-professionals en operationeel managers die samenwerken aan groei, werkgeluk en duurzame resultaten. Deel kennis, leer van anderen en zet samen de stap naar een wendbare, efficiënte organisatie. Ontdek vandaag nog onze community op Slack.

Word vandaag nog lid!

Ontdek waar je nu staat

Ieder bedrijf gaat door verschillende fases van groei. Wil jij weten waar je nu staat?
Doe dan onze gratis 0-meting.

Doe de groeiscan