The development process Part 2

Have you read the previous blog yet?: The Development Process, part 1?

Alex, vastbesloten om echte verandering teweeg te brengen, stelt een gedurfde oplossing voor waarvan Alex gelooft dat die de kern van de problemen kan aanpakken. “Ik heb onderzoek gedaan en hier goed over nagedacht,” zegt Alex. “Ik stel voor dat we bij Etrain een fundamentele verandering in onze manier van werken overwegen. Uiteindelijk bouwen we allemaal aan verschillende producten, maar ze maken deel uit van één gezamenlijke visie. We moeten alle beschikbare middelen benutten en rekening houden met de wensen en expertise van onze ontwikkelaars. Onze omgeving is complex en voortdurend in beweging. We verliezen waarde omdat onze teams daar niet goed mee omgaan. Dus in plaats van de ontwikkelaars te vertellen wat ze moeten doen, moeten we hen vragen wat zij denken. Flexibiliteit en het centraal stellen van mensen moeten onze leidende principes zijn bij het aanpakken van dit probleem. Laat de softwareontwikkelaars zelf met een oplossing komen. Ik weet zeker dat ze dat kunnen.”

Het voorstel van Alex roept gemengde reacties op in de groep. Sommigen knikken instemmend en zien de potentie van dit idee, terwijl anderen, zoals de projectmanager die eerder al bezorgdheid had geuit, voorzichtig blijven.

“Het klinkt veelbelovend,” zegt een van de product owners, “maar hoe zou dat in de praktijk werken? Stel je iets voor als een grootschalig agile framework? Zou dat echt helpen tegen de voortdurende veranderingen en instabiliteit waar we mee te maken hebben?”

Alex schetst de visie en benadrukt het belang van multidisciplinaire teams, duidelijke communicatie en aanpassingsvermogen. Volgens Alex kan de organisatie, door zich te richten op een gezamenlijke visie, teams meer beslissingsruimte te geven en samenwerking te bevorderen, een omgeving creëren waarin mensen kunnen groeien en hun beste werk leveren. Terwijl de discussie verdergaat, wordt duidelijk dat het pad moeilijk zal zijn, maar dat het een veelbelovende oplossing biedt voor de aanhoudende problemen waar Etrain al zo lang mee kampt.

“Ja hoor, veel succes ermee,” zegt een projectmanager spottend. “Etrain is hier helemaal niet klaar voor. Je vraagt om het onmogelijke.”

Een ander voegt toe: “Misschien moet je gewoon weer achter je laptop kruipen, Alex. Dit ligt buiten jouw expertise.”

Alex zwijgt even. Twijfel sluipt naar binnen, maar dan klinkt een vertrouwde stem. Het is de product owner van het boekingssysteem. “Ik denk dat softwareontwikkeling juist precies Alex’ expertise is.”

Mensen boven plannen

In The Development Process, Part 1 bespraken we de belangrijke rol van planning binnen softwareprojecten. Toch is plannen slechts het begin; het echte werk gebeurt tijdens de ontwikkelfase, waar menselijke creativiteit en expertise centraal staan. Zelfs in dit tijdperk van kunstmatige intelligentie, waarin we ons onmiskenbaar bevinden, blijft één waarheid overeind: mensen brengen software tot leven. In tegenstelling tot planning, testen of programmeren zijn mensen geen onderdeel van softwareontwikkeling, ze zijn het kloppende hart ervan. Software bestaat om mensen te helpen, en software engineering bloeit dankzij de mensen die het creëren. Dat brengt me bij het belangrijkste punt van deze blog: kunnen samenwerken met mensen is een onmisbare vaardigheid voor elke software engineer.

Samenwerken met anderen, zelfs als je alleen werkt

