Voor elk softwareproject is de beschikbare tijd en het budget beperkt. Daarom is het uitermate belangrijk om software op een zeer productieve manier te bouwen, die tevens voor het developmentteam volhoudbaar is. Er zijn veel aspecten die belangrijk zijn als je wilt dat je team twee keer zoveel waarde levert in de helft van de tijd. Deze post gaat dieper in op hoe je je tijd niet moet verspillen wanneer je een project uitvoert om hoogproductieve software-ontwikkeling te realiseren. Hoogproductieve teams zoeken quasi permanent naar voor de hand liggende, maar ook naar meer verborgen verspillende activiteiten die zorgen dat hun project niet op tijd of niet binnen het budget kan worden uitgevoerd.
Hoogproductieve teams zijn er zich bewust van dat ze best geen middelen verspillen aan activiteiten die geen waarde toevoegen aan de software die ze bouwen. Deze blog geeft enkele richtlijnen om verspilling in te perken die te vaak over het hoofd worden gezien tijdens het bouwen van software.
Doe het goed van de eerste keer
Dit gaat over focussen op de juiste features tijdens het bouwen van software.
De juiste features bouwen houdt in dat de eigenaar van het product altijd software features wilt die op dat moment het meeste waar voor zijn geld leveren.
Zie het als een rode vlag wanneer een project start met CRUD-schermen te realiseren voor referentiegegevens. De eerste software increments zouden essentiële functies moeten opleveren. Essentiële features maken de kern uit van je software. Als deze niet goed gebouwd worden faalt de software sowieso. In plaats daarvan zou je verwachten dat vroege software-incrementen de basisfuncties leveren, zoals berekeningsengines voor een salarissysteem of het kopen van boeken voor een online boekenwinkel. Veel zogenaamde agile projecten hebben nog steeds last van een upfront requirements mindset. Daarnaast hebben veel agile projecten nog steeds een soort van grote upfront requirements-activiteit welke een scope definieert die in steen is vastgelegd. In zo’n omgeving hebben stakeholders de neiging om te veel te communiceren over requirements, omdat ze niet willen dat ze een eigenschap missen die door een collega belangrijk wordt geacht.
Mensen zijn bijzonder slecht in alle noodzakelijke details van een product vooraf te voorspellen. We zijn van nature eerder goed in details stapsgewijs te ontdekken. Hoe verder we eraan werken, hoe gedetailleerder het wordt. Wanneer de producteigenaar zich vooral vastklampt aan een vaste scope, gaat het al wat meer de goede kant op. De taak van de producteigenaar moet een zoektocht zijn om zo vroeg mogelijk echte bedrijfswaarde te leveren. De business en de functie-eisen onderzoeken kan best zo gedetailleerd mogelijk zijn, zodat een specifieke functie niet een tweede of zelfs derde keer moet worden gebouwd.
Bouw features op de juiste manier
Denk na voordat je begint met het bouwen van software. Het is zeer belangrijk dat de domeinniveaus van je software overeenkomt met jouw specifieke bedrijfsrealiteit. Als je dit goed doet, kan het je helpen om dure aanpassingen in je software te vermijden. Maak daarom je domeinmodellen en je domein glossary expliciet. Zorg er ook voor dat deze goed verstaan worden door alle developers en stakeholders van je bedrijf. Als één model van belang is in de systeemarchitectuur, dan is dat zonder enige twijfel het domeinmodel.
Als je een fout maakt, los het dan meteen op. Stop met al de rest en los het op. Er is veel onderzoek dat aantoont dat als je bugs later oplost, je meer dan twintig keer zo lang eraan kan werken dan dat je onmiddellijk alles oplost.
De realiteit is vaak dat functies testen 1 tot 4 weken na de implementatie gebeurt. Fouten zo laat oplossen verspilt je projectmiddelen. Ze kunnen namelijk niet meer in waardevolle functies worden geïnvesteerd. Het is dan ook van groot belang dat de upgrade van de software die overeenkomt met een gebruikersverhaal zo snel mogelijk wordt gepromoot in de testomgeving. De producteigenaar (of een afgevaardigde) test of de implementatie aan de eisen voldoet en geen fouten bevat. Het team lost dit functioneel of technische problemen op voor alle andere dingen.
Zorg voor een flow tijdens het bouwen van software
Een goede flow heeft twee aspecten. Instroom en doorstroom.
De instroom van eisen wordt soms onderbroken. Het ontbreken van een consensus over de kernvereisten onder de stakeholders is vaak een reden.
Een andere reden is een ontbrekende of niet beschikbare stakeholder met belangrijke zakelijke kennis en beslissingsbevoegdheid.
Wanneer de instroom van requirements wordt onderbroken, proberen teams meestal de technische problemen weg te werken. Zodra het probleem voldoende is weggewerkt, zal het team proberen zich op een nuttige manier bezig te houden. Ondanks de beste intenties van het team om dit te doen, gaat in de meeste gevallen het projectbudget verkwist worden op een niet-productieve manier.
Het aangenomen ontwikkelingsproces moet eenvoudig, vlot en probleemloos verlopen om zaken voor elkaar te krijgen. Verwijder alle stappen die geen waarde aan je software toevoegen. Richtlijnen moeten worden ingekort om alleen de voorwaarden te beschrijven waaraan moet worden voldaan om een verhaal naar de volgende stap in de procedure te kunnen verplaatsen.
Een goed retrospectief optimaliseert je proces en richtlijnen. Als dat niet het geval is, heroverweeg dan het retrospectieve format dat je gebruikt. Activiteiten en richtlijnen die tijd verspillen, verkwisten ook resources die je niet meer kunt gebruiken voor waardecreatie. Stop er dus best onmiddellijk mee.
Doe één ding tegelijk
Door te multitasken gaan beide taken langzamer en slechter verlopen. Dit voor gelijktijdig te werken aan verschillende projecten, maar ook voor multitasken binnen één project.
Deze grafiek verschijnt in “Quality Software Management” van Gerald Weinberg. Eén van de klassieke werken over software development.
Het toont de hoeveelheid tijd die verspild wordt aan de projectcontext om te schakelen in functie van het aantal projecten waarover de aandacht moet worden verdeeld.
Harold Pashler heeft begin jaren negentig aangetoond dat dit ook geldt voor eenvoudige taken. Hij voerde een paar eenvoudige experimenten uit. Hij liet één groep één simpel ding doen, zeg maar op een knop drukken als ze een geluid hoorden. En dan gaf hij een andere groep dezelfde taak met nog een andere eenvoudige taak. Een voorbeeld was een andere knop indrukken als er een ander geluid werd gemaakt.
Zodra er een andere taak werd toegevoegd, hoe eenvoudig ook, verdubbelde de tijd dat ze ermee bezig waren. Pashler stelde dat er een soort van knelpunt in de verwerking was – dat ze eigenlijk maar aan één ding tegelijk konden denken. Hij dacht dat er een zekere inspanning nodig was om het ene proces “in te pakken”, in je geheugen te reiken en het andere eruit te halen, en dan die klus te klaren. En elke keer dat je van taak wisselt, kost dat proces tijd.
De rubriek “Loss to Context Switching” is pure verspilling. Wees je dus bewust van de kosten van naar een andere context om te schakelen. Het is een reëel probleem en je moet proberen het zo veel mogelijk te vermijden. Als je denkt dat dit niet van toepassing is op je team, dan heb je het mis – dat is het wel.
Te hard werken zorgt voor meer werk
Lange uren werken zorgt er net voor dat je minder gedaan krijgt. Te hard werken voor een langere periode resulteert in vermoeidheid, wat leidt tot fouten, wat leidt tot dubbel werk. Later moet je dan je fouten proberen op te lossen. Teams moeten alleen doordeweeks werken in een duurzaam tempo. Werk best niet te laat door en al zeker niet in het weekend.
Scott Maxwell introduceerde scrum op OpenView. Hun bedrijfscultuur verwachtte dat mensen laat en in het weekend zouden moeten werken. Het waren agressieve, ambitieuze mensen. Toch kregen ze burnouts, werden ze depressief en zakte hun moed snel in hun schoenen. Veel goede collega’s konden er gewoon niet meer tegen en stopten er gewoon mee.
De y-as staat voor productiviteit en de x-as staat voor werkuren. Scott merkte een verschuiving in de productiviteit op. Meer uren werken zorgde voor minder output.
Hij mat de prestaties van verschillende open view-projecten en tekende hierbij de volgende curve. De piek van de productiviteit daalt eigenlijk met iets minder dan veertig uur per week.
Takeaways
Wanneer je een hoogproductieve softwarelevering wilt bereiken, zijn veel verschillende aspecten van belang. Bij teveel projecten zorgt tijdverspilling voor een aanzienlijke afname van de beschikbare middelen. Tijdverspilling is dus echt wel een doodzonde!
Maar hoe kun je tijdverspilling inperken?
Doe het de eerste keer goed. Bouw de juiste features op de juiste manier. Test en corrigeer onmiddellijk. Pas dan is je verhaal klaar. Zorg voor een flow. Het team mag niet inactief worden door onvoldoende influx. De flow moet moeiteloos verlopen. Verwijder dus alle stappen en beleidsregels die niet bijdragen aan een waardevolle software. Doe één ding tegelijk. Door meer dan één ding tegelijk te doen, ga je beide taken langzamer en slechter uitvoeren. Doe dit niet. Als je denkt dat dit niet op jou van toepassing is, dan ben je verkeerd. Werk hard, maar op een duurzaam tempo. Lang werken zorgt er niet voor dat je meer gedaan krijgt, maar net veel minder.
