🍃 Leaf

Extreme Programming

Extreme Programming (or just XP) is a software development methodology based on Agile. It was designed to improve productivity by including the customers into the team as well as making frequent and small releases of working software. Thus adding value often, easing communication and feedback, and quickly responding to change on system requirements. And as a side effect, also reducing long-term risks since we avoid accumulating problems over time.

XP Origins

XP was introduced in the late 80s and early 90s (first used on March 6 of 1996) by Ward Cunningham, Kent Beck, Ron Jeffries, Martin Fowler, Don Wells, James Shore, among others to address the constant change of requirements. Said changes not only came from customer decisions, but also from dynamic environment factors (such as market trends, business priorities, nature conditions, etc.), which are often unavoidable and hurts productivity.

It resulted in a set of practices for the Chrysler Comprehensive Compensation project (or C3, the “birth project” of XP), practices later isolated and named “Extreme Programming” under the slogan “Embrace Change.” It was one of the first Agile methods. Agile and Lean (from the Toyota Production System) served as the inspiration and foundation for the XP values.

What Makes XP Different

Understanding the importance of potent teamwork, developing skills in adaptive planning, and close collaboration with the customers and users of the resulting software … enables teams to learn more about what is valuable. (The Art of Agile Development)

It’s usually executed by small teams of 2 to 12 people including managers, testers, developers, and customers. A group known in XP as the Whole Team. Work is based on interactions of 1 to 2 weeks long, ensuring it’s done at a sustainable pace for the long run.

XP has its focus on customer and business value over anything else and more than anything else. It drives us to concentrate on how to focus on value and how to deliver that value reliably. There are at least three concepts we can highlight:

XP Values

You are in harmony with your values when you are happy with your work. (Don Wells)

Most of them adopted from Agile, XP values are (but not limited to):

Process & Practices of XP

Often called Rules, they are divided into five groups known as XP phases or stages. They define working conditions, process steps, and approaches for every discipline. In real life, many companies don’t use all of the XP practices, they just choose the ones that they find useful. However, a few such as working in frequent and small releases, test-driven development, and continuous integration are used in most of the cases for modern development projects.

Some of the most relevant rules are as follows.

The Planning Game

The overall project planning may be quantified by four different variables:

User Story

Often called just Story, it describes what the system needs to do so we can plan our work out from it. It’s written by the customer in a non-technical language with a low level of detail to then be used by the rest of the team to create time estimates.

Each story is a reminder to have a conversation. (The Art of Agile Development)

Stories are then broken down into task cards which are no longer written in the customer’s language but in the developer’s language, which is technical and more detailed. Developers will again estimate, this time, how much it will take to finish each task.

Two key characteristics every User Story has:

*Aka. “conditions of satisfaction” or “definition of done” in Scrum.

Ideating a Story, its Traits

The acronym INVEST can be used as a guide for creating User Stories:

Writing a Story, its Content

When writing User Stories we can give them any shape, there is not a mandatory standard, however, we often use Connextra, one of the most used Story templates because of its simplicity and straightforwardness.

Connextra looks like this:

  1. “As a … (role),” one of those who get a benefit from it.
  2. ”I need … (something),” the software feature to be developed.
  3. ”So that … (results),” the answer for why are we doing this.

CRUD can be used as a practical approach for defining what the user needs, it’s an acronym for Create, Read, Update, Read, four of the most basic and common operations in the world of software. It’s useful because it lets customers write a Story in a non-technical language, as it’s supposed to happen, but it also leaves a clear clue from the technical point of view as developers can directly translate that into data and functionality. CRUD promotes a common language between (often) quite different roles.

Estimating Efforts

(some from scrum theory…)

(what it is, who does it, when it is done, how is it done) estimation is done exclusively by the development team, units, hour, days, weeks, Story Points could be, absolute units, relative (estimation) units: value series: Fibonacci, or exponential, t-shirt sizing

Planning Poker: it is to purpose and discus different perceptions about the estimation of different team members about a given Story. Each member chooses a number and everyone reveals the number at once, discrepancies get addressed until every one agrees on a common value. It is a collective way of estimating for Stories that represent a significant level of uncertainty via consensus by combining multiple people’s knowledge and suggestions.

Special Categories, Epics & Themes

(modern concepts:)

Epics: an epic is just a special “category” of Story, it’s a large user story that is practically impossible, or technically not reliable, for making an estimation which represents an entire business work flow or process containing many requirements, actors, and functionalities.

Themes: it is a way to tag or categorize Stories under a common topic/attribute.

Splitting and Combining Stories

