Agile vs Software Craftsmanship


I’ve expressed on this site before that Agile has been somewhat of a frustrating topic as a developer. It seems every time I told a developer that we are ‘agile’ or mention something along those lines, it was met with a sigh and an eye roll.

As a developer, I’ve been really into Uncle Bob’s material lately. I’ve read a few of his books since September and have tried to watch at least one of his talks each week. He focuses a lot of ‘software craftsmanship’ - keep the code as clean as possible, follow TDD, etc.

Today, I saw on his blog:

The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don’t recognize as Agile any more. It has been a shift away from excellence towards mediocrity, away from hard realities, towards feel-good platitudes.

It began with the notion that anyone could become a “master” of anything by sitting in a two day class and getting a piece of paper. Soon to follow was the dilution and eventual loss of the technical practices. This prompted Martin Fowler to publish his classic and definitive blog: Flaccid Scrum. Then came the emphasis of project management over craftsmanship and the rise of the soft skills (attitudes) over the hard skills (practices).

At that 2001 meeting in Snowbird where we wrote the Agile Manifesto, Kent Beck stated one of our goals: “…to heal the divide between development and business.” Unfortunately the deemphasis of practices within the Agile movement has only served to widen that divide. While project managers have flocked into the Agile movement, developers have fled out of it. The original movement has fractured into two movements. The Software Craftsmanship movement has preserved the coupling between practice and culture; whereas the Agile movement has shifted away from it.

I had no idea there was a formal “Software Craftsman” manifesto:
I also couldn’t agree more with his take on Agile.


I have found that Jim Highsmith’s Declaration of Interdependence is a good basis for how all of our roles should intertwine.

  • John Voris


You’re not alone in that observation, Matt. Next week (hopefully) we will be releasing the podcast interview with James Grenning. I am not sure if it is in the recording, but we definitely discussed the utter lack of acceptance for the XP practices that I believe are required for agile to exist. I have not been to a single certification training where the practices are taught appropriately.

“Agile” has become more of a buzzword and project management tool than what it was intended to be. When we interviewed Ron Jeffries, he quoted Kent as saying Agile is “Meant to make development safe for developers again”, and honestly that is very often not the case. What compounds the issue, Uncle Bob calls out the rate at which software engineering grows - exponentially. As new engineers enter the market, they are learning from the last wave. If that last wave is behaving in poor fashion, the next generation will follow suit.

I choose to believe that all hope is not lost. You will always have a large portion of the industry doing whatever they want, but the successful teams will have a deep appreciation for the principles and practices of excellence. Quality engineering is and will continue to be a competitive advantage in the digital market. Teams that understand these practices will stand the test of time, and the others will implode, be breached, or die some other way. Hopefully as those teams dissolve, the engineers slowly find quality teams.


I agree with the comments here, as would (I believe) Uncle Bob and other Manifesto authors. As part of the training that I perform for clients, I have a slide I refer to as “Forgotten Agile”.

  1. Focus in “The Market” is on Agile as Project Management
  2. Most of XP rules are about Design and Development/Testing
    The rules follow sound Engineering practices
  3. Remember the Agile Manifesto’s 12 Principles…especially:
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.


I completely agree with your comments @PaulD and @ryan and I’d like to add one more thing. As you have observed, some developers and agile practitioners are not ready to embrace these practices but if you’re ready don’t let them stop you. I believe the best way to improve is through practice and repetition. You will continue to grow and improve and eventually influence the nay-sayers through your example.