Continuous Communication

Het is 11 februari 2001. Zeventien ervaringsdeskundigen komen bij elkaar in een ski resort in Utah. Twee dagen later keren ze terug naar de buitenwereld. De stenen tafelen die zij meedroegen, kennen wij inmiddels als het Agile Manifesto. De rest is geschiedenis.

Inmiddels ruim 13 jaar later zijn de principes van de Agile werkwijze wijdverspreid en worden ze binnen vele organisaties in meer of mindere mate toegepast. Maar is Agile nu ook daadwerkelijk zo succesvol? Valt er überhaupt wel iets steekhoudends te zeggen over de effectiviteit van de Agile werkwijze? Linda Rising verwoordde dit ooit zeer treffend op de GotoCon met de vraag: “wie van jullie doet Agile vanwege de zorgvuldig uitgevoerde dubbelblind experimenten en wetenschappelijke onderbouwing?”. Of Jez Humble, die op de vraag vanuit het publiek waarom hij gelooft dat Continuous Delivery wél werkt, antwoordde dat hij van Continuous Delivery, in tegenstelling tot Agile, wel concrete gevallen in de praktijk heeft gezien.

 

Werk je bij een ‘Agile’ organisatie en heb je jezelf wel eens afgevraagd of dit nu echt zoveel efficiënter is? Staat bij jou de functionaliteit die je moet opleveren minimaal drie sprints vooraf al vast? Werkt het lijnmanagement nog steeds met (half)jaarplanningen en “moet het af”? Zie je dit niet snel veranderen, maar wil je toch weten hoe je binnen deze kaders effectiever kunt (samen)werken? Lees dan verder en ontdek hoe je ook binnen een organisatie die niet ‘Agile all the way down’ is toch effectief kunt zijn.

 

Het aantal organisaties dat het afgelopen decennium een Agile werkwijze heeft (of althans zegt te hebben) geadopteerd is enorm. Echter, wij zien dat er momenteel een discussie gaande is over hoe dicht we in de praktijk nog bij het originele gedachtegoed zijn gebleven. Doordat iedereen in de loop der tijd een eigen invulling heeft gegeven aan Agile, constateren we dat het begrip is verwaterd. Deze constatering wordt gedeeld door de oorspronkelijke bedenkers. Martin Fowler geeft hiervan akte en heeft het in deze context over ‘Semantic Diffusion’. Anderen, zoals Dave Thomas, schromen niet om nog een stapje verder te gaan en betogen dat de betekenis inmiddels ter ziele is gegaan en dat het hoog tijd is voor een nieuwe term, die beter aansluit bij de oorspronkelijke kernwaarden.

 

Ofschoon de argumenten in bovenstaande motivaties beklijven, leert de ervaring ons dat het bewerkstelligen van de cultuuromslag ,die nodig is om een dergelijke pure vorm van Agile werken te bereiken (zo je al kunt zeggen dat er zoiets bestaat) vaak geen haalbare kaart is. Menigeen ontbreekt het aan tijd (vaak jaren) en niet te vergeten de overredingskracht, die vereist is om de juiste mensen binnen de organisatie van deze verandering te overtuigen.

 

Steeds meer ondernemingen bevinden zich in deze spagaat tussen het traditionele lijnmanagement en het nieuwere Agile werken. De wijze waarop wordt omgegaan met jaarplanningen, budgetbepalingen en documentatie staan vaak haaks op de werkwijze van het implementatieteam. Dit gebeurt in de praktijk zo vaak, dat het inmiddels een eigen naam heeft verworven: WaterScrumFall.

 

Hiervoor bestaat helaas geen silver bullet. In dit artikel belichten we daarom een ander aspect van het Agile gedachtegoed dat ons ICT'ers toch steeds lijkt te blijven ontglippen. Iets eenvoudigs, dat binnen de status quo wel degelijk kan zorgen voor verbetering, zelfs onder suboptimale omstandigheden. Het aspect is zo belangrijk dat één van de kandidaten voor de uiteindelijke naam van de Agile-methodologie dit feilloos weerspiegelde. Kent Beck, aanwezig op de in de inleiding genoemde bijeenkomst en daarmee één van de grondleggers van het Agile Manifesto, stelde voor de methodologie de naam ‘Conversational’ mee te geven.

 

