Agile 2. Adrian Lander
Читать онлайн книгу.
recognize a great book by its ability to make obvious what is wrong with existing worldviews and to add new insights or nuances to change or improve this worldview. I believe Agile 2 meets these criteria easily. It is an easy read not only for those new to the subject of agility, but also for die-hard professionals who are looking for something “beyond” the basic Agile concepts that are at times dogmatic and often being misused in practice.
In this era of digital disruption and an ever-growing world full of volatility, uncertainty, complexity, and ambiguity, it becomes increasingly important for organizations to become more agile. The Agile Manifesto, originally intended in 2001 to disrupt traditional, not-too-effective software development practices, has inspired many organizations over the past decades to change their ways of working, affecting both work cultures and structures. Its popularity was boosted by a growing workforce consisting of millennials and Generation-Z professionals who demand more autonomy, ownership, and the opportunity to make meaningful impact. Over the past decade, the “Agile movement” has gained increasing momentum and also moved beyond the realm of IT.
A side effect of its success and growth was that all kinds of Agile frameworks, doctrines, and certifications popped up to standardize and monetize the discipline. The original Agile values and principles, being high-level on purpose, gave ample room for various interpretations of the core paradigms. During my career I have worked with many different Agile coaches and consultants, and I was always surprised by how much discussion and fanatic debates arose among them with regard to how to live certain Agile values or implement specific practices. This tribalism led to confusion among non-Agilists, and this hampers Agile transformations significantly. I thus see a clear need for a comprehensive Agile idea set that is both pragmatic and nuanced by nature. Enter Agile 2.
I was happy to find out quickly that the authors do not claim to have written yet another Agile doctrine or “Bible.” Instead, they have written a pragmatic companion guide that will be useful for managers and specialists alike. It is packed with hands-on tactics and practices that can help leaders and specialists in organizations to grow to a next level of agility, while preventing cargo-cult behavior or avant le lettre implementations that often do more harm than good.
One of my key drivers for cofounding the DevOps Agile Skills Association (DASA) in 2016 was building a comprehensive view on how to create high-performance IT organizations. The popularity of DASA stems largely from the six DevOps and Agile principles that advocate continuous improvement, customer centricity, autonomous multidisciplinary teams, and product thinking. Following these principles often results in a digital and organizational transformation that typically goes far beyond choosing a standard Agile framework or adding some basic Agile rituals to the mix. To transform successfully to high-performance, organizations need a more mature take on and guidance on what it means to really “be Agile” at scale. Providing this guidance is one of this book's core differentiating features.
Over the past decade I learned firsthand as a consultant, trainer, and senior leader the importance of building the right type of leadership in the organization and creating a culture of continuous learning, experimentation, and innovation. What I like about Agile 2 is that both the importance of leadership and learning are advocated strongly. It provides many tangible ideas to reimagine an organization's leadership culture. I wish that I had this book on my nightstand five years ago. It would have helped me greatly in understanding why certain things happened—or did not happen—during the organizational transformations I was leading.
I like the fact that the authors do not intend to reinvent the wheel, but are keen on building on what is already working. Some of the key Agile values and principles are powerful to this day, but application in practice often needs some additional clarity and lots of examples. The authors nicely provide nuance to how to interpret Agile principles and values while referring to many interesting, and more recent, bodies of work. The authors hit the nail with addressing key topics that are haunting many organizations, leaders, and teams, such as how to collaborate, communicate, value both experts and generalists, and commit team capacity. They rightfully argue that how to adopt certain principles or how to interpret certain values depends on your organization's needs and its current level of maturity. Using this book as your Agile guide, you can aim and navigate your transformation in a more tailor-made way, resulting in more business value. I expect this book to be found on many nightstands in the coming years.
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
Preface
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.