Kan je cultuur veranderen met een compliment?

Het bedrijf is continu in beweging, er gaat een collega weg, en komt een andere collega voor in de plaats. Het bedrijf groeit, er komt een nieuw team bij, nieuwe collega’s komen in dit nieuwe team, aangevuld met een aantal ‘langer zittenden’ uit reeds bestaande teams. De bestaande teams worden weer aangevuld met wederom nieuwe collega’s. Maar niet alleen de teams wijzigen, ook de code wijzigt, de grote bak met programmacode (de monoliet) wordt beetje bij beetje uit elkaar getrokken zodat losse onderdelen makkelijker aangepast kunnen worden en los van de andere onderdelen gedeployed zouden kunnen worden, en uiteindelijk komen we dan bij het punt aan waarbij DevOps wordt genoemd. Het hing al een tijdje in de lucht, maar nu begint het te gonsen en even later krijgen alle teams een uitnodiging om per 2 teams hierover samen na te denken.

Na wat uitleg wordt ons de vraag gesteld: ‘Wat staat ons in de weg om komende maandag DevOps te zijn/doen?’.

Iedereen pakt stickies en begint te schrijven. “de juiste tooling mist”, schrijft de een, “Standby regeling”, schrijft de ander. Even later hangt de muur vol met stickies en nadat deze nog eens gesorteerd zijn op ‘moet maandag geregeld zijn’ en ‘moet geregeld worden, maar kan ook later dan maandag’, is het wel duidelijk dat we komende maandag nog geen DevOps zijn. Het mooie is echter wel dat iedereen er over nadenkt en dat er een lijst is met punten die we dus moeten gaan regelen.

Nu was dit alleen nog maar de input van deze 2 teams, maar er zijn nog meer teams met input. De lijst wordt dus nog langer. Het meest opvallende sticky komt overigens vanuit een ander team: “De testers moeten weg”… Daarover later wellicht meer.

Onlangs hadden we een tweede meeting waarbij er gekeken werd wat nu uiteindelijk in de kolom van ‘moet per maandag geregeld zijn’ stond en waarbij er gekeken werd hoe we die punten op zouden kunnen pakken.

In de tussentijd gaat het gewone werk echter ook door, ‘de winkel moet immers wel open blijven’ en deze week hadden alle teams hun teamretrospective gehad en kwamen de teamoverstijgende punten daaruit op tafel bij dat wat wij de overall-retro noemen.

In totaal lagen er iets van 14 punten die gepitched werden. Daarna doen we dot-voting waarbij iedereen 3 stippen kan zetten op 1 of meerdere onderwerpen die hij van belang vindt. Daarna worden de onderwerpen op volgorde gelegd van aantal stippen en worden deze met een timebox afgewerkt. Nadat de timebox van een issue afgelopen is, bepalen we dan of het onderwerp voldoende behandeld is en eventuele acties etc bekend zijn, of dat we nog wat meer tijd willen voor dit onderwerp.

Normaal lukt het ons om in de tijd alle onderwerpen te bespreken. Nu kwamen we niet verder dan 4 onderwerpen. What’s up?

Cultuur, that’s up!

Meerdere onderwerpen hadden te maken met een stroef verlopen release. Uiteindelijk is alles op z’n pootjes terechtgekomen, maar daarvoor was wel inzet nodig van een aantal mensen die iets verder keken dan hun eigen team, of eigen sprint. En terwijl de een de ander daarvoor prijst, wordt diezelfde persoon er door iemand anders juist op aangesproken.

Het is het verhaal wat ik vaker langs zie komen en eigenlijk heel interessant vind om te aanschouwen. Iemand is klaar met zijn softwarewijzigingen en start daarbij een pipeline op. Hierbij worden een aantal stappen uitgevoerd, waaronder een hele serie geautomatiseerde tests (of beter: checks). Als een of meerdere checks niet slagen, worden die afzonderlijk nog een keer automatisch gerund. Als dan nog steeds niet alle checks geslaagd zijn, dan wordt de merge van die software tegengehouden. Op dit moment wordt er nog gewerkt met een 2 wekelijkse sprint en aan het eind van die sprint wordt gekeken naar de laatste ‘groene build’ en die zal (na nog wat extra controles) live gaan. De softwarewijziging waarbij net niet alle tests geslaagd zijn, leverde geen ‘groene build’ op en die wijziging werd dus geweigerd en zal dus niet in de op te leveren release zitten. Hier moet dus actie worden ondernomen.

Wat er nu gaat gebeuren, kan je volgens mij nog het beste onder Cultuur vatten. Een aantal mogelijkheden:

  • Analyse van de gefaalde test(s). Is het iets wat door onze (zojuist geweigerde) wijziging komt en waar andere teams dus geen last van zullen hebben, of is het iets groters en zullen alle teams nu niet kunnen mergen? (bijvoorbeeld iets stuk in de pipeline, iets uit de lucht waardoor alle teams falende tests zullen krijgen etc). In het eerste geval blijft het bij het team en die zal nagaan wat er aan de hand is, andere teams kunnen in de tussentijd gewoon verder en eventueel mergen. In het tweede geval zal het team een bericht posten op de chat dat de pipeline ‘stuk’ is en dat zij ernaar kijken. Andere teams weten op dat moment dat zij dus even moeten wachten met het aanbieden van hun wijzigingen.
  • De merge is niet gelukt, we starten hem gewoon nog een keer, waarschijnlijk was het een hikje.
  • De merge is niet gelukt, maar ik zie dat hij gefaald is op een test die eigenlijk niets met mijn wijziging te maken kan hebben. Da’s raar, eens kijken wat er aan de hand is en of ik hem misschien wat stabieler kan maken
  • De merge is niet gelukt, maar ik zie dat hij gefaald is op een test die absoluut niet met mijn wijzging te maken kan hebben dus ga ik er ook niets mee doen
  • De merge is niet gelukt, mond houden en verder gaan met andere werkzaamheden, als een volgend team ook niet kan mergen, dan pakt die het hopelijk wel op
  • De merge was niet gelukt, maar ik zie dat de merge ervoor ook niet gelukt was, dus dat team zal er wel mee bezig zijn
  • Ik laat het even voor wat het is, als een ander team bezig is met hun wijziging, dan gooi ik meteen die van mij er achteraan. Als die eerste faalt, dan mogen zij het oplossen, als die van hun wel slaagt, dan is de kans groot dat die van mij ook slaagt.

