Principe: Gereedschap eerst
Gereedschap eerst is het principe dat je eerst moet zorgen dat je effectief kúnt veranderen, opleveren of bouwen. Investeer eerst in je eigen vermogen om te veranderen: het gereedschap, de pipeline, de vaardigheid. Ga daarna pas aan de slag met de inhoud die je eigenlijk wilde opleveren.
Wereldbeeld en context
Als je wilt veranderen, moet je eerst zorgen dat je kúnt veranderen. Investeren in het vermogen om te veranderen gaat vooraf aan de verandering zelf. Dat voelt vaak als vertraging. Maar het maakt juist de versnelling erna mogelijk.
Ook in de timmerambacht is dit een gebruikelijke benadering. Een timmerman maakt eerst zijn eigen (houten) hamer. Die gebruikt hij vervolgens bij het maken van alle werkstukken die daarna komen. Dat is een praktische variant van de bekende volkswijsheid van houthakkers, vaak (ten onrechte) toegeschreven aan Abraham Lincoln: als ik een paar uur heb om een boom te kappen, besteed ik het grootste deel van die tijd aan het slijpen van de bijl. Die wijsheid komt niet van Lincoln, maar van generaties houthakkers vóór hem (Quote Investigator – oorsprong van het bijl-citaat). Dat maakt het eigenlijk sterker: het is beproefde vakkennis, geen aforisme.
Stephen Covey formaliseerde dit tot een gewoonte in The 7 Habits of Highly Effective People: “Sharpen the Saw” (gewoonte 7). Zijn parabel is bijna letterlijk de houthakker hierboven. Iemand zaagt zich koortsachtig door een boom heen. Stel je voor de zaag even te slijpen, dan zegt hij “geen tijd om de zaag te slijpen” en zaagt nog harder door. Covey’s gewoonte gaat verder dan het gereedschap zelf. Hij onderscheidt vier dimensies van zelfvernieuwing: lichamelijk, mentaal, sociaal-emotioneel en spiritueel. Die hebben allemaal onderhoud nodig om op de lange termijn effectief te blijven. Zoals hij het zelf verwoordt: “Renewal is the principle — and the process — that empowers us to move on an upward spiral of growth and change, of continuous improvement” (FranklinCovey – Habit 7: Sharpen the Saw).
In softwareontwikkeling geldt hetzelfde. Zorg eerst voor eigen efficiëntie, eigen lokale scripts en een goed ingerichte lokale ontwikkelomgeving. Bouw en lever daarna pas de software zelf op. Kent Beck vat dit scherp samen: “for each desired change, make the change easy (warning: this may be hard), then make the easy change” (Kent Beck – Tidy First Example). Eerst maak je de verandering makkelijk. Dan pas voer je de (nu makkelijke) verandering door.
Dit is ook zichtbaar op teamniveau. Henrik Kniberg’s bekende “Spotify Engineering Culture”-video’s (2014) beschrijven naast feature squads ook infrastructuur-/platformteams. Die bouwen self-service tools en voorzieningen, onder meer voor Continuous Delivery. Zo kunnen de feature-teams zelf snel en zelfstandig opleveren (Spotify Engineering Culture, part 1 – Henrik Kniberg). Het platformteam bouwt het gereedschap. De feature-teams bouwen daarmee. Dat is dezelfde volgorde als bij de timmerman en de hamer, nu op organisatieniveau.
Het principe
Voordat je gaat veranderen, opleveren of bouwen: zorg eerst dat je dat effectief kúnt. Investeer eerst in je eigen vermogen om te veranderen: het gereedschap, de pipeline, de vaardigheid. Ga daarna pas aan de slag met de inhoud die je eigenlijk wilde opleveren.
Consequenties
Het principe zelf is universeel. Wat het betekent, verschilt per domein.
Algemeen / vakmanschap – voordat je aan een werkstuk begint: investeer in het gereedschap en de vaardigheid om dat werkstuk goed te kunnen maken. Dat voelt als tijd die niet direct aan het eindresultaat besteed wordt. Maar zonder die investering duurt al het latere werk langer, of mislukt het.
Architectuur / softwareontwikkeling – bouw eerst de pipeline, de lokale ontwikkelomgeving en de eigen scripts die het mogelijk maken om snel en veilig te veranderen. Doe dat vóórdat je de eerste feature bouwt. Dat is geen vertraging, maar een investering. Dit heb ik zelf zo toegepast bij KOERS, de vervanging van het 40 jaar oude Kadaster-mainframe. Voordat er ook maar één stuk business-functionaliteit werd gebouwd, is eerst een Continuous Delivery-pipeline naar een Platform-as-a-Service opgezet. Dat maakte de daaropvolgende vier jaar aan opleveringen mogelijk. Toets nieuw werk aan een vraag: kan ik dit al makkelijk veranderen? Zo niet, maak dan eerst de verandering makkelijk, voordat je de verandering zelf doorvoert. Op teamniveau vertaalt dit zich naar de taak van een platformteam. Dat bouwt niet zelf de business-features, maar zorgt ervoor dat de feature-teams dat snel en zelfstandig kunnen. Precies zoals Spotify’s infrastructuurteams self-service Continuous Delivery bouwden voor de feature squads.