Many companies today operate in an ever-changing and highly-competitive environment. To keep their competitive edge and achieve a sustainable growth pace, this requires them to be more adaptive and resilient than before.
As modern management theory says, the most adaptive and resilient companies are powered by engaged and innovative individuals who self-organize in agile teams that deliver against an aligned vision, mission, and goals. Leadership teams play a critical role in making that happen.
What is agile leadership?
Agile leadership is a new leadership style that comes as an alternative to the past’s top-down management styles. Agile leaders create a safe-to-fail environment that fosters a culture of transparency, inspection, and adaptation. They allow the agile teams within their organizations to continuously experiment and learn, achieving organizational agility and business growth.
An agile leader is, in a way, like a farmer. A good farmer doesn’t manipulate the crops by hand every day. Nor does he keep measuring their growth and challenging them to grow faster. Instead, he fosters an environment that allows the crops to grow naturally—even if the weather and the storms it brings are generally unpredictable. The farmer is accountable for the atmosphere he creates. The crops own and deliver their growth.
How to Become an Agile Leader
To become an agile leader, you need to think and act in an agile way. In general, there are three steps to becoming an agile leader:
- Get to know the agile manifesto
- Adopt an agile leadership mindset
- Understand the mechanics of agile
In the rest of this post, we’ll look at each of these three steps in more detail.
Step #1. Get to Know the Agile Manifesto
The first step to adopting an agile mindset is understanding what agile is all about.
Agile began as a movement among software developers in the early 2000s. At the time, software projects were managed using a “waterfall” project management approach.
Waterfall project management is a sequential and linear way of managing projects of all kinds.
Waterfall assumes that 99% of a project’s scope, budget, and timeline can be discovered and planned before the start of a project. Using a waterfall approach, projects are delivered in phases, with each stage being separate from the ones that precede it and handing over deliverables to the ones that succeed it.
Many companies today approach their business, program, and project planning in a waterfall way. They make five-year strategies, plan out their budgets in one-year cycles, and demand a step-by-step plan for every program and project they sponsor.
As the software development community found out, the problem with a waterfall planning approach is that plans change. By the time a one-year project is complete, up to 65% of the initial requirements will no longer be valid. If you discover this only when you complete a project, 65% of your investment is sunk cost.
Waterfall is a useful approach to planning if the environment and outcomes are generally predictable. The problem with software development—and organizational leadership as a whole—is that the environment is volatile, uncertain, complex, and ambiguous (“VUCA”), and the outcome is emergent. When your planning cycle is one to multiple years long, you make mistakes that cost as much as one to multiple year’s effort (and opportunity cost).
In 2001, a group of 17 software development thought leaders went on a ski retreat in the mountain resort of Snowbird, Utah, not far away from Salt Lake City.
As the story goes, they got snowed-in. Since they couldn’t do much skiing, the group’s members got together in a room with a whiteboard—and started exchanging experiences for building better software and working with clients more smartly.
The more they talked, the more similarities they discovered between their ways of working. So they wrote these similarities down on the whiteboard and created the Manifesto for Agile Software Development, the very document that gave the start to the agile movement.
Years before they got together on the ski retreat and created the manifesto, many of the group’s members had done extensive research into the success stories and case studies of lean manufacturing and product development in American and Japanese companies in the 20th century.
The 4 values and 12 principles of the agile manifesto (I’m going to share them with you in less than a minute) are grounded in the values and principles of lean, product development, and customer collaboration from some of the world’s most successful product companies at the time, such as 3M, Hewlett-Packard, Canon, Honda, and others.
The agile manifesto is a 68-word document that outlines the 4 values of agile:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
The Manifesto for Agile Software Development (agilemanifesto.org)
In the days after they wrote the manifesto, the storm passed and the members of the group went on to do other activities—like skiing—that they had come to Snowbird for in the first place.
In the days that followed, they also wrote the 12 principles behind the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The 12 Principles Behind the Agile Manifesto
Agile started as a software development movement. It quickly spread among fast-growing startups and large corporations as the de-facto way to build high-value software products.
In the 20 years since its creation, agile grew out of the IT function and has turned into the modern way to lead others and do work. As I wrote in “Is Agile a Framework or Methodology?”, agile is a mindset that anyone can use to achieve more outstanding outcomes in any line of work, on any level, and in any sector or geography.
Step #2. Adopt an Agile Leadership Mindset
An agile leadership mindset is about acknowledging that plans are only plans—and that circumstances change along the way.
It’s also about understanding that the most valuable products and the best solutions to problems come from capable and engaged individuals working in self-organized teams.
To tell if a plan is going to work or not, try to make it happen. The agile mindset is based on empirical thinking. Empiricism is a philosophical school of thought according to which the only way to obtain knowledge is through practical experience.
People who work in an agile way don’t make plans for how things will turn out. They make hypotheses that something (i.e., initiative, program, project, product, service, feature, enhancement) will create customer value or deliver an organizational outcome.
The agile practitioner then sets out to prove that hypothesis right or wrong. They do so by working in short cycles (a.k.a. in an iterative way) and shipping in small chunks (i.e., building products or services incrementally).
To make better plans, shorten the feedback loop and maximize learning. When an organization and its network of agile teams work in short cycles and ship working products or services in small chunks, they can shorten the feedback loop and adapt faster.
This is one of the most significant differences between a waterfall and an agile approach to organizational leadership and program/project management. In waterfall, you make a grand plan—and you only find out if it worked or not when you’re done executing on it. In agile, you make nimble plans in short cycles—and use customer feedback or insights through analytics to continuously course-correct along the way.
Waterfall is more like a map. If you know your environment and are confident that it will not change, a waterfall approach will get you to your desired outcomes. If you’re exploring uncharted territory or one with many unforeseen obstacles along the way, you need a compass. A compass will give you just enough information to help you stay on course without fooling you with details that are no longer relevant. Agile is that compass.
Empowered individuals and self-organized teams deliver the best outcomes. Agile requires leaders to acknowledge a fundamental truth about organizational leadership: that in 99.9% of the cases, their people know what to do (and how to do it) better than them.
In an agile context, top-down management and command-control governance no longer apply. The top-down, command-control notion of leadership implies that one person (or a governing body of a few seniors) knows better than the hundreds, thousands, and sometimes tens of thousands of employees in their organization.
Leaders in agile organizations play a different role. They remain accountable for setting the vision, mission, and goals in a compelling, actionable, and relevant way to the organization’s aspirations.
However, instead of exercising control over the delivery process, their new challenge is to:
- Become better at setting the vision, mission, and goals for the organization and its units;
- Sharpen their capital allocation skills to determine which programs, projects, products, and services to sponsor;
- Focus on making decisions and trade-offs and removing organizational roadblocks for their teams faster as they become servant-leaders.
Simply said, to become an agile leader, learn how to set the “Why” for your organization, empower the teams and individuals within it, and exercise subtle organizational control without interfering with the “What” and “How” that they are working on.
Adopt a long-term view and strive to build a sustainable pace. Agile is about working in short cycles and shipping in small chunks. Unfortunately, this iterative and incremental way of work is often used as an excuse for short-termism.
It’s not uncommon to see agile leaders taking the fundamental concepts of agile and bending them as an excuse to push employees to work after-hours on ever-changing plans because “agile is about responding to change.” In reality, they lack the skills and know-how for how to use agile to create a sustainable pace.
An agile leader steers the entire organization toward making better decisions before the start of each cycle and maximizing the delivery of value and lessons learned throughout the execution of each cycle. High-performing agile leaders understand that the most effective way to manage change and disruption is by creating a sustainable pace of adaptation and delivery through cadence and self-organization.
As your organization adopts agile, it will gradually create a unique rhythm by establishing cyclicity and pace. Understand that your number one goal as an agile leader is to make that pace sustainable and work with everyone across the organization to eliminate the glitches.
Step #3. Understand the Mechanics of Agile
Agile is an empirical process control system. And empirical process control systems are best applied in circumstances and situations where the outcome is, to no small extent, not known and hard to determine.
In Scrum’s early days, the most popular agile framework, the framework’s founders Ken Schwaber and Jeff Sutherland collaborated with process control scientists at DuPont.
DuPont is one of the leading chemical companies in the world. In the 20th century, the company experienced a series of disasters in various plants. After the Bhopal disaster, a gas leak that exposed 500,000 residents of an Indian city to methyl isocyanate gas, DuPont hired some of the world’s best process control scientists to prevent issues of this magnitude and impact from happening again.
The more Schwaber and Sutherland learned about how DuPont solved the systematic problems in its plants and production process, the more similarities they found with common problems in software development that they were trying to resolve by creating the Scrum framework.
DuPont’s scientists explored the company’s problem through the lens of industrial process control theory. According to industrial process control theory, there were generally two types of processes: predictive processes and empirical processes.
- Predictive processes were complicated but predictable; they could be run like an assembly line. Every step of the process had a highly predictable outcome with little deviation. Predictive processes could be run with a predictive control system where every step, inputs, and outputs could be planned in a linear and sequential way.
- Empirical processes were complex and unpredictable; they required an emergent approach. These processes, like mixing chemicals in a vat and exposing them to high temperatures to trigger chemical reactions, these processes required close monitoring and continuous adjustment. Empiric processes had less predictable outcomes with high deviation. They required a different, empirical control system.
“In every case of an exploding chemical plant,” Scrum co-founder and Agile Manifesto co-signer Jeff Sutherland recalls in a talk on the topic, the process control scientists had found “that somebody had applied a predictive control system to an empirical process.”
From the lens of industrial process control theory, software development is an empirical process. Since the number of external factors and internal variables is so high on most software development projects, the outcome is practically impossible to predict.
This is why software development—like any other complex initiative, program, project, product, or service—requires an empirical process control system that allows you to determine “what to do next” as you learn “what the situation right now is.”
Or, as they say in the military, “no battle plan survives contact with the enemy.”
Agile is an organizational leadership and project management approach that gives you a set of mechanics allowing you to exercise empirical process control:
- Focus on value;
- Work in short cycles;
- Ship small chunks of working product in each cycle;
- Seek out feedback early and often; learn as much as you can through analytics;
- Slice down big plans into smaller ones you can deliver in a single cycle;
- Estimate relatively and measure your velocity with it;
- Aim to create a sustainable pace; a rhythm;
- Continuously improve your process;
- Course-correct often.
High-performing agile leaders understand that organizational leadership is a complex challenge with unpredictable outcomes. They prefer empirical process control over predictive process control and create a culture and a system that encourages openness, transparency, inspection, and adaptation at all organizational levels.
The Bottom Line
Agile leadership is as much an art as it is a science.
To become an agile leader, understand that the world—and the environment that your company operates in—is volatile, uncertain, complex, and ambiguous. Not a single person has an answer to all problems, and the only way to tell if most plans are going to work is to try and make them happen.
This is why creating a network of self-organized agile teams that deliver toward a common vision, mission, and goals is critical to any organization’s survival and success. And why capable and engaged individuals are the only kind of employees that can power these teams with the mindset and behaviors to make things happen.
The agile leader leads by example by thinking and acting with an agile mindset. They use the 4 values, 12 principles, and an infinite number of practices in agile to help the organization create a sustainable pace of value creation in an iterative and incremental way. An agile organization runs like clockwork; its individual bits and pieces synchronize to create a unique rhythm of responsiveness to change and creation of value.
