Het succes van bedrijven is tegenwoordig net zo geworteld in het succes van ontwikkelteams als in de prestaties van elke andere business unit. Zoals Satya Nadella van Microsoft in 2015 zei: “Alle bedrijven zijn softwarebedrijven.” Het begrijpen en implementeren van best practices om ervoor te zorgen dat teams floreren en zeer effectief werken, wordt dus een zakelijke noodzaak. Tijdens Snykcon 2021 hebben wij een aantal experts uit de branche uitgenodigd om hun advies te geven over hoe we het beste uit ontwikkelaars kunnen halen.
Door Simon Maple, Field CTO, Snyk
De belangrijkste factor
Suzie Prince, Head of Product voor DevOps bij Atlassian merkte een belangrijke bevinding in het baanbrekende onderzoekswerk van DORA (DevOps Research and Assessment) op: dat de best presterende ontwikkelteams van de meest succesvolle bedrijven een belangrijke factor gemeen hebben. Dit was niet het aantal PhD’s, personeelniveaus, extra’s of beloningen. Wat ze ontdekten was dat de meest succesvolle ontwikkelteams een aanzienlijke onafhankelijkheid en vrijheid hebben in hoe ze werken.
Deze autonomie is niet absoluut – we hebben het niet over ontwikkelaars die opdagen wanneer ze maar willen, of dat elk individu een ander pad volgt, werkend aan wat ze maar willen, wanneer ze maar zin hebben.
Onafhankelijkheid en een hoog vertrouwen leiden objectief gezien tot betere resultaten
Succesvolle teams zijn juist in staat om uitdagingen en problemen op hun eigen manier aan te pakken en zichzelf zo te organiseren om de beste resultaten te behalen. Ontwikkelaars hoeven niet gemicromanaged te worden en zullen niet floreren als andere mensen over hun schouder meekijken. Onafhankelijkheid en een hoog vertrouwen leiden objectief gezien tot betere resultaten, zo blijkt uit het onderzoek.
In deze context wordt het de taak van het management om de doelen, principes en vangrails vast te stellen die ontwikkelaars in staat stellen te begrijpen wat ze moeten bereiken, wat hun prioriteiten zouden moeten zijn en de grenzen van wat ze zouden moeten doen. Zoals Gareth Rushgrove, VP Product bij Snyk, opmerkt, is het voor organisaties moeilijk om de perfecte balans tussen richting en autonomie te vinden, en moet er een bereidheid zijn om te veranderen: “Er is een cyclus aan het spelen tussen centralisatie en decentralisatie. Tussen besluitvorming in een ivoren toren en die besluitvorming doorschuiven naar teams.”
Het vaststellen, communiceren en beoordelen van de voortgang aan deze doelen en principes is moeilijk. Maar er zijn zeker enkele best practices die waarde kunnen toevoegen voor organisaties.
Ken je grenzen
Tamar Yehoshua, Chief Product Officer bij Slack, behandelde dit onderwerp. Om eerst de vangrails te bedekken, is het belangrijk om ontwikkelaars te helpen de grenzen van hun vrijheid te begrijpen. Dit zijn zeer slimme en creatieve mensen, en hun vaardigheden zorgen ervoor dat ze vaak kunnen bedenken hoe een applicatie beter zou kunnen zijn, of meer functionaliteit voor de gebruikers zou kunnen bieden. Vaak zijn deze ideeën precies wat het bedrijf wil. Maar veranderingen moeten worden beoordeeld aan de hand van productprincipes en effecten op langere termijn.
Tijdens haar tijd bij Amazon beschreef Tamar hoe experimenten en veranderingen van ontwikkelaars soms werden beschreven als ‘eenrichtings’- of ’tweerichtingsdeuren’. Sommige wijzigingen kunnen worden uitgeprobeerd, beoordeeld en gemakkelijk teruggedraaid als ze ongewenste gevolgen hebben. Dit zijn het soort experimenten dat ontwikkelaars actief moeten stimuleren om na te streven. Andere wijzigingen, ‘eenrichtingsdeuren’, zijn veel moeilijker te herzien, zeker als je gebruikers bijvoorbeeld nieuwe features of functionaliteit aanbiedt. Het uitschakelen van dergelijke functies kan erg impopulair zijn en het nastreven van dergelijke veranderingen moet zorgvuldig worden beoordeeld.
Als een functie niet voor de hand ligt hoort het niet in de software
Hou vast aan je principes
Dit maakt doelen en principes erg waardevol. Slack heeft bijvoorbeeld een ‘masterplan’ met vier kernprincipes die sinds 2014 ongewijzigd zijn gebleven. De eerste is ‘don’t make me think’: als een functie niet voor de hand ligt of te verklaren is, of gebruikers het gevoel geeft dom te zijn omdat ze er niet snel achter kunnen komen hoe ze het moeten gebruiken, dan hoort het niet in de software. Master-productprincipes worden zo een zeer eenvoudige en duidelijke maatstaf voor het beoordelen van elke voorgestelde wijziging.
Productstrategie en -principes moeten voortdurend en consistent worden verwoord, omdat ze voortdurend als leidraad dienen voor onafhankelijke besluitvorming. Volgens de president van Snyk, Guy Podjarny, bestaat er niet zoiets als overdreven deze principes publiekelijk herhalen: “Je zou kunnen denken dat je de strategie al tien keer hebt herhaald, maar het blijkt dat je het niet genoeg of niet correct hebt gezegd.” Het zal bijna altijd mogelijk zijn om mensen te vinden die zeggen dat ze de strategie van het bedrijf niet begrijpen.
En veel technologiebedrijven groeien heel snel: als de strategie maar één keer per jaar wordt uitgesproken, heeft de helft van het bedrijf er misschien nog nooit van gehoord wanneer er een paar maanden voorbij zijn. Indoctrinatie in de strategie en productprincipes moet worden ingebouwd in de on-boarding. Het is ook belangrijk om ervoor te zorgen dat actieve luistertechnieken worden toegepast. Mensen halen verrassend weinig uit passief luisteren naar een presentatie, merkt Tamar op, maar als ze de stof in eigen woorden moeten uitleggen, dan zijn ze actief bezig met het verwerken en dus vasthouden van de informatie.
Focus op het einddoel
De taal van deze principes moet duidelijk, ondubbelzinnig en gemakkelijk in het geheugen worden vastgelegd. ‘Don’t make me think’ is daar een voorbeeld van. Omdat het zo eenvoudig is, is het ook gedenkwaardig. Een ander voorbeeld uit Tamars tijd bij Amazon, toen het werd geleid door Jeff Bezos, was een intense focus op ’time to glass’. Ze zeiden niet ‘latency verminderen’ – wat de focus op technologie zou hebben gelegd. In plaats daarvan richt ’time to glass’ zich op het einddoel, een verbeterde gebruikerservaring.
Het is ook belangrijk om deze doelen en principes op te nemen in team- en individuele OKR’s (Objectives and Key Results). Dit versterkt de kracht van die principes, dat ze niet alleen leuk zijn om te hebben, of iets extra’s, maar echt prioriteit hebben voor het management. Als OKR’s standaard minder strategische maatregelen nemen, zoals het aantal gesloten tickets of code-commits, ondermijnt dit de strategie en vermindert het het vermogen van ontwikkelaars om zich autonoom te gedragen.
Autonomie moet zich ook uitstrekken tot tooling, merkte Suzie op. Doorgaans zullen ontwikkelaars de tools gebruiken die hen in staat stellen productiever te zijn, het werk gemakkelijker te maken en betrouwbare automatisering mogelijk te maken. Dit zijn allemaal wenselijke dingen voor het bedrijf als geheel, en kunnen betekenen dat verschillende individuen tot op zekere hoogte verschillende tools gebruiken. Zolang dit andere teamleden niet belet om effectief samen te werken, zal het ondersteunen van individuele voorkeuren een boost zijn voor productiviteit en werkgeluk.
Security en vrijheid
Het uitbreiden van deze ideeën naar de securitypraktijk heeft enkele kleine complicaties. Goede security is in sommige opzichten onzichtbaar. De code is gecontroleerd op mogelijke zwakke punten; componenten zijn zorgvuldig gescand op kwetsbaarheden, de cloud- en containerconfiguratie volgt de beste praktijken – en er gebeurt niets. Applicatiesecurity bevindt zich in de ongelukkige positie dat het vaak pas wordt opgemerkt als er iets misgaat.
In dit geval wordt het belangrijk om het harde werk te erkennen dat nodig is om ervoor te zorgen dat de applicatie beveiligd is. Dat de timing en grondigheid van controles en het elimineren van problemen volledig worden erkend: dat de afwezigheid van fouten net zo belangrijk is als het toevoegen van functies. Dit verschilt van veel ander werk omdat het niet zichtbaar iets nieuws toevoegt en de positieve voordelen van veilige code moeilijk te beoordelen zijn. Het is het beste om hier een licht te werpen op best practices: erken het verrichte werk en beoordeel de waarde ervan voor het bedrijf in termen van de verliezen die zouden ontstaan als de security in gevaar zou komen. Dit is al gebruikelijk bij het begrijpen van de ROI van cybersecurity en zou moeten worden uitgebreid tot de erkenning en prioritering van het werk dat is gedaan .
Tegenwoordig erkennen we dat creativiteit en verbeeldingskracht de belangrijkste aspecten van het ambacht zijn
Code-ontwikkeling is soms behandeld als een daad van fysieke productie. Mensen zijn beoordeeld op de hoeveelheid code die ze produceren, alsof het maken van een applicatie vergelijkbaar was met het assembleren van componenten op een productielijn.
Tegenwoordig erkennen we dat creativiteit en verbeeldingskracht de belangrijkste aspecten van het ambacht zijn. En dat het begrijpen en oplossen van problemen en het behalen van doelen op hoog niveau een grotere strategische waarde heeft dan het produceren van honderden regels code. De rol van het management is dus om ontwikkelaars te helpen hun beste, meest creatieve en vindingrijke werk te doen, afgestemd op de breedste doelen voor de applicatie. Het definiëren en communiceren van strategische doelstellingen, verwachtingen, beperkingen en principes wordt de belangrijkste taak voor het management.
> LEES MEER BLOGS
Volg Security Management op LinkedIn