DISC model of team roles

Jean Tabaka has an excellent explanation of the DISC model of team roles in her book Colloboration Explained. DISC is an acronym that stands for four different personality types

• D: you can describe this person as demanding, forceful, egocentric, strong willed, driving, determined, ambitious, aggressive, and pioneering.


• I: you can describe this person as convincing, magnetic, political, enthusiastic, persuasive, warm, demonstrative, trusting, and optimistic.


• S: you can describe this person as calm, relaxed, patient, possessive, predictable, deliberate, stable, consistent, and tend to be unemotional and poker faced.


• C: you can describe this person as careful, cautious, exacting, neat, systematic, diplomatic, accurate, and tactful.

Teams tend to be imbalanced if a majority of the people on the team have the same personality role. This imbalance happens frequently because people tend to gravitate towards like minded and like acting individuals.

Teams with too many "D" types tend to be very results-oriented, but they don't produce very high-quality work or very detail-oriented solutions. Decisions are made based on speed and who has the strongest or most dominating personality in the group. Team meetings are marked with frequent power struggles, grandstanding, and little collaborative output. These teams are constantly running as fast as they can, straight into brick walls and then on to the next great idea or initiative.

Teams with too many "I" types tend to enjoy debating and brainstorming but have trouble really making any productive progress. These teams are weighed down with endless design meetings and can't focus enough to fully understand the details of the software they are building.

Teams with too many "S" types tend to hyper aware of how everyone is feeling, but they take too long to come to decisions. In addition previous decisions can be retracted and revisited the next time the group meets because someone's opinion was not included.

Teams with too many "C" types tend to have trouble sticking to their decisions because their decisions never feel quite right. They spend too much time reworking solutions trying to handle all possible scenarios even if the scenarios were not requested by a customer. All of this rework results in missed deadlines.

The highest performing teams are the ones that are composed of all these personality types. These teams just need the right guidance to move from divergence to convergence.

Teams should be improved, not enlarged

Cockburn writes:

Here is a common problem: A manager has a 10-person team that sits close together and achieves high communication rates with little energy.

The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.

If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.

This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).

The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.

To improve the individuals on the team, the manager can do any or all of the following:

* Send them to courses to improve their skills.
* Seat them closer together to reduce communications cost.
* Improve their amicability and teamwork.
* Replace some of the people on the team with more talented (and more highly paid) people.

Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.

Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.

As a programmer and not the manager how can I help our team improve? Hopefully reading this book is a start, but I am going to keep looking for ways to do more.

Designing a methodology

Cockburn writes:

Designing a methodology is not at all like designing software, hardware, bridges, or factories. Four things, in particular, get in the way:

* Variations in people. People are not the reliable components that designers count on when designing the other systems.
* Variations across projects. The appropriate methodology varies by project, nationality, and local culture.
* Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.
* Changing technologies. By the time the methodology designer debugs one methodology design, the technologies, techniques, and cultures have changed and the design needs updating.

No wonder it is so hard to get this stuff right. It keeps things interesting though.

Extreme Hour

Cockburn writes

More recently, Peter Merel invented a one-hour process miniature for Extreme Programming, giving it the nickname Extreme Hour. The purpose of the Extreme Hour is to give people a visceral encounter with XP so that they can discuss its concepts from a base of almost-real experience.

In the Extreme Hour, some people are designated "customers." Within the first 10 minutes of the hour, they present their requests with developers and work through the XP planning session.

In the next 20 minutes, the developers sketch and test their design on overhead transparencies. The total length of time for the first iteration is 30 minutes.

In the next 30 minutes, the entire cycle is repeated so that two cycles of XP are experienced in just 60 minutes.

Usually, the hosts of the Extreme Hour choose a fun assignment, such as designing a fish-catching device that keeps the fish alive until delivering them to the cooking area at the end of the day and also keeps the beer cold during the day. (Yes, they do have to cut scope during the iterations!)

This sounds awesome. I wish we had done an extreme hour on my team before we started XP. I wonder if I could convince people to do one now.

There are so many different pieces to XP. It is hard to see how they fit together by reading a book. I think the Extreme Hour could show people how each part of the process is important without making them invest more than an hour.

Coordination is important

Cockburn writes:

Coordination is important. The same average people who produce average designs when working alone often produce good designs in collaboration.

Conversely, all the smartest people together still won't produce group success without coordination, cooperation, and communication. Most of us have witnessed or heard of such groups. Team success hinges on cooperation, communication, and coordination.

