De juiste "Agile Coach" vinden

In de jaren 2004 en 2005 stapten steeds meer teams over op agile methoden en vaak hadden ze als eerste natuurlijk advies en training nodig. In veel gevallen moest ik helaas na de trainingen bij de bedrijven langskomen om de rommel op te ruimen die de trainers hadden achtergelaten. Destijds ging ik er onterecht van uit dat dit alleen een probleem zou zijn zolang de nieuwe agile teams – vooral in bedrijven die standaardsoftware ontwikkelen – nog ervaring moesten opdoen. Helaas is het probleem van slechte trainers en coaches nog niet verdwenen. Hoewel veel bedrijven inmiddels voor goede trainers hebben gekozen, zijn ze naar mijn mening nog steeds eerder de uitzondering.

Zoals bij veel andere dingen is het natuurlijk aan de klant om de beste trainer voor zichzelf te vinden. Maar als een team training nodig heeft, is de kans groot dat degenen die deze beslissing moeten nemen daar nog geen ervaring mee hebben. De bedoeling van dit artikel is dan ook om productbedrijven te helpen de juiste trainers en coaches voor agile methoden te vinden.

Verschillende factoren bij het zoeken naar de juiste Agile Coach

1. In de meeste gevallen wordt software nog steeds voor interne doeleinden (IT) of specifiek voor een bepaalde klant ontwikkeld. Daardoor kunnen veel agile trainers simpelweg nog niet goed omgaan met bedrijven die oplossingen voor de massamarkt ontwikkelen. Natuurlijk wil je ook niet het bedrijf zijn waarop zo'n trainer oefent. Daarom is het belangrijk om vooraf te weten of de potentiële trainer het verschil begrijpt tussen IT (intern), klantspecifieke softwareontwikkeling en standaardsoftwareontwikkeling.

2. Bij bedrijven die standaardsoftware ontwikkelen, bestaan er heel andere rollen dan bij andere soorten software. Een potentiële trainer moet de rol van de productmanager, productmarketing, het User Experience team, de Interaction Designers, Visual Designers en User Researchers begrijpen.

3. De trainer moet weten hoe de samenwerking tussen productmanagers en UX Designers met het agile ontwikkelteam eruitziet. De trainer moet persoonlijke ervaring hebben met Dual-Track Agile (tweesporige ontwikkeling) – dus met Product Discovery en Product Delivery.

4. In een softwarebedrijf moet je in bepaalde gevallen in staat zijn om concrete toezeggingen te doen en betrouwbare schattingen te geven over het moment van oplevering. Dit moet met integriteit gebeuren en je moet je ervan bewust zijn dat conventionele roadmaps vaak vol staan met items die de klant niet echt iets opleveren. De trainer moet dus begrijpen hoe je zulke toezeggingen doet en hoe ze binnen een productteam worden gemanaged.

5. In ontwikkelteams voor standaardsoftware is de productvisie enorm belangrijk om context te creëren en het team te motiveren. Een trainer voor agile methoden moet dus de sleutelrol van de productvisie en de strategie begrijpen en ook weten hoe dat samenhangt met Product Discovery en Delivery.

6. Bij interne software denken veel trainers voor agile methoden dat ze behoorlijk snel zijn als ze elke tweewekelijkse Sprint een paar ideeën uitproberen. Bij standaardsoftware zou dit echter als ongelooflijk traag worden beschouwd. Zorg ervoor dat je trainer begrepen heeft dat snelheid voor innovatie extreem belangrijk is en hoe Dual-Track Agile ons helpt om de meeste ideeën te valideren zonder daarvoor code te hoeven schrijven.

7. In organisaties voor standaardsoftware heb je een doorlopende cyclus waarin je iets bouwt (prototypes en productie), de resultaten meet, ervan leert en het proces vervolgens herhaalt. Het is zeer belangrijk dat de trainer begrijpt welke betekenis deze cyclus, evenals prototypes, analyses en A/B-tests hebben voor het nemen van beslissingen, het testen en continu leren.

8. Cultureel gezien is er een groot verschil tussen de ontwikkelaars in een IT-organisatie en die in een organisatie voor standaardsoftware. De agile trainer moet weten dat het niveau van ervaring en vaardigheden van de ontwikkelaars sterk verschilt en dat de aanpak daarop moet worden aangepast. Veel van de ontwikkelaars hebben aanzienlijk meer ervaring met het ontwikkelen van echte producten dan de meeste trainers. Daardoor kunnen trainers met de verkeerde instelling er snel aan falen om het respect van het team te verdienen.

9. Een ander groot verschil is dat een team in een IT-organisatie aan de behoeften van het bedrijf moet voldoen. Het productteam in een organisatie voor standaardsoftware is er om oplossingen voor de klanten te ontwikkelen op een manier die voor het bedrijf haalbaar en rendabel is. Dat is geen onbeduidend verschil. De trainer moet begrijpen dat dit geen dienstverlenende organisatie is die erop gericht is om aan de behoeften van het bedrijf te voldoen.

10. Uiteindelijk is het cruciaal dat de trainer niet alleen bedrijven voor standaardsoftware begrijpt, maar ook de eisen en methoden van bedrijfskritische SaaS (Software as a Service) diensten. Onderwerpen zoals schaling, betrouwbaarheid, fouttolerantie, prestaties, monitoring en controle, testautomatisering en technische schuld zijn niet langer optioneel maar een absolute must. Bovendien is er bij de ontwikkeling van standaardsoftware geen ruimte voor een dogmatische en blinde naleving van processen. Sommige mensen verwarren bij agile methoden graag de middelen om een doel te bereiken met het doel zelf. Het enige doel dat er echt toe doet, is een succesvol product.

Conclusie

Als je een trainer of coach voor agile methoden uitkiest, moet je er rekening mee houden dat het bedrijf waarvoor hij werkt vaak niet zo doorslaggevend is als de persoon zelf. Controleer dus de potentiële kandidaat en zoek uit of diegene ook over de ervaring met bedrijven voor standaardsoftware beschikt die je nodig hebt.

Over het algemeen kun je zeggen dat een trainer naar je toe komt, je de theorie uitlegt en dan weer vertrekt. Een coach daarentegen past de methoden daadwerkelijk toe met je team in jouw unieke omgeving.

Deze tekst is afkomstig uit de blog van Marty Cagan en werd door ons naar het Nederlands vertaald.