Values

The 4 values of XP are:


Communication

There are few activities where good communication is more important than in a User/Development team. An XP team is a mix of customers/users and technical staff. We have people of different competencies, different education, different personalities, different knowledge bases – and yet we must conceptualise the same ideas, the same processes and the same structures (or metaphors). Some of our members will be very young, some used to giving commands, some will think very logically and precisely while some will read body language and respond emotionally.

The biggest difference between computer people and business people is one has low “social needs” (and skills) while the other may be a very social creature (particularly sales and marketing staff).

We all need to be disciplined to play a team game where we know our individual responsibilities and we will ensure that our colleagues can rely on us. But on the rugby field tries are often scored by individuals exercising flair and individually. Others automatically move to provide support and cover when these unpredictable plays occur. On the net ball court we even learn to play to the space throwing the ball to where there is no-one but we know our player can get there first.

Good boxers, cricketers and judo exponents have practised their moves so frequently that they position instinctively and act unconsciously.

While we need checklists and cards to ensure requirements do not get dropped most communication takes place face-to-face. We need to read the body language. We need to know if everyone has bought in. We need see on each person’s face and read that they are “with” us and do understand.

So long white board sessions until we all understand the business issues and general environment.

So lots of stand-up meetings as we check that we do understand each requirement. The whole team must communicate well.

Each person in the pair must be able to read their partner’s mind. Each person on the team must be conscious of the need to educate other members in their area of expertise, knowledge and experience.

Bulky documentation does not communicate well. There are quite fundament reasons why computer “help” is notoriously unhelpful. Bulky written documentation can be difficult to change and adapt and usually slows our process.

Communicate face-to-face while standing up in front of a white board!  Top

Simplicity

When we prepare a map we decide what the map will be used for and remove everything that is not needed for the map’s purpose except context which will tell us where we are.

The reality of our city is hugely complex but the street map is very simple. It is easy to use provided we can locate where we are. As a nuclear physicist by training I admire Albert Einstein. A quote: “Everything should be as simple as possible, but not simpler!”

We must simplify each release as much as possible – but not cut out anything which is inherently part of release – without which it will fail.

Newtonian scientists operate to a culture which says “I will take the simplest theory which explains the facts and try to prove or demonstrate that the simple theory is sufficient”.

Every requirement stated by our customer will be examined in detail and initially implemented in a minimal form.

To achieve this we will look at the requirement and take a cut-throat razor to it. Can I remove any word from the statement? Can I remove “all” and replace it with a subset? In this implementation can I take this rare case and ask the user to just enter the answer the software would otherwise have to deduce?

For this release is it ok if the reports are simply tabulations? If data is missing from the legacy system can I just ask the user to fix it on the fly? User stories may be divided into tasks – can I get those tasks down to 1 pair day in size?

Flashes of brilliance are often conceptualisations where complex systems are suddenly perceived as “simple”.

Newton reduced mechanics to three sentences. All of Euclidean geometry has two objects, two operations and five axioms. If we think carefully about complex things they become simple. So every working session should end up with a final question looking only three weeks ahead: “Is this as simple as possible?”  Top

Feedback

Every engineer can explain that if a system does not have feedback it is inherently unstable. Without feedback systems will drift over time, possibly randomly, usually in a direction determined by the engineer.

But if the engineer is not receiving any feedback, the system will not satisfy the particular requirements of the user.

Not even the users have a perfect understanding of their own problems. So the solution provider without feedback cannot have a perfect understanding of someone else’s problem.

So the engineer will solve some problem brilliantly – but not necessarily the right problem. In XP we use the analogy of driving on a road at night. New Zealanders, with our roads, know that you do not determine to drive at 10 degrees east of north – one looks for the white lines and the reflective markers – and use this feedback to steer around the next bend. The short-term plan is just to follow the feedback, stay focused and steer carefully slowing when you can’t see beyond your stopping distance.

Feedback is useless if you do not receive it earlier enough. If the speed warning is too close to the bend, it is too late – you go off the road!

In XP this means that you must receive feedback on your last delivered code before you have moved too far forward.

The feedback must come from real users (if possible). Certainly when delivering bug fixes for a mature software suite they can be completed, delivered, put into real use and feedback provided within 24 hours.

The only people who can tell you the last delivery of functionality was great is the user. Try to design each delivery so you can get that feedback as soon as possible. You have not finished until the user says “Great!”.  Top

Courage

You will need courage to introduce XP.

You need courage to stand up and say “What we are doing does NOT work!”.

Some of your colleagues will be with you but some will be in CYA mode. “If we do it the conventional way we cannot be blamed if it fails.” How naïve!

Firstly you need to persuade your colleagues and gain their whole-hearted co-operation. We often joke about how hard it is to get programmers to agree on common standards. We need to persuade our peers to move into “pairs” as a normal way of working. We may have to deal with colleagues who cannot co-operate and move them out – hard decisions!

Having won the total mutual agreement of our peers we then have to persuade our users. Our immediate users can be persuaded simply. They understand the benefits of seeing deliveries quickly and that this will give them confidence that the solution in its final form will be useful and valuable.

But top management and project managers may be different. When lawyers are involved their thinking is based on precedent and not on the future. They will try to make us commit to fixed price fixed delivery date and ill-defined product. This is where you will need courage.

Finally you may need the courage to walk away when management is in “bully” mode and not in enablement mode.

But there is tons of work out there and your courage will reward you with the greatest challenges.