Concurrenten van Agile Analytics

Zoek op een engineering management platform, een software engineering intelligence platform of gewoon op developer productivity tools, en je krijgt dezelfde twintig namen terug. Ze zijn niet uitwisselbaar. De meeste lezen één systeem goed en leiden de rest af, en welk systeem dat is bepaalt wat ze je wel en niet kunnen vertellen.

Git- en pull request-analyse. Deze lezen de codekant — commits, branches, reviewtijden, hoe vaak er gemerged wordt. Swarmia, LinearB, Waydev, GitClear en Pluralsight Flow zitten grotendeels hier. Sterk in hoe een wijziging door review en release beweegt, en ze zien een stuk werk pas vanaf het moment dat er code voor bestaat.

Ticket- en projectanalyse. Deze lezen het issuesysteem — cycle time, flow, onderhanden werk, forecasting. Ze zien het werk vóórdat er code is, en daar zit het meeste wachten, maar ze zien niet wat de pijplijn er daarna mee doet.

Developer experience-platforms. DX en Jellyfish zitten dichter bij deze kant en combineren enquêtedata met systeemdata. Ze beantwoorden de vraag die geen enkel logbestand beantwoordt — hoe het werk aanvoelt — en zijn afhankelijk van of mensen reageren.

Internal developer portals. Backstage, Cortex en Atlassian Compass catalogiseren services en beheren de gebaande weg. Dat is infrastructuur vóór ontwikkelaars in plaats van meting ván ontwikkelaars, en ze duiken in dezelfde zoekopdrachten op omdat de koper vaak dezelfde persoon is.

Waar begint de klok? Een tool die pas bij de eerste commit begint te meten, rapporteert een gezonde lead time voor werk dat drie weken in een backlog stond. Dat is niet fout van de tool — het is een vraag stellen waarvan hij het begin niet kan zien.

Is het te sturen vanuit een statusveld? Beweegt een getal zodra iemand een kaart versleept, dan zakt het vanzelf zonder dat er sneller geleverd wordt. Tijdstempels uit de pijplijn en het issuesysteem overleven een doelstelling; handmatig gezette statussen niet.

Meet het mensen of het systeem? Alles wat individuen rangschikt wordt geoptimaliseerd, en wat je krijgt is meer activiteit in plaats van meer levering. De DORA-metrics zijn juist daarom bewust op systeemniveau.

Waar is het blind voor? Elke tool in deze markt dekt een deel. DORA beschrijft levering en zegt niets over hoe het team zich voelt; enquêtetools beschrijven het gevoel en kunnen geen release klokken. De twee raamwerken beantwoorden andere vragen, en een leverancier die beweert beide uit één databron te dekken verdient een tweede blik.

Hoe lang duurt het voor er antwoord uit komt? Een platform dat een kwartaal configuratie nodig heeft voordat het een getal produceert, kost een kwartaal — ongeacht of dat antwoord nuttig blijkt.

Wij lezen beide kanten: het issuesysteem en de deploymentpijplijn, zodat een stuk werk zichtbaar is vanaf het moment dat het wordt aangevraagd tot het draait in productie. Dat is een bewuste keuze over reikwijdte en geen claim dat we alles doen — het is wat het gat tussen cycle time en lead time zichtbaar maakt, en daar zit de vertraging meestal.

Heb je een servicecatalogus nodig, dan helpt een internal developer portal je beter dan wij. Wil je alleen sentiment uit enquêtes, dan is een gericht developer experience-platform de kortere route. Is de vraag wáár werk vastloopt tussen aanvragen en live staan, dan is dat de vraag waar dit platform omheen gebouwd is — zie productiviteit verbeteren met developer goals voor hoe dat er in de praktijk uitziet.