Cooperation & Collaboration in Scrum

April 22, 2014

http://www.scrumexpert.com/knowledge/cooperation-collaboration-in-scrum/

The first value of the Agile Manifesto is” Individuals and interactions over processes and tools”. Its third value

is “Customer collaboration over contract negotiation”. In his book “Agile Analytics”, Ken Collier discusses the

concepts of cooperation and collaboration in Agile.

Cooperation between group members involves the smooth transfer of work in progress, work products, and

information from one member to another. The team has a shared commitment to a common outcome, and

individuals coordinate their activities in ways that support other group members. In a cooperative team,

members interact in an egoless manner and understand their individual roles as they relate to the group’s

objectives.

Collaboration elevates groups beyond cooperation, adding an essential ingredient for emergent, innovative, and

creative thinking. With cooperation, the properties of the group’s output can be traced back to individuals,

whereas with collaboration, the properties of group output exceed anything that could have been achieved

individually. When a team is truly collaborating, its members build on top of each other’s ideas, and the

collective result is beyond what any one member could have envisioned. Cooperation is a prerequisite to

collaboration.

Source: “Agile Analytics : a value-driven approach to business intelligence and data warehousing “,

Ken Collier, Addison-Wesley

Transitioning from individual responsibility to collective ownership of the

product is one of the key challenges of Agile approaches like Scrum. In his

book, Ken Collier cites Lyssa Adkins. In her book “Coaching Agile

Teams” she wrote “group cooperation yields the sum of its parts, while

collaboration yields a sum that is greater than its parts”.

The interaction status has to be assessed and improved both internally in the

Scrum development team and in its relationships with other stakeholders like

the customers. Trust is an essential part of achieving good collaboration and creating a high level of trust

between all stakeholders should be the main goal of the ScrumMasters and the managers of Agile teams. We

should however recognize that this requires time and the delivery of meaningful results from the team and

valuable feedback from the customers. The transition period could be even longer if you are just adopting Agile

and you were formerly organized in “silos” where all functions where working separately.

Further reading on cooperation and collaboration

in Scrum:

Cooperative or Collaborative Agile Teams?

Defining and Achieving True Collaboration

Chaos, Cooperation and Collaboration

Teamwork in Agile

Opening Communication within a Scrum Team

Related Content:

Agile Communication

3 Simple Tools for Successful Scrum Meetings

Organizational Debt

Further reading on cooperation and collaboration in Scrum

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

Defining and Achieving True Collaboration

Agile Practitioner, 1.15.2013

by Alan Dayley

The word collaboration is everywhere these days. Talks, meetings, conversations are almost sure to include it.

Managers praise the powers of collaboration. People cite “collaborative efforts” and “collaboration is key.” This

is all fine, except, I don’t think many of those speaking know what collaboration really means. In fact, I know

from personal experience that many things later labeled as “a collaboration” were not collaborative at all.

Some of the problem is that the word collaboration is often used as a synonym for three other words that start

with C: Communication, coordination, and cooperation. There is a difference between these words, one which

most people don’t know or don’t see as important. It is important to understand what collaboration really

means. Especially if you aspire to achieve it!

Let me illustrate the differences between these terms. I’ll use the Cambridge Dictionary of American English

and my own understandings. Then we can see why collaboration is both highly desirable and hard to achieve.

Communication

Dictionary definition: the process by which messages or

information is sent from one place or person

to another

Communication is the transmission of information from one person

or group to another person or group. Communication is key to any

endeavor, of course. The receiver determines the success of the

communication. And, good communication is two way, meaning

the sender and receiver should take action to confirm that the

information was understood.

Coordination

Dictionary definition: the activity of organizing separate things so

that they work together

Many times in doing work, the piece that I created needs to work

well with the piece you created. The work of integrating these

separate efforts is coordination. It may be that one part or the other

does not make a useful result, so coordination of these pieces is

required. Or the parts might be valuable on their own but are more

valuable together.

Cooperation

Dictionary definition: to act or work together for a shared purpose, or

to help willingly when asked

Cooperation is the act of helping someone else achieve his or her

goal. And, probably sooner or later the same person will help achieve

your goal. The plus here is that some teamwork is involved, though

we might not be always on the same team.

Collaboration

Dictionary definition: to work together or with someone else for a

special purpose

Two or more people work together for a single purpose. They work

together, side by side, to accomplish the shared goal. Some

elements of communication, coordination, and cooperation will

exist as parts of a collaboration. These elements come and go

naturally as the pair or team are focused on creation, not

information.

Examples