Ik wil niet overdrijven, maar ik heb mensen horen zeggen dat ze “alleen coderen” omdat ze niet in een team werken. Je zou kunnen beweren dat mensenvaardigheden voor zulke softwareontwikkelaars niet belangrijk zijn. Je zou dat kunnen beweren, maar je zou ongelijk hebben. Laat me kort uitleggen waarom ik denk dat zelfs “solo-ontwikkelaars” op verschillende manieren met mensen samenwerken. Ten eerste krijg je te maken met eisen die door mensen zijn opgesteld, of dat nu je eigen specificaties zijn of die van klanten en belanghebbenden. Ten tweede is je software bedoeld voor gebruikers, echte mensen die ermee werken en erop vertrouwen. Ten slotte, zelfs als je de eerste en enige ontwikkelaar van een project bent, bouw je voort op het werk van voorgangers die hun code, documentatie en kennis hebben achtergelaten, en op dat van opvolgers die verder bouwen op wat jij hebt gemaakt. Of je nu alleen werkt of deel uitmaakt van een groter team, de invloed en betrokkenheid van mensen zijn onlosmakelijk verweven met softwareontwikkeling.

En natuurlijk, als je werkt in een softwareteam dat uit meer dan één persoon bestaat, zijn mensenvaardigheden nog belangrijker. Laten we daarom de verschillende mensen bespreken met wie je als software engineer samenwerkt, te beginnen bij de eisen. Aan de ene kant zijn er analisten, requirement-schrijvers en stakeholders, en het kunnen communiceren met hen is een grote meerwaarde. Aan de andere kant heb je degene die het vaakst met de eisen wordt geassocieerd: de productleider. Communicatie met je productleider is van cruciaal belang.

Productleiderschap versus productmanagement

Je hebt misschien gemerkt dat ik het had over een productleider in plaats van de meer bekende termen product owner of product manager. Binnen softwareontwikkeling is het essentieel dat er iemand is die de essentie van het product vertegenwoordigt en ervoor zorgt dat het aansluit bij de visie en de doelen van de organisatie. Deze verantwoordelijkheid ligt vaak bij de rollen van Product Owner (PO) en Product Manager (PM). Deze twee functies vervullen verschillende, maar elkaar aanvullende rollen binnen het ontwikkelproces.

Een PO richt zich vooral op de eindgebruikers en belanghebbenden. De PO is verantwoordelijk voor het definiëren en prioriteren van functionaliteiten, het creëren van een duidelijke backlog en ervoor zorgen dat het ontwikkelteam levert wat de gebruikers nodig hebben. De PO fungeert als de stem van de klant en onderhoudt een nauwe feedbacklus met de eindgebruikers om ervoor te zorgen dat het product blijft aansluiten op hun wensen.

Een PM heeft daarentegen een bredere blik. De PM is verantwoordelijk voor de algehele strategie, marktanalyse en de langetermijnvisie van het product. PM’s coördineren met verschillende teams, stellen strategische doelen en zorgen ervoor dat het product aansluit bij de bedrijfsdoelstellingen. Zij spelen een belangrijke rol bij het begrijpen van markttrends en de concurrentiepositie.

In veel succesvolle softwareontwikkelingsteams vloeien deze rollen samen tot één conceptuele rol: de Productleider (PL). Een PL combineert de gebruikersgerichte focus van een PO met het strategisch inzicht en de marktkennis van een PM. In dynamische omgevingen wordt het steeds belangrijker om iemand te hebben die deze functies kan overbruggen.

Waarom is invloed hebben op productbeslissingen binnen het ontwikkelteam zo belangrijk? Wanneer softwareontwikkelaars inspraak hebben in de richting van het product, vergroot dat niet alleen hun gevoel van eigenaarschap en betrokkenheid, maar leidt het ook tot innovatievere oplossingen. Ontwikkelaars die dagelijks met de code werken, hebben vaak unieke inzichten in technische haalbaarheid, potentiële obstakels en kansen voor verbetering. Hun betrokkenheid bij productbeslissingen kan leiden tot efficiëntere processen en betere resultaten.

