Software development is een serieuze zaak en in de regel een teaminspanning. De op zichzelf werkende ‘zolderprogrammeur’ is meer en meer iets uit het verleden. Toch is samenwerken makkelijker gezegd dan gedaan. Java-veteraan Sven Peters verklapt het geheime recept voor succesvolle teams.

Teams van software-ontwikkelaars lijken op het eerste oog veel op elkaar. Elk team bestaat immers uit developers, die code schrijven en nieuwe features maken. Alleen produceren sommige teams minder bugs in hun code en brengen ze sneller nieuwe features uit. Dergelijke succesvolle teams doen het dus anders. Zijn hun developers dan beter? Niet per sé. Ze zijn wel beter in staat om zich te concentreren op hun werk en dat kan ze werkplezier, voldoening en zelfs ontspanning opleveren.

 

Geen rockstar developer

Wat is het geheim? Ontwikkelaar en J-Fall keynote spreker Sven Peters vertelt over de ‘secret sauce’ voor succesvolle teams. Dat is niet het hebben van ‘het schaap met vijf poten’, ofwel de mythische 10x rockstar developer. Nee, het gaat simpelweg om teamwork en soepele samenwerking door een goed op elkaar afgestemd team. Alleen is teamwork niet simpel te realiseren.

“We denken niet goed na over hóe we samenwerken”, begint Sven Peters zijn uitleg. De technology evangelist bij Atlassian trekt de vergelijking met voetbal. Daarbij vormen verschillende spelers met diverse talenten een soepel werkend – en winnend – team. Een keeper heeft hele andere skills nodig dan een aanvaller, die weer andere talenten nodig heeft dan een verdediger. Elk van die spelers is wel een voetballer. Bij development ligt dat subtiel anders.

 

Keeper tot en met aanvaller

“In de ICT denken we nogal in silo’s: je hebt programmeurs, designers en ops-mensen”, somt Peters op. “Modern software development moet die hele keten omvatten”, stelt hij. Dus vanaf de programmeur die voor functionaliteit zorgt, via de ontwerper die over uiterlijk en toegankelijkheid gaat, tot en met operations (ops) die de uiteindelijke software beheert, zodat het echt gebruikt kan worden. Hechte samenwerking tussen deze spelers is de basis voor een succesvol team en daarmee voor succesvolle software-ontwikkeling.

Peters pleit dan ook voor cross-functionele teams. “Die zijn als core-teams, maar dan diverser.” De grotere diversiteit geldt niet alleen voor de samenstelling van de individuele teams. Het moet ook gelden voor ‘doorkruising’ van teams. Peters legt uit: “het opnemen van een designer in diverse ontwikkelteams zorgt ervoor dat je een consistent design hebt. Hetzelfde valt bijvoorbeeld te doen voor de onderliggende architectuur van je code.”

 

‘HR-probleem’

Een dergelijke consistentie middels ‘doorkruising’ levert wel een probleem op. Een ‘HR-probleem’, zoals Peters het omschrijft. Namelijk de taak om mensen, taken en werktijd dusdanig in te delen dat het doenbaar is. Wat hierbij veel helpt, is het formuleren en nastreven van duidelijke doelen voor elk team in het hele ontwikkelproces. “Een jaardoel is dan te ver weg. Je moet én short-term goals hebben én doelen voor de lange termijn.”

Laatstgenoemde is dan de Noordster waar je op af koerst. Het ‘guiding light’ van de overkoepelende visie waar je als organisatie naar toe wilt. Overigens is dat lange termijn doel niet in steen gebeiteld, voegt Peters nog een belangrijke nuancering toe. Gaandeweg kunnen nieuwe ontwikkelingen, nieuwe inzichten en nieuwe prioriteiten opkomen. Deze moeten natuurlijk niet genegeerd worden, omdat er ooit een visie is vastgelegd.

 

Visie en focusgebieden

Onder zo’n grote, algemenere visie vallen dan de focusgebieden. Dát zijn dan de duidelijke doelen waar individuele teams zich op moeten richten. Bij twijfel over werk- en tijdverdeling kies je dan voor de focusgebieden. Het bepalen van die aandachtsgebieden is een taak voor de projectmanagers, waarbij ook doelen (objectives) en kernresultaten (key results) worden opgesteld.

Het objective voor een developersteam kan bijvoorbeeld het bouwen van een mobiele app zijn. Het doel voor de organisatie is dan bijvoorbeeld het bereiken van vijfhonderd dagelijkse gebruikers van die app. Natuurlijk kan een extra impuls worden gegeven door een verder gaand streefdoel (stretch goal) te formuleren.

 

Ruimte voor verandering

Peters raadt uit eigen ervaring een regelmatige controle aan voor de objectives en doelen van elk focusgebied. “Bijvoorbeeld elk kwartaal, dat geeft een goede cadans.” Zo’n regelmatig ritme geeft stabiliteit. Niet alleen voor de organisatie, maar ook voor de developers. Maar de controle moet ook weer niet te krap of te strikt zijn, want er is altijd flexibiliteit nodig wanneer de doelen veranderen. Soms moet je nu eenmaal de doelposten verplaatsen, om de voetbalmetafoor er weer even bij te halen.

