It came up again several times in the XP2006 conference that people are seeing Agile crossing the chasm. And I agree. Kind of. Agile is gaining mass and it certainly looks to me like Agile is indeed crossing the chasm if it hasn't already.

Actually, I'm sure Agile has crossed the chasm. It's just that what has come over is not always the same thing that began crossing. That is, crossing the chasm doesn't mean that the mainstream is ready to adopt Agile the way the early adopters have. And I'd like to muse on some of the ways this is showing in the work of consultants like myself.

A new audience is a new challenge. And a new audience is often a difficult audience. Jon Kern recently faced one such audience at Dave's company.

A few weeks ago I was presenting in a seminar targeted at senior management in the Finnish banking and insurance industries. These are the kind of companies one would not associate with anything that sounds fast, agile, or flexible.

Talking about agile methods to this kind of an audience is something that could be considered rather a new thing in Finland. But it does happen and there is interest towards agile methods within the management of these large financial institutions.

To quote another presenter in the same event, these companies and these executives are doing damn important work for the country. And, to quote one of the executives, they wouldn't be doing their job if they weren't looking into agile methods.

Over time, we will start seeing the results of this movement as well. As long as there are enough smart people who know what they're doing and why, these institutions can step up their performance in delivering business critical systems reliably and fast.

Which brings me to the next topic I'd like to muse on.

Scott Adams' Dilbert cartoons making fun of the pointy-haired boss without a clue is something that unites software developers across the world. The rough edges of the chasm are not because of clueless bosses with pointy haircuts, however.

Perhaps the biggest challenge of all in an organization's adoption of agile methods is the people. People are notoriously bad at adapting to change. Deep down, very few people like change. We object to change we don't want and we only want change we have been initiating ourselves.

With this in mind, the roughest edge of all is the pointy-haired boss with enough clue to be dangerous. In fact, it's not even the bosses with enough clue to be dangerous. It's pretty much anyone with the wrong kind of clue--although the boss tends to be a bigger problem due to her typically having more power to exhort than Joe Developer.

These are the kind of people who game the game to their own advantage, without regard to the good of the company. For example, I remember one consulting gig in the past where a project sponsor brought me in to help one of his projects ramp up their development capability with practices such as TDD. Arriving at the scene on Monday morning, I was told by the project manager that they want me to write unit tests for their existing code in order to raise their code coverage metric. "We'll then mimick what you've done," he said. That gig didn't last until the next day.

Referring to one of Jerry Weinberg's laws of consulting, one should only ever solve the client's problem and noone else's. The project sponsor wanted higher productivity while the project manager wanted his project to look better without risking any change to the current level of productivity. And the project manager was not my client.

The project manager in question was highly esteemed by many in the organization and while the project sponsor agreed wholeheartedly with myself that there is no point in getting a "hired unit tester", the project manager had a strong bias towards the way he'd done things before and the organization decided it couldn't afford changing the project manager. Note that it's not that they couldn't change the project manager. They simply resisted such a change (quite understandably) and opted for an easier solution, which was to look at improving their delivery capability elsewhere.

As agile methods are moving towards the mainstream, more and more organizational transformations to adopting agile methods are initiated top-down, "top" being the top and senior management. This brings forth problems some agile consultants may have not encountered before, having worked for organizations where the change has been initiated from the lower ranks.

It sucks to get new problems all the time. And still, when the dust settles, I love solving them the best I can.