Tips naar aanleiding van (R)evolutie van de ontwikkelingsorganisatie

In de afgelopen jaren heb ik meerdere organisatorische wijzigingen binnen de softwareontwikkelingsbranche gezien en meegemaakt. De verschillende methodes/frameworks die in de organisatie werden toegepast zijn o.a. Waterfall, Scrum, DevOps, Feature teams & Agile scaling. In mijn laatste blog heb ik een kort overzicht van deze methodes/frameworks gegeven. In deze vervolgblog geef ik vijf tips naar aanleiding van mijn ervaring met deze methodes/frameworks. Het belangrijkste is dat je flexibel moet zijn en de methode moet veranderen als dat nodig is.

Ik zal geen advies geven over welke methodes/frameworks het beste voor jouw organisatie zijn. Elke aanpak heeft zijn eigen kenmerken. Maar ondanks de verschillen die er zijn, hebben ze ook overeenkomsten. Mijn tips kunnen op alle methodes/frameworks worden toegepast.

Kijk naar zowel het project als de organisatie

Mijn eerste tip is om de methode of het framework te kiezen dat het beste bij zowel je project als bij je organisatie past. Voor elk project moet je kiezen welke methode of welk framework het beste past. Je kunt bijvoorbeeld de grootte van het project in overweging nemen.

Moet je kleine wijzigingen aanbrengen of een klein systeem bouwen, misschien zelfs zonder integratie, en kan de volledige analyse van tevoren plaatsvinden? In dat geval, kun je nog steeds een waterfall-aanpak toepassen. Het voordeel daarvan is dat je een volledig overzicht van de functionaliteit en de architectuur hebt, voordat je begint met bouwen.

Wanneer het systeem groter of complexer wordt, kun je ervoor kiezen om een van de overige genoemde methodes/frameworks te gebruiken. Het voordeel is dat je kunt inspelen op steeds veranderende behoeften. Deze behoeften kunnen veranderen als gevolg van nieuwe inzichten of regelgeving.

Naast het project moet je ook goed kijken naar de organisatie en vooral naar de volwassenheid van de organisatie. Je kunt bijvoorbeeld kijken of de organisatie al zo ver is om aan continue integratie/inzet te werken, zoals je DevOps teams kunt inzetten.

Afhankelijk van de uitkomst van de analyse van het project en de organisatie, zou je er zelfs voor kunnen kiezen om een combinatie van verschillende methodes/frameworks te gebruiken. Je zou Waterfall en Scrum kunnen combineren, dit wordt ook wel Agifall genoemd.

Flexibel zijn

Wanneer je een methode/framework hebt gekozen voor het organiseren van je project en je ziet dat het niet werkt, moet je niet twijfelen en deze aanpassen aan je behoeften. Zelfs als dat betekent dat je een andere methode of ander framework moet kiezen. Dat brengt me bij mijn tweede tip. Je moet niet alleen flexibel zijn ten opzichte van de functionaliteit waaraan je werkt of gaat werken, maar ook ten opzichte van de manier waarop je werkt en je werk wordt georganiseerd. De genoemde methodes/frameworks staan niet vast en kunnen altijd aan de behoeften van het project en/of de organisatie worden aangepast.

In sommige organisaties moet je echt flexibel zijn als je met een methode werkt, omdat veel wijzigingen op de organisatie én het project worden toegepast. Ik heb gemerkt dat de één beter met dit soort situaties kan omgaan dan de ander. Dus blijf letten op mensen die anders hun betrokkenheid verliezen en geen interesse meer hebben in hun werk. Iedereen kan veranderen, maar sommige mensen hebben meer tijd en/of begeleiding nodig.

Houd de werkeenheden klein

Naar mijn mening hebben mensen de neiging om zich niet meer te focussen wanneer de werkeenheid te groot wordt. Probeer dus mensen kleine werkeenheden te laten doen. In dit geval, kunnen deze werkeenheden user stories of gebruikssituaties zijn. Kleine werkeenheden zijn vooral zinvol wanneer er in sprints wordt gewerkt. Het zorgt ervoor dat het team zich op haar werk kan focussen en de werkeenheden binnen een sprint kan afronden. Dit geeft de voldoening dat de functionaliteit voltooid is en motiveert het team voor de volgende sprint. Het resultaat is dat de productiviteit van het team beter voorspelbaar wordt en de releases betrouwbaarder gepland kunnen worden.

Bedrijfsanalisten werken vooruit

Wanneer er met een agile methode/framework wordt gewerkt, moeten alle teamleden volgens de theorie aan dezelfde werkeenheden werken. Je wilt echter dat alle teamleden aan het begin van een sprint productief zijn. Je wilt niet dat de ontwikkelaars en testers moeten wachten tot de analyse van de werkeenheid is afgerond, voordat ze productief kunnen worden. Dus wil je niet dat ze moeten wachten totdat de wijziging is aangebracht of de test cases/scripts zijn gemaakt. In de praktijk zul je merken dat de bedrijfsanalist meestal vooruit werkt op de rest van het team. Ze analyseren dan de werkeenheden van de volgende sprint of die van daarna. Je wilt niet te ver vooruit werken, want als je in een agile omgeving werkt kan de planning per sprint veranderen. In het geval dat de functionaliteit wordt veranderd of de prioriteit ervan verandert, is de moeite van de bedrijfsanalist voor niets geweest.

Uiteraard blijft de bedrijfsanalist deel uitmaken van het team en ook heeft de bedrijfsanalist de input van de ontwikkelaars/testers nodig voor de technische (on)mogelijkheden. Ontwikkelaars/testers hebben de bedrijfsanalist nodig voor vragen over de functionaliteit die wordt geïmplementeerd/getest.

Samenwerking/communicatie

De interactie tussen de bedrijfsanalist en de ontwikkelaars/testers brengt me bij de laatste tip. Alle mensen die bij het project betrokken zijn, moeten samenwerken en met elkaar communiceren. Dit geldt niet alleen voor de bedrijfsanalisten en ontwikkelaars/testers, maar ook tussen gelijken, tussen ontwikkelaars en beheer, tussen producteigenaren, etc.

De communicatie kan beter niet via documenten en e-mails plaatsvinden, maar is bij voorkeur persoonlijk.

Het werkt productiever wanneer mensen in dezelfde ruimte werken. Op die manier kunnen ze vragen stellen en direct reageren waar nodig. Mensen zijn zich meer bewust van wat er in het project speelt wanneer ze andere mensen horen praten over (problemen met) het werk. Ze kunnen zich er ook direct in mengen als dat nodig is. Uiteraard heb je nog steeds documentatie nodig voor informatie en voor het documenteren van beslissingen over het ontwerp. Dit moet bij voorkeur niet alleen per e-mail gebeuren, omdat je anders niet meer weet waarom bepaalde beslissingen in het verleden zijn genomen.

Conclusie

Ik hoop dat deze blog je enige inspiratie geeft om na te denken over hoe je je project/organisatie moet organiseren en ik hoop dat je de juiste keuzes voor je project/organisatie kunt maken. En wanneer je niet direct de juiste beslissingen hebt genomen, twijfel dan niet om flexibel te zijn en de dingen te veranderen die niet werken voor je project/organisatie.