Formuleer je kernwaarden

Hoe ziet softwareontwikkeling er – volgens jou – idealiter uit? Hoe functioneert een ontwikkelteam op de toppen van z’n kunnen? Wat is de verhouding tot hun stakeholders en collega’s? Hoe ondersteunt het management daarin? – Als je dat plaatje eenmaal scherp hebt, wat kun je dan concluderen over de kernwaarden van waaruit je software ontwikkelt?

Dat zijn belangrijke vragen om een antwoord op te formuleren. Want als je weet wat volgens jou goede softwareontwikkeling is, dan kun je in kaart brengen op welke punten je op dit moment nog tekortschiet.

Geradbraakt

Ik stelde deze oefening voor aan onze (inmiddels ex-)Scrum Master, nadat we ons een goed halfuur hadden verbaasd over de manier waarop sommige teams – niet het onze, gelukkig – worden gemanaged binnen de organisatie.¹

Sommige teams – niet het onze, gelukkig – worden geradbraakt: ze hollen van deadline naar deadline, snijden hoeken af om features op tijd te kunnen releasen maar krijgen (of nemen) niet de tijd om hun rommel op te ruimen. De problemen die ontstaan, probeert het management op te lossen met meer controle: het aantrekken van de teugels, het nauwkeuriger voorschrijven van hoe het team dient te werken, het afstoten van “optionele” zaken als Retrospectives, kennisdelingssessies of refactorslagen.

Een karikatuur van de werkelijkheid, ongetwijfeld, maar niet zonder kern van waarheid.

Meningsverschil

Het is verleidelijk om te concluderen: het management wil het proces niet op orde krijgen, het wil niet op een duurzame manier kwalitatief hoogwaardige software opleveren; het management wil deadlines halen en meer niet. Maar de ander kwade wil toeschrijven is, hoe lekker het ook voelt, te kort door de bocht. De kans is groter dat het management net zo graag goede software op wil leveren als de teams die ze radbraken, maar dat ze van mening verschillen over hoe je dat doel het best kunt bereiken.

Dit was mijn idee: laat de teams en het management apart van elkaar een antwoord op de bovenstaande vragen formuleren. Laat hen, op basis van hun ideaalbeeld van softwareontwikkeling, drie kernwaarden formuleren. Deze kernwaarden vormen de essentie van hoe de teams respectievelijk het management softwareontwikkeling zien. Het zijn zaken waar, in hun ogen, niet over gemarchandeerd kan worden. Alles wat zij doen om software te ontwikkelen moet binnen die kernwaarden passen.

Inzicht

Er zijn twee redenen om deze groepen hun kernwaarden te laten formuleren.

De eerste is om hen een verdedigingsmiddel te geven tegen de waan van de dag. Iemand die zich niet (voldoende) bewust is van datgene wat hij of zij écht belangrijk vindt, laat zich leiden – of: afleiden – door dat waarvan anderen zeggen dat het belangrijk is. Dat is, denk ik, waarom ik veel ontwikkelaars toe zie geven wanneer managers hen onder druk zetten snel code op te leveren tegen een lagere kwaliteitsstandaard.

Dat zal iemand die zijn kernwaarden op een rij heeft, minder snel gebeuren. Diegene herkent het wanneer er van hem wordt gevraagd iets te doen waar hij niet achter staat. Diegene kan zijn standpunt verdedigen, want hij weet wat hij wél wil en weet waarom het huidige voorstel daar niet mee verenigbaar is.

Begrip

De tweede reden is het kweken van wederzijds begrip. Stel, de ontwikkelteams en het management hebben hun eigen kernwaarden opgesteld. Ze hebben – voor de ander net zo goed als voor zichzelf – een expliciet overzicht gecreëerd van dat wat zij belangrijk vinden. Dat is waardevolle informatie wanneer beide groepen met elkaar botsen.

Omdat je inzicht hebt in de waarden die voor- en tegenargumenten informeren, wordt het makkelijker om afwegingen te maken. Het is niet langer het ene woord tegen het andere. Als je weet waar iemand vandaan komt, dan dicteert onbegrip niet langer je reactie.

Een voorbeeld. “Je wil graag dat deze feature zo snel mogelijk gereleast wordt, omdat je het belangrijk vindt om snel waarde te kunnen leveren voor de klant. Dat vind ik ook. Maar toch pleit ik ervoor nog even langer hieraan te blijven sleutelen, want ik wil morgen net zo snel waarde kunnen leveren als vandaag – en dat kan alleen als we niet beknibbelen op de kwaliteit. De feature in zijn huidige vorm is nog niet productierijp.”

Geheel

Maar dit is niet waar het verhaal eindigt. De volgende stap zou zijn: overeenstemming bereiken over de kernwaarden als geheel – dus voor de ontwikkelteams én het management. Nu beide van elkaar weten waar ze staan, kunnen ze aan een gezamenlijke visie van softwareontwikkeling werken, waarin hun beider belangen zo goed mogelijk naar voren komen.

Ze zouden gezamenlijk een manifest op kunnen stellen waarin duidelijk naar voren komt welke waarden ze hoog willen houden in hun werk. En: welke waarden voorrang hebben op andere, want in de echte wereld willen die dingen nogal eens botsen. Stel dat waarde x een voorstel a motiveert, maar dat deze conflicteert met waarde y, en we hebben als geheel besloten dat waarde y hoger staat dan waarde x, dan moeten we a in zijn huidige vorm verwerpen.

Gedeelde taal

Het geeft ontwikkelaars en managers en gedeelde taal waarmee ze elkaar verantwoordelijk kunnen houden. “Wij als afdeling – en jij dus ook, manager! – vinden kwaliteit belangrijk, maar je pleit er nu voor om hoeken af te snijden om een deadline te halen. Dat gaan we niet doen: we kunnen in plaats daarvan beter de scope aanpassen.” Of: “Wij als afdeling – dus ook jij, ontwikkelaar! – vinden het belangrijk elkaars werk over te kunnen nemen, dus we moeten ons ver houden van deze complexe oplossingsrichting die jij als enige teamlid begrijpt.”

Begrijp me niet verkeerd: het doel is niet elkaar de maat te nemen. Het doel is te kunnen identificeren wanneer we werkwijzen of oplossingen introduceren die niet in lijn zijn met dat wat we als afdeling belangrijk vinden. Alleen dan kunnen we samen werkwijzen en oplossingen te vinden die dat wél zijn.

Idealisatie

Natuurlijk, ik ben de eerste die toegeeft dat het bovenstaande is gebaseerd op idealisatie. Is het formuleren van kernwaarden voldoende om sommige ontwikkelteams – niet het onze, gelukkig – uit het hamsterwiel van deadline naar deadline te halen? Zeer zeker niet. Maar het zou een eerste stap kunnen zijn.

En als het aan het eind van de dag allemaal niets heeft mogen baten, dan hebben we in elk geval iets geleerd over wat we belangrijk vinden als we softwareontwikkelen, zelfs al handelen we er niet naar.

---

1. Het vertrek van onze Scrum Master stond overigens volledig los van haar moeizame relatie tot het management; ze was aangenomen ad interim. ↩︎

communicatie · empathie · kernwaarden · management · procesverbetering · teamcultuur · verantwoordelijkheid · werkplezier