Week 7: Working together
Once again, I had hoped to write about puzzles and messes, but my quest for more content has pushed it back another week. In the meantime, staying on the topic of the social side of software development teams, here are my thoughts on working relationships for small teams.
You generally find teams with many members are broken down to smaller, more manageable teams. This works for several reasons, such as: letting people specialise and build up knowledge in one area, giving people more responsibility/ownership over sections of work, and dividing up the team to match the architecture/model of the product. But I'm more interested in how to manage those teams once they've been formed and setting up good work practices to get the most out of them.
The management view...
In a large project there are generally several teams. The 'why' factor (see week 5) demands that team members are aware of what the others are doing, but not to the point where they're distracted from their own work. Firstly, setting up the teams to have as few dependencies on other teams' work as possible is a big plus. Then managing the teams independantly also becomes an issue, trying to keep the work seperate but keeping them in sync and driving them towards the overall goal.
The sub-team view...
This is where the fun stuff happens. A sub-team is focussed on its individual goals. To have 4-5 people working towards those goals is in itself a logistical dilema, but can be effective with the right procedures in place. Assuming a harmonious dynamic (see week 6), there are certain ways to get the most out of the team.
Pair programming is a tactic used now. Its effectiveness is arguable, but for complex software and when used in conjunction with techniques such as test-driven development (TDD), its benefit is amplified. This has sub-conscious benefits such as: a pair has a better chance of comprehending where their work stands in the greater picture (better direction) and there is more immediate communication which improves the general flow of information within the sub-team.
Having an open-plan work area is another tactic. Some team members respond better than others to this. People generally like to have a physical barrier between them and the outside world while working. There are issues with sound and distractions, but significant benefits as well. Team members dont feel as 'out-of-the-loop' when they can eaves-drop on conversations of other members, which keeps everyone in touch with what's going on with other work in the team. They can also help out when a problem arises that they know how to fix. Open plan also encourages members to share their problems, work at a more steady pace and not lock themselves away where no-one can see them playing games... so they read slashdot instead. It's generally a bad idea to sit management in the same room unless they have knowledge to offer and a non-threatening manner.
There are pros and cons, but those are a couple of ways of improving the inner workings of a small team. Generally the more contact, the more communication (formal and informal) the better.
Next week, problems, puzzles, messes.
You generally find teams with many members are broken down to smaller, more manageable teams. This works for several reasons, such as: letting people specialise and build up knowledge in one area, giving people more responsibility/ownership over sections of work, and dividing up the team to match the architecture/model of the product. But I'm more interested in how to manage those teams once they've been formed and setting up good work practices to get the most out of them.
The management view...
In a large project there are generally several teams. The 'why' factor (see week 5) demands that team members are aware of what the others are doing, but not to the point where they're distracted from their own work. Firstly, setting up the teams to have as few dependencies on other teams' work as possible is a big plus. Then managing the teams independantly also becomes an issue, trying to keep the work seperate but keeping them in sync and driving them towards the overall goal.
The sub-team view...
This is where the fun stuff happens. A sub-team is focussed on its individual goals. To have 4-5 people working towards those goals is in itself a logistical dilema, but can be effective with the right procedures in place. Assuming a harmonious dynamic (see week 6), there are certain ways to get the most out of the team.
Pair programming is a tactic used now. Its effectiveness is arguable, but for complex software and when used in conjunction with techniques such as test-driven development (TDD), its benefit is amplified. This has sub-conscious benefits such as: a pair has a better chance of comprehending where their work stands in the greater picture (better direction) and there is more immediate communication which improves the general flow of information within the sub-team.
Having an open-plan work area is another tactic. Some team members respond better than others to this. People generally like to have a physical barrier between them and the outside world while working. There are issues with sound and distractions, but significant benefits as well. Team members dont feel as 'out-of-the-loop' when they can eaves-drop on conversations of other members, which keeps everyone in touch with what's going on with other work in the team. They can also help out when a problem arises that they know how to fix. Open plan also encourages members to share their problems, work at a more steady pace and not lock themselves away where no-one can see them playing games... so they read slashdot instead. It's generally a bad idea to sit management in the same room unless they have knowledge to offer and a non-threatening manner.
There are pros and cons, but those are a couple of ways of improving the inner workings of a small team. Generally the more contact, the more communication (formal and informal) the better.
Next week, problems, puzzles, messes.
posted by Vivski at 7:38 AM
0 Comments:
Post a Comment
<< Home