Agilent's agile transformatietraject

De manieren waarop agile Agilent hielp fouten te verminderen, kwaliteit te verbeteren en productcapaciteit te vergroten

David Vermette Door David Vermette
Onderwerpen zoeken

In 2015 zat de afdeling Software en informatica van Agilent in de problemen. Te midden van een grote nieuwe productrelease besefte het team dat het de releasedatum niet zou halen. Dat was niet voor het eerst: de divisie bracht maar ongeveer 20% van haar releases op tijd uit.

De gemiste releasedata legden een enorme druk op de softwareteams. "Als teams onder druk staan, nemen ze slechte beslissingen", zegt John Sadler, VP en GM van Agilent's afdeling Software en informatica. "Ze offeren kwaliteit op en boeten daar achteraf voor. Het team was over het algemeen relatief gedemoraliseerd en had het moeilijk om iets op tijd te leveren."

Een deel van de uitdaging was dat de afdeling Software en informatica van Agilent bestond uit 150 werknemers op twee continenten die voor één derde samenwerkten met aannemers. Het was een grote, versnipperde afdeling met medewerkers op het gebied van engineering, marketing, kwaliteitsborging, technische support en sales. Het bedrijf moest nieuwe teampraktijken opzetten om het te helpen sneller waarde te leveren, met meer kwaliteit en voorspelbaarheid, en beter te reageren op veranderingen. Kortom, ze hadden behoefte aan een agile transformatie.

Beginnen aan een agile transformatie

In 2015 bracht Agilent een agile transformatie in kaart met de volgende doelen:

  • Focus op voorspelbaarheid
  • Ontwikkel een betrouwbare releasefrequentie
  • Creëer een reproduceerbare leveringscyclus
  • Stimuleer continue verbetering

De agile aanpak stelt kwaliteit voorop, een reproduceerbare cadans op de tweede plaats en scope op de derde. "Wanneer teams deze prioriteiten niet volgen, stellen ze vaak scope op de eerste plaats, wordt de tijdlijn opgelegd in de vorm van een deadline en komt kwaliteit smekend achteraan", zegt Sadler.

Agilent wilde agile processen opzetten die prioriteiten voor softwareontwikkeling vastlegden. Het vaststellen van continue verbetering als primaire waarde bracht een culturele verschuiving met zich mee die een context creëerde voor de transformatie. Kwaliteit voorop stellen betekende meer tevredenheid voor externe en interne klanten. Agilent was bereid scope op te offeren om aan de verwachtingen van de klant in het veld te voldoen.

De tweede prioriteit was dat de afdeling een voorspelbare releasecyclus creëerde die in de loop van de tijd kon worden verfijnd. Een kortere, betrouwbaardere ontwikkelingscyclus betekende dat het team problemen zou vermijden en risico's vroegtijdig zou beperken om voor voldoende responstijd te zorgen.

Agile transformatie: stap voor stap

Sinds augustus 2015 werkt Agilent samen met CPrime, een adviesbureau dat ervaring heeft met het helpen van organisaties door middel van agile transformaties, en later met TCGen, een toonaangevend adviesbureau voor productontwikkeling.

De implementatie van de agile-productbeheertool Jira was de eerste stap. Jira biedt nu één registratiesysteem voor al het ontwikkelingswerk van Agilent, verspreid over wereldwijde teams. Het creëert transparantie met één versie van de waarheid die agendapunten onthult wanneer ze worden verwacht en duidelijk maakt wat er in teams is bereikt.

Agile governance-grafiek en -beschrijving

Aangepast met rechten van CPrime, Inc.

Agile training was de volgende prioriteit, met doelen om agile principes en concepten aan te leren en een gedeelde terminologie vast te stellen. CPrime schetste zijn Recepten voor Agile in het Governance in the Enterprise (RAGE)-model dat belangrijke ceremonies schetst, waaronder releaseplanningsvergaderingen, team Scrum of Scrum-vergaderingen, producteigenaar Scrum of Scrums Scrums-vergaderingen, vergaderingen om backlogs voor releases weg te werken, releasebeoordelingen en vergaderingen om op releases terug te blikken.

Agilent stelde ook rollen voor producteigenaren en rollen van programmamanager vast, en mat de voortgang met burnup-grafieken. Agilent nam verder lichte besluitvormingstechnieken over, hield ceremonies, gebruikte agile scrumartefacten en nam andere agile praktijken over.

Agile in actie

