Volatile Extreme Programming Team

Question

Would you recommend extreme programming practices implemented in organizations where team composition changes often? If in an extreme programming scenario, the team becomes volatile midway, what would you recommend? Thanks.

Answer 1

What process is going to work when the team composition is volatile? At least with XP, using pair programming, you have some hope that more than one team member has some familiarity with all parts of the code. FWIW, I don't practice XP, I just don't see how the issue is exacerbated by using XP.

Answer 2

I would suggest that the issue of team volatility is addressed first. No process is going to work very well if you've got a revolving door in your office in the first place and I'd say that using a process that relies more heavily on an individual's performance and contribution than one intended to be used with "replaceable cogs in a machine" is going to make matters worse if that's possible.

Pair programming might work in a situation like this provided you can keep some people around for long enough so that they can impart their knowledge on new members on the team. However part of the problem with that is that you can't really practise the "pair of equals" part of pair programming and you'll end up in an implied senior/junior situation simply because one half of the pair doesn't know the code well enough.

Most development processes rely on a comparatively stable team that does know the codebase well. If you don't have that, you need to design a process around the fact that you will be dealing with developers that are trying to grasp the codebase at the same time as they're trying to be productive.

Answer 3

Pair Programming should help with getting new team members up to speed, as well as osmotic communication in a team room. Extensive suites of both developer and customer tests should make sure that new team members don't break existing functionality. High code quality should help them find their way around faster.

Having said that, volatile teams are really a strong antipattern. Why do you have them in the first place?

Answer 4

High test coverage and a continuous integration can help ensure that new team members do not break what was previously implemented. Pair programming is the fastest way that I've found to help someone get familiar with a project. Planning meetings, short iterations, and tracking velocity over those iterations could also help new developers easily bite small pieces that are more easily managed.

Answer 5

Programmer Pairing becomes a must. Engineer practices (XP) along with management practices (SCRUM) enables to deliver at a sustainable pace. One of the first things you should emphasize for a working team is to keep it together. If that is not possible, programming pairing carries even more importance!

For waterfall, a project is started, people are gathered, they then have to go through Form, Storm, Norm then Perform. Once the team learns how to work together, the project ends and the working team is disbanded. Then the process is repeated again. Do you see the problem? Who has so much money that they can continue to pay the cost for teams to Form, Storm, Norm then Perform again and again?

That being said, every team will see team people come and go. With programmer pairing, you can bring new folks to the team and they will become effective almost immediately. By pairing they will learn the business domain, application code and engineering practice very quickly.

We took a team of 4 pair and added 3 new pairs to the team. We paired all the new developers with experience team members. We gave ourselves 30 days to bring the new members up to speed. The team hit all deliverables. Could you image adding 6 developer to a team of 8 developers on a waterfall team. The team would nearly grind to a halt assimilating the new team members.

Bottom line, keep a function team together. If that is not possible, make effective use of pairing to bring new folks on board quickly.