Communication – A slide presentation. The architect writes a design document, presents and posts it.

The business analyst sends an email.

Coordination – The developer submits code for testing. The UX designer checks that the developer

implemented the elements correctly. One team times their release to match the release of another team.

Cooperation – The product owner adjusts some story priority to meet the dependency of another team.

One developer implements some code because another developer got called away. The client accepts

that a story be dropped so a different can be developed instead.

Collaboration – Pair programming. The developer and tester write tests and code together. An energetic

discussion at an iteration review leads to a paper prototype of an exciting new feature.

Flowing

Collaboration comes when the participants are using data to create something new, not just transmitting or

sharing data. Communication, coordination, and cooperation happen in rapid succession, feeding the creative

stream. The diversity of experience, skills, and knowledge is focused all at once on a single effort.

You’ve probably experienced collaboration. It was that time when everyone is was focused, ignoring the clock,

emails, and everything else. When suddenly a result was created with relief and elation. When you and your

collaborators looked back and said “What just happened? How did we do that?” and you weren’t able to

describe how you got to the result.

Have you ever experienced the psychological state of flow? Collaboration is that but as a group, as a real team!

Power of Agile

A great deal of the power from Agile practices is the nurturing of collaborative opportunities. All those “silly”

exercises, using sticky notes, standing up, estimating together, colocation, and so on exist to foster

collaboration. They are intended to create the environments and actions that produce collaboration more often,

so that enjoyable work and better results happen more often. Such a way of working results far more often in

innovative solutions, in things that none of the participants could have thought of by themselves. Collaboration

is how you get the whole team to be more than the sum of the individuals.

Collaboration is hard to achieve because it takes time and focus. Time to become comfortable with your skills,

your collaborator’s skills and the problem you are trying to solve. Time to work into a focused state. Focus on

shared goals and agreed outcomes instead of the work method. Things like multitasking, work structured to be

done by individuals, highly controlled environments, and fear are just some of the things that push a team back

into communication, coordination, and cooperation instead of collaboration.

How many of us pay homage to the idea of collaboration, but don’t take a hard look at how collaborative our

actual systems for fulfillment really are? Do team members have shared deliverables? Do you structure the

work environment so that collaboration is encouraged? What must change in your work so that real

collaboration happens more often?

Chaos, Cooperation and Collaboration

by Thierry Ventadour (Article added on 21 October 2012)

The path from Chaotic organization, to Cooperative, then innovative organization

1+1<2: The first level of a just created group or organization is the Chaotic level. Everyone in the group does its

best to reach an unshared, uncommon goal. This type of organization creates lots of waste, as mechanisms to

work together are not defined.

1+1=2: The next step is to organize these mechanisms: who does what, what are the information exchanged

between people or sub-groups. People cooperate to reach a common objective: provide a well-defined service or

product. This is the Cooperation step.

1+1>2: Then, the group may need to provide something new, unusual, and different from what is usually

provided by competitors: they have to collaborate to imagine new concepts, new functionalities, this is the

Collaboration step.

Cooperative organization is well suited for stable, well known and already efficient process. A typical

implementation is the Waterfall development process: each step is under the responsibility of one group who

provides a deliverable. This deliverable is then used as an input for the next step, potentially under the

responsibility of another group. These groups collaborate. If you need to improve this organization, you need to

set up a separate group that will be in charge of improving the process: typically a process improvement project.

Cooperative organizations are badly suited to improving themselves.

Collaborative organization is required when you do not have a suitable defined process (and you want to avoid

chaos). People need to work together to allow innovative ideas to emerge. This is the objective of Agile

methodologies. Scrum retrospectives performed by a self-organized team are a typical means to create

innovative ideas. Improvement is a central on-board activity of Agile groups.

A typical example are off-shore testing groups, set-up in low cost countries with the objective of reducing cost.

This objective (cost reduction) often differs from the development team objective which is to deliver

functionalities fast which will fulfill users’ needs (reduced time cycle, good quality). This cooperative

organization often creates tensions between these two groups as their objectives are not aligned. A new way of

working together has to be found. Only teams’ members (from both groups) can define these new efficient

practices, through a collaborative organization. The first step is to define common goals: it is the well-known

Agile team charter.

Is Cooperative organization a requisite step for Chaotic organization that want to deploy a Collaborative

organization through Agile methodologies? The answer has to be “No” as it is a request from our customers. It

only means that the journey will be longer as these teams will have more to learn: An organization where

requirements management is lacking will have to be more rigorous in tracking these requirements, before being

able to work efficiently with its customers to improve requirements definitions.

