Het ideale SCRUM Team
SCRUM is hot, maar of het nu een zegen of een vloek is, daar zijn de meningen over verdeeld. Een van de belangrijkste key succesfactoren is het SCRUM Team. De inrichting van het team bepaalt het succes van het project.
Immers in SCRUM bepaalt het team zelf hoe ze de zaken op de Backlog gaan realiseren. Daarnaast zal hun tijd helemaal gereserveerd moeten zijn voor het werken aan het project in sprints. Het team wordt beschermt door de SCRUM Master tegen invloeden van buitenaf en het enige dat het team nog met de rest van de organisatie verbindt, is de Product Owner. Die af en toe nieuw wensen van uit de organisatie op de Backlog zet. Aan het eind van elke sprint presenteert het team aan de organisatie wat ze hoe hebben gerealiseerd. Ongestoord werken in zo’n SCRUM Team is natuurlijk best lekker projecten doen!
Voor de opdrachtgever zou het ook een zegen moeten zijn. Immers periodiek wordt de organisatie voorzien van nieuwe functionaliteit, nieuwe processen, nieuwe inzichten. Daarbij heeft de opdrachtgever altijd inzicht in de voortgang van het project op basis van de Velocity. Dat lijkt een prima opzet of toch niet?
Het klinkt natuurlijk heel fijn zo’n SCRUM Team, zo’n team dat helemaal zelfstandig werkt. Een team dat dus 100% gefocust bezig kan met nieuwe dingen en dus het verbeteren van je organisatie. De grote vraag is alleen hoe ga je dat team inrichten. Ga je allemaal nieuwe / externe specialisten inhuren om aan die verandering te werken of kies je je eigen toppers.
Het formuleren van een team met allemaal nieuwe / externe specialisten duurt lang en is best lastig. Daarnaast weet je ook niet wat voor vlees je in de kuip haalt. Tegelijkertijd lopen er in de meeste organisatie al genoeg toppers rond. Toppers die veel kennis hebben en die bovenal het meest weten wat past bij de organisatie en dus uitstekend kunnen bijdragen aan het project. Het enige issue is dat deze toppers ook nog hun eigen werkzaamheden hebben waar niet zo één twee drie een vervanger voor is. Meestal wordt er dan een alternatief plan gesmeed zodat de geselecteerde medewerkers half in het project kunnen werken zodat ze ook nog tijd over hebben voor hun normale werkzaamheden.
Dit is precies het punt waar de meeste ellende begint. Immers het SCRUM team zou autonoom moeten zijn en daardoor gefocust aan het werk moeten zijn met de punten die de Product Owner op de Backlog gezet had en de SCRUM Master zou het team moeten beschermen tegen in vloeden van buiten af
Met de introductie van team leden die niet volledig gefocust kunnen werken aan het project ontstaat er een situatie waarbij bepaalde teamleden in het team andere prioriteiten hebben. Deze prioriteiten kunnen vaak niet door de SCRUM Master weggenomen worden, immers de prioriteiten van de daily business zijn andere prioriteiten dan die gelden voor het project. Daarnaast zal de Product Owner niet meer de enige zijn die contacten heeft met de rest van de organisatie. Daarnaast zullen andere leden van de organisatie proberen om de meewerkende team leden te beInvloeden om punten voor hun te realiseren.
Er ontstaat dan een situatie waarbij het team niet meer autonoom kan werken, waarbij de SCRUM Master het team niet meer kan beschermen en de Product Owner niet meer de enige is die de belangen prioriteert.
Tip:
- Neem tijd voor het formuleren van je SCRUM team. Zoek niet allen goede specialisten voor in het team maar ook ter tijdelijke vervanging van bestaande medewerkers zodat je die volledig kan vrijmaken voor het team.
Op de hoogte blijven?
Schrijf je dan in voor de periodieke Virtual BA update en krijg een bericht zodra er weer een nieuw artikel is.
Using ChatGPT for Process Modeling: Flowcharts, Sequence Diagrams, and More
In my last post, I shared how you can use ChatGPT to generate user stories. But did you know that ChatGPT is also highly effective for creating flowcharts, sequence diagrams, and other essential diagrams for Process Modeling? Creating diagrams is a core skill for...
Het schrijven van User Stories met ChatGPT
Sommige mensen denken dat het schrijven van user stories hetgeen is waar Business Analisten (BA's) het meest van genieten. Per slot van rekening bestaat een groot deel van het werk van BA’s uit user stories, epics (grote verhalen), of soms PowerPoint-presentaties, die...
Omgaan met Wettelijke Requirements
u
Hoe je je Epics Episch maakt
Een Epic is een user story die niet binnen één sprint te ontwikkelen is, is een vuistregel die veel projecten hanteren om Epics te identificeren. Als je het mij vraagt ben je dan eigenlijk net te laat en mis je heel veel aspecten van een Epic waarmee je effectief je...
Type Business Analyses
3 Situaties die baat hebben bij een Business Analyse In dit artikel leg ik uit in welke situaties een Business Analyse toegevoegde waarde biedt en waarom. Digitalisering van bedrijfsprocessen Integratie van verschillende systemen Introductie nieuw product of...
10 Tips for creating perfect User Stories
Often it is believed that a perfect User Story is written like: “As a user X I want to do Y So I can achieve Z”. Some people also believe that this is all what needs to be written down for a development team to create the right results. Therefore, it is not surprising...