In de twee vorige delen van deze serie keken we naar het vastleggen van de omgeving, de doelstellingen en de perspectieven waarin we onze agile trajecten uitvoeren. We gingen in op hoe je in een grote omgeving de diverse agile trajecten gezamenlijk uitvoert en hoe je daarbij efficiënt gebruikmaakt van je buffers. De rode draad is en blijft een goede onderlinge samenwerking tussen de verschillende teams.
Wie deze inzichten en adviezen zorgvuldig uitvoert zal merken dat de agile trajecten beter en efficiënter verlopen, wat uiteraard leidt tot betere resultaten. Kortom: agile plus! In deze aflevering bekijken we de relatie tussen het ontwikkeltraject en het product dat daaruit kan voortkomen. In een standaard agile traject wordt geen aandacht besteed aan deze relatie. Eigenlijk staat in geen enkele projectmethodiek wat de relatie tussen het ontwikkelproces en de producten betekent voor het eindresultaat. Een gemiste kans.
Poldermodel
In ieder ontwikkeltraject doet een aantal partijen mee. Alle hebben een stem in hoe de voortgang verloopt. Dat zijn allereerst de klanten, de mensen de software uiteindelijk gaan gebruiken. Hun voornaamste belang is dat de software goed aansluit op hun wensen. Dat hangt voor een belangrijk deel samen met het gebruiksgemak van de software. De tweede partij zijn de ontwikkelaars. Zij hebben een sterke voorkeur voor het werken volgens heldere standaards. Immers, zo ontstaat een solide product, dat goed onderhoudbaar is. Het is evident dat deze twee wensen elkaar niet per se aanvullen. Sterker nog, ze staan enigszins tegenover elkaar. Een groot gebruiksgemak en allerhande leuke gimmicks die de klant goed bevallen, zijn een drama voor de ontwikkelaar. Omgekeerd is voor de klant een standaardsysteem snel saai en zelden gebruiksvriendelijk. In een agile traject zetten we klant en ontwikkelaar dicht bij elkaar en laten we ze met grote regelmaat overleggen. Op deze wijze ontstaat in kleine stapjes een poldermodel van de software. Iedereen wordt er op zijn minst wel een beetje blij van, want in iedere oplevering zit iets dat beide partijen aanspreekt.
Lappendeken
Toch kent deze ogenschijnlijke win-winsituatie vanuit het oogpunt van efficiency en kwaliteit de nodige beperkingen. De agile methodiek levert incrementele verbeteringen op, die bij elkaar een grote lappendeken aan (sub)optimalisaties vormen. Dat wordt dan de uiteindelijke applicatie. Dit lappendekenmodel heeft als nadeel dat er vaak geen eenduidige architectuur in het systeem is en dat we overal net niet het optimale resultaat hebben gehaald. De opgeleverde software werkt wel, maar het zou zoveel beter kunnen.
Drie groepen werk
Daarom stellen wij een andere aanpak voor. Aan het begin van een project maken we op de door agile voorgeschreven wijze een product backlog. Als de backlog initieel gevuld is, gaan we normaal de sprints indelen om vervolgens te starten met de eerste sprint. Bij agile plus zetten we hier een stap tussen. We maken onderscheid tussen drie groepen werk. Die kun je zien als drie wegen die naar Rome leiden.
- Innovatieve onderdelen
De eerste groep zijn de innovatieve onderdelen die in ons project zitten. Dit worden de kleine componenten die we via de standaard agile methode gaan ontwikkelen. Het resultaat is de eerder genoemde lappendeken, wat voor deze onderdelen een uitstekende vorm van output is. We zijn relatief veel tijd kwijt met het ontwikkelen en uitvinden van hoe het er precies uitziet en werkt, maar dat hoort nu eenmaal bij innovatie.
- Standaardonderdelen
De tweede groep zijn de standaardonderdelen, zoals servicemodules of grote batch rekenprogramma’s. Deze maken we volgens een strak gestandaardiseerd ontwikkelproces, bijvoorbeeld het oude en vertrouwde lineaire of watervalmodel. Hier is het uitgangspunt: snel, efficiënt en zonder opsmuk iets stevigs realiseren dat als backbone voor het systeem functioneert. Kenmerk van een dergelijk systeemonderdeel is dat de gebruiksvriendelijkheid beperkt is, maar de robuustheid optimaal.
- Klantonderdelen
De derde groep zijn die systeemonderdelen waar de klant de meeste betrokkenheid bij heeft en waarover hij ook de meeste inspraak in wil hebben. Hier wordt een veelheid aan kleine systeempjes ontwikkeld die volledig tegemoetkomen aan de wensen van de klant. Dit leidt tot grote klanttevredenheid en tot een wat chaotische architectuur. Dat laatste moeten we vooralsnog maar voor lief nemen.
Buiten de doos
In de stap na de backlog worden de activiteiten in deze drie groepen verdeeld. Daarbij is het belangrijk dat er een goede balans is en dat je zorgvuldig kijkt op welke wijze de systeemdelen het best verdeeld kunnen worden. Op deze manier ontstaan er drie deelprojecten die onderling ook weer goed op elkaar moeten aansluiten.
Veel scrummasters en projectleiders vinden de hierboven beschreven aanpak lastig. De meesten voeren hun werk het liefst uit binnen de standaardmethode. Het geeft hen de benodigde houvast. Het op voorhand uitsplitsen naar drie groepen werk vereist meer van de scrummaster, maar het levert absoluut wat op. De resultaten zijn gegarandeerd beter. Diversiteit is heel belangrijk als je een goed product wilt neerzetten. Het vraagt van je dat je niet alleen buiten de doos denkt, maar ook buiten de doos werkt. Wie durft?
Bert van der Zee is consultant en trainer en is auteur van het boek ‘Intuïtief Innoveren methodisch werken aan echte doorbraken met QuTE’.
Lees ook het eerste en tweede deel van de snelcursus Agile Plus van Bert van der Zee
