(Excerpt from the upcoming book “Agile in the Bloodstream” by Daryl Kulak and Dr. Hong Li)

Agile is an exciting prospect. It is usually pretty easy to see that an Agile project is physically different than other ways of developing software (team rooms, pair programming, etc.). Moving to Agile can feel like jumping across a chasm into a whole new territory.

Once you’re there, and it starts working well, Agile can be exhilarating. We’ve seen teams experience true joy from producing results quickly and being so deeply in touch with their customers using Agile.

But often a strange thing happens with Agile teams inside non-Agile organizations. They don’t expand. The Agile team may be able to produce great successes but the rest of the organization doesn’t recognize the team’s victories or, worse, start working against the team to ensure its failure.

Is this crazy? Is the rest of the organization insane with jealousy because the Agile team has found something new and useful? Yes, this is possible. But, in our experience, there is more going on. Introducing Agile into a non-Agile organization creates all kinds of issues that the organization and the Agile team need to address upfront if the team wants to be successful in the long term. We group these issues into a category we call illth.

Agile is Like Wal-Mart (Sort Of…A Little)

Illth. Nineteenth century English art critic John Ruskin created this word to describe the messy bits that came along with wealth. In Ruskin’s time, he saw that wealth was being created in various ways in England, with businesses and factories, but with those advances came the “side effects” of wealth, which were not as desirable. Underpaid and overworked laborers’ dismal lives could have been considered illth. The pollution and grime created by the factories in the community would have been illth. And the unrelenting movement of money from the poor to the rich was certainly illth in Ruskin’s mind.

Here is the definition of illth in Ruskin’s own words:

Wealth, therefore, is ‘The possession of the valuable by the valiant’; and in considering it as a power existing in a nation, the two elements, the value of the thing, and the valour of its possessor, must be estimated together. Whence it appears that many of the persons commonly considered wealthy, are in reality no more wealthy than the locks of their own strong boxes, they being inherently and eternally incapable of wealth; and operating for the nation, in an economical point of view, either as pools of dead water, and eddies in a stream (which, so long as the stream flows, are useless, or only to drown people, but may become of importance in a state of stagnation should the stream dry); or else, as dams in a river, of which the ultimate service depends not on the dam, but the miller; or else, serve as mere accidental stays and impediments, acting not as wealth, but (for we ought to have a correspondent term) as ‘illth,’ causing various devastation and trouble around them in all directions; or lastly, act not at all, but are merely animated conditions of delay, (no use being possible of anything they have until they are dead,) in which last condition they are nevertheless often useful as delays, and ‘impedimenta.’

Although Ruskin’s definition sounds overly damning toward the rich, we still feel there are aspects of this definition that can be quite useful.

Since Ruskin’s time, illth has been used only sparingly in books and speech, mostly notably by George Bernard Shaw in his essays on socialism. But it seems like a good word. Certainly, often when we do something good in our community, there are bad things that come with it that we need to deal with. Pollution is the best example in our own time. Our incredible engines of growth in North America, Europe and Asia have generated great wealth for millions of people. But the scourge of pollution has inevitably followed that wealth, darkening its splendor.

Wal-Mart is a great example of wealth and illth. When Wal-Mart comes to town, there are great things that happen. People can get stuff for good prices and there are more jobs, lots more jobs. But there is also illth. Wal-Mart has a tendency to have a bad effect on the local smaller stores, putting them out of business because they can’t compete with the low prices.

What does illth have to do with Agile? Please don’t be offended that we are comparing Agile to Wal-Mart, and please don’t think that we’re saying that Agile team members are very like the idle rich that Ruskin seems to detest so much.

When you look at a highly-functioning Agile team, you can see their success as a form of wealth. An Agile team is often somehow magically able to accomplish mountains more work than a comparable waterfall team, and yet they work fewer hours and are happier with their work. The wealth flows.

So where is the illth? It might not be within the team itself, but it could be leaking into the teams surrounding the Agile team. How does the Program Management Office (PMO) feel about the Agile team? Are they “feeling the wealth” or “feeling the illth?” What is the effect of Agile on the team that deploys applications into production? How about the competency centers? Or the human resources teams?

You don’t have to scratch the surface very hard to find people in a large organization that are actually upset about the Agile team’s successes. Yes, this might sometimes be due to their jealousy of the success, but there is another aspect to it.

Think of your large organization like the body of an animal or a person. What happens when your body ingests something that it doesn’t recognize? White blood cells attack the new thing and try to kill it. War is on, and either the intruder is flushed out of the system or the body dies trying.

Is that necessary in your organization? It doesn’t have to be if you, the Agile team, can manage your illth.

First, let’s examine the problems that an Agile team can create for its neighbors in the large organization. After that section, we’ll look at some solutions that can help Agile and non-Agile co-exist.

Here are some types of Agile illth:

• Agile vanity
• Agile project within Non-Agile program
• Incremental impedance mismatch upstream
• Incremental impedance mismatch downstream
• Clash with the corporate methodology
• Clash with the corporate project management structure and tools
• Clash with competency centers

Here is a bit about Agile vanity. (We’ll discuss the other topics in a later post.)

Having seen Agile projects in many, many situations and variations, we’ve had the chance to observe a peculiar Agile tendency that we call “Agile vanity.”

In fact, it is quite natural, once you’ve discovered a new and better way of doing something to feel a bit full of yourself for a while. The only trouble is that this can cause great strain in your organization. Let’s look at some of the things that happen when Agile proponents turn into “Agilistas.”

Inside the Agile team, the observation of results helps to create enthusiasm and a willingness to commit time and energy. The team feels like they are being productive and are working well together.

When someone in the team is discussing their project with people outside the team, they may give a sunny picture of what is happening due to their own happiness with their work. The outsider is likely to question these new methods, especially if they haven’t seen it work themselves. This may put the Agile team member on the defensive a bit, feeling like they need to give the most articulate answers or this person might think the Agile team is just being duped by the latest software development “fad.”

Each time this happens, the Agile team members may feel like they just shouldn’t bother interacting with those outside the team, or if they do, maybe they shouldn’t discuss Agile too much for fear of being in a defensive situation again. The other aspect that can arise is that the team members discuss the successes of Agile among themselves but decide that the others “just can’t understand the Agile way.” This creates a barrier between the “insiders” and “outsiders.” This is what we call “Agile vanity.”

The danger here is that, as soon as the team erects this barrier, those outside instantly feel that they need to defend themselves against being viewed as stalwarts of the “old way.” The outsiders begin to come up with lists of reasons why Agile can’t possibly work and why the Agile team’s successes are due to factors other than the Agile practices they are using.

As you can imagine (or possibly as you’ve experienced), this is not productive. The outsiders can be other teams or they can also be the executive managers of the Agile team. The direct and indirect managers of the team can cause a great deal of havoc for the team, at worst hemming them in with random directives that are, subconsciously, being done to ensure the failure of the team.

The same things that help the team stick together can be the very things that distance them from the outside world. And those outsiders are people the Agile team needs to be successful, whether direct managers, co-workers, upstream or downstream projects, or other connecting teams. Agile vanity, although it feels good at the time, can be quite destructive.

It is worth paying equal attention to what is happening “outside the Agile team room” as well as inside. Too many of our Agile practices and principles deal with the goings-on inside the room, but it is what’s happening “out there” that can kill the project too.

Trackback URI | Comments RSS