Business agility helps organizations adapt rapidly to unexpected changes. Agile businesses have survived market, supply chain, and regulatory changes, while rigid businesses have gone bankrupt. If you want to know why your business should be agile, and how to get there, you’ve come to the right place.
To succeed with business agility, start with why. Current advocates present conflicting messages because the business agility field is new. If you learn only how to practice agility from existing advocates, but not why agility was created, your practices could be misguided, your advocacy won’t be as convincing. your efforts won’t be as effective, and your investment won’t last as long.
This article shows how clinging to traditional management practices caused huge project (and company failures) in the mid-1900s. Emerging agile practices helped manufacturing, consumer products, government, and software businesses succeed. Armed with a clear definition of business agility, you can make smart decisions, guide your company’s agile efforts, and ride change like a pro (including in your personal life).
Why Business Agility Improves Success
Business success factors have been changing radically since the dawn of the information age. The industrial age, starting in the mid-1700s, rewarded predictability, but the present information age, starting in the mid-1900s, rewards learning and creativity. Change now dominates most businesses, even in fields considered stable and slow-moving. Businesses that that rely on detailed, long-term plans now growingly produce failure.
Intuition tells us to “get our ducks in a row” before proceeding on a large project, but industrial-age ducks are sunk costs with risky assumptions. A lot of work goes into a preparing detailed plans, approving budgets, locking down contracts, acquiring equipment and facilities, hiring employees, building and testing components, then assembling, testing, and delivering the final product. What if the project doesn’t satisfy user, buyer, or organization needs? Careful planning often creates over-confidence and hubris. Market assumptions, competitors, customer preferences, and supply chain availability can change fast in the information age.
Business agility is continuous, directed experimentation, throughout the life of your business and its projects. Getting your information age ducks in a row requires building skills, policies, and organizations that can identify important assumptions, rapidly test them, learn and navigate change. It requires systemic cultural and operational transformation from traditional industrial-age management styles.
Business Agility Examples
Even businesses serving seemingly predictable markets can be surprised when their markets “suddenly” change. The damage wrought by inattention, inflexibility, and long-term planning can lead to bankruptcy, as demonstrated by traditionally-managed roadkill.
General Motors, the world’s largest automobile manufacturer, maintained fixed relationships and costs in worker pensions and dealer contracts, while Ford anticipated market change, restructured its organization and finances [Berman 2009]. GM went bankrupt in 2009, during the Great Recession, Ford Motor Company did not.
Kodak, chemical photography manufacturer, invented digital photography, but failed to experiment with and learn from its new market. It produced prohibitively expensive and unwanted products, while relying on its legacy markets for revenue and profitability. Meanwhile, adjacent competitors created online services and camera phones [Anthony 2016]. Kodak declared bankruptcy in 2012.
How Agile Arose
Project disasters in the software industry drove the development and understanding of agile practices. Software has rapidly evolving markets, freewheeling creativity, uncertain opportunities, and expensive developers. In the days before agile, IT projects frequently produced breathtaking failures, including $560M lost by the Denver International Airport, $400M lost by Ford, $445M lost by CIGNA, $2.6B lost by FAA, and $600M lost by London Stock Exchange [Charette 2005].
Traditional managers, using their gut intuition, would demand detailed plans and delivery deadlines from software developers. Software developers would then experience “death marches,” knowing that a project would likely fail, but be forced by managers to work overtime. Cost overruns followed by abject failure caused many business leaders to reexamine their assumptions. Thought leaders started thinking about how they could reduce these failures.
What is Agile?
An agile business rejects the traditional “mega project” of well-planned logical steps that lead to customer delivery.Instead, an agile business restructures a mega-project into a sequence of short sub-projects. Each sub-project ships an incrementally growing set of features to end-customers for their feedback. Such sub-projects may not pay for themselves, but when customers pay even a little for them, we have a “signal” they might pay more for additional features, and a direction based on the features they like. These sub-projects are called “sprints.” In software development, they typically last one to four weeks. At SAAB Aeronautics, which develops the Grippen Fighter Jet, sprints last 3 weeks [Rigby 2020].
An agile business limits commitments to subsequent sprints until the current one completes. This allows the organization to adapt those later sprints to discoveries about development challenges, market feedback, and other news. In other words, Agile philosophy expects changes.
What are the tradeoffs?
Agile philosophy provides rapid learning and adaptation at the cost of repetition. Learning in agile happens far more rapidly than traditional management: by delivering a sub-project all the way to a customer in a short time, you learn the challenges in requirements gathering, procurement, development, manufacturing, testing, marketing, supply chain, delivery, and feedback.
The agile cost is repeating these tasks in every sprint. When you perform these activities in a traditional project, you do them once, theoretically, in the whole release process. You don’t learn much with traditional management, but assuming you have conquered all the challenges and eliminated risk, traditional management could be more efficient—if you get everything right. Relying on assumptions, however, could spell disaster in our fast-moving world, so the most successful businesses consciously pay some price in repetition to gain some agile advantages.
How can business agility be achieved?
To reduce the cost of repetition, agile software businesses have developed sophisticated automation systems, e.g., continuous-integration continuous-deployment (CICD). They create organizational skills and structures to reduce communication and handoff costs, e.g. work teams that take responsibility for development, documentation, testing, and deployment (DevOps). They mitigate risk by establishing rapid “rollback” capability.
These new systems and structures arose from an agile forcing function. Agile leaders explain “why” the organization must release faster, and then demand that it develop the necessary systems, skills, and structures to do it.
Case study: Manufacturing
Agile manufacturing actually emerged before agile software development, with Toyota’s “Lean Manufacturing” (originally called Toyota Production System). Toyota’s forcing function was waiting until a customer ordered a car before assembly. Toyota had to abandon assembly lines, escalate quality issues more rapidly than its competitors, unify its workforce around a driving purpose, and train its suppliers to deliver just-in-time.
Interestingly, in 1984 GM partnered with Toyota to create their shared NUMMI plant. Toyota taught GM its lean manufacturing system. Cars manufactured in the NUMMI plant were more reliable than anything GM had ever produced, but GM didn’t understand its deep implications. In those 25 years until its bankruptcy, GM could have spread what it learned to other plants, but never did. This is one more piece of evidence that agile is counterintuitive; those who understand agile can excel while competitors remain confused.
Case study: Rockets
SpaceX is a relatively recent agile manufacturer. Its driving purpose is “to revolutionize space technology, with the ultimate goal of enabling people to live on other planets.” Such a huge purpose demands low-cost space transport, and profit-making along the way. Since its successful orbital launch in 2008, SpaceX has racked up a series of firsts: first Earth landing and reuse of a first-stage rocket, largest satellite constellation operator in the world, longest streak of orbital launches without a failure for a single rocket type (Falcon).
SpaceX performed many (relatively) low-cost learning experiments to achieve its many firsts, and many such experiments “failed.” SpaceX learned while critics ridiculed it. SpaceX as a whole became profitable in 2013. Its Starlink internet service will likely become independently profitable in 2023.
Case study: Warfare and more
Agile warfare, which promotes adaptability through decentralized decision-making and iterative planning, has shown its advantages in the Russo-Ukrainian War, where Ukraine has defended its territory for far longer and with fewer troops than anyone expected. This was thanks, in part, to NATO-sponsored training in Mission Command, Maneuver Warfare, and OODA (Observe, Orient, Decide, Act) loop principles (all components of “Agile Warfare”).
Other organizational types and functions are less mature in their agile journey. Product management has agile “Lean Startup” and “Design Thinking” approaches, which use low-cost experiments to test customer desire, price tolerance, marketing channel impact, and usability. Finance has an agile “Beyond Budgeting” approach, which decentralizes decision-making, budgets adaptively, and promotes transparency. Education has an agile approach called “Design for Understanding,” which measures student knowledge and adapts lesson plans frequently.
Each organization, and even each group in an organization, may need to tackle the challenges of rapid, successive releases in a different way.
Agile Fundamentals
Though the terminology and specifics may differ between organizations, there are fundamentals that are present in every agile entity. Understanding those fundamentals will help you assess any organization, and prescribe improvements that significantly improve results. Senex Rex has defined the fundamentals of agility in its Agile Base Patterns [2018 Greening].
These are the minimum characteristics for an “agile entity,” whether that is an individual, team, or organization [. An agile entity
- aligns its activities around a driving purpose. This requires continuous reinforcement, to avoid distraction and wasted effort. [Align to a Driving Purpose]
- limits work-in-progress, by time-boxing production, by delivering work frequently to beneficiaries, by actively seeking feedback, by focusing its attention to its purpose, and by completing work it has started. [Limit Work in Progress]
- measures progress using leading indicators (because more accurate indicators usually take too long to drive rapid adaptation) [Measure Leading Indicators]
- complete low-cost learning experiments to validate assumptions. Such experiments operate iteratively at different time scales, including work days, sprints (typically a fixed number of weeks), quarters, etc. They can also operate at the individual, team, or organization level (such as with Scrum-at-Scale). Learning experiments, by definition, require a significant probability of failure, so agile organizations must support teams that occasionally fail. [Experiment to Improve]
Additional patterns strengthen agility. Sustainable agility requires collective responsibility, where each participant feels personal responsibility for the organization’s actions and outcomes. In turn, collective responsibility seems to require psychological safety and welcoming low-cost failure in service to learning. And finally, expanding agility requires systems thinking.
Assessment
If you wonder whether your organization is agile, consider the basic four patterns, and ask whether its fundamental policies and practices produce these patterns. If not, the organization is not agile; if so, it is.
Because the term “agile” is trendy, executive job applicants and consultants who don’t understand the fundamentals of agility may claim agile skills. If you understand the agile fundamentals described above, you can test their claimed skills by asking them to describe their previous activities. What practices did they put in place to align their organization around a driving purpose? How did they limit work-in-progress? What leading indicators did they use to anticipate a lagging measure of organizational health, such as quarterly profit? What experiments did they run, and how did they support participants whose experiments failed? Such questions, in my experience, expose agile charlatans quickly.
Transformation
Adopting an agile organizational philosophy demands such dramatic structural changes that we call a transition from traditional to agile management “an agile transformation.” Though most agile transformations show improvements in agility over the short term, creating a sustained agile transformation seems to require transformations throughout the organization, especially at executive management levels. If executives do not have their own frequent iterations on company management, policy, planning, and budget, then departments that locally operate with agility will likely see their advances lost in reorgs or executive turnover.
Summary
My objective was to provide the motivation to pursue business agility (the “why”), and explain agile fundamentals clearly so you can assess any business or person. You’ll likely encounter key moments when understanding these fundamentals will improve your future. Use this guide (and its references) to
- assess the agility of a business you might work for, because you want to benefit from an industry leader or a successful startup, rather than a dud.
- evaluate the knowledge of a consulting company offering to lead an agile transformation in your business, because you want the money you spend to produce lasting improvements.
- test the claims of a potential hire, particularly an executive, because you don’t want to cluelessly hire someone who will impede, damage or destroy your organization’s agility. You especially want this knowledge if you want your new hire to lead an agile transformation.
Good luck in your quest for business agility!
