Zo realiseer je maximale outcome van je digitale projectteam

Ken je het gevoel dat je opdrachtgever per se wil scrummen, terwijl jij twijfels hebt of dit wel de beste werkwijze is? Of dat de output van je team plotseling afneemt? Of dat je team steeds naar jou kijkt en wacht tot jij ze vertelt wat ze moeten doen? Het inrichten en begeleiden van een project is niet makkelijk. Je hebt te maken met allerlei verwachtingen, beloftes, politieke invloeden, afhankelijkheden, meningen, karakters, oftewel met mensen en hun grillen.

Als Scrum Master en Projectleider bij Jungle Minds loop ik hier geregeld tegenaan. In deze rol train en begeleid ik ook (onervaren) Product Owners en Scrumteams. Bij navraag bij zes ervaren Product Owners en Scrum Masters, die bij vooraanstaande corporates werken, bleek (gelukkig) dezelfde ervaringen naar boven te komen. Ik heb onze ervaringen gebundeld in dit artikel. Je vindt in dit artikel tips hoe je tot een maximalisatie van de outcome van jouw project team komt en wat de valkuilen zijn.

1. Zet het fundament van je traject goed neer

Kies je werkwijze

In dit artikel ga ik uit van werken volgens de Scrum-methodiek. Let op: bedenk altijd of de klant, het vraagstuk en de voorwaarden geschikt zijn om volgens deze methodiek te werken. Te vaak wordt gekozen voor een Agile werkwijze als Scrum, zonder te controleren of aan de voorwaarden voor Agile werken en Scrum wordt voldaan.

Wat is Scrum?

Scrum is niet zozeer een aanpak, maar eerder een filosofie. Waarbij we afscheid nemen van het traditionele blauwdruk denken. Het betreft een manier van werken die voor allerlei soorten veranderingen en projecten toepasbaar is.

Het is de filosofie van ‘see-feel-change’. Oftewel leren door doen. Anders geformuleerd: Beter al doende, met kleine stapjes, succes boeken dan na veel werk het systeem implementeren en falen. (Managementsite, Wat is Scrum & Agile)

Het hogere doel is zo snel mogelijk tot een succesvolle en klantgerichte oplossing te komen dat waarde levert voor gebruikers en de business. Aanvankelijk werd Scrum voornamelijk gebruikt in de ICT wereld. De methode is ontwikkeld om het mislukken van kostbare ICT projecten te voorkomen. Nu wordt Scrum en specifiek Agile gebruikt bij een grote diversiteit van veranderingen en projecten.

Wat zijn de voorwaarden voor werken volgens de Scrum methodiek?

• De opdrachtgever moet begrijpen en onderkennen dat de Scrum methode draait om het creëren van klantwaarde in plaats van het voldoen aan een vooropgezette planning en scope beschrijving.

• Er is 1 werkbudget. De valkuil van werken met deelbudgetten is dat je budgetten aan het verantwoorden bent en niet zozeer output.
• Er is geen druk van een eindig budget en datum bij livegang van een eerste release. Scrummen is namelijk gericht op zo snel mogelijk live gaan met een MVP (Ensie, Minimal Viable Product) en optimaliseren door te leren.
• Werk met een dedicated team dat minimaal drie dagen per week op het project werkt op dezelfde locatie bij elkaar in 1 kamer. Dit om de onderlinge cohesie en synergie binnen de diverse rollen van het team te bevorderen.

• Er moet een zeker mate van Scrum kennis binnen je team aanwezig zijn. Een jong Scrum team qua volwassenheid zal een grote leercurve hebben om de Scrum methodiek eigen te maken. Geen kennis binnen het team brengt te veel vertraging en verspilling van kosten op.
• Een betrokken Product Owner met mandaat maakt onderdeel uit van het team. Hij is meerdere dagen per week, gedurende een lange periode beschikbaar en is fysiek bij de rest van het team aanwezig. Voorwaarden voor een goede Product Owner zijn dat hij moet kunnen handelen vanuit de 3 pijlers: ‘business’ (domein kennis is essentieel), ‘design’ (denken vanuit de gebruiker) en ‘techniek’ (basiskennis over techniek is een vereiste). En daarnaast mag ook voor deze rol enige Scrum kennis verwacht worden.

