*** Before we get back into my list of development principles for Biotech data teams, I need your help. Or more specifically, I need a name for the principles. Please fill out this form to vote on a name or suggest a better one. If you’re the first to submit a name that I go with, I will thank you on this newsletter (unless you don’t want me to). ***
As we get near the end of my list of development principles for Biotech data teams, we’re starting to hone in on the heart of the matter. One of the key concepts associated with Agile development is to start from a minimal viable product (MVP) and continuously iterate. This week, we’ll explore what the equivalent is in this new context:
It’s better to evolve processes and tools incrementally, in parallel, based on continuous feedback, rather than introducing major changes all at once.
There are two main ways you can fail at this while still technically following the Agile principles. The first is to get incremental feedback on a tool or system via mocks or demos, but without having users use it in production. Then when it’s “ready”, you have to do a big rollout and migration. This is more common with off-the-shelf software, particularly ELNs and LIMS, where it feels like you need to implement everything before anything will work. But it also happens with internally developed tools when teams push back the initial rollout so they can fix or add just a few more features.
The second failure mode is to iterate on the tooling without addressing the processes around it. Often data teams will assume that what the wet lab teams do is set in stone and not up for debate. But in practice, there are always aspects that can be adjusted, particularly if you have an open discussion about trade-offs of different options and how they impact the organization’s scientific objectives. If you’ve followed the principles that we’ve gone through so far, you’ll find the tools (such as empathy) to have these conversations.
Iterating on tools without iterating process in parallel is asking for problems.
May I suggest that you are laying the groundwork for the other MVP, the 'mvp'. A search for "Minimally Viable Product" ~ 50K hits. A search for "minimally viable process" less than two hundred.
The initial Requirements Gathering for a product can inadvertently fossilize what should be a living objective. Agile seems easiest and is the perhaps the most dangerous when there is only one degree of freedom, that of the data team . You're right that ongoing "deliberate empathy" is helpful. The wet lab and the data bench might be lacking rapport, they likely do not share nuanced vocabulary. People do tend agree to hazy notions, and need a mechanism to review and refine them. Incrementally.