Hoe Agile waren we eigenlijk zelf bij Anago?

shutterstock_1150302662.jpg

De manier waarop wij onze klanten helpen om meer Agile te denken, heeft veel te maken met de menselijke maat – adviseren, bewustwording, etc. – maar daarnaast bieden en bouwen wij ook handige online platforms waarmee bedrijven hun werkzaamheden overzichtelijk kunnen inplannen en monitoren.

Dat betekent dat wij bij Anago aardig wat softwareontwikkelaars hebben rondlopen die soms veel op zich af krijgen: bugs oplossen, kleine functionaliteiten toevoegen, maar ook grote wijzigingen zoals nieuwe koppelingen of een nieuwe gebruikersinterface. Soms zijn het projecten die echt een paar maanden kosten om te ontwikkelen van de basis tot het eindproduct.

Alles belangrijk

Natuurlijk hebben wij hiervoor bij Anago ook onze eigen ontwikkelagenda en gebruiken wij ons eigen planningssysteem.

Toen wij een tijdje terug onze eigen manier van werken eens tegen het licht hielden (we kunnen het iedereen aanraden, ook al werk je al jaren volgens de Agile principes!) – zagen we opeens dat het voor veel taken onbekend was, of onduidelijk stond aangegeven, hoeveel tijd ze eigenlijk kostten en wanneer ze klaar moesten zijn.

Wij werken meestal met tweewekelijkse sprints. Maar tijdens ons zelfonderzoek kwamen we erachter dat prioriteiten lang niet altijd sterk geformuleerd waren binnen deze sprints: net iets (te)veel zaken stonden gelabeld als belangrijk – product-owners kon autonoom dingen op de to-do lijst zetten met een datum waarop het af moest zijn. Als je vijf product-owners hebt, is een dergelijk lijstje zo gevuld.

Onze workflows liepen – al onze structuren ten spijt – praktisch volgens het “Last come, serve first” principe. Wie het hardste piepte werd het snelst geholpen. Niet alleen bleek onze werkpraktijk strijdig met zo ongeveer alles wat wij onze klanten leerden – in de praktijk werkte het ook niet goed. Iedereen vond de eigen cases het belangrijkste. En door alle werkdruk die dit opleverde, was er geen tijd meer voor het managen van de grote lijnen.

En toen?

Toen we er bij Anago achterkwamen dat we zelf veel minder Agile werkten dan we onze klanten leren besloten we een aantal maatregelen te nemen:

  • Om te zorgen dat grote, langlopende projecten voortgang bleven houden, gingen we een vaste hoeveelheid tijd van de sprint reserveren voor het ontwikkelen van grote functionaliteiten in onze ontwikkelagenda.

  • Onze product-owners kregen allemaal een eigen lijstje waarop ze zelf hun eigen prioriteiten mochten kiezen. Welke prioriteiten uiteindelijk op de grote lijst terechtkwamen, dat mochten de product-owners zelf onderling uitvechten.

  • Er werd strenger gelet op het doorrekenen van het aantal beschikbare uren voor ieder project. Als de product-owners toch in de knoop kwamen met hun taken en gereserveerde uren, dan werd de uiteindelijke beslissing over capaciteitsuitbreiding doorgeschoven naar een hoger managementniveau.

  • Product-owners gingen nog meer met elkaar in gesprek over het 'economische belang' van hun eigen prioriteiten. Gaat een case over één klant, of over 100 klanten? Is deze wijziging handig voor mijn ene beheerder, of voor alle gebruikers?

Afwegingen maken

Agile werken is afwegingen maken. En dat waren we bij Anago wat minder gaan doen. Iedereen altijd zo goed en snel mogelijk willen helpen. Zoiets sluipt er snel in als je je werk leuk vindt.

Maar wat bleek? In 80% procent van de gevallen vonden onze klanten het prima als een kleine onhandigheid niet stante pede werd opgelost. Vaak wordt een specifieke functionaliteit maar een keer in het half jaar gebruikt. Dan lijkt een kleine onhandigheid acuut en irritant, maar dat is eigenlijk niet zo.

Daarbij komt dat een goede, duurzame oplossing voor een systeem soms vanzelf naar boven komt als je de case heel even laat rusten.

Natuurlijk. Als er echt iets mis is bij een klant dat direct moet worden opgelost – en er is een tekort aan tijd - dan schalen we op. Zonder enig probleem. Maar wat we nu wel doen is: er een business case omheen maken zodat we onze bevindingen kunnen meenemen naar de toekomst en ons meer bewust zijn van het probleem in bredere context.

Want ook dat is een van de vele voordelen die het beter nadenken over prioriteiten binnen onze Agile manier van werken heeft meegebracht: er ontstaat automatisch een grotere kennisuitwisseling over verschillende projecten. En het standaard terugkijken, de retrospect, is weer – meer dan ooit - een belangrijk onderdeel van onze sprints.

Vroeger kwam de klantwens nogal eens ongefilterd terecht bij de ontwikkelaar. Nu hebben wij onze product-owners weer meer in de kracht van hun werk gezet als probleem-eigenaar.


Denk jij dat je helemaal werkt volgens de Agile principes?
Wij kunnen je aanraden om je dagelijks praktijk toch eens tegen het licht te houden.