I think a lot of us dealing with Agile software development frameworks and practices on a regular basis have a good understanding of what it means to be “Agile” at that level. On the other end of the spectrum, there is “Business Agility” and that term is more amorphous and less understood. Below is my summary of what I believe the goal of Business Agility is as well as characteristics of organizations embodying Business Agility. Some of the definitions “out there” tend to be more lengthy, so I’m trying to keep it very succinct.
Business Agility aims to enable an organization to …
Respond quickly to emerging market needs and opportunities
Make critical decisions quickly
Reduce risk by testing hypotheses quickly, succeeding or failing fast
Innovate aggressively and often
Learn and evolve quickly based on short, frequent feedback loops
In my research, the following characteristics appear to occur most commonly in the context of Business Agility:
Focus on the customer
Self organization within small, cross-functional teams (development teams and beyond)
Decentralization of decision making
Adaptive and flexible
Experimentation and iteration on ideas (e.g. Lean StartUp approach)
Small batches and short planning horizons
Reduction of complexities and dependencies in favor of smaller, de-coupled autonomous units and architecture
Comfortable with risk, uncertainty and not having full, centralized organizational control
Shared purpose, vision, and/or values over detailed “processes”
A number of these characteristics are rooted not in specific practices and techniques, but more in the overall company culture.
The notion of innovation I didn’t find mentioned all that often, but I took the liberty to add it because I think it’s important. Being adaptive and responding quickly to change are great, but they’re purely reactive and “outside in”. The concept of innovation is a proactive, “inside-out” effort, which in the end may be even more valuable in moving an organization and its products forward.
P.S.: After writing this post, a great article on the topic of Organizational Agility was published here.
Agile is pervasive and changes organizations, some more, some less. The same way as there are different levels of Agile planning (daily commitment, sprint, release plan, product roadmap and product vision), there are different levels of optimization an organization can achieve by applying Agile and principles based on the Lean Startup.
When a development team implements an Agile framework such as Scrum, it starts optimizing a number of its practices, which has certain benefits. However, because the focus is only the development team and not the larger organization, the level of optimization achieved is limited. The Agile team is embedded in an organization that doesn’t holistically apply Agile principles, therefore the optimization is limited to the technical team and hopefully the Product Owner, which is the only part of the team intersecting with the non-technical part of the business. While this yields some benefits, they are limited.
When the whole organization “is Agile”, it becomes possible to optimize the entire business, which includes the Development group, the Product organization and even Finance and senior management as well as other related parts of the business. At this level, the whole business is optimized to deliver on business value, the product roadmap and vision. Many organizations stop here, but on 2nd thought, the optimization is often still based on internal assumptions. The organization delivers those projects and features that it thinks will produce the highest business value and deliver the best business results. (The Product organization is pretty certain it knows exactly what features the customer base needs and works with the development organization to ensure those assumed high-value features are delivered first.) These assumptions may or not be correct.
Only once actual results after release to the customers are measured and fully understood can an organization truly optimize real business outcomes and validate the internal assumptions with external results. That’s where applying principles of the Lean Startup are helpful and allow an organization to release an MVP (minimally viable product), gather systematic feedback and then pivot on the information received if necessary. Only once those features hit production can those assumptions be given the litmus test of real customers and revenue plans be turned into actual dollars.
The bottom line is this: We obviously don’t want to practice Agile just at the team level. Many companies have understood that and strive to transform themselves to Agile organizations in a more holistic manner. While this is great, the true optimization of actual business results comes from optimizing for actual, validated customer outcomes and market adoption. Product life cycle approaches such as the Lean Startup are therefore complementary to Agile and needed to achieve the best possible business results.