Agile 2. Adrian Lander
Читать онлайн книгу.
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!
1 How Did We Get Here?
At a developer conference in 2015, Dave Thomas, one of the authors of the Agile Manifesto, gave a talk titled “Agile Is Dead.”1 In a 2018 blog post, Ron Jeffries, another Agile Manifesto author, wrote, “Developers should abandon Agile.”2 In a 2019 article in Forbes titled “The End of Agile,” tech author Kurt Cagle wrote, “[Agile] had become a religion.”3 A post about the article4 in the programmer forum Slashdot received more than 200 comments from software developers, asserting things like “Agile does not always scale well” and “The definitions of ‘agile’ allow for cargo cult implementations.”
Agile has been a subject of ridicule since its beginning. In the early days, there were many people who did not understand Agile and spoke from ignorance; what has changed is that today the criticism often comes from people who do understand Agile methods and have decided that those methods are problematic.