Skip to main content

Collaboration Work-Thru: Tapping the Knowledge of Your People

"We don't want to do Scrum." In the room were about 16 middle-managers. I had presented them Scrum on three different occasions, answered their questions, done Food, showed them (I thought) what Scrum would do for them, and applied (I thought) all the tools of the trade to motivate these people to do Scrum. The debate was endless. For every argument, there was always a "Yes, but..." to answer it. And all those 'buts' added up to 'No'.

What to do now? 'OK, if not Scrum, what do you want to do?' I reminded the assembled managers that the CEO would be back in the room in three hours, and he expected to find how how they want to proceed. I asked them to split into two groups. Each group should create a flip chart showing how they would like to organize product development. After two hours the groups came back together to review and understand each others proposals.

Three hours later the CEO came back, got a presentation on the two alternatives, and picked one of them. To everyone surprise, off they went! The middle management, with the support of their top management, implemented the new plan quickly and effectively. Two months later, the 'adaption' of the organization was mostly completed and 75% of the people involved thought the adaption was a good thing.

Rod Collins
I had stumbled upon a simple form of Rod Collins' 'Collaboration Work-Thru.' I met Rod at the Washington Radical Management Gathering last May where he worked the participants through his collaborative problem solving process. It was a 'Eureka!' Moment. This is a way to leverage the knowledge of the entire company, identify viable solutions (and potential impediments that need to be solved), gain commitment for the implementation while de-emphasizing the issues that people cannot yet agree on. It reminds me a lot of a heartbeat retrospective, except 1) it can be used to solve a wider range of problems and 2) it can be used with much larger groups (15 to 60 is a good number -- I've done variations with groups as small as 3 and Rod has worked with groups of up to 200 people!).

I plan to describe in more detail how to do a Collaboration Work-Thru in a future article, but first I'd like Rod to explain the Collaboration Work-Thru in his own words:

Peter Stevens: What problem did you face when you created the Collaboration Work-Thru?

Rod Collins: In 1997, when I was with the Blue Cross Blue Shield Federal Employee Program (FEP), I was asked to lead the operations of the business. FEP is a unique business arrangement in that it’s an alliance of the 39 independent Blue Cross Blue Shield companies to provide a seamless national health insurance product to 4.5 million federal employees and family members across the United States. At the time, FEP had endured two decades of low growth and low performance, having lost over 23 points in market share in the mid-1970’s and recovering only four points of that lost share over the 20 year period. Our challenge was to transform our business into high growth and high performance. And in order to meet that challenge, we recognized that we needed to change the way we conducted meetings when we brought the different companies together. We had to stop the endless and fruitless debates and find a way to find common ground and reach real closure on our most important business issues. The result is what is now known today as the Collaboration Work-Thru.

PS: What is the essence of a Collaboration Work-Thru?

RC: A Collaboration Work-Thru is a facilitated meeting process that enables a diverse group of individuals to quickly co-create a shared understanding and a clear consensus about the core elements of strategy and the key drivers of execution. The shared understanding assures that everyone is on the right page and the same page, which, in turn, creates a highly unusual level of collaboration and productivity that often results in a leap to extraordinary performance. The key to the success of Work-Thrus is that the process doesn’t allow for the usual debates that render the typical meeting so ineffective; instead the facilitated process engenders a discussion where differing ideas are brought together and integrated to identify creative or breakthrough solutions that work for all the members of the group.

PS: As a facilitator, how do you lead a Collaboration Work-Thru?

RC: The most important rule for facilitating a Collaboration Work-Thru is that the facilitator has to “check his or her own opinions at the door.” Even if asked, a facilitator never gives his or her opinion about the topic under discussion. The facilitator’s prime role is to guide the group in uncovering its own collective intelligence. Sometimes that means the facilitator recedes into the background if the group is making its own progress on an emerging solution. At other times, the facilitator may play a very active role in helping the group to probe a very difficult issue. But at no time does the facilitator attempt to move the group to a pre-determined outcome. The only outcome that matters is whatever solution emerges from the collective wisdom of the group.

PS: What place does debating have in a group’s discovery of its own collective knowledge?

RC: Debate has no place at all. In fact, if a debate begins to break out in a Collaboration Work-Thru, the facilitator will move the group into an appropriate exercise designed to foster a blending rather than a battle of ideas. Perhaps the most important lesson that I have personally learned over 15 years of facilitating Work-Thrus is that there is no such thing as a healthy debate. Debates are about who’s right and who’s wrong, and they tend to further reinforce the entrenched positions of widely disparate views, making the discovery of common ground virtually impossible. Advocates become riveted on taking control of the message so they can advance their own point of view, even if it means imposing their thinking on those who disagree. When one side is able to wrestle control and exert its will, there are always winners and losers. That’s because these verbal jousts often enable coercion by either the majority or the powerful. And in those instances where debates are able to bring together all sides, it’s usually because none of the parties could amass either the numbers or the power to get its way. So, both sides are forced by circumstances to agree to a compromise that represents nothing more than a least common denominator solution. It is often said that a good compromise is one in which everyone walks away unhappy. When debate is the primary process for bringing closure to different opinions, that’s usually the best that anyone can hope for. The problem with debates is that they are fundamentally about getting control, and thus, are poor processes for creating the large consensus necessary for discovering the best or the most innovative solutions.

PS: What kind of discussion is useful during a Collaboration Work-Thru?

RC: The best discussions happen in the small group exercises and in the facilitated large group discussions. Small groups promote greater participation by everyone in the group and provider greater opportunities for everyone’s voice to be heard. Well-facilitated large group discussions enable the group to effectively blend ideas, identify innovate solutions, and create a shared understanding in which all the participants have a stake. These dynamics are what make Collaboration Work-Thrus so powerful.

PS: What results can you expect from a Collaboration Work-Thru?

RC: You can expect to make a leap to extraordinary performance. The most untapped – and often the richest - resource in almost every organization is the collective knowledge of its own people. What organizations usually lack are the processes to aggregate and leverage this powerful resource. When we instituted the Collaboration Work-Thrus in FEP, we made an incredible leap to extraordinary performance. Within two years of incorporating Work-Thrus as the foundation for our management discipline, our operational performance indices made a huge jump from below threshold to record high performance levels, and over the ten-year period from 1997 – 2007, we steadily grew our market share by 16 points.

PS: Thank you Rod!

What happened to my managers who didn't want to do Scrum? Their ideal organization was organized around the different products that they develop. Each product group had an interdisciplinary team that was responsible for the entire product (e.g. marketing, sales, development), and had one person able to make decisions and responsible for dealing with the many other stakeholders. In short, it looked a lot like Scrum, and a few months later, they were training their first Scrum team.

And: Do these challenges resemble those your company? What to make it better?  Join us for the Zurich Gathering For C-Suite Leaders with Steve Denning and myself: Zurich, Sep 12, 2011


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…