Cooperative or Collaborative Agile Teams?

January 11, 2011

In choosing to go agile, as a manager you no doubt want at least a few benefits:
  1. To improve productivity.
  2. To improve productivity that is sustainable in the long term.
  3. To improve productivity in a way that is repeatable across your entire organization.
Of course, even these few explicit benefits have other implicit assumptions built in, like valuing people and wanting to retain them…

Scrum has become the Agile framework of choice, with the most recent VersionOne State of Agile Development Survey reporting that Scrum is used by 58 percent of agile teams. Scrum provides a sound, repeatable way for teams to coordinate and manage their work, solving the problem of what to use across your organization.

The next major question on the table is: What productivity do you need out of your team(s)? Lyssa Adkins, in her book Coaching Agile Teams, addresses this question by noting that the difference between cooperation and collaboration:

Cooperation yields the sum of the individual parts.

Collaboration yields a whole that is greater than the sum of the individual parts.

Cooperation using Scrum will still promote things like autonomy, sustainable development, and individual and team improvement. It will also discourage counter-productive practices like long e-mail “dialogs” that are designed, as Lyssa points out, “to place blame than to solve the issue at hand.” Getting people to interact and leverage each other’s complementary skills will increase the effectiveness of the team.

If your work is incremental in nature, involving either very small, well-defined modifications or bug-fixing, cooperation is all that you really need. Teams can benefit from the smooth work-in-process flow that a framework like Scrum provides, moving beyond teams that are simply a collection of individuals that are relying on others to coordinate their efforts.

Collaboration, on the other hand, needs the foundation of cooperation, but takes things up a notch. Innovation is necessary, and this requires greater overall involvement from all members of the team. In a Scrum context, this means that User Stories are not considered to be locked down, but a basis for a conversation.

A good User Story is crafted so that they type of user and what they want to achieve is understood, including the benefit(s) that the business expects as a result. The dialog between the users (or proxy such as a Product Owner) and the team enable what I’ve coined as emergent innovation.

It’s the dialog and building upon one another’s ideas – with everyone keeping their egos in check – that produce unexpected results. With great collaboration between qualified teammates, complex, difficult problems can turn into elegant, differentiating product features.

I advise caution at stopping at mere cooperation for most software development work – unless a maintenance team is being used to work solely on defect-fixing. Even small-sounding enhancements are a design activity where collaboration provides a benefit. It takes more time and effort to become a high-performing, collaborative team, but I believe in aspiring to bigger and better versus selling yourself short.