How to Get Executive Buy-In for Agile Using Two Popular Product Development Approaches

One of the most common complaints from teams going through an agile transformation is that their bosses don’t get it. The teams are asked to change how they work but the demands coming from stakeholders and executives continue to demand fixed time and scope commitments. The vocabulary changes but the language stays the same. 

In an earlier post on the blog I discussed the concept of Jobs to Be Done and how it integrates with Objectives and Key Results (OKRs). The idea behind JTBD is that a person is “hiring” something (tool, product, service, process, etc) to achieve some kind of goal — to do a job for them. We often focus this way of thinking on products and services but the same concept can be used to create an objective conversation in your company about why you’re changing your ways of working and how you’ll know it’s having the desired effect. 

Why did we bring in Agile in the first place? What problem were we trying to solve?

To get started we focus on the problem being solved and ask, “Why did we bring in Agile in the first place? What problem were we trying to solve?” Asking your executives these questions can kick off a conversation about what challenges they see in the organization. While oftentimes you’ll hear concerns with “time to market” and “efficiency” it’s worth discussing this specifically with your stakeholders to ensure you’re not missing any other “jobs” they’re trying to get “done” with Agile. 

If you can get this far you’re about halfway to building up an objective review of your agile transformation and where it could use improvement. You now have the job to be done — why the company decided to change their ways of working in the first place. Next, you can move on to defining success. 

The key question here for your leadership team is, “If our agile implementation is successful, what will our people be doing differently?” In other words, how will the staff’s behavior change if we become more “efficient” and reduce “time to market?” The goal is to get specific with the success criteria and to ensure that each answer to this question is a measure of someone’s behavior in the organization — including the leadership team. 

If the early answers to “what will people be doing differently?” start with “they’ll be more efficient” or “they’ll reduce time to market” push to uncover the actual day-to-day behaviors that predict greater efficiency. For example you can ask a clarifying question like, “What does a more efficient team do that our teams aren’t doing today?” or “If we reduce time to market what does that give us time to do more of?” 

The answers to these questions are your key results. They’re your outcomes. They’re your measures of success. One thing to watch out for is answers that describe the behavior of the teams only. If that starts to happen, broaden the discussion to understand what executive teams would be doing differently in this future, successful world. Ask, “How does your work help implement these desired behavior changes?”

If you’re successful in having this conversation with your leaders you create the space for improvement to take place. Strict adherence to Agile recipes starts to diminish in favor of process experiments that reveal better ways to achieve your desired outcomes. As with the implementation of any process, the success lies in the adoption and application of that process to make teams, companies and customers more successful. If that’s not happening then the implementation of that process — agile or otherwise — failed. The faster we can bring our leaders to the table to understand what jobs they’re trying to get done and create an objective list of behavior changes that tell us we’re headed in the right direction the faster we can build greater alignment and transparency throughout our organization.