Eerder zei ik dat communicatie met je productleider cruciaal is. De meeste ontwikkelaars zullen het daarmee eens zijn. Degenen die dat niet zijn, hebben vaak een heel andere manier van denken. Ik onderscheid twee denkwijzen: ‘ik schrijf de code’ en ‘ik help het product te creëren’. De eerste duidt op een enge focus op programmeertaken, terwijl de tweede een bredere visie omarmt. De ‘ik help het product te creëren’-mentaliteit erkent dat softwareontwikkeling niet enkel draait om het schrijven van code, maar om het creëren van oplossingen die gebruikers helpen en voldoen aan bedrijfsdoelen. Deze manier van denken stimuleert samenwerking, een dieper begrip van het doel van het product en een gedeelde verantwoordelijkheid voor het succes ervan. In de snel veranderende wereld van technologie is het aannemen van een product creator-mentaliteit een krachtige manier om innovatie te stimuleren, waardevolle gebruikerservaringen te creëren en ervoor te zorgen dat je software niet alleen werkt, maar uitblinkt in het vervullen van gebruikersbehoeften.

Interactie met gebruikers

Laten we beginnen met het belang van interactie met gebruikers. Meestal is het de productleider die het voortouw neemt in het contact met gebruikers, zowel direct als indirect, terwijl ontwikkelaars zich richten op de technische aspecten. Toch is het voor een software engineer waardevol om zelf te kunnen communiceren met gebruikers. Het biedt nieuwe inzichten en een breder perspectief, wat bijdraagt aan je persoonlijke en professionele groei. Daarnaast is het als ontwikkelaar nuttig om na te denken over manieren om gebruikerscommunicatie in je product te vergemakkelijken en te automatiseren. Functies zoals een ‘Neem contact op’ optie, evaluatiemogelijkheden voor verschillende functies, duidelijke foutmeldingen en foutcodes, en sterke monitoringmechanismen zijn daarbij waardevol. Hoewel deze onderwerpen eerder zijn besproken, verdienen ze herhaling, omdat ze bijdragen aan een soepelere gebruikerservaring en een efficiënter ontwikkelproces.

Werken in een team

Nu gaan we naar de kern van dit stuk, waarin we onderzoeken hoe de samenstelling en interactie binnen teams invloed hebben op productiviteit. Voor de meeste ontwikkelaars is teamwork een essentieel onderdeel van hun werk, en inzicht in teamdynamiek is cruciaal.

Ik heb het eerder al kort genoemd, maar laten we nu dieper ingaan op de fasen van teamontwikkeling volgens het model van Tuckman.

Forming: In deze eerste fase komt het team net bij elkaar. Teamleden zijn vaak beleefd, voorzichtig en proberen hun rol en verwachtingen te begrijpen. Ze hebben nog geen volledig beeld van het project of van hun plaats daarin.

Storming:In de tweede fase kunnen conflicten ontstaan. Teamleden leren elkaar kennen, brengen ideeën in en botsen soms over beslissingen of prioriteiten. Dit is een periode van spanning en machtsstrijd, waarin teamleden hun invloed proberen te vinden.

Norming:In deze fase beginnen teamleden gemeenschappelijke grond te vinden en afspraken te maken over samenwerking. De samenwerking verloopt soepeler, vertrouwen groeit, en de rollen en verantwoordelijkheden worden duidelijker.

Performing:In de vierde fase werkt het team op zijn hoogst mogelijke niveau. De leden zijn betrokken, werken naadloos samen en behalen hun doelen effectief. Er is een sterk gevoel van eenheid en richting.

Adjourning:In de laatste fase rondt het team het werk af en gaan leden verder naar andere projecten of rollen. Dit moment wordt vaak gebruikt om terug te kijken op de prestaties en het gezamenlijke leerproces af te sluiten.

In elke fase kunnen gedragingen die in de ene fase nuttig zijn, in een andere fase juist schadelijk zijn. Daarom is het belangrijk te herkennen in welke fase het team zich bevindt en wat het effect van bepaald gedrag is.

In de Forming-fase zijn teamleden vaak te voorzichtig of terughoudend om hun mening te delen, en vertrouwen ze te veel op de leider. Richt je daarom op het opbouwen van onderlinge banden en een cultuur van openheid.

