Overdreven transparant zijn
Assumption is the mother of all fuckups.
We kennen allemaal die bekende afbeelding op het internet over wat we willen, wat we denken dat we willen en wat we uiteindelijk krijgen. Kortom, iedereen maakt aannames en bouwt gewoon naar beste kunnen. Al die mensen werken hard, hebben verwachtingen en proberen die waar te maken.
In mijn carrière als software-engineer heb ik inmiddels het verschil ervaren tussen overdreven transparant zijn—elke dag vooruitgang laten zien aan iedereen—versus pas na zes maanden ontwikkeling iets tonen. Raad eens welke aanpak het beste eindproduct opleverde voor onze klanten?
Het team dat zich zes maanden opsloot in een kelder en daarna een demo gaf, natuurlijk! Nee, niet echt. Elke keer dat ik deel uitmaakte van een team dat demo’s, catch-ups en afstemming uitstelde—oftewel feedback uit de weg ging—en alleen een zogenaamd perfect eindresultaat wilde tonen, zag ik teleurstelling.
De klant of stakeholder, omdat hij na lange tijd eindelijk werkende software te zien kreeg, maar inmiddels nieuwe inzichten had opgedaan waardoor het niet meer helemaal was wat hij wilde. Het ontwikkelteam, omdat ze keihard hadden gewerkt en de klant niet super enthousiast was. Dan begon de lange lijst met bugs en issues die opgelost moesten worden om het product daadwerkelijk bruikbaar te maken. Nog eens zes maanden later werd het eindelijk gelanceerd, en niemand voelde er nog enige liefde voor.
Scrum, agile… beter, maar niet goed genoeg
We werken tegenwoordig volgens het scrum-agile model: elke twee sprints een demo. Beter, toch? Ja, maar niet goed genoeg. Software is een levend iets. Het zo snel mogelijk in de handen van je klanten krijgen is prioriteit nummer één. Hoe doen we dat?
✅ Zorg voor een pipeline ⚙️ die software zo snel mogelijk bij de klant krijgt
✅ Houd je software altijd in een releasable staat
✅ Release meerdere keren per week voor iedereen die betrokken is! 🤩
Bouw een relatie op met iedereen die aan het product werkt en zorg dat ze voelen dat het leeft en continu verbetert. Marketeers, managers, testers, developers, product owners, helpdesk—iedereen. Zorg dat er altijd een versie klaarstaat en lever, lever, lever. Je ZULT feedback krijgen. En dat is mijn grootste les. Directe feedback verbetert leren, inzicht en stelt je in staat om snel aanpassingen te maken. Zo krijg je op elk moment het best mogelijke product voor je klanten.
Van voorzichtigheid naar radicale transparantie
Hoe gingen we van "voorzichtig zijn met wat we tonen" naar totale transparantie over de staat van onze software?
Toen we begonnen bij NS (Nederlandse Spoorwegen), heerste er overal angst. Angst om een nieuwe versie uit te brengen, omdat klanten of stakeholders negatief zouden kunnen reageren. Het releasen van nieuwe versies van de Reisplanner was ingewikkeld en kostte te veel tijd en moeite. Twee jaar later was alles anders: we hadden het vertrouwen om releases te doen wanneer we maar wilden. We brachten bijna dagelijks updates uit. (Zowel backends als mobiele apps, en ja, Apple’s reviewteam moet ons echt gehaat hebben 😜).
De aanpak was simpel:
📲 Zorg dat iedereen in de organisatie toegang heeft tot testversies (omdat het eindproduct een app was)
👥 Laat iedereen meedoen aan intern testen, zolang ze feedback geven
🧑💻 Laat externe testers meedoen en geef hen feature-completere versies
🙋♀️ Betrek mensen bij features, of ze nu bestaand of nieuw zijn
🏎️ Doe snel iets met feedback!
🤝 Wees benaderbaar—heb direct contact met interne en externe gebruikers
✅ Fix het, pas het aan, of leg het uit—maar DOE iets, wacht niet
🔦 Blijf leren en verbeter het product continu
Omdat het product al in ieders handen was, waren er geen verrassingen meer. Iedereen wist op elk moment hoe het ervoor stond. Door deze openheid en het vertrouwen (vertrouwen, omdat we echt iets deden met feedback en in dialoog bleven) konden we releasen wanneer we maar wilden.