Agile zijn vraagt om uiteenlopende gedragingen. Niemand zei dat het makkelijk is

APMG International, waar je je kunt certificeren in tal van werkvelden en voor uiteenlopende methoden, hield van  hield 16 juni het webinar Being Agile. De opname is gratis te bekijken op Youtube. Agile concepten rond de behoeften van de business, on-time delivery (denk aan 200% leveren in 50% van de tijd, zoals Scrum vaders Jeff Sutherland en Ken Schwaber claimen), iteratieve benadering (met DSDM, RUP, etc. sinds de jaren ’90 al uitgewerkt als belangrijk), samenwerking (alle betrokkenen in een team werken samen aan een product) en een evoluerende oplossing (zoals Agile PM als methode voorstelt). Onderliggende waarden en principes doen een fors beroep op je mentale modellen en gedragingen. Agile doen, wat technieken toepassen, rituelen organiseren, etc. is niet genoeg om slagvaardig en wendbaar te zijn.

Agile gedragingen zijn ook nog eens onderling verbonden en niet los toepasbaar. Met alleen vertrouwen (jippie, het eerste niveau van Lencioni’s piramide voor goed functioneren teams is gehaald!), besluiten durven nemen, willen innoveren of samenwerken ben je er niet.

Met het moordende tempo van elkaar opvolgende sprints is er niet veel tijd om het werkproces radicaal om te gooien of eens rustig de tijd te nemen voor reflectie, al is er aan het eind van elke sprint een slot voor retrospectie gepland. Hoeveel ruimte is er echt voor experimenteren en dus falen om na spreekwoordelijk 99 pogingen wel goud in handen te hebben? Hoe uitgehold is het begrip Minimum Viable Product (MVP) inmiddels?

Melanie Franklin (Continous Change Community) draagt de volgende oplossingen aan:

• identificeer succes- en faalfactoren voordat je start met een experiment. Een zich evoluerende oplossing vereist een ‘wetenschappelijke mindset’ om proeven te doen, een thesis te staven of te weerleggen.
• focus op bereikte resultaten, niet de activiteiten die daarvoor nodig zijn. Druk zijn we allemaal, maar wat heb je nu bereikt? Wat wil je vandaag afronden? Heb je hulp nodig? Staat er iets in de weg? Laten we dan een oplossing zoeken.
• voltooi eerst wat de meeste waarde oplevert. Prioriteren volgens MoSCoW kan helpen.
• het opleveren van een zich evoluerende oplossing gaat niet lineair. Alles lijkt met alles verbonden, een netwerk of kluwen zo je wil. Ondanks pogingen om tot component teams, autonomie, of alle benodigde competenties in één team te komen, is de werkelijkheid anders. Er zijn voor een beetje systeem, oplossing, product of dienst, veel teams betrokken met behoorlijk wat onderlinge afhankelijkheden. Opdelen in kleinere eenheden helpt afhankelijkheden te verminderen.
• genereer nieuwe ideeën voor het de oplossing waaraan je werkt. Gebruikers kunnen de oplossing verschillend inzetten. Kun jij meebewegen of waarde toevoegen?
• gebruik visuele hulpmiddelen als (digitale) borden, information radiators, video’s, testimonials, etc. om behaalde resultaten te benadrukken.
• lever op tijd op, Houd rekening met de tijd die conceptualiseren, ontwerpen, reviewen, doorgaan feedback loops, etc. vergen.
• vraag om feedback, geen kritiek. Focus op wat je gerealiseerd hebt, niet op waar je niet aan bent toegekomen. Wat kan er verbeterd worden aan of juist weggelaten uit een volgende versie?
• blijf de bestemming, het grotere plaatje, de context van waar je aan werkt, in het vizier houden. Kun je vertellen hoe jouw oplossing bijdraagt aan het grotere geheel?
• verdiep (met experts) en verbreed (aanvullende vaardigheden, dwarsdenkers, verbinders) je netwerk om genoeg keuze te hebben uit mensen om mee samen te werken. Ben je geloofwaardig, zodat anderen met jou willen samenwerken?

Kijk je naar deze oplossingen, is ook duidelijk dat het benodigde gedrag niet enkel van de Scrum master, de lead developer, ofzo verwacht mag worden. Team èn mensen in de omgeving (leidinggevenden, belanghebbenden) moeten hiervan doordrongen zijn. Agile zijn is niet zweverig, maar juist erg praktisch, zoveel wordt duidelijk in de presentatie van Melanie Franklin.