Agile 2 NEXT ITERATION OF AGILE The Case for Agile 2 Agile is deeply broken. In the early days of the Agile movement, the movement could claim to be undergoing growing pains. Over time, it was expected to mature, and progress from being a disruptive juvenile to a mature and efficacious adult. Instead, the community split into numerous factions which grew in influence. Some of those were cooperative with the others, while some were (and still are) competitive and exclusionary. Large organizations that tried to use Agile — the word quickly became a noun — often failed. This was no surprise because early Agile was about individual teams, but a large organization is far more complex than a single team. Everyone expected that over time, consensus would emerge for how to use Agile methods at scale, but instead, the community continued to splinter. Today, organizations that want to use Agile methods at scale are stuck choosing one of several competing and divergent approaches. Meanwhile, while there has continued to be a widespread feeling that there are some important ideas in Agile, there started to be grumblings that Agile was failing. In the early days, these grumbles came from those who wanted to preserve the status quo; but today the grumbles increasingly come from people who have experienced Agile — the reality of how Agile is applied today in real settings — and are disappointed. Interestingly, if one polls Agile coaches about the state of Agile, one usually receives celebratory remarks: “It is great! It is improving all the time!” But if one polls programmers - the very constituents whom Agile was designed to help - their remarks are far less sanguine. In fact, programmers’ complaints about Agile, as they have experienced it, are long. Agile evangelists will be quick to respond, “The Agile that those people experienced was not real Agile — they did not do it right.” But if the community has been unable to define what “real” Agile is, after all this time, then isn’t something wrong with the community? Or maybe they have defined it, but ithas not been sold or communicated well; or — just maybe — there is something wrong with Agile, or with the Agile community. tually We believe there is: there are things wrong with the Agile community and with Agile itself. Let us say it loud and clear: Agile is broken. The Agile community is broken; many Agile practices are broken; and some foundational Agile ideas are broken, or at least overly simplistic and incomplete — and therefore misleading and even damaging. 1. The Big Gap We feel that the largest defect in Agile thinking regards the role of leadership. Leadership is a very complex topic: there are many thousands of books about leadership. It is a topic that has preoccupied thinkers and doers since the early days of human civilization. The Epic of Gilgamesh — humanity's first “book” — s at least partly about leadership, containing lessons about perseverance and the dangers of falling under the influence of those who might distract one from one’s que: Leadership has dominated human writing throughout history. The invention of representative government in Greece created a new model for human society, and that innovation was fundamentally about leadership and how to manage it. ‘Today we have a crisis of leadership throughout society, at many levels, and that is having a huge impact on us all. Leadership is central for human endeavors. Despite this, the Agile Manifesto says little pertaining to leadership. One statement is, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” The other is, “The best architectures, requirements, and designs emerge from self- organizing teams.” While these statements have merit, they appear to dismiss the need for any formal leadership, and they also are drastic simplifications and have led to widespread misinterpretation and extreme implementations. 2. A Culture of Extremes ‘The Agile movement arguably began with the release of the book Extreme Programming Explained: Embrace Change, in 1999. Extreme Programming (XP) sent shock waves through the IT industry. At the time, extremes were popular: we had extreme skiing, extreme volcano surfing, and the “X Games.” At that moment in history, for anything new to get attention, it had tobe “extreme”; thus, XP was trendy, and as its name implies, it was a collection of very extreme methods. ‘The Agile movement crystallized when the Agile Manifesto was written two years later. Unlike XP, the Manifesto was not about extremes; in fact, it was about balance. Thus, it was diametrically opposed to XP, which advocated all-in adoption of extreme methods instead of using judgment about choosing the right method. Few noticed that XP and the Manifesto were at odds. As a result, the Agile movement began with built-in cognitive dissonance. The prevalent ethos of extremes was then applied to the Manifesto, and so the Manifesto’s carefully balanced statements were interpreted as extremes. The statement “[We value] Working software over comprehensive documentation” was interpreted by many as, “We value working software, and documentation is not needed.” The statement, “The best architectures, requirements, and designs emerge from self-organizing teams” was interpreted as “All teams should self- organize,” or even, “We don't need anyone with explicit authority — managers are bad.” The Agile community continued to amplify the extremes in a kind of race to be the most extreme, coming out with “mob programming” as a more extreme version of XP's “pair programming.” The idea of self-organization turned into a call for totally flat organizations. The agendaless Lean Coffee became a popular format for events. The minimally planned “open space” format became popular for many corporate conferences. Many organizations tried these things. Google tried a flatter organization in 2002, but the experiment failed. The lesson that these practices contained good ideas but that the extreme version tended not to work was lost on the Agile community, which doggedly pursued the extremes, shutting out news of failures. The “Agile team room” — an open room with everyone on a team sitting in close proximity — continued despite widespread criticism: all one has to do is Google “open plan office” to see how the arrangement is disliked. Yet, Agilists still advocate it, ignoring the push-back. It is as if these practices have momentum, and cannot easily be updated in response to feedback, or there is an unwillingness to update them once people have invested social capital in advocating for them. ‘This dogma and linear intransigence is actually toxic. It locked the Agile community into a rigid set of ideas, and prevented the community from doing what it itself recommends: trying something and then pivoting if necessary. Instead, the Agile community progressed in the same direction, no matter the outcome.It was this rigidity that led to the independent evolution of DevOps — a set of methods for rapidly deploying large-scale computing applications. DevOps methods were presented at Agile conferences but those methods went largely ignored by the Agile community at large, and so DevOps became its own movement, and today most DevOps experts do not know much about Agile, and vice versa. The Agile community stifled its own evolution — a profound irony. 3. We Want to Fix This ‘We want Agile to evolve — to pivot to what works better. The original Agile Manifesto was created by a collection of middle-aged Western culture guys (like this author) and all from similar cultural backgrounds. For Agile 2, we assembled a global team of 15 people, with skills and experience in program management, leadership, human resources, product design, engineering, data science, and of course Agile and DevOps. Our aim: fix Agile. First we conducted a retrospective: we each spoke to what we felt was wrong with Agile. We then debated those issues. Because of our globe-spanning locations, and because of our number, we could not collaborate easily in real time, so we used a combination of Google documents, email, and one-on-one web calls, Despite the logistical challenges, we were able to thoroughly discuss our retrospective issues and came up with a large number of “insights,” and then a set of “principles.” We then stepped back from that and defined a set of “values.” Thus, it was a bottom-up effort: a process of defining problems, possible solutions, and then rolling those up into general principles and finally values. The core of our guidance is about leadership. We realized that: * Leadership is a complex issue - it cannot be addressed by a short maxim or phrase like “self organization” There are different forms of leadership, appropriate for different situations, and every individual can be a leader in some ways. Leadership is essential, and it sometimes (not always) requires authority. Eliminating authority or leadership does not solve the problem of bad leadership ~ it exchanges one problem for another. Leadership can become stifling and self-serving: we must focus on forms of leadership that are empowering yet that provide the needed direction.* The best leaders use their authority sparingly. * Leadership is the most important thing of all in an organization: with good leadership, the initial methodology will not matter in the long run because it will be adjusted as needed; conversely, with bad leadership, the best methodology in the world will fail. Because of these conclusions, we knew that we had to address the issue of leadership head on. Our goal was not to compete with the wealth of writing about leadership that exists. Rather, we attempted to address the leadership issues that arise in organizations, and the varying contexts, and the different approaches and their tradeoffs. One might ask, what about the old Agile Manifesto? Well, itis just that — the Old Agile Manifesto. It helped to disrupt some bad trends and push thinking in a new direction. It had good ideas in it. Its emphasis on balance and judgment was insightful, even though that was lost on those in the Agile community who kept pushing things in more extreme directions. But the Manifesto was an experiment: and it is time to pivot. Read the Agile 2 Values and Principles here. Agile 2