Tag verandering
Het probleem met technische schuld op je backlog
Zo gaat mijn team om met het monitoren van technische schuld: we prikken elke Sprint een moment waarop we er met elkaar over praten, en als we het belangrijk genoeg vinden om er wat aan te doen, dan voeren we een Product Backlog Item op om die schuld weg te werken. Die aanpak werkt goed - goed genoeg, in elk geval. De technische schuld van onze huidige applicatie blijft grotendeels binnen de perken. En bovendien - dat is nog veel belangrijker - is iedereen in het team op de hoogte van het feit dat sommige plekken verbetering behoeven, en welke plekken dat zijn. Maar toch zit iets me niet helemaal lekker in die aanpak.
Wat is de O in SOLID nog waard?
Een ontwikkelaar die eens code schrijft en deze nooit meer aan denkt te hoeven passen, is een ontwikkelaar die rot in zijn applicatie verwelkomt. Een al te strikte naleving van het Open-closed principe (OCP) getuigt van een ronduit onverantwoorde houding - in elk geval binnen de context van Agile ontwikkeling. Waar komt de aantrekkingskracht van het OCP dan vandaan?
Eén test per keer
Ik hou niet van programmeerboeken die van me vragen dat ik onder het lezen code schrijf. Daar kan zo’n boek niks aan doen, ik houd er nu eenmaal van om een boekje op de bank te lezen, ver weg van mijn laptop. Voor één boek maak ik een uitzondering, en dat is Learning Test-Driven Development van Saleem Siddiqui. Dat boek draait namelijk niet om het eindproduct, de code. Het draait om het proces.
Over het hek van Chesterton
Ik ben niet vies van het refactoren van code die ik onduidelijk vind, of zelfs van weggooien van (meestal dode) code. Dat is een goede eigenschap wanneer je het met beleid doet en een slechte als het uit louter enthousiasme voorkomt. De eerste resulteert in helderder en eenvoudiger code, de tweede in buggy software. Waar zit hem precies het onderscheid in? Het antwoord vond ik in Software Engineering at Google in het hoofdstuk over kennisdeling.
Hoe Nooglers testen de norm maakten
Google greep haar snelle groei aan als kans. In plaats van zich te focussen op hun bestaande werknemersbestand, richtte het management ze zich op nieuwe medewerkers. Ze gaven deze nieuwe Googlers, liefkozend Nooglers genoemd, bij binnenkomst allemaal hetzelfde praatje over testen en het belang ervan. Ze gebruikten de Nooglers, buiten hun weten om, als Trojaans paard om een cultuurwijziging te bewerkstelligen.
Klimmen op de cultuurladder
Het succes van een organisatie is van een boel dingen afhankelijk. Eén van die dingen is de bedrijfscultuur. Een organisatie waarin hard werken de norm is, en het vanzelfsprekend is dat je als team staat voor je resultaten, zal beter presteren dan een cultuur waarin medewerkers doen wat er van hen gevraagd wordt en geen millimeter meer. Dus: hoe krijg je het voor elkaar om de juiste cultuur te kweken in je organisatie? Dat is de vraag die centraal staat in De Cultuurladder van Marcel van Wiggen, Gerard Vriens en Frits Galle.
Anderen veranderen met hun eigen argumenten
Alle verandering is moeilijk, maar anderen veranderen, dat is nog veel moeilijker. Toch zijn we vaak van anderen afhankelijk om te kunnen veranderen, bijvoorbeeld als je je collega’s aan wil sporen een nieuwe werkwijze uit te proberen. Of wanneer je als manager de opdracht hebt gekregen om een afdeling te reorganiseren. Er zijn boeken volgeschreven over verandermanagement op de werkvloer, Verandergedrag van organisatiepsycholoog en communicatiekundige Thijs Leenman is daar slechts één van.