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."
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.
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.
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."
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.