Na het beloofde land van agile en sprintteam, een boek dat duidelijk op ervaring is geschreven. Zo duidt ook een van de auteurs Hans Gort in het voorwoord. Als je succes afhankelijk is van IT-projecten, en dat is het, dan red je het niet met agile denken. Je wilt ook dat je projecten voorspelbaar, nauwkeurig en betrouwbaar zijn. Het boek is hier te koop. 

Zo betrouwbaar als een machine.

De Happy Sprint Machine is welzeker een methode die is gebaseerd op korte sprints, maar dan wel op basis van een perfecte voorbereiding, uitstekend gedocumenteerde communicatie en een gecontroleerde omgeving. Een perfect afgestemde machine die leidt tot producten die klanten echt nodig hebben en die zowel klant als leverancier happy maken.

In het boek beschrijven de ontwikkelaars van deze methode hoe IT-projecten nog elke dag in de praktijk ontsporen, en hoe hun aanpak veel tijd, geld en werkplezier kan schelen. Ze laten zien hoe een team met militaire discipline, één doel en één plan elke keer kan slagen.

 

 

Partners en methode

Hans Gort, Arnold Pouls en Ron van Wieringen ontwikkelden De Happy Sprint Machine met de ambitie om de slaagkans van projecten substantieel te verbeteren. Als partner van Twycis brengen ze hun aanpak elke dag in de praktijk. Hans Gort is directeur van het bedrijf en sparringpartner voor leiders en ondernemers in business, development en conceptontwikkeling. Hij verbindt technologie, mensen en business voor opdrachtgevers tot een succesvolle drie-eenheid en stond aan de wieg van de developmentmethode die de Happy Sprint Machine is gaan heten.

In de inleiding wordt net als in het voorwoord de transparantie van werken benadrukt. Tevens wordt het grote verschil in aanpak per sector benadrukt.

Word je gelukkig van projecten die soepel lopen? En de hamvraag: welke methode werkt als werkwijze bij IT-projecten? 

 

Faalt de IT, dan faalt de business!

De open deur dat wij allen afhankelijk zijn van I(CT) wordt direct benadrukt. Als de IT-huishouding binnen een organisatie niet werkt, dan hebben we een groot probleem in veel organisatieprocessen. In hoofdstuk komt aangepast (DSO) wetgeving langs en wat rake voorbeelden van grote (overheids)projecten die veel vertraging hebben gekend en niet altijd voorbeeldig zijn geweest. Kritische kanttekening daarbij is dat een project als de OV-chipkaart, die wordt aangehaald in hoofdstuk 1, zo uniek is/was qua karakter dat daar niet even een blauwdruk en gestandaardiseerde methode van toepassing kon zijn.

Kwaliteit lijkt plaats te hebben gemaakt voor snelheid.

Bij de start mislukt

Projecten die onrealistisch zijn of gewoon slecht uitgevoerd; het vormt een tweedeling en de rode draad in het tweede hoofdstuk van het boek dat prettig leest in opmaak en schrijfwijze. Terecht de opmerking dat na het tekenen van de offerte er spontaan veel ruimte is om na enkele maanden met meerwerk te komen. Onbewust wordt hiermee toegelicht dat we eigenlijk veelal niet altijd weten waar het IT-project toe leidt. De aanbesteding en de soms ondoorzichtige procedure komt langs waarbij de auteur en ondernemer raak wil scoren op het feit dat vooral de briefing en uitleg rondom de aanbesteding soms zo vaag is dat dit ook tot een vaag en onrealistisch aanbod/offerte leidt. Een project “Mislukt bij de start” noemen de schrijvers het. Interessant is de claim dat scrum en agile het alleen maar “erger maken”, want in principe kun je het project, de projectdefinitie en briefing dan weer vanaf de start herpakken. Ook claimen de makers in hoofdstuk 3 dat productowners met verkeerde dingen bezig zijn: “Is er een call om 12 uur, dan zit je 2 voor 12 uur klaar.”

Design en analyse

We lezen verder in een aaneenschakeling van beweringen waarom projecten veelal falen, en komt tot een welkome uitleg van wat Productowners nu behoren te doen en wat het verschil is met bijvoorbeeld Businessanalysten. We scrummen, auditen, zijn bezig met de optimale IT-architectuur en maken ons druk over de delivery-manager waarbij het verschil met zomaar een projectmanager niet altijd duidelijk wordt. We komen geleidelijk tot de conclusie dat het boek geschreven moet zijn voor de grotere IT-projecten met megabudgetten en veel “handjes” voorradig. Wellicht had dit hoofdstuk met de introductie van veel functie, termen en taken eerder gekund en had de schaalbaarheid van zomaar een IT-project een issue kunnen zijn in de structurering van de beoogde methode en uitvoering.

De methode

In hoofdstuk 4 de eigen sprintmethode. De term “machine” doet vermoeden dat het snel, accuraat en in grote aantallen kan. De methode is niet nieuw en leunt op de schouders van agile en de zogenoemde Waterval-aanpak van projecten, uitleg (red.):

