De voordelen van agile ontwikkeling worden breed gedragen. Ontwikkelen via de agile methode is dan ook meer regel dan uitzondering. Toch slaagt het ene project wel en het andere niet. In de praktijk blijkt dat communicatie een cruciale factor is. Ook met de beste enablers blijken agile-trajecten te mislukken als er geen goede sturing wordt gegeven aan de communicatie.
Ook met de beste enablers blijken agile-trajecten te mislukken als er geen goede sturing wordt gegeven aan de communicatie. Een intrigerend gegeven, als je het mij vraagt. Reden genoeg om samen met de Radboud Universiteit dit gegeven nader te onderzoeken om zo gericht aan een oplossing te kunnen werken. De eerste goede stappen zijn gezet die ik hier als Computable-expert graag deel.
Binnen agile-ontwikkelprojecten zijn, in verhouding tot andere ontwikkelmethoden, veel stakeholders betrokken. Naast it’ers zijn ook marketeers, salesmanagers, productmanagers, domeindeskundigen, et cetera betrokken en allen hebben iets in de melk te brokkelen. Bovendien heeft iedere stakeholder eigen kennis en expertise die waardevol kan zijn. Om dat te kunnen benutten moeten stakeholders elkaar begrijpen. Alleen dan kun je werken aan het creëren van draagvlak. Aan deze softe kant van ontwikkeling, dus het communicatie-aspect, wordt vaak voorbij gegaan.
Onderzoek softe kant
Vanuit mijn functie als business architect bij Everest heb ik samen met onder andere Stijn Hoppenbrouwers van de Radboud Universiteit Nijmegen de softe kant van agile ontwikkeling nader onderzocht. Dit onderzoek bevestigt dat tijdens de ontwikkeling veel beredeneerd wordt vanuit it- modellen, bijvoorbeeld door middel van processchema’s en gegevensmodellen. Het bevestigt ook dat deze benadering nog ver af staat van de belevingswereld van menig andere stakeholder. Er wordt vaak gedacht dat de business-vertegenwoordigers de it-modellen maar moeten leren begrijpen, wat lukt tot een bepaald niveau, maar lang niet altijd volledig. Toch rekenen we er vaak wel op dat zij op basis van deze modellen hun fiat geven. Dat zij dit niet altijd durven te doen ligt voor de hand. Door dit knelpunt te constateren, zijn we al een stuk dichter bij de oplossing waar vanzelfsprekend meer voor nodig is dan louter een constatering. We zijn dan ook verder de materie ingedoken.
De verschillende typen stakeholders hebben we nader onderzocht. De belangrijkste vragen die we beantwoordden zijn: wie zijn het, hoe communiceren ze, wat is hun vermogen om te abstraheren, wat is hun taal/jargon en wat betekent dat? Het antwoord op deze vragen hebben we gevat in een mentaal model per type stakeholder. Daarnaast hebben we communicatiesituaties benoemd. Dit zijn alle situaties binnen het ontwikkelproces waarop gecommuniceerd wordt. Bijvoorbeeld over het in kaart brengen van processen, het onderzoeken van de complexiteit van de producten die in het proces zijn betrokken, of het opstellen van het te automatiseren acceptatiebeleid.
Communicatiesituaties en mentaal model
Om het samenspel tussen de stakeholders te verbeteren en je doelen te bereiken, kun je aan de hand van de communicatiesituaties en de mentale modellen sturing geven aan de communicatie. Per communicatiesituatie kan je namelijk gaan vastleggen welke type stakeholders met welke mentale modellen betrokken moeten worden om effectief de beoogde uitkomst te bereiken. Tevens kan de meest ideale setting worden beschreven: wel of geen facilitator, de te gebruiken technieken, en de meest effectieve representatie. Op basis van het mentale model kun je bovendien de communicatiesituatie op de betreffende stakeholder aanpassen. Zo zal je je er bijvoorbeeld bewust van worden dat niet iedereen hetzelfde beeld heeft bij hetzelfde begrip. Een it-specialist heeft bijvoorbeeld een heel ander beeld bij het begrip ‘actor’ dan bijvoorbeeld een marketeer.
In een andere situatie heb je misschien de keuze uit meerdere stakeholders van hetzelfde type, dan kun je een stap verder gaan. Verschil in achtergrond van een zelfde type stakeholder maakt hen verschillend. Bij een domeindeskundige met vijftien jaar it-ervaring wegen tenslotte andere zaken mee dan bij een domeindeskundige die net van de universiteit komt of een die geschiedenis heeft gestudeerd. Bij alle drie de situaties zullen de mentale modellen en dus ook de communicatiestijlen er anders uitzien.
Al snel ontstaat de behoefte aan een methode om communicatiesituaties en mentale modellen gestructureerd te kunnen beschrijven en om best practises te gaan ontwikkelen met betrekking tot het inrichten van communicatiesituaties. Dit hebben we uitgewerkt en beschreven in het boek ‘Agile service development’. Op dit moment zijn we bezig met een verdiepingsslag in het CoMoLab. Toekomstige inzichten willen we ook graag delen. Als een paal boven water staat in ieder geval dat ook met de beste technische platformen of agile projectmethode je nergens bent zonder aandacht te besteden aan het effectief inrichten van de communicatie.
Dat communicatie cruciaal is, helemaal eens! Vraag me wel af hoe een mentaal model daarbij kan helpen?
Mijn aanpak is om, bij de introductie van agile practices, ook de intensiteit en de kwaliteit van de communicatie tussen de betrokkenen op te voeren. Communicatie zit al “ingebakken” in de agile practices, bv in de planning game, stand-ups en de sprint review. Mijn ervaring is dat extra aandacht voor communicatie, bv. door een agile coach, helpt. En daarbij de communicatie ook regelmatig te evalueren, als er signalen uit een stand-up komen, en uiteraard in de retrospectives.
De vraag is in hoeverre communicatie in te richten valt, en maakbaar is? Uiteraard zijn er condities die helpen om communicatie beter mogelijk te maken, en heeft het zin om impediments mbt de communicatie aan te pakken. Maar vaak zit het veel meer in de vaardigheden van de betrokkenen, het leren en continue verbeteren van communiceren. En dan helpt “gewoon gaan doen” meer als een model.
De Standish Group (ik weet het, ligt ietwat onder vuur) noemt een gebrekkige c.q. gebrek aan communicatie als voornaamste reden van het mislukken van een project. We moeten ons eens afvragen waaróm er zoveel communicatie (en getheoretiseer daarover) nodig is om een softwareproject in goede banen te leiden.
De noodzaak tot veel en foutloos communiceren is een symptoom van een dieper liggende oorzaak…
Ik ben het helemaal met Gerwin eens. Volgens mij is de dieper liggende oorzaak gelegen in het feit dat communicatie vanuit verschillende contexten/perspectieven plaatsvindt. Mensen hebben nu eenmaal verschillende achtergronden en kennen vanuit hun perspectief betekenis toe aan concepten.
Inderdaad is binnen Agile met stand ups de communicatie prima geregeld (zie reactie Ben Linders) , echter het richt zich op de communicatie tussen projectleden/automatiseerders die een gelijksoortige context hebben. Communicatieproblemen zijn daar ook erg gering.
De echte uitdaging is communicatie met “stakeholders”met afwijkende contexten. Zet een IT-er naast een jurist en de IT-er begint tegen een jurist te klagen dat hij niet exact genoeg is. Einde oefening…..
De IT-er zou moeten realiseren dat de jurist juist super axact is, maar dat i.t.t. de IT een begrip meerdere betekenissen kan hebben afhankelijk van de context!
Mee eens, mentalen modellen zelf gaan daar niet bij helpen! Wel bewustwording van het feit dat je respect moet hebben voor verschillende perspectieven, als je dat doet heb je de helft al gewonnen. Mentale modellen als techniek is wel interessant in het ontwerp van business faciliteiten / HCI die business stakeholders wel eens fatsoenlijk in staat stellen om applicaties te onderhouden!