…we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the military-industrial complex. The potential for the disastrous rise of misplaced power exists and will persist. –Dwight D. Eisenhower’s Farewell Address to the Nation
The Swinging Agile Pendulum
The agile community, like most other movements I suppose, has gone through several pendulum swings since it was “officially” became a movement in 2001 with the creation of the Agile Manifesto.
Leadership summits are too exclusive. We shouldn’t talk about leadership in agile
How do we get the executives to come to our executive summits?
Agile is only for small teams
We must scale!
Extreme Programming is the way to go
Scrum is the way to go
SAFe is the way to go
With a healthy dose of Kanban (whose proponents would argue “is Lean, not Agile”) mixed in there for good measure.
The most recent pendulum swing is from a large number of, for lack of a better term, self organized organizations providing consulting and tools for agile to a raft of consolidation.
That’s a sampling of the announcements from the last couple of years. While each merger has a specific reason it happened, I can’t help but think that this is a trend that warrants some attention.
If you look at the announcements, most (but not all) of the acquisitions are a larger entity trying to buy their way into the “agile space” by purchasing skills or products they don’t currently have in order to enter a target rich environment they currently do not inhabit. That is a typical reason to do an acquisition. However in this case, these new entrants have a disturbing effect on the community as a whole and the amount of new ideas that get generated.
To understand why, it’s helpful to consider different types of communities.
Consolidation Changes Focus From Needs to Solutions
Chris Matts took a look at the agile community in terms of Geoffrey Moore’s technology adoption curve and Cynefin and described how different types of communities are better suited for different points along that curve.
From Communities of Need & Communities of Solution by Chris Matts
Starting out on any new technology or idea, you have a Community of Need. These communities consist of people who try to solve their problems by looking at solutions from other contexts and try to adjust those solutions to fit their own context. They tend to focus on the areas to the left of the chasm.
As word starts to spread about about a particular idea or technology, folks start to form Communities of Solutions which are focused on selling the idea or technology to the people on the other side of the chasm. Unfortunately, the idea or technology that is sold is something that worked in a specific context of the organizations to the left of the chasm, which may not be the same context as that on the right.
Because the motivations of the people in the Community of Solution is spreading an idea as quickly as possible, they aren’t as interested in figuring out whether it’s appropriate for the new contexts. Chris described how this happened in the agile community in his assessment of agile as a broken learning machine. To make matters worse, while there are certainly aspects of agile that have been figured out (how to build software in small teams) there are several aspects that are not ready to cross the chasm, yet these are the problems most prevalent in the organizations being approached by the community of solutions.
These consolidations take organizations which at one time (some more recently than others) were part of a community of need and assimilate them into a community of solution. Any tackling of problems in different contexts, any unique approaches to unique solutions, any sharing of failures along the way that will lead to learning and success down the road will stop. That’s the case with most acquisitions in other industries. The new ideas and different approaches of the organization that was acquired gets lost in the way we’ve always done things of the acquirer. The new ideas can’t survive against the inertia of the collective and caring for context and fit for purpose get pushed to the wayside in the interest of meeting unreasonable sales targets. This community of solutions forms a part of the Agile Industrial Complex.
Meanwhile, the people at the organizations that get help from these new merged entities find themselves in the midst of another transformation program of the month. They figure if they keep their heads down this change will wash over them like all the others and will follow the same path out of the organization in due time, until the next transformation program of the month comes along.
There is a better way
Don’t seek to adopt agile, or lean, or SAFe, and certainly don’t impose those practices on your teams. Seek ways to more effectively satisfy your customer’s needs. It just so happens that many agile and lean ideas will help you accomplish that, but adopting agile should never be your end goal.
Remember your context in everything you do. By all means find out what worked for other organizations. It’s only smart to avoid reinventing the wheel. But also seek to find out why a particular technique worked in that context, and then understand the difference between that context and yours.
Seek out communities of need. These are your local gatherings of people who share their successes, and their failures. Local agile groups often have those types of discussions for people directly involved in software development. Groups such as the local Product Tanks do the same for product people.
If you find your organization has engaged a member of the Agile Industrial Complex who is trying to impose practices on your team, follow Chris Matt’s advice: “show them the door and find a new partner whose goal is your success rather than an easy life.”
If you would like a nice description of the ideas above and enjoy videos, you may want to check out the video of Chris’ talk on InfoQ: What Is the Purpose of the LLKD Community?