Interview James Coplien

Jim “Cope” Coplien is the inventor of Organizational Patterns and author of several books on the subject. Cope currently works as a consultant and is often asked to assist with organizational improvements. Cope is a frequent speaker at conferences and a reoccurring favorite at Øredev.
He is a man with strong opinions and I was curious about his views on introducing Scrum and how he works with problematic organizations.

What is required of an organization to be Scrum-ready and be able to reach hyper-productivity? What is required to start with Scrum?
– This is something I’ve talked a lot to Jeff Sutherland about. Jeff would focus on some of the practices and the technical infrastructure. That is something engineers listen to. Like automated checkin testing: a checkin should only be accepted if a test passes, otherwise it should be rejected. You cannot run Scrum without that. Jeff has also said that you will never run effective software development within Scrum without upfront architecture.

There are also the standard things: you have a product owner, the product owner is present and updates the backlog. On top of that I would like to emphasize that Scrum won’t give you excellence. When people start going into Scrum I always say “Wow are you going to make trouble”. But of course they’re not causing problems. What they are doing is surfacing problems that are already there.

To run Scrum you need connection with the customer. Scrum will not give you that, only make it obvious that you don’t have it. You also need some degree of unity of purpose: the team being a team. Scrum will not make a team into a team, only make it obvious that they are not working as a team. Some of the things people feel they should be getting from Scrum, such as a team and better customer communication, are actually preconditions to Scrum. What Scrum gives you is predictability.

Jim “Cope” Coplien

You have said that Scrum can be described with organizational patterns. Is it a good idea to start with the patterns before going for a full Scrum? What kind of benefits will the separate patterns give a new Scrum team?
– I think it depends on the individual teams. If it is a small, hungry and fairly young at heart team there is a kind of hipness to Scrum that sets a wonderful rallying point. Jeff would say “go to Scrum overnight”. I don’t know if I would be quite that bold. You probably should do things in pieces. Start with a product backlog, then a product owner, then sprints and so on. You should do it incrementally.

In a large and trenched organization you really benefit from the organizational patterns approach to Scrum because the improvement is incremental and it reduces risks. In large and trenched organizations you want to manage risk very carefully. In a young organization, that is small and isolated, you are going to find a way to recover anyhow. But in a large system you need to be attentive to risks, and that’s where patterns really shine. Some of those things are not Scrum, they are preconditions to Scrum.

Is there not a risk that if you do things incrementally, you will never get to the actual Scrum?
– So who cares? The goal is not to do Scrum. The goal is to repeatedly deliver value to your stakeholders: your users, customers and employees. You might be following the practices but not delivering value to your customers. Then you are missing what it is all about. It is not to do Scrum, to do XP, to be part of a club or to follow a religion. It is about expecting and adapting within some framework that makes sense. With that said Scrum is a great starting point. For some teams XP or Crystal Clear is a good starting point. For more heavy weight agile things DSDM is going to be a great starting point. Once you get to the starting point and show that you can do the disciplines, you will evolve.

I have always thought of Scrum as being something that has to come from a grassroot level, that the developers have to drive Scrum forward. How do you introduce Scrum to an organization that has been fed with it from the top of the organization?
– There’s the ideal and there’s the pragmatics. Before either of those there are some principles in organizational change. It’s going to be very difficult to make any change if management is against it. You need at least the tacit support of upper management. One of the things I say is that managers can’t make substantial improvement in an organization, they can only prevent them. You also need buy-in from the troops. This top-down thing is falling into some challenges. I think you need both and I would prefer to have strong elements of self-organization. This gets into the principles. By the time you get to that level, the question of bottom-up vs. top-down does not make any sense. There is no bottom or top. It’s potentially one level. To me that is the idea.

Lately I have been talking to Jeff Sutherland quite a bit and I’ve been understanding Scrum much better. I am finding out more and more what the history is about and they say some weird things. One of the things in the Toyota-way approach is that it’s not really worthwhile to go in and just have self-organizing teams. So instead you have these things called cells. You get people together as close as possible so you don’t stockpile parts to move them down the assembly line. You just move them over the table. You are only working on one part at a time and you do not stockpile. This is a lean principle, just in time, no inventory. To make that work you need continuous process improvement, and everybody is a process engineer. You need hands-on involvement from managers.

If there is anything wrong in the plant management does not get a report up the line. They come down to the factory floor and become materially involved. And they do this on a daily basis. They can look at status boards on the factory floor. At any given time they can tell what the inventory status is. It is very visual. It is like constant feedback loops. It is important that upper management receives this feedback.

Jeff is really big on having the entire company involved in the Scrum framework and the Scrum value system. He would say that everybody is part of some Scrum. Management is part of their Scrum, let us call it a meta scrum. Teams are doing things in Scrum, and then you have a Scrum of Scrums that gets them together. In Jeff’s model you basically have a two level structure.

The point is not that they’re going through the framework and following a process, but that there is a company- wide sense of very close communication and continuous process improvement. That is neither top-down or bottom-up. Maybe it is a steady state result of one or the other, but by the time you get to that point, agile permeates every corner of the enterprise. The problem with bottom-up is that you will end up with a couple of teams that run Scrum, and a couple that don’t.