Teamwork in Agile

Bal Mahale, CA Technologies, 16 February 2011

Several years ago, I worked for Cambridge Technology Partners (CTP), a consulting company that specialized

in Rapid Application Development (RAD). CTP’s hallmark was Rapid Solutions Workshop (RSW), in which

we would build a prototype of a real application in three weeks. Key to the success of the workshop was rapid

consensus-building between client, business, and technical teams, and extreme teamwork.

CTP mastered the art of teamwork so well that they were mentioned by Ed Yourdon in his book, Death March,

on how a company can manage death-march -- or, impossible -- projects through exceptional teamwork. Agile

Sprints remind me of the RSWs. Exceptional teamwork is critical to any team that wants to get results with

Agile.

How do people work together?

People work together in one of three modes; non-cooperation, cooperation or collaboration.

People sometimes find themselves in non-cooperation mode due to differences in opinions or a lack of

communication. This results in teams working against each other or doing redundant work. I have heard of

senior managers who cut staffing when the project falls short, claiming that the team’s large size is causing it to

operate in non-cooperation mode and reducing the number of members will change the dynamic and improve

teamwork.

People operate in cooperation mode when they divide the responsibilities and identify touch points (contract). In

mathematical terms this is similar to 1 + 1 = 2. It means they are doing what is expected of each of the roles, but

nothing beyond.

People work in collaboration mode when they build off each other’s strengths and knowledge to create

something that is exceptional and beyond their individual abilities. In mathematical terms this is similar to

1 + 1 > 2. This mode involves a lot of negotiating, challenging assumptions, and learning/building on each

other’s perspectives. Several of our competitors suffer from the same collaboration challenges, so by

collaborating we may gain a competitive advantage. At the basic level this could be as simple as dev and QA

collaborating to determine what and how to test, resulting in reduced testing effort and earlier discovery of

defects.

Thought leaders value collaboration so much that they often don’t want to call people working together without

collaboration a team, and instead prefer to just call them a group.

What makes collaboration so difficult?

We are a society that values freedom and democracy, which means we all have the freedom to do things our

own way. This approach gets us into the “throw things over the wall” mindset -- we complete our part (such as

requirements document or design document) per the agreed upon contract and let the person on the other end

proceed from there. This approach allows us to maintain our freedom and work in our own siloed environment

without interacting with anyone, avoiding any conflicts and the need to learn anything beyond our own skill set.

Toyota believes that this does not work even in an assembly line environment where there is a repeatable, well-

defined process. Collaboration can be hard because we need to patiently explain to others what we do and why,

while at the same time, remain open to criticism and be willing to change the way we do things. Similarly, we

need to take a keen interest in others and how they do their work, while keeping an eye out for improvement.

Other possible barriers to collaboration are the biases and hierarchies we have in our head, based on our

background and skillset. This can be an asset if we respect/value the diversity of opinions, or it can be a liability

if it prevents us from learning and respecting others that come from different backgrounds and skillsets. To

collaborate, we will need to suspend some of the biases and not only understand the viewpoint of others, but

build on it to create something exceptional.

How does Agile help with teamwork/collaboration?

Agile forces people from different backgrounds to work together on the Agile team. By creating a self-

managed, empowered Agile team, all barriers or departmental silos naturally go away.

Agile practices such as release planning, sprint planning, and standup meetings provide the time and space for

teams to collaborate and build relationships with each other. Daily standup meetings help teams identify

potential collaboration opportunities that they can then follow up on, while sprint and release planning provide

more structured and extended opportunities for collaboration.

Through retrospectives, teams periodically reflects on the collaboration experience and provide feedback to

each other to improve it. Teams also evaluate results from the sprint to determine if collaboration could produce

better results. The end of the sprint review, or the demo, gives a sense of accomplishment and meaning to the

team’s work, motivating the team and reinforcing the value of collaboration.

Teamwork is something that most people take for granted. When I observe Agile teams closely as a coach,

teamwork does not come easy at first. It’s especially difficult for people who have been working in siloed

environment for a long time, because there is a natural tendency to go back to the old way of doing things. It

gets better with every sprint, however.

It is a wonderful thing when developers, product managers, testers and writers build off each other to create

something unique and drastically simple. Any team can be collaborative, but it takes lot of motivation and effort

from everyone.

Opening Communication Within a Scrum Team During the Daily Meeting Mike Vizdos, www.implementingscrum.com

Introduction This article examines something called "The Daily Scrum Meeting" used by Scrum Teams on Agile Software

