Adrian Lander - Agile 2

Dr. Rik Farenhorst

Senior IT Exec | Trainer | Coach | Speaker | Writer on Creating High-Performance Digital Organizations | Co-founder of DevOps Agile Skills Association (DASA)

Utrecht, The Netherlands

December 2020

Afew people who have become aware of Agile 2 have dismissed it as “more of that Agile stuff,” not realizing that Agile 2 is a departure from the original Agile in attitude, approach, and substance. One of those individuals—a chemical engineer—said that he had discussed Agile at length with an Agile advocate, but still concluded that Agile is not for him. Another—an experienced systems engineer who has testified before Congress regarding aircraft and spacecraft systems reliability—also believes that Agile methods do not provide a robust process for trustworthy systems.

We view ourselves as Agilists, and yet we find widespread doubt about the efficacy and usefulness of Agile in many quarters. One of these is among engineers. These people are not ignorant. They know their job extremely well, yet Agile, as described to them, or as they have experienced it, has not resonated or has not answered critical questions.

The Agile movement also uprooted the product design community to some degree (which we will document in this book), although this is an area in which the Agile community has realized the issue and some are trying to rectify it.

Agile authors largely ignored the role of data: something that is so immensely important, that it is akin to speaking about mountains but missing a vast canyon immediately beside you.

The Agile community also sidestepped the issue of leadership — something that the DevOps community has tried to address. Leadership is so important for any endeavor, that to omit it is, frankly, quite equivocal.

Agile has not resonated among the growing DevOps community. Even though DevOps ideas were developed by people who strongly identified as Agilists, the Agile community at large has remained mostly ignorant of DevOps, which had the effect that DevOps became its own movement. As a result, most Agile coaches today know little about DevOps, and we find that DevOps practitioners often view Agile as superfluous.

You might think that mainstream programmers accept Agile, since they are the ones who use it most directly, but in actuality, there is a lot of doubt about Agile within programming communities in general. That is the biggest irony of all: that Agile, which was created for programmers, has in effect been taken away from them, and no longer serves them.

Agile is mostly accepted within Agile communities—comprised of Agile coaches, and managers who have been persuaded of the benefits of Agile. Programmers tend to have mixed feelings about Agile. (We will support that assertion in this book.)

Was Agile described poorly? Is Agile missing things? Did it get some things wrong? Does Agile truly not apply to the needs of the work of any of these people? Since Agile ideas can be applied to most things (in our opinion), we believe that the last explanation is not likely to be the true one.

What we have observed ourselves is that too often, Agilists explain and advocate Agile ideas and methods before asking enough questions. Some of us have seen Agile coaches fired for coming into a setting and insisting on particular practices before actually understanding how the work in that setting is done—a hypocrisy given that Agile coaches so often explain that Agile transformation is a learning journey.

To understand how to apply Agile ideas, one must first understand that domain, how the work is currently done, and why it is done that way. No Agile practice is universal. One size does not fit all, so prescribing before understanding is potentially destructive.

Indeed, the “dogma” of the Agile community helped to launch it, but it has also been its chief failing. Early proponents of Agile insisted that the Agile movement needed to be disruptive—a “call to arms”—and so dogma was called for; but dogmatic insistence also alienates and causes dysfunction when it is not the best advice for the situation.

Agile 2 is not dogmatic. It is not designed to stir up emotion. It is not a call to arms or an attempt to disrupt what we have. As such, it does not try to be disruptive. It does not replace Agile or replace DevOps or replace anything. Agile 2 pivots Agile in some important ways and attempts to fine-tune it. Agile 2 also adds many extremely crucial ideas that have been ignored by much of the Agile community, even though successful Agile practitioners often use those very ideas, and other communities of thought embrace those ideas.

Agile 2 reinforces some DevOps ideas, and some Lean ideas, but Agile 2 does not attempt to duplicate or replace those, and so those sets of ideas are still important in their own right. Agile 2 does not attempt to subsume any existing community of thought. Agile 2 also does not claim to cover all aspects of these topics. Agile 2 claims to only be a set of useful ideas for how to achieve agility in human endeavors and encourages people to include other ideas and fields of thought as well.

Agile 2 is more verbose than the Agile Manifesto. The reason is that we feel that one of the weaknesses of the manifesto was that it over-simplified complex issues. A simple value maxim cannot describe important trade-offs, and one or two principles cannot address nuanced issues such as what good leadership looks like and which styles of leadership apply best in a given situation. So Agile 2 gives these important topics the space they deserve, from an agility perspective.

One important way that Agile 2 departs from the Agile Manifesto is that Agile 2 provides the foundation of thought from which it was derived. Rather than make bold statements without substantiating them, Agile 2 provides the “problems” and “insights” that arose in discussions about Agile, in the course of the Agile 2 team's retrospective about the state of Agile. It was these problems and insights that led to the Agile 2 principles.

An Agile 2 principle is not intended to be an absolute. This is because there can be no absolutes when it comes to human behavior. An Agile 2 principle is a proposed rule of thumb: true most of the time, but perhaps not in some circumstances. That is why the underlying assumptions and thoughts—the problems and insights—are important for understanding the intention of each principle, meaning what problem it is trying to solve and how.

Someone posted a comment online about Agile 2, saying that if the original Agile Manifesto authors were not involved in the Agile 2 effort, he would not look at it. We believe that all great ideas build upon what has come before, and that even “original” ideas have deep roots. The term Agile had been used prior to the creation of the Agile Manifesto, and “agile” methods had been used and circulated for years prior to that. Not only do many Agile methods date back decades, but core ideas in Agile 2 such as Socratic leadership date back millennia.

There is also the matter of dysfunction within the Agile community, which we will discuss at length in the book. The dogma that is found in some quarters is one form of dysfunction; another is the separation of the community into tribes, for the various frameworks. We will explain why this has been a problem and how it has “frozen” Agile thinking and stifled its evolution.

Many of the thought leaders in the Agile community have a lot invested in current paradigms and practices, and so change is not in their best interest. For these reasons, we felt that we could not rely on the community to fix these problems. The problems come from the community—not from the whole community, but from some of the most established and entrenched parts of it.