In de Storming-fase ontstaan conflicten en discussies. Het instinct om deze te vermijden is begrijpelijk, maar niet verstandig. Laat ruimte voor meningsverschillen, maar zorg voor duidelijke regels: houd gesprekken professioneel en respectvol, en beperk de tijd die eraan wordt besteed.

Tijdens Norming kunnen teamleden te comfortabel worden, veranderingen vermijden of meegaan in groepsdenken. Documenteer daarom de gemaakte afspraken, beslissingen en werkwijzen, zodat de teamstructuur stabiel blijft en motivatie behouden wordt.

In de Performing-fase is er een risico op burn-out door hoge betrokkenheid. Creativiteit kan afnemen als het team te veel focust op efficiëntie. Blijf daarom regelmatig terugblikken en vooruitkijken, zodat het team zijn energie behoudt en tijdig veranderingen kan opvangen.

De efficiëntie van een team kan afnemen als het terugvalt naar een eerdere fase. Dit kan gebeuren door:

Nieuwe teamleden
Veranderende rollen
Het vertrek van sleutelfiguren
Verschuiving in projectdoelen, budget of scope.
Schijnbare vooruitgang, waarbij men doet alsof er overeenstemming is om het management tevreden te stellen, kan echte groei belemmeren.

Het begrijpen van deze teamdynamiek en alert blijven op mogelijke valkuilen is essentieel om een productieve en harmonieuze werkomgeving te behouden.

Tot slot zijn er nog enkele andere belangrijke aspecten van succesvolle softwareteams. Naar mijn ervaring moeten teamleden gelijkwaardig zijn en fouten kunnen accepteren.
Daarnaast hoort het begeleiden en coachen van elkaar bij het vak van software engineer. Dat leg ik graag verder uit.

Gelijkheid

In mijn ervaring is een van de belangrijkste aspecten van effectief teamwork het principe van gelijkheid binnen het team. Natuurlijk maken we allemaal graag onderscheid tussen juniors en seniors. Zelfs ik heb aan het begin van deze serie een onderscheid gemaakt tussen coders, programmeurs en engineers, wat als een hiërarchie kan worden gezien. Toch geloof ik dat elk team waarin één persoon niet kan worden tegengesproken, vroeg of laat tot problemen zal leiden. Niemand heeft altijd gelijk, zeker niet in de complexe wereld van softwareontwikkeling.

Om het belang van gelijkheid te illustreren, gebruik ik een voorbeeld uit de luchtvaartgeschiedenis.

(En ja, ik geef toe: ik heb bijna elke aflevering van Mayday: Air Crash Investigation gezien. De parallellen met softwareontwikkeling zijn vaak treffend.)

De tragische crash van Eastern Air Lines vlucht 401 in 1972 laat zien wat er kan gebeuren als teamleden, in dit geval de copiloot en de boordwerktuigkundige, zich niet vrij voelen om beslissingen van een andere collega, de piloot, in twijfel te trekken. Het vliegtuig was technisch in orde, maar stortte neer vanwege een defect lampje van het landingsgestel. De copiloot en boordwerktuigkundige merkten het probleem op, maar durfden de piloot niet tegen te spreken. Ze vonden dat het ongepast was om zijn oordeel in twijfel te trekken. Het gevolg was een ramp waarbij vele levens verloren gingen.

Deze gebeurtenis onderstreept hoe belangrijk het is om een werkomgeving te creëren waarin alle teamleden, ongeacht hun rol, zich vrij voelen om hun zorgen te uiten en beslissingen te bevragen wanneer dat nodig is. In softwareontwikkeling betekent dit een cultuur van open communicatie, waarin junior engineers senior ontwikkelaars mogen aanspreken en andersom. Diversiteit in denkbeelden en perspectieven leidt tot betere beslissingen en veiligere resultaten.

Emotionele veiligheid

Een andere belangrijke factor voor teamsucces is emotionele veiligheid. Met andere woorden: elk teamlid moet zich vrij voelen om fouten te maken. Falen is een onvermijdelijk onderdeel van groei en innovatie, en het is essentieel dat teamleden fouten kunnen maken zonder angst voor zware gevolgen. Als mensen bang zijn om gestraft te worden, zullen ze minder snel risico’s nemen of nieuwe ideeën aandragen. Die angst smoort creativiteit en leidt tot middelmatige oplossingen.

