Who is talking about Business Agility?

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

A Collection of Manifestos

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

 

Satisfy needs instead of solving problems

The Daily Stoic newsletter for September 19, 2017 shared a common optical illusion that depending on how you looked at it could appear to be a couple of different things.

For the record, I saw the duck first, although with a little staring I was able to see the rabbit.  I’m not sure whether which animal you see first says anything about how your brain works, but the the fact that you can see multiple things in the image does.

The lesson here is that how you look at this illustration, and what you “see” resembles how our perceptions work. From the Daily Stoic newsletter:

Most of our perceptions about anything—people, situations, problems, anxieties—are like this. You can see a problem; or you can see an opportunity. You can see a crippling defeat, or you can see a fresh start. You can see the end, or you can see the beginning.

Your assessment is what changes.  The Stoics suggest that while you can’t control outside influences, you can control your reaction to them.  You can change how you think about them.

One change I’ve made over the past couple of years, and this has a lot to do with my work at kbp.media is that I talk about needs to satisfy rather than problems to solve.

To be clear, part of the reason I chose that language is because “needs to satisfy” is the way that concept is described in the Business Analysis Core Concept Model (BACCM) from IIBA. They were trying to make satisfying needs the standard (and admittedly shorter) way of saying “problems to solve and opportunities to exploit”.

 

If you look at it from a stoic perspective there’s another, perhaps greater reason.  You are no longer surrounded by problems.  Rather you help your customers by satisfying their needs.  You’re helping them move forward rather than just always getting them back even with everyone else (although there is certainly good that comes from that).

That small change in words can have a big impact on how you view your work, and the value you derive from it.  Give it a try.

The National Park Bucket List

National Park Service

One of the purposes of this site to share my experiences and lessons learned while trying to fulfill my quest to visit every single National Park in the United States.

Yes, every single one.

The quest started when I declared a bucket list to visit all of the National Parks in the United States.  Since it is a bucket list, the time frame initially was a long one – before I kick the bucket.  Since we originally created the bucket list item, we’ve refined the time frame a little bit, hopefully making it a bit more restrictive for reasons which should seem fairly clear.  Our aim is to visit every National Park by the time my daughter starts college (Fall of 2022).

For those of you who may be familiar with the National Park Service and all the various sites they manage across the United States, you may be thinking “Holy Cow!”  All these folks will be doing is traveling.  To set the record straight, I should point out that we are only visiting National Parks, those things noted in the Ken Burn’s documentary as “America’s Best Idea.”

There are currently 61 National Parks.  I say currently because in January 2013 that number changed from 58 to 59 when Pinnacles National Park was created, from 59 to 60 in February 2018 when the Gateway Arch was made a national park and to 61 in February 2019 when Indiana Dunes went from a National Lakeshore to a National Park.

My father has asked me what will happen if a new national park is created.  Well, if it is created before we finish the list, we have to go, don’t we? Here is the full list of National Parks as well as when we visited them.

What this bucket list does not include are all of the National Monuments, National Preserves, National Historical Parks, National Historic Sites, International Historic Site, National Battlefield Parks, National Military Parks, National Battlefields, National Battlefield Site, National Memorials, National Recreation Areas, National Seashores, National Lakeshores, National Rivers, National Reserves, National Parkways, National Historic and Scenic Trails, National Cemeteries, or National Heritage Areas.  That’s not to say that we won’t visit those places if we happen to be near by, but we’re not going to go out of our way to visit them for purposes of this bucket list.

What Constitutes a “Visit”?

As luck would have it, we did actually visit a few of the parks before we established the Bucket List.  (Those parks are marked with an asterisk by the visit date until we meet the criteria below).  To make sure we kept things above board,  we (my wife Beth and my daughter Paige) established the following rules.

  • We (at least one of the three of us) have to physically be in the National Park.
  • Proof of a visit is via the official stamp in my National Parks Passport which shows the date of my visit.  (This makes the Passport book a very precious commodity).  This is also an indication that one of us was actually in the Park Visitor Center
  • Preferably view the main sites in the National Park and go on at least one hike.

Those are the rules.  We tried to keep them simple and straightforward.

We obviously try to make the most of each trip because it would be kind of silly to make a long trip from say Iowa to Alaska solely to get a stamp.

We spend more time in some parks over others.  The shortest time spent in any of the parks was probably Cuyahoga National Park.  I spent a couple of hours there in March while on a trip to Cleveland for a speaking engagement.  I at least went and saw Brandywine Falls.  Probably the longest we have spent at any Park is Rocky Mountain National Park – we have been there four times – twice for a week at a time.  As you could probably suspect, that’s our favorite.

Our National Park Roster

As of June 2019, we’ve visited 35/61.

Name

Location

Date formed

When Visited

AcadiaMaine

February 26, 1919

July 2010

American SamoaAmerican Samoa

October 31, 1988

ArchesUtah

November 12, 1971

March 2012

BadlandsSouth Dakota

November 10, 1978

July 2012

Big BendTexas

June 12, 1944

January 2013

BiscayneFlorida