Development Projects around the world. Using some real-life stories and cartoons, you should walk away from

this with a better understanding of what not to do, what to do, and then how you can make changes if the first

team looks more like what your Scrum Team is doing today.

Before we start, I’d like to introduce you to the concept of a Chicken and Pig on a Scrum Project. I think this

comic strip will help you when thinking more about the context of this article.

Team X -- Scrum Meeting -- 8:38 AM Tuesday Morning The room for the Daily Scrum Meeting is the best-of-the-best conference room in their organization, containing

thousand dollar plus individual leather chairs around an imported teak wood conference table, with coffee and

donuts available. A state-of-the-art conference calling system in place.

The Daily Scrum is supposed to start at 8:30, and only 1/2 the team is there. Nobody bothered calling into the

conference bridge line. Of the Scrum Team Members who are there, one just rolled in from an all night party

smelling of smoke and cheap liquor. He is clearly hung over (and possibly still drunk). Again. Nobody on the

team seems surprised. People are chatting on their phones or thumb-typing into the crack berries.

No ScrumMaster is present. Instead of the Product Owner being in attendance, a Senior VP has decided to show

up, and so far she does not seem impressed. She is looking at her watch. And. Looking at someone to take

charge. Clearly in her mind this Scrum thing is not in control. She is planning on talking to the Product Owner

right after this meeting if she can find that committee of people.

The drunk team member rips out a large burp, and hangs his head over the back of the chair, moaning.

It is now 8:45. The team looks around the room at each other and decides the Daily Scrum meeting is over.

They spent their fifteen minutes in the conference room and all of the good donuts are gone anyway. That’s

what they expect a Scrum Team should be doing on a daily basis. All Scrum Team members leaving sighing in

relief an thinking, "We have real work to do, this is such a waste of my time."

All the team members head back to their cubicles in different parts of the campus, the drunk one heading to the

bathroom to pray to the Porcelain Princess. The Senior VP is standing there. In shock. Thinking, "Heads will

roll on this." E-mail wars begin going up and down the chain of command. There is no ScrumMaster in sight.

The Senior VP’s telephone starts ringing with a familiar tone from Jimmy Buffet. The lights go out and she

leaves the room very frustrated, thinking now is a good time to get HR to make sure they get a Project Manager

to take control of this ScrumMaster job they are clearly not doing today.

Team Y -- Scrum Meeting -- 8:38 AM Tuesday Morning The room for the Daily Scrum Meeting is the same room where the team completes their work on a daily basis

as a collocated team. Information radiators abound -- including a Story Board, a BurnDown Chart and Team

Norms.

T

he Scrum Team has been together for about four months, and know that the main reason for the Daily Scrum

Meeting is to keep it under fifteen minutes so that the team can get together and coordinate what has occurred

since the last meeting (normally yesterday!), what will happen today, and what impediments are slowing people

down.

They know it is not a daily status report to anyone. It is for the team.

Most of the Scrum Team members are there and the meeting started promptly at 8:30 AM. The ScrumMaster is

absent and the team is not concerned as they know the ScrumMaster is not a traditional Project Manager of past

waterfall projects they have worked in (before moving to more agile software development techniques).

They also know the ScrumMaster would not be here today, as a personal item came up with the family that

takes priority over any work they are doing. The team has a sense of a work-life balance and tries to hold each

other accountable to make sure this team norm is followed by everyone on the team.

A Quick Reflection Here are a few questions for you and your team to discuss. Pass this around to your team members -- including

both the Chickens and Pigs -- and decide what you as individual team members, the team as a whole, and the

entire organization wants to do next.

If you are using Scrum today, which team looks like yours today -- Team X or Team Y?

Why?

If you are looking a lot like Team X, what is stopping you from becoming more like Team Y?

List the reasons and discuss them. As a group.

If you are not using Scrum today and are thinking about using it, which team do you want to be more like --

right from the beginning?

This will not happen overnight and takes a patient and effective ScrumMaster to help.

Next Steps This article has given you a start regarding some of the tough conversations you have to discuss as a Scrum

Team.

Talk about it with your Scrum Master, Product Owner, and the rest of your Scrum Team Members.

Why do I consider this so valuable? Because without communication people will shut down and start making

assumptions.

And. As a member of a Scrum Team -- no matter what your role -- part of your job is to initiate these tough

conversations so that you can become a high performing team. If you do not take personal responsibility and

accountability, the rest of the organization around you will continue to try to push things back to the way they

used to be.

So what if I told you I have seen teams transform from the hypothetical "Team X" into "Team Y" if the

