Agile Zone is brought to you in partnership with:

Esther Derby helps create great work places where people can do their best work and make products their customers value. Not so very long ago, she made her living writing code. She's co-author of Behind Closed Doors Secrets of Great Management and Agile Retrospectives: Making Good Teams Great. You can read more of her thoughts on management, organization, teams, and agile methods at Esther is a DZone MVB and is not an employee of DZone and has posted 73 posts at DZone. You can read more from them at their website. View Full User Profile

Collaboration: more than facilitated meetings

  • submit to reddit

I’ve noticed something lately: when people write about collaboration, they discuss facilitated meetings or affinity grouping stickynotes. Well-run meetings that encourage participation and building consensus are certainly valuable. Grouping stickynotes can help people see common ideas. Yet, there’s  much more to collaboration than meetings and affinity grouping.

True collaborative assumes shared responsibility, shared ownership, and boosts creativity and learning.

Shared Responsibility

Collaborative teams focus on meeting a shared goal. Everyone’s skills and contributions are needed to reach that goal. In the end, they’ll either succeed or fail together. No one can say, “I got my tasks done. It’s your fault we didn’t meet our goal.”

Shared Ownership

A colleague told me a story about a co-worker, Bob, who was very protective of his code. If anyone else attempted to refactor or add to Bob’s code, he’d pitch a fit and remove all the changes. The result was that Bob was the only one who really knew the details of that module, and all features and fixes had to funnel through Bob. That may mean job security for Bob, but it’s risky for the business.

With a team goal, there’s no room for “my code” or “my tests.” The team shares ownership for its products. Individuals still may know a part of the system in more depth than others, but everyone has an understanding of the overall system, and that keeps the “truck-factor” risk low.

Cross-functional Learning

Shared goals, shared responsibility, and shared ownership drive cross-functional learning. Josh, a tester, applies the Java scripting skills he uses for test automation to write code for the GUI to help the team meet its goals. When the team members are worried about meeting their goals for test coverage, everyone pitches in to write automated unit tests. Team members learn from each other and expand their skills outside of their functional silos.

Process and Organizational Learning

When teams hold retrospectives, they share their perceptions about technical practices, work processes, and teamwork. Team members learn about the specific topic they are discussing and also about process analysis, process improvement, and influencing change.

Deciding Together

In business, we search for the “right” decision and often rely on experts to reach decisions for the rest of the group. While that’s the right approach some of the time, other times it’s more important to have decisions that the entire group will support and move forward. It’s a matter of looking for a good decision that the team will support rather than the “right” decision that doesn’t go anywhere.

Thinking and Solving Problems

Most people in the software field are really good at thinking and figuring out problems alone. Collaborative teams make use of each member’s insights and ideas to generate multiple solutions and then pick from the best. Looking at problems from different perspectives drives creative solutions. When I listen to teams that are starting to solve problems collaboratively, I hear comments such as “I never would have thought of that” and “Your comment sparked another idea.”

Creating Together

As with solving problems, many heads are often better than one when creating. Different people see different visions of what’s possible. Team members build on others’ ideas and challenge each other to fill gaps and weaknesses in solution candidates.

If better results, lowered risk, and increased learning aren’t enough, collaboration is also more fun.

I recently spoke to a domain expert, Sally, who was working with a software team to define features for the company’s main product. “After finishing customer research, I used to work on my own to create the perfect feature description,” she said. “Inevitably, I’d miss something or write an ambiguous description. Sometimes, I’d find out later that what I described was technically possible, but expensive. Those discussions always led to finger pointing. Now that the team and I are working on the features together, we catch those things early. They have good ideas that I wouldn’t have thought of, and we’re having fun.”

When teams collaborate, there’s less pressure on each individual to create the perfect part. Everyone realizes that she has the help and support of the rest of the team, and together they’ll create something far better than each could do on her own.

Collaboration Gone Bad

In spite of all these benefits, some people shy away from collaboration. Collaboration isn’t for everyone. Some people prefer to work alone and do their best work solo. Trying to force collaboration on people who aren’t interested is an exercise in futility (and not very collaborative). Some might have had a bad experience and are wary of trying collaboration again.

Just as collaboration isn’t a good fit for every person, collaboration isn’t a fit for all work. A work group responsible for installing and configuring servers was urged to work as a team and “be collaborative.” The group’s work was queued by tickets that specified the setup for each server. Each setup was a one-person job. While there were occasions when it made sense for people in the group to work together, most of the time there wasn’t a shared goal that required the effort of more than one person. Their manager decried the lack of collaboration—not seeing that the work didn’t require it—and the group members felt their boss was unfairly berating them.

A weak goal can undermine collaboration and lead to churn. One company convened a cross-functional team to “redesign the organization.” Each team member had a different idea of the scope and authority of the group. After several weeks of argument and aimless conversation, group members quietly drifted off to more focused and satisfying work. They never reached the point of collaborating because they didn’t have a shared idea of where they were going.

A team needs the right mix of skills to collaborate, too. If the group lacks key skills, they won’t be able to get the work done, no matter how well they get along and how creative and cooperative they are.

I’ve also seen collaborative teams struggle when one person didn’t follow through on commitments or persisted in working as a lone wolf. Teams that have the skills to do so may hold the person to account or coach her off the team. However, if the team isn’t ready to manage its membership and the coach or manager doesn’t step in, that could spell failure for the team.

Also, when the team members have a shared goal but are rewarded and rated as individuals, people have less incentive to cooperate. Depending on how people are rewarded in the company, they may be incented to compete with each other or even undercut each other. Some collaborative teams survive in organizations that stack rank and otherwise foster competition; these teams need some other motivator to overcome the factors that demotivate collaboration.

And collaboration requires specific skills—skills that we don’t normally learn in school. Dealing with conflict constructively, giving peer-to-peer feedback, and reaching sustainable agreements are all developmental areas for collaborative teams.

By all means, work to make meetings more effective by using participation and facilitation. But don’t forget the other parts of collaboration: shared responsibility and ownership, learning, creating, thinking, and deciding. When we hone our collaboration skills, all of us are smarter together than any of us is alone.

Published at DZone with permission of Esther Derby , author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)