Is Agile Really Just a Happy Accident?

happy accidents largeIn recent weeks, there has been increased discussion among some in the Agile PMI community who are seeking empirical proof for how and why autonomy and team empowerment actually works. What I find interesting is how difficult it is for Agilists to provide much more than anecdotal evidence supporting this foundational Agile principle.

This discussion interested me because I have reached beyond the Agile community over the last year to learn more about how human performance is influenced by our work environments and our cognitive biases. During this time, I’ve become increasingly aware that Agile values and supporting process patterns are either a very happy accident (when they work) or, more commonly, very dangerous “solutions” to those seeking corporate transformation within the software and product development collaboration space.

Leaders that I have had the privilege to spend time collaborating with and learning from this past year include several behavioral scientists, such as B.J. Fong at Stanford and Dan Ariely at Duke, as well as business leadership innovators like Gary Hamel of Harvard. These thought leaders in the behavioral and management science fields are helping future business leaders explore ways of radically changing how we design and manage organizations based on the exciting research and insights we’re acquiring from the behavioral sciences.

Some of the more interesting work will sound familiar to those who are students of system design and architecture. Reconfigurable networks, composed of loosely coupled teams, each with a scope and mission objective focused on global, corporate, product, and/or local, human performance, are starting to emerge as an organizational pattern. Empowering these future teams with enormous autonomy and self-directed latitude is a given; however, despite the DNA these networks share with the Agile world, I am bothered by how common it is for those promoting Agile practices to lead with a predefined solution pattern, Scrum and Lean being the current flavor of the day. I rarely see Agile coaches, instructors, and Agile software tooling companies seeking to first understand the system bias and constraints within a specific client context before advocating and implementing a solution. Yes, I know the “just do it” approach feels good to those in the Agile community, but I’ve seen way too many failed Agile transformations over the last few years to suggest that this is an enlightened approach, despite what those pushing Scrum Training and Agile tools might have you believe.

As I work with the cognitive and management scientists, I’m also learning that the root cause of so many corporate Agile adoption and culture impediments has been mislabeled and misdiagnosed. While we spend a great deal of time in the Agile community talking about the need for culture challenge, I actually think we’ve gotten it all wrong. Yes, I completely agree that culture must change, but it’s the architecture and design of the enterprise (“the system”) that shapes culture, not the other way around. For this reason, I believe that we should encourage a renewed focus on redesigning the architecture of the enterprise management system, not on tackling culture head on.

The encouraging news is that emerging models for future corporate design within the behavioral and management innovator community point to corporate system designs that share many of the principles that inspired the Agile manifesto. Despite this, however, the specific solution patterns that are emerging are richer and less “cookie cutter” than solutions generated by those who promote Scrum as a panacea for all problems and all stakeholders in an organization. And for those who espouse Lean as a more “grown up solution” for the larger company challenge, I’d remind them that large companies are complex adaptive systems, and by their very nature, no two companies will ever produce the same result each time a pattern like SCRUM or Lean is applied.

Before the flames start, please don’t misunderstand my comments. I’m NOT saying that Scrum and Lean are without utility or value. In fact, we actively teach and use both as tools for corporate change here at Gear Stream. Instead, I’m simply suggesting that the enterprise transformation objectives our clients need and deserve require us to first re-imagine the architecture/design of the larger corporate collaboration context. Then and only then can tailored and optimized solutions be explored. Said differently, deploying Scrum and Lean “by the book” is both intellectually bankrupt and downright dangerous. If it does work, consider yourself lucky. For this reason, I encourage all enterprise clients to avoid the “Agile widget crowd” that has cleverly packaged Agile to look like a simple recipe book of training and tools. Instead, seek out those who serve as navigators and problem solvers who bring Agile thinking and tools with them but never pull these tools out before first understanding what problems we’re really trying to solve – and more importantly, taking the time to define success in terms that are relevant to creating a sustainable, relevant enterprise .

As always, YMMV.

Leave a Reply

Your email address will not be published. Required fields are marked *