Indien je niet met zekerheid kunt zeggen dat aan bovengenoemde voorwaarden voor Agile werken en Scrum wordt voldaan, stap dan niet in de valkuil het te gebruiken en kies liever direct voor een andere vorm, zoals Waterval of voor een andere Agile methodiek als Kanban. Laat je niet verleiden tot het werken in een hybride vorm onder het motto ‘laten we er het beste van maken’. Dit leidt zeker tot een onsuccesvol project, omdat deze hybride vorm vrijwel altijd een fixed deadline en budget en als je echt pech hebt ook een fixed scope heeft.

Manage direct de verwachtingen

Je opdrachtgever heeft altijd een bepaalde verwachting van wat hij krijgt, terwijl met Scrum een inspanningsverplichting geldt. Hij heeft immers al een idee wat de oplossing gaat worden en heeft vooraf een inschatting gevraagd van de effort die het kost tot het benodigde product te komen. Blijf weg uit deze discussie. De opdracht aan het projectteam is optimale waarde creëren voor de gebruiker en vooraf kan niet worden vastgesteld wat het eindproduct is. Maak dit duidelijk aan je opdrachtgever en leg ook uit waarom dit zo is.

Aan de andere kant heb je te maken met het projectteam. Een valkuil van Scrum is dat in het projectteam het gevoel bestaat dat dingen niet af hoeven en dat er geen omlijnde scope beschrijvingen nodig zijn; de bekende ‘open eindjes’. Je team conformeert zich tijdens de sprint planning wel degelijk aan een hoeveelheid werk. Dat ze dit halen door het versimpelen van de oplossing is natuurlijk geen probleem. Deze keuze en verantwoordelijkheid ligt bij het team. En de scope omschrijving? Dat zijn de user stories. Die moeten zo gedefinieerd worden dat helder is wat een gebruiker nodig heeft. De wijze waarop, wordt door het team ingevuld.

Besteed hier tijd en aandacht aan met het gehele team, definieer acceptatiecriteria en omschrijf wanneer een user story door de Product Owner geaccepteerd wordt (definition of done / DoD) en zorg ervoor dat ze er niet alleen zijn, maar dat deze ook kwalitatief zijn. Lees meer hierover in het artikel van Agile Scrum Group, Wat is DoD?.

Spreek dezelfde taal

Werk volgens 1 filosofie, kies met je team welke boeken je leest en dreun samen het Agile manifesto op. In andere woorden: zorg dat je dezelfde taal spreekt en dat iedereen het belang ziet van de regels die je met elkaar hebt. Boeken en visies die mij aanspreken zijn: The Scrum guide (Ken Schwabe en Jeff Sutherland), Large Scale Scrum (LeSS) (Bas Vodde en Craig Larman), Scrum, tweemaal zoveel doen in de helft van de tijd (Jeff Sutherland) en The lean startup (Eric Ries).

Heb een duidelijke stip op de horizon

Helderheid over de roadmap en inzicht in ‘wat is maximale output’ wijst het team continu op het grotere doel. Door dit doel regelmatig te toetsen bij je team, check je of het team nog op het juiste pad zit. Wat hierbij helpt, is het hebben van een mantra. Laat de Product Owner in een paar krachtige woorden de visie, ambitie en doelen van het project omschrijven en maak dit goed zichtbaar in de projectkamer. Neem hierin ook mee of de focus ligt op het creëren van gebruikswaarde, het snel opleveren van code of wat anders. En bedenk je steeds: wanneer je het team een (haalbare) uitdaging geeft dat leidt tot een helder resultaat, gaan ze vanzelf hard rennen. En herhaal, herhaal, herhaal.

Zorg voor balans

Zorg dat een evenwichtige balans is tussen design, UX (user experience), techniek en testen. Indien de focus teveel op een van de vier ligt, ontstaat een gat. Je merkt dat het onderdeel dat minder focus heeft, minder urgentie krijgt met als gevolg minder beschikbaar budget en verlies op kwaliteit en uiteindelijke output. In het begin zal dit nog niet zo’n groot probleem opleveren. Maar uiteindelijk leidt het tot achterstand en gebrek aan fundament om het product kwalitatief goed door te kunnen ontwikkelen.

Besef met elkaar dat ruimte om na te denken ook werk is. Af en toe naar het plafond staren om na te denken over de ideale oplossing is onmisbaar voor een goed resultaat. Als je puur focust op produceren, slaat het team dood. Onderken daarnaast dat meetings, sparring en plannen maken ook als output geldt. Bepaal samen met het team hoe hiermee om te gaan. Je kunt het bijvoorbeeld opnemen in de user stories of resources reserveren buiten de sprint werkzaamheden om.

Organiseer vaste team evenementen

Vaste team momenten zijn essentieel om transparantie in voortgang en belemmeringen te krijgen en heldere communicatie te realiseren, zowel binnen als buiten het projectteam.

