Determining Your MVD (Minimum Viable Data)
In agile, your priority is always to satisfy data users and stakeholders through early and continuous delivery of valuable solutions. But there is a lot of investigation, exploration, testing, and tuning required to make real sense of your data, and that’s where your MVP (minimum viable product, or MVD, minimum viable data, for our purposes) comes in. When you determine your MVD, it needs to be more than just that — your solution needs to be viable, but also achievable, and desirable.
Where Do You Start?
It’s essential for business, data, and IT groups to collaborate while determining MVD. Business decision makers often come to the table with a specific need to address or a desired result — they’ll help you understand what is desirable in your MVD. Once the business has provided both what they want to achieve in unbiased terms and some wide-ranging ideas on how to execute, your team needs to determine the difficulty of those ideas, their cost-benefits, and then rank them. The data and IT groups are often the ones implementing the MVD, so it’s important to rely on their expertise when understanding what will actually be achievable. It’s much more likely you’ll come up with a successful solution once everyone is involved and has provided their opinion.
With enterprise businesses typically seeking a larger success up front, narrowing down to a true MVD can be difficult. This is why it’s important for your team to rank these options by complexity and value in order to select an initial ‘low-hanging fruit’ option so you can begin working toward your end goal quickly by breaking the process down into iterative cycles. Keep in mind that your MVD shouldn’t include everything your team wants to implement, it should only include the first iteration that gets a data solution into the hands of users.
We suggest you start with a pilot project to prove out your concept and gather buy-in before you begin. Keep things simple and contained by beginning with one set of source data instead of trying to tackle it all, building only one model instead of a new architecture, or choosing one report rather than an entire product.
Fail Fast; Delivery On Every Sprint
If teams can’t get something out of your data initiative right away, they may not want to be involved further. That’s why it’s important that you work in quick, iterative cycles to produce something of value that’s easy to put into the hands of users. Alternatively, you must ensure that your next iteration or ones thereafter will have that golden nugget – this is foundational to the next steps of your project and the heart of agile.
In the initial cycles, you're in the process of laying a foundation to get the next success, and the one after to provide for a more viable, valuable MVD – we refer to this as failing forward. You will inherently compromise some value by trying to bring something to the table quickly (don’t panic, this is part of the process), so pick a simple vertical and fail quickly. As long as you learn and make adjustments, the “failure” is still progress.
Working in this cadence, you should ideally be delivering something on every sprint. If you’re not, your sprints are too short – the typical cadence is two-week cycles, but based on the complexity of your project, be flexible in extending that.
The scenario: A business wants the necessary data to be able to scale operating costs based on changes in demand. This is a massive undertaking that has many facets (staffing, project scale backs, supply chain issues, etc.). Instead of trying to tackle everything at once, focus on a particular use-case or facet of the problem that can be solved first.
MVD Use Case: Forklift operator staffing correlating to demand changes.
Small win: Determining that they can operate with less operators seasonally.
Larger win: Transporting that knowledge to other areas of the business.
Main deliverable: The business gets an understanding of how to scale operations based on demand.
Big Blockers To Delivering MVD
While it’s imperative that you deliver something to the business upon every sprint, you should be aware that there are often blockers to this process. Typically it’s a misalignment or lack of mutual buy-in from the business and the team responsible for carrying things out, but there are other issues that can crop up as well.
For one, different parties may look at the same data entirely differently. To best alleviate this, pull these teams together. It’s not easy and you should start with teams that need the least momentum to meet in the middle, but if there is any reason for them to work together, build a combined team between them. Anytime you need to ask for help beyond your team, your data efforts can slow. A good way to avoid this is by including someone from every function that will help make decisions on your execution team.
Since the agile process seeks to get rid of red tape and empower team members, governance and oversight of data also provide a bit of a quandary, forcing your team to navigate a governance body while maintaining the “just move forward” mindsight of working in iterative cycles of agile. The more your team needs to reach out to others to do this moving forward, the slower their progress will be.
It can also be hard to test your solution without production data – something usually found outside of your team. We suggest you try and get as close to actual data as possible to test the viability of your solution. Mock data works okay, but a sandbox with real data is better.
Ensure ‘Quick Wins’ Are Tied to Business Value
‘Quick wins’ in your iterative cycles sound nice, but when business decision makers don’t see how it ties back to their main objective, then they won’t be wins at all. Your team needs to ensure that every win they claim is directly tied to business value. To do this, make sure all of your goals have a business aspect when you are prioritizing steps in your process. An easy way to go about this is incorporating business value rankings that can help to determine what you should deliver when.
Wrapping Up
Always be mindful that, while much of your MVD is initially determined by business decision makers, it is still a process. You will certainly expand out from your initial MVD, but it defines a starting point that allows you to show success (or fail forward) quickly.
Get a deeper dive into determining your MVD in our complete guide here.
