Wie bezig is met projectmanagement kent zonder twijfel de SCRUM-methodologie. Voor wie SCRUM nieuw is, staan er onderaan dit artikel een paar extra links.
De term zelf komt uit de rugbywereld waar men de bal over het veld beweegt, één positie per keer. En zoals veel zaken uit de sportwereld doorsijpelen naar een businessomgeving, is het hier niet anders.
De filosofie die er achter zit, is dat je beter al doende - met kleine stappen - successen boekt dan dat je na veel werk een nieuw systeem implementeert en faalt.
Het is de projectaanpak waarbij niet te lang op voorhand grote plannen worden gemaakt over hoe een projectdoel zal gerealiseerd worden. SCRUM werkt met veel kortere periodes en mijlpalen en gaat een groot project opknippen naar verschillende zgn ‘deliverables’ en ‘milestones’ waar je met een vast team gedurende 2 tot 4 weken geconcentreerd (en enkel daarop!) op werkt. Het resultaat breng je zo snel mogelijk naar de klant. Op basis van de feedback en volgende prioritaire ‘deliverables’ werk je de volgende periode aan een volgend afgebakend facet van het project. Vaak wordt ook het woord 'Agile' in deze context gebruikt, wat zoveel betekent als wendbaar werken.
SCRUM heeft een heel uitgesproken manier van werken. Zo zijn er ‘sprints’, ‘daily standups’, ‘retrospectives’, is er naast de Product Owner ook een ‘SCRUM master' ...
Toch zijn er een aantal eenvoudige principes die in élk project en élk bedrijf toepasbaar zijn en het resultaat in de markt zullen versterken.
Absoluut op 1 : Ga eerst aan de slag met zaken die waarde creëren voor je klant
Tijd is beperkt. Budget is beperkt en vaak zit daar geen rek op. Als je dus gaat plannen wat eerst wordt aangepakt, wees dan heel consequent om eerst die zaken aan te pakken die de belangrijkste toegevoegde waarde leveren voor je klant. Daarvoor kan je een groot project opsplitsen in verschillende ‘user-stories’, die je vertellen wat je product of dienst doet voor je klant. Een voorbeeld van verschillende user-stories in 1 project
Als klant wil ik online mijn bestelling kunnen doorgeven, zodat ik in de winkel sneller mijn bestelling kan ophalen.
Als klant wil ik op afstand mijn betaling kunnen regelen, zodat daarvoor in de winkel niet meer in de wachtrij moet
Als klant wil ik mijn bestelling thuis laten leveren, zodat ik me niet meer hoeft te verplaatsen.
...
Werk deze verhalen af in volgorde van belangrijkheid. Bekijk voor elk van de user-stories wat de verschillende vereisten zijn. Maar verlies je ook daar niet in detail.
Heeft een ontwikkeling belangrijke toegevoegde waarde voor de klant? Doen! Is het ‘nice to have’ voor de back-office? Dan kan het wellicht naar achter op de prioriteitenlijst.
Met stip op 2 : Verzamel zo snel mogelijk feedback van je (potentiële) klanten
Wacht niet tot alle toeters en bellen in orde zijn, maar ga zo snel mogelijk met een basis van je product/dienst naar de (interne of externe) klant en vraag of dit is wat hij/zij nodig heeft, of er wijzigingen nodig zijn dan wel of wat je maakte eigenlijk niet meer zo relevant is. Elke feedback-opportuniteit is een kans om bij te sturen! Zit je er naast? Veel beter om het snel te ontdekken dan aan het eind van een project waar veel meer tijd, geld en energie is verspild. Nu kan je nog bijsturen.
Al is je product een 'MVP of Minimum Viable Product', het is er wel eentje dat je kan tonen, wat effectief werkt en wat je dus onmiddellijk kan testen bij de doelgroep.
Kijk even naar het voorbeeld hierboven. Niet voor niets zijn die verschillende zaken opgeknipt in verschillende user-stories. Heel vaak wordt gewacht tot een webshop volledig ‘af’ is om er mee naar buiten te komen. ‘Af’ is dan vaak : klaar met alle functionaliteiten erop die nodig zijn voor klant - en back-office. Terwijl je veel beter al - stuk voor stuk - kan buiten komen met nieuwe facetten van je webshop. Je ziet dan meteen of klanten de weg de weg vinden naar de webpagina, je hoort of ze de manier waarop duidelijk vinden of waar je moet bijsturen, doet zelf ervaring op met het verwerken van bestellingen, ...
En op 3: Zorg voor een duidelijk team, niet te groot, niet te klein
Een ideaal team bestaat uit 7 personen. 2 meer is OK, 2 minder is OK.
Efficiëntie daalt als je met meer mensen aan de slag gaat. Minder? Dat is ook niet optimaal, maar komend uit een KMO-omgeving besef ik dat het vaak niet anders kan. Je kan dan de slagkracht van je team vergroten door tijdelijk externe mensen aan te trekken (als het budget dat toelaat…).
1 iemand in het team heeft de expliciete opdracht om de productvisie streng te bewaken: tijd en energie gaan eerst naar zaken die de hoogste toegevoegde waarde creëren (de nr 1 in dit lijstje van tips). In SCRUM-terminologie is hij/zij de zgn ‘Product Owner’ of ‘Producteigenaar’.
Probeer ook in de mate van het mogelijke de mensen ‘dedicated’ op je project te hebben. Desnoods dan een kortere periode, maar dan is er wel focus.
Wil je meer weten over dit onderwerp?
Hier alvast 2 interessante links:
Jeff Sutherland is 1 van de grondleggers van SCRUM. Zijn boek wordt dan ook beschouwd als 1 van de basisboeken voor wie er meer wil over weten. Je kan het bijvoorbeeld hier bestellen.
LinkedIn biedt in haar 'academy' heel wat interessante online cursussen aan, zoals deze 'Scrum Basics' Wil je meer, dan zijn er vervolgopleidingen (een paar getest en goed bevonden :-) )
