Does your software development team 'jell'? Do they think and act as a single cohesive team, working together to solve problems and push their performance to new heights? Or are they a bunch of people who happen to be working on the same project, each working in isolation and barely aware of what the other team members are doing? Studies have shown that a high performance, highly jelled team can be up to ten times more productive than a poorly performing team.

Although teams can occasionally jell of their own accord, there are a number of things you can do to help this process along.

1. Give Them Their Own Space

It is virtually impossible for a team to truely jell if its members are not all in one place. A lot of companies put their workers in individual cubicles that seem deliberately designed to stop them working effectively - they are shielded from their colleagues well enough to stop them communicating easily, but not well enough to stop them being distracted. Give the team its own area, and let the team truely take ownership of the area. Encourage them to move the furniture around, dismantle cubicle walls, and add their own embellishments. Let the team control who can enter the area, and where the team members sit. The area will need a good acoustic barrier beween the team and the rest of the company, not least because a jelled team can be dynamic and noisy, and is likely to disturb its neighbours.

2. Try Agile Development Methods

Traditional software development methodologies have focused on the process, separating out the development activities into different stages, and specifying the output from each stage such as a set of documents that need to be created before the next stage can be started. The needs of the team members were at best ignored, at worst they were treated as expendable interchangeable parts. This is starting to change with the rise of a new breed of software development methodologies under the umbrella term of 'agile'. This new movement is far more people-centered and has as its core values:

The best known agile methodology is Extreme Programming (XP for short), but there are many others such as SCRUM, DSDM and Crystal. Let the team explore different agile methods and select the practices that work best for it. Many of the suggestions in this article are taken from agile methodologies.

3. Maximise Communication, Minimise Bureaucracy

A key to creating a high performance team is open, honest, face-to-face communication. Here are some ways to improve communication:

4. No More Heroes

Discourage programmer heroics. Many teams have a 'lone ranger' who works in secrecy churning out large volumes of complex code that no-one else understands. Although they may be highly productive as individuals, they will ultimately drag down the productivity of the rest of the team and stop it from jelling. Remove them from the team and give them a job they can do on their own. Also discourage the team from working long hours and putting in huge amounts of overtime. Although this may appear to be productive it is not sustainable in the long term and will destroy team morale.

5. Let Them Grow

Encourage the team to learn and to develop new skills, both as individuals and as a team. Pair programming is a great way of sharing skills and knowledge between team members. Give the team control over its own training and book budget.

Encourage the team to learn from its own experiences. Many teams have a retrospective at the end of a project, where they dissect what worked and what didn't. The end of the project is too late - it is far better to have regular introspectives, where the team explores ways of working more effectively that it can put into effect immediately.

Another aspect of letting the team grow is in terms of team size. Start with a small team of highly experienced developers and grow the team slowly, as needed. Only add one person at a time, giving that person long enough to be integrated into the team's culture before adding the next. A common mistake is to overestimate the number of people needed for the project, and create a huge inefficient team to do a task that a small team could do more easily.

6. Give them Play Time and Rest Time

Software development is a highly creative activity. There are two major aspects to creative thinking, cross-fertilisation and incubation, which can be promoted through play and rest. By play I mean having a period where the developers are free to try out new ideas, tools, methods, etc that are not part of the immediate project. One XP team has 'gold cards' - the team allows each developer to play a gold card once each iteration, which means that they can spend the day playing. Other companies reserve Friday afternoons as playtime, when everyone is free to do anything they like even if not directly related to the project.

The other aspect is rest. It is well known that having a short rest break can stop fatigue setting in and can keep you mentally and physically alert. Rest breaks are also an opportunity for the human mind to process information subconsciously and come up with creative solutions to problems. Have a separate rest area where developers can go to relax, unwind and even sleep. If the US Marines can have PowerNaps, then so can the rest of us.

7. Trust the Team

