A Brief Overview of eXtreme Programming

eXtreme Programming (XP) is an agile development methodology developed by Kent Beck et al. It emphasises the human aspect of software development and how issues such as respect, trust and communication are key issues along with purely technical aspects of software development.

It is agile in the sense that Beck is strongly against giant requirement documents and the waterfall model of software development in general, preferring to build the simplest system that solves the current customers problems, and iterating from there with rapid (weekly/monthly) feedback loops.

The core ideology of XP is explained in a series of complementary values, principles and practices.

 

Core Values of eXtreme Programming

Values are the abstract issues and ideas that XP practitioners feel are important for a project to be a success, they guide the principles and practices.

  • Communication – communication is important for creating a sense of team and effective communication. Most often when you encounter a problem, someone else on the team already knows the solution.
  • Simplicity – develop the simplest system that could possibly work.
  • Feedback – change in a project is inevitable, so rapid feedback is required to adapt the project to changing requirements.
  • Courage – effective action in the face of fear. Knowing there is a problem and having the courage to fix it.
  • Respect – the contributions of each person on the team need to be respected.
  • Others – there may be other values that are particularly important to certain types of projects, such as safety and security.

Core Principles of eXtreme Programming

Values are too abstract to directly guide behaviour. Specific principles are needed to guide the practices of software development.

  • Humanity – people develop software, therefore software development must meet basic human needs such as: safety, accomplishment, belonging and growth.
  • Economics – the project must have business value, meet business goals and serve business needs.
  • Mutual Benefit – every activity should benefit all involved. A practice should benefit you now, you in the future and your customer.
  • Self-Similarity – try copying the structure of one solution into a new context.
  • Improvement – get an activity started right away but refine the results over time (iterative development).
  • Diversity – teams need a variety of skills, attitudes and perspectives to see problems and pitfalls.
  • Reflection – good teams don’t hide their mistakes, they expose them and learn from them.
  • Flow – deliver a steady flow of valuable software by engaging in all the activities of development simultaneously.
  • Opportunity – problems need to turn into opportunities for learning and improvement, not just survival.
  • Redundancy – the critical, difficult problems in software development should be solved in several different ways.
  • Failure – if you’re having trouble succeeding, fail. Risking failure can sometimes be the shortest road to success.
  • Quality – sacrificing quality is not effective as a means of control.
  • Baby Steps – baby steps acknowledge that the overhead of small steps is much less than when a team wastefully aborts big changes.
  • Accepted Responsibility – the above practices reflect accepted responsibility by, for example, suggesting that whoever signs up to do work also estimates it.

Primary Practices of eXtreme Programming

The practices are the things XP teams do day-to-day. The primary practices are the key practices that need to be fully adopted before the secondary practices can be adopted.

  • Sit Together – having a big, open space, where people can sit together encourages communication, collaboration and co-operation. Privacy needs can be meet by secluded workstations around the edge of the area.
  • Whole Team – include on the team people with all the skills and perspectives necessary for the project to succeed.
  • Informative Workspace – make the workspace about the work. It should be informative: stories on one wall, tasks on another, etc.
  • Energised Work – work only as many hours as you can be productive and only as many hours as you can sustain.
  • Pair Programming – write all the production code with two people sitting at one machine.
  • Stories – plan using units of customer-visible functionality. As soon as a story is written, try to estimate the development effort necessary to implement it.
  • Weekly Cycle – plan work a week at a time. Have a meeting at the start of the week to review progress, have customers pick a weeks worth of stories and break the stories into tasks.
  • Quarterly Cycle – plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.
  • Slack – in any plan, include some minor tasks that can be dropped if you get behind.
  • Ten-Minute Build – automatically build the whole system and run all the tests in ten minutes, any longer, and it will be used less often, missing the opportunity for feedback.
  • Continuous Integration – integrate and test changes after no more than a couple of hours. The longer you wait to integrate, the more it costs and the more unpredictable it becomes.
  • Test-First Programming – write a failing automated test before changing any code. This helps address scope creep, coupling and cohesion, and trust.
  • Incremental Design – strive to make the design of the system an excellent fit for the needs of the system that day.

Secondary Practices of eXtreme Programming

The secondary practices should only be adopted after successful adoption of the primary practices. It would be dangerous to deploy everyday without a low defect rate (due to test-first programming, continuous integration etc.).

  • Real Customer Involvement – people whos lives and business are affected by your system should be part of the team. Visionary customers could be part of the quarterly or weekly planning.
  • Incremental Deployment – big “D Day” deployment hardly ever works. Deploy limited functionality at a time and run both systems in parallel.
  • Team Continuity – keep effective teams together.
  • Shrinking Teams – as a team grows in capability, keep its workload constant but gradually reduce its size.
  • Root-Cause Analysis – every time a defect is found after deployment, eliminate the defect and its cause. The goal is to make sure the team will never make the same kind of mistake again.
  • Shared Code – anyone on the team can improve any part of the system at any time.
  • Code and Tests – maintain only the code and tests as permanent artifacts. Generate other documents from code and tests.
  • Single Code Base – there is only a single code stream. You can develop in a temporary branch, but never let it live longer than a few hours.
  • Daily Deployment – put new software into production every night. Any gap between what is on a programmer’s desk and what is in production is a risk.
  • Negotiated Scope Project – write contracts for software development that fix time, costs and quality but call for an ongoing negotiation of the precise scope of the system.
  • Pay-Per-Use – with a pay-per-use system, you charge for every time the system is used. Money is the ultimate feedback.

So that covers the basic values, principles and practices of XP. For a more detailed look check out Beck’s book, eXtreme Programming Explained [aff].

This entry was posted in Software Engineering and tagged . Bookmark the permalink.