Old Agile vs New Agile

Agile has changed. In the words of Jeff Patton,

“When people say Agile today, they mean something different today than they did in 2001…it’s come to mean something else.”

Unfortunately, some members of the Agile community are stuck in the past. They still believe early Agile myths and dogma such as:

• Every team can and should self organize.
• Teams can and should be fully autonomous.
• Before Agile there was only waterfall.
• Programming is a mostly social activity, and is analogous to sports.
• Agile coaches do not need to take an interest in the technical aspects of how the work is done, such as DevOps issues.
• Facilitators do not need to understand the subject being discussed.
• Good leadership usually emerges.
• The team usually knows best.
• The human side of Agile is where the focus should be: the team will take care of the technical side in the course of their work if you merely empower them.
• A team needs a methodology or framework.
• The problems that need solving are mostly at the team level.
• Scrum and Kanban are the only choices.
• Popular Agile practices such as face-to-face communication, a team room, standups, TDD, and pair programming are best for everyone and all teams.

Granted, not everyone bought into the above extremes, but a great many did, and these became assumed standard views across the Agile community during its early years. Yet if one looks at a range of compelling books and blogs that have come out in the past ten years from new authors, they paint a very different picture, and it is remarkably consistent. These arguably define a “new Agile”. Who are these new authors and what do they say? What is the “new Agile”?

One of my favorites is Klaus Leopold, and his book Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility. It is a non-technical book, so you won’t find DevOps in it, but despite that he brilliantly paints a vivid picture of why old-school Agile’s obsessive focus on teams causes us to lose sight of the product. He connects the dots on just how much has to happen to get a product to market and why an Agile team is only a tiny slice of that, and why all those involved need to understand the big picture and not just their little slice.

Another favorite is Mathew Skelton and Manuel Pais’s book Team Topologies. In it they expertly explain how teams exist in an ecosystem, and that the structures around those teams and how they interact is what is most important of all. Unlike old-school Agile’s tunnel vision about “the team”, Skelton and Pais explain why the entire product creation ecosystem is the wicked problem that must be solved.

Some old-school Agilists might react with, “But Agile has always pointed to the need for the organization to be Agile.” Well, I was around in the early days, and that is not true. The claim that the organization needs to be Agile really became loud during the late 2000s, after it became clear that inserting Scrum into an existing organization (which Scrum proponents happily supported) did not work, and we saw the rise of the mantra “Don’t do Agile, be Agile.” But by and large, Agilists had no answer for what it looked like for an organization to “be Agile”. Eventually the message became that an organization needs to have an “Agile mindset”, but again that is ill-defined. It is a catch-all for the unknown. In fact, this ambiguity is what led me and others in 2014 to launch Transition2Agile.com, for which we assembled a team that included people who had actually studied organizational behavior.

The books and blogs of new Agile are too numerous to list, but I need to mention some more so that you can see the pattern. Of particular note is the acclaimed book Accelerate by Dr. Nicole Forsgren (now VP of Research and Strategy at GitHub), Jez Humble (arguably the “father” of continuous delivery), and Gene Kim (perhaps the “father” of DevOps). In that book they have an entire chapter about leadership, which states (in the Kindle Edition, pp. 238–239),

“Why have technology practitioners continuously sought to improve the approach to software development and deployment as well as the stability and security of infrastructure and platforms, yet, in large part, have overlooked (or are unclear about) the way to lead, manage, and sustain these endeavors?. . .we must improve the way we lead and manage IT.”

They are pointing to the need for explicit leadership: self organization is not sufficient. In their book, they also provide statistically validated evidence that technical practices pertaining to DevOps strongly and causally correlate with business performance.

In the community of thinkers who write about business agility, the topic of leadership is central. The obsessive emphasis on self organization and autonomy are not present: the focus is on having the right kinds of leadership who can create the right climate and support so that people can be empowered. (“Empowered” is not the same as “autonomous.”) Academic writings on organization culture and leadership theory also emphasize the need for the right kinds of leadership.

(A note about team autonomy: Among people who really know how this works, “autonomous” is actually shorthand for “mostly autonomous”. For a team to be mostly autonomous, they need to have the right training, skills, experience, support teams, and self-service infrastructure; and even then, they are seldom 100% autonomous.)

There are countless other authors who have written powerful books about how humans work best together, including David Marquet, Dr. Daniel Kahneman, Eric Ries, MIrco Hering, Dr. Marta Wilson, Daniel Pink, Patrick Lencioni, Titus Winters (“Software Engineering at Google”), Mik Kersten, Greg McKeown, Jeff Dalton, and many others. Importantly, there are also authors who dismantle the extrovert-favoring and non-neurodiverse bias of the Agile community, including Susan Cain, Cal Newport, and Daniel Goleman. There are also bloggers such as Maarten Dalmijn and countless others who have pointed to myths and dysfunctions with some original Agile ideas and traditions.

The “New Agile” Ideas

And then there is Agile 2. Agile 2 is new in that it aggregates the ideas of these new thinkers, and integrates these ideas into a cohesive system of thought, while adding missing pieces. Agile 2 interprets these many writings and translates them into a common and holistically integrated shared narrative.

But what is that narrative? Agile 2 is complex because humans are complex. It is not a set of bumper sticker maxims asserted without supporting explanation and rationale. Agile 2 is nuanced and broad, and is published with the thought that went into it. But I will summarize it, to give you a sense.

Agile 2 is defined by its Values and Principles. Most of those principles could be summarized as described here. Basically, Agile 2 says that extremes don’t usually work well, and that judgment is called for when applying any practice. It also emphasizes the critical importance of having the right kinds of leadership for each situation. Note that “kinds of leadership” is plural. Agile 2 favors emergent leadership and autonomy, but it views those as aspirations rather than assumptions, and includes the theory that senior leaders need to be intentional about the kinds of leadership needed within their organization, as well as take an experimental yet thoughtful approach to the problem of leadership.

Another main thesis of Agile 2 is that it embraces neurodiversity, and that effective collaboration about complex topics is not as simple as having a face-to-face conversation. It also recognizes that people not only need to collaborate, but they also need to focus and be able to attain deep thought—something that many people cannot do in a group setting.

Another key element of Agile 2 is focus on the product and the ecosystem, instead of on the team. The hard issues tend to be how collections of teams work together and within their ecosystem. Individuals are called out as well, as being important to mentor, develop and recognize just as much as teams need those things, pushing back on old-school Agile’s obsession with “the team”. Again, it is about balance rather than old-school Agile’s extreme focus on the team and minimization of the individual.

Conclusion

Agile needs to evolve — and it has. We all need to let go of early partially formed ideas and elevate our thinking. Much of the thinking is not new in the history of human discourse: many if not most Agile ideas, both new and old, have been expressed many times before; but what changes is the balance and the collections of ideas that link together into a narrative. We need to advance the narrative.

More recent Agile ideas are a more evolved expression of Agile. They are more “grown up” in a sense, because they reflect reality instead of a simplistic ideal. Recent ideas are more inclusive, diverse, and rich. Gone is the insistence that everyone works best a certain way: new Agile embraces neurodiversity and helping people to work together and collaborate even when they do not all work best and communicate best in the same way.

Finally, this grown-up new Agile is not just about teams: it is about ecosystems and teams, and it addresses head-on the need for leadership in many forms and in many directions, both outward-facing and inward-facing. New Agile builds on and resonates better with the thinking in other communities of thought, including business agility, DevOps, leadership, PeopleOps, and organization design.

It is long overdue. If you largely agree with what the aforementioned “new Agile” authors have been writing, then old-school Agile is dead. Long live new Agile, and long live Agile 2!