Om maar meteen met de deur in huis te vallen: het eerste deel van de titel van deze blogpost is simpelweg niet juist. Zelfs als je een technical lead bent, moet je geen technische discussie leiden; je moet de discussie alleen coördineren en faciliteren.
Dit klinkt vrij voor de hand liggend, maar vaak zijn de meest getalenteerde technische mensen introvert. Het is voor hen, inclusief mijzelf, niet gemakkelijk om iets te zeggen in het heetst van de discussie. Stop dus af en toe even en vraag iedereen persoonlijk om een bijdrage te leveren. Ik begrijp dat het een beetje geforceerd lijkt om elk teamlid te vragen een bijdrage te leveren aan de technische discussie, maar vaak komen de beste technische ontwerpen van de stilste teamleden.
Mijn favoriete manier om kleine sessies voor het ontwerpen van een solution architecture te houden, is op een whiteboard. Een whiteboardsessie is de ideale manier om een eerste technisch ontwerp te maken met veel korte feedbackcycli. Het maakt niet uit of het een traditioneel whiteboard is of een fancy digitaal whiteboard. Met het traditionele whiteboard is het natuurlijk meer werk om het bord handmatig te wissen om een nieuw ontwerp te beginnen. Ik denk dat dat een positieve zaak is, omdat je dan niet te snel van het ene onderwerp naar het andere springt. Wanneer een traditioneel whiteboard wordt gewist, is dat als een afsluiting van de design sessie over een bepaald onderwerp.
Een andere tip is om ervoor te zorgen dat er slechts één whiteboard marker tegelijk in gebruik is voor alle mensen in de ruimte. Terwijl de ene persoon uitleg geeft en op het bord tekent, luistert de andere persoon. De whiteboard marker fungeert als een token, zodat er maar één persoon tegelijk spreekt. Het equivalent tijdens een videogesprek is je hand opsteken, waarbij de host elkaar de tijd geeft om hun punt uit te leggen. Deze strategie kan natuurlijk ook worden toegepast tijdens een traditionele vergadering, gebruik dan gewoon een teddybeer als token.
In een eerder project waar ik voor een bank werkte, hadden we ter voorbereiding op een nieuwe ontwikkelingscyclus van de volgende sprint verschillende whiteboard sessies met een roulatiesysteem. Alle teamleden, junior of senior, namen op gelijke voet deel aan de whiteboard sessies volgens een eenvoudig roulatiesysteem. “Je kunt er niet onderuit, nu is het jouw beurt om te spreken!”
De laatste verfijning van een technisch ontwerp moet best door het hele team worden gedaan. Deze vergadering fungeert als een goedkeuring van het technische ontwerp, zodat je weet dat het hele team op één lijn zit. Voor de verdeling van de tickets zou ik het werk verdelen over de teamleden die aanwezig zijn bij de vergadering. Bekijk snel elkaars tickets en zorg ervoor dat de acceptatiecriteria duidelijk zijn geformuleerd. Als er geen grote aanpassingen aan het technische ontwerp nodig zijn, kan het team aan het einde van de vergadering, met het ontwerp nog vers in het geheugen, meteen de story-schatting doen.
Als je veel ervaring hebt als technical lead, kun je beter niet zomaar met een oplossing komen (ook al is die nog zo goed). Wijs je teamleden in de juiste richting en laat hen de voor- en nadelen van het ene ontwerp ten opzichte van het andere bespreken. Er bestaat niet zoiets als het perfecte ontwerp voor softwarearchitectuur. Het is altijd een afweging tussen schaalbaarheid en eenvoud, beschikbaarheid en kosten, om maar een paar voorbeelden te noemen. Gezien deze afwegingen moet je het technische ontwerp kiezen dat geschikt is voor jouw specifieke gebruikssituatie. Zorg er wel voor dat je het technische ontwerp met je hele team hebt uitgewerkt en overeengekomen.
Tot slot mijn laatste advies voor elke communicatie die je voert. Stem je communicatie af op je doelgroep. Onlangs vroeg een manager mij om de solution architectuur voor het synchroniseren van lokale data en bestanden naar de cloud uit te leggen. Omdat ik maar weinig tijd had om de solution architectuur uit te leggen, concentreerde ik me meer op de samenwerking tussen de verschillende teams in de organisatie en hoe elk team verantwoordelijk zou zijn voor het leveren van de oplossing. Een diepgaande analyse van hoe de technologieën samenwerken om de beoogde architectuur te realiseren, zou niet het beste gebruik zijn geweest van de beperkte tijd die we voor de vergadering hadden.