XP Values: Courage
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Values - of methodologies but also of companies - always sound fluffy. Courage is in fact such a term, but it makes sense together with the other XP values.
Is it possible to give a definition of courage?
Betteridge's law would say no, but actually Kent Beck made one:
Courage is effective action in the face of fear. -- Kent Beck, XP Explained 2ed
Sometimes it's easier to define a value by looking at its opposite, in this case fear. This path may risk to define a reactionary methodology, but indeed XP and other Agile methods are part of the reaction to the Taylorist software industry and the pervasive, heavyweight processes that were fashion in the 1990s. Who knows what would programmers say of us when looking back 10 or 20 years from now.
In a complex system such as a software development team, it's easy for fear to arise: fear that we will be blamed for an action we took, or that we will break some functionality and the build; fear that we will look as incompetent; fear that our product won't be successful.
Despite feeling fear (we are all human, remember?) the most effective response to it is not avoiding action. Natural selection forced us to be loss-averse, so that we take less risk that what we can actually bear: when you heard a noise in the woods while hunting, survival is favored from considering it a wild animal rather than the wind blowing.
In our protected environments made of cities, supermarkets and automated tests, no one eats you if you break the build and it's rather difficult to get a known bug into production on purpose while maintaining discipline (unknown bugs are another story of course).
Values, taken together
Courage does not mean deploying without or with broken tests, or experimenting code directly on a production server. This is rather recklessness rather than effective action, and is not sustainable.
Courage as an XP value is sustained by the other values:
- Simplicity strives for minimizing the code necessary to accomplish the task, not creating the burden of having to understand more than necessary when going live.
- Communication ensure your action is clear to others, so that they can object, and that you're not taking decisions with incomplete or wrong information.
- Feedback stimulates us to look at the effect of our actions as soon as possible and sustainable, so that problems can be caught immediately.
From the C2 wiki:
"Courage" or even "confidence" could be used to imply that one should be confident without basis, which would of course not be what XP recommends. Still I think they're better than "Aggressiveness", which really pisses me off and makes me want to shout at people.
There are a number of practices that depend on courage to be implemented. For example (not an exhaustive list):
- Energized work: have the courage to stop at 40-hour (a Sustainable Pace) and explaining that this is how you produce more.
- Pair Programming: no barriers in seeing how me and your program, and what is our ability.
- Stand-up Meeting, Weekly Cycle: do not hide blocks and problems, but bring them out to get help from the rest of the team.
- Slack: you won't be perfectly productive, and something will be dropped during the next iteration.
If you're already doing all this, I have nothing to teach you (rather the converse). But many of us still have to find the courage and the environment where to do that: changing a person is possible but changing a team is more difficult and takes longer.
The motto Courage is effective action in the face of fear explains what this value is there for: recognizing that humans feel fear, but that acting in concert with the other values leads you to take bold but productive decisions.
No test ensures you that you won't break a production system, but it takes the courage to deploy every commit to get to a point where breaks are easy to find (Simplicity), you are aware of them possibly manifesting (Communication) and you can check if they did in a short time (Feedback).