Agile teams are often told they need to collaborate more. Most teams probably do.
But some teams take that advice too far. Six people attend a meeting that only needed two. Every decision requires consensus. Team members feel they can’t act without checking with everyone else first.
That isn’t effective teamwork. It’s a lack of judgment disguised as collaboration.
Strong agile teamwork means collaborating on the right things, at the right level, with the right people. Team members share goals, problems, information, and responsibility. They still allow individuals and small groups to make decisions within their areas of expertise.
Here are seven rules I’ve found helpful for getting that balance right.
1. Share an Outcome, Not Just a Backlog
A backlog gives team members work to do. A shared outcome gives them a reason to work together.
When people see only their assigned items or tasks, they naturally optimize for finishing those assignments. When they understand the larger outcome, they can make better local decisions and notice when someone else’s work matters more than their own.
A good Sprint Goal helps, but only when the team uses it to guide decisions. A Sprint Goal displayed in a tool and ignored during the sprint won’t create teamwork.
I sometimes use the acronym SLAM, which originated at Pepsi, to describe the type of team we want: self-managing, lean, autonomous, and multidisciplinary.
A SLAM team can be given a meaningful challenge and trusted to determine the best way to solve it. The team will usually develop a better solution than the smartest individual could develop alone—and implement it more effectively—because the solution reflects multiple perspectives and the knowledge of the people doing the work.
That starts with giving the team a problem worth solving, not merely a list of assignments to complete.
2. Integrate Before the Work Feels Ready
One of the easiest ways to improve collaboration is to connect related work sooner.
On one video game project, a team designing weapons didn’t collaborate adequately with the team designing the game’s characters. When the work was finally brought together, the weapons were too big for the characters’ hands.
Fixing that mismatch required substantial rework and delayed the release.
No large coordination process was needed to prevent the problem. Informal conversations, early demonstrations, or integrating partially completed work would probably have exposed it while both designs were still easy to change.
Teams often postpone collaboration until their individual pieces feel finished. That’s exactly when collaboration becomes most expensive. Assumptions have hardened, people have become invested in their choices, and changing direction now means undoing completed work.
Show unfinished work. Integrate sooner. Ask for feedback while it can still help.
The broader Agile Collaboration guide includes more ways teams can shorten feedback loops and reduce costly handoffs.
3. Share Problems Before You Share Solutions
Sometimes a leader or technical specialist spends days defining a solution and then brings it to the team for “collaboration.”
The team may be invited to ask questions or adjust a few details, but the important choices have already been made.
People tend to accept a leader’s proposed solution as done—or nearly done. The leader is also more invested in that solution and may resist changes that would have been welcome earlier.
A better approach is to bring the team what needs to be accomplished and let them help shape the solution.
There is a gray area here. Sometimes a leader must specify part of how something will be implemented. There may be regulatory requirements, technology constraints, organizational standards, or commitments that the team can’t ignore.
The danger comes from treating preferences as constraints. Every unnecessary constraint shrinks the solution space and reduces the team’s opportunity to co-create the result.
Two warning signs are especially useful:
- Success is described primarily in implementation terms rather than as an outcome.
- Team members have stopped offering ideas.
When you give a team a constraint, explain why it exists. Then let them question it. If nobody can explain why a constraint is necessary, it may simply be a solution someone chose too early.
4. Use the Smallest Group That Can Make the Decision Well
Giving a problem to the whole team doesn’t mean the whole team has to discuss every part of the solution.
For high-level issues, sure, involve everyone. The team needs a shared understanding of the product, the users, the goal, and the important tradeoffs.
As the team moves into the details, smaller groups will usually be enough. Half the team—or even a third—may have all the knowledge needed to solve a particular problem.
Before inviting everyone into a decision, consider three questions:
- Impact: Will the decision materially affect other people’s work or the shared goal?
- Reversibility: Would a poor decision be expensive or difficult to undo?
- Expertise: Does making the decision well genuinely require all perspectives?
When impact is limited, the decision is easily reversed, and one person has the necessary expertise, let that person decide. They can keep others informed without asking everyone for permission.
Broader participation makes sense when a decision crosses specialties, changes the product direction, or will be costly to reverse.
5. Let Leadership Move Around
On a strong team, leadership moves constantly, transparently, and without fanfare.
A developer may lead a technical conversation. A tester may lead when the team is assessing risk. A Product Owner may lead a product decision. Someone who recognizes a process problem may guide the team through addressing it.
When the subject changes, leadership may shift to someone else.
Tom DeMarco and Timothy Lister described this in Peopleware: the best teams allow different people to provide occasional leadership in the areas where they have particular strengths.
This type of leadership doesn’t require a new title or an announcement. The most appropriate person simply steps forward, and the others recognize that person’s expertise.
A warning sign is that every important conversation waits for the same manager, architect, or senior developer. That person has become a bottleneck, and the team has learned to depend on authority rather than judgment.
Self-management doesn’t eliminate leadership. It creates more of it, supplied by different people at different moments. The Self-Managing Agile Teams guide explores the boundaries and authority that make this possible.
6. Disagree Fully, Then Support the Decision
Good teams don’t need everyone to think alike.
Different specialties, experiences, and personalities should produce disagreement. If they never do, the team may be avoiding difficult subjects or deferring too quickly to its most influential member.
Team members should explain their reasoning, expose assumptions, and argue for the approach they believe is best. The discussion should remain about the work and the shared outcome, not the people advocating for different choices.
But disagreement can’t continue indefinitely.
After the relevant perspectives have been heard, the person or group with the appropriate decision authority should decide. Everyone then supports that decision unless new evidence gives the team a reason to reconsider it.
When uncertainty makes choosing difficult, run a small experiment. Often the team doesn’t need a longer debate; it needs information.
Trust doesn’t require agreement. It means I can disagree with your idea, respect your judgment, and help make the eventual decision succeed.
7. Specialize in Skills, Not Responsibility
Specialists are valuable. Specialized responsibility for the team’s result is dangerous.
One of the worst things you can hear on a team is, “My part is done.”
I worked with a team that finished a sprint without completing everything it had planned. The team referred to it as a “failed sprint,” which may have been overly harsh, but that was the language they used.
One team member strongly objected. He said, “You may have failed. I didn’t. I finished everything I said I would.”
That attitude is poisonous to teamwork.
His individual tasks may have been complete, but the team’s work wasn’t. Once he finished his tasks, he could have asked, “Can anybody use help?” Better still, he could have looked at the sprint backlog and Sprint Goal, found work he could contribute to, and helped move it toward completion.
Even if he lacked the skills to help directly, his mindset was the larger problem. He saw the sprint as a collection of individual promises rather than a shared effort.
The same problem appears when work piles up between specialties, defects bounce from one person to another, or team members start something new while existing work is waiting for help.
Strong teams contain specialists, but those specialists share responsibility for the outcome. Quality doesn’t belong only to testers. Architecture doesn’t belong only to architects. The backlog doesn’t belong only to the Product Owner.
As the Shared Ownership guide explains, individual accountabilities remain important. They simply don’t become walls that prevent the team from finishing together.
Collaboration Should Help Work Move
Most teams need more collaboration, not less. They need to share problems earlier, integrate work sooner, and pay more attention to the team’s result.
But participation has diminishing returns. The whole team needs to understand the challenge without participating in every detailed decision. Individuals need autonomy without becoming isolated. Specialists need room to apply their expertise without retreating behind their roles.
A useful question to take into your next sprint is:
What does the whole team need to understand—and who is the smallest group that can take the next decision from there?
Agile Teams And Collaboration
FeaturedAgile teams do more than divide work among specialists. They collaborate around shared goals, learn together, and take responsibility for finishing valuable work.
Agile Collaboration
FeaturedAgile collaboration is the way a team works together to finish valuable work, learn quickly, and adapt as it goes. It is more than good communication.
Shared Ownership
FeaturedShared ownership helps agile teams move from “my work” to “our work. ” On a strong agile team, people still bring different skills, roles, and accountabilities.
Effective Agile Teams
Effective agile teams are designed to finish valuable work together. A useful way to remember the characteristics of effective agile teams is **SLAM**: self-managing, lean, autonomous, and multidisciplinary.
Self Managing Agile Teams
Self-managing agile teams decide how to accomplish their goals. They do not wait for a manager to assign every task, solve every problem, or approve every ordinary work decision.
Why Your Scrum Team Still Works Like Individuals
Learn how handoffs, individual task ownership, and status-report daily scrums keep Scrum teams from collaborating—and what to change next sprint.