Any team working on its own or a client’s project faces the fact that without a clear management methodology, chaos will quickly ensue. This chaos affects all aspects: relationships between participants, interaction with clients and external partners, funding, deadlines, etc. In the end, the project falls apart before it is completed.
In the following, we will take a closer look at one of the agile software product development methodologies — Extreme Programming.
It is fair to say that other types of project can be managed using the principles underlying this methodology. Such management will also be called extreme management.
So let’s get started.
What is Extreme Programming?
Extreme Programming (XP) is a methodology for managing IT projects or software products developed by Kent Beck and tested in his work on large projects. The methodology is based on close interaction between participants, including customers, continuous feedback, ease of implementation and the courage to take responsibility.
At the same time, the development team (i.e. the executors) are not expected to make any fateful decisions. It is assumed that they will only do what the customer or client has asked them to do. Nothing new or additional.
Values and rules are very important in the extreme programming paradigm. It does not work without them. To implement the methodology, all participants in the process must accept the declared values and rules. More about them below.
Values of Extreme Programming
Values are the most important element of the methodology. They will be above the rules in the hierarchy of priorities. You need to know this and take it into account, especially in complex and controversial situations.
Another interesting point: you can start with the values set by the author, but later add your own to the list.
There are only five extreme programming values:
- Simplicity.
- Communication.
- Feedback.
- Respect.
- Courage.
Now a little more detail on each value.
Simplicity
Because investment that is relevant now is most valuable, implementers should do only the tasks that are necessary and assigned to them, rather than doing what they want or think is more logical.
The steps to the goal should be as simple as possible. And failures and missteps along the way should be mitigated as soon as they are identified.
Developers should make a product for reasonable money that they can be proud of in the long run.
Communication
Everyone involved in a project is part of a team. All tasks and problems must be tackled together. The result of the project is the best that the team can create together, i.e. according to the available possibilities.
Feedback
At each iteration, the team shows the working product to the customer. The team then listens carefully to the customer’s wishes and comments. Necessary changes are made based on the feedback.
The product being developed is the focus. That’s why we need to talk about it and adapt our work processes to it, not the other way round.
Respect
Every member of the team is important and contributes in their own way. This applies not only to relationships within the team, but also to relationships with the outside world. Developers should respect the experience of customers, and customers should respect the experience of developers. Project management should properly understand their management authority and respect the developers’ right to make independent decisions.
Courage
It is necessary to be level-headed about the current progress and reviews of the product. The team needs to succeed, so they need to take feedback and failures into account and adapt to changes as they occur.
Rules of extreme programming
This is roughly how the XP development process works.
The rules are divided into main groups.
Scheduling rule group
- User stories should be written.
- Release planning should lead to a release schedule.
- Focus on small and frequent releases.
- The project should be divided into iterations.
- Every new iteration starts with planning.
User stories are used to understand product use cases and to correctly estimate implementation time. User stories can easily replace a large and unnecessary requirements document.
Stories are written by customers or clients. In them, it is important to describe what the software system should do (for them or to them, what tasks it should solve).
Based on the user stories, a system of acceptance tests should be developed to understand whether the system solves the set tasks or not.
The time of working on a user story should not exceed 3 weeks (usually a cycle of 1, 2 or 3 weeks is used). Otherwise, the story needs to be more detailed and broken down into components. If the implementation takes less than a week, it means that you have over-detailed the story.
The time is considered to be full load. This is when the team is only working on one task and is not distracted by other tasks.
In the release plan, the number of stories should be 80, plus or minus 20.
In planning meetings, technicians should be responsible for decisions on technical tasks, and business people should be responsible for business tasks.
Each user story is designed as a card and moves around the desktop or whiteboard, forming a set of stories to be worked on in the first (next) release.
At this stage it is best to replace the physical cards with a convenient information system — task tracker.
A very interesting point. At the planning stage, when the release schedule is already in place but still not satisfying the investors, it may be tempting to adjust the timing of individual user stories.
But you should never do this, or you will end up with potentially more problems in the future. It makes much more sense to drop some stories, or rework all the release plans, until you get the best options that suit everyone.
Although a full working version of the product may not be available soon, the team can release a customer-only test version, even every day, so that they can quickly track progress and adjust the list of user stories if necessary.
The longer the release cycle, the less time there is to fix problems as they are discovered.
Each new development iteration should include the user stories that are most important to the customer.
Group of management rules
- The team should work in a single open space.
- A steady pace of work is set (mainly due to correct iterations).
- The working day starts with general meetings (stand up meetings).
- Project speed is measured regularly.
- Rotate specialists — they can be moved between tasks.
- Don’t be afraid to fix those XP processes and rules that get in the way or don’t work.
An open workspace is the key to rapid communication between participants, and communication is one of the key values of XP.
In this format it is easier to organise pair programming, have quick meetings and discussions, ask questions directly and get answers quickly. Even if team members are not involved in direct discussions, they are sure to be aware of everything that is going on.
No less convenient will be shared virtual spaces, e.g. services where you can draw design sketches and discuss individual elements, add your comments, notes, etc.
A single shared chat room (workgroup) is also an open space format.
Cross-training with the movement of employees by tasks avoids situations where so-called islands of knowledge are created. In this case, the loss of one or more core developers can be very painful. This is why it is worth diversifying the knowledge on the project.
Keeping up the pace isn’t really about proper development cycles or iterations. It’s about completing tasks. If, at the end of an iteration, you’ve done a lot of work but haven’t completed any tasks (user story), that’s bad pacing.
If you are not meeting deadlines, simply increasing the number of people working on some tasks will not help. In such cases, the team should be expanded gradually, where necessary. Otherwise, you may have the opposite effect and make the situation worse.
The first daily meetings should be as short as possible. It is logical to discuss only urgent problems. There is definitely no need for summaries or information that would only take up team members’ time.
Group of design rules
- The design should be simple.
- Choose a system metaphor.
- Use CRC maps for design sessions.
- Create quick solutions to technically complex problems (spike solution).
- Do not add features up front.
- Use refactoring whenever and wherever possible.
Of course, simplicity is always subjective, but there is no need to complicate things. Typically, characteristics such as understandability, testability, visual accessibility and explainability are used to evaluate tasks.
A system metaphor is a short description of the essence of your project. It is how you would explain to an outsider what you are working on. In fact, it is the purpose of your project.
CRS stands for Classes, Responsibilities and Collaboration. These are special cards that help to plan the development process. They identify system objects (classes of objects).
Group of programming (coding) rules
This is something that is directly related to the development process.
- The client should always be in touch (available for questions).
- The code is written according to pre-agreed standards that everyone is happy with.
- The unit test is written first.
- All code is written by pairs of programmers.
- Only one pair integrates their code into the project at a time.
- Integrate code as often as possible to keep the code base as up-to-date as possible.
- Allocate a separate computer/workstation for integration.
- Use collective ownership of the code (the whole team is responsible for the code, not just one person).
Note that pair programming, like collective code ownership, does not involve a student-mentor approach. Everyone works with equal rights. Rather, another pair of eyes is needed for operational control and to get an alternative point of view, i.e. a multi-faceted evaluation of the chosen approach.
Group of testing rules
- All code is necessarily covered by unit testing (it is like a direct analogue of continuous checking and automation at the same time).
- Before being released or integrated into a project, the code must pass all tests.
- If bugs are found, new unit tests are created.
- Acceptance tests, based on user stories, are run as often as possible so that the result can be released more quickly.
Instead of totals
Extreme programming has many supporters and opponents. However, it is important to realise that XP is not a rigid set of rules. The principles outlined above can be modified as their effectiveness or ineffectiveness is determined.
As a result, it can be found that XP is similar in many ways to other popular software project methodologies. The differences between them are often subtle and can be blurred under certain conditions.
