Ouderwets programmeren of ontwikkelen? Dat is soms zo slecht nog niet!
Java, programmeren
Er is een wereld van verschil in de aanpak van de jaren 90 en die van nu. In de jaren 90 werkte ik bij een semioverheid organisatie. We hadden een elegant ontwikkel-team: programmeurs, ontwerpers, testers, een paar informatieanalisten, projectleiders, hoofd systeemontwikkeling en dat was het wel zo’n beetje. Als ik dat vergelijk met wat er nu allemaal om me heen loopt: nog steeds die programmeurs, ontwerpers en informatieanalisten, maar ook een scrum master, een product owner, een productmanager, architecten, changemanagers … Allemaal extra mensen die vooral het voortgangsproces in de gaten houden. Dan bekruipt mij de vraag: waarom kon dat destijds met een paar man en is het tegenwoordig zo ongeveer één op één? Voor elke programmeur is er een persoon voor het voortgangsproces. Gaat het nu dan zoveel beter?
Leestijd: 3 minuten – Auteur: Ton Neijzen Sr. Java programmeur
Vergadertijgers
Eerlijk gezegd denk ik dat het nu vooral langzamer gaat. Al die mensen hebben ook weer producten die zij moeten opleveren of moeten krijgen en alles moet gecontroleerd worden. Allemaal niet-essentiële zaken die veel tijd kosten. Begrijp me niet verkeerd, ik heb niks tegen scrum of agile werken! Het is een prima uitgangspunt om een beperkt groepje mensen te hebben dat wat vaker overlegt en als zelfstandige eenheid functioneert. Het wordt, in mijn ogen, gecompliceerd door alle ‘randzaken’ zoals refinement sessies, etc. Op zich leuk om te weten wat er allemaal in het team gebeurt, maar al die vergaderingen en overleggen kosten vele uren per week. Tijd die ik niet kan gebruiken voor het opleveren van code of het oplossen van problemen. Zonder al die vergaderingen had ik misschien wel 50% meer vermogen beschikbaar om het echte werk te doen.
Controledrang
Natuurlijk zijn er in het verleden projecten misgegaan. Vanuit het management zullen ze gedacht hebben dat ze meer grip op projecten hebben door er meer mensen omheen te zetten. Ik vraag me af of dat effectief is. Als er bij Alvant iets geregeld moet worden, gaan we daar niet met 100 man (stel dat we 100 man zouden hebben) over kletsen voordat er iets besloten wordt. Er worden spijkers met koppen geslagen zodat we snel weer verder kunnen. Ik denk dat er bij veel bedrijven veel meer slagkracht is als je met een paar man het werk kan doen. Voordat ik kan programmeren, heb ik natuurlijk eerst informatie nodig. Maar of ik die ophaal in een vergadering waar acht man bij zitten, of in een vergadering met twee man, is een wezenlijk verschil.
Risicomijdend gedrag
Een hoop bedrijven realiseren zich niet hoe ingewikkeld ze het zichzelf maken. Het is er ingesleten, dit is het nieuwe normaal. Ik overdrijf niet met het voorbeeld van iemand waar ik mee heb gewerkt, die met een procesplaat aankwam van 50 stappen om een project af te krijgen. Tussen al die stappen stonden drie vakjes met de thema’s ontwerp, bouw en test. Dat betekent dat er 47 vakjes omheen waren toegevoegd die niet essentieel waren voor het proces. Deze werkwijze is een vorm van risicomijdend gedrag. Iemand heeft ooit bedacht dat er meer schakels toegevoegd moeten worden om risico’s te beperken. Als er een probleem is, probeert men zoveel mogelijk mensen in een zaaltje te krijgen om het probleem op te lossen. Terwijl het bij een technisch probleem veel effectiever is om mij een paar uur ergens apart te zetten, dan kom ik ook met een oplossing of een weg daarnaartoe.
Ruimte en vertrouwen
Het is zeker niet zo dat vroeger alles beter was, maar ik zou managementteams wel mee willen geven: vertrouw je ontwikkelteams. Zo’n team kan vaak heel veel. Als je ze lekker aan het werk laat, dan komt er ook heel veel. Als je ze niet vertrouwt en er allemaal mensen omheen zet om te kijken wat er gebeurt, wordt het eindresultaat niet beter en duurt het alleen maar langer. Als programmeur kan ik niet, tegen de stroming in, een organisatie omgooien. Er zitten veel mensen omheen en er zijn veel belangen. Werkt het scrumteam niet goed, dan is er altijd wel iemand die daar een training voor heeft of er wordt een coach opgezet. Zo hou je het systeem in stand. Nogmaals, ik zeg niet dat we terug moeten naar vroeger, maar ik vraag me wel af waarom het zo ingewikkeld is geworden.
Een beetje terug naar toen? Moet je doen!
Met het risico als een oude mopperpot over te komen, durf ik te zeggen: ik heb jaren levens- en werkervaring. Daardoor kan ik oud en nieuw goed vergelijken. Zeker in deze tijd van arbeidskrapte, is het heel welkom als je dingen beter kan doen met minder mensen. Dus wat ik managementteams mee wil geven is: kijk eens goed naar alle processen, vraag je af wat wel of niet nodig is, geef je mensen ruimte, vrijheid en vertrouwen en probeer een tandje terug te schakelen. Mensen herontdekken de goede dingen van weleer. Ik heb mijn oude platenspeler ook weer in de kamer staan. Misschien is de good old watervalmethode wel de nieuwe platenspeler! Sommige dingen van vroeger zijn namelijk zo slecht nog niet.