This week, we’ll continue with development principles for Biotech Data Teams related to collaboration, with a principle that may seem obvious, but is hard to get right in practice:
Development timelines should be deliberately coordinated with experiments to maximize opportunities for feedback.
To understand what this means and why it’s difficult, let’s start with what it looks like without this principle. Software and data teams, particularly those influenced by Agile, tend to define timelines by working forward based on estimates. They figure out what they want the final product to look like, decide the most logical steps to get there, estimate how long each step will take, then plot out what this looks like on the calendar. (This is if they write down a timeline at all, which is kind of rare.)
The problem if you do this on a biotech data team is when you get to a point where you’re ready for the lab to try out what you’ve built, you’ll often find that you missed the bus. The next experiment that could use your work may already be too deep into planning to change course now. There may not be another suitable experiment for months.
Software teams that keep a release schedule deal with a similar problem internally: They have a deadline when the release “bus” will leave, and any feature that isn’t ready by the deadline has to wait for the next release. So instead of saying it’ll be done when it’s done, they often split their work into smaller chunks to make sure they can get something onto the bus.
With experiment schedules, this is a bit more complicated because someone else controls the schedule, and it rarely has the regular cadence of software releases. But if you deliberately coordinate with the wet lab teams, you can find out when the next bus is leaving and make sure you have something ready for it.
Instead of planning forwards based on the technical work, you’re now planning backwards based on when you can get feedback from the lab. This might mean using a model that you’re less confident in, or emailing spreadsheets before the app is ready, but the most important thing is that you catch the bus.
Speaking of Coding and Data not wanting to "miss the bus", the Wet Lab cannot afford to "Miss the Truck". In the manufacturing world, missing a shipping deadline can bankrupt a firm.
For the Wet Lab, patents, licensing, funding, go-to-market, quarterly earnings, hand-off to engineering, trade shows, are just a few concerns. Many of us have been burned by "New and Improved", so even with "Coordinate Rollouts" there will be a temptation to go instead go with "Tried and True" A double of "Deliberate Empathy" might be in order.
In principle this is a great idea. A could be a bit tricky, tho. Getting the budget is a 'small' issue, since the code shouldn't delay the wet lab.
The easiest rollout would be a strictly performance release, e.g. speed or storage. The most challenging would be one where features which the wet lab have gotten accustomed to, get removed. New features, especially those requested by the wet lab, like any x.x.0 release, might be a bit buggy, so testing and repair time needed.
Getting the lab liaisons involved in testing before full deployment seems prudent.