The eXtreme Programming Values
The eXtreme Programming Values
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Values are more important than practices: the latter are only an aspect that can change to adapt to people (people over processes, remember?), but they're often the practical (what a pun) aspect of XP and of the Agile credo that is easier to teach. Francesco Cirillo said values in eXtreme Programming are not a marketing stunt: they are really a part of the methodology. So I tried to rediscover them by reading up and seeing where they apply to my experience in programming in the last years.
An assumption we make is that values should be aligned between the different components of a team, to avoid creating waste. If me and my colleagues continuously give importance to different things, we won't converge on an agreement but each will undermine the efforts of the others.
Solving problems is possible not only by concentrating for many Pomodoros, but also by communicating effectively with other people who have encountered them in the past. In this sense, this leaves you free of solve new problems instead of re-solving older ones.
Ask yourself if the next problem you encounter was caused by lack of communication (I will indeed do it.) Sometimes I may know a powerful solution and it does not get through to the rest of the team, just because of lack of communication with who has the power to make a change. A problem I see is my team getting good at object-oriented design but not at communicating their results to colleagues.
Simplicity is the most intensely intellectual value, according to Kent Beck. Make software simple enough to solve today's problem: software that however is different from yesterday's simple solution. The famous maxim here is the "simplest thing that could possibly work".
Simplest is part of the solution; but also work is. Code that passes the tests is the first rule of simple design. It also means that every requirement, functional or non functional, should be expressed as a test: the difficult in expressing some requirements in this form is not an excuse for justifying a complex design that maybe addresses them. Without tests, no one knows if the added complexity is worth.
This value is linked with the first one: improving communication (e.g. with the customer) helps simplicity because it eliminates unneeded requirements; improving simplicity in turn reduces the amount of information to communicate.
In [software] engineering, the less moving parts a solution have, the less probably it will break (that's why SSD are robust to bumps and hard disk are not.) There is no redundancy in software components like in hardware: if a single class break, the whole system may break.
We need to ask ourselves: is the code we wrote today really the simplest solution or I'm already introducing complexity by cheating and preparing for a requirement in advance? I joked about double-blind development (DBD): telling the developers one requirement at the time to train them in evolutionary design instead of in change prediction.
Here's another comparison with engineering: feedforward control system, which tries to build a model of the system to control and regulate input variables, are not very diffused. Feedback system works better, if they are well-designed: the thermostate in your home is an example. You set a temperature and it activates until it gets the feedback from its sensor that the temperature has been reached.
A model of software development is impossible to build, since it involves people (highly non linear if you want a technical term, and with strong stochastic properties). Feedback helps:
- feedback on design and working code from the tests.
- Feedback from the client by producing working software every two weeks.
- Feedback from the client by reprioritization at the end of an iteration.
- Feedback from your colleagues about the solution you found.
- Feedback on difficulties in the build process from setting up Continuous Integration.
- Feedback on ultimate performance from continuous deployment.
But these are only examples: the value resides in looking for feedback in new scenarios. In some areas, the shorter the cycle, the better; unit tests give you a 30-second feedback cycle on small parts of the system. In other areas, teams must be protected by rapidly changing feedback (e.g. by reprioritizing stories only at the start of an iteration).
What we have to ask ourselves here is: am I ignoring feedback? Or how can I get some feedback to reduce my risk? Again, values are linked: feedback arrives from communication channels. To find the simplest solution, you can get feedback by exploring different solutions and see which works better.
Courage is effective action in the face of fear. -- Kent Beck, XP Explained 2ed
Were we reading a book on software development, not the Lord of the rings, right? But we feel fear as everyone else: fear that the next requirement will be impossible to satisfy, fear that that we will take too much time to get this framework running, fear that the customer won't like our product.
We need the courage to tell the truth in communication, avoiding a Death March project. Courage of giving bad feedback to foster improvement, instead of hiding it (my code was a mess? Tell me where I screw up.) Courage to discard complex, ineffective solutions even if you have sunk costs on them (spent a lot of time to develop them.)
Respect (bonus value)
Respect underlies the other values:
- every member of the team must care about the project. Intrinsic motivation beats extrinsic one every time.
- Every person in the team should be respected, and not exploited. The pizza factor (number of evenings a month pizza is ordered for team members that stay working late) is not something to brag about.
These are the XP values, and I hope to have made a good job in describing them. You can add your values to the picture, if they are shared by your team and your company. We could really go on all way citing examples of how disalignment with these values resulted in problem in our team. So let's trying to think of them more often instead.
To bridge values with more practical examples (practices), we need XP principles, which are less abstract and can help generate new practices. But that's a story for another day.
Opinions expressed by DZone contributors are their own.