I recently had the opportunity to hear Jim Coplien, one of my primary agile influences, speak at the Agile Development Practices Conference in Orlando, Florida.  I was so inspired by Cope’s presentation at the conference that I wanted to share some of his thoughts with the broader agile community.  The best way I could think of to do that is to let Cope speak for himself by way of an interview.  So, as the first in a series of my new Agile Minds interviews with today’s thought leaders in agile development, I’d like to present Jim Coplien.

For those of you who have not heard of Cope, he is a leading voice in the agile community, especially in the area of organizational development.  He is considered the father of Organizational Patterns, and is one of the founders of the Software Pattern discipline.  He is currently Second Mate (a curious and only indirectly meaningful title) at Gertrud & Cope in Denmark.  He is also the co-author of the widely acclaimed book Organizational Patterns of Agile Software Development.  Cope was also a founding member of the Hillside Group along with such visionaries as Kent Beck, Grady Brooch, Ward Cunningham, Ralph Johnson, Ken Auer, and Hal Hildebrand. So without further ado, here's part one of my interview with Cope.

Q. Cope, you have had the opportunity to work with many software development teams in your career.  Is there something special that seems to define or set apart high-performance agile teams?

A. I suppose I could offer the obvious and usual answers such as the presence of a good communication network; and, in fact, that is a key facet of software development I've scrutinized for most of my career. But if I look at the really fun teams and fun times, I think they all shared one rare quality: that they had a life. They got outside the office, traveled, went to the pub or restaurant together now and then, and did dangerous things like read books — even non-technical ones. That is, they countered the usual stereotype of being a nerd.

It's true: for many of them, their social circle wasn't much different than the people they worked with, but the connections and their nature varied from the office environment in subtle ways. Normal teams may have good interactions among themselves; in the exciting places there's more interaction across teams. Normal teams get together for a code jam; exceptional teams get together to support one of their colleagues at her art exhibition.

Q. The flip side of that coin might be equally important.  What would say are the common pitfalls that cause agile teams to fail or be ineffective?

A. I don't know how important this consideration actually is. There is a common misperception that goodness is the absence of badness. I don't think one aspires to excellence by avoiding pitfalls; I think you avoid pitfalls by aspiring to excellence. To just avoid errors is to muddle along. One corollary to this perspective is that there are ten times as many ways to do things wrong as to do things right, so it is more efficient to enumerate the desideratæ of a good team than to list things to avoid. Human minds — including the collective human mind of a team — crave such efficiency.

So if I were to list common "pitfalls," more of them are sins of omission rather than sins of commission. If you look at Jeff Sutherland's seven failure modes of Scrum, all of them are of this nature: lack of a product owner vision and product backlog; failure of the team to properly break down backlog items; the team is not properly sized; the ScrumMaster doesn't do his or her job; the team isn't skilled; the product isn't demonstrable; or failure to have adequate resources.

Q. It seems that many organizations focus on processes and process improvement in the hopes of fostering high-performance development teams.  However, many of these organizations seem to fail when process becomes too important.  Why do you think this is the case?

A. Again, it could be for many reasons. First, you don't want the absolute maximum of performance; it's about balance. I received a wonderful little mail from one of our CampScrum colleagues the other day, Anders Jutebrant Ivarsson of Ascom:

I [recently] picked up the latest issue of a popular Swedish sailing magazine. There was an interesting article about Roger Nilsson, a famous and experienced sailor that recently was a member of the crew at Orange II, a huge sailing catamaran that set the world record sailing around the world in approximately 50 days.

In the interview, Roger says:

"The most common failure other sailing crews do is that they focus on top-speed. When sailing around the world, that is not important. It will just wear out your crew and equipment. It is by achieving the highest average speed you become a winner!"

This reflects a well-known principle of good process improvement: things need to be in statistical control before you have a foundation for improvement. I advised one of my clients just yesterday to get their Scrum team velocities more consistent before trying any improvement (except those improvements aimed at consistent velocity: better enabling specifications to support estimation; shorter sprints; use of story points instead of absolute hours). Many people jump into Scrum thinking that it will make things better for them, and too many of them end up in disaster. The reason? Scrum is a disciplined process improvement program which itself should build on a stable foundation, and they lacked a stable foundation. Scrum won't give you a good connection to your customer; it depends on having one. Scrum won't give you good configuration management; it depends on having it already. The same is true for automated check-in tests, domain expertise in the team, and a couple dozen other things.

Another important factor here is that processes are a bi-product of a system's structure, so they are at best a second-order factor in organizational improvement. If you change process without changing structure, the structure will win out and the processes will backslide to where they were. It's like dieting: going on a diet is like a process change, a set of rules you apply for a specific partial ordering of tasks called meals. But to lose weight, you need a deeper life-style change: exercise, changes in self-esteem—and maybe dieting, too.

Q. A belief amongst many traditional organizations is that by creating things like mission statements, they somehow instill values into an organization.  Again, this seems to be a major point of failure in many organizations.  How do you believe successful organizations sustain positive values that percolate throughout the entire organization?

A. There is no universal answer. Just as each culture and each company has its own values, it has its own way of diffusing value change. And the techniques vary from value to value.

Trust is a key value in Agile development. Diana Larsen tells us that you build trust in others first by demonstrating trust in others: that at least will help them trust you, and helps people open up to be more trusting in general. This is particularly true when managers demonstrate trust in their employees. How? Sometimes, by giving them enough rope to hang themselves and then rejoicing in their success. It also comes from a culture of appreciation and a discipline of consistency. In all of these issues of appreciation, consistency, and giving up control, it starts with one random act of kindness. It's not something you can plan; I think most of it comes from examples. I think that's true of all values.

I know that there are management teams that believe that such leadership comes by creating posters of values or by giving employees wallet cards with the corporate values on them. People tend not to follow lists; they follow other people. A leader is someone who has followers, and followers arise from trust. In a healthy organization, everyone takes their share of some leadership role at some time as the organization explores and adjusts the value space. An organization that tries to "install" values from a list usually does so because of misguided well-meaning, but it can also telegraph management fear or an attempt by management to master plan things.

That's not to say that vision or positive values are unimportant. There is a proverb that says, "Where there is no vision, the people perish." The values must be lived, and they must be lived in a culture that sustains quality of work life for the employees while helping make the world a better place with quality products or services. A manager who lives great values has monumentally more impact than one who posts values on a plaque or in a mission statement.

The long lists of rules at Hogwarts in the latest Harry Potter movie come to mind.

Q. For organizations that are just starting out on their agile journey, what advice can you give in terms of cultural shifts they may need to make to support their agile teams?

A. Take it one step at a time. Evolution, not revolution. Some organizations get there by revolution, but it's rarely because anyone advised them to take a revolutionary approach. If the culture is ripe for a revolution, it will happen. In that sense revolutions are easy to make happen, though it's hard to quickly arrive at a positive result. It's evolution that takes hard work and discipline, which is why people look for a revolution instead. Patience is a virtue. (And I want it NOW!)

Stay tuned for the conclusion of my interview with Cope tomorrow...same place...pretty much same time.