Het is maar een aantal van de mogelijkheden en ik heb ze allemaal langs zien komen.

Zelf ben ik (te?) erg van de instelling dat we met z’n allen proberen een mooi eindproduct te maken dus als iemand bij mij komt met een melding ‘hij gaat stuk, maar het kan niet door mijn code komen, kan jij kijken?’, dan ga ik helpen. Ik vraag wat hij al heeft uitgezocht en ga daarna verder. Er zijn er echter ook die in zo’n opmerking horen “hij gaat stuk, dat komt niet door mij, en ik klopt bij jou aan want jij hebt het dus blijkbaar stukgemaakt”. Dat klinkt misschien als een rare gedachte voor velen, maar zo wordt er in praktijk wel gedacht en, als je vraagt waarom, ook wel met goeie redenen. Het gevolg is echter wel dat die persoon sneller zal zeggen ‘ik heb geen tijd’. Wat door de ander opgevat kan worden als ‘hij heeft echt geen tijd, ik ga kijken of iemand anders kan helpen’, of ‘krijg nu de hik, ik ben al de hele dag bezig met iets waar ik ook geen tijd voor heb en als ik hulp vraag, dan heeft hij geen tijd, nou, dan stop ik er ook mee en ga ik weer verder met datgene wat ik zou moeten doen, de rest van mijn sprint, bekijk het maar”. Actie, reactie.

De opmerking van beide personen, die van ‘ik heb hier (ook) geen tijd voor’, is in dit verhaal echter wel een belangrijke opmerking. Het geeft namelijk aan dat beiden op dat moment in zekere mate vinden dat de sprint van hun team belangrijker is dan de pipeline die ervoor zorgt dat het gemaakte ook echt in productie komt. En die gedachte is ook niet zo gek, want soms wordt een persoon, die buiten zijn sprint kijkt en de pipeline fixt, ‘beloont’ door leden uit andere teams voor zijn inzet, maar een andere keer wordt diezelfde persoon er op aangesproken (bijvoorbeeld door zijn eigen teamleden, of een productowner) dat hij zich niet genoeg focust op zijn eigen sprint waardoor de velocity omlaag gaat en de sprint wellicht niet gehaald wordt…

Dat kwam dus ook in onze overall-retro terug en het blijkt herkenbaar te zijn. Er worden stories geduwd en de randzaken er omheen worden daarbij wellicht wat vergeten. “Hoe kunnen we dat veranderen?”, wordt er gevraagd en iedereen is het over eens dat het een stukje cultuur is. Ik opper ‘complimenten geven’ en leg uit wat ik daarmee bedoel. Voorheen hadden we een chatprogramma waarin ‘karma-punten’ zat. Als iemand iets deed waar je blij mee was, dan kon je die persoon een karma-punt geven. Dat was voor iedereen zichtbaar in het chatprogramma, en er werd getoond hoeveel punten die persoon in totaal had. Wat die persoon daarmee kon? Helemaal niets. Het is dus puur een digitale manier van aangeven ‘jij bent goed bezig’, iemand even in het zonnetje zetten, een compliment geven. Onlangs zijn we echter over gegaan naar een ander chatprogramma waar deze plugin niet zit. En om nou een openbaar bericht te gaan sturen met ‘nou nou, jij bent goed bezig, hierbij zet ik jou in het zonnetje, mijn complimenten’, dat gaat blijkbaar net even wat te ver, dus doet iedereen nu zijn ding en daar blijft het bij. Daarmee mis je echter ook die virtuele schouderklop en, en dat is denk ik nog wel het belangrijkste, het aangeven van ‘dat wat wij belangrijk vinden’, de cultuur.

Wat je namelijk indirect doet met zo’n karma-punt, of het geven van een openbaar compliment, is aangeven dat je waardeert wat die persoon doet. Dat wat jij doet, dat vind ik oké. Iemand laat zijn sprint even voor wat het is om de pipeline te fixen, en krijgt daardoor meteen uit meerdere hoeken een karma-punt aangeboden, is een indicatie dat ‘we’ dat waarderen. Als iemand zegt ‘ik ga die pipeline niet fixen, want ik vind mijn huidige sprint belangrijker en wil dat alle stories af zijn’ en daar komen geen karma-punten op, dan geeft dat indirect aan dat we dat dus misschien niet de juiste werkwijze vinden.

Uiteraard is het geven van een punt niet de oplossing van alles, maar mijn ervaring is dat een simpel iets als het geven van een compliment meer gedragsverandering teweeg brengt dan een opgelegde afspraak.

Zeg eens eerlijk, wanneer gaf jij voor het laatst een compliment?