Agile software development typically works toward creating a minimum viable product (or minimum lovable product as we’ve said)—but if you’ve ever hit a few integration hiccups before going to market, you know the MVP/MLP approach isn’t perfect.
As the software architecture stack evolves and product demands become more challenging for developers, we need to refine the MVP/MLP approach. Implementing a minimum viable bureaucracy will help, but we need to do more.
Go deeper than MVP/MLP and shape your agile software development around minimum testable features.
How We Learned to Go Deeper than Minimum Viable/Lovable Products
Whenever we finish a client project, we like to do a retrospective on how things went. What worked, what didn’t work, how we aligned with our values, and how we can improve our strategies and processes for the future.
Early on with our software development projects, we noticed a consistent issue coming up in our retrospectives.
We were building a front end to pull data and define the user interface while separately creating an API layer on the back end to run all of the logic. Because these two are so heavily co-dependent, we would try to bring them together toward the end of a project and inevitably see some integration issues.
These integration challenges wouldn’t derail our projects, but looking back we realized that we could avoid them altogether if we just planned our sprints and stories better from the very beginning. This is what gave rise to the minimum testable feature (MTF) mindset.
What Is a Minimum Testable Feature?
Your final product is going to be full of features defined by your development team and the stakeholders involved. But at the very start, we break that final vision out in epics so we can plan sprints effectively.
These epics are essentially the high-level features that you expect to exist in your MVP/MLP. With a minimum testable feature approach, you plan out the stories for each epic such that the front end and backend are working on each feature concurrently. Additionally you assign one of the resources working on the feature to be the feature-owner. This person is now responsible for not only their portion of the feature, but the overall end functionality of the feature.
Typically, as a developer, you would finish your part of the feature and continue on to the next one once you’ve run your unit tests and mark it complete. With an MTF, you go beyond the individual testing and work closely with the front end or backend to ensure that the feature is covered by not only unit tests, but integration tests as well to ensure that the entire feature as a whole is complete. During this process is when the small integration bugs are found and fixed before ever getting to quality assurance. Then, once the feature owner is satisfied with the quality, they demos the feature to the quality assurance team for final sign-off and approval.
Taking the MTF approach lets you address bugs early, minimizing your technical debt in the project, rather than waiting until the end to integrate the front end and backend. When you can tweak little issues out of the project early on, you can shorten the feedback loop and save a lot of time down the road and enjoy the benefits of an iterative checks and balance system. The MTF approach also increases communication between the different sections of your product (front end, backend, mobile, etc.) creates more product ownership and increases development quality within your development team.
When you shift from a strict MVP/MLP mindset to an MTF approach, you’ll have to front load more effort into your sprint planning, thinking through not just what your features are, but how to time their implementation and lay out detailed descriptions and acceptance criteria for each feature. This front loaded effort allows for shortened feedback loops, better product quality, and an over all quicker development time.
A Word of Caution for the MTF Approach
One of the great consequences of an MTF approach to software development is that you create functional features iteratively so you have something to showcase for stakeholders.
When the front end and back end are disconnected, you don’t have an integrated product to visually demo until the very end of the project. The front end might be beautiful, but it can’t do much without the back end. And showcasing the back end would just be a raw API that does little to excite stakeholders.
But while it’s great to showcase features early on, there’s one word of caution to keep in mind—creating awareness could lead stakeholders to request new directions and new features.
The key to implementing a MTF minded project is to manage expectations throughout the entire project. The backlog might change as the project progresses and you demo real functionality to the stakeholders, but that's what the agile methodology is all about. The trick to a successful project is to manage the stakeholders expectations and to communicate clearly the pros and cons to each change of the project scope.
The MTF approach gets to the true heart of agile development—iterating as soon as possible so you don’t have an entire project that has to be scrapped in the end. But planning more effectively in the beginning is just one piece of successful software development.
If you want to learn more about our own processes, check out our free ebook, New Product Development Process for Software.
Editors note: Updated 05/23/2017 with Slideshare