Ook uit het Agile manifesto en de principes hierachter keert dit thema vaak terug:

 

• Individuals and interactions over processes and tools;
• Customer collaboration over contract negotiation;
• Business people and developers must work together daily throughout the project;
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

 

Zo eenvoudig is het dus. ‘Gewoon’ met elkaar praten is dé manier om succesvol te werken. Echter, hierbij hoort ook het creëren van een veilige context, waarin mensen deze conversatie ook daadwerkelijk aan durven te gaan. Om het maximale uit een gesprek te halen, moet je je open en kwetsbaar op durven stellen. Binnen de ICT zien we hier jammer genoeg nog te vaak een terughoudendheid in. Bijvoorbeeld bekennen dat je iets niet weet, wordt nog te vaak gezien als een teken van zwakte en wordt derhalve vermeden. Er wordt dan liever een aanname gedaan, die in de praktijk helaas vaak niet de juiste blijkt.

 

Communicatie, conversatie, interactie, samenwerken, dat is de rode draad. Het is niet iets dat zich zou moeten laten beperken tot vooraf geplande meetings (Scrum) of een select clubje mensen, maar een continu proces dat plaatsvindt tussen alle stakeholders betrokken bij het project. En niet af en toe, maar continu: Continuous Communication.

 

Neem een gemiddeld Scrum-team. Het team wordt gevoed met stories, die geschreven worden door ‘de analist’. Deze baseert zijn werk op gesprekken, die hij voert met de product owner. Deze laatste heeft namelijk niet de tijd vast onderdeel te zijn van het team. Er zijn bijvoorbeeld meerdere teams, die werken aan hetzelfde project en de product owner kan ze niet allemaal fulltime bedienen. De stories zijn onderdeel van een epic waarvan nu al bekend is wanneer het af moet zijn. Er is namelijk een belofte gedaan aan de business over wat wanneer af is, teneinde überhaupt budget los te krijgen. Ruimte om functionaliteit te bouwen en op basis van feedback te verbeteren – op een incidentele bugfix na – is er niet. Het moet in één keer goed zijn, anders kan het niet mee in de kwartaalrelease.

 

Klinkt dit herkenbaar? Hoe kun je er in een dergelijke situatie nu voor zorgen dat de klant toch zoveel mogelijk waar voor zijn geld krijgt?

 

Three amigo’s

Stel je het volgende scenario eens voor. Alle stakeholders komen vooraf fysiek bij elkaar om de user stories eenduidig te krijgen. Het betreft hier niet alleen de standaard teamleden (developer, tester, product owner), maar wellicht ook de beheerder, DBA-er of andere stakeholders. Het resultaat van een dergelijke bijeenkomst zijn acceptatiecriteria en acceptatietests. Door vragen te stellen als: waarom bouwen wij dit? Hoe gaan we dit bouwen? Wat gaat er fout wanneer wij dit niet bouwen? en de meest belangrijke: kun je mij voorbeelden geven?, verklein je de kans op boemerangfunctionaliteit (werk dat je opnieuw kunt doen ten gevolge van miscommunicatie).

 

Het kan niet genoeg benadrukt worden hoe belangrijk het is dat iedereen, die iets te maken heeft met wat je aan het ontwikkelen bent, aanwezig is en actief bijdraagt. Het doel is om een gezamenlijk begrip en draagvlak te kweken. Deze bijeenkomst is ook het moment waarop iedereen nadenkt en input levert over wat je bouwt en hoe je het bouwt. Met name de input van developers en testers met betrekking tot alternatieve oplossingen wordt nog vaak over het hoofd gezien. Stories worden wel door hen gereviewed, maar echt betrokken bij de totstandkoming van de story worden ze vaak nog niet. Martin Fowler heeft in ieder geval een duidelijke boodschap voor elke developer: “We’re not just code monkeys!”.

 

Het idee dat het wel handig is om de input van alle belanghebbenden evenredig mee te laten wegen in het creatieve proces in plaats van dat er nog steeds iets over de schutting wordt gegooid (toegegeven, de schutting is tegenwoordig lager en de hoeveelheid kleiner) heeft inmiddels zelfs een eigen naam gekregen: het three amigo’s principe. Principe is hierbij natuurlijk wel een erg groot woord, maar we zijn er binnen de ICT nu eenmaal dol op om labels te plakken op de meest triviale dingen.

 

