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.
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.
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.
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
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!”
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?
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
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.
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.
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
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.