Extreme Programming (XP) – An overview

Extreme Programming or XP is a very popular set of practices and firmly part of the Agile family. XP fits very well within other processes like Scrum. It is a set of values, principles and practices that are used to create excellence from and within the development team.

XP differs from Scrum in that Scrum is a framework for delivery software and XP is a set of practices that the team does to reach excellence. For this reason they work very well together.

For the history of XP and a good overview, I recommend reading the founder of XP, Kent Beck’s book ‘Extreme Programming Explained’ and reviewing Wikipedia.

Path to excellence

XP starts by evaluating the core values of the individual, the team and the organisation. With these core values, XP builds a set of principles that are specific to software development. The principles then lead to a set of practices that govern day to day working

Values

The first step in implementing XP is to determine the core values that everyone holds as individuals, teams and as an organisation. Discussions take place that focus on:

• Individual values on how we see our work, the things that make us happy with our work, the way we are perceived and the progress we make.
• Team values about what the shared team produces, how the team interacts. Definition of a team for a particular set of stories, discipline, features etc.
• Organizational values. What are the values we expect our organization to have. Both internally and externally.

The foundation for quality has to be based on a set of common values. We can then define working principles around these values and day to day practices from the principles.

Without core values that all the members on the team have fed into, practices will not be consistently followed by the team as the motivation and ownership of them will not be there.

Examples of values used in Extreme Programming:

• Feedback
• Respect
• Communication
• Simplicity
• Courage

When I have worked with teams before, I have found teams come up with new values I have never considered before. Each team and organisation is different.

These values are intangible, meaning that no direct day to day practice can be derived directly from them. However, we can derive principles from them.

You can read more about these values on the Extreme Programming Website

Principles

Principles are a bridge to turn our values into specific concepts related to software development. The principles can help decision making and can be translated into practices which we as an organisation and individuals can practice each day.

Principles expand our core values. The fundamental principles of XP are:

• Rapid feedback
• Assume Simplicity
• Incremental Change
• Embracing Change
• Quality Work

Further principles are:

• Teach Learning
• Small initial investment
• Play to win
• Concrete experiments
• Open, honest communication
• Work with peoples instincts, not against them
• Accepted Responsibility
• Local Adaption
• Travel Light
• Honest measurement

See Martin Fowler’s comment: http://martinfowler.com/bliki/PrinciplesOfXP.html

A lot the success at software engineering comes from having the right mind-set. This must be cultivated by understanding the values of the individuals, teams and organisation and building upon these to drive the day to day work. Principles derived from the values are the bridge between the values and the day to day work.

Practices

Practices come from the principles.

XP suggests 12 practices. This list continues to grow, following the principle of Local Adaption and more and more teams find ways and other practices that suit their individual needs. No doubt different books you may read will add more. The core practices are:

• Sit Together – More discussion and better working happens when the team sit together.
• Whole team – All the skills must be present on the team to deliver the stories.
• Informative workspace – The environment that the team works in should be visual and this allows total transparency of what everyone is working on and any issues that arise.
• Energised work – Teams do not work longer than 40 hours per week. Anymore and productivity rapidly decreases.
• Pair Programming – Developers sit together and program in a pair. One person drives and the other navigates.
• Stories – Stories are used as place holders to conversation, they are flexible and different than requirements.
• Weekly Cycle – The development iteration is a week long.
• Quarterly cycle – Larger amounts of work, such as epics, releases etc. should be release every quarter.
• Slack – The team needs to build in Slack. A highly productive and energised team needs time out to maintain their usual pace. Some teams do this by working on lower priority tasks or do things like enhance the test automation.
• Ten Minute Build – The code base should be able to be automatically built and the tests run in 10 minutes or less.
• Continuous Integration – All the integration tests should be run automatically and frequently in order to ensure the entire system integrity is sound.
• Test First Programming – Tests should be written that match the acceptance criteria for the stories and then the code should then be written to make the tests pass. This is TDD (test driven development).
• Incremental Design – The design of the system should evolve as development unfolds, rather than a huge upfront detailed design.

These practices above are the official 12 practices of XP. You can read more about them in Kent Beck’s book Extreme Programming Explained.

Other practices I have seen teams use that are extensions, additions or clarifications on the above official practices:

• Developers work in small teams of approximately 6-10 people.
• Have the customer on site. If the customer is on site, they can advise with no downtime or assumptions from the development team. Visibility and the relationships that day to day contact provides builds trust.
• Acceptance (and Unit) tests become part of the definition of done. A story is not complete if the code is not covered by unit tests or acceptance tests.
• Unit tests are run as part of every check in. Code can’t be checked in if it breaks the unit tests.
• Acceptance tests define the completion of a task, minimising or removing ‘Gold Plating’, which means developers building things that are cool but out of scope.
• Have the customer define the release.
• Code coverage reports are generated as part of every check in. These can be published on the intranet or product wiki.
• Code quality metrics can be generated on every check in. Again, these can be published on the intranet or product wiki.
• Refactoring code is a constant and valuable part of every iteration.
• A team should be self-managing and self-motivating. This provides the most efficient way of getting the right people to work on the tasks at hand.
• Have showcases (demonstrations) at the end of each sprint to the customer. This can be scheduled in to the calendar in advance.

This list is not complete and could never be complete. It is a quick glance at the most common practices I have encountered and used and that are commonly found in the finance world.

I recommend reading the books and resources in the further reading section on this page for other ideas and practices teams have adopted.

The XP Wordle

Kent Beck the creator of Extreme Programming put together this wordle of all the things that XP means to him. I think it shows how XP is a set of values, principles and practices rather than a prescriptive framework like Scrum.

Extreme Programming in Finance

Most development teams in Finance are doing some of the XP practices. Different teams have adopted different approaches and most teams implement more as acceptance of the practices take hold higher up in the organisation and they get permission to proceed.

I believe the way changes are being brought in, follows the agile iterative approach of transparency, inspect, adapt. The level of compliance with XP practices can be small at first and iteratively brought in as time and trust in the process allows.

I have not found anyone yet across the banks and funds I asked that are practicing pair programming. There is still great opportunity in this area to bring huge improvement into Finance and people with these skills from other industries will benefit here as the industry becomes more mature in its adoption of XP.

Tools

There are many tools that help automate or facilitate the working practices in the day to day process of building software.

Common tools are:

NUnit for unit testing .NET code: http://www.nunit.org/

JUnit for testing Java code: http://junit.org/

Resharper: For refactoring .NET code: http://www.jetbrains.com/resharper/

NCover: For measuring the amount of .NET code that is tested: http://www.ncover.com/

Dot Cover: A better code coverage tool for .NET from visual studio but one that doesn’t adequately provide command line coverage for servers.: http://www.jetbrains.com/dotcover/

Spec Flow: A BDD (Behaviour (or business) Driven Design) coding framework for .NET acceptance tests: http://www.specflow.org/

Pickles: A live documentation generator for use with Cucumber or Spec Flow, to produce living documentation from the acceptance tests. https://www.nuget.org/packages/Pickles

NDepend: A Code metrics tool to measure the quality of .NET code: http://www.ndepend.com/Default.aspx

Further reading: