Staying Agile in Product Development
Why agility is key in product development
I'm driven by the question "how do we do the right thing?" My PhD research was focused on determining the best way to measure the performance of computer systems. Over the next decade, I worked as a professional software engineer. I studied software modeling languages and design patterns to learn the best way to build complex software systems. When I transitioned to IT management, I read extensively about leadership practices and management standards like ITIL, Lean, and Six Sigma. Later, I became an Enterprise Architect where I learned to take the big-picture view of the strategy and operations of an organization.
Throughout my 35+ year career, I've always been curious to learn what best and emerging practices can help me be a better engineer, businessman, or leader. I'm constantly looking at how the best minds are shaping how we work. However, I never take any single idea as dogma. I find the best results are achieved by combining ideas in novel ways to create something that works best for a given situation.
For example, in this article, I’m going to look at how combining agile techniques, OKRs, and ideas from the Cynefin Framework can help an organization improve their success in a rapidly changing environment.
How Agile techniques help adapt to change
We all know that "the only thing constant is change.". However, things don't all change at the same rate. There are some areas of your business where you constantly need to change and adapt to customer interests and market trends. On the other extreme, there are parts of the business that are more stable and dependable.
As an example, let's look at how you build a software application. The individual features of the application might change fairly rapidly based on customer feedback. Your choice of what programming language and libraries to use to build the application will change more slowly. The choice of what operating system is running on your software engineers' computers might change even more slowly.
The techniques you use to execute your strategy and to manage your work will be different depending on how fast your area is changing. The most challenging situation is dealing with an environment that is changing rapidly.
Reacting to Complex situations in product development
When things change quickly, it's usually because there are a lot of things going on. There are many different factors at play that make it difficult to know exactly which decisions to make and how to proceed. This is what the Cynefin framework calls a Complex situation. In Complex situations, it's difficult to determine the relationship between cause and effect. As such, the best thing to do is to experiment. Try different options, and learn from the results.
What does this mean for a product development organization?
Let's look at this top-down. Suppose your business operates in a market that is rapidly changing. It's Complex. There are no clear indicators to tell you how to grow your market share. You can't rely on the old-fashioned annual strategic planning sessions to set the course. Market situations can change in a matter of months. You need to be, dare I say, agile.
Using OKRs for continual strategic planning
Adapting to rapid change requires continual strategic planning. The best way that we know how to do that is through OKRs: Objective and Key Results. The standard recommendation for using OKRs is to set Objectives that are a bit longer term (6-12 months) and define Key Results that you intend to complete quarterly. Instead of the annual strategy review, you get feedback on a quarterly basis as to whether your KRs are making a difference toward achieving your objectives. This gives you the agility to declare progress, stop unproductive work, or make course corrections on a much more frequent basis.
The good thing about OKRs is that they aren't just your average output-based goals. Key Results are about producing positive outcomes with respect to achieving your objectives. For a product development organization, the Objectives are likely to be around attracting new customers, retaining existing customers, and reducing the cost of producing and supporting the product. Therefore, the outcomes produced by your KRs are likely tied to how well the product provides value to your customers or value to your company.
Let's take this down to the next level: How are you building your product? If your potential customer base is changing rapidly, then using Agile techniques is the best way to be able to put a product out in front of your customers and get their feedback. There are lots of ways to get this feedback, such as A/B testing, focus groups, surveys, beta test groups, etc. However, as useful as these techniques are, they don't tell you if you are actually providing value to your customers in a way that supports your company's strategy.
Agile and OKRs drive outcomes
This is where the tie between Agile techniques and OKRs makes for a powerful combination. As I already described, OKRs can be developed to help you identify outcome-based Key Results that align with the strategic Objectives of your company. Understanding these desired outcomes will help you design your customer feedback approach. You can focus on identifying leading indicators that can predict future customer success. It will also be a critical input into how you develop tasks in your agile backlog. Instead of choosing tasks that your “voice of the customer” thinks will be cool, you can be more strategic. At the other end of the agile pipeline, the acceptance criteria for a given sprint won't be "does the code work?" but "does the code create the desired customer value?"
I'll admit, finding ways to measure "creates customer value" is a lot harder than measuring "doesn't crash." But it’s clearly a much better acceptance criterion. I'd rather build something that achieves the former than merely clears the bar of the latter.
There's one more way that Agile development techniques and OKRs are a good fit. Both build on the "agile mindset." That is, they both recognize that achieving the desired end (whether a working product or a strategic objective) requires frequent evaluation of your progress and adjustments to your course. When both product developers and leaders talk the same language, you will create a culture of collaboration instead of one built on an "us and them" mentality.