I like this quote. This is the reason why I am reading this book. I want to learn how to help myself and my team cooperate, communicate, and coordinate better.

Amicability and Conflict

Cockburn writes:

Amicability is the willingness of people to hear the thoughts of another person with goodwill and to speak without malice.

Amicability is the weaker cousin to trust. Trust is wonderful and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.

When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost-opportunity cost as well as the overall cost per idea developed.

Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.

One might think that removing all conflict from a project team would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems!

I think being able to listen and without an agenda is really important but really hard for me to do. I start thinking about how to word my response before the other person is even finished talking. I want to be more patient and not be in such a hurry to steer the conversation in one way or another. I need to trust that eventually both people working together will come to the best conclusion.

Repairing Design Discussions

Cockburn writes:

On project "Winifred" (Cockburn 1998), the lead programmer announced at regular intervals that design was unnecessary and that code simply grew under his fingertips.

As a predictable result, the young programmers working in the room with him also felt it unnecessary to design. The code looked that way, too.

He eventually left and I took his place. To reverse the situation, I arranged for us to design by having conversations at the whiteboard. After some period of doing this, I started getting questions like, "Could you look at the responsibilities (or communication patterns) of these objects?"

By setting an audible tone in the room and making these design discussions legitimate and valued, the programmers started to converse about design together.

We struggle with these discussions on my team. I want to have these discussions, but I have a hard time getting everyone to participate. There are a few vocal members on my team that complain that our efforts to design as a group are unnecessary. I wonder if there are ways to work through this problem without losing team members.

Program by example

Cockburn writes:

You can and should start taking advantage of people's strengths in copying and altering work samples. Create a small, online library of real samples for work products produced on your (or some previous) project. Other people can then simply copy one of the samples as the base for their own work. In copying it, they will pick up both the structure and style from the sample, while changing the details to fit their purpose.

The implication is, of course, that you would like the work samples you collect to be relatively "good," having structure and style you don't mind having copied. They don't have to be perfect, of course, just "good enough."

I cut and paste code all the time. I think I have a catalog in my head of all kinds of patterns of solving problems. I wonder if people would use a WIKI site with code examples instead of cut and pasting from the codebase?

Cockburn writes

Piattelli-Palmarini describes a number of experiments involving risks and rewards. The interesting thing is that even when the outcomes are mathematically identical, the results are different depending on how the situation is presented.

Illusions of Choice

Piattelli-Palmarini cites a dual experiment. In the first, people are given $300 and then have to choose between a guaranteed $100 more or a 50/50 chance at $200 more.

People prefer to take the guaranteed $100.

In the second, people are given $500 and then have to choose between having $100 taken away from them or a 50/50 chance of having $200 taken away from them.

People prefer to risk having $200 taken from them.

(Piattelli-Palmarini, p. 58)

Mathematically, all outcomes are equal. What is interesting is the difference in the outcomes depending on how the problem is stated.

Piattelli-Palmarini sums up the aspect relevant to project managers: We are risk-averse when we might gain.

and then later

This characteristic, "preferring to fail conservatively rather than to risk succeeding differently," gets coupled with people's fear of rejection and the difficulty they have in building new work habits. The three together explain (to me) why managers continue to use the long-abused one-pass waterfall development process. Based on this line of thinking, I expect that people will continue to use the waterfall process even in the presence of mounting evidence against it and increasing evidence supporting incremental and iterative development. Use of the waterfall process is anchored in a failure mode.

Our group has been trying to practice XP for over a year now. I like it, but I think it is going to be a long hard journey to get some people to try this.

Them's Funky People

Cockburn writes:

There is some resistance in our industry to the idea that people factors dominate software development.

As I participated in initiatives for formal program specification, advanced programming environments, and new development processes, I kept discovering that successful teams were still delivering software without using our latest energy-saving ideas.

Initially, I viewed this as a nuisance: "Why can't those people just realize how much better off they would be if they used our ideas?!"

Eventually, it went from a nuisance to a curiosity.

Slowly, it became a discovery.

I reversed my assumptions and found that the opposite correlation held: Purely people factors predict project trajectories quite well, overriding choice of process or technology.

I found no interesting correlation in the projects that I studied among process, language, or tools and project success. I found successes and failures with all sorts of processes, languages, and tools.

A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology might help or hinder them along the way).

I need to remember this. Put the people above all else.