Agile transformations have little, if anything, to do with Agile Software Development. Let me hook up some connections for you. Bit of a rant here …

The fundamental message of this and many related articles is that while bringing “Agile” ideas to leadership may improve the company’s performance, it will not likely “transform” the company, and it will almost certainly not improve either the production of software or the lives of software developers.

The article Connections - Leadership isn’t enough. set forth in 15 sentences and a few pictures one key aspect leading to this conclusion: any message starting from leadership will inevitably be corrupted by the time it reaches the worker level. This is a fundamental and inevitable result of information theory. We all do our best to avoid this concern, with shorter lines of communication, careful crafting of our messages, and so on, but even with great care, it happens.

Worse yet is the fact that almost no one who does “Agile Leadership” training or coaching has any real understanding of software development, much less the particular, relatively new, practices that need to be applied for Real Agility™. Since they don’t know, they cannot infuse this information at the leadership level, so leadership can’t even try to transmit it down.

Some would-be “transformation” approaches give lip service to this concern. For example, SAFe calls for “Scrum plus XP” at the bottom, and says, right there on page umpty of the slides “Train Everyone”. It’s not their fault if not everyone gets trained.

Also playing in there is that there aren’t very many people who are even able to show developers how to do the things that are necessary to perform well under the “Agile” umbrella. There are good people out there, and good web-based material, but it’s too little too late for most developers.

Let’s digress a moment.
What does it take for developers to do this?

It’s not really germane here, but in essence, to get Real Agile™, developers need to be organized so that the team can produce a regular “Increment” of software, every week or two, that can be understood by the business people and customers who are asking for it. Developers also need to have the technical skill to produce that increment, and that includes a number of technical practices that most developers have not yet encountered.

Without this organizational and knowledge support, development will never be Agile, and therefore the company will never be Agile.

But we digress.

Meanwhile, the company at large will receive benefit. This will come, primarily, from shortening lines of communication, and in particular, from applying Lean principles to the production of product. They’ll limit WIP, working only on the most important things first. They’ll streamline the decision process, and so on.

These are all good things, even great things. Done with any diligence at all, the company will benefit, often profoundly. More work will be important, decisions will flow more smoothly. Good things happen.

The company is not, however, Agile. A company can’t be doing Real Agile™ until its development teams are doing Real Agile™.

And because the development teams are not trained in Agile, and therefore can’t do Agile, they will often come under more pressure than before, resulting in what I call Dark Agile™ and in the “Code Mines of Ohio”1.

I’m not sure whether this is irony or tragedy. I’m never sure about irony. But whatever it is, I find it sad that under the flag of “Agile”, good ideas, often but not always borrowed from Lean, result in a bad situation for developers, and don’t even produce the benefits that Real Agile™ promises and can deliver.

What can we do about this, Ron?

Some idiot once said “Bring me solutions, not problems.” He never heard about any problems, ever again, and I hope he went right down the tubes. More likely, he bailed in time and moved on to even bigger mistakes.

Be that as it may, I don’t know any great solutions. My Abandon Agile article is a serious attempt to start answering the question. Developers need to recognize that the thing called “Agile” they are encountering is very likely not going to help them, but that they can thrive within it if they learn a bit about producing the Increment, and related topics.

More is surely needed, much more. I don’t know what it is, or how to do it. Mostly all I can do today is cry out a warning.

Most everything on this site is related to this topic. Here are some links to things you might want to look at.

Categories of Interest

  1. Unfortunately not at all limited to Ohio. ↩