The value of courage

One of the core scrum values is the value of courage. The courage to say no to a request. The courage to say that you can’t handle a task; that you are missing the deadline, that that are some issues that eventually will cause troubles at later stage, that the quality is poor, that you don’t know how to build the feature properly. The courage to tell your teammates, and your boss the truth, the courage to accept the possibility that you are wrong.

I use the term “commitment to the truth” to describe all of the above; because not bringing up a topic won’t make it disappear and it’s always better to change your plans instead of following plans which you already know will fail. So you need courage to accept the reality as it is, but at the same time as something that can, and should be changed. Because you don’t have anything to lose. Maybe you would argue that you can lose your job. In the current market, at least in engineering, you just can’t be afraid of this. Even if this was not the case, one should never be afraid of loosing a job; if the job is not worth it, it’s better to be forced to find another one instead of accepting something you don’t like. And if it’s not worth risking your job in a try to do it in a better way, it’s a job that doesn’t worth being at.

You have nothing to lose, except for your time. Someday you’ll turn 50, you will look back and you will realize that you never tried to make things different, never tried to make them better and never learnt whether you were right or wrong.

One of the common misconceptions about agile is that it’s a methodology, while it’s a journey towards a better work. It’s not a set of practices but a set of values. Agile values responding to change over following of a plan, because chances are, 2 months from now, the plans will be somehow different than currently are. Why then to plan more than couple of months? That doesn’t mean that there should not be planning at all, or that changes are welcomed at any time. The reality is that you may only guess what will work and what will not, so in order to learn, you need short feedback cycles. That’s why agile methodologies promote short iterations — to enable fast feedback. Fast feedback is better for learning, as you can perform more experiments — trying new things, new ways of work, to see what works better for you and what’s not. Trying new things requires courage.

Agile values customer collaboration more than specifications. First, because you will collaborate anyway — some things will have unnecessary complexity, other won’t make sense, so in the process of “contract negotiation”, as it’s called in the original manifesto, you will collaborate anyway. Why to stop collaborating as soon as you start working, when you gain new insights, new ideas and new things to negotiate along the way? As soon as you accept that the worlds is not predictable and you can’t plan everything, it doesn’t make sense to plan more than couple of iterations.

Above all, agile values individuals and interactions over tools and processes. Because you learn most from interacting with the world, not by following an established process. So I don’t see agile as a methodology, but as a process of constant learning. And same goes for scrum, which is an inspect and adapt framework. It has a set of values, and set of widely adopted practices that encourage learning. One of those values is courage — the courage to accept that you will never know the best ways and sometimes you may be completely wrong — which should not prevent you from trying.