Steven Somer Manager - Dutch Grit 24 januari 2018
Dutch Grit


Interview projectaanpak Tyres in Stock

In de case-omschrijving van Tyres in Stock (TIS)hebben we al kort inzicht gegeven in hoe we de oplossing voor TIS gerealiseerd hebben. Voor meer inzicht in de projectaanpak gaan we in gesprek met Steven Somer, scrum master bij Dutch Grit.

 

Steven, bij het inlezen voor dit artikel las ik dat jij bij dit project scrum master was. Klinkt stoer, maar hoe is dat anders dan een projectleider?

“Om van het TIS-project een succes te maken, was al snel duidelijk dat een klassieke watervalmethode niet tot het beste resultaat zou leiden. Daarom is er gekozen voor de AGILE SCRUM-aanpak. We hebben het daarbij dan over een scrum master in plaats van een projectleider. Deze persoon leidt het proces in goede banen, coacht het team en staat de productowner bij.”

 

Zelfde functie, andere naam dus.

“Nee, zeker niet. Maar dan moet ik wat uitleggen over de methodieken. Deze zijn compleet verschillend en daar horen dan ook andere functies bij.

Voorheen werkten we voor onze projecten met de watervalmethode. Van oudsher zijn we gewend om een ICT-project eerst helemaal uit te denken en dan in één ruk uit te voeren. Het idee is dat een FO (red. functioneel ontwerp) grip geeft op de kosten en inzicht geeft in wat je daarvoor krijgt. Bij Dutch Grit ervoeren we dit echter helemaal niet zo. Zeker niet bij grotere maatwerktraject, zoals een rebuild voor TIS. Het FO is bij voorbaat incompleet, vatbaar voor interpretatieverschillen en biedt geen flexibiliteit om gaandeweg bij te sturen. Met regelmaat kwam het dan ook voor dat we aan het eind van een project precies hadden geleverd wat een klant vroeg, maar niet geleverd hadden waar hij behoefte aan had.”

 

Eerlijk is eerlijk, als interne klant bij jullie weet ik dat ik gedurende projecten vaak bij wil sturen op voortschrijdend inzicht tijdens de ontwikkeling, omdat ik vaak niet alles van te voren uit kan denken.

“Precies! Dat maakt SCRUM zo geschikt voor deze trajecten, waar op basis van de ervaring van eindgebruikers wordt gewerkt. De ‘userstories’ noemen we dat: korte beschrijvingen van functionaliteit. Deze gaan we uitwerken. Dat doen we met een productowner, iemand aan de kant van de klant. Deze persoon kent het bedrijf, de business en de klanten. Bijkomend voordeel is dat het bedrijf zo een hoge mate van betrokkenheid heeft met het project. Het is niet meer zo dat ze op 3 momenten het resultaat of een deel daarvan te zien krijgen, maar constant stukjes. Feedback wordt in de ontwikkelsprints steeds verzameld en verwerkt. Aan het eind van elke sprint is direct resultaat te zien. De klant kan dan dus ook besluiten dat dat resultaat voor hem genoeg is, bijvoorbeeld om een nieuw concept te starten en kan dan besluiten om te stoppen met de verdere ontwikkeling."

 

Dat is voor jou dus niet zo handig, financieel gezien.

“Financieel gezien misschien niet, maar de mate van tevredenheid, het echt leveren van waar de klant behoefte aan heeft, is dat meer dan waard. Zo zijn we echt een partner die waarde toevoegt."

 

Klinkt goed, maar ik ben zelf eerder bang voor het omgekeerde. Want van te voren staat dus niet vast wat je precies gaat doen. Hoe weet ik dan dat als mijn budget op is, ik wel iets heb waar ik wat aan heb?

“We gaan niet van start zonder doel. Aan het begin van het project stellen we op wat de productowner wil hebben. Dit omvat het gehele project, dus zowel noodzakelijkheden als wensen. Die lijst gaan we daarna prioriteren, de belangrijkste punten eerst en dan zo door naar wensen en wannahaves. De zaken die noodzakelijk zijn om te kunnen starten, definiëren we als een minimum viable product (MVP). Hierin geeft de klant aan wat hij minimaal nodig heeft. Wij geven een indicatie van het aantal sprints en dus de kosten en een belofte dat hij voor dat budget het MVP krijgt. Dan gaan we ontwikkelen op basis van de opgestelde lijst. We beginnen met de MVP-punten op de lijst en werken zo door naar beneden. De productowner krijgt elke 2 weken een sprint opgeleverd en kan dan beslissen of hij doorgaat, het project op pauze zet en later door laat ontwikkelen of stopt."

 

Wat vraagt dit van de partners waarmee we samenwerken? Moeten die ook volgens deze methoden gaan werken, want dat zijn ze vast niet gewend?

“Wij werken voor vrijwel elk project samen met één of meerdere partners. Sommigen zijn deze werkwijze gewend en gaan daarin mee, bij anderen werkt én hoeft dat niet. Voor TIS hebben we in een voortraject gewerkt met een user experience en met een designbureau. Zij hebben onderzoek gedaan, advies gegeven en producten opgeleverd voordat wij aan de slag gingen met de ontwikkeling.”

 

Welke tips kan je geven aan bedrijven die overwegen te gaan werken met SCRUM of aan klanten die op deze manier een product willen laten ontwikkelen?

 

TIP 1

 

  Zorg dat de productowner goed opgeleid is in SCRUM. Deze rol wordt door klanten vaak onderschat, waardoor het project niet zo efficiënt loopt als zou kunnen.  

 

TIP 2

 

  Beperk de teamleden in SCRUM-meetings tot echt betrokkenen. In het proces zijn een aantal meetings opgenomen, maar met een te groot team de backlog grooming doen, waar iedereen bij zit, is niet efficiënt en kost de ontwikkelaars teveel tijd.  

 

TIP 3

 

  Testen, testen, testen! Voor je tijdens de sprintreview met de klant naar de release gaat kijken, is het essentieel dat er met een grote groep getest is. Wij hebben zelf elke donderdag een testronde, waarbij we alle projecten bekijken met ons volledige team. Iedereen op een ander apparaat en vanuit zijn eigen expertise.  

 

Back