Naast ruimte voor verandering is ook terughoudendheid nodig. Wanneer er teveel doelen en focusgebieden worden gesteld, leidt dat tot overdaad, verwarring en versplintering van de development inspanning. “Bij Atlassian hebben we ongeveer vier focusgebieden. Dat zou wel de algemene regel moeten zijn”, meent Peters. “Per kwartaal hebben we dan drie objectives.”

 

Sneller, beter, leuker

Zijn werk bij softwareleverancier Atlassian geeft hem een aparte blik op deze materie: Atlassian is namelijk ontwikkelaar van software voor ontwikkelaars. Peters gelooft er heilig in dat ontwikkelen niet alleen efficiënter en productiever kan, waarbij hogere kwaliteit sneller valt te realiseren. Hij gelooft er ook in dat dit developmentwerk leuk moet zijn: dat het developers moet inspireren en dus motiveren. Het moet wel leuk blijven, om succes op te kunnen leveren.

Het geheime recept voor succesvolle teams kent nog een belangrijk ingrediënt, dat volgt op diversiteit van teams, visie en kwartaaldoelen, flexibiliteit en terughoudendheid. Het volgende ingrediënt is ‘het proeven tijdens het koken’. “Bekijk je doelen! Kijk nog eens goed naar je kernelementen. Het gaat hierbij niet alleen om nieuwe technologie of verandering omwille van verandering. Is bijvoorbeeld je architectuur wellicht gewoon goed genoeg?”

 

Koerscorrecties

Het kritisch bekijken – en indien nodig herijken – van de doelen geldt op twee gebieden. Enerzijds voor de organisatiedoelen op de korte termijn en anderzijds voor de technische objectives, die deze korte termijn doelen moeten realiseren. Uiteindelijk gaat het om het grotere plaatje, dat vervat is in het lange termijn doel van de overkoepelende visie.

“Het varen op de Noordster mag soms best met een rukje naar links of rechts gebeuren”, legt Peters uit. “Zolang de algemene lijn van het kompas maar gevolgd wordt. Verandering mag, maar moet wel in overleg gebeuren. Met consensus binnen het betrokken team”, benadrukt de evangelist. Vaak is er geen duidelijke lijn in dit soort veranderprocessen. Er zijn simpelweg diverse projectmanagers, die elk om het hardst schreeuwen. “De luidste wint dan”, stelt Peters droogjes.

 

Mensen meekrijgen

Het nut van, nee: de noodzaak voor, keuring en aanpassing geldt zelfs voor de overkoepelende visie die de algemene koers bepaalt. “De richting waarin je als organisatie gaat, moet je ook kunnen veranderen. Je moet niet een jaar lang doorrennen”, in wat later de verkeerde richting kan blijken te zijn. Klinkt heel logisch, maar deze logica blijkt in de praktijk niet altijd toegepast.

Tot slot nog een ingrediënt om het geheime recept af te ronden: aandacht voor de menselijke factor. “Je moet een koersverandering wel uitleggen, om mensen mee te krijgen.” Want dat is de alfa en omega van succesvolle teams: de spelers die het samenspel soepel plegen. Zij moeten elkaar kennen, op elkaar vertrouwen, elkaar respecteren en daarbij ook nog eens open staan voor nieuwe aanwinsten. Want een verse transfer die niet warm wordt opgenomen in het team kan zijn of haar waarde niet waarmaken. Of dit nu een ‘gewoon goede’ programmeur is, een doortastende designer, of een mythische 10x rockstar developer.

 

 

“Developers zijn geen code monkeys”

Succesvolle teams van developers zijn een waardevol goed, maar dan ben je er nog niet. Om succes te continueren en uit te bouwen valt er verder werk te verrichten. Juist met ICT. “Er valt nog zoveel meer te automatiseren”, bezweert J-Fall 2016-spreker Sven Peters. “Meer dan alleen de automatisering van build-test-deploy.”
Sven vertelt enthousiast over de nieuwe mogelijkheden van softwarematige ontwikkelhulpjes voor developers. Digitale tools zorgen voor werkbesparing en ook voor werkversnelling. “Ik heb ooit in de Java Posse-podcast gehoord over een nieuw framework, dat voor automation zorgt: de Hudson server. Ik ben dat toen gaan uitproberen en die software stuurde me toen een magisch mailtje: een test was mislukt!”, zegt Peters blij.
Blijdschap over een mislukking? Jawel, want de developer had zelf niks gedaan: “Ik had alleen maar mijn code ingediend”. De development tool voor continuous integration heeft de code automatisch getest en vervolgens afgekeurd. Zonder handwerk aan de code, wat volgens Peters eigenlijk minder nodig moet zijn.
“Automatiseren kan en moet verder gaan.” Een simpele toepassing is bijvoorbeeld het blokkeren van code branches als er een bug in de master branch zit. Maar de grote meerwaarde zit in vergaande automatisering, zoals een bot die codekwaliteit checkt. “Elke codebase dijt uit, wordt ouder en is daarmee steeds moeilijker te overzien voor mensen. Toepassing van machine learning kan dergelijke computerhulp nog verder vergroten. Ja, software kan ook de softwaremakers helpen.”
“Misschien nemen bots straks delen van je baan over”, is zijn eerlijke boodschap aan developers. “Maar jij hebt dan tijd over voor het creëren van toegevoegde waarde voor de uiteindelijke klant.” En dáár zit nou weer de meerwaarde van moderne developers: geen simpele codekloppers, maar meedenkende doeners. “Developers zijn geen code monkeys”, vat Peters de moderne tijd samen.