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/

Agile Success Measures to answer the question "How do I know when I'm Agile"?

I often get asked, “How do I know when my company is Agile? ” While I have various answers, it led me to construct an Agile measurement framework that helps you guide your Agile transformation toward success.  

    

I start by asking, “What outcomes an organization would like to see when they go Agile?”  Agile asks that you consider your outcome instead of output as a measure of success.  I would suggest that being Agile should only occur if your outcome is some type of better business results.  In other words, Agile shouldn't be the outcome of being Agile.  The good news is that organizations are looking for better business results.  This could be in the form of shorter lead times, reduced whip, or an increase in revenue.  Sometimes it can be all three. It is important to understand that outcomes are lagging metrics.   Now that we have highlighted the importance of outcomes, let’s add two ingredients to give us perspective and help us build the framework.

For the first ingredient, I will take a page from the book Being Agile in Chapter 2 “Crossing the Agile Chasm”.  When we discuss Agile adoption, we are talking about a change to the organizational culture.  This is because adopting Agile is more than learning skills or understanding a procedure.  It is about adopting a set of values and principles that require change in people’s behavior and the culture of an organization.  This mindset and culture change involves the most time for an organization to adjust.  According to Paul S. Adler and Aaron Shenhar, “Adapting your Technological Base: The Organizational Challenge”, a culture change is measured in years.   

For the second ingredient, I will take a page out of the article Agile Lagging to Leading Metric Path.  This article highlights that an Agile lagging to leading metric path recommends that for every outcome (aka, lagging indicator), you supplement it with corresponding leading indicators that provide you with visibility during an Agile transformation.  Capturing the leading indicators helps you steer toward a successful Agile transformation.  The leading indicators are effectively feedback loops that help you understand if you are leading toward your outcome.

Now that we have the two key ingredients, the goal is constructing an Agile lagging to leading metric path that recognizes that change takes time and provides us with feedback to adapt toward a more successful Agile transformation.   Lets start with the outcome.  For my Agile transformation, the key outcome is that we are seeing better business results for our products, translated into increased revenue for our business.  From this, I need to consider what leading indicators help guide me toward better business results.   From my Agile transformation experience, I will suggest that the two broad leading indicators are adopting Agile mechanics and embracing the Agile mindset.   This is illustrated within this lagging to leading framework.

This illustrates several conventions.  The first is that from an Agile perspective, in order to get to better business results, we must educate folks on the Agile mechanics and Agile mindset.  As we do this, we gain feedback so that we can adapt the Agile journey to ensure more success in our Agile transformation and achieve the better business results we are looking for.  The second is that applying Agile mechanics tends to be easier and takes less time since it involves learning skills and understanding procedures.  Adopting an Agile mindset takes more time since it requires changes in people’s behavior and the adaption of the organizational culture.  The end result (outcome or lagging metric) is that we hope to see better business results by first implementing Agile mechanics and adapting to an Agile mindset. 

The last task at hand is to create measures within each indicator to gauge progress.  For the Agile mechanics, capturing a training metric is helpful.  In order for people to mechanically adopt Agile, they need some form of education in their role (e.g., Scrum Master, Product Owner, etc.) and education in the process (e.g., Scrum, Kanban, etc.).  Then you can assess if the mechanics are being applied.  If education doesn’t occur or the mechanics aren’t being followed, this can impact your success.

For the Agile mindset indicator, you need to gauge if there is a shift in ways of working. You can assess if the Scrum Master is exemplifying servant leadership, you can gauge if management are allowing for self-organization, you can assess if the team believes in the Agile values and principles, and you can determine if the product owner and organization are adapting to customer needs based on actual feedback and to delivering early and often.  You should also gauge if the team is incrementally improving the mechanics, meaning are they applying the retrospective for the team to improve their ways of working. If the behaviors behind the Agile mindset are not occurring, how do you expect to be Agile?   This is why they are all leading indicators to getting better business results. 

I hope this article may provide you with a framework to help you more effectively gauge “How do we know when we are Agile?”.  It highlights that if you are looking for the business benefits that Agile can bring, then establishing an Agile measurement framework based on lagging to leading indicators can help guide you achieve a more successful Agile transformation. It is then up to you to identify what is your outcome, then your leading indicators to know if you are heading in the right direction.  Many end their journey with adopting Agile mechanics without adapting their culture toward an Agile mindset.  Stopping at the mechanics is why many organizations fail at Agile.  Hopefully this framework can help you see the bigger picture toward Agile success and the business benefits it can bring.  

Agile Executive Playbook

