Scrum is gewoon ouwehoeren met elkaar

Gisteren gaf ik een Scrum cursus aan een groep en ik hoorde mezelf in reactie op vragen steeds zeggen “Scrum is gewoon ouwehoeren met elkaar!”.

Toen ik ‘s avonds thuis kwam dacht ik daar nog eens over na. Klopte het eigenlijk wel wat ik zei? In ieder geval past het prima in het Agile Manifesto. We have come to value Interaction over Documentation. Maar het is natuurlijk ook wel wat eenzijdig.

Veel van de vragen gingen over documentatie. De deelnemers wisten nog heel weinig van Scrum of Agile maar hadden al wel ergens de klok horen luiden. “Bij Agile hoef je geen documentatie meer te schrijven”. Dat is in ieder geval een groot misverstand. Ja, het is waar, het is Agile om minimale documentatie op te leveren. Maar het is ronduit onprofessioneel en slecht vakmanschap om dat te vertalen naar geen documentatie! Agile is een prima tegenreactie op het schrijven van wat ik al jaren write-only documentatie noem. Documentatie die gezien wordt als een verplichte deliverable, maar waarbij niemand er echt over nadenkt wat de doelgroep is van de documentatie.

Meestal wordt technische documentatie gezien als voorwaarde voor goed onderhoud. Als het oorspronkelijke ontwikkelteam er niet meer is en anderen moeten het onderhoud doen, dan hebben we documentatie nodig. Daar valt wel iets voor te zeggen maar ook veel op af te doen. De praktijk leert dat ontwikkelaars bij onderhoud niet of nauwelijks grijpen naar documentatie maar meteen de source code induiken. En dat is meestal terecht. Ten eerste is documentatie vaak niet consistent met de code en daarmee waardeloos. Als slechts 5% van de documentatie niet up-to-date is leidt dat tot 100% wantrouwen in de documentatie. Dus hier geldt: òf je doet het echt goed, òf je kan het beter laten. Ten tweede is documentatie vaak veel te gedetailleerd (wat natuurlijk een belangrijke oorzaak is voor het eerste probleem). De echte detailinformatie over de code hoeft ook niet gedocumenteerd te worden. De code kan daar zelf het werk wel doen. Wat wel heel nuttig is in documentatie is the big picture. Hoe hangt alles samen? Wat is de structuur? En het meest belangrijke, maar ook het moeilijkste is de vraag “wat was de intentie van dit design?”. Waarom is het systeem op deze manier opgezet?

Alistair Cockburn toont in zijn boek “Agile Software Development – The Cooperative Game” duidelijk aan dat er grenzen zijn aan wat zich laat documenteren. Hij noemt hierin een bijzonder sterk beeld van de (taal)filosoof Ludwig Wittgenstein, die de volgende vragen stelde: “probeer eens een bepaalde stoel aan anderen te beschrijven” en “probeer eens het geluid van een klarinet te beschrijven”. Het eerste zal wel redelijk lukken, jouw mental image kan je redelijk goed op anderen overdragen. Maar het tweede is nagenoeg onmogelijk. Er zijn dus blijkbaar zaken die niet te beschrijven en dus ook niet te documenteren zijn.

Vervolgens haalt Cockburn wetenschappelijk onderzoek van Pelle Ehn aan. Pelle bestudeerde adaptief onderhoud van software systemen. In het ene geval moest het team dat onderhoud deed zich geheel verlaten op de beschikbare documentatie. In het andere geval was er nog toegang tot het oorspronkelijke team. In het tweede geval was die situatie uiteraard beter. Maar het interessante is de reden waarom. Het oorspronkelijke team kon steeds in zeer korte tijd aangeven op welke manier uitbreidingen in de structuur en het concept van het bestaande systeem pasten. Dat was op basis van de documentatie niet mogelijk. En deze documentatie was in principe goed opgezet. De context was een volwassen organisatie met professionele design standaards en up-to-date documentatie. Maar, de klank van de klarinet kan niet gedocumenteerd worden.

Terug naar “gewoon ouwehoeren met elkaar”. Natuurlijk is dat een eenzijdige versimpeling van Scrum. Maar om een Pavlov-reactie tegen te gaan – “we kunnen toch zeker niet zonder documentatie” – moet je wel eens overdrijven. Documentatie is goed, maar er gaat niets boven communicatie.

