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.

Here's my short (kind of) recap of the XP2006 conference that was held in Oulu, Finland this year. Before going any further, I'd like to thank the organizers and volunteers for a well-organized conference. The Reaktor team thanks you!

We arrived at the crime scene on Saturday and didn't stop having a great time at any time during the conference. It was fun, it was teaching, and it was revitalizing.

In addition to being Gold sponsors for this year's conference, we decided to revive the fine tradition of having conference t-shirts. There hasn't been a conference shirt at the XP conferences for a while and since we at Reaktor love good gear, we wanted to do something about it. And do it in style--here's Tom Poppendieck modeling our Scandinavian street wear design (come see us at the Milan Fashion Week next year...).

As you probably noticed if you were there, some people were also wearing a white Reaktor designed t-shirt featuring the code police. Pekka Abrahamsson, the programme chair, even announced keynote speakers wearing the code police shirt and our legendary I Love Servers trucker cap!

People thanked us many times for providing such cool t-shirts (and, to quote another conference delegate, a shirt that doesn't yell "I'M A GEEK" from a distance...) I really hope that our effort carries on to next year's conference in Lake Como, Italy.

Oh, and of course we had our beautiful ladies Kaisa and Miina handing out the shirts to make sure we don't have to carry a single one back! (and we didn't :)

This year, my participation involved an activity session and a couple of open space sessions (which this year's conference featured for the first time in its history). Just a few words of each of these.

The activity in question was the 3-hour at the conference on Tuesday afternoon together with Markus Hjort. The activity in question was the Coding Tournament which I blogged about before the conference.

We had advertised that participants could use either Java or Ruby, but we didn't quite finish the Ruby API in time for the session due to problems getting the built-in XML-RPC server running (it seems to have been a machine-specific issue). Most teams went for Java anyway, which wasn't a surprise. Geoff Bache, however, was there to try Ruby so I paired with him, having done some stuff with Ruby earlier in the year and being a Ruby fan in general. Also, J.B. Rainsberger stepped in and together we managed to whip up the necessary Ruby code for communicating with the game server over XML-RPC and to eventually to test-drive the actual bot stuff.

It turns out I wasn't much of a pair, though. Running the session for some 15 people with just two or three organizers (Pekka Enberg and Antti Mattila also helped us throughout the preparations and the session itself) meant that I had to run around a lot. Luckily, J.B. (whom I met in person for the first time in this conference, even though he's been kindly reviewing drafts of my book for over a year) was there and could pair with Geoff quite effectively, being a Rails convert himself.

We will submit the Coding Tournament to forthcoming conferences so if you missed the opportunity this time, don't fred. We'll also make the source code for the game server publicly available (probably at Laughing Panda). And speaking of forthcoming conferences, you are coming to XP Days Germany in November, aren't you?

We hosted the two open space sessions together with Bartek from Nokia Networks (that is, Nokia Siemens Networks after the recent merger) in Düsseldorf whose team I've visited a handful of times during the past year or so.

The first session was titled "Scaling Scrum" and drew some 15 people interested in talking about the ways Scrum can be effectively scaled up from a single team. The discussion revolved pretty much around a few people from Reaktor, Tecnomen, Nokia Siemens Networks and Sulake. Mike Cohn was there and not surprisingly had a lot of insights to share as well, having run Scrum projects of up to 100+ people.

The discussion was exactly what I am looking for in conferences and it was good to hear other people's observations and war stories on what has worked and what hasn't. Among the excellent notions that came up during the conversation was that "scaling Scrum" doesn't necessarily mean adding people. Splitting an existing team into two is also scaling--with many of the same problems one faces when scaling by adding a new team.

The other open space session I co-hosted (I mostly just participated since Bartek took care of introducing the topic and moderating the discussion) was titled "Leadership in Agile." Again, we had quite a good attendance and the people that showed up had a lot to say.

The discussion started off with some rather unexpected (in my opinion) disagreements. The fundamental issue seemed to be that not everyone understood the word "leadership" meaning the same thing. Specifically, "leadership" and "management" were considered synonyms by some, although personally I consider them being two wildly different things. In any case, plenty of discussion ensued from these disagreements and Bartek had his hands full keeping track of whose turn it was to get the speaking token.

Also, the session having taken place 11pm after the conference dinner and people drinking beer during the session may have had an effect on the style of argumentation that took place...

Again, I had a great time. I didn't attend as many sessions as last year but the conversations I had in the corridors more than made up for it. And it's always nice to connect with friends you haven't seen in a while--and to make new friends to learn from and share experiences with. As a matter of fact, I'll write down a note to self for ramping up some collaboration with our beloved neighbours in Sweden. It's only a ferry ride away from Helsinki but I've only met members of the Swedish Agile community in conferences like this one.