Developers are motivated by the desire to develop! They take pride in doing a good job, and the best incentive you can give them is recognition that what they are doing is valuable and worthwhile, and to show that you trust them to do their jobs well. They are not generally motivated by status or the next quarter's profit margin. If you are going to give them a financial incentive such as a bonus, then give it to everyone in the team equally or give it to the team and let them decide how to split it. Singling out team members for special bonuses is a great way to destroy morale and team cohesion.

Another great morale destroyer is the unrealistic schedule. If the team says it will take six months to produce X, then accept it. Forcing them to do it in three months will not get it done any quicker, and will probably make it take even longer as they do a rush job end up re-doing large parts of it to get it to an acceptable level of quality. If six months is too long then drop functionality until the estimate is acceptable.

8. Work Iteratively and Incrementally

Iterative development means working in fixed length time periods. Each iteration starts with a planning session to decide what will be accomplished in that period. Depending on the size of the project and the methodology being used, the iterations can range from a week to one or more months.

Incremental development means adding features one at a time. At each stage you have a working system but with a subset of the total functionality.

The importance to the team of using iterative and incremental development is that they always have a deadline in the near future to work towards, and a clearly defined set of objectives for that deadline. This keeps the team focused on a common set of goals, and gives them lots of little successes to celebrate at regular intervals.

There are also management advantages to iterative and incremental development, such as better visibility of progress and better planning.

9. Use Test First Design

This is not specifically a team practice, since it can be used equally well by solo programmers, but it is a great productivity boost either way. Test First Design (sometimes called Test Driven Development) means that you write the tests before you write the code to make the test pass. This is usually done using a unit test framework such as JUnit (or the equivalent for your language of choice - CppUnit, PyUnit, HttpUnit, etc). When done properly the act of writing the tests is also a way of doing the low-level software design. You also end up with a comprehensive suite of unit tests for your code, ensuring a high level of quality and allowing the team to refactor the code with confidence. The suite of tests also act as documentation for the code.

10. Get A Team Coach

One of the central roles of XP is that of team coach, a role that is becoming more common in other agile methodologies. A good coach will ensure that the team sticks to the process and does all the practices required by the methodology. A great coach will also monitor the team dynamics and work with individuals or the whole team to resolve interpersonal issues, help the team forge a common vision and set of values, brainstorm with the team to find creative solutions to problems, and facilitate during team introspectives to enable the team to find new and better ways of working together.

 

Resources:

Here are a few books and URLs for you to explore these ideas further.

Software Teams

Books:

Peopleware by Tom DeMarco and Tim Lister

Rapid Development by Steve McConnell

Agile development and Extreme Programming

Books:

Agile Software Development by Alastair Cockburn

Extreme Programming Explained by Kent Beck

On the Web:

http://www.agilemanifesto.org/

http://www.agilealliance.com/home

http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap

http://www.pairprogramming.com/

http://www.extremeprogramming.org/

Creativity

Books:

Thinkertoys by Michael Michalko

Hare Brain, Tortoise Mind by Guy Claxton

Coaching

Books:

Coaching For Performance by John Whitmore

The Complete Guide to Coaching at Work by Perry Zeus and Suzanne Skiffington

The Coaching at Work Toolkit by Perry Zeus and Suzanne Skiffington

About the Author

Dave Kirby has had a lifelong interest in human psychology and group dynamics, and took a degree in Psychology and Cybernetics over twenty years ago. While at university he got hooked on computer programming and went on to work in the software industry, mainly in the games and telecoms sectors. He discovered Extreme Programming in 1999 and started incorporating XP practices into his programming. After twenty years of software development he decided to go back to his first love and retrained as a life coach. He now does coaching both for individuals and for software development teams wanting to improve their performance. He has been a regular at the Extreme Tuesday Club in London since November 2000, and is a member of the International Coach Federation. He can be contacted at dave@thedeveloperscoach.com, or visit his website http://www.thedeveloperscoach.com.

This article is copyright © Dave Kirby - The Developers' Coach 2003. Permission is given to redistribute it in its entirety, including this copyright notice.