Extreme Delivery

Many of the principles and practices that we now consider to be part of agile development were first presented in 1996 by Kent Beck under the name Extreme Programming (XP).

Many of these best practices were already known, the view that Beck put forward was that these things were so beneficial there use should be taken to extreme levels.

If doing a little of something yields some benefit then doing a lot of it should lead to large benefits. 

Extreme Activities

The approach to XP can be divided into four categories, coding testing, listening and designing.

The goal of software engineering to provide code that is a solution to a problem, therefore working code is the most important output of the team, all other aspects of how the team works should be aiming to ensure this code is efficiently produced and is the solution the customer needs.

The key description of the code is working, this can only be determined by testing. We take testing to extremes in terms quantity, frequency and tenacity in ensuring all errors are dealt with. We realise that the only way to achieve this is via automation.

So now we have an efficient pipeline for producing working code we need to ensure this code fixes the correct problem. We do this by listening to users, whether existing or potential, we realise that they are the only ones that define the problem that they need solving and only the will ultimately rubber stamp our solution as effective.

The transition between the knowledge we gain from listening to the output of working code is delivered via design. We do value design, we also realise that a law of diminishing returns applies to its effectiveness.

Extreme Design

The goal of our extreme design is not to formulate a solution to the whole problem, it is instead to provide an effective solution to a certain scaled down version of the problem with enough flexibility to provide a roadmap for fixing the bigger versions of the problem to come.

In the design of our code we value communication, simplicity and feedback.

The most effective form of communication between developers is code, it breaks down barriers and communicates ideas and principles. But it can only do this when its written to be clear and concise, we design our code to communicate its purpose via skim reading not via having to tackle a large unwieldy novel.

Problems in software are always related to complexity, sometimes this complexity is essential, the problem we are trying to solve is by its nature complex. But when we have it within our control we should prefer simplicity in solving the problem at hand at not choose to introduce complexity to solve problems that we don't yet know need solutions.

This concentration on simplicity means we must have effective channels for feedback, we will need to gradually increase the level of complexity to continue to offer value to the user. We also must design our code such that it can provide feedback on its current state of health, we do this by making our code testable and capable of testing itself. We aren't satisfied that the solution appears to work we want to ensure that under the hood it isn't by luck or magic but by design.

Extreme Delivery

All of these extreme practices are aimed towards delivering on promises. But this extreme approach is related to the speed and frequency at which we deliver, we aren't attempting to solve an extremely large problem in one fell swoop, we are attempting to solve an ever increasing number of small problems at an extreme rate.

This is only achieved via flexibility, our code must be designed to expect to be continually re-factored, re-purposed and re-used.

We also need to be flexible in our approach to our users, feedback from them may not always be coherent or easy to work back into the product. We need to realise the responsibility for this lies with us and not the user, it is our job to coax out of them what problem they need solving not to tell them what will make there lives better.

As with most things in life problems can occur when things are taken to extremes, but the majority of teams are nowhere near this barrier and will nearly always have something to gain from trying to turn the dial up to 11.