Extreme Programming (XP)
Jump to navigation
Jump to search
Extreme Programming or XP for short is a collection of technical practices that provide a focussed and lightweight approach to software development and creating value for the customer. It is not a methodology or a set of rules, but rather a toolbox of practices that can be very handy for a Development Team to use within the construct of a Sprint to deliver a high-quality Increment.
XP Values
- Communication – rapid and effective communication warts and all to interested stakeholders
- Simplicity – using the simplest approach is easier and more sustainable
- Feedback – actively seeking out feedback to constantly learn and adapt
- Courage – to try new approaches and build honesty and trust within the team
- Respect – caring about other team members and recognising their opinions and observations
XP Principles
The XP principles include:
- Humanity – providing basic safety and equal voice in the team and to approach things in a human centric way
- Economics – focussing on the return on investment with a bias towards low cost of development with a high return in customer value
- Mutual Benefit – focussing on providing a win-win approach for the technical journey and customer value
- Improvement – a focus on continual improvement and refinement with respect to regular feedback and learning rather than producing perfect first-time outcomes
- Quality – provisioning for the ability to build quality into the product and recognising the economic impact of improved quality
- Accepted Responsibility – an understanding that each team member who volunteers for the work also accepts responsibility for it
Primary Practices
The Primary Practices underpin the toolbox of both primary and corollary practices and include:
- Sit Together – the whole team can interact and work much more efficiently when they can communicate and collaborate in high bandwidth intensity, which naturally happens when they are simply collocated together. For remote teams, this could also be interpreted as the ability to mentally sit together within a virtual eco-system that fosters instant collaboration and interaction with others.
- Whole Team – a cross-functional team of highly skilled people with all perspectives necessary to produce the work with a sense of “wholeness” rather than partial representation
- Informative Workspace – using the workspace to provide information about the project and the work, such as card walls for example, as well as a workspace that caters for human needs such as collaboration, social interaction as well as privacy and quiet
- Energized Work – provisioning for a sustainable working practice that includes periods of high intensity as well as periods of rest time. The intention here is to respect the human body and mind in order to be more efficient rather than working for extended periods of time with mediocre results
- Pair Programming – pair programming provides a highly collaborative interaction that yields high quality code and propels teams forwards with new ideas and creativity, however, personal space must also be respected
- Stories – using conversation reminders to interact with the team and understand the needs and context rather than relying on requirements and written documents to replace conversations
- Weekly Cycle – in XP the working cycles are set to a weekly rhythm to provide high intensity and opportunities for feedback and adaptation
- Quarterly Cycle – as a form of release planning, the quarterly cycle sets a project horizon as a longer rhythm that supports interactions with suppliers and stakeholders
- Slack – providing some slack time e.g. 20% of the working week to provide opportunities for learning and thinking can be invaluable and has indirect benefits for the product as more improved and efficient ways of doing things are allowed to emerge
- Ten Minute Build – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.
- Test-First Programming – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.
- Continuous Integration – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.
- Incremental Design – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.
Corollary Practices
The corollary practices also include:
- Real Customer Involvement – having access to real customers that can provide accurate and meaningful feedback will have a dramatic effect on the end product, its usefulness and the trade-offs needed when working to timelines
- Incremental Deployment – releasing often will small amounts of risk seems to be better than releasing infrequently with large amounts of risk, as the team get more practice at releasing and each release can be rolled back instantly. The impact to customers and users is also reduced with more frequent releases reducing the need for training and other modes of knowledge transfer.
- Team Continuity – working with long running persistent teams avoids the ramp up and ramp down between projects, and preserves a well running team rather than disbanding them after a project. A positive side effect is the longer running teams develop some deep skills and domain knowledge, and after a while evolve into product teams rather than project teams.
- Root Cause Analysis – determining the root cause rather than the superficial cause can yield a deeper understanding of the issues and uncover deep dysfunctions. Arguably it is more cost effective to fix the underlying issues rather than apply the short term workaround.
- Shared Code – shared code ownership is intended to encourage a Development Team to collaborate to create the software assets, improve their quality and resolve issues as and when they are detected rather than depending upon single individuals to “own” parts of the code until completion.
- Code and Tests – the intention is to only produce artefacts that contribute to what the system does today and what the system will do tomorrow, with everything else being waste[16]. Hence, the code and the associated tests are intended to be the long living artefacts which can then be used to regenerate other artefacts, such as documentation.
- Single Code Base – avoiding making additional versions of the code and increasing the complexity, but instead, focus on fixing underlying design issues on a single version of the code base instead. Some code repositories use a branching approach, however, these are intended to be short lived and temporary before being merged back to the main “trunk” and back into the single code base.
- Daily Deployment – evolving to a point where the software assets can be deployed into production every day reduces the impact of change and risk, and enhances the software development practice into a constant refinement activity, rather than delivering an impactful change.
- Negotiated Scope Contract – the intention is to migrate away from fixed contracts, and instead, move towards an agreement that satisfies both customer and supplier with less specifics, more smaller agreements, and a move towards time and materials with constant collaboration.
- Pay Per Use – using customer revenue as a form of feedback for systems that charge for their usage helps to align relevant and useful features to the economics and the return on the investment
See Also
References
- Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005
- http://www.extremeprogramming.org accessed 03 January 2018