Adrian Lander - Agile 2

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.orgdocument 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!

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 article 4 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.

Is Agile actually dead? The statistics say no, 5 yet something is clearly wrong. Agile—which was sold as the solution for software development's ills—has severe problems. What are those problems, how did they happen, and what can be done about them? And is Agile worth saving?

Most of the discussion in this chapter will be about software. That is because Agile began in the software domain. In later chapters, we will broaden the discussion to product development in general, and to other kinds of human endeavor, since many Agile ideas apply to essentially any group effort.

In 1999 a new book called Extreme Programming Explained by Kent Beck sent shock waves through the IT industry. Agile ideas had been circulating and in use prior to this, but Beck's book somehow pierced corporate IT consciousness. It arguably launched the Agile movement, even though the movement was not called “Agile” yet.

The movement's core thesis was that methodical, phase-based projects were too slow and too ineffective for building software—challenging the approach then used by most large organizations and pretty much every government agency.

The book did not launch Extreme Programming, aka XP, which was first defined in 1996, 6 but it was the book that popularized it. Talk about XP could be heard in the halls of every IT shop. It was controversial, but its values strongly resonated: Small teams, working code (rather than documents) as the only real proof of progress, frequent discussions between the customer and the programmers. Out with big, up-front requirements documents that were always incomplete, inconsistent, and incomprehensible; out with big, up-front designs that were usually wrong. Recurring and incremental customer approval instead of contracts that locked everyone in to unvalidated assumptions.

Many of the methods of XP were not new, but they had been outlier methods, and XP put them under a single umbrella. The book strongly asserted that these methods work and are a superior alternative to traditional methods.

It is not that there were no other proposals for how to reshape software development. So-called lightweight methods had been around for a while. Extreme Programming was new in that it threw a grenade into much current thinking by being so radically different and proposing methods that were so extreme —methods such as pair programming (which had been described as early as 1953) 7 and Test-Driven Development (which also had some history prior to XP), which turned many assumptions about programming on their head.

Thus, the movement began as a rejection of the predominant existing paradigms. People knew something was wrong with software development as it was being done. Extreme Programming provided an oppositional alternative. It was not so much that people thought XP was great, but they were sure that current practices were not great. XP received a lot of attention and was a radically different approach. Perhaps the attention was not because XP was so much better or radical, as there had been other ideas circulating such as Rapid Application Development, but perhaps XP got attention mostly because the Internet provided a new medium that made rapid awareness possible.

Then in 2001 a group of IT professionals—all men by the way, with most from the United States and a few from Europe—got together over a weekend and hammered out a set of four “values,” which they believed should be the foundation of a new approach to building software. Kent Beck was among them. You can find these four values at AgileManifesto.org. It was largely a rejection of many approaches that had become commonplace, such as detailed plans, passing information by documents, and big all-at-once deliveries.