You can tell that an idea is starting to catch on when different people or groups start trying to advance it independent of each other.

The advantage of that is people who hang out in different circles find out about the idea. The downside is that they run a chance of finding out wildly different views about that idea to the point when people from those different circles start talking to each other, they can’t tell whether they are even talking about the same thing.

Business Agility is in that territory right now.

I defined business agility for Agile Alliance’s Agile Glossary as:

Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers.

Business agility is not a specific methodology or even a general framework. It’s a description of how an organization operates through embodying a specific type of growth mindset that is very similar to the agile mindset often described by members of the agile software development community.

There are at least three different views of Business Agility of which I’m aware. I suspect there are others. They have some common themes, primarily the ability of organizations to respond to change and a focus on their customers. They also have some differences.

Agile Alliance

Agile Alliance has an initiative, facilitated by a group of current and former business leaders focused on identifying and sharing methods to explore the adoption of the Agile mindset and methods in the enterprise.

The initiative includes a monthly webinar that connects business leaders to the Agile community to share perspectives and insight of how Agile works within a business and an ongoing worldwide narrative-based retrospective of Agile and business. The goal of the program is to identify both positive and negative stories from the agile community and to work to amplify what makes Agile work well for business.

ICAgile And the Business Agility Conference

The International Consortium for Agile (ICAgile) has added a Business Agility Track to their Learning Roadmap that will provide a path toward a business agility certification.

ICAgile presented the Business Agility Conference in 2017 The conference was 2½ days of authentic short stories and facilitated deep dives on business agility; focusing on organizational design, market disruption and product innovation, agile outside IT and next generation leadership. You can get the videos from the 2017 conference from InfoQ.

Evan Leybourn the conference chair of Business Agility Conference 2017 described business agility in the article Domains of Business Agility. In that article, you can find the following comment:

“If, and until such time as, there is a Business Agility manifesto, the values and principles of the Agile Manifesto apply across all areas of the organisation with one minor modification.”

He posted that article in May, 2017. By September, a Business Agility Manifesto showed up.

A Business Agility Manifesto

In September 2017, Roger Burlton, Ron Ross and John Zachman published the a Business Agility Manifesto with plans to “officially” announce the manifesto at the 2017 Building Business Capability Conference (BBC). The manifesto includes a few supplements, including the SideBar for IT Project Professionals which appears to try and address several agile adoption anti patterns.

Making Sense of these Perspectives

If your organization is trying to implement business agility, you’ll find some practical experiences and stories from the Agile Alliance efforts and the Business Agility Conference content. I haven’t seen much practical information from the Business Agility Manifesto, but then again manifestos are primarily intended to communicate principles and intent.

Did I miss any discussions about business agility? Let me know in the comments.

Photo by Climate KIC on Unsplash

Photo by Mona Eendra on Unsplash

A thought crossed my mind a couple of weeks back when I saw the announcement on LinkedIn about the Business Agility Manifesto.

“Oh great, another manifesto…”

(Full disclosure: I played a part in creating one of those manifestos, the Declaration of Interdependence.)

Then I wondered how many manifestos there are in the world of business and software. So in a bout of productive procrastination, I conducted a search. The results are listed below in an admittedly arbitrary organizational scheme. During the search, a couple of questions came to mind.

Why Write a Manifesto?

Manifestos are generally used to publicly declare principles and intentions and have been used for political purposes for several centuries. Geoff McDonald (no relation) compiled this list of famous manifestos which includes things such as the Bible, the US Declaration of Independence, Martin Luther King’s “I have a Dream Speech”, and the Communist Manifesto.

One of the other items on that list is the Cluetrain Manifesto. This manifesto, originally posted online in 1999 spoke to the impact that the authors foresaw the internet having on business. It probably signals the start of a trend toward using manifestos to share principles outside of the political sphere.

The document that had even more of an impact on the manifesto trend in technology and business is the Manifesto for Agile Software Development written in 2001. The Agile Manifesto provided a statement of values and principles that became a focal point for the agile software development community to form around.

Since it’s original creation in 2001 the Agile Manifesto has been widely referenced and has inspired a host of additional manifestos, including a fair share of parodies.

People with a set of beliefs in some aspect of business or technology look at the spread of agile software development, attribute the spread to the presence of a manifesto and reason that if it worked for agile…

What makes a Successful Manifesto?

Since manifestos are intended to declare and spread the ideas of its authors. Therefore a successful manifesto is one that spreads those ideas wide and generates actions that are aligned with the ideas contained within.

If you look at the manifestos in the list below and see which ones are more well known than others, there are some possible patterns that contribute to success:

• The manifesto resonates with people and expresses principles that they share.
• The manifesto is simple and concise
• The manifesto is created by a group of people from different organizations who may compete, but share the same values and principles
• The manifesto is backed by a community where people can share ideas and experiences about how they’ve actually applied the ideas in the manifesto in their actual context.

Examples of manifestos that meet these criteria to some extent include: Manifesto for Agile Software Development, The Manifesto for Software Craftsmanship, and Modern Agile.

Here is a list of manifestos related to Business and Software. Please let me know if I’ve left any off.

Agile and Agility

Manifesto for Agile Software Development

The Declaration of Interdependence

Modern Agile

Product Agility

The Business Agility Manifesto

The Responsive Manifesto

Agile Manifesto Variations

The Waterfall Manifesto for Realistic Software Development

Manifesto for Half-Arsed Agile Software Development

Dark Manifesto for Agile Software Development

Software Development

The Manifesto for Software Craftsmanship

A Software Development Manifesto – Klipfolio

Manifesto for Responsible Software Development

The Reactive Manifesto

The Boring Software Manifesto

Manifesto for AntiFragile Software

Manifesto for Adoptable Software Development

The Good Eggs Software Development Manifesto

Manifesto for Minimalist Software Engineers

Manifesto for Async Software Development

The GNU Manifesto

Software Architecture Manifesto

SOA Manifesto

Software Gardening Manifesto

The Rugged Software Manifesto

Business Analysis

Business Analysis Manifesto (Xebia)

The Business Analyst Manifesto (Bridging the Gap)

The Business Analysis Manifesto (Business Exchnage)

Jeffrey Davidson’s BA Manifesto

The Lean Business Analysis Manifesto

The Junior Business Analyst Manifesto

User Experience

UX Manifesto

Testing

The Testing Manifesto

Continuous Testing Manifesto

Agile Testing Manifesto

GDS Agile Testing Manifesto

Testing Manifesto

The Open Source Test Manifesto

Project Management

The Pragmatic Manifesto for Project Management

The PMO Manifesto

I’m in the process of building this site out. My intent is for it to be a place to share observations and suggestions on topics not relevant for other places where I write for specific purposes.

This is not intended to be a Minimum Viable Product.  It is a website that is in the process of being built, yet public anyway.

There is a difference.

Photo by 贝莉儿 NG on Unsplash

…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
to
How do we get the executives to come to our executive summits?

Agile is only for small teams
to
We must scale!

Extreme Programming is the way to go
to
Scrum is the way to go
to
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.

CA acquired Rally

CollabNet acquired Version One

Accenture acquired SolutionsIQ

Apax Partners acquired ThoughtWorks

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.”

Update 09.19.2017:

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?