Management will tacitly support it with no real vision of changing the company. You may be able to get a 30-35 % improvement. We have to go beyond bottom-up vs. top-down thinking and realize there’s a whole enterprise. Now you are really going to see the benefits and being able to transform the way you do development, and get these hyper-productive teams. They are getting a factor of 10 or 100. That is exciting.

Are managers needed in self-organizing teams and what are their roles?
– I have an anecdote related to this. I had a client who had a whole bunch of project managers. They were all yuppies, enthusiastic about agile. They said they would make their team run agile. I told them that it is not about telling them what to do, it is about self-organization. They said “I’m going to self-organize my team”. If you look at the Scrum framework, the job of managers is to remove impediments. If the team cannot solve the problem themselves they give it to the ScrumMaster. If the ScrumMaster cannot solve it he takes it to management. That is one very important role of management. The ScrumMaster is being a servant leader.

Finding how he or she can move the team forward. Management have the same role but they have bigger hammers. If you look at the management’s training or wishes, they like working with people and growing people. To some degree ScrumMasters can do that but their main focus is getting products out of the team. Management has a more strategic view: to get funding and send people to conferences and training.

The ScrumMaster has a lot of responsibilities on a day-to-day basis. Sometimes conflicts will escalate to a situation where you need to bring in management. So it is a kind of leadership. But what exactly a manager does differs from culture to culture. I do not think we need a standard Scrum manager. I think individual cultures will have different roles for managers. Will they do the hiring and firing, or will the teams do that? Who does salary administration? Does the team divide a pile of money themselves, or does the manager give out rewards based on their involvement in programs inside the company? I strongly feel there’s a place for managers in a Scrum context. This is a place where Scrum doesn’t go. That said, there is no place for project managers.

Let’s say you are called in as a consultant by upper management. You enter a problematic organization. What would be the first thing you do?
– The first thing would be to listen and to find out what the problem really is. I have some skills, both technical and organizational, but I’m not a personal coach. I would probably take someone along with that kind of skillset and have a team of two or three people to just sit and listen. The next step would be to say that we really need to get the whole organization involved: let us sit down and do an analysis. There are a lot of ways this could go. As an external consultant you may find out that the problem with the corporation is that a higher manager is an alcoholic or some other single point of failure. Then you do what you need to do. There are a couple of organizations where I have gone and done exactly this. In fact it was management who called me in. It was the CTO. The old CTO had just been fired. The new CTO’s company had gone under so he was looking for a job. The company hired him in hopes he would clean up the mess and fire all the stupid developers and replace them with his old employees. He was smarter than that. He saw these organizational patterns, and he called me. What we did was we got everybody together on the engineering team, the whole engineering organization of about 50 people, in one room and we did a roleplay. This was the first time the engineering organization understood what they were doing. They where astounded. That is what I would do!

Again it is an interest of the Scrum principles of honesty, openness and visibility. Let’s make things visible, let us bring it in front of everyone. Let us be inclusive so that we get everyone’s perspective. Then we are in a position to do something. Also, in the interest of Scrum, I will not tell them what to do. I can not tell them what to do to as a consultant. I can suggest analogies that has worked in other companies in the past. I want to make models, and show them models of themselves. Given these models what do you think of yourselves? What do you think of these models of yourself? We make these social network models. They are usually very telling. It never ceases to amaze me.

The best story I have about this is a company I used to work with that was called Project Silver Bullet. I was invited to study them. I did my exercise, I made models and I handed them the models the next day. I delivered them to the manager because she was my client. She was chocked and angry. She said “who told you this”. I said “we just did a roleplay with your people, and I made models”. She said: “No, you were only there for four hours. Who told you this. Who’s trying to destroy me?” The model was so good she actually felt threatened by it. So they see themselves and they can see the problems right away. The data all comes from them, and I put them into this tool that makes three dimensional scaling of the data, and shows them what communication structure is. This is very telling.

You have been part of many different discussions at Øredev; everything from DDD to Agile. You have written several books and your webpage states that your interests are collecting carpets, Questing and genealogy. You seem to be a man with many interests and many opinions. If we turn the tables, what do you think would be a good question that you would like to have published in an interview like this?
– There are several actually. One is of the kind “what do you want to be when you grow up?” That is one of my standard questions. But a really good one is: “If I could make a lasting impression on the world, a lasting change. Without ever being credited or recognized for it. Or if I could have a broad change in my lifetime and be credited for it, but it doesn’t persist after my death. Which do I choose?”

And the answer?
– I’m in this to make the world a better place for everybody. At the Øredev opening dinner Michael Tiberg had me stand up and said “Cope helped connect me to a lot of you! And that’s why you are here”. I see myself as a yenta. It’s a yiddish word that means matchmaker. I connect people together. Part of it are the connections themselves. It’s wonderful to watch people come together. It’s wonderful to come together with people who have different opinions. Like King David said: “iron sharpens iron”. In the long term these connections will cause the kind of feedback that makes it possible for the world to become a better place.

I choose being a leader as a person rather than creating this leadership role. A mantle that is going to be handed off, from me to another person and then to another and then passed around very rapidly. The everyday play and game of doing what we do in our profession is fun. That is what is going to make the world a better place. I do not know about today, but in the long term. That is a lot more satisfying to me.

Leave a Reply

Close Menu