Are we agile? The highest performing innovators follow 6 progressive agile base patterns. To assess your agility, ask how well you follow those patterns. To stay agile, follow the agile base patterns indefinitely. Audit your business agility with this guide.

People keep asking: Are we agile? or How agile are we? The confusing answers posted to this frequently asked question show we have no good definitions of agile. The Agile Manifesto, perhaps the most recognized definition, covers only software. Other software-specific agile patterns and frameworks claim to define agility. But if we want to live in agile companies and agile economies, we should speak the language of business and commerce, not software. We have nothing.

In this vacuum, breathless advocates make contradictory assertions. Agile is anything from no-rules self-organization to command-and-control [albe2006]. More than one colleague has claimed that Rational Unified Process is agile, an iterative approach that postpones product delivery until after a long sequence of specialized activities. Is it any wonder that some business leaders assert Agile is a religion, some have suggested I stop using the term agile because the term is derided, and some people consider agile development to be nonsense [adam2015]?

But accepted agile methodologies have a practical goal. Agile methodologies seek to rapidly sense environmental change, rapidly adapt to change, and rapidly create solutions. Agile methodologies surf chaos, to gain competitive advantage. We grudgingly pay for rapid adaptation and evolution—we increase the release rate by 10 times or more, suffer structured meetings and scolding ScrumMasters, automate manual work, renegotiate contract lead times, train our staff, etc.—because chaos is not going away. When we respond better to chaos than competitors, we win.

You can’t responsibly answer, Are we agile? Nobody is agile. But you can answer, How agile are we? We can be more or less agile than we were, more or less agile than someone else.

Jeff Sutherland, the co-inventor of Scrum, challenged me to define agile. One day in Hawaii (the absurdity of pondering process in paradise is not lost on me), Jeff said, “Agile is not well defined, anywhere, so why do you even talk about agile anything? You should be talking about Scrum, which has a definition!” And I laughed. And he laughed. And then I thought, “Really?”

To define “agile”, look at practices agilists talk about. Agilists admire and study Lean Startup, Scrum, XP, Kanban, Lean Manufacturing, Theory of Constraints, Toyota Production System, Getting Things Done, PDCA, OODA, Cost of Delay, Real Options, Pomodoro, etc. They have a lot in common, we just have to look.

Every creative activity benefits from agility. Manufacturing design, general management, finance, marketing, human resources, facilities, business development, venture capital, art, event planning, recruiting and sales all can be, and should be, agile. No agilist thinks agile applies only to software development. In fact, as software agilists make engineering departments more agile, we discover that non-agile departments in the company impede us. But we stick with our myopic software-based agile definitions. And when our non-software colleagues encounter the term “software” in the Agile Manifesto, they conclude that “agile is a software thing.” It’s our own fault people think agile is just for software.

With no general agile guide, I decided to construct one, if only for myself. Over the past months, I have classified every agile pattern into six generative base patterns. I intend to create an agile pattern language. A pattern language is a collection of progressively more specific patterns that generate a system. An agile pattern language is a set of patterns that generates all agile methodologies. The coolest pattern languages, like Christopher Alexander’s book on towns, buildings and construction [alex1977], present a first pattern that could generate a healthy system on its own, but add further patterns to generate it faster, more resiliently, etc.

Here we go…

Agile Base Patterns

Agile entities …

1. establish a driving purpose (i.e., a mission to focus Sprint goals, minimum viable products (MVPs), learning objectives, etc.)
2. measure leading indicators (i.e., velocity, NPS, clicks, happiness, progress metrics aligned with entity’s mission),
   
3. experiment to improve (i.e., retrospective in Scrum, measure-learn in Lean Startup),
4. limit work in progress (i.e., ship every Sprint, follow one piece flow).

Resilient agile entities also …

5. embrace collective responsibility (i.e., Sprint Commitment and Surrogate Product Owner in Scrum, Collective Code Ownership in XP).

Expansive agile entities also …

6. solve systemic problems (i.e., five whys, theory of constraints).

The first four patterns create something I call “fragile agile”. If you establish a driving purpose, measure economic progress, proactively experiment to improve and limit work-in-progress, you can sense, adapt and produce rapidly. But you might not be able to sustain that discipline for long. Routine disturbances fatally misalign your capabilities and market: when an important team member leaves, when a competitor emerges, or when a leader advocates a new mission, you are left with a team that can no longer sense, adapt and produce rapidly.

Adopting the fifth pattern gives us resilient agile. Collective responsibility (or just plain personal responsibility for an agile individual) motivates people to fill in for lost skills, investigate market changes and learn faster. Routine disturbances simply motivate people to learn.