And, of course, the Exoftware guys are always a fun bunch to go out with. Here's a photo from the early morning brunch at the pier. We managed to attract some locals to join the fun as well...

You may have seen them already but there's a bunch of "official" photos online taken by Hubert Baumeister and Patricia Figueira. Also, you can find some random images by searching for "xp2006" in Flickr. Plus, Tom will sooner or later make his photos available for purchase on PopppsPhoto as usual.

I just browsed through some of the Rails Day 2006 applications for which there's a live demo available. Most of the applications were nothing special but one of them really got my (proverbial) vote right away:

Pingup solves a simple problem, which any geek with a little scripting mojo can solve using existing tools. Pingup just makes solving the problem a lot easier.

I've said this before but perhaps the most important thing about working at Reaktor is the people you get to work with. As an example of the kind of devotion to the profession, here's a photo I just snapped of a book that a coworker had ordered.

Yes, you're looking at a COBOL book. And we're mostly a Java shop with exactly zero COBOL projects (although some of our finance industry clients are still running large parts of their business on mainframes). With this in mind, I can only admire one's desire to learn new things when I see someone picking up a COBOL book purely out of interest.

Something about Skip Angel's blog post about business killers and killer leaders got me thinking about how different people exhibit different behavior in stress situations, even though they have just agreed about the "ideal" behavior outside of the situation.

We've all worked once in a company with The Process. The Process was what people were taught on their very first day into the job and The Process was what every single project plan depicted with perhaps a slight variance in exact wording. And I wouldn't be surprised if you remember that nobody in that company actually followed The Process.

Intelligent people suck at following a process that they don't value. And it's not just processes. Recommended practices, monthly instructions from a distant part of the organization, a new tool that nobody asked for. Some of the resistance is likely due to the Not Invented Here syndrome but some of it is warranted.

And we all know this. It's not interesting. At least not as interesting as some other phenomena that can be observed every day in the corporate IT world that we all love so much.

Unfortunately, people neglect practices they were supposed to believe in. For example, many Scrum teams start out by defining what "Done" means, agree on the use of practices such as pair programming, test-driven development, automated acceptance tests, and so forth. But when push comes to shove, few of these practices are really executed by the team as a whole.

Why? Why do people decide to not follow practices they've committed to following just a couple of weeks, maybe only a couple of hours earlier? Because they hadn't really committed? Because they were holding their fingers crossed while they vaguely nodded during decision making? Because they stood silent and nobody noticed that their silence might be a sign of disagreement with what the majority was rushing ahead with?

Discipline is a powerful trait for a software developer. It's discipline that keeps us on the "righteous path" and from following the dark road of little white lies and tiny little compromises that we'll "make up for in the next iteration." Discipline also becomes a lot easier to achieve when the discipline is towards something you believe is good.

Discipline isn't just for software developers, however. Let's go back to the kick-off meeting where the team wrote up their rules and gained commitment and buy-in. Let's go back to that one team member who didn't say much in the meeting but also didn't object to what the team was about to decide. Let's assume that that person didn't buy in and therefore didn't commit to what the rest of the team was going for. Who's to blame when it turns out that that one person isn't really following the team's decisions? Should that person be disciplined enough to suck it up and follow the pack?

To a degree, yes. It is a team member's responsibility to speak up rather than stay quiet and create misinformation about the team's commitment to certain things. It's not wholly that one person's fault, however, when this kind of a thing happens. Bad things rarely happen because of one person alone.

What strikes me as a more serious problem than a couple of developers lacking the discipline their colleagues exhibit is when the process facilitator--be it an XP coach or a Scrum Master--lacks the discipline to do his job. I've seen and heard of plenty of cases where the process facilitator is anything but. Where the process facilitator is just a project administrator (we used to refer to this role as "project manager").

The best Scrum Masters I've seen are developers themselves or have been true craftsman developers before. Another demographic group I've seen do a good job at being Scrum Master or process facilitator are people with an eye for peopleware. On average, and in my experience, these type of people fare much better in their job than the ex-project manager turned to Scrum Master by two days of training and a secret audible handshake. These Scrum Masters are good at what they do because they care and because they believe. They've seen first hand what discipline can accomplish and what kind of a disaster the lack of it can create. They've seen first hand what kind of a deadlock can people issues create and how to solve them.

Many project managers simply seem to be missing some fundamental understanding of the kind of issues they're supposed to be helping the team to conquer. Or they're too unsure about themselves to do something about it. Lacking the discipline to do what they know is the right thing to do.

Discipline is core to the success of agile software development and to software development in general.

If you're a Scrum Master or a process facilitator with some other name, stop for a moment to think back at how you've done your job recently. Think about situations where you've smelled something burning but decided to not look for the fire. Think about occasions where you could've helped the team understand their problem better by pushing back and digging for the root causes instead of caving in immediately. Your job is not to make friends. Your job is to help the team live up to their full potential.