PS. Op 4 november geef ik een Intro cursus Agile in Houten

Picture uploaded from Flick, originally uploaded by The Infatuated

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in Scrum and tagged , , . Bookmark the permalink.

8 Responses to Scrum is gewoon ouwehoeren met elkaar

  1. Via LinkedIn kreeg ik onderstaand commentaar van Jan Jaap Cannegieter. Hier ga ik graag op in.

    Kun jij je nog herinneren dat ik je laatst belde over Scrum? Volgens mij is Scrum een heel goed gedefinieerd, gestructureerd proces. Met goede user requirements in de vorm van user stories, planningspoker, burndown charts, plan boards, goed gedefinieerde rollen etc. Tuurlijk wordt er door de multidisciplinaire teams en stand up meetings veel geouwehoerd, maar dat is niet anders dan in waterval projecten. Scrum is GEEN excuus-truus om software engineering best practices overboord te gooien! Fijn weekend!

    Hoi Jan Jaap,
    Scrum is geen excuus-truus. Helemaal mee eens. Maar Scrum is wel echt anders dan traditioneel ontwikkelen. En dat wordt vaak niet helemaal toegegeven. Er worden veel artikeltjes geschreven waarin een mapping wordt gemaakt van Scrum naar Prince2 of naar CMMI, en dan lijkt het alsof Scrum niets nieuws is. Daarmee ben ik het fundamenteel oneens. De mapping tabelletjes kloppen vaak wel. Op het niveau van practices is Scrum wel compatible met oudere aanpakken. Maar op het niveau van de achterliggende principes is er wel een groot verschil.
    Op één van die principes ga ik in deze blog in. In traditionele projecten wordt interactie (“het ouwehoeren”) als inferieur gezien. Met elkaar praten mag, als het erna maar grondig gedocumenteerd wordt.
    In Agile projecten is het net andersom: documenteren mag, als er ook maar grondig met elkaar gesproken wordt.
    Documentatie is altijd beperkt. Het is een vorm van communicatie waarin zeer veel wordt weggefilterd. Alleen in een face-to-face gesprek krijg je echt de intentie van de ander te pakken. Na dat gesprek wordt in Scrum de essentie vastgelegd in een user story. Die hoeft niet als een grondige requirement beschreven te zijn (compleet, niet-ambigu, etc.). De documentatie dient alleen als een reminder om ons het gesprek te herinneren. Als deze user story in de komende sprint (dus de komende 3 weken) wordt geïmplementeerd is dat in vrijwel alle gevallen voldoende.
    Vroeger – in waterval projecten – was dat niet voldoende. Er zaten maanden tussen de requirements discussie en de implementatie. Nu – in Scrum – is dat geen probleem.
    De wereld verandert Jan Jaap – ga je mee?

    • Jan Jaap Cannegieter says:

      Beste André,

      Bovenstaande toelichting vind ik veel genuanceerder dan je eerste verhaal. Voor de goede orde: ik ben groot fan van Agile, mits het goed gebeurt. Ik krijg jeuk van teams die iedere dag stand-up meetings doen en dan zeggen dat ze Scrum doen. Dat is geen Agile maar zinloos. Doe het goed of niet. Halverwege jaren ’90 heb ik een project met RAD gedaan, multi-disciplinaire teams, korte time boxen, juicy bits first etc. Fantastisch.
      Agile kan ook heel goed werken, maar goed gereedschap in onkundige handen kan ook heel gevaarlijk zijn.
      Kortom: ik ga mee, maar doe het dan wel goed.
      Jij ook?

      Groet!

      Jan Jaap

      • Hoi Jan Jaap,

        Misschien worden we het nog wel eens eens met elkaar 😉
        Je laatste zinnetje blijft bij me hangen “doe het dan wel goed”. Dat klinkt een beetje als een open deur, maar ik vrees dat er zich achter die deur van alles kan verbergen.
        Is “goed” dat we alle oude engineering principes blijven vasthouden en in Scrum projecten ook meenemen? Dus tijdens een sprint een FO en een TO schrijven? Requirements volgens alle regelen der kunst uitwerken in dikke specificaties? Naast de stand-up meetings ook nog eens wekelijks voortgangsverslagen schrijven met stoplichtrapportages? Met zoveel ballast kom je niet echt ver in een sprint van 3 weken!
        Of is “goed” dat we in alle gevallen alle Scrum practices moeten toepassen. Ook daar wil ik wel graag oproepen tot nadenken. Ik herken je beschrijving van een “Scrum-but” implementatie – “we doen stand-ups dus we doen Scrum”. Maar soms kunnen de omstandigheden vereisen dat we bepaalde Scrum practices ook niet implementeren.
        De enig juiste aanpak is naar mijn mening dat we continu blijven zoeken naar de beste aanpak in een bepaalde context. Er zijn zoveel variaties mogelijk in de randvoorwaarden dat één beste aanpak niet mogelijk is. Denk aan de ervaring van het team, de domeinkennis, het aantal stakeholders en de mate van betrokkenheid, de volwassenheid van de CM aanpak en het automatisch testen, etc.
        In het nieuwe logo van mijn bedrijf heb ik de slogan “IT is IF that counts” laten opnemen. IF staat voor die openheid voor de context, “ALS dit het geval is DAN …”.
        Dat betekent ook dat ik in ‘onze wereld’ van IT niet meer geloof in best practices. Dat is een van de dingen die ik geleerd heb uit het Cynefin framework. Best practices passen alleen in het Simple domein. In de wereld waarin er heldere oorzaak-gevolg verbanden zijn die altijd hetzelfde zijn. In de IT leven we helaas niet in het Simple domein. En meestal ook niet in het volgende domein: Complicated, waar Good Practices nog nuttig zijn. We leven meestal in een Complex domein waar er geen helder oorzaak-gevolg relaties zijn. Het trucje dat vandaag in deze organisatie werkt, werkt morgen niet in een andere. Omdat er andere mensen zijn, omdat het product complexer zijn, omdat er iemand met ruzie thuis in het team zit, enz.
        Goed, genoeg gefilosofeerd voor vandaag. Ik kijk uit naar je reactie. André.

  2. Andrè,
    Ik vindt het prachtig dat je het belang van *context* benadrukt (en refereert naar Cynefin). Er bestaat in elk geval geen one-size-fits-all oplossing. Wat werkt voor 1 project werkt niet voor andere projecten. Dit is vaak de oorzaak waarom in SCRUM versus CMMI, of PMBOK versus XP, of XYZ versus ABC, discussies naast elkaar gepraat wordt.
    Cynefin leert ons inderdaad dat er fundamenteel verschillende domeinen bestaan waarin verschillende spelregels van toepassing zijn. Ik ben het echter oneens met de conclusie dat heel IT plots in het Complex domein zit. Integendeel! Vele ontwikkelingen, zoals repetitieve ontwikkelingen of evolutieve maintenance, zitten in het “simple” domein. Andere ontwikkelingen die een verdere elaboratie zijn op een bestaande architectuur, zitten in het “complicated” domein. Sommige ontwikkelingen, bvb. breakthrough innovation, zitten effectief in het complex domein. En ten slotte zitten er ook af en toe ontwikkelingen in het “chaos” domein… Het herkennen van deze diversiteit en het afstemmen van de aanpak op de gepaste context is de basis van ons 360° raamwerk.
    (zie de 360° project manager group op linkedin: http://www.linkedin.com/groups?mostPopular=&gid=3177436).

  3. Nico Marien says:

    Heren,

    Jullie convergeren naar een conclusie waar ik het mee eens ben; de juiste aanpak voor het juiste project op het juiste moment. M.a.w. vermijd model fundamentalisme!

    Bovendien, laat model mapping over aan de guru’s van deze wereld die dan hun bevindingen in conferenties aan de experten kunnen meedelen. Wat telt is wat werkt op de vloer!

    Het 360° raamwerk dat we bij TeamProsource hebben uitgewerkt is een praktische toepassing van het Cynefin model. Het laat ons toe om de situatie op een goede manier te beoordelen (kwalificatie van het project) en de gepaste aanpak toe te passen.

    Voor meer informatie zie: http://www.slideshare.net/TeamProsourceEU

    Je kan je ook toevoegen op onze discussiegroep rond 360° improvement.

    Nico

  4. Johnk419 says:

    Great, thanks for sharing this blog.Really thank you! bcdgeekdbfef

  5. Hey! Would you mind if I share your blog with my twitter group?
    There’s a lot of folks that I think would really appreciate your content.
    Please let me know. Thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s