Hoe kun je nu naast het toepassen van dit ‘principe’ Continuous Communication bevorderen, zodat er voor alle partijen zoveel mogelijk begrip en draagvlak te creëren valt? Hieronder geven we je een aantal ideeën.

 

Ken je domein

Om mee te kunnen denken met de klant moet je de klant kunnen zijn. Domeinkennis is daarbij onontbeerlijk. Niet voor niets is één van de pijlers van Domain Driven Design het creëren van een Ubiquitous Language. Om effectief te communiceren met de business moet je weten in welke wereld zij leven. Wanneer je zowel het proces als de techniek begrijpt, ben je in staat optimaal advies uit te brengen over waar en hoe je het beste waarde voor de business kunt creëren.

 

Hoe korter de lijn, hoe minder ruis

Iedereen kent het spel waarbij één persoon een ander een bericht influistert, waarop deze het weer doorgeeft aan zijn buurman, etc. Aangekomen bij de laatste persoon, herhaalt deze hardop het bericht tot groot vermaak van de groep, aangezien er van het oorspronkelijke bericht dan vaak weinig meer over is.

 

Overleg daarom, indien mogelijk, direct met de mensen die ook een beslissing kunnen nemen. Werk je met een product owner en een analist samen, stel je vragen dan in bijzijn van beiden. Blijf dicht bij de bron. Ga de dialoog met elkaar aan en luister ook actief naar de ander. Vat in je eigen woorden samen wat de ander heeft gezegd om misverstanden te voorkomen. Alleen dan weet je zeker dat de boodschap ook over is gekomen, zoals deze bedoeld is.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Zit fysiek bij elkaar

Communicatie is lastig wanneer de teamleden niet fysiek aanwezig zijn. Laten we eerlijk zijn, niets werkt beter voor wederzijds begrip dan een paar mensen met een whiteboard en wat stiften. Wij geloven derhalve niet in ‘Het Nieuwe Werken’. Flexplekken zijn een leuk, hip en vooral als kostenbesparend bedoeld fenomeen, maar in de praktijk bij lange na niet zo effectief als face-to-face communicatie. Non-verbale communicatie speelt hierbij een zeer belangrijke rol. Natuurlijk, thuiswerken moet af en toe kunnen, maar het zou een uitzondering moeten zijn, niet de norm.

 

Do not assume unless you want to make an ass out of u and me

Verifieer al je aannames. Kan een belangrijke stakeholder niet aanwezig zijn bij een vergadering, dan zijn we geneigd onder tijdsdruk toch verder te gaan. We kunnen immers wel raden wat hij te zeggen zou hebben. Vermijd dit fenomeen zoveel mogelijk. Juist dit soort aannames leiden tot last-minute rework. Als stakeholders niet aanwezig kunnen zijn bij een belangrijke vergadering, is het kennelijk niet belangrijk. Herinner ze hier ook aan. Uiteindelijk zijn aannames natuurlijk onvermijdelijk, maar probeer het aantal te beperken. Wees je bewust wanneer je een aanname doet en breng ze ook in kaart, zodat de aanname later bevestigd danwel ontkracht kan worden door de beslissingsbevoegde.

 

‘Nee’ is ook een optie

Heb je als team wel eens ‘Nee’ gezegd tegen een stakeholder? Wanneer je als team ziet dat een oplossing beter kan of andere problemen nijpender zijn, zou je dit eens kunnen overwegen. Hoewel, overwegen, zeg gewoon ‘nee’! Echter, onderbouw je antwoord en kom ook met alternatieven. Een query op de productiedatabase kan bijvoorbeeld helpen om aan te tonen dat een gepland stuk functionaliteit een probleem oplost dat in de praktijk zelden voorkomt. In plaats daarvan zou het team ook andere werkzaamheden kunnen verrichten, die met deze informatie beschikbaar wellicht meer prioriteit hebben. Juist dit soort discussies (communicatie) zorgen ervoor dat een gemeenschappelijk begrip wordt gevormd en dat de gekozen oplossing een gezamenlijk draagvlak verkrijgt.

 

Maak meerdere schattingen voor een story

