Here’s number two on my list of principles for data teams embedded in biotech organizations:
The primary measure of progress is data-driven scientific discovery.
This is a very intentional riff on the principle from the Agile manifesto that working software is the only measure of progress. The Agile version was a response to early software development approaches in which separate teams would follow detailed specifications to write software components over the course of months before trying to fit them together at the very end. The Agile Manifesto instead suggests that all these components should be put together as early as possible, long before they’re done. This way, you have functioning (if incomplete) software that will give you a more realistic measure of progress from very early on.
In the context of an embedded bio data team, where the scope of the objectives and accountability is much broader, it isn’t enough to just have the software fully functioning early on. We need to have the end-to-end process from wet lab to data team and back, generating scientific insights and advances.
In other words, it doesn’t matter if your app does everything the wet lab team asked for. If they’re not using it, or they’re using it but not learning anything new, you’ve fallen into the same trap as those early software developers: Building components independently then hoping they’ll fit together at the end. This is premature productionization. In the same way that Agile encourages you to put the components together into working software as early as possible, this new principle suggests you do this on a larger scope that includes the processes around the tool. Get to that first scientific insight as quickly as possible, before you implement that next feature.
You've touched upon an important weak link in Agile - usability. Wet lab resources are very constrained compared to code. CI/CD is not intended for mission critical processes. Can you imagine an artificial heart being given updates every second? Even if the code works, it could be fatal.
A poorly conceived Agile rollout might dissuade bench researchers from even giving the software a second glance. Stable releases have their place.