Team Collaboration

Collaboration is at the core of problems experienced when implementing Scrum (or any team work). As I mentioned last week, consideration of personalities is important when composing a team. This is a big/important enough subject that I decided to devote a whole post to it.

Developers, generally, are simply not good at working in a team. In the past, good programmers could get away with working fairly independently in their own specialized area. Nowadays, larger projects, more varied project types and different development methodologies means that good team-work is expected of everyone. It is a simple demonstrable fact that collaborative (Agile) teams invariably produce a better outcome, more efficiently and with less risks.

“collaborative teams
invariably produce
a better outcome...”

You can try to hire people with the right personality, but it's not necessary (and sometimes you simply don't have that choice). Luckily, using Scrum and some tips that I mention below, most developers can learn to work as part of a team, and even enjoy working with others for a worthwhile goal.

Why Teams Don't Collaborate

Poor collaboration is most obviously seen in conflict over technical issues. In three decades in the industry I have seen this many times. When you get to the heart of the matter the problem is rarely purely a technical issue but also due to personality conflict, poor communication or interpersonal skills (or even emotional disturbance).

Differences of opinion on technical topics such as software design, coding standards, etc are inevitable. Often this is simply a sign that different people have different priorities - eg, different team members may focus on different aspects of the quality of the code such as efficiency vs maintainability. (See Importance of Developer Quality Attributes for more on software quality attributes and their relative importance.) When the team is collaborating, and pulling in the same direction these issues can disappear, or become much easier to resolve, since team members are more amenable to compromise.

Managers often realize there is more behind the disagreement, such as a clash of egos. But they fail, or are reluctant to, to dig deep enough to find that some of the team may feel disempowered, threatened or generally dissatisfied. Again, a Scrum team overcomes these sorts of problems by empowering and encouraging communication and collaboration.


Personality

Typical Developer DISC Profile

To get an idea of why collaboration does not happen let's look at the personality of a typical developer. Last month I mentioned the DISC system of personality assessment (see Team Composition). Developers tend to fall in the S-C-D range and are predominantly of the C personality type (see diagram at right). This means they are conscientious and competent, striving for accuracy and quality. However, they prefer to work independently with little social interaction.

It seems that the software industry tends to attract people who are averse to collaboration. (In fact DISC assessors recommend software development as an appropriate career for those with a C personality type!) This is the major problem when attempting to get a Scrum team to collaborate and self-organize.

So do we give all new recruits a personality test and only hire developers with the right personality type? No -- that's not a good idea. It would greatly reduce the pool of potential candidates, some of whom may be otherwise ideally suited to the role. The fact is almost all developers (even the extreme case of someone with Aspergers) can learn to collaborate, and even enjoy working in a small self-organizing team.

My Internal DISC Profile

I believe this non-collaborative behavior is primarily a conditioned or learnt response, as I explain later. This is clearly shown with DISC personality assessments of a typical developer. DISC assessments give two personality profiles - called internal and external. An internal profile (see diagram at right) reveals a person's natural tendencies, whereas the external profile (see diagram below) shows actual behavior in the work environment. In disempowering environments developers typically suppress their collaborative tendencies.

My External DISC Profile

For example, last year I had a DISC assessment which showed that for my Natural/Internal personality my S and C styles were about average. However, for my Adapted/External personality my S style had disappeared. (The S personality type is supportive and likes working closely with other people.)

What was it that suppressed my natural collaborative tendencies? I think there are a number of factors which I cover in the next few sections. Further, I also believe that proclivity to working in a small team is a part of human nature as I explain later in the section below entitled Homo Habilis.

Training

Training in the industry tends to reinforce the notion that software development (at least design and coding) is a solitary activity. For example, in all the courses I did at uni. just one (of the dozens) of modules I took involved working as part of a team - my 3rd year course on "Software Engineering". Things have undoubtedly improved since 1983 but I still believe there is a problem.

Conditioning

Even more significant is non-collaborative behavior that is reinforced by many organization's culture or managerial practices. Many managers, by their attitude and behavior, promote rivalry and even conflict between team members. This is symptomatic of a command-and-control management style as I discussed previously (see Production Line Mentality).

Managers often realize that what they do and say has detrimental effects and try to change their behavior. However, this can be difficult when  motives are questioned. For example, common advice is "Praise publicly, criticize privately" - but this can backfire. Of course, you should never criticize publicly - it is demoralizing and humiliating - but (too much) public praise may not be seen as genuine and may trigger envy in other team members. A sudden change in behavior will also be viewed with suspicion unless there is evidence of a change of attitude. Above all never say one thing and do another.

Praise privately   