individuals, team members, and organizations supported this change.

You will always always always always (multiplied by infinity plus one) have a reason for not implementing a

change within your organization. Change that wording "Yes... But" to "Yes... And" with your team and see

what we mean by Scrum becoming the, "Art of the Possible."

They are in the process of building a high performing team, and their ScrumMaster has facilitated the team to

get through the forming, storming, and norming cycles of team development (as they learned about from a

model by Bruce Tuckman and some corny exercises along the way).

One of the team members walks in at 8:38, clearly late for the meeting. Without hesitation, the late Scrum Team

Member walks over to the corner with an extra large pickle jar, silently opens it, and starts chomping away. The

late team member joins the circle that has formed for the group this morning.

Everyone is standing up. Everyone in attendance is keeping focused on the three questions that should be

addressed by each person during this meeting:

What have I completed since yesterday?

What will I complete before our next Daily Scrum Meeting?

What are my impediments?

Nobody controls the meeting or takes notes and one can feel the respect level among the team members

speaking with the others.

One of the team members is having a hard time with a technical task, and knows this is not the time to dig down

into a solution -- this is what they do during the day as the team is collocated and working together toward a

common Sprint Goal. This team member brings it up as an impediment, and another team member agrees to

follow-up with them after the Daily Scrum Meeting in order to remove the impediment together. Someone

makes a note of it on the whiteboard listing out impediments and who is working on them, since they need to

keep track of this kind of stuff for compliance purposes.

One of the team members starts to talk about a party being planned for tonight after work. The rest of the team,

knowing that this is not part of what they should be discussing right now, reminds her of the three questions and

asks that she please focus on helping get this Daily Scrum Meeting completed. She passes.

Story cards during this meeting are moved from "Not Started" to "Work in Process" to "Done" as needed. The

feeling of "waterfall" projects is nowhere to be felt in this room; the team is focused on a very clear Sprint Goal

that delivers specific business value at the end of this Sprint.

At the end of the meeting one of the team members adds up the hours remaining for the tasks in the Sprint, and

updates the Burn Down Chart.

They all look at the Burn Down Chart and see if they are on track to complete the Sprint, and agree that all

looks well right now. They agree with the Product Owner -- who is present -- to make sure they keep in touch

during the day with the possible impediment mentioned earlier because they know they may have to de-scope a

story from the Sprint Backlog and put it back onto the Product Backlog for future prioritization. Their is no

sense of "us" versus "them" -- clearly this is one team working toward a specific goal who understand the larger

picture and business implications of what they are delivering.

Throughout this Daily Scrum Meeting, a Senior VP has been standing outside the circle the team has formed

around a small folding table with toys all over it, listening to what is happening -- real time. And. She has been

quiet throughout the meeting since she knows she is not a contributing team member (she was a little ticked

about being called a "Chicken" but now realizes the real difference between a Chicken and Pig as the metaphor

for this Scrum Team).

It is 8:44. The meeting is over in under the maximum of fifteen minutes. The team breaks out into pairs and

starts their daily work within their collocated room; they have a clear understanding of what needs to happen

today and is excited about working together towards a real business solution.

A Quick Reflection Here are a few questions for you and your team to discuss. Pass this around to your team members -- including

both the Chickens and Pigs -- and decide what you as individual team members, the team as a whole, and the

entire organization wants to do next.

If you are using Scrum today, which team looks like yours today -- Team X or Team Y?

Why?

If you are looking a lot like Team X, what is stopping you from becoming more like Team Y?

List the reasons and discuss them. As a group.

If you are not using Scrum today and are thinking about using it, which team do you want to be more like --

right from the beginning?

This will not happen overnight and takes a patient and effective ScrumMaster to help.

Next Steps This article has given you a start regarding some of the tough conversations you have to discuss as a Scrum

Team.

Talk about it with your Scrum Master, Product Owner, and the rest of your Scrum Team Members.

Why do I consider this so valuable? Because without communication people will shut down and start making

assumptions.

And. As a member of a Scrum Team -- no matter what your role -- part of your job is to initiate these tough

conversations so that you can become a high performing team. If you do not take personal responsibility and

accountability, the rest of the organization around you will continue to try to push things back to the way they

used to be.

So what if I told you I have seen teams transform from the hypothetical "Team X" into "Team Y" if the

individuals, team members, and organizations supported this change.

You will always always always always (multiplied by infinity plus one) have a reason for not implementing a

change within your organization. Change that wording "Yes... But" to "Yes... And" with your team and see

what we mean by Scrum becoming the, "Art of the Possible."