De Scrum methodiek kent de volgende evenementen:

• sprint planning: bij aanvang van iedere sprint wordt het werk dat gedaan moet worden in een sprint ingepland. Bij deze meeting is het gehele team aanwezig. Er wordt bepaald:
  • Wat kan de aankomende sprint gedaan worden?
  • Hoe zal het geselecteerde werk uitgevoerd worden?

Lees meer hierover in het artikel van Scrum Guide, Scrum sprint planning.

• stand-up: iedere werkdag start het team samen op tijdens de stand-up. Alle teamleden geven aan wat ze de vorige werkdag hebben gedaan, wat ze vandaag gaan doen en wat eventuele beperkingen zijn die opgelost moeten worden, voordat ze verder kunnen (impediments). Dit event vindt staand plaats omdat het kort, maximaal 10 minuten, mag duren.
• backlog refinement: Ik werk over het algemeen in 2-wekelijkse sprints. Iedere 2de week van de sprint vindt de backlog refinement plaats, oftewel de voorbereiding van de komende sprint(s). Iedere rol binnen het team is bij dit evenement aanwezig. Je loopt samen door de backlog heen en bepaalt welke voorbereidingen nog getroffen moeten worden, voordat met een user story gestart kan worden. Denk hierbij aan uitwerken van design, het ophalen van input bij stakeholders en technisch onderzoek.
• demo: het moment waarop het team het geklaarde werk van de afgelopen sprint presenteert aan de stakeholders en sponsor. Let op: alleen het werk dat afgerond is volgens de DoD wordt gepresenteerd.
• retrospective: de evaluatie met het gehele team na afronding van iedere sprint. Let op: definieer samen heldere acties.

2. Zorg voor de juiste teamsamenstelling

De kern van Scrum is een multidisciplinair en zelfsturend team. Samen pakt het team het project op. Iedereen is betrokken bij het plannen, benoemen van blokkades en het verdelen van de taken. Daarbij gaat Scrum ervan uit dat de benodigde kennis in het team zelf aanwezig is.

Diversiteit binnen je team is ontzettend belangrijk. Diversiteit zit hem in persoonlijkheid (extravert vs introvert), expertise (design vs techniek), focus (UX vs techniek) en ervaring (junior vs senior). Ik merk dat dit vaak een onderbelicht onderwerp is en dat je ‘moet roeien met de riemen die je krijgt’. Als Scrum Master ben jij degene die het laatste woord heeft in de teamsamenstelling. Zorg dat je ruim research doet naar de ideale samenstelling en neem afscheid en trek nieuwe mensen aan indien nodig. Maar leg het ook bij je team neer. Zij moeten immers samen de boot besturen. Indien zij de teamsamenstelling niet meer voldoende ervaren om tot het beste resultaat te komen, moeten ze aan de bel trekken. Geef ruimte om dit bespreekbaar te maken.

Mijn uitgangspunt is dat een vast team, van maximaal 8 personen – zodat mensen elkaar blijven vinden – en maximaal 3 individuen op 1 discipline bijdraagt aan de efficiency. En indien nodig kun je per discipline tijdelijk opschalen. Dit is alleen relevant indien efficiency een gedefinieerd doel is.

Pas op met rollen als architecten en business analisten binnen je project. Dit soort rollen zorgt ervoor dat de ownership buiten het kern projectteam kan komen te liggen. Bekijk of teamleden deze rol kunnen vervullen. Indien dit niet mogelijk is, kan de Product Owner deze rollen, wanneer nodig, als externe stakeholders aan laten haken.

Zorg voor een duidelijke rolverdeling

Binnen agile projecten zijn de Product Owner en de Scrum Master de sleutelrollen tussen de strategie van de organisatie en het projectteam dat verantwoordelijk is voor de realisatie.

Een heldere rolverdeling en inzicht in verantwoordelijkheden per rol geeft duidelijkheid. Zo weet iedereen wat van hem verwacht wordt en kan men elkaar aanspreken indien er van afgeweken wordt. Het benoemen van deze rollen en verantwoordelijkheden is bij mij altijd onderdeel van de kick off. Ik laat mijn teamleden dit zelf invullen, zodat ze ook gedwongen worden hier zelf over na te denken.

Een complexe rol is die van de Product Owner. Vaak komt deze persoon uit de business en mijn ervaring is dat het dan lastig kan zijn een brug te slaan naar techniek. Is dit het geval, zorg dan dat pijler ‘techniek’ door iemand anders wordt opgepakt. Dit kan zowel iemand zijn binnen het team als een externe. Ben je er wel van bewust dat de toegekende Product Owner eindverantwoordelijke blijft van het product en de kwaliteit ervan.

