Extreme programming – XP

Extreme Programming framework, Extreme Programming methodology, XP practices, XP values, XP agile methodology, XP principles, XP meaning

Extreme Programming (XP) is an lightweight, iterative, customer and developer focused agile software development methodology that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development and while other agile frameworks like Scrum and Kanban are focusing on the process, extreme programming focuses on the agile development practices and many of the agile concepts and practices used in software development are coming from XP.

Extreme Programming – XP

Extreme Programming – XP – focuses on software engineering best practices, stresses code refactoring and paired programming and it values teamwork, collaboration and shared workspaces. XP is also relying on frequent feedback and feedback at different time scales, from months to seconds, from release feedback, iteration feedback, standup meetings, acceptance testing, pair-programming and unit testing.

XP takes good development practices and amplifies them to the extreme. Software testing is amplified to the extreme, teams using Extreme Programming try to test all the time during the development life-cycle, also involving automated tests and this is called test-driven development or test-first development. Code review is amplified to the extreme, XP teams review the code all the time with a partner, calling it pair-programming. Building and integrating code is also done to the extreme levels, by building and integrating frequently, and this is called continuous integration.

Extreme Programming values

  • communication – team members work together and collaborate at all stages
  • simplicity – simple code saves time and effort for developers and increases product value
  • feedback – team delivers software frequently, while getting feedback and improving the product accordingly
  • courage – developers objectively evaluate results of their work and embrace change
  • respect – team members contribute to a common goal

Extreme programming principles

  • incremental changes
  • assumed simplicity
  • rapid feedback
  • embracing change
  • quality work

Extreme programming practices

  • User stories – tell a story from the user’s perspective, they follow the template of having a title, a main character/stakeholder, what the user wants and why, additional details and the acceptance criteria for the user story
  • Release Planning – large scale feedback and planning session occurring every few months by gathering the entire team and stakeholders to plan the work and product deliveries for the next few months, while getting alignment on what will be achievable, what are the risks and what can be done
  • Iteration Planning – medium scale feedback and planning session occurring every few weeks, planning meeting where team and customers draft the plan for the next iteration of work and deliverables, deciding what and how will be done in the iteration
  • Standup Meetings – small scale feedback daily meeting used to inspect progress on the iteration plan and adapt the work of the team to complete the plan successfully, opportunity for the team to self-manage, inspect progress, reorganized planned work, ask for help and remove impediments
  • Test Driven Development (TDD) – fine scale feedback practice – acceptance tests offer small scale feedback in terms of days and unit tests offer fine scale feedback in terms of minutes, writing automated unit tests before writing the code, coding just enough to pass the test at every step, focused on passing the tests at each step until the final result is reached and then improving and simplifying the code
  • Pair Programming – fine scale feedback practice where two developers working on the same code on the same computer solving the same problem and switching roles at very short time intervals, one writing and the other reviewing the code, suggesting improvements and fixing errors
  • Continuous Integration – is merging every developer’s code together, building it and testing it several times a day, while developers communicate and share or reuse code, limit integration problems and use automated tests to fix errors before deployment, Continuous integration steps: developers work in pairs to write tests and code, then they make sure the code passes all tests in their private environment, then they commit the code to a shared repository, the CI system notices the new code in the repository and checks all the code and builds it, if the build is successful, the CI system deploys the code onto a test environment where all the automated tests are executed and it updates the status to show if it was successful or not
  • Code Refactoring – is incrementally improving the internal structure of existing code without changing its external behavior, keeping code simple, easy to understand and to modify later by continuously improving code, removing redundancy, eliminating unnecessary parts, increasing code coherence and decoupling elements
  • Small Releases – the practice of delivering small increments of working software frequently, release a Minimum Viable Product (MVP) sooner and then update the product incrementally with small releases, receive feedback frequently, detect errors early and monitor the product in production
  • Collective Code Ownership – the whole team is responsible for every line of code and each team member is able to review and update code, figure out where to write new code for the new features, avoid duplicate code, cooperates more and brings new ideas
  • Coding Standard – team has a common set of coding practices and a collective ownership of the code, using the same format and style for writing code, which allows every team member to easily read, track, share, learn and refactor code
  • Simple Design – the best technical design should contain the fewest possible methods and classes, have reduced complexity, must be understandable to new team members to allow them to start working on it faster and write code just for the features that are currently being implemented
  • System Metaphor – is a shared story that every team member can tell about the product and how it works, the metaphor makes it easier to understand the design and functionality of the code, it provides guidance on coherently naming of classes and methods, while objects are named as if they already existed
  • Sustainable Pace – developers must work at a sustainable pace indefinitely for every iteration, not going too fast or too slow
  • Programmer welfare – reminder that software developers are humans and that they should take care of their health, keeping a work-life balance to prevent burnout and avoid as much as possible the need for overtime work

Extreme programing roles

  • Customers
  • Developers
  • Trackers
  • Coaches

Agile frameworks