Hoe herken je dat de Agile/Scrum implementatie niet helemaal gelukt is of zelfs mislukt? Bij 5ST3PS worden we vaak gevraagd voor zogenaamde Second Time Right opdrachten. De organisatie is niet tevreden hoe de Agile/Scrum implementatie is verlopen en kan er niet de vinger opleggen waar dat aan ligt. Vanuit 5ST3PS zijn we dan alert op een aantal signalen die aangeven dat er iets niet is goed gegaan en die voor ons vallen onder de welbekende Klok en Klepel.
1. De burn-down is een Fall-down en heeft de vorm van een Noorse Fjord.
Als je aan het einde van de Sprint ziet dat ineens de story points worden opgebrand, dan heb je vermoedelijk te maken met het studenten syndroom waarbij het team tegen de deadline begint op stoom te komen. Dan is het de vraag waarom het team niet gelijkmatig heeft opgeleverd en of wat is opgeleverd aan het eind van voldoende kwaliteit is en niet zoals sommige studenten doen bij een deadline opleveren in de ijdele hoop misschien wel een voldoende te krijgen.
2. Wat overblijft aan het einde van de sprint wordt doorgeschoven naar de volgende sprint.
Als je aan het einde van de sprint bij wijze van spreken 90% gereed hebt, dan heb je voor de business 0% opgeleverd, omdat de business 100% nodig heeft om verder te kunnen. Vraag is dan of de inschatting te optimistisch was of dat het team nog denkt vanuit inspanningen in plaats van concrete resultaten.
3. Er wordt heel veel opgeleverd: vooral papier.
Ik was eens bij een organisatie die keurig het werk in Sprints had georganiseerd en elke sprint een deliverable opleverde. Na de eerste sprint het Requirements Document. Na de Tweede Sprint de Impact Analyse. Na de derde Sprint het Functioneel Ontwerp. En ga zo maar door. Feitelijk deed deze organisatie wat ze vroeger ook deden in hun waterval ontwikkel methodiek, alleen nu in een timebox in plaats van een stage. Agile wil zeggen dat je empirisch kennis verwerft door iets te maken in plaats van een papieren werkelijkheid te creëren.
4. De product owner heeft geen mandaat in de organisatie.
De Product Owner heeft een duidelijke visie op wat waarde is voor de klant en de organisatie. Dat betekent dat de Product Owner beslissingen moet kunnen nemen wat wel en wat niet te doen. Als de Product Owner geen mandaat heeft, dan kan hij in een positie terechtkomen dat hij geen richting kan geven aan het ontwikkelteam. Ontwikkelteams zullen dan zich niet kunnen focussen, helemaal als stakeholders de Product Owner passeren en direct invloed gaan uitoefenen.
5. De scrum master gedraagt zich als een directieve projectleider/projectmanager
Een scrum master faciliteert en coacht het ontwikkelteam. We kennen ook de directieve projectleider/projectmanager die vooral aangeeft wat er moet gebeuren en erop toeziet dat de resultaten gehaald worden. Zoals een oud-collega projectmanager van me altijd zei: vertrouwen is goed, controle is beter. Als je een dergelijke projectmanager nu omvormt naar scrum master, dan kan dat problemen opleveren in oud gedrag nu het team zelf verantwoordelijk is en je niet wilt dat het team de scrum master aankijkt voor wat er gedaan moet worden.
6. Cherry picking in het ontwikkelteam.
Het team bepaalt zelf de volgorde van het werk en dat kan er dan voor zorgen dat de makkelijkste taken als eerst worden gedaan. Ook kan het gebeuren dat ontwikkelaars datgene doen wat ze leuk vinden in plaats van wat noodzakelijk is. Hoewel in Agile ontwikkelen er relatief gezien veel vrijheid is voor de ontwikkelaars, is de manier van werken daarmee nog niet vrijblijvend.
7. Werkpaardjes en sierpaardjes in het ontwikkelteam.
Klassiek is het verhaal van het kip en het varken. Zelf gebruik ik de Werk- en de Sierpaardjes. Dan zie ik in een ontwikkelteam aan de ene kant de mensen die het werk doen. En aan de andere kant zie ik dan de mensen die vooral ‘input’ leveren. Vervolgens moet deze ‘input’ verwerkt worden door de mensen die het werk doen. Zo kwam ik eens in een team terecht waar men speciaal een externe programmeur had ingehuurd die vervolgens door de twee interne collega’s werd ‘gecoacht’ voor het programmeren. En die twee gingen dan weer andere dingen doen.
8. User stories worden heen en weer gemept tussen de Product Owner en het Ontwikkelteam.
De Product Owner is verantwoordelijk voor Wat er moet worden opgeleverd. Het ontwikkelteam is er verantwoordelijk voor dat het wordt opgeleverd en daarmee verantwoordelijk voor het Hoe. Soms willen Product Owners zie ook met het Hoe bemoeien en soms willen ontwikkelteams zich van de spreekwoordelijke domme houden door aan te geven dat de user story niet duidelijk is en dat dat de taak is van de Product Owner. Ook hier geldt de regel Mensen en Interactie boven Processen en Tools.
9. Er wordt per saldo wel meer opgeleverd, maar de innovatieve ideeën blijven uit.
Door het werken met timeboxes en de harde deadlines zul je als je dit aspect goed hebt geïmplementeerd meer opleveren, desnoods omdat ontwikkelteams overwerken om de deadline te halen. Vraag is of als teams structureel overwerken om de deadlines te halen of dat voor de lange termijn wenselijk is. Agile is echter ook een manier om creativiteit uit de ontwikkelaars te halen en daarmee op verfrissende nieuwe ideeën en zelfs wel innovaties te komen. Als die uitblijven, is de vraag of de ontwikkelaars de ruimte krijgen creatief te zijn, of dat ze vooral productie leveren volgens vastgelegde stramienen.
10. Er wordt feitelijk niet gewerkt met punten maar met uren.
In sommige organisaties zie je dat de puntentoekenning gekoppeld is aan de uren die men denkt te besteden. In Scrum wil je juist het niet hebben over uren omdat ureninschattingen onbetrouwbaar zijn en het mensen eigen is slack in te bouwen. Nu heb je de slack dan indirect terug in de punten waardoor er meer effort wordt ingeschat dan werkelijk nodig is wat ten koste gaat van het opleveren van business waarde.
Zelf leren?
Wil je leren hoe je Scrum wél goed toepast? Volg dan onze opleiding tot Scrum Master of Product Owner. Tijdens onze opleidingen maken we gebruik van echte casussen en is er voldoende ruimte om jouw situatie in te brengen. Bovendien hebben wij een database met honderden oefenvragen, zodat jij je optimaal kunt voorbereiden op het officiële examen!
Meer info?
Je kunt ook vrijblijvend contact opnemen met info@5st3ps.nl.