De Product Owner moet zich bewust zijn van investeringen, oftewel ‘het prijskaartje van een story’. Hij moet een gevoel krijgen / hebben van de impact van een story en de oplossing ervan. Bijvoorbeeld kan het de ene keer de investering waard zijn een complexe functionaliteit te ontwikkelen, een andere keer kan een eenvoudige oplossing ook passend zijn. Hij moet deze keuze ook aan zijn stakeholders kunnen uitleggen. Hiervoor consulteert de Product Owner zijn team en wordt hierin bijgestaan door de Scrum Master.

De rol van de Scrum Master is puur faciliterend. Hij organiseert de vaste team evenementen, lost impediments op, door de juiste vragen te stellen en mensen bij elkaar te halen, behoudt de sfeer, bemiddelt indien er problemen zijn en adresseert risico’s. En zorgt voor een gezond spanningsveld tussen de Product Owner en het team. Goed om te blijven beseffen: de Scrum Master is niet verantwoordelijk voor wat opgeleverd wordt.

Let op dat bij de toekenning van de rol van Product Owner of Scrum Master een van de twee personen de technische vragen moet kunnen stellen aan het projectteam

3. Maak je team eigenaar van het product

Creëer een context dat eigenaarschap stimuleert

Besef je dat mensen betrokken, gehoord en gezien willen worden. Je spreekt indirect je waardering uit wanneer je mensen betrekt. Via interactie bewerkstellig je dit en creëer je eigenaarschap. Het gevoel en hebben van eigenaarschap binnen het team is essentieel om tot het beste resultaat te komen. Creëer daarom vanaf het begin een context waarin je eigenaarschap stimuleert.

Maak je team echt eigenaar

Mensen zijn intrinsiek gemotiveerd op het moment dat iets van hen is. De Scrum Master is er om de kaders (randvoorwaarden) te schetsen, het ‘hoe’ laat je aan je team over. Jij moet bedenken wat ze nodig hebben om hun werk optimaal te kunnen doen. Maak het team vervolgens end to end verantwoordelijk voor het opleveren van het product. Zorg dat alles wat nodig is voor de integrale ontwikkeling van het product binnen het team wordt opgepakt. Denk dan aan copy en beeldmateriaal. Dit resulteert in minimale afhankelijkheid en eigenaarschap binnen het team. Bepaal vooraf met je team waar de end to end verantwoordelijkheid van je (autonome) team eindigt.

Durf je team los te laten

Juist als het spannend is, moet je het gesprek aangaan. Luister en stel open vragen. Geef geen oplossingen, maar bevraag je team wat ze in deze situatie zelf zouden doen en laat het vervolgens los. Geef mensen de mogelijkheid het te doen. Om “fouten” te maken. Om het anders aan te vliegen dan dat jij het zou doen. En dat betekent ook dat je er niet elke dag om moet vragen en controleren.

Ben je ook bewust dat teams een transitie doormaken en dat hier tijd overheen gaat. Ze gaan van fase ‘werk’ (ik werk aan project a) naar ‘output’ (welke stories rond ik af) naar ‘outcome’ (mijn output leidt tot een echt product en ik creëer waarde). Geef je team de tijd hiervoor en coach ze waar je nodig acht.

Spreek mensen aan op gedrag

Mensen worden vaak niet aangesproken op gedrag, terwijl hier een belangrijke sleutel ligt. Ik betrap me er zelf ook wel eens op. Maar bedenk dat elke keer als we het gesprek niet aangaan, we de boodschap geven dat het geoorloofd is geen eigenaarschap te pakken. Denk hierbij aan te laat komen, het niet afronden van de sprint en taken, een te groot gevoel van empowerment bij een individu en het niet signaleren en actief oplossen van impediments. Geef support aan mensen die eigenaarschap oppakken. Laat zien en vertel dat je het belangrijk vindt en waardeert als eigenaarschap opgepakt wordt.

Bedenk wat de intrinsieke motivatie van je teamleden is

Eigenaarschap pak je als je bewogen bent. Vraag eens aan je team wat ze drijft aan het project te werken en te doen wat ze doen? Wat maakt dat ze elke dag hun bed uitkomen om hier te werken? De drijfveer is de kern waarop mensen eigenaarschap pakken.

Durf afscheid te nemen

