Scaling XP

In this post I will be talking about Kent Beck’s Extreme Programming Explained book, specifically Chapter 15, in this chapter we will talk about Scaling XP.

It’s not the same to maintain and organize a team of twelve compared to a team of one hundred. However, both team sizes can apply XP with no problem but each need to follow the path in a different way. The number of people on a project is not the only measure of scale for software development. Software development scales along many dimensions:

• Number of people
• Investment
• Size of the entire organization
• Time
• Problem complexity
• Solution complexity
• Consequence of failure

Number of People

Solving a problem with two developers is not the same when you have one hundred of them. With bigger teams comes bigger procedures to ensure good software development. However, sometimes the problem is so small that two developers are better than one hundred. When you encounter a big problem still is better to solve it with small teams instead of placing a big team on it. When faced with a big problem I work in three steps:

1. Turn the problem into smaller problems.
2. Apply simple solutions.
3. Apply complex solutions if any problem is left.

Investment

Investing and software development are two completely different worlds. Accounting handles software development, not XP. Blindly applying accounting models from the world of factories and widgets to an activity as different as software development inevitably creates distortions in the accounts.

If you are starting large-scale software development XP-style, find an ally in finance early on to help you navigate these issues. Each company seems to account for software a little differently.

Size of Organization

When applying XP to a team or company, you need to consider everyone. Not everyone will like the new practices so you need to communicate in a way that they understand that it is for the good of everyone, if you force them to do what you want they will become enemies of the team. We can’t afford enemies in XP, a good XP project manager has the ability to join XP practices with company ones that already existed. Each company or team has an XP version that everyone has agreed upon. So, be patient and smart, people are afraid of change, encourage them that this change is for the better and they will be on your side.

Time

Progress doesn’t have to be spectacular. The important thing is that defects are rare, the team advances in a steady way and adding functionality with no problem. If things get out of hand and the project dies, XP teams write a “Rosetta Stone” document that is a brief guide to future maintainers and this document tells them how to run, build and test the project.

Problem Complexity

XP is ideally suited to projects requiring the close cooperation of specialists. One challenge at the beginning of such projects is getting everyone to work in concert while learning a bit about each others’ specialities. At the end of the day, even the specialist of a certain topic can miss a simple bug and the other members on the team can detect it after they have been learning from him.

Solution Complexity

Sometimes systems grow big and complicated, out of proportion to the problem they solve. The challenge is to stop making the problem worse. It is difficult for a struggling team to keep going when every defect fixed creates three more. XP can help.

The XP strategy for dealing with excess complexity is always the same: chip away at the complexity while continuing to deliver. Brighten the corner where you are. If you are fixing a defect in an area, clean up while you are there. One objection is that this “extra” cleanup takes too long. The team is likely wasting time on interruptions to fix defects. Cleaning up helps reduce the overhead of work.

Consequences of Failure

XP applied to life-critical situation is different. Some rules change in order to prioritize safety or security, for example a hospital, there’s no room for failure when lives depend on the software we build.

A system isn’t certifiably secure unless it has been built with a set of security principles in mind and has been audited by a security expert. While compatible with XP, these practices have to be incorporated into the team’s daily work. For example, refactoring have to preserve the security of the system as well as its functionality.

Avionics and medical systems are audited before they are allowed to be deployed. XP’s principle of flow suggests that auditing should not be a phase at the end of a project. Auditing should happen early and often.

Traceability

Is the ability to link what has changed in a system to why it changed, is built into XP, although the information isn’t routinely recorded. The only change to implement traceability is to make a physical record of this information. If I am changing this line of code, it is because I wrote that test which is a part of that system-level test which came from that story which was scheduled May 24 and was ready to deploy on May 28. Your auditor will tell you what format to use in saving this information.