It's commonly said to "criticize privately but praise publicly". My own policy is to give all feedback to employees privately - both criticism and praise.

Of course (unless you are very good a deception :) it should also be honest, otherwise it is simply seen as manipulative.

Admittedly, it is nice to ensure it is known publicly when someone has done a good job.

In addition, many companies have policies that work against team work. For example, such things as Annual Performance Reviews and Employee of the Month awards usually have little effect apart from causing resentment. But when they do have an effect it is one that promotes competition and rivalry which actually undermines collaboration.

Why Teams Should Collaborate

We have seen how the personality, training and years of conditioning make it difficult for developers to work together - so why don't we give up on the idea of an highly-collaborative, self-organizing team?

Don't give up! If we can overcome the above problems then there are big advantages. I have been expounding these advantages (and the disadvantages of a command-and-control no-collaborative approach) in all my posts since last December (except for Lean is Not Agile).

In summary they are:

• more creative ideas are generated
• less coordination overhead
• avoids many pointless activities
• greater focus on giving the customer what they need
• less specialization leading to greater productivity
• specialists cannot hold the organization to ransom
• greater adaptability to change
• greater job satisfaction
• greater productivity

In essence a good Scrum team will produce better results. Further, the results are often produced more quickly - or there is, at least, the perception of increased productivity because the team is focused on what is important to the customer - in the short term. In the long term there are definitely large productivity benefits.

Disadvantages

In researching this post I found quite a few web pages arguing against small self-managing teams (eg: Does XP/Scrum Violate the “Agile Manifesto”?), Some of them have a point, but some are simply incorrect. I refined it to six basic points which I will now address.

1. Having many small tasks done by different people results in inconsistencies.

This will happen in any team, but in Scrum team members are actually more likely to work together to avoid these sorts of problems. For example, in almost all jobs I have had there have been coding standards "in use", but I have only ever seen them followed with any rigor in a Scrum team.

2. Group decisions are often not good decisions.

The team may be prone to "group think", but this is not due to Scrum. In fact, Scrum empowers individuals to make a contribution. The focus should be on finding the best solution, not going along with everyone else.

There will be occasions where there are differences of opinion on technical issues, but in my experience, when all team members are aligned, these are easy to resolve. Moreover, decisions are often not group decisions since generally Scrum teams have experts in different areas to whom they defer.

3. Decisions are slow because they are made by committee.

First, it is important to remember that a Scrum team is not a committee. Most committees are composed of members with very different agendas; whereas in a Scrum team all members should have the same focus.

Also, it may appear that a team is indecisive because they are using an important Agile practice of deferring decisions until necessary (see JIT). When the current backlog task dictates that a decision be made then a good Scrum team will not hesitate to decide (or give it to the expert in that area to decide).

4. There is no single person with the authority to enforce design consistency.

This is related to the previous points. The argument is that there is nobody in control who sees the big picture, which results in haphazard decisions and inconsistencies in the design. Common opinion is that it's better to have a single person with the vision to direct the project.

“Scrum...works better
than the single
visionary approach”

The truth is that the "single visionary" approach does not work well with a team of more than a few people. The people actually creating the software are continually twisting and changing the vision for many reasons. The visionary is flat out ensuring that her vision is implemented.

Scrum encourages a better approach where everyone sees, or at least has a grasp of, the big picture. It does not always work perfectly, but it works better than the single visionary approach.

5. The more you divide a task between people the greater the communication burden.

Again, this is simply a consequence of working in a team of more than a few people. Using Scrum and feature teams (an example of DIRE) actually reduces the communication burden.

6. There is no individual ownership and pride in work.

I talked about this last week (see the section on Code Ownership). You may believe, as I do, that you write perfect code, but with input from other team members it can be even better. Moreover, there are other disadvantages of ownership such as specialization, increased risk, etc.

Of course, taking pride in your work is a good thing. Knowing you have done a good job is immensely satisfying. What I didn't expect with Scrum is that I can be even more proud when my team does a good job.

Homo Habilis

One fundamental advantage that humans have is the ability to work in small teams. Humans are inherently social - far more than any other species. Much of this behavior (or tendency towards the behavior) is built into our DNA, due to our recent evolution over the last few hundred thousand or more years.

The formation of small teams was an important early step in human evolution probably beginning more than two million years ago when Homo Habilis began hunting in small self-organizing teams.

Many developers work for years, even decades, almost in isolation, which can be alienating. Many report having an immense feeling of satisfaction when they first work on a collaborative, high-performance Scrum Team. The problem is that not all teams are like that - in the next section we will try to fix that.

How to Encourage Collaboration

Collaboration is fundamental to Agile and Scrum in particular. Lack of a collaborative spirit is usually the reason that Scrum fails. So how do we fix it?