June 28, 1980

 November 2016
Black Canyon of the GunnisonColorado

October 21, 1999

March 2012

Bryce CanyonUtah

February 25, 1928

March 2014

CanyonlandsUtah

September 12, 1964

March 2012

Capitol ReefUtah

December 18, 1971

March 2012

Carlsbad CavernsNew Mexico

May 14, 1930

Channel IslandsCalifornia

March 5, 1980

CongareeSouth Carolina

November 10, 2003

July 2018
Crater LakeOregon

May 22, 1902

Cuyahoga ValleyOhio

October 11, 2000

March 2012

Death ValleyCalifornia, Nevada

October 31, 1994

 March 2013
DenaliAlaska

February 26, 1917

 August 2016
Dry TortugasFlorida

October 26, 1992

EvergladesFlorida

May 30, 1934

 November 2016
Gates of the ArcticAlaska

December 2, 1980

Gateway ArchMissouri

February, 2018

GlacierMontana

May 11, 1910

 June 2017
Glacier BayAlaska

December 2, 1980

June 1995*

Grand CanyonArizona

February 26, 1919

Grand TetonWyoming

February 26, 1929

July 2009*
June 2015

Great BasinNevada

October 27, 1986

Great Sand DunesColorado

September 13, 2004

March 2012

Great Smoky MountainsNorth Carolina, Tennessee

June 15, 1934

June 2018
Guadalupe MountainsTexas

October 15, 1966

HaleakalāHawaii

August 1, 1916

February 2000*
February 2015

Hawaii VolcanoesHawaii

August 1, 1916

 February 2015
Hot SpringsArkansas

March 4, 1921

December 2012

Indiana DunesIndiana

February 15, 2019

May 2019
Isle RoyaleMichigan

March 3, 1931

 August 2014
Joshua TreeCalifornia

October 31, 1994

 March 2013
KatmaiAlaska

December 2, 1980

Kenai FjordsAlaska

December 2, 1980

 August 2016
Kings CanyonCalifornia

March 4, 1940

Kobuk ValleyAlaska

December 2, 1980

Lake ClarkAlaska

December 2, 1980

Lassen VolcanicCalifornia

August 9, 1916

Mammoth CaveKentucky

July 1, 1941

June 2019
Mesa VerdeColorado

June 29, 1906

Mount RainierWashington

March 2, 1899

August 2013

North CascadesWashington

October 2, 1968

OlympicWashington

June 29, 1938

Petrified ForestArizona

December 9, 1962

PinnaclesCalifornia

January 10, 2013

RedwoodCalifornia

October 2, 1968

Rocky MountainColorado

January 26, 1915

November 2002
July 2008
July 2009
March 2012

SaguaroArizona

October 14, 1994

SequoiaCalifornia

September 25, 1890

ShenandoahVirginia

May 22, 1926

June 2018
Theodore RooseveltNorth Dakota

November 10, 1978

July 2012

Virgin IslandsUnited States Virgin Islands

August 2, 1956

VoyageursMinnesota

January 8, 1971

August 2014

Wind CaveSouth Dakota

January 9, 1903

July 2012

Wrangell –St. EliasAlaska

December 2, 1980

YellowstoneWyoming, Montana, Idaho

March 1, 1872

July 2009*
June 2015

YosemiteCalifornia

October 1, 1890

 October 2015
ZionUtah

November 19, 1919

 March 2014

Farewell Cassini

The Cassini Spacecraft during testing in 1996

Imagine for a moment, working on the same thing for over 20 years of your professional career only to see it end as a loss of signal from a piece of hardware over a billion miles away because you intentionally sent it careening into the object the the mission intended to observe.

Photo Credit: (NASA/Joel Kowsky)

That is what leads to images like the one above – the end of the Cassini mission that has been exploring Saturn and it’s moons since 2004 after leaving earth in 1997.

20 Years.

In case you haven’t heard what happened at Saturn amidst all the idiocy happening on this planet. The team working on the Cassini Mission chose to plunge the spacecraft into Saturn in order to reduce the risk of the spacecraft crashing on one of Saturn’s moons and potentially contaminating a moon that might have life.

I find it interesting that this team seems to have more concern for objects a billion miles away from Earth than many people and corporations do for areas on this planet.

It gives me hope that maybe, just maybe, humans can care about the world and the universe in which we live to make a decision that while personally difficult and painful is in the best interest of the bigger picture.

Cassini is was a probe launched in 1997 to explore Saturn and it’s moons. The original planned mission was supposed to be four years in duration once it reached Saturn in 2004.

It continued to gather data about Saturn until it’s final, intentional plunge into the planet 20 years from it’s launch on September 15, 2017.

There’s not too many government activities you can point to that continue to add value for twice as long as their intended life.

I would like to thank these people for making Cassini happen and for getting us a bit more information about the universe in which we live.

The Cassini Mission Team

If you would like to know more about Cassini, goto NASA’s Cassini Site. While you’re there, check out what else NASA is up to.

The Agile Industrial Complex: Solution over context?

…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?

Living the effective life