Help: mijn software project zit vast

Als CTO, technisch directeur of programmamanager zorg je ervoor dat de techniek op tijd beschikbaar is om de bedrijfsstrategie uit te voeren. Daarvoor start je allerlei projecten, na een keuze voor buy of build, in- of out-source en cloud of on-premise. Die projecten lopen lang niet altijd op rolletjes.

Toen ik zelf CTO was kreeg ik nog wel eens het verwijt: het duurt twee keer zo lang of kost drie keer zo veel. En als er weinig zichtbare voortgang is, lijkt zo’n software project wel een zwart gat waar alleen maar euro’s in verdwijnen. Helaas zit je soms al vast voordat je begonnen bent, door tekort aan tijd, mensen en/of middelen.

Hoe doorbreek je dit?

Wanneer een project is vastgelopen, heb je in principe weinig te verliezen. Dus waarom gooi je het roer niet eens om? Als je doet wat je deed, krijg je wat je kreeg, en dat was duidelijk niet de oplossing. Het kan soms voelen als een nederlaag wanneer je extern om hulp vraagt. Maar door een (gedeelte van) een project uit te besteden aan een partij die gespecialiseerd is in hetgeen waar je tegenaan loopt, komt jouw project ineens wél van de grond.

Zo heeft Zilverline in 2009 Scrum geïntroduceerd bij Albert Heijn: er moest voor kerst een project worden opgeleverd, maar met de gebruikelijke projectaanpak was dat onhaalbaar. Het moest anders: mensen in één team plaatsen en elke twee weken een werkende oplevering. Het leidde tot discussies en meningsverschillen, maar het werkte wel! De deadlines werden gehaald en de nieuwe manier van werken bleef. Ook bij Havenbedrijf Rotterdam ontstond er een crisis nadat er een lange tijd alleen papier was opgeleverd. Tijd om het over een andere boeg te gooien! Bij de herstart van het project werden eindgebruikers van het begin af aan betrokken bij het project en werd er in elke sprint resultaat opgeleverd.

Waarom werkt het? Binnen twee weken resultaat leveren geeft vertrouwen. Daarnaast werkt het inspirerend voor de organisatie. Het doorbreken van een negatieve spiraal waarin het starten van een project een steeds hogere barrière opwerpt, is belangrijk. Door het project op te delen in sprints met concrete opleveringen voorkom je een papierfabriek.

Waarom komen projecten vast te zitten?

Er zijn talrijke redenen waarom een project vast komt te zitten.

• ‘Virtuele’ teams. Iedereen zit tegelijk in verschillende teams, waardoor het meer uitzondering dan regel is dat iedereen aan hetzelfde project werkt - en er focus is. Het gevolg is dat iedereen heel druk is, maar dat je weinig gedaan krijgt.

• Onduidelijkheid over interfaces, rechten, afhankelijkheden of externe leveranciers. Wanneer een gedeelte van een project om deze reden vastloopt, wordt dit probleem vaak niet direct opgelost, maar worden deze problemen ‘opgespaard’. Iemand die vastloopt kan wel verder in een ander ‘virtueel’ team, maar het blokkerende probleem blijft bestaan en onduidelijkheid over verantwoordelijkheid en deadlines groeit.

• De “Business”. De afstand tot de eindgebruiker is in veel organisaties een groot probleem. Ontwikkelaars hebben soms nog nooit een eindgebruiker gesproken of gezien en denken vaak alleen uitsluitend vanuit een technisch perspectief. Het product zou altijd moeten worden afgestemd op de behoefte van de klant; zij geven de software immers bestaansrecht.

• De “Olifant”. Het project is zo groot dat er verschillende teams aan verschillende aspecten werken en het grotere doel niet kennen, maar verwachten dat andere teams dat doen. Ieder team kan iets van hun stukje laten zien, maar het geheel is onbruikbaar.

Hoe ontstroef je software projecten?

• Stap 1. Eén team. Meer mensen geven minder resultaat. Verantwoordelijkheden worden al snel onduidelijk binnen één team met veel mensen, laat staan meerdere teams die zogenaamd onafhankelijk van elkaar werken, maar wel afhankelijk zijn van elkaars product. Starten met een klein team van maximaal 5 mensen is het meest effectief.

• Stap 2. Na twee weken resultaat. Het is belangrijk dat er snel een tastbaar en bruikbaar resultaat wordt opgeleverd. Binnen twee weken wil je de eerste resultaten kunnen bespreken, zodat er snel inzicht is wat er allemaal nodig is om de volgende sprints beter te maken en een realistisch inschatting te kunnen maken van wat er nog nodig is om het product te kunnen leveren.

• Stap 3. Bruikbaar voor de ‘business’. Het resultaat van de eerste sprint moet ook bruikbaar zijn voor de mensen die ermee gaan werken; voor de ‘business’. De gebruikers zijn dus actief betrokken bij de specifieke keuzes en invulling van het product aan begin van het project - maar ook vooral aan het einde van de sprint bij de oplevering.

Stap 2 en 3 blijf je herhalen. Als het zoveel werk is dat één team het niet binnen de gegeven tijd kan bolwerken, ontstaat vanzelf het inzicht hoe een volgende team kan worden toegevoegd dat onafhankelijk en autonoom kan opleveren.

Als je dat 20 keer achter elkaar hebt gedaan, kan het best zijn dat je je omdraait en met bewondering kijkt naar een prachtig systeem dat je hebt neergezet. Dat is het resultaat van voortdurend opleveren en nauwe betrokkenheid van de business.