What really is an MVP in an Agile World?

There is often a bit of misunderstanding of what is an MVP (Minimum Viable Product) in an Agile context (and I contend in any context).  MVPs are meant to provide the minimal functionality or feature set that will be useful to customers.  However, to attempt to define the minimal set up front means that you know what the customer wants from the start.  How often do you know what the customer wants at the beginning?

Instead, think of an MVP as an opportunity to learn what the customer wants, loves, and needs.  It should neither be fixed nor should you be certain of what it is.  Instead it should be considered an evolving concept from which you learn what the customer wants over time based on continuous feedback.  What mindset shifts might you have to make in order to adapt to what an MVP is in an Agile world? 

The first Agile mindset shift is the MVP is a draft.  Defining an final MVP upfront is akin to big-up-front planning and claiming certainty.  Instead, you hypothesize what the minimal set of features might be as a draft, and then have a mindset and practices where you validate your assumptions and hypothesis.  You start with an adaptable idea of what might be minimal and valuable to the customer. The moment you attempt to succinctly define the set of features, you are doing a disservice to your customer. 

The second Agile mindset shift is that customer feedback is key to evolving the MVP.  It is an opportunity to learn what the customer wants, loves, and needs.  If you want your MVP to align closely to customer value, you must include continuous customer feedback loops when working on an MVP.  These can take the form of customer demos or hands-on sessions.  Customer feedback can start as early as when you are hypothesizing what is an MVP and must be part of evolving the MVP to gain a strong inspect-and-adapt mindset with the inspect coming from the customer.  Eric Reis writes that an MVP “allows a team to collect the maximum amount of validated learning about customers with the least effort.”  Customer feedback is the cornerstone to validated learning and establishing an MVP. 

So who really determines what is the MVP?  If you think the answer is you, your management, or your team, then maybe its time to Reduce your certainty and Ready your mind with the Agile mindset, discovery mindset, and Feedback loops. The right answer is the customer determines what is the MVP in Agile.  The more closely you align with customers throughout the effort, the more likely you will have an MVP that is considered valuable to the customer.          

Are Google’s OKRs compatible with Agile?

A collaboration by JP Beaudry and Mario Moreira

Recently, someone asked us if we thought that the Objectives and Key Results (OKRs) used at Google and applied at Intel in the 1970s is compatible with the Agile mindset. In order to refresh our understanding of OKRs, we reviewed the Rick Klau presentation on How Google sets goals: OKRs. After examining the characteristics of OKRs, and with a few open questions, we are of the opinion that for the most part, they can be used in support of the Agile mindset. 

To provide a basic understanding, OKRs is a technique for setting and communicating goals. The first part, the objective, is the outcome that is sought. While the second part, the key results, is comprised of 3 to 5 specific and measurable pieces of evidence of progress against the objective. OKRs can be cascaded and refined at various levels in an organization. In order to allow people to be bold and think big, the guidance is that only about two thirds of OKRs be completed within a given period of time. To promote transparency, everyone’s OKRs are publicly accessible and graded.

Now back to the key question – Are OKRs compatible with Agile?  Based on our examination of OKRs, here are some reflections:

Ambitious - By design, OKRs should only be met or succeed about two thirds of the time. This lines up well with the general desire for organizations to be more innovative. There is a broad agreement that innovation is inherently uncertainty/high beta, and that a certain amount of failure/learning is inevitable. A goal of imperfection makes it safe for people to take chances

Measurable - Measurable outcomes are critical in determining whether one is getting closer to the stated objective. This is well aligned with Eric Ries’ concept of Validated Learning. It also plays well with Mario Moreira’s framework of a Lagging-to-Leading metric path. 

Public - I’m sure the public display of OKRs does wonders for creating alignment on priorities. This is because it makes it so much easier for all stakeholders to notice, and more importantly correct, misalignments. So much the better if the full cascade from strategy to team-level user stories is visible in one place. 

Graded - Grading OKRs forces participants to confront reality. Without an explicit process step where results are confronted, it’s too easy to skip the learning step. Without the result-driven feedback, roadmaps cannot be updated.

Because we haven’t worked with OKRs on a sustained fashion at scale to date, we have a few open questions on how they would fit in an Agile environment:    

Individual or Team

At what point does the individual accountability get in the way of teamwork? Most Agile organizations spend a tremendous amount of energy creating high performing teams. It seems that individual OKRs could undermine teams

Local or Global Optimization

A corollary is how to prevent local optimization that could make top-level objectives more difficult to attain. Would OKRs promote a narrow view?

In summary, it seems to me that the Objectives and Key Results (OKRs) technique has several characteristics that make them compatible with Agile environments, and few obvious downsides. The fact that OKRs are also used at LinkedIn and Twitter seems to provide further evidence of their usefulness in innovative environments. 

If you have experience with how OKRs can be used in an organization that values Agile and the discovery mindset, please consider sharing.  Bonus points if you can shed some light on the open questions in the article.  

------------------

To read more of JP Beaudry's articles, visit: http://www.thepragmaticleader.com/   

To read more of Mario Moreira's articles, visit: http://cmforagile.blogspot.com/