We can leverage Stories’ complexity by combining several stories into a single one, or by splitting one into more specific ones. It is important to keep in mind that modified User Stories must remain customer-centric. Usually, combining User Stories is the easiest part, we can merge them by directly copying their contents when they are too short and highly related. However, conditions for splitting Stories tend to be more complex, e.g.:

Release

A release is meant to deliver working software in short periods of time, making it possible to add value often and to make changes easily as we don’t accumulate much work to do and fix. We run a release planning meeting (also known as the Planning Game) at the beginning of every release to create the release plan by letting the customer define which functionality has to be done at the end of the the release. Here we also define the release schedule which is negotiated and then committed by everyone involved in the project.

Iteration

Iterations divide a release into even shorter periods of time. Iteration planning meetings take part at the start of each iteration (as we do for the release) to, one more time, let the customer choose and prioritize the stories that need to be done at the end of the iteration.

Managing

Managing is the weakest point of XP, that’s why Scrum has been created.

Stand Up Meeting

Stand up meetings usually happen every morning involving the entire team which ideally attends to it in-person and standing up, to have a short (15 minutes-long) meeting to at least report working status and issues (if any), promoting focus and collaboration. Well-done meetings can be spotted through brief but effective communication, letting the team synchronize its working progress, and producing opportunities for people to coordinate efforts. After the meeting is over, team members can hold an “after party meeting” to follow up and have in-deep conversations about what was put onto the table during the main meeting.

It’s a much more efficient alternative when compared with the multiple, long, tedious, and unattended traditional meetings, keeping us from wasting large amounts of resources (time and people, thus money), also making them easy to be scheduled or not necessary to schedule at all—as they happen every day at the same time in the same place. Due to the short interval between instances, the team monitors its own work often, thus any impediment gets spotted early, avoiding expensive issues from growing up.

There is not a rule for strictly defining what should we say. However, one of the most common and basic paths is one in which every attendee answers three questions:

  1. What was accomplished since the last meeting?
  2. What will be attempted today?
  3. What problems are causing delays? (If any.)
More than a Status Meeting

Traditional bibliography/authors talk about these meetings as “status meetings,” nevertheless, they are much more capable than a data-sharing instance. Nowadays it’s clear that building solid teams, people that trust one another and are highly performant: depend on direct communication; feeds from real human interactions.

These meetings not only eliminate the need for other traditional, similar meetings, what makes them practical in terms of management, but also encourage people to exercise core values of Agile: Courage, Communication, Feedback, and Simplicity; as well as each and every pillar and the foundational value of Scrum: Transparency, Inspection, Adaption, and Trust. Hence, stand up meetings are a cheap way to enrich the traits a team needs to work as a team.

Attendants & Guests

Participants are the entire team of developers as the meeting is made by them and for them. The meeting is facilitated by the Scrum Master, who’s only interventions should be to ensure the conversation keeps on the right track (toward the sprint goal). Nonetheless, have other roles permission to join in the meeting? Yes, sure. Have other roles permission to interrupt the conversation? No, not at all. It’s important, yet sometimes difficult, to keep other stakeholders or interested people out from actively participating in the meeting to prevent shifting its focus and main intention. Other roles can attend but should not actually participate.

Project Velocity

A metric used to determine the event rate for the project by measuring either by time or by scope. Approaches known as Date Driven Commitment and Story Driven Commitment respectively. The initial estimate is just a guess (as we have nothing to measure), but then we take numbers from each finished iteration to know either: how many stories can fit within a given period of time; or how long it will take to finish a given set of stories. Velocity helps us work at a sustainable, measurable, and predictable pace, however, a few ups and downs are expected.

Whole Team

Growth and profit are a product of how people work together. (Ricardo Semler)

The group of managers, developers, and customers is known in XP as the Whole Team. It’s composed of people with diverse skills such as business experts, developers, designers, coachers, among others. These people build up a self-sufficient cross-functional, self-organizing team in which everyone works to broaden their skills over time, specially customer-related skills, one of the most relevant and difficult ones. Skilled people is the fundamental resource for the business to deliver a successful result with no exception.

When the Whole Team sits together in the same space, magic happen. (Clean Agile)

The idea of Whole Team makes great emphasis on the fact that customers are part of it because they are the ones who understand best what (final) users’ need. Reason for it to be initially called On-Site Customer. This makes every process faster and smoother as we reduce (almost at all) communication delays from the development to the customer and viceversa.

Sit Together

When people can’t communicate directly, the effectiveness of their communication decreases. It’s too easy for writing to be misunderstood. (The Art of Agile Development)

