Projecten aansturen zonder wendbaarheid te verliezen

Haarlemmerolie 1: laten we van alles een project maken

Waar 10-15 jaar geleden projectmatig werken in een organisatie nog bijzonder was, zo ongeveer alleen

Nederlands: Reclamekaart: De eenige oprechte H...

voorbehouden aan grote organisaties die zich dure projectmanagers en een projectbureau konden veroorloven, heet tegenwoordig teveel ‘project’ en verlangt menigeen voor elke opdracht die langer dan een dag duurt een plan van aanpak, rapportages en een projectleider. We zijn bijna vergeten, dat er ook nog productiewerk, procesmatig werken of tijdelijke opgaven bestaan die helemaal niet gebaat zijn met een gestructureerde projectmanagement aanpak.

Haarlemmerolie 2: laten we alles Scrum ‘aanvliegen’

Evenzo is Agile, sterker nog één voorkomen ervan: Scrum, tegenwoordig het buzz word binnen organisaties om (tijdelijk) werk te organiseren. Wendbaarheid klinkt beter dan strak, star en bureaucratisch.

Wat licht is, licht houden

Scrum als raamwerk of voorschrift is vederlicht. 3/3/3 – 3 rollen (ScrumMaster, Product Owner en Ander  / Ontwikkelaar), 3 Artifacts (Burndown, Product Backlog, Sprint Backlog) and 3 gebeurtenissen (Sprint Planning, Daily Stand-Up, Sprint Review). De principes kun je je in 10 minuten eigen maken. Na een 2-daagse training en examen mag je jezelf Certified Scrum Master noemen. En de officiële Scrum Guide van Scrum.org (De definitieve gids voor Scrum: de regels van het spel) is met 16 pagina’s lekker leesbaar.

Maar in de trainingen wordt meer onder Scrum geschaard dan voorgeschreven in de Scrum Guide. Voorbeelden zijn spikes (onderzoeksopdrachten), grooming (regelmatig onderhouden van de product backlog) en refactoring (herschrijven van te moeilijke, foutgevoelige programmatuur door voortschrijdend inzicht). Ook in de 1 augustus 2012 besproken The Scrum Papers valt dat op: veel extra zijstappen die uit de wereld van Extreme Programming en Kanban komen. Het Agile Manifesto jaren na de totstandkoming van Scrum door de founding fathers onderschreven, blijft een belangrijke referentie voor de praktijk die zo graag wendbaar gehouden wordt:

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we  

  • Mensen en hun onderlinge interactie boven processen and tools
  • Werkende software boven allesomvattende documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  • Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

De scheiding dus Scrum.org (de organisatie achter de Scrum Guide, met Ken Schwaber) en ScrumAlliance (met Mike Cohn)  kan alleen maar om macht en geld draaien. Bij Scrum.org kun je trainingen volgen om je kennis te laten waarderen en titels te verdienen als Professional Scrum Master, Professional Scrum Developer, Professional Scrum Product Owner en een Enterprise Assessment. De basis is de Scrum Body of Knowledge, ofwel de Scrum Guide.

Scrum Master

Via ScrumAlliance heet je anders: Certified Scrum Developer, Certified Scrum Master, Certified Scrum Product Owner, Certified Scrum Professional, Certified Scrum Trainer, Certified Scrum Coach. Nog los van het business model achter deze 2 organisaties zie je het al gebeuren: in rollen die niet eens in het raamwerk staan beschreven, kun je jezelf professionaliseren. Op z’n minst boeiend, maar om eerlijk te zijn: beschamend en onprofessioneel!

Waarom moeilijk doen?

Persoonlijk ben ik voor het zo compact mogelijk houden van de gekozen aanpak om een projectopdracht te kunnen vervullen. De PRINCE2 Manual begint bewust met de oproep de methode op smaak te maken en te schalen voor jouw project. Ordina bedacht voor het uitgebreide Rational Unified Process van IBM een RUP op Maat: overzichtelijk en hanteerbaar. En met combinaties van PRINCE2 en RUP of Scrum heb ik goede ervaringen.

Recent ontdekte ik de Cubrix van Marcel van Marrewijk. De boekbespreking heb je nog tegoed. Ook daar is de bottomline: zoek een aanpak die past bij het complexiteitsniveau en de context van je opdracht. Maak het niet te moeilijk. De wereld om je heen is toch maar beperkt maakbaar.

Wees wendbaar, zet een aanpak niet op een voetstuk

Gedragsverandering is tijdrovend en in organisaties vaak kostbaar. Ervaring spreekt. Een treffende uitspraak trof ik bij Johanna Rothman.

I can sympathize with management wanting to cap their expenses transitioning to agile. And, training project managers as trainers who have no experience in agile is not a cost-effective way to create a successful transition. Neither is training managers with no experience. The problem is this: in order to teach agile, you need experience doing it so you can diagnose the problems as you see it in the training, because there is no recipe.

There is no recipe because every team of people is unique. There may be common patterns of pitfalls, but how each team solves those problems is often unique to their context.

This is a problem. It means that in one organization you might not have just one definition of agile if one project has silo’d teams across the world and another project has cross-functional teams in one location. The definition will come from the people on the team who will discuss what done means for them, and how they will handle the issues of where the people are, and how to manage the deliverables. The team members will lead from within the team.

En Ken Schwaber waarschuwt:

Scrum is like your mother-in-law. It’s constantly pointing out your shortcomings. The trick is that you’re supposed to learn from that feedback and fix your problems.

Wees bescheiden, zo roept Maxwell Daemon’s blog op. Agile is géén Haarlemmerolie. Het gevaar als kind met badwater weggegooid te worden, is groot.

I am a fan of agile development in general because the Agile movement formally questioned and rejected the dogma of how software development should be done and, in particular, challenged the continuously failing waterfall model. Agile is just a step along the way and isn’t without fault and dogma itself. We sorely need to keep moving towards improving our understanding of successful software development.

 

Enhanced by Zemanta