In november 2015 hield de afdeling Software en informatica van Agilent Sprint Zero een agile planningssessie van twee weken met veertien getrainde teams. Voor het OpenLab-chromatografiedatasysteem werd een productreleaseplan ontwikkeld dat acht maanden besloeg.

De activiteiten van Sprint Zero omvatten drie categorieën:

  • Teams opleiden omtrent de zakelijke en technische doelen, drijfveren en hoge vereisten voor OpenLab door middel van presentaties en posters.
  • De nieuw aangeleerde technieken gebruiken om vereisten te ontwikkelen en story's, epics en defecten te schatten.
  • Story's, epics en defecten uiteenzetten op het Release Planning-bord en alle afhankelijkheden tussen teams aangeven.

Agilent ontdekte al snel dat hun agile verbeteringen verder gingen dan het pilotproject. Een van de eerste indicatoren voor succes was intern. "Omdat we moesten samenwerken met andere Agilent-afdelingen, was het enorm belangrijk om te doen wat we zeiden dat we zouden doen”, zei Sadler.

Agilent zag ook externe verbeteringen. Feedback van klanten speelde een belangrijke rol in het toegenomen reactievermogen van de Agilent-teams op veranderingen in de markt. Door klanten vroeg in het ontwikkelingsproces te betrekken, verhoogde Agilent de softwarekwaliteit en verminderde het de markt- en integratierisico's.

Een van de inzichten van Agilent was om in de definitie van 'gedaan' op te nemen dat upgradestory's werden opgenomen in elke agile epic. Babita Jain, directeur softwarekwaliteit en Stefan Weiss, manager software-integratie bij Agilent, leidden de transformatie-implementatie en hielpen de teams de totale scope van het project te begrijpen. "We hebben de epic pas als gedaan beschouwd als deze de upgrades bevatte", zei Jain.

De agile transformatie verbeterde niet alleen de kwaliteit, maar ook de betrouwbaarheid. In 2016 werd het OpenLab-chromatografiedatasysteem op tijd geleverd. Sinds de agile transformatie heeft Agilent software geleverd in een gestage cadans en in het veld gerapporteerde defecten zijn afgenomen.

Succes meten

Agilent definieert en meet het succes van zijn agile initiatief met „lage faalpercentages in het veld en hoge klantloyaliteit”, zei Sadler. Klantbehoud is ook essentieel. In de volwassen, concurrerende markt in de biowetenschappen is uitputting van klanten een gevaar. De mogelijkheid om oude klanten een nieuw systeem te verkopen is essentieel.

Hieronder volgen vier kritieke statistieken die mogelijk worden gemaakt dankzij het Jira-capaciteitsmodelmodel van Agilent:

Burndown/burnup-grafieken

Agilent heeft eerder werk gemeten in engineering-uren, mensdagen of storypoints. Nu gebruikt iedereen burnup-grafieken om voltooid werk en de totale hoeveelheid werk bij te houden. Burnup-grafieken laten zien hoeveel werk er nog resteert.

Percentage van de op de markt gebrachte capaciteit (payload)

Het vermogen om capaciteit te modelleren en te volgen speelt een essentiële rol in de manier waarop Agilent succes meet. Jira maakte het mogelijk voor Agilent om een gedetailleerd capaciteitsmodel samen te stellen. "Met dit model konden we in de planningsfase de marketingafdeling vertellen met hoeveel storypoints ze moesten werken voor een release. De marketingafdeling mag de backlog rangschikken zodat deze kan voldoen aan die capaciteit," zei Sadler.

Telling en mediane tijd voor het leveren van oplossingen

Het capaciteitsmodel bood een meer gedetailleerd beeld. Hierdoor kon Agilent de capaciteit zien die werd besteed aan het oplossen van kritieke of ernstige in het veld gerapporteerde defecten versus defecten die het kwaliteitsteam ontdekte en rapporteerde.

Percentage van tijd besteed aan het oplossen van defecten ontdekt door handmatige tests

Het capaciteitsmodel helpt Agilent de tijd te meten die wordt besteed aan het maken van functies die klanten waarderen versus tijd besteed aan het onderhouden of ondersteunen van bestaande producten.

In iets meer dan drie jaar verdubbelde de divisie het capaciteitspercentage dat was gericht op werk met toegevoegde waarde, waardoor het werd verhoogd van 30 procent naar 65 procent. Naarmate de softwarekwaliteit verbeterde dankzij de nieuwe agile aanpak, waren er later ook minder defecten te herstellen.

