I Think It Really Wants Out

Recently, Charlie Rudd of SolutionsIQ posted an article entitled "The Third Wave of Agile."  Although I've never really dug SolutionsIQ's Scrum-centric version of agility, and I might dicker a little with Mr. Rudd over some of the details of his article, he did a great job of portraying certain trends in our community and American business in general as well as associating these trends with particular events and, especially, particular authors and works.

It's a good article, and I suggest giving it a read if you have the chance.  The upshot of the article is this: the current trend in agility has moved beyond software development teams, is leaving the vicinity of scaling, and is entering the area of what he calls "Business Agility" that embraces both non-software aspects of an enterprise as well as non-software enterprises.  In other words, the current focuses in the agile community are on how an entire organization increases their agility rather than simply how software development efforts can become more agile.

I think this is a solid observation, and he's correct about the general timing in which these various areas were the focus of the agile community.  I'm sorry to say that it's only recently that the community at large has caught up to the fact that "agile" is an organizational quality and not a software development methodology.  Instead of seeing this trend as good news for the community and business in general, I thought it was kind of sad.  How could such a large swath of agile thought and initiatives not approach agility as a business issue and approach it primarily as a software development issue for so long?

I'm tempted to say part of the explanation comes from our origins.  The full name of the Agile Manifesto is "Manifesto for Agile Software Development."  It was drafted and signed by founding fathers of Scrum, XP, Domain Driven Design, and many of the movements and advocacy directions we associate with modern software development. The fact is that the agile movement as we know it more or less originated with and was primarily concerned with software development sucking less.  Obviously, this is going to shape the movement's interest and direction for some time.

However, the principles behind what Rudd describes as Business Agility predate the manifesto and agile software development by some time.  Demming, Goldratt, and even more recent authors like Reinertsen accomplished in manufacturing the kinds of things "Business Agility" encompasses decades before agile software development.  So, we can't blame this all on origins.

I'm also tempted to blame Scrum, as I often do for most of our economic and social ills.  Certain organizations have worked very hard to make the terms "Scrum" and "Agile" synonymous.  Being an "agile shop" means that you are "doing Scrum" and vice-versa, so of course agility primarily means software development in that vector as "becoming agile" is more or less the same as "doing Scrum consistently."

With experience, however, even the biggest Scrum fans come to realize that these things are not necessary connections.  There are organizations that are very agile that have never heard of Scrum, and there are organizations "doing Scrum" that are about as agile as a brontosaurus with inner ear problems.  However, there's about a decade in there of equating these terms, so it's not surprising that it's only recently that the bulk of the agile community are starting to think outside of software development.  Unfortunately, that tends to look like trying to apply Scrum outside of software development, but we'll get there.  Baby steps.

Whatever the reasons are, it has become clear to just about everyone that true agile transformation does not want to stay inside the software development box.  Certain visionary geniuses were writing about this years ago, but this is slowly starting to dawn on the community as a whole, and I expect this is due less to the efforts of authors and more of the product of experience.

If you truly have an agile software development effort, you will create significant tensions at the boundaries between your effort and the rest of an organization that is not agile.

Agile coaches, if this has never happened to you, or you pride yourself on making teams agile "in ways that are compatible with the rest of the business," you might want to take stock of what you've actually accomplished.  You can't have a segment of an organization's value creation be agile and the rest of it not be agile and not have issues. It's like speeding up one wheel of a shopping cart or strapping the engine of an F-16 to a crop duster - the rest of the system is going to buck against it because it doesn't have the structure to handle it.

Any and every successful agile coach and consultant knows that, even if you make a tactical decision to start with software development, you absolutely cannot stay there.  The whole organization must eventually be changed by these principles, or the results will be unpredictable and even possibly worse than it was before.

An agile software development effort should cause tensions with how the organization plans their strategy, picks their projects, funds their projects, executes their work, makes decisions, structures their departments - there really is nothing that won't or can't go untouched - so it is only a natural progression that our sights should move from software development to business agility, if they weren't there already.

As you think about your software development efforts (or your law firm, or your publishing company, or your restaurant) becoming more agile, ask yourself questions about the rest of the picture.  Do you know how accounting will need to change?  How about your model for project definition and how to manage them?  How about how you identify and manage risks?  How about how you decide how to act on a strategic goal?  Does your consultant or coach know how to help you in these areas?  If you are an agile coach or consultant do you know how to help a client with these areas (HINT: It isn't to take a software development methodology and try to apply it to other departments)?

If you haven't already come around to these issues, Rudd's article is right on the money.  This is the next big need in increasing agility.  Are you ready for it?