It is another key concept related to teams. It is to have a dedicated open work place. Thus enhancing communication and encouraging everyone to participate with the feeling of equal value and contribution, letting people to work either in pairs or alone with no distractions, but at the same time, without becoming disconnected from the group. Boards and blank walls for sketching and posting user stories are a perfect channel for communication. Areas for daily meetings keep people from missing them, encouraging everyone to listen and join.

Designing

On Simplicity

Simplicity is the ultimate sophistication. (Leonardo da Vinci)

Do the simplest tasks first to only then refactor incrementally if needed. Simplicity is hard to measure because it’s a subjective quality. One person’s simple could be another person’s complex. It requires domain knowledge to know when something is simple and adequate. However, we can measure qualities such as how testable, understandable, browsable, and explainable something is (aka. TUBE). At the end, the team decides what is simple, that’s key for XP to be reliable.

Related and well-known XP practices:

Spikes

A spike is a prototype-like software meant to explore potential solutions and difficulties for a very specific problem, a concept similar to Minimum Viable Product (MVP) but for a single (or small group of) features defined by a single user story. As a result, a spike helps to reduce technical risks and increase estimates’ reliability. Usually they are discarded after use, as they tend to be not good enough to keep. That’s why we must keep them short and simple.

Refactoring

Always leave the code a little better than you found it. (The Art of Agile Development)

Read notes at Refactoring (docs-and-notes).

Coding

The Customer is Always Available

Most XP practices are optional or context-dependent, however, to have the customers always available is actually a requirement. All project phases require constant communication with them, preferably face-to-face as on-site customer. They are an actual team member.

They are the ones who write the user stories. During both release and iteration planning meetings, customers choose which stories are to be done. They also negotiate the timing to be scheduled. Before the coding job starts, customers detail each user story. Once a piece of software is working, they give early feedback to the team. When doing functional testing we require them to help with the desired data for each use case. Customers review and decide if it is good enough and what must be fixed or changed through acceptance tests before code is deployed.

Code Standards

The development team needs to agree on the coding standards they consider optimal. Code that looks consistent and familiar encourages collective ownership. Code that follows the same rules and has the same format makes it easy for everyone to find, read, understand, and refactor as we don’t need to waste time thinking which way to do it.

Test-Driven Development

Read notes at Test-Driven Development (docs-and-notes).

Pair Programming

Read notes at Pair Programming (docs-and-notes).

Collective Ownership

Programming is a social activity. (Robert C. Martin)

The whole team shares responsibility for its results. If something goes wrong, we work together to solve the problem; if something goes well, we all takes credit for it. This also warranties that knowledge will remain in case somebody leaves the team. We should be always available to assist who needs help and learning how to contribute to work we don’t yet know well. Team members can work on a different task independently, however, it’s better to tackle one story at a time, so work in progress will be minimal and risks will get exposed early.

Egoless Programming

It does seem that the general level of competence of such a group is likely to rise itself. (The Psychology of Computer Programming, Egoless Programming, page 60, Gerald M. Weinberg, 1971)

We need to let go a bit of ego. Enjoy sharing and building together. Accept that our solutions could be improved or fixed by others. Rather than thinking “my code,” think “our code.” Exposing other person’s weak points and mistakes is an opportunity for conflict to happen, however, it is a good thing, it helps us align our styles. That’s why we follow coding standards and do pair programming (among other practices), they help us smooth the process.

Secretive, possessive programming [is] bad … open, shared programming [is] good … Errors [are] simply facts to be expected to investigation with an eye to future improvement, not attacks. (The Psychology of Computer Programming, Egoless Programming, page 57, Gerald M. Weinberg, 1971)

Gerald M. Weinberg published “The Psychology of Computer Programming,” book in which he introduced the concept of Egoless Programming. In it he describes timeless facts such as:

Continuous Integration

XP encourages to commit code multiple times a day, we should never wait more than 24 hours to integrate a new change. To achieve that, we all need to work with the latest version of the system. Communication among developers is critical to keep integration smooth, it’s important for them to share information about what can be reused and shared.

The main idea is to standardize and automate the integration process, thus we can take releasing as a business decision instead of a technical problem. Instead of thinking how will we get all our code to work together every time we need to release a new version: we just press a button. By consequence, continuous integration helps us detect and avoid compatibility problems from being accumulated.

Testing

Unit Testing

Read notes at Unit Testing (docs-and-notes).

Acceptance Testing

An acceptance test ensures a user story has been successfully implemented or it is at least acceptable by the customers’ judgement. During iteration planning, customers not only select the stories we will work on, but they also specify scenarios and expected results for the respective acceptance test of each story. Several tests are often defined for a single story. At a certain point before deploying the new code, we demonstrate the current software to the customers, then they decide whether or not to proceed based on their domain knowledge.

Benefits of XP

Reference: