Volatile Extreme Programming Team [closed]

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

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 2

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.