Collaboration, Over Work in Isolation

When I’m working with new Scrum Teams and say that Scrum encourages collaboration among team members, everyone nods and smiles. When I ask them to describe their actual collaboration, I hear about collaboration in Sprint Planning, Review and Retrospective. If I’m lucky, someone mentions solving impediments found in Daily Scrum through collaboration.

Wow. Jaw drops. Jaw hits the floor and shatters. That is a seriously low bar for collaboration. This suggests that only 10% of a Scrum team’s work is collaborative.

Let’s define our terms:

• Coordination – synchronizing the independent work among a group people. The work isn’t necessarily working towards a common goal.
• Cooperation – to act or work together for a shared purpose. However, many tasks will still be completed independently.
• Collaboration – working together in a joint effort towards a common goal.

In the world that many Scrum people imagine, team members grab User Stories, Tasks, or (worse) Tickets at the start of the Sprint. They then retreat to their desks and only emerge to talk during Daily Scrum. When they finish their part of the task, they mark it as “Done”, and hand it off to the next person, then grab a new task. So their “Done” isn’t truly done and deliverable, it’s just done for them, before someone else tags in and takes it another stretch forward.

The Sprint Planning and Daily Scrum portion are being used for coordination. Sometimes this rises to the level of cooperation, but typically each task is performed solo. This certainly isn’t collaboration because team members aren’t working together toward a common goal.

The above paints a disappointingly common scenario where they call themselves a Scrum team but, in reality, people are working primarily in isolation.

Why is working in isolation so bad?

• Handoffs result in a loss of information and force (re)learning about the current and historical status of the item. The more handoffs there are, the greater the loss of information. The more handoffs, the slower the progress of items from start through to delivery to customer (aka cycle time). This happens because each handoff adds the opportunity for a ‘waiting for’ delay.
• Work in isolation (and with additional handoffs) reduces quality since the work is completed without ensuring the person’s work meets the needs of the User Story. Or worse, the expectations of the other people who will work on this item.
• Work in isolation harms our sense of team because of lack of time spent interacting with each other.
• Working only on individual Tasks or User Stories harms the overall Product Vision, because team members aren’t staying focused on the overall product, just the piece in front of them right that moment.
• Work done in isolation leads to only marginal improvements in productivity and customer satisfaction, because real performance improvements come from acting as a team through diversity of thought, spotting each other’s mistakes, reduction in errors, helping your partner stay focused, etc.
• Work in isolation increases our coordination costs through lost productivity during handoffs and, even more so, the reduced amount of information transmitted, which increases the likelihood of defects and the need for rework.

I have never seen a truly high-performing team (and I’ve seen many teams) when the work was done largely in isolation rather than with collaboration.

Why is collaboration beneficial?

• Shares knowledge and aids the cross-skilling process through hands-on work, rather than just theoretical study.
• Generally diverse groups make better decisions than a single individual because of the broader range of experience and knowledge to draw from.
• Easier to adapt to changing circumstance (e.g. if a Dev and Business Analyst or Dev and Tester are working together and there is a change in the acceptance criteria, they can more easily write new example and test case together)
• Increases motivation. Humans have evolved to be social, and working together on a problem deepens relationships and communication.
• Increased creativity through diversity of thought.
• Reduction in mis-communication thanks to more face to face discussion, and opportunity to clear up misunderstandings quickly before they compound.
• Constant feedback, which catches errors early.
• Rebalances workloads and reduces bottlenecks.
• Items finished to truly “Done” sooner, thanks to fewer handoffs and delays.
• Reduces Work In Progress. When two people are working on one thing, they’re more likely to get it to “done”, and there aren’t two separate things in progress at the same time.

How can you tell the difference between coordination, cooperation and collaboration?

Coordination

• Daily Scrum is about reporting to the ScrumMaster and not understanding what your peers are working on.
• You exchange messages in Slack, GitHub Issues, or over email. Real time conversation is low.
• All work is completed by individuals who then pass it to the next person. For example, a User Story starts with a Business Analyst, who hands it off to a Developer, who hands it off again to a Tester.

Cooperation

• You know what your peers are working on.
• You help each other out when there are specific issues you think you can assist with.
• Most work is completed by individuals as above, however there is more communication around the handoffs, reducing the errors.

Collaboration

• Scrum has evolved beyond the dreaded three questions: What did you yesterday? What will you do today? What are your blockers?
• Instead, it is a collaborative event where people discuss who will pick up a User Story on a given day. They also might touch on the pairing rotation (see Pair Programming).
• Most work is completed by 2–3 people working in flow. For example, the Business Analyst and Developer sit down to work the first pass at a User Story. After a day of work, they involve a Tester.
• Work in Progress is limited to 2–3 User Stories at one time and handoffs have been mostly eliminated.

Hint: a large volume of noise on Slack or any other chat mechanism isn’t a sign of collaboration. It is either coordination or, at best, cooperation. When collaboration is happening, people move out of Slack to actual conversation.

Why does work happen in isolation?

It probably starts with history. Most people have spent a large chunk of their career working this way, and they don’t realize that a different approach is possible. I’ve spent time in work places where people were compared to others on the speed at which they completed work items. When the performance system puts a high premium on individual effort and productivity, then you get people working in isolation.

Many team members see their Sprint Backlog/Kanban board with columns like Develop, Test, and Deployment as a demarcation of roles. This is reinforced by the ticket-focused culture that often comes with JIRA and many other electronic work tracking tools. (Hint: these aren’t Agile tools.) Many JIRA implementations limit User Stories (or Product Backlog Items) so that only a single person can be assigned to a task. So, by default, people assume that this is the correct model for work.