Het is een flinke stap, maar durf afscheid te nemen van mensen die zich niet houden aan de project- en teamregels en niet geloven in de gekozen filosofie en productvisie. In het begin kan dit leiden tot een daling van de output. Mijn ervaring is dat dit zich vanzelf herstelt.

4. Zorg voor heldere communicatie

Speel allemaal op hetzelfde veld

Een Scrum team moet elkaar kunnen ruiken en voelen. Zorg dat het team op 1 locatie werkt in een eigen projectruimte. Dit zorgt voor zo min mogelijk ruis in de communicatie en voor volledige focus. En het geeft je continu inzicht in voortgang en impediments.

Het helpt je ook om alles wat afleiding geeft buiten het team te houden. En dan heb ik het ook over die ene interne vraag, het aanschuiven bij een sollicitatiegesprek met een potentiële nieuwe collega of de hulp tijdens een pitch. Maak het team zelf verantwoordelijk dit te regelen. De Scrum Master is de poortwachter, mocht er toch afleiding binnensijpelen.

Zorgvuldige en open communicatie

Je moet een ecosysteem creëren, waarin het gehele team vaak met elkaar praat over hoe het gaat. Zorg voor gestructureerde team meetings met duidelijke agenda’s en houdt je hier ook aan. Maar het gaat niet alleen om de momenten dat het om de inhoud gaat. Net zo belangrijk is het persoonlijke vlak. Organiseer daarom geregeld een teamuitje. Het doel is elkaar te leren kennen en te begrijpen en daarmee onderling begrip te creëren. Je werkt immers met zoveel verschillende persoonlijkheden dat het tijd en energie kost elkaar te leren kennen. Maar bedenk dat indien je elkaar begrijpt, dit ten goede komt van de output.

Het team moet betrokken blijven bij projectontwikkelingen. Want betrokkenheid leidt tot kennis en daarmee focus op het doel van het eindproduct. Deel daarom relevante updates altijd met het team. Bedenk wel goed wat je wel en niet wilt delen. Zorg voor een goede afscherming van het team van politiek en stakeholder management. Irrelevante en ongefilterde informatie schaden de focus van je team.

Individuele aandacht

Persoonlijke aandacht kan mensen vleugels geven. Zoals eerder benoemd is het inzien van de intrinsieke motivatie van de individuen in je team van groot belang. Daarom praat ik afzonderlijk met mijn teamleden en bekijk ik hoe ik het persoonlijke belang kan afstemmen op het belang van de klant. Het lukt niet altijd, maar openstaan en luisteren helpt zeker om je teamleden te motiveren. Leg wel altijd uit wat je acties zijn en wat wel en niet haalbaar is.

En bovenal belangrijk: vier successen, momenten en mijlpalen!

5. Besteed aandacht aan stakeholders

Creëer continue urgentie

Zorg voor continue urgentie rondom je team, het project en het product. Manage verwachtingen. Mijn ervaring is dat de eerste 3 sprints onstabiel zijn, er ruimte moet zijn op de backlog voor het oplossen van technical of UX dept, denkwerk, overleg, gebruikersonderzoek en optimalisatie. Communicatie hierover is enorm belangrijk. Doe dit vaak, op een vast moment en maak de impact inzichtelijk en breng deze zo helder mogelijk in kaart. Een manier om dit te doen is het gebruiken van metaforen. Bijvoorbeeld: ‘met 9 vrouwen kun je niet in 1 maand van een gezond kind bevallen’ en ‘als je een uitbouw wil van je huis, start je niet direct met bouwen, maar investeer je eerst in een architect om een plan te maken’. Het klinkt misschien stom, maar het helpt mij complexe verwachtingen naar de realiteit te vertalen.

Heb een directe lijn met de sponsor

En last but not least: er moet een directe lijn zijn met de sponsor van het traject. Besef je dat zij niet bij de dagelijkse werkzaamheden betrokken zijn en dat ze 1000 dingen aan hun hoofd hebben, maar dat zij betalen en het daarom essentieel is dat deze mensen worden meegenomen en aangehaakt blijven. Ze moeten snappen wat het team aan het doen is en waarom ze dat doen. De belangrijkste tool die je hiervoor hebt is de demo, het moment waarop het team het geklaarde werk van de afgelopen sprint presenteert.

Plan daarnaast een vast moment in om de sponsor op hoofdlijnen bij te praten. Geef het op een presenteerblaadje indien het nodig is dat de sponsor ergens een besluit over neemt. Als Scrum Master help je de Product Owner om zijn stakeholders en sponsor te managen.