Een veel voorkomend punt van botsing tussen lijnmanagement en het development team heeft betrekking op de velocity van het team en het wel of niet halen van het afgegeven commitment voor de sprint. Een bron van verwarring hierin is vaak de schatting. Een schatting wordt, veelal onbewust, omgevormd tot harde garantie.

 

Geef voor de verandering in plaats van één getal eens een range (bijvoorbeeld 3 tot 8 punten) of maak drie schattingen: best case, normal case en worst case. Op deze manier maak je de onzekerheid, die inherent is aan een schatting beter inzichtelijk en voorkom je dat er één getal is dat een eigen leven gaat leiden in een rapportage of Excelsheet van je lijnmanager.

 

Bring your own team

Heb jij invloed op wie er in jouw team komt? Autonomie is één van de belangrijkste drijfveren van een mens. Autonomie wil zoveel zeggen als de vrijheid om je eigen keuzes te maken. In een teamsamenstelling waar jij zelf invloed op uit hebt geoefend, zul je je opener opstellen dan wanneer je voor een voldongen feit wordt gesteld.

 

Pairing

Pairprogramming is inmiddels een bekend fenomeen. Maar pair je ook met verschillende disciplines? Als je zo dicht naast elkaar zit, ga je vanzelf met elkaar praten en breng je de informatie-uitwisseling op gang. Pairen kan ook over meerdere teams. Werk je met meerdere teams en een ander teamlid vraagt jou om hulp, los het dan niet voor hem of haar op. Stel in plaats daarvan eens de vraag: "zullen wij dit samen oplossen?". Durf ook zelf om hulp te vragen. Als je dit eenmaal uit jezelf kunt doen, zul je merken dat je die daily standup eigenlijk niet meer nodig hebt.

 

Have fun

Werken met elkaar betekent meer dan alleen maar gefocust zijn op code kloppen, testen en naar productie brengen. Wij zijn van mening dat je als team ook plezier mag hebben. Dit verhoogt de moraal en common understanding binnen het team. Tijdens werktijd kun je denken aan ‘Google Fridays’. Dit concept van Google betekent dat je op vrijdagmiddag met een team van mensen innovatief probeert te zijn op een manier, die niet zozeer direct met je dagelijkse werkzaamheden te maken heeft. Schaf als project eens een voetbaltafel of dartbord aan of ga gamen met zijn allen op vrijdagmiddag. Dit competitieve, maar leuke spelelement kan bijdragen aan het geheel. Natuurlijk zijn wij geen familie, zoals vele bedrijven ons willen laten denken: wij zijn een team. Maar dat betekent niet dat je als team niet eens kan gaan poolen, karten of gewoonweg naar een kroeg kunt gaan.

 

Team responsibility

Ben je als team gezamenlijk verantwoordelijk? Taken zijn een team responsibility en niet van één persoon. Een vakantie van één van je teamgenoten betekent niet dat zijn taken niet worden overgenomen. Tests moeten geschreven worden, specificaties moeten helder zijn en code moet worden geschreven. Er kan niet gewezen worden naar één persoon, want het gehele team is verantwoordelijk voor alle taken die zij moet uitvoeren. Om een sfeer van verantwoordelijkheid te verkrijgen is vertrouwen van groot belang, met name vanuit het management en de business. Zorg dan ook dat je dit vertrouwen krijgt door aan te tonen dat je als team deze verantwoordelijkheid aankunt.

 

Conclusie

Continuous communication gaat ervan uit van dat je continu communiceert met alle betrokkenen met als doel ambiguïteiten en onduidelijkheden in elke hoedanigheid zoveel mogelijk uit te bannen. In plaats van de focus te leggen op een kentering van de bedrijfsfilosofie en achterliggende cultuur, valt er al veel winst te behalen door de aandacht te richten op het binnen de grotere organisaties toch nog vaak ondergeschoven communicatieve aspect. En het is nu juist dit aspect dat eigenlijk de basis vormt voor de ons inmiddels zo dierbare Agile principes. Door niet alleen betrokken te zijn bij de implementatie, maar ook bij het voor- en natraject actief mee te denken over de op te leveren functionaliteit alsmede de toegevoegde waarde hiervan, voorkom je dat kostbare tijd wordt verspild met het bouwen van boemerangfunctionaliteit en de daaruit voortvloeiende problematiek. Continuous Communication: Gewoon doen en vooral, vertel het door!