Cooperation & Collaboration in Scrum April 22, 2014http://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 CollaborationAgile Practitioner, 1.15.2013by 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.

CommunicationDictionary definition: the process by which messages or

information is sent from one place or person to anotherCommunication 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.

CoordinationDictionary definition: the activity of organizing separate things so that they work togetherMany 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.

CooperationDictionary definition: to act or work together for a shared purpose, or to help willingly when askedCooperation 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.

CollaborationDictionary definition: to work together or with someone else for a special purposeTwo 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.

FlowingCollaboration 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 AgileA 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 Collaborationby 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 AgileBal 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 MeetingMike Vizdos, www.implementingscrum.com

IntroductionThis 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 MorningThe 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 MorningThe 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.The 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 ReflectionHere 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 StepsThis 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 ReflectionHere 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 StepsThis 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."