Een jaar na het starten van hun agile transformatieproces beschrijven teamleden van Agilent verschillende 'vooraf'- en 'achteraf'-scenario's:

Vooraf: De prestaties werden gemeten in engineering-uren, persoonsdagen of storypoints.
Achteraf: Iedereen is het eens over het meten van snelheid en burndown.

Vooraf: Teams met verschillende niveaus van agile training hadden verschillende definities voor epics, story's en subtaken.
Achteraf: Iedereen in de organisatie spreekt dezelfde taal.

Vooraf: Scrummasters schreven code, leidden teamvergaderingen en bemoeiden zich met functieprioriteiten.
Achteraf: Scrummasters zijn taakmeesters die rapporteren aan productmanagers.

Vooraf: Functies met bugs kunnen worden goedgekeurd en defecten naar volgende ontwikkelingsfasen brengen.
Achteraf: Een universele definitie van 'gereed' zorgt ervoor dat bugs worden geëlimineerd vóór de volgende sprint.

Vooraf: Problemen deden zich vaak voor op het laatste moment, wat paniek en aanzienlijke vertragingen veroorzaakte.
Achteraf: Een gedeelde set tools die in alle teams wordt gebruikt, voorkomt verrassingen en helpt de focus te behouden.

Vooraf: Er was geen instrument om de capaciteit van een team om werk te doen te meten.
Achteraf: Er is overeenstemming over hoe de capaciteit dagelijks kan worden voorspeld en gemeten.

De agile toekomst bij Agilent

Zoals elke cultuur die waarde hecht aan continue verbetering, is de agile transformatie van Agilent geenszins compleet. De volgende stappen zijn onder meer het blijven verkorten van de cyclustijd en het aanscherpen van de mogelijkheid om vroeg inzicht te krijgen uit marktfeedback, enkele belangrijke elementen van DevOps-statistieken.

Agilent heeft de cyclustijd al drastisch verkort, waardoor jaarlijkse releases worden opgesplitst in twee cycli van zes maanden, ook al brengt het bedrijf jaarlijks releases op de markt. Het bedrijf is van plan de cyclustijd weer te halveren en over te gaan naar een driemaandelijkse cadans.

Klanten vroeg en vaak bij het ontwikkelingsproces betrekken is ook een onderwerp van voortdurende verbetering. Sadler meldt dat zijn groep vindt dat er minder arbitrage is tussen concurrerende belangen in discussies over productomschrijving wanneer er duidelijk bewijs is uit marktfeedback. Het handhaven van kwaliteit en bruikbaarheid voor klanten in het veld is een voortdurende prioriteit, en voortdurende betrokkenheid bij gebruikers helpt de bedrijfsprioriteiten te behouden: kwaliteit eerst en vervolgens de cadans en scope van releases.

Geleerde lessen

Sadler schrijft succes toe aan zijn team, waaronder de leiders Jain en Weiss, die agile-ontwikkeling omarmden als een manier om snelle en voortdurende verbetering te bevorderen. Met de juiste tools, zoals Jira en Confluence, kon het team het werk op één plek consolideren en de voortgang meten.

Agilent ontdekte dat een agile transformatie een sponsor vereist die toezicht houdt op onderzoek en ontwikkeling, inbound marketing en kwaliteit. "Als je niet alle drie kunt transformeren, zul je niet slagen", zei Sadler. "Je kunt een agile transformatie niet alleen laten uitvoeren via R&D." Het belangrijkste is niet het werk dat binnen de functies wordt gedaan, maar de manier waarop ze samenwerken.

Agilent vond het ook essentieel om de veronderstelling los te laten dat een perfect begrip van de behoeften van de klant al inhouse aanwezig is. Een agile aanpak is bedoeld om producten uit te brengen volgens een betrouwbare cadans en vervolgens direct feedback van klanten te ontvangen. In deze aanpak moeten releasedata heilig zijn: wanneer de deadline is bereikt, verzendt het team het product zoals het is.

Tot slot merkt Sadler op dat het agile framework problemen zichtbaar maakt. Agile legt bijvoorbeeld hiaten in de capaciteit bloot. Het onthult de delen van het proces zonder toegevoegde waarde die vertragingen veroorzaken en kwaliteitsproblemen aan het licht brengen. Het overschakelen van een watervalbenadering naar een agile aanpak vereist niet alleen veranderingen in de manier waarop teams werken, het is ook een culturele verschuiving. Agile stimuleert een cultuur van continue verbetering die ronduit besmettelijk is.