As Agile methodology gains traction year after year, many companies are still finding it difficult to maintain their course and change a tire all while driving the car, too. What I mean by this metaphor is that business agility is an organization’s ability to adapt quickly to market changes—internally and externally—and to respond rapidly with flexibly to customer demands.
If you dig a little deeper, you’ll find news about billions wasted each year on failed Agile IT projects. Also, the VersionOne 12th Annual State of Agile Report (the biggest worldwide) reports that only four percent of agile practices are enabling greater adaptability to market conditions. There are hundreds of books specific to business agility and large, extensive services in many consulting firms.
But why is sustaining agility so hard? And how can it work?
In my 15 year career, I’ve observed and learned how to connect the dots for overall improved agility in product companies, and in the last several years, I’ve worked as a product owner, where I could lead and influence product roadmaps. Now, I’ve decided to shed light on poorly lit product management areas where it’s harder to spot agility pitfalls. Fast delivery of something that completely misses the target is very common, for one.
Based on this experience, I decided to create a three-part blog post to show you how to achieve sustainable product agility in your organization.
Disclaimer: I don’t mention the role of leadership and how leaders can create principles and values to strengthen the culture. Nor do I mention the importance of a coaching mindset and practices for effective enablement. Don’t let this fool you. These are fundamental elements to successful and sustainable agility as well.
Move Confidently Towards a North Star
Frame Your Measurable Outcome
I often witness teams investing time and resources to work quickly towards a finish line. But how can they be sure that they’re delivering the best thing? Depending on the degree of certainty your team has, you should adapt your roadmap accordingly.
It might be better to create shorter roadmaps. That’ll allow you to test assumptions and incorporate learnings—after all, this is what agility means—and create a list of long-term roadmap candidates.
So, focus on a quarterly North Star. Identify the outcome that will impact the business and how to measure it. Print it and make sure the entire team knows. All decisions regarding the problem or solution space should indicate how they expect to move the measurement from X to Y. Getting a baseline is also another challenge but we’ll leave that to another post.
There are small challenges though. Since moving a business number can take more than a quarter, you can build a connected tree of metrics from the North Star to leading metrics, which are input-oriented. North Star metrics tend to be more output-oriented and serve as a proxy number that will indicate if you are on the right track to achieve the major outcome (e.g. feature adoption, customer behavior), and mapping how input- and output-related metrics affect each other will help guide your team.
Having a connected system of metrics based on a North Star has many benefits. Here’s just two. First, it will cut off many conversations forcing the teams to focus on the measurement (less subjective). Secondly, it will significantly narrow down the scope of their mission. And that is the beauty of getting to concrete and meaningful numbers.
Value doesn’t happen when teams ship code, it happens when the shipped code has the intended impact. And to measure that, you need numbers. But if there is no trustworthy number to give guidance, how can teams know if they are on the right path?
Justin Bauer explained it very well on his “Using Data to Set Product Strategy” talk at Productized last year.
Speed up Your Decision Making
Many of us place equal value on almost every decision. Why? We don’t want to be wrong. Ever. But sometimes it’s okay to be wrong, as long as we learn. Deciding fast and learning from being wrong can be more beneficial than to iterate indefinitely for all the context to make an informed decision.
Jezz Bezos states that most decisions should probably be made with somewhere around 70 percent of the information you wish you had. If you wait for 90 percent, in most cases, you’re probably being slow. Plus, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.
Bezos’s “disagree and commit” has also become very popular due to its effectiveness. The meaning of this sentence can save you a lot of time. If you are convinced of a particular direction even though there’s no consensus, it’s helpful to say: “Look, I don’t entirely agree with what you are proposing but I’ll play along.” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
Regardless of the system that works better for you, keep a systematic way to ease and accelerate an alignment on the decision making.
Being wrong is the opposite of failing. It moves an idea forward. And speed matters in business.
– – – – – – – – – – – – –
Stay tuned for the next part where I will discuss the importance of reaching out to real customers and experimenting solutions.