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.
Bewuste technische schuld
Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.
Agile zijn, niet Agile doen
Heeft Agile gefaald? Of heeft Agile nooit écht een voet aan de grond gekregen? In Clean Agile pleit Robert “Uncle Bob” Martin voor dat laatste. Het succes van Agile is zowel een vloek als een zegen geweest. Een zegen, omdat het het inefficiënte Waterval heeft verdreven, maar een vloek omdat de kerngedachte achter Agile zo vaak verkeerd begrepen is dat deze geheel verloren dreigt te gaan. Clean Agile is zijn poging de vele misverstanden recht te zetten.
Is onze performancetest mislukt?
Het doel van de performancetest was niet om aan te tonen dat onze applicatie de load aankon. Het doel was om erachter te komen of onze applicatie de load aankon. Nu weten we het antwoord: nee. Men zegt niet voor niets: meten is weten, en niet: meten is slagen.
Wat is 'hetzelfde proces'?
Hoe verhoudt het proces zich tot de wens van de gebruiker? - En andersom? Is wat in wezen hetzelfde proces is, niet eigenlijk twee heel verschillende dingen? En hebben gebruikers die erop staan dat “dit echt iets totaal anders” is, het wel bij het juiste eind? Die vraag stellen is allesbehalve hem beantwoorden.
Slecht nieuws en Sprint Reviews
Natuurlijk, het liefst toon je tijdens een Sprint Review de coole nieuwe features die jij en je team deze Sprint gebouwd hebben. Maar helaas, niet elke Sprint verloopt even soepel. Obstakels van buitenaf kunnen het ontwikkelwerk verstoord hebben, of een feature kan groter blijken dan op voorhand werd gedacht. Wat doe je wanneer je deze Sprint Review geen blijde boodschap hebt om te verkondigen?
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.
Schorseneren en software architectuur
Een ontwerper van een systeem - of dat nu een kok is of een softwarearchitect - dient niet alleen rekening te houden met de functionele eigenschappen van zijn componenten. Smaak is niet alles! Een lekker ingrediënt kan om allerlei redenen niet in een gerecht terechtkomen. De impact van het ingrediënt op de afwasser - niet onbelangrijk! - kan dusdanig zijn dat het verstandig is om toch maar een ander smaakje te kiezen.
Tijd om te ontwerpen
Ik heb jarenlang als ontwikkelaar code kunnen kloppen zonder ooit maar één stroomdiagram te hoeven bekijken. Een grappig gegeven, want één van de eerste dingen die ik moest doen toen ik solliciteerde naar een traineeship als back end developer, was een cognitietaak waarbij ik steeds complexere stroomdiagrammen voor mijn neus kreeg. En om de indruk te wekken dat software ontwikkelen méér is dan alleen naar een scherm staren, moest ik dat doen in een ruimte behangen met foto’s van mensen die lachend naar whiteboards staan te wijzen.
Horizontale of verticale PBI's?
Een risico van horizontaal ontwikkelen is dat je veel tijd besteedt aan de back-end, om er vervolgens bij de implementatie van de front-end achter te komen dat je iets over het hoofd hebt gezien. Met als gevolg dat je alsnog verticaal aan het ontwikkelen slaat. Dat is niet alleen irritant, het is ook ontzettend inefficiënt!