Extreme Programming (XP)

Extreme programming is programming to the EXTREME! I know it sounds silly when I exaggerate it like that. We don’t often refer to extreme programming by its full name. instead, we only hear it called XP. As you know, acronyms are common in the software industry, and we usually refer to things by their acronym rather than their formal name.

Despite being a software ­centric agile method, there are plenty of uses outside of software. For the most part, agile’s references and concepts are usually only presented in a software­ based context, so I’ll discuss XP in the context of software development and software development best practices. Because of this, a lot of what we cover here will use software development terminology. If you work in a technology field, then our discussion will make sense and you will have a much easier time applying it to your day­ to ­day work. If you don’t, I am going to try to keep the software development jargon to a minimum to assist you in learning this material.

One of the major pieces of XP is its reliance on “user stories.” User stories are the lightweight requirements expressed to communicate the user needs and expectations through a persona. Not only are explicit functional needs expressed — such as the background including the logo for this particular part of the app and displaying all the employee’s benefit providers on one screen — but also implicit needs, such as the reason or rationale behind why benefit providers are displayed so that the employee can see at a glance all the benefit programs they are currently enrolled in. They’ll be able to see where their coverage may be lacking and have the ability to navigate to the benefit they are interested to learn about or do more with.

Good user stories should fit a certain set of criteria. The acronym INVEST is good mnemonic to remember the criteria.

  • I stands for Independent.
    • Every user story should be able to stand on its own. It should have its own outcome: whether that outcome is a deliverable, such as the app page displaying provider names, or a result, such as a decision on what table architecture to use.
  • The N stands for Negotiable.
    • The user story is not a contract, but an invitation to a conversation. The essence is expressed in the user story, but the actual result is a discussion and collaboration between team and customer.
  • The V stands for Valuable.
    • If it provides no value, then why do it? The whole point of working on something is to get something of value from it. The “value” is determined in the eyes of the user, whether that user is the customer, the company, the end user, or the development team, there must be value gained from the effort.
  • The E stands for Estimable.
    • If you cannot estimate it, how are you able to schedule it, prioritize it, and otherwise manage it? Time boxing is one of the cornerstones of agile project management, XP included.
  • The S stands for Small.
    • When you are wrestling with the idea of how large of an endeavor you are looking at when attempting to estimate and keep it independent, remember that smaller is more manageable. Larger stories add more complexity and variability. Risks increase with larger stories because unknowns and uncertainties are much greater.
  • T stands for Testable.
    • If you cannot test it and agree to accept its finality, then how can the user story ever be considered “done”? As we discussed earlier about the purpose of defining when a project is truly done, a good user story needs to have that defined at the start and build quality assurance from the get go.

XP Core Values:

Extreme programming is an agile discipline based on the values of simplicity, communication, feedback, respect, and courage. By using simple designs and operating with less complexities, the whole team can communicate effectively with useful feedback because they have the encouragement and respect of their peers to work openly and accept constructive criticism.

Let’s examine the core values of XP agile management:

  • Simplicity​ forces the team to consider and focus on the simplest solutions. As such, waste, complexities, and mess that can mangle teams and their production should be removed. The aim should be to always do the simplest thing that works with your project.
  • Communication​ is the constant flow of information, collective wisdom, and the ability of the whole team to always be in the know. These are just a few of the important attributes of communication. Like in Scrum project management, the use of daily stand­up meetings are used to encourage the regular flow of knowledge and as a sharing forum.
  • Feedback​ is getting input and others’ perspectives early, and is often invaluable. Failing early and softly is better than failing late and hard.
  • Respect​ is required to gain good feedback and the lessons provided in the feedback, free of ridicule and shaming. Conducting yourself with respect for self and others, and demanding respect from others, encourages the entire team to contribute, be productive, and gain from each other.
  • Courage ​is the final core value. To appreciate and effectively use the feedback and support of others, the individuals of the team, and the team as a whole, must have the courage to accept feedback, learn from their mistakes, and have the confidence to be bold and try new things. That also includes having the courage to share code and present work publicly to others. A common trend in many software development environments is to have shared code that everyone works on together

Leave a Reply

Your email address will not be published. Required fields are marked *