Binnen softwareontwikkeling bevordert een cultuur van psychologische veiligheid juist experimenteren en leren van fouten. Een software engineer kan hierin het goede voorbeeld geven. Wanneer ontwikkelaars niet bang zijn om fouten toe te geven of onconventionele ideeën te delen, kan dat leiden tot doorbraken en verbeteringen in het ontwikkelproces. Het helpt ook anderen in het team om zich veilig te voelen. Door open te praten over mislukkingen en ze te zien als leermomenten, kan een team groeien en sterker worden.

Mentorschap en coaching

Mentorschap en coaching zijn essentieel voor de groei en professionele ontwikkeling van software engineers. Activiteiten zoals code reviews zorgen niet alleen voor een betere codekwaliteit, maar bieden ook kansen voor kennisdeling en begeleiding. Senior engineers kunnen junior collega’s begeleiden en hun waardevolle inzichten en best practices doorgeven.

Daarnaast dragen mentoring en coaching bij aan de professionalisering van het vakgebied. Het gaat niet alleen om technische vaardigheden, maar ook om ethisch besef en verantwoordelijkheidsgevoel. Door mentorschap te stimuleren binnen softwareteams, overbrug je de kloof tussen ervaren engineers en nieuwkomers, en verhoog je de algemene standaard van de industrie.

Maak je geen zorgen, wees gelukkig

Natuurlijk zijn er nog veel meer factoren die bijdragen aan succesvol softwareontwikkelen. In eerdere blogs heb ik Agile en DevOps al genoemd, omdat ik transparantie als cruciaal beschouw. Toch moet bijna elk ander aspect van het ontwikkelproces worden afgestemd op de specifieke situatie. Als je de adviezen uit deze serie volgt en transparantie, softwarekwaliteit en ethiek als leidraad gebruikt, vind je een werkwijze die past bij jouw team, jouw product en jouw moment.

Er is echter nog één heel belangrijk element dat succes bepaalt, of in elk geval hoe vaak en hoe diep je succes ervaart: plezier in je werk. Software engineers moeten plezier hebben in wat ze doen om goed te kunnen presteren. Niemand kan goed functioneren in een complexe en veranderlijke omgeving zonder voldoening uit zijn werk te halen. Kijk daarom regelmatig terug op je vooruitgang, stel duidelijke grenzen en maak werkplezier een expliciet doel voor jezelf en je team.

Een van de terugkerende thema’s van deze blogserie is geweest: “[X] is jouw verantwoordelijkheid, niet die van iemand anders.” Dat geldt nergens meer dan bij je eigen geluk. Het is waarschijnlijk de moeilijkste verantwoordelijkheid van allemaal, zeker voor sommigen, dus help elkaar waar je kunt.

Een mensenmens zijn is noodzakelijk voor de toekomst van ons vak

We zijn bijna aan het einde van deze blog. De volgende blog in deze serie zal de laatste zijn en een iets andere vorm aannemen. Maar voordat we afsluiten, wil ik nog één laatste argument geven over waarom goed met mensen kunnen omgaan zo belangrijk is. Het is essentieel om de vooruitgang van ons vakgebied te bewaken. We moeten samenwerken met de volgende generatie, hen inspireren en ook naar hen luisteren. De wereld van software engineering zal alleen verder ontwikkelen en professioneler worden als ervaren engineers actief in contact treden met nieuw talent en bereid zijn om de status quo ter discussie te stellen. Het is niet genoeg om in je comfortzone te blijven; ervaren engineers zouden actief kansen moeten zoeken om te mentoren, te onderwijzen en nieuwkomers te inspireren. Dat ik dat belangrijk vind, zal geen verrassing zijn; het is tenslotte de reden waarom ik deze hele blogserie schrijf.