Lack of trust also contributes to work in isolation. If we don’t trust each other, it is easier and safer to work alone on items than to risk working with our colleagues. Anyone who ever did a group project in school where some of the group didn’t contribute, may have trust issues to overcome.

Other contributing factors:

• Lacking a common goal (aka Product Vision)
• Unclear priorities. Too many teams I meet tell me their Product Backlog isn’t a well-ordered, clear list. Instead, it looks more like the overgrown, building lot down the street, where there was once a good building, however the owner moved out a while ago and it’s starting to fall down.
• Remote work has improved the lives of many people by reducing their commute, reducing costs, and giving them more time with family. However, collaboration went from the ease of walking down the hall or mentioning something at the water cooler, to online communication that requires more explicit effort and is more prone to misunderstanding.

How to encourage real collaboration

As with many questions in Scrum, start with asking the team. What do they need to do to move from coordination to collaboration?

There are many approaches that lead to increased collaboration; I will touch on three specifically. But more important than any individual technique is the goal to create a team culture that defaults to asking the question: How could I do this piece of work with the help of at least one other person? This will result in collaboration becoming a healthy habit.

All of these approaches are documented in our Agile Engineering Practices section of our glossary.

• Pair Programming – Two people work together in a single development environment to do a chunk of work.
• Ensemble Programming (formerly called Mob Programming) – The whole team work together to build a feature and get it to truly done.
• Behaviour Driven Development (BDD) – Many people think that BDD is a technical practice that automates acceptance tests. That is a side effect. The primary benefit to BDD is communication and collaboration. Getting 3–4 diverse people (often Analysis, Development, and Test) to sit down and agree on detailed acceptance criteria with examples, is a deep form of collaboration. When done, all the people who are at the table have a deep understanding of the feature.

Specific actions that help improve collaboration:

• Create Psychological Safety – In environments where people feel unsafe about experimenting or trying things, it is difficult to collaborate. Before trying the rest of the items on this list, if there isn’t psychological safety, work on establishing it.
• Have a Common Goal (aka Product Vision) – Without team members having a deep and shared understanding of the goal they’re attempting to achieve, they will not form a true team and collaboration won’t happen. If we believe that working independently will get the job done, by default human nature, we’ll usually choose to work alone.
• Set Goals Collaboratively – Set (or create) all goals within the team: Vision, Product Goal, Strategy, Sprint Goals, and especially User Stories collaboratively. This puts the emphasis on collaboration as a default model.
• Limit Work In Progress – This should naturally invite people to collaborate. Once the limit is hit, team members should be asking themselves where they can help others out.
• Run a Cross-skilling Exercise – As the team inventories their skills and see where they can learn from one another, they will collaborate to share the knowledge.
• Retrospectives – Appreciative Inquiry (AI) – This takes the approach of finding what is best within the system. Instead of focusing on finding fault and fixing problems, Appreciative Inquiry wants to find the good and amplify it. From the Retromat you might ask questions like: “When was our collaboration at its best?” and “When did we do the best work with our Product Owner?” Having found the good, AI is often followed by an exercise to imagine a future positive state (“Remember the Future” is the classic example).
• Model Behaviour – Don’t wait for collaboration to start happening on its own. Model the behaviour you would like from other people. Invite people to pair program with you. When you see other examples of collaboration, ask them what worked and then comment on it out loud.
• Make Collaboration Intentional – Consider incorporating collaboration into the team’s Working Agreements.
• Improve Communication – Collaboration can’t happen without a clear understanding of what is happening in the team. Make it explicit what should be communicated through email, Slack, etc. One team I’ve worked with recently has a rule that anything that requires more than one email exchange immediately goes to a short Zoom meeting. Another team has set office hours, where each person sets aside two slots a week where they open a Zoom session and anyone can come by to chat.
• Create Space for Experimentation – When the team runs experiments, acknowledge it. Celebrate both the successes and failures. Put emphasis on the learning, more than the outcome.
• Map Workflow – Rather than expect collaboration to happen magically, get the team to map the flow of work. Then invite them to find ways to reduce handoffs. Invite them to find opportunities to run experiments.
• Make it Visible – Having mapped the workflow, make it easily visible using a Sprint Backlog or Kanban board.
• Reduce Communication Bottlenecks – James Shore has an exercise where team members, including Customer/Product Owner, spend time learning what information they need from each other, and then working out how to reduce the time it takes to get/provide the information. This is a more involved exercise than others, and it provides a model to improve both communication and collaboration between parties with limited understanding of each other. 

When does collaboration not work?

There are rare cases where collaboration isn’t possible:

• People on the team have skills far enough apart that don’t share a common language. To my surprise, I have had one client overcome this barrier. They had designers/artists on the same team as metal workers. The distance in their skill areas was far enough apart that they didn’t really have a common language. Yet, over the course of months, they created a common language.
• Legal boundaries exist that block people in one area from working closely with another.
• No overlapping time when people on the same team are located far enough apart that they don’t have any business hours where they can work together.

It saddens me to hear of the low levels of collaboration most teams have. It’s time to break down the virtual zoom barriers (or climb over the cubicle walls if you’re back at the office). We need to help our teams understand what real collaboration is and then coach them to get there. Cooperation alone will not build the high performance teams we all aim for.

 

---