Imagine that you are an executive of a company (and quite possibly some of you reading this are or have a direct line to an executive).  You’ve heard about this thing called Agile and some of you have experienced it.  However, Agile is still a bit confusing because in many cases, it appears to be occurring only at the development team level and can occur in many different ways.  Some of you believe that Agile is a set of practices and tools and may be surprised to know that it is nothing-more-and-nothing-less than a set of values and principles.   Maybe some of you haven’t seen the connection between applying Agile and gaining the business benefits.  What exactly is your role and responsibilities in moving your company toward Agile?  Here is guidance on what you may do to support Agile and more importantly increase your chances of deriving the business benefits of Agile. 

Strategic Shifts           

The key responsibility for the executive within the organizational scope is to become the sponsor of the Agile initiative.  This highlights to the employees that Agile is important and increases the chances of buy-in.  But simply proclaiming “make it so” isn’t sufficient.  The executive must continue to be a key player in this on-going sponsor role.  Here are strategic shifts that are beneficial:

• Study the Agile values and principles.  Knowing this language helps you become more conversant in Agile and to the teams and organizational players that are involved.  Studying the values and principles will also help you ascertain if you really believe in them (or not). 
• Move away from the iron triangle of schedule, cost or scope and move to a framework focused on value.  Prioritizing ideas via cost of delay will provide a much better value-driven pipeline of ideas.  These ideas can be decomposed into increments that can then be validated with fast feedback loops. 
• Measure and adapt the flow of your end-to-end concept to cash pipeline.  There is a tendency to focus on just development, but it is often other parts of the pipeline where ideas wait much too long.  Consider value stream mapping to better understand waiting states and no or low value steps. 
• Adapt the organization from a hierarchical organization to more of a self-organizing organization.  When employees feel that they have more ownership and decision-making of their work, they will apply much more brainpower and bring passion to their work.

Key Sponsor Activities

Now let’s take a look at the more in-depth activities that you as an executive should consider playing and why.  These are more tactical, but since becoming Agile doesn’t happen overnight, they help keep the engagement and interest along the way. 

• Treat your Agile initiative as a journey.  Because this does take time, it would benefit you to build an adaptable roadmap.  This may be best handled with a small local team of Agile champions who are committed to adopting Agile and an Agile consultant who has experience in this area.  To get a good understanding of what an Agile roadmap may look like, consider reading the book Being Agile: Your Roadmap to Successful Adoption of Agile.
• Build a learning culture.  Consider establishing an education vision on how to best educate your organization. Infuse the education with experiments and experience. I suggest starting with the Value, Flow, and Quality materials that provide the reader with great insight into many of these new concepts and ideas, along with case studies and activities.
• Build the foundation for a Customer Value-Driven Enterprise.  This is a company that is explicitly looking for the highest value ideas, applying an incremental mindset, and applying feedback loops to validate value along the way.  Learn more by reading The Agile Enterprise.
• As an executive, examine your own behavior and align it with the Agile mindset of Agile values and principles with a focus of delivering customer value.  Are you speaking the language of Agile and the strategic shift that you are looking to achieve? 
• Provide funding for the Agile initiative.  Funding should include meeting education needs, bringing in talent (coaches) as needed, and providing tool support. This may occur incrementally or per the budget cycle.  
• Periodically provide public support for Agile. Establish an Agile communication plan, of which portions can be executed over time to keep employees aware of the progress and accomplishments of the deployment.  This may also include providing 'air cover' to the Agile deployment team and the coaches and champions and mitigating the risks that could prevent a move to Agile.  
• Consider your staff.  Ask yourself, “are they Agile minded and aligned with the cultural shift that is needed?”  You may need to be involved with making adjustments to staff members who cannot make the switch away from command-and-control. This can be hard to do, but if they don't, then those around them will not take the change seriously.
• Learn how to read agile metrics and measures of success. Gaining an understanding of the lagging to leading metric path, sprint burn-downs, release burn-ups, value capture, release frequency, Agile Mindset, Values, and Principles (MVP) Advisor, and other Agile-related metrics can help ensure the organization is moving in the right direction.
• Adapt the employee compensation model toward agile behaviors being sought and away from rewarding command-and-control attributes. To change behavior, recognize the behavior you want to change, evaluate the reward system, and adapt it to the behavior that is needed for Agile. Without aligning the reward system to Agile, you will not get to behavior you want.
• Attend the Sprint Reviews of your top products within your organizational scope. This will give you a genuine sense of progress and see actual working functionality of your products.

The intent of this article is to provide highlights of what an executive can do to get the most business benefits from their Agile initiative.  There can be other perspectives and further details.  As an executive (or those who have supported executives), what have you found helpful in your Agile journey?