Much of my work these days is with small to medium sized Hedge Funds, and I have been using a subset of the 12 XP Practices check http://www.extremeprogramming.org/rules.html for a more detailed view of these practices. I would like to share which of the 12 are being used, and the value that it has added to the business.
Small Releases.
An important aspect of working with the client, is to provide continuous feedback to the users, this is necessary as it provides the client with visibility into the progress of the team, and builds confidence with the business that the efforts of the team are focused to the good of the business. We push out new releases into production on average twice a week, some of the changes are minor other fairly sizable, but each is an important increment of functionality that resolves a business need.
Simple Design.
The client has a small group of developers, with varied skill sets, so a key concern is that the design of the system needs to be understood by the entire team, so simple is good, as it allows full participation by all team members. The team participates on a daily basis with regards to ensuring that we all obey this practice.
Refactoring.
Once business functionality has been added to the system, we review and refactor, this has allowed the team to keep the code base small and compact and has allowed for additional requirements to be added very quickly with fewer defects. This has benefited the client, by the team being able to move quickly on many new requirements.
Testing.
We are using NUnit in conjunction with CruiseControl to allow for automated test sweeps of the system, each time a build is performed. Each programmer is responsible for developing the appropriate test suites for the components that they are primarily responsible for. Many of the tests that are run, correspond to the verification of analytical calculations, this is highly visible to the client, and the continually testing that is provided has built confidence with the business that releases are of a good quality, this being key when your business relies on the results of the analytical calculations.
Collective Ownership.
The team is collectively responsible for the system, there is a primary contact person for operational issues, this is only to aid the business users. All of the code belongs to the team, this has allowed the team to move very quickly, without impedance from external forces. The client sees that the team as a whole is responsive to business demands, and no one individual is seen as a bottleneck, or as a hero. The team is seen as the hero.
There is a notable practice that’s missing from the above list and it is
40-hour Week.
This is one of the XP practices that is not followed, the reasons are many, primarily the team is very small, and acts as both developers and operational support for the business. The business will start to see a reduction in quality, as the system grows and more functionality is added and needs to be supported, more and more of the time that the team spends will be dedicated to operational support. Hence fewer new features will added with the same level of quality as they are today. This becomes a vicious circle that can only be broken by investing in additional resources that can provide the necessary operational support.
Summary.
The XP practices that we have employed at our Hedge Fund clients have allowed the client to start seeing results within the first two weeks, and continue to see results on a regular basis. This has built confidence with the business that has allowed a very good working relationship between the IT staff and the business users, there is trust and mutual respect that re-enforces the relationship between the two groups.