Jon Kern spoke at our company
Topic: Mindset and culture
Recently, our company was honored by a visit from one of the authors of the Agile Manifesto, Jon Kern. It was a pleasure for me to connect a face with the name, having interacted with him from time to time online.

We've been building an agile practice in-house for about three years now, and we have an agile development group with about 70 members in all, of whom perhaps 12 to 15 actually understand how to apply agile development practices (that's down a bit in the wake of an unfortunate management turnover a few months back; another story). Jon's audience came from the larger IT organization that has not been involved with agile projects to date. With some exceptions, the audience's background in agile concepts ranged from a high of blithe ignorance to a low of seething hostility (in the latter case, probably for familiar reasons).

In two separate sessions, Jon addressed mid-level and project managers (and a few people in other roles) from our IT organization to give them an overview of the agile approach. I sat quietly in the back of the room through both sessions. That behavior may seem uncharacteristic of me, but I had a personal goal: I wanted to observe the managers' reactions to Jon's presentation. I must say it was an eye-opener.

Jon knows his stuff, and the content of his presentation was right on the mark. But I got the distinct impression he is unaccustomed to dealing with an ignorant, hostile audience. He answered their questions in a way that suggested he had overestimated their knowledge of the underlying concepts. His answers would have been appropriate for an audience that already had a general idea what agile methods were about, and who were looking for a little more information. Instead, he had an audience who would rather stick their fingers in their ears and chant "La, la, la!" than to be confronted with the possibility that Firesign Theatre had been right all along.

For instance, he explained that in the planning stages of a project there is an effort to elicit the business requirements (features) from the customer, while concurrently a technical team defines and validates the technical architecture for the solution. A manager in the audience had difficulty visualizing how it might be possible to validate a technical architecture empirically before an application had been deployed on that architecture. Jon explained that the details depended on the particular problem, and moved on to the next topic. But the level of the question was really more basic than that — the questioner did not realize it was possible to build a test harness to validate the -ilities of a technical architecture. He could only visualize after-the-fact testing, because that is the extent of his background. "Architecture," to him, means a document, and nothing more. That person left in a huff shortly thereafter.

In another case, a manager asked him how agile methods handled the situation when team members are working on multiple projects. Jon spoke to the case in which team members must be pulled off a project to deal with some high-priority incident, such as a critical production support problem; and the converse, when new team members are introduced to a team that is already functioning well together. These situations are sometimes unavoidable. After he went over the standard forming-storming-norming-performing thing, I followed up by explaining the question had to do with the fact that our (non-agile) developers are routinely assigned to several projects simultaneously. Jon looked as if he had been punched in the gut. My impression was that it surprised him to learn anyone, in this day and age, would intentionally assign a developer to two or more projects simultaneously, agile or not. Once he regained his composure, he debunked the old fallacy about multi-tasking and explained the effect of context-switching on productivity. Once again, Jon had overestimated the level of knowledge of the questioner.

There were many other indications that the audience was not prepared for this level of information. The idea that working software is more important than comprehensive documentation seemed to offend certain people. One man stormed out of the meeting as soon as he heard it. I assume his career has been largely concerned with the preparation of comprehensive documentation. Another manager simply did not see why it is unrealistic to lock in all three sides of the iron triangle. She calls this "control." Of course, we call it something else. She asked, How can you meet all your deadlines and stay within your budget without burning your people out? Jon shrugged and said, By dropping features. She stormed out of the room. (You know, just to keep it short, I'll summarize and say that six people, in all, stormed out of the room at various times, when they heard things they didn't like.) Others saw the notion of sustainable pace as an excuse to be lazy, and a slap in the face to those "dedicated professionals" who are willing to "go the extra mile" by sacrificing their health and their family relationships to join a death march on project after project after project.

<sigh>

Jon said nothing in his presentation that was any different from what any of us might say. It was all quite straightforward and clear. Many of the attendees have heard the same information from internal agilists, although they tend to be unreceptive due to a certain well-documented characteristic of human nature. I had hoped they would be more receptive to agile ideas if they heard them from an external source. It seems that was a bit optimistic.

Notwithstanding all that, some participants in the session were open to new ideas and very receptive to the benefits the agile approach delivers. I noticed the people who were most interested in agile methods were from the same group that had been especially positive and responsive during one of our internal agile workshops: The QA testing group.

The business managers at our company are on board with the approach. They or their peers have enjoyed the financial benefits directly. Most of our technical personnel are very interested in working in the agile way, because they can see the improvement in professional satisfaction over traditional methods. The QA group is excited about agile methods. They stand to benefit directly by solutions they know have been thoroughly tested before they are handed off for official QA testing. Resistance tends to come from entrenched, traditional IT managers, whose careers have been built on a foundation of heavyweight, high-ceremony processes.

Apart from underscoring the depth of the cultural barriers to agile adoption at our company, I found Jon's visit to be very valuable because of the interesting and practical conversations we had after the presentations, involving Jon and a colleague of his from Compuware who does agile team coaching and some of our internal agile practitioners. I hope to have an opportunity to work with him at some point.

Meanwhile, it seems most of the traditionally-minded mid-level IT folks at our company think agile development is for the birds. Too bad. If only they knew what we know: Birds can fly.

Our old-school colleagues can fly, too, but first they must come to realize they have wings. To help them discover their wings, we must be sensitive to their fears. Until then, they won't remove their fingers from their ears.