Excellente agile teams in perspectief: meten is weten

donderdag 26 januari 2017

Er bestaan agile projecten die slagen en er bestaan agile teams die uitstekende resultaten opleveren. Ligt dat aan de professionele manier van werken, de eenduidige aansturing, een overvloed aan tijd of iets anders? En blijft dat zo of is het toeval? Of kan het nóg beter? Zulke vragen leven vaak bij ICT-managers en bij eindgebruikers. In deze blog ga ik in op de factoren die het succes van een agile team bepalen, tegelijkertijd maak ik het agile proces inzichtelijk.

Excellente software

Software is de belangrijkste factor voor het succes van een onderneming. Geen wonder dat management belang heeft bij uitstekende software ontwikkelprocessen. En dan vooral bij agile software ontwikkeling, want dat is de manier waarop moderne software geproduceerd wordt.

Uit onderzoek blijkt dat excellente ontwikkelteams in excellente ontwikkelprocessen tot 70% minder fouten produceren. Vooral daar waar het er toe doet, in productie, zijn excellente teams in staat zichtbaar betere software te maken. Als je de software van excellente teams vergelijkt met die van doorsnee teams kom je op opmerkelijke verschillen uit.

Software opdelen

In de eerste plaats blijkt dat excellente teams beter in staat zijn software op te delen in kleine, onafhankelijke modulen met een duidelijke, afgeschermde functie en een heldere structuur. De onderhoudbaarheid van zulke software is beter, bij aanpassingen worden minder onverwachte bijeffecten gegenereerd.

Afspraken nakomen

Een tweede – opvallend – verschil is dat mensen in excellente teams zich beter aan codeconventies en afspraken houden. Niet dat er meer van zulke conventies zijn, meestal juist minder. Want in excellente teams vindt men dat alleen zinvolle afspraken nodig zijn, het gaat de teams om het effect en niet om het volgen van regels.

Code duplicatie voorkomen

Tenslotte valt op dat excellente teams in staat zijn vrijwel alle duplicatie van code te vermijden. Hetzelfde twee of meer keer programmeren is niet alleen onderhoudsgevoelig, het vergroot de kans dat de verschillende implementaties niet precies hetzelfde doen. Dat leidt tot lastig te vinden fouten.

Wat maakt een agile team excellent?

Ondanks alle voordelen is het tot stand brengen van excellente agile teams een uitdaging. Het management kan de beste mensen bij elkaar zetten, maar als het team niet samenwerkt en niet gezamenlijk het proces volgt, dan is het resultaat niet wat het moet zijn. Gekwalificeerde mensen laten zich niet sturen door algemene “management talk”. Ze zoeken liefst zelf naar de beste aanpak en dan gaan ze ervoor.

Meten is weten

Wat dan zowel het management als het team helpt, is het meten van geschikte parameters in het proces. “Geschikt”, want zomaar iets meten - zoals het aantal geproduceerde regels code per werkuur - zal averechts werken. Het gaat om het metingen van code-eigenschappen die ertoe doen, die leiden tot betere software, die inzichtelijk zijn en de agile medewerkers helpen hun werk wezenlijk te verbeteren.

Meet de kwaliteit van software

Geschikte tooling om de werkelijk de relevante factoren te meten is schaars. Zulke tooling is flexibel en tegelijk betrouwbaar: de tooling kan snel en eenvoudig verschillende parameters meten en de uitkomsten van de metingen zijn betrouwbaar. De tool meet écht wat kwaliteit van software is. De tools die Valori Software Improvement gebruikt, helpen het management objectief vast te stellen of software code “geweldig goed” is of “beter kan” en de diverse stappen er tussenin. Bovendien geeft een meting weer op welk gebied een verbetering het meest oplevert. Je krijgt een Maturity Score voor de verschillende gemeten aspecten van de software. Die scores kun je gebruiken om een verbeterpad op te stellen. Een goede aanpak die zich in de praktijk bewezen heeft, is het gebruik van Maturity Levels. Hieronder zie je een voorbeeld van een dergelijke meting.

Voorbeeld meting Echnacia

Met een allesomvattende meting kan Valori Software Improvement exact aangeven waar een verbeteractie het meeste rendement heeft. In het project Echnacia is meer dan voldoende structuur aanwezig, maar de structuur is niet in de code verwerkt. Zo is een grote technische schuld ontstaan. Klaarblijkelijk wordt dat veroorzaakt door onvoldoende aandacht voor de processen.

Verbeterpad opstellen én volgen

Een verbeterpad opstellen is één, het lopen van het verbeterpad is twee. Iedereen zal beamen dat elke verbetering een goede zaak is en toch zijn er steeds praktische bezwaren en menselijke weerstanden te overwinnen. Er komt bij een veranderingsproces veel meer kijken dan alleen de te bereiken verbetering. Al begint het daarmee wel. Als het verbeterproces eenmaal loopt, is de volgende stap ervoor te zorgen dat de verbetering in stand blijft. Het is erg aantrekkelijk om terug te vallen in oude gewoonten, om nog maar niet te spreken over nieuwe medewerkers die hun eigen manier van programmeren meenemen.