Authority inversion en deadlines, een zegen en een straf

Er zijn van die momenten dat je als software-engineer, architect, projectleider of willekeurig welke andere rol geconfronteerd wordt met een schijnbaar onneembare muur. Die muur heet de persoonlijke voorkeur van een verantwoordelijk manager – vaak een projectleider, disciplinemanager, divisiedirecteur of programmamanager. Net als ieder ander zijn deze mensen heel gevoelig voor veranderingen en hebben ze ook een natuurlijke aversie daartegen. Heel vervelend als je een nieuwe manier van werken, een nieuw platform of een nieuwe softwarearchitectuur wilt gaan toepassen. Naast argumenten als tijd en budget, waar met enig rekenwerk wel omheen te komen is, gaan dan opeens argumenten als ’We hebben het altijd zo gedaan‘ en ’Wat gaat dit over een jaar opleveren?‘ een rol spelen. Vragen die vaak niet zo concreet zijn te beantwoorden, ofwel omdat de antwoorden moeilijk kwantificeerbaar zijn, ofwel omdat we domweg niet nauwkeurig genoeg in de toekomst kunnen kijken. Daarnaast is het heel moeilijk om iemand die een beperkte scope heeft van alleen een project of programma warm te laten lopen voor iets dat daarbuiten gaat.

Een manier om daaromheen te komen, is wat we wel authority inversion noemen. Waar we in software processen tijdelijk een hogere prioriteit geven door priority inversion toe te passen, kunnen we bij het managen van softwareontwikkeling hetzelfde doen, zij het op een ietwat omslachtige manier. Zo kun je als architect de blokkade van een projectmanager omzeilen door een programmamanager in te schakelen. Iets wat interessant is voor een programma op langere termijn met meerdere projecten of producten zal deze programmamanager wel aanspreken, terwijl het voor een projectleider enkel overhead voor zijn project betekent. Door de programmamanager te paaien, kun je organiseren dat die gaat vertellen wat hij verwacht – en dat is dan precies wat jij hebt gevraagd. De autoriteit in de organisatie ligt daarmee indirect bij jou als architect of software-engineer, en de projectleider krijgt als opdracht om te doen wat hij van jou niet wilde aannemen. Mits slim gespeeld, kan dit op lange termijn positieve gevolgen hebben vanuit engineeringoptiek, zonder de relatie te schaden.

De keerzijde van de medaille is dat het ook andersom kan. Elk team van meer dan vijf softwareontwikkelaars heeft minstens één persoon aan boord die alles op zijn eigen manier wil doen, en weinig tot niets aanneemt van anderen – ook hier vanwege zijn of haar eigen beperkte scope. Vaak worden de afwijkende keuzes die zo iemand maakt pas erg laat in het ontwikkeltraject zichtbaar, bijvoorbeeld tijdens codereviews of integratietests. De ruimte voor aanpassingen is dan beperkt.