Software Craftsmanship promotes Competence Culture

The rise of anemic Scrum was noted to dismay among the Agile community and in particular by “Uncle Bob” Martin who coined the fifth Agile manifesto value of Craftsmanship over Crap(Execution). This gave rise to the much needed community of Software Craftsmanship.

Looking at an earlier post – Agile is about Collaboration and Cultivation Culture – it is clear that the Agile community was not addressing the Competence Culture. And we as a community of software professionals do need to pay attention to competence and technical excellence for long term sustainability. Uncle Bob recently wrote a good article on this topic – The Land that Scrum Forgot.

Cultural View of the Manifesto for Software Craftsmanship

The diagram below relates parts of the craftsmanship manifesto to cultures identified in the Schneider cultural model.

Not surprisingly, there is a big focus on Competence Culture. This culture is focussed achieving success by being the best. And craftsmanship is about being the best software developers possible.

The value of productive partnerships stands alone. I am curious as to what purpose this supports as it is not directly related to writing quality software. I am wondering whether:

  • this exists as a bridge to the Agile community?
  • is related to the strong XP practice of pairing?
  • is intended to appeal to the need for mentorship?

So what?

Craftsmanship needs to exist to make sure that the technical practices promoted by XP don’t get lost in fluffy bunny Agile culture. Things like: refactor mercilessly, do the simplest thing that could possibly work, TDD, ATDD, continuous integration, continuous deployment, shared code ownership, clean code, etc.

The existence of a separate movement to support competence culture that exists outside of the Agile, supports the assessment of Agile culture as focussed on Collaboration and Cultivation.


I think that Craftsmanship is a good thing. I also believe it is complementary to Agile.

This is post is about understanding how Craftsmanship fits with Agile and company culture.

Print Friendly
Tagged with:
, , , , ,

Find Content

Adoption Agile Agile2009 Agile Failure Agile in the Large Agile Tour Toronto Change Artist Christine Day Coaching Communication Container Craftsmanship Creativity Empathy Facilitation Fear Games and Simulations Hierarchy Kanban Kotter Leadership Lean Management Observing Organizational Change Organizational Culture People Personal Growth Production Product Strategy Project Management Red Pill Safety Scrum Strategic Play Teamwork Technical Practices Training Training from the Back of the Room Transformation Transition Trust VAST Vulnerability XP


  1. I totally agree – agile will not ‘take care’ of teams if they don’t have the technical safety net that the above engineering practices provide. The challenge is to build the practice of craftsmanship into the (busy) daily life…

    Good post!

  2. Hi,

    After having ago at Kanban, I thought it only fair I have ago at Agile too, just to keep things balanced 🙂 Whilst I agree with you that an Agile culture values cultivation and collaboration, for incremental and iterative software development to actually work, Agility relies on a very high degree of developer competence.

    Why? Well it is the cost of change curve. Traditionally using procedural programming languages, the cost of change increases exponentially the later in the project you make that change. This is why BDUF and the “get it right first time” culture flourished under waterfall.

    With the rise of OO development people began to realise that through good OO design and “DRY”, you could actually flatten the cost of change curve, allowing you to make design changes at any stage. If this is true then you can deliver different versions of the software, morphing one version into the next as you go, without the need for BDUF.

    There was a diagram that explained this in Kent Becks XPEI book. It is missing in his second revision XPEII, and the tie between engineering practices as an enabler for incremental and iterative development isn’t even mentioned in Scrum (it wouldn’t be, since Scrum isn’t about software). Over the years the appreciation of the connection has been mostly lost.

    This is a great series of post, that shows our history along the Agile journey. What I find interesting, is that Craftsmanship is a backlash against what Agile as become and an attempt to get back to Agiles roots, namely (extreme) programming and good OO design (the Smalltalk way).

    As someone that came to Agile through XP, it is interesting to see what has append over the years. From a developer deferred centric movement we have become Manager centric. The Scrum boom has lead to Agile being associated with deferred technical debt, the Flaccid Scrum. We now have Kanban, which like you say can be associated with extrinsic Management control.

    Out of all of these, the only culture guaranteed to work for iterative and incremental development, is one that puts competence first. The Original XP culture and the current craftsmanship culture. Without a very high level of competence incremental and iterative software development simply doesn’t work 🙂

    Some have expressed concern over the recent craftsmanship culture leading to egotistical developers who are self consumed and self important. To temper this tendency the XP culture like Scrum had a good dose of humility. One of the reasons that many aren’t comfortable overtly calling themselves master craftsmen 🙂

    It as though we’ve gone backwards. Take care and I’m looking forward to your next post.


    • Paul,

      Thank you for your insightful comments. You add a strong measure of clarity to the discussion.

      Although I agree there is an element of going back to XP roots, I think that craftsmanship is a wider umbrella and can be home to more than just XP practitioners.

      – Michael

  3. Agreed. These are all stereotypes of a sort. Real teams and individuals don’t neatly fit into one cultural category or the other. I guessed what you are describing here is the dominant traits and I was relating those to my own experience.

    I’ve gone back and read your post on the Schneider cultural model. I agree with the assertion that culture is persistent and is best accepted as a given. Most organisations just want to get better at software delivery, most don’t sign up to cultural change 🙂

    I’m getting over to Amazon right now and ordering my copy. Thanks for blogging.



Submit a Comment

Your email address will not be published. Required fields are marked *