De waterval methode is een klassieke aanpak voor projecten. Het gaat er vanuit dat je eerst het gewenste eindresultaat zo volledig mogelijk specificeert, ontwerpt, bouwt, test en in productie neemt. Wanneer het eindresultaat in productie is genomen, kunnen de beoogde gebruikers er mee aan de slag. Doorgaans is dat laat of aan het einde van het project. Dat betekent dat de gebruikers dan pas in de praktijk ervaren of het eindresultaat echt is wat ze nodig hebben. Als dat niet goed blijkt aan te sluiten, dan kan dat veel herstelwerk en dus kosten en vertraging opleveren. Doorgaans is het zo dat hoe vroeger een fout wordt ontdekt, hoe minder tijd en geld het kost om het te herstellen. Voorbeeldje: een fout in een bouwtekening herstel je sneller dan een slechte fundering wanneer het gebouw al staat.

De beschreven methodiek gaat het niet helemaal anders doen. Het is vooral een voorspellende, beheersbare methode en aanpak. Een goed team, discipline, eerlijkheid, een doel en een plan, zijn voorbeelden van de componenten van de methode. We missen soms de duiding wie nu precies waarvoor verantwoordelijk is.

Een stappenplan helpt ons van doel naar customer journey en in de altijd noodzakelijk opsomming van valkuilen is nog steeds “Garbage in is garbage out”. Valkuilen als “.. je bent niet scherp genoeg..” lezen als een wat wazige roep in de woestijn. We hadden graag gelezen hoe je een IT-team in de discipline en scherp houdt als het bijvoorbeeld tegenzit. Ook valt af te vragen of de ongeduldigheid van een “business” een valkuil of gegeven is? 

Wat richtinggevende documenten geven het hoofdstuk aan het einde een praktische hand.

Het heilige ritme van de spring.

Van roadmap naar wireframes

Via een roadmap, de MVP’s gaan we naar de altijd vitale wireframes die de boel inzichtelijk maken, ook aan de klantkant. Het doel en plan is bekend, we kunnen gaan bouwen. Handig zijn de lijsten waar een sprintverloop en -aanpak aan moet voldoen. Alle losse onderdelen zijn helder uitgewerkt met nodige visuals (zoals een schema) in het hoofdstuk acht. Het hoofdstuk had meer tools en voorbeeldschema’s verdiend, aangezien “sprint” het hart is van de machine en aansprekend lijkt voor veel leden van de projectteams.

De punten en de praktijk

We geraken in het overzicht van punten die de Sprint machine duiden met onder andere een hartslag. Praktische, hilarisch, interessant en gezien vanuit de praktijk is dan ook het afsluitende onderdeel waar we de sprint machine in de praktijk zien met een diversiteit aan aansprekende voorbeelden. Deze hadden wellicht relevant door het boek geplaatst kunnen worden voor duiding van de theorie? 

Dus?

Boeken over IT-projectmanagement bestaat al lang. Dat daarbij informatiemanagement en de communciatiestroomlijningen vitale factoren van succes zijn, wordt al sinds de jaren zeventig uitvoerig beschreven. De eerste projectmanagement software had ook een focus op IT-projecten en hun beheer. Het boek De Happy Sprint Machine gaat verder dan zomaar wat agile en sprintteams, en dat geeft nieuwe inzichten die gestapeld lijken in aanpak en methodiek. Qua projecten en learnings die veelvuldig langskomen in het boek is het soms iets te gemakkelijk “achteraf praten”. Het praktische en soms komische boek, lijkt een bloemlezing van wat er mis kan gaan bij zomaar een IT-project. Wie ervaring heeft met verschillende manieren van projectmanagement, ziet een subtiele mix van bestaande stijlen en inzichten. Er komt veel langs; veel functies, taken en termen. Het feit dat het handboek wat gericht lijkt op grote IT-projecten bij corporates, maakt het boek niet altijd voor een diversiteit aan (deel)projecten in de I(CT) hanteerbaar. Dat het boek is geschreven door ervaren IT-projectmanager en ontwikkelaars, staat als een paal boven water. Net als het feit dat het op veel gebieden kan winnen aan kader, schaalbaarheid en de nodige uitwerking en visualisering per onderdeel.

 

Het boek is fraai opgedeeld met ook een Nawoord en literatuurlijst.

 

---

Inhoud (boek is hier te koop)

Voorwoord
Inleiding
Vakvolwassen worden

1. FAALT DE IT, DAN FAALT DE BUSINESS

2. BIJ DE START AL MISLUKT
Terreur van de aanbesteding
Een bewust conflictmodel
Mislukt bij de start

3. DE WEG NAAR VAKVOLWASSENHEID
Orde in de chaos
Flexibiliteit en wendbaarheid in een snel veranderende wereld
Klachten uit de praktijk
Een volgende stap in volwassenwording
De Happy Sprint Machine

4. WAT IS DE HAPPY SPRINT MACHINE?
Het ontstaan van de Happy Sprint Machine
Eén doel, één plan, één team
Eén doel
Eén plan
Eén team