“Always be doing the most important thing that you can be working on.” – Kent Beck.
While Scrum puts more emphasis on project management, XP is more focused on programming. XP surfaced from the need for flexibility, speed and quality. None of the XP practices are wholly new, but it takes existing ones to a new (extreme) level.
Although XP is older than Scrum, this entry comes second, presenting a comparison between the two; without covering user Stories, ‘Estimates or Acceptance Criteria.
Teams and people involved in XP:
The Product Owner role is assumed by:
- On-site customer; which is not necessarly an end user
- Stakeholders
The Scrum Master role is replaced by:
- Coach; which acts as a mentor, ensuring XP stays XP
- Tracker; performing administrative tasks
Instead cross-functional Scrum Teams, XP teams have clearly defined roles:
- Developers
- Testers
- XP teams do not have the analyst role
Similarly to Scrum Sprints, XP has Iterations, which usually last for 1 week each; occur at regular intervals; with the goal that at the end of each heart-beat, software is delivered. However, unlike Scrum, XP has a non-regular release interval. Each iteration is preceded by an iteration level planning meeting (Planning Game).
XP Practices
Planning Game
Customers and developers decide the scope for the next release; with customers prioritising items and developers contributing with stories. The Planning Game includes a Release Plan, consisting of stories assigned for each iteration.
Small Releases
“Every release should be as small as possible, containing the most valuable business requirements” – Kent Beck
According to Jim Highsmith, “the cost of each release – installation, training, conversions – need to be factored into whether or not the features delivered at the end of an iteration are actually released to the end user or simply declared to be in a releasable state”.
Metaphor
Provide an overview of the project’s goal; aiming mainly at developers and to a lesser extent to customers.
Simple Design
Design for the required functionality; not for “potential” functionality.
Testing (unit and acceptance)
Get instant code ‘feedback’, by writing tests first and running automated tests against written code.
Development life cycle:
1) Gather requirements
2) Test
3) Code (using pair programming)
4) Design (or refactor)
Refactoring
Improve the internal code structure, to increase it’s responsiveness to change. Works hand in hand with factoring, and design patterns.
Pair Programming
Software reviews aid learning and uncover defects. Pair Programming takes inspections to a new level, by allowing two people to simultaneously program. While most companies find Pair Programming hard to accept and adopt, the goal is increase code quality. It consists of two people sitting side by side, with one developer writing the code; and one developer writing tests. Developers are usually helped by a Pair Programming coach.
Collective Ownership
Any developer can change any part of the code, at any time. Each developer should work and have knowledge of each part of the system. If a developer leaves the project, this ensures knowledge is not lost.
Continuous Integration
Daily system builds; to ensure components work together.
40-hour Week
Do not work too much overtime. Maintain a sustainable pace.
On-site Customer
Ongoing, on-site customer/proxy user/domain expert involvement; to insure constant feedback and access to knowledge.
Coding Standards
Aids collective ownership.
Iterations
First day:
Similarly to Scrum, each Iteration in XP starts with a Planning Meeting (Planning Game):
– lasting up to 2 to 4 hours
– can take up to one day, first time
During an Iteration:
Daily meetings (morning stand-ups):
1) What team members did, and what decisions were taken
2) What problems occurred
3) What will be done for the rest of the day
*) With a slight difference from Scrum daily meetings, the team team organizes for the day, based on answers to the previous questions
Testers work on acceptance tests; by communicating with the on site customer, to ensure that ‘Stories’ have been implemented as expected.
Developers communicate with the customer; and write code for their ‘Stories’.
Last day:
Unlike XP, the last day of an iteration may or may not produce demonstrable software; however, code must be delivered.
Retrospective.
NOTE: This is my first note about XP, and relies heavily on course materials from the ‘Agile Methods’ class, at Oxford University, ‘Agile Software Development Ecosystems’ book, by Jim Highsmith and ‘Extreme Programming: A gentle introduction’.
Note my skills at drawing arrows.