Scrum Practices

Scrum practices encourage collaboration. The visibility provided by the daily standup provides a feedback mechanism that keeps everyone on the same track (as well as providing motivation and peer pressure - see the discussion of the Ringelmann Effect in Scrum == Communism). The product owner, and particularly their product backlog, keeps everyone focused on the one thing - what the customer needs. Empowering the team gets them working together to come up with creative solutions.

XP Practices

Other Agile (not specifically Scrum) practices also help. Here are some examples from XP.

A common open work area for the team encourages communication. (See XP:Space)

A customer representative (eg, the PO in Scrum) works closely with the team. This not only allows the developers to obtain timely help, it also gives the customer invaluable insight into the development process as I explained in Customer Management. (See XP:Customer)

Continuous integration means the developers are always working together to ensure that the system works and that code modifications are compatible. (See XP:CI)

One of the best signs of a good team is when programmers are happy to work on other's code and have other's modify their code. At the very least all code should be reviewed by at least one other person. If people get defensive about "their" code then that is a problem. Pair programming is the ultimate aim in this regard, and has the added benefit of producing better code. (see XP:Pair)

Related to pair programming is the idea of "collective code ownership". Nobody owns any piece of the code (or anything at all, actually), so anyone is free to modify any part of the code. Note that I do agree that often only the original creator(s) of a piece of code may be the only one to appreciate all nuances of the code, which is why Unit Tests are essential to ensure that changes do not introduce bugs. (See XP:Ownership)

Enhancing Team Spirit

Unfortunately, some teams just never "click". Usually the problem is the "mind-set" of one or more team members, as I discuss below. First we look at building team spirit which can be the first step towards changing a mind-set.

Here are 12 suggestions:

1. encourage open and honest communication
2. empower the team to make decisions
3. communicate about strategic planning/goals
4. encourage team members to trust each other
5. make the most of the talents of the team
6. never punish or humiliate team members for mistakes
7. avoid behavior (like public criticism/praise) which promotes rivalry
8. never compare team members against each other
9. reward the team not individual team members
10. encourage the team to be polite to each other
11. encourage the team to eat together
12. encourage the team to see the customer's point of view

Changing Mind Set

I guess the whole point of this post is that many developers have the wrong mind-set. They become defensive when their mistakes are pointed out. Alternatively they are reluctant to give feedback when someone does a bad job for fear of offending them or getting a bad reaction. People forget to give positive feedback when someone does a good job.

Somehow you need to encourage the team to be open and honest with each other. A collaborative environment where people bounce ideas off each other will produce the best possible software.

Here are 12 tips for team members:

1. trust team-mates to do their job
2. be open to new or different ideas
3. take responsibility for committed tasks
4. always find a way to make a contribution
5. be open to helping in areas outside your expertise
6. look at things from the customer viewpoint
7. don't be defensive when someone points out a mistake or a better way
8. don't hide your mistakes
9. don't be afraid to give negative feedback BUT
10. don't be offensive in pointing out other people's mistakes
11. be polite and respectful
12. never put personal ambition ahead of the project

Culture

As I discussed a few years ago (see Why Scrum Fails) the root cause of the failure of Scrum is the culture of the organization. The team will not change their mind-set if the culture discourages it.

First, managers need to relinquish their control, so the team can effectively self-organize. Rewards should encourage collaboration - ie, team rewards, not individual bonuses. Encourage the team to identify and fix their own problems.

Most importantly, it is important to drive out fear. People won't take risks if they are fearful of the repercussions when things don't go to plan.

Conclusion

Scrum is centered around the team - a small, stable, self-organizing, self-managing, collaborative team. When the team works well together Scrum works very well. When the team does not collaborate Scrum does not work well.

Unfortunately, many developers by their nature are not prone to collaborative behavior. Luckily this is not an inherent limitation but is a mainly a conditioned response due to years of working in an oppressive environment.

The advantages of removing an untrusting, blaming culture and overcoming developers defensiveness to develop a collaborative team are big. As explained above there are many benefits but in essence better results are produced, often more efficiently and with greater satisfaction to customer and developers.

Many of the practices of Scrum help to encourage collaboration such as the visibility provided by the daily standup and the focus provided by the backlog. Feature teams as discussed last week are also important. Further, other Agile practices such as continuous integration, collective code ownership, customer focus, collocation, etc are very useful.

The most important thing is to change the environment to one where the developers are empowered to do their best and rewards are team-based not individual.

Further, developers need to be open to the change and fight their defensiveness and preference for working alone. It may be surprising that working as part of a highly-functional small team can be deeply satisfying.