At its core, organizations are demonstrating meaningful business agility when they are able to deliver value to the market in progressively smaller increments, minimizing the delay required to gather market and customer feedback. Almost all agile methods will include some technique to take a large loosely defined increment of work, break it up into smaller increments, and then delivery these increments independently of each other. During this post I’m going to go over three different ways to think about breaking down work in the smaller increments, each of these different approaches require thinking about value from a fundamentally different mindset.
The Minimum Viable Product (or MVP for short) is a term that is gaining increasing traction within the enterprise over the last couple of years. The term has become somewhat loaded to mean different things to different people. Some define an MVP as a product increment defined in such a way as to get value into the customer’s hands as soon as possible, measure their response, and use that data to inform the choice of what to work on next.
A more formal definition of an MVP would be the smallest increment of effort that can enable us to learn whether we have a viable product in the context of a highly uncertain market. Using this thinking teams would deploy different strategies to introduce features to customers in such a way as to be able to test how those customers would react to the speeches. In many cases the early MVPs of a team would contain little to almost no software, favouring interviews, mock-ups, and manual prototypes. Even as the product start to mature in terms of feature completeness, the focus stays on continually learning while delivering value.
How we approach thin slicing our work into smaller increments of value can depend on what the term Minimum Viable Product means to us. In this post I’ll give a brief overview of these different approaches and some of the advantages they offer. These approaches include:
It’s fairly common for teams getting started with agile to continue to think about their work from a more traditional mindset. Using this thinking, the team takes larger work items, such as projects, stakeholder requests, customer demand, etc., and decompose the work into smaller deliverables, interim milestones, and explicit tasks. The team will then go about managing their work using a mixture of agile practices such as visual management, sprint planning, standups, etc to improve collaboration within the team and with stakeholders. This can be a fair starting point for some teams, especially non-technology teams, as it allows them to get comfortable with some of the mechanics of agile while minimizing disruption.
Teams working in this manner tend to track their work as a set of deliverable/milestones or activities that go through a very simple task management workflow (ie: Plan, In Progress, Next). The approach has the advantage of being intuitive, as it tends to be similar to how people often currently think about their work. Using this breakdown technique with visual management provides focus on getting things done, and this can help prevent the team from being overloaded. It’s easy to understand who’s doing what, and the team can plan future work based on a more informed throughput and understanding of the team’s capacity to deliver.
However, the approach has very real disadvantages, the biggest one being is that while the teams are introduced to some agile techniques, they are still thinking about value from a traditional perspective. I have seen a number of teams moving along the agile journey stop here, as a result customer value doesn’t get delivered more frequently, and true business feedback does not increase .The focus stays on deliverables and tasks, which often does not lead to any real improvement from end to end perspective.
An alternative approach involves taking a more value centric mindset.