The sixth pattern, solving systemic problems, expands our analysis and solutions beyond our agile entity to the system around us. There are no rigid boundaries between the agile entity and its context, beyond the practical. Yes, we continue taking collective responsibility—it is our job to fix problems apparent in our collective product—but systemic solutions explicitly consider how we might help suppliers, bosses, other departments discover new ways of doing things, for their benefit and ours. Toyota ultimately had to train its suppliers, and even its competitor General Motors, to adopt its agile Toyota Production System, to help it adapt more rapidly to a changing world.

Are these six patterns sufficient to define agile methodologies? I think so. And ask yourself whether non-agile approaches conform to any of these six base patterns. I think not.

How agile are we?

Now that we have defined agile, you can assess how agile you are by answering these questions:

1. Do we have a driving purpose that our current activities serve? Do we have a shared purpose? Does it help focus our work? Do we set challenging goals aligned with our purpose? Does the organization have a program to align our activities with our purpose? For more, see: Agile Base Pattern: Driving Purpose.
2. Do we frequently and easily measure our economic progress? What is our economy? Do we measure progress toward our driving purpose? What metrics provide leading indicators for us? Could we improve our progress metrics for better alignment with the overall organization’s mission and economy? For more detail see: Agile Base Pattern: Measure Economic Progress.
3. Do we proactively experiment to improve? Are we actively comparing our hypothesized economic progress metrics with the actual outcome in our experiments (aka iterations, sprints or SDLC)? When we change our process (WIP limits, Sprint length, Done criteria, Ready criteria, methodology, etc.) do we base our decision to change on something we can measure, do we hypothesize an improvement, and do we test our hypothesis? Do we mutually agree and adhere to our process so we have a controlled experiment? For more detail see: Agile Base Pattern: Proactively Experiment to Improve.
4. Do we limit work in process? How much work have we done that is currently unreleased? How long are our Sprints? What about our planning efforts? Do we have a lot of work invested in planning, estimation, design? Could we get the same benefits with less overall waste by iteratively building, planning, estimating and designing? For more detail see: Agile Base Pattern: Limit Work in Process.
5. Do we embrace collective responsibility? How many people on our team felt personally responsible for a recent problem in the collective team outcome, and changed their behavior to help prevent that problem in the future? Do we help each other excel?
   When you’re looking for it, it can be obvious when employees and leaders don’t embrace collective responsibility: Do we deny problems exist? Do we rapidly blame others for problems? (If good people mysteriously disappear from your organization, it probably has this problem.) Do we blame organizational policies or hierarchies for our problems? Do we feel guilty (blaming our immutable characteristics)? Do we shamble into work, like zombies, because it pays the bills? For more detail see: Agile Base Pattern: Embrace Collective Responsibility.
6. Do we solve systemic problems? When we last had a problem, was the discussion limited to obvious causes, or did we dig deep to find systemic causes, come up with more permanent solutions, and advocate for those solutions, possibly outside the team? Does the organization seriously encourage these deep explorations, and reward people who lead them? For more detail see: Agile Base Pattern: Collaborate to Fix Systemic Problems

By answering these questions, you answer How agile are we? Don’t just leave it at that, ask your peers these same questions. What about your executive suite? How agile are they? What are the simplest, least politically dangerous actions they can take to add agility to the company?

The point, of course, is that these questions can not only assess your agility; they provide guidance to improve. That’s what you were really asking when you said, “Are we agile?”, right?

Good luck!

p.s. I intend to base a larger body of work, specifically an agile pattern language on these generative agile base patterns. I need your feedback to help improve and promote them. Whether I irritate or inspire, bore or enlighten, please comment or tweet (with @greening or #agility) or call me up and yell.

References

[albe2006] David S. Alberts and Richard E. Hayes, Understanding Command and Control, Command and Control Research Program (CCRP), 2006 http://dodccrp.org/files/Alberts_UC2.pdf.

[alex1977] Christopher Alexander, Murray Silverstein and Sara Ishikawa, A Pattern Language: Towns, Buildings, Construction, Oxford University Press (1977).

[adam2015] Jasmine Adamson, “Why do some developers at strong companies like Google consider Agile development to be nonsense?” Quora (25 March 2015), https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense (> 2000 up votes).

Related Work

The six Agile Base Patterns are described in detail at Senex Rex. See Driving Purpose, Measure Economic Progress, Proactively Experiment to Improve, Limit Work in Process, Embrace Collective Responsibility and Collaborate to Solve Systemic Problems. Subsequent posts will explore patterns beyond these basics. Subscribe below to be notified when new posts go live.

---

Senex Rex tackles challenging problems at the agile management frontier. We help companies, teams and leaders accelerate and sustain value and quality production, so we can all live better lives. Contact us for help with agile transformation, turnaround management or performance improvement.