Door kennis te delen, een gevoel van ethische verantwoordelijkheid te bevorderen en kritisch denken aan te moedigen, dragen ervaren engineers bij aan een professionelere en meer ethische software-industrie. Deze verantwoordelijkheid gaat verder dan het schrijven van code. Het draait om het vormgeven van de toekomst van het vak en ervoor zorgen dat het zich in een positieve richting ontwikkelt. Het is een investering in de groei en duurzaamheid van het vakgebied zelf, met als belofte een helderdere en innovatievere toekomst voor software engineering.

Epilog

Een jaar later, in het gezellige kantoor van Kim, een ervaren coach en mentor, zit Alex comfortabel in een stoel. Ze drinken samen een kop koffie en blikken terug op de veranderingen die zich het afgelopen jaar bij Etrain hebben voltrokken. Kim speelde een belangrijke rol in het begeleiden van Alex tijdens de uitdagende periode waarin een nieuwe, samenwerkingsgerichte manier van werken in de hele organisatie werd ingevoerd.

Kim begint met een warme glimlach. “Zo, Alex, het is een bewogen jaar geweest. Laten we eens praten over hoe het gaat met de verschillende projecten die je bij Etrain leidt.”

Alex leunt iets naar voren en knikt dankbaar. “Dat kun je wel zeggen. We hebben veel fouten gemaakt, maar de veranderingen in de teamdynamiek hebben wel meer stabiliteit en transparantie gebracht. Het was niet altijd makkelijk. Mensen zijn vertrokken. Er waren conflicten. Maar ik denk dat de resultaten goed zijn.”

Kim knikt bedachtzaam. “Verandering is nooit makkelijk. Het is een cliché, maar waar. Als ik het goed heb, werk je nu bijna twee jaar bij Etrain? Je hebt veel gedaan dat niet direct van je werd verwacht toen je begon.”

Alex glimlacht. “Klopt. Ik heb veel petten gedragen. Naast programmeren en architectuur opzetten, ben ik ook mentor en coach geworden voor andere ontwikkelaars en zelfs voor anderen binnen Etrain. Het stond niet in mijn functiebeschrijving, maar het voelde gewoon noodzakelijk om hen te helpen omgaan met de veranderingen die we doorvoerden.”

Kim knikt goedkeurend. “Dat is bewonderenswaardig, Alex. Je hebt een leiderschapsrol op je genomen die verder gaat dan je functietitel.”

“Maar gaat het echt verder dan mijn rol?” vraagt Alex. “Is dit niet juist wat er nodig is om goede software te ontwikkelen?”

Kim kijkt even nadenkend naar Alex en haalt dan haar schouders op. “Misschien wel. Laat ik het zo vragen: wat vind jij dat de verantwoordelijkheden van een software engineer zijn?”

Alex denkt even diep na. “Ik denk dat de verantwoordelijkheden van een software engineer veel verder gaan dan alleen code schrijven. We zijn probleemoplossers, samenwerkers en mentoren. Onze taak is niet alleen om werkende software te bouwen, maar om oplossingen te creëren die het leven van mensen beter maken. Het gaat om een cultuur van continue verbetering, leren van fouten en anderen helpen hetzelfde te doen. Uiteindelijk draait het om de impact die we hebben op de organisatie, de industrie en zelfs de wereld.”

Kim glimlacht. “Misschien moeten we de vacaturetekst voor software engineers op de website aanpassen,” grapt ze. “Je bent ver gekomen. Je was al een indrukwekkende engineer toen ik je ontmoette, maar nu combineer je dat met diepgang en empathie.”

“Bedankt, denk ik,” zegt Alex met een glimlach.

“Je moet alleen nog een beetje oefenen op hoe je complimenten aanneemt,” zegt Kim lachend.

Als het gesprek eindigt, verlaat Alex het kantoor met een gevoel van rust, ondanks de uitdagingen die de projecten bij Etrain nog steeds met zich meebrengen. Terwijl Alex door de gangen loopt, denkt die terug aan de afgelopen twee jaar. “Software engineering is een geweldig vak,” denkt Alex, terwijl die achter een laptop gaat zitten en nog een paar regels code schrijft.