Читать книгу Agile 2 - Adrian Lander - Страница 9

A few 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.

Why bother then? Why deal with this? It's because Agile is extremely important. DevOps cannot replace Agile. While Agile has become mostly about the human side of building things, DevOps has become mostly a collection of technical practices. That is the reality on the ground. But there is more to building things than the technical side: one needs both the human side and the technical side.

We therefore realized that addressing Agile's gaps is really important, and that to do it, we needed a diverse team with a wide range of skills, composed of people who are not deeply invested in current paradigms or frameworks. We needed original thinkers. Those criteria led to the Agile 2 team of 15 members, which you can find on the Agile 2 website.

Agile 2 is an attempt to make a solid course correction to Agile, but in an open, additive, inclusive, and nondogmatic or emotional way. We welcome ideas that can supplement Agile 2 and feedback on its principles, in the spirit of inclusiveness and advancing everyone's understanding of these complex issues.

Agile 2 broadens Agile's focus beyond software. The reality is that Agile ideas have been applied for many things besides software, and so the Agile 2 team felt that it made no sense to define Agile 2 only for software.

The reader will notice that many Agile 2 principles are stated in the margin, but not all of them. This book is not a textbook about Agile 2 that covers every aspect of its principles. The purpose of this book is to introduce Agile 2, explain why we need it, and give an overview. You can find more information about Agile 2 on the website: https://agile2.net, which is published under a Creative Commons Attribution license, “CC BY 4.0.”

This book attempts to make the many topics of Agile 2 concrete. We give guidance on how to apply the principles and provide examples. However, we refrain from providing specific steps or templates to follow: we do not want to repeat the mistake of current Agile frameworks in that regard.

Except for our examples, we do not define practices to implement. Practices are important, but that is for another book and for others to propose. This book lays out a conceptual foundation, while using concrete situations as examples, but not for prescription.

A note about the use of the words “agile” and “Agile”: This book uses the word “Agile” when referring to the ideas embraced by the “Agile community,” which is comprised of Agile coaches and others who view the agilemanifesto.org document as a guiding source of insight; or in the context of so-called “Agile frameworks” which claim to define practices that are consistent with the philosophies of the Agile community. We use the word “agile” when we intend to convey the generic quality of agility. Agile with a capital “A” and agile with a small “a” are two different words.

The name “Agile 2” is not intended to be a version number, as in “2.0,” “2.1,” etc. Rather, it is the name of a reborn Agile. We feel that the principles of agility are timeless, so we do not expect an Agile 3, and so on. Rather, we see Agile 2 as an attempt to reimagine Agile—not from scratch, but by taking Agile ideas and pivoting. We hope that Agile 2 hits closer to the mark!