Tag: co-location

Scrum and all Agile methods work best when:

1. Team members are co-located
2. Team members are together through the entire work day
3. Information is radiated visually
4. Every member of the team is 100% on that team with no responsibilities outside the team
5. All work is done in pairs of team members
6. The team has a large suite of automated unit tests
7. The team practices continuous integration of work
8. The team is skilled in refactoring and has a large, maintained regression test suite

The first 2 items (team members are co-located and team members are together through the entire work day) address the importance of face-to-face communication. This is because all human language is imprecise. We make up for the imprecision through body-language, tone of voice, and emphasis on some words over others.

We lose all of those advantages when we use written communication, and therefore we lose meaning.

With telephone, we lose body language and have the added problem of possible noise on the line or words that are dropped in transmission, and therefore we lose meaning.

Video conferencing would appear to solve all these problems, but it is only as good as the clarity of the connection and how much the camera is able to see. Even with video conferencing, we lose the meaning of what others are saying.

Item 3 (information is radiated visually) is important because putting team information in an online tool inhibits the transparent sharing of information. If I have to open some software and browse to find the information I want, there is a barrier to me getting the information. If the information is posted on a wall in my team work area, then that information is instantly available to anyone in the area. Including me and my team mates.

Item 4 (Every member of the team is 100% on that team with no responsibilities outside the team) addresses the importance of reducing interruption. Study after study has proven conclusively that human beings do not multitask well. I don’t care what people choose to believe, the proof is overwhelming and it is true for every generation. Young people don’t multitask any better than mature adults.

Study after study has show that switching between tasks takes time, and the more complex the tasks are, the longer it takes to unload one from your brain and load the second one in. When a knowledge worker (writers, analysts, designers, coders, architects of all kinds) is working on two projects, approximately 20% of that person’s available work time is lost in switching between tasks. This is bad enough, but the problem only grows worse as more projects are added.

Item 5 (all work is done in pairs of team members) gives at least two benefits. First, by pairing the work, you always have more than one person who knows what that work is and who can explain it to others. Second, if someone has to be out of work for a few hours, then their partner can quickly catch them up-to-speed on what has happened on the project during that time. This greatly reduces the time to switch between work and the outside world. Pairing is also an effective way to quickly get a new team member up-to-speed.

Finally, items 6-8 (the team has a large suite of automated unit tests, the team practices continuous integration of work, the team is skilled in refactoring and has a large, maintained regression test suite) address the uncertainty of software. We will almost never get it completely right the first time, and so we need mechanisms to help us make continuous small improvement (kaizen), trying and testing until the software is what it needs to be. We are not looking for perfection, but quality and value. We get the quality and value quickly by writing small amounts of code, then testing it and getting it right before writing the next small amount of code.

This stuff works when you do it. If you want to pick and choose just the things you like, you will never get the full benefit of Scrum and Agile practices.

Geri