Nine years ago IDEXX created a 15 person “agile” team to create a new labs info management system for IDEXX worldwide, called LYNXX. This system did it all: CRM, Billing, Diagnostics, Instrument interface, Report generation, Fax and Email. It served its purpose well at the time as there were no commercial products similarly designed for the animal health space.
From an agile perspective this large team had a product backlog and worked in iterations. However, it lacked a product owner, stories were sized at the task-hour level, and there was always hidden work: technical enhancements, integration with other enterprise apps, interfaces with lab instruments. Prioritization and predictability were major challenges.
The team that developed LYNXX was a group of highly skilled architects, Java developers, systems analysts and testers. They all had their silos of expertise. You had the Java swing client developers, the Web Logic service developers, Middleware engineers, the billing analysts, the chemistry analysts, the fax/email specialists. They all worked on an assigned module and were considered SMEs in their area. Again, this worked very well to build this large, robust application and the labs were pleased. Users knew exactly who to turn to if a bug was found or an enhancement identified.
However, a lack of a central product owner made it difficult to determine which enhancements and defects to focus on. So each group of SMEs continued to develop the app in their area.
Several years ago, IDEXX revenue growth really began to take off. Acquisition strategy led to a significant increase in IDEXX reference labs volume in North America and across the globe. LYNXX was being rolled out to some of the higher volume labs in the US. And then we ran into a scalability problem. The app had amassed a significant amount of technical debt… and we discovered that changing the Beast came at a significant cost.
Six months was spent ripping and replacing 80% of the code onto a modern SOA stack, and another six months in test/fix/test/fix. The results were significantly improved performance … 15 team members did a great job putting Humpty Dumpty back together again…
This was done in a waterfall fashion. Consultants were brought into re-architect and rewrite the service layer, internal developers were then assigned to integrate the swing client application to the new service layer, and internal testers were then given the application to test against the existing regression suite and then user acceptance testing from the business side to test against the many workflows across the global regions. Ultimately, a very performant system but at a huge cost.
Two years ago our new CIO Ken Grady, implemented a cloud first strategy. Our first mission was to peel away 3 of the 15 member dream team to implement a scanning app using AWS micro services. We were able to build a very discreet application to serve a very specific function for the labs. This led to our next mission to take those 3 members and add 4 more to rebuild our Report Generation module in the AWS cloud. Thus, a new Agile scrum team was formed, with a new product owner. And while we have at times been on the bleeding edge in working directly with the Amazon Web Services product teams, the ensuing results have been vastly improved performance and more retired tech debt.
Along with the strategy of moving infrastructure and platform to the cloud, was to offload ancillary functionality to “petals” or integrated best in breed solutions. Billing to SAP, CRM to Salesforce, Instrument connectivity to Instrument Manager. And so we peeled off another 3 team members from the Beast’s Dream Team… and yet a third scrum team was formed with a new product owner.
We now have 3 scrum teams in the program. Each team has its own business milestones but they often have interdependent release deliverables, so a good deal of coordination is needed. The teams have their own dynamics and their own maturity levels. We don’t try to create a one-size-fits all approach to estimating and sizing, but there are opportunities to align on agile approaches that we haven’t yet explored. Overall, we can gain a good deal more productivity and visibility across the program’s multiple work streams. We can pivot to change much more quickly, manage smaller, more-focused product backlogs and provide our stakeholders more predictable outcomes.