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.
Mostly I was thinking of the overall process rather than the project or product. For instance, on family cross-country trip, one might separate schedule for rest stops and food stops. Modifying the trip on the fly to make the planned stop for one an opportunity to achieve the other, could be a nice win-win.
In the data :: wet lab situation, downtime for 'maintenance' could be a useful point to engage the teams, rather than wait for the 'scheduled' meeting a day or two later.
Another, could be realtime highlights from a conference across teams back home.
Meetings and paperwork tend to be a drag on productivity, of course, A goal is to maintain a healthy 'signal to noise ratio' in comms, hopefully avoiding unpleasant surprises.
How do see leveraging Minimum Viable Change for these sorts of indirect activities? Or not.
So, a lot of those indirect activities are habits and the bad habits are often a way of coping with a gap that can be filled by a better tool. But if you just introduce a tool that fills the gap, the habit is still there, and can actually block users from using the tool in a way that fills the gap.
For example, some users insist on capturing decisions in emails because they know that they get lost otherwise. So you can introduce shared docs (GSuite, Sharepoint, whatever) which is an even more reliable way of capturing decisions. But if all the decisions are in email, the docs get outdated and never become a reliable source of truth.
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.
Yes, but I call it the minimum viable change (https://scalingbiotech.substack.com/p/the-minimum-viable-change)
Point taken. And well put.
Mostly I was thinking of the overall process rather than the project or product. For instance, on family cross-country trip, one might separate schedule for rest stops and food stops. Modifying the trip on the fly to make the planned stop for one an opportunity to achieve the other, could be a nice win-win.
In the data :: wet lab situation, downtime for 'maintenance' could be a useful point to engage the teams, rather than wait for the 'scheduled' meeting a day or two later.
Another, could be realtime highlights from a conference across teams back home.
Meetings and paperwork tend to be a drag on productivity, of course, A goal is to maintain a healthy 'signal to noise ratio' in comms, hopefully avoiding unpleasant surprises.
How do see leveraging Minimum Viable Change for these sorts of indirect activities? Or not.
So, a lot of those indirect activities are habits and the bad habits are often a way of coping with a gap that can be filled by a better tool. But if you just introduce a tool that fills the gap, the habit is still there, and can actually block users from using the tool in a way that fills the gap.
For example, some users insist on capturing decisions in emails because they know that they get lost otherwise. So you can introduce shared docs (GSuite, Sharepoint, whatever) which is an even more reliable way of capturing decisions. But if all the decisions are in email, the docs get outdated and never become a reliable source of truth.