For most businesses, Agile transformations have been disappointing, if not disastrous, with 96% failing to generate the capability to adapt to changing market conditions, according to the 2018 State Of Agile survey.
On paper, the signals seem promising: Agile has evolved into a nearly universal framework that can help organizations adapt faster than ever, at every level, to changing market conditions.
Sadly, what most businesses consider agility is the exact opposite. They deploy rulebook methodology, copy-paste hip organizational structures (Spotify Model anyone?), and measure success as implementing all the practices in the playbook. Basically, they’re looking at, “Are we compliant?” and if so, they assume all is well.
Adopting a framework that everybody understands can be positive in providing a shared language, set of practices, and general understanding across the company. But too often, people equate executing the methodologies with being agile.
It’s an output-based approach that runs counter to the principles of agility that should inform which practices you apply to the context and circumstances you’re in.
I’m going to introduce you to a simple model for true business transformation that I call the Agility Flywheel, but first, to show you why I developed this model, let’s take a quick look at where companies are getting stuck.
What Businesses Overlook About Agile
Most businesses hire me because they want to change the way their organization operates. They aspire to develop thriving cultures for people to do the best work of their lives. They envision building great products and exceptional experiences by making evidence-based decisions about what to do and how to do it so they maximize positive impact on customers and the world.
These companies are trying to transform the way they work, but often they have an organizational operating system that’s broken into lots of different components that can’t communicate. Everybody is blaming each other or a given product for failures and undesired results, rather than trying to find a way to get their system to operate effectively.
Some of the key problems facing these organizations include:
- Functional Siloes – Having a divide between their business and technology functions, which leads to communication breakdowns, unaligned expectations, and difficulty treating technology as the strategic capability it is, rather than a cost center to reduce.
- Putting Frameworks Before Fluidity – They argue over the methodologies, how they’re implemented, and who’s right and who’s wrong. True agility comes from understanding how to identify the principles that let the best practices for the context they’re in emerge.
- Focus on Outputs – Measuring success by completing tasks on time and budget, often without knowing if that effort is solving a real problem or if the output is achieving the business outcomes they’re aiming for. (Often the outcomes haven’t even been clarified or communicated through the organization.)
- Lack of Data – They’re missing feedback mechanisms throughout their organizational operating system—especially with customers—to guide their actions based on the real results of their efforts.
- Going Big – They THINK BIG, BET BIG, BUILD BIG, and become TOO BIG TO FAIL, leading to perverse behaviors and perception.
If any of these issues sound familiar, never fear! I’m going to show you how I’ve helped many companies address these kinds of inefficiencies and get on a path to higher performance, innovation, and morale.
Starting to Spin Your Business Agility Flywheel
At a high level, here’s what needs to happen to create the circumstances for agility to thrive.
- Start with improving your technology delivery capability—meaning you can continuously deliver new releases to your customers confidently at a higher cadence.
- Once you’re able to build a product right, the next question to emerge is “Are we building the right products?” A proven delivery capability starts to highlight that what you’re building may be the problem, not how you are delivering—product management and discovery is questioned more.
- Gathering data and measuring outcomes leads to people starting to ask should you build what you’re building? Is it the right product or formulation, as you start to analyze your results.
- As you master discovering, building, testing, and iterating a product to make it world-class, start applying the same principles across your portfolio of products and scale out your stories of success.
So how can you bring these principles into your organization in a way that makes sense for your situation? That’s where the Business Agility Flywheel comes in. It starts on a small scale and grows into a self-reinforcing system for rapid experimentation and learning for effective product development and portfolio management.
What Is The Business Agility Flywheel?
The essence of the Business Agility Flywheel is working in small batches, and adapting your approach based on customer usage and tight feedback loops throughout the organizational operating system. It has 3 main components:
1. Product Discovery and Continuous Delivery
When you decide to build a new product, what’s the processes you use to build it? This is where Agile came from—evolved and inspired the DevOps movement—and it’s still the best place to start. It’s all about building the capability to release software when you want to. The smaller the changes, the faster and more frequent you can iterate.
I still remember in 2010, following the release of Continuous Delivery by two of my colleagues at ThoughtWorks, David Farley, and Jez Humble (one of my co-authors for Lean Enterprise), the shocked faces we would get when we said teams should be deploying software hundreds of times a day.
People thought we were mad. “We release once every six months. How do you expect us to do all the work multiple times a day?” The answer is to unlearn the practices that made you successful to date and adopt new practices, such as automation and shipping smaller batches of changes to get the breakthrough you need.
Today, if you’re not deploying software multiple times a day, you’re considered mad.
Continuous Delivery paired with Product Discovery enables new ideas and learning cheaply, quickly, and safely (e.g. with a group of beta users) so you can course-correct at every step along the way.
2. Organizational Architecture
How you design your organizational operating systems includes the way you work, how you measure success, and how you structure and incentivize your teams. Key questions to assess and transform your structure could include:
- How easy is it for someone to identify an opportunity and pursue it?
- How do we organize our teams to own problems, connect with customers, experiment, learn, and adapt to achieve their desired outcomes?
- How do we measure success? Is it “on time, on budget, on scope?” How could we focus more on outcomes rather than outputs? (E.g improving customer retention by 20% in the next 12 weeks)
- How can we better reward and recognize people for their effort? Do we ask people to be team players, yet pay individually for performance? Do we focus on the impact of teams, and how they’re living the values, behaviors, and principles we believe enable the thriving culture we wish to create?
- How can we get better at adapting and optimizing our ways of working for our context (putting principles over practices)?
Conway’s law (named after computer programmer Melvin Conway) states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
What feedback loops do you have in place to let you know if your current organizational architecture is performing as desired? How do you know if you’re unSAFe, Spotify, or Squad model is working? What characteristics have you defined for success?
If you don’t manage your organizational design, it will end up constraining the company you wish to create. Good design evolves over time to meet the changing circumstances and challenges the business faces in pursuit of the company mission you’ve defined.
3. Business Model and Innovation Portfolio Management
How do you assess and adapt your business model and strategy to decide which bets to invest in?
Business agility is about how you identify and fund innovation ideas, and decide what to stop, start, and continue based on what you learn from the bets you make.
As you start to iterate your products faster and scale across your portfolio, you start to bump up against larger legacy processes and practices. Slow moving, big batch work activities such as annual budgeting, planning, and performance reviews become bloated blockers—an issue now visible due to a fast cadence and results of continuous delivery .
Waiting for a once-a-year decision point, and investing in business cases packed with untested assumptions and wide predictions makes no sense. You don’t want to wait once a year to place a few big bets – you want to make hundreds of small bets every month.
Working in smaller funding cycles, rather than annual or biannual, allows for safer-to-fail investments and a higher chance of success since you can then make more informed decisions at a higher frequency.
Having a balanced portfolio between products to Explore, Exploit, Sustain, and Retire also protects you from taking on too much water from any particular failure.
For most companies, a 10-20-60-10 ratio works well, but there are always outliers. Netflix, for example, invests about 90% of their funding in the Explore category. This works because they must continually be investing in new content to retain customers and resilient hosting technology systems to support an ever-scaling market size. Their business model is based on innovation, so their investment strategy must match their business model for the company to succeed.
What’s your ratio of investment in Explore, Exploit, Sustain, and Retire in your business? What should it be to align with your business model?
These three components cover all the critical areas of your agility program, and they should all support each other.
Now you might be wondering how you could create this framework in your large, complex organization, replete with existing structures, systems, and processes. So let’s look at how to plant the seeds for new, Agile growth.
How To Build Your Agility Flywheel: Think Big, Start Small, Learn Fast.
This might sound like a huge undertaking that could disrupt everything. And you’re right, if you try to do it all at once. So don’t.
Start small, and focus on the technology department, because they’re the builders. Design the beginnings of the organizational architecture you want to grow into and set up a few customer-facing product teams where uncertainty is high.
Adopt Product Discovery and Continuous Delivery practices, with good analytics to understand what you are building and how customers are using it in real time—what outcomes over output are being achieved? This quickly makes visible when the product is not actually achieving the outcomes people want.
As these teams start to operate differently, they’ll bump up against inefficiencies not only in the way the technology teams work, but in the business teams. And if these inefficiencies are opportunities to be addressed with new practices adapted to suit the context the teams are operating within, they’ll start to surface the organizational processes that no longer make sense.
The organization will have to change as a whole, but it will stem from the needs of the technology teams as they start implementing changes faster, and more frequently as they figure out where they’re being held up.
I won’t sugarcoat this – it’s hard to get the momentum going. But once you start to get one system spinning, you create a virtuous cycle. You build momentum by doing lots of small things more frequently. And that creates a cadence.
The speed of the smaller subsystems flying around in the middle of the organization can make it very clear where the larger systems need to adapt toward smaller and faster processes.
Once you’ve optimized your system for your test products, start applying the changes to your other products and scale out throughout your organization.
What most businesses consider agility is the exact opposite. They deploy rulebook methodology, copy-paste hip organizational structures (Spotify Model anyone?), and measure success as implementing all the practices in the playbook
Support For Your Innovation Efforts
One way you can start small is by reading Unlearn or Lean Enterprise, or listening to the Unlearn podcast (be sure to subscribe!).
For more in-depth training and inspiration, you can attend one of my events http://bit.ly/barryoreilly-next-events.
Building Agility Flywheels within large companies is my specialty, so if you have any questions about applying this process in your organization, shoot me an email. I always respond personally.