I love driving my car. It’s a male thing, I suppose. It’s somewhere in my Y-chromosome. I embrace every opportunity I can find to hop in my car and start driving.
And (like every other male on the planet) I think I’m a good driver.
You see, I always watch the other cars around me on the road. When changing lanes I check all sides and mirrors. My distance to the cars in front of me is enough to allow for occasional extreme speed reduction. I match my speed with the weather conditions. I play music in my car (loudly) but I don’t wear headphones. I don’t use my mobile phone while driving. And, as far as I can tell, I am the only person in the world who is able not to cross the lines that mark my lane while taking a curve to the left or the right.
I have adopted this behavior myself. I might have copied some stuff from other people, but it was my choice to learn these rules and use them, always.
In software development it is the same. We may learn practices from colleagues, books, or from any other source. But it is our personal choice to learn new practices and to apply them. It is not the number of official rules in an organization that counts. What really counts are the rules that people are willing to learn and use. In his book Complexity and Management Ralph Stacey wrote:
”Rules are not what make an organization function. What people do despite the rules is what brings an organization success.”
It is people’s actual behavior that must result in successful projects. And so I come to the topic of craftsmanship and discipline.
In his post What the Agile Manifesto left out, Brian Marick (one of the original signatories) wrote that discipline was never explicitly mentioned in the manifesto. Consequently, this lack of mentioning discipline introduced the problem of many people incorrectly interpreting agile as being “undisciplined”, which is untrue, or forgetting about implementing the disciplined parts. Scott Ambler wrote about that in The Discipline of Agile. The truth is that discipline is essential to agile software development. Many professional software developers agree, and so we now have a Manifesto for Software Craftsmanship, which mentions “well-crafted software” and a “community of professionals”.
Unfortunately, while many people think they’re good drivers, not many people attempt to be good drivers. In my recent presentation I said it like this:
Agilists assume craftsmanship Only few people pursue craftsmanship
My recent Big Agile Practices Survey showed that following a Definition of Done is the 2nd most important practice in software development (right after Source Control). But 17% of the respondents told me that they did not apply this practice. In fact, the percentages of practices deemed important were always higher than the percentages of them actually being applied.
People are not doing what they think is important.
Only thinking and talking about something doesn’t make it so. Just like making up official rules won’t turn your business into a success, traffic signs won’t make you a good driver. In fact, I often don’t notice many of the signs. It is my attitude and actual behavior on the road that makes all the difference.
Craftsmanship is something agile doesn’t introduce by itself. And just thinking and talking about it doesn’t give you successful projects. Managers who want better results must acknowledge that they have to actively change the attitudes and behavior of their people. They must stimulate craftsmanship and discipline. Or else…
Or else accidents will happen.
They say changing people's behavior starts by giving them a good example. So let the world know that yesterday night, while many people were watching the Champions League Final, I myself was learning how to do test-driven development with Python.