I normally don’t comment much when luminaries have debates (I’ll call them debates as they aren’t arguments, but there is disagreement and a desire by each side to win those to other sides), but I think I’ll weigh in…


The debate is over whether the concept of Software Craftsmanship as a (separate) Community/Movement is helpful or hurtful to the Agile Community and more importantly how those of us in Software Development serve our customers  It all stems from comments made by various members that are well respected taking up sides so to speak.  Bob Martin (@unclebobmartin) sees making the distinction as helpful as it shows that programmers are focused on quality and commitment to doing a good  great job.  Martin Fowler (@martinfowler) sees it as pulling the overall Software Development Community and Business apart to some degree.


Here’s my take….

The comments seems to be stemming from the fact that many non-software development domains are latching onto the concept of Agile as the Agile Software Development Community is using it (notice I added Software Development into this…) and it is diluting it.  This is not a legitimate concern IMHO.  Why shouldn’t other groups take advantage of the principles, practices, and techniques we have come up with…  So it’s filled with PMs?  Well, you need them on board! (see Note I added below)  If you don’t get them on board, you’ll have them (with generally more clout) resisting.  You want them becoming proponents (there is one thing that could be talked about more and that is Servant Leadership, but that will be a topic for another day).  The point is there is an Agile Community that has grown to become a superset of the Agile Software Development Community.   The issue is that people aren’t drawing that distinction when they toss around the word Agile.  

We need to…

Some conferences should serve both.  Some should be specific to their domain (e.g. Agile HR, Agile Marketing, Agile Manufacturing, and Agile Software Development). And all communities could learn from one another as we are all linked in the real business world.  Just as the PMBOK started with one basic domain and then became domain specific, so is the Agile Community.  It just started more from a set of grassroots developer-leaders and not from a management perspective. Let’s emphasize that the Agile Software Development Community also focuses on sets of practices; practices that the other domains will develop in time.  Some in existence are directly applicable, like  creating acceptance tests before going off and doing work.  Others less so….

(Side note on Acceptance tests: I had the opportunity to work on a recent engineering project with a fabric manufacturer thanks to some Navy Reserve work where the guy was applying TDD, to manufacturing fabrics - it was amazing to realize.  He didn’t call it TDD though, but the first thing he thought of and conveyed to me as the program manger was how he would approach making a test that shows he would pass the criteria being articulated.  This is why I am confident other domains can take advantage of what we are doing.)

So talking about (and obviously believing in) craftsmanship I think is useful; trying to make it a separate movement less so as we are JUST starting to get traction in many businesses on Agile Software Development.  We don’t need to obfuscate with additional language.

Revised 1/22/11 to correct some grammar issues and add my note

NOTE: In my talk about getting success with Agile in the Federal Government, I talk about the intrinsic motivation at least most developers have when they get their degrees (or start programming for those that don’t get degrees).   They have a passion for doing what they think is right and want to become better at it.  I also discuss that programming is a craft - it has both skills and creativity (it is supported with engineering practices, but as a pure knowledge domain, I wouldn’t call it an engineering).  It takes this intrinsic motivation for the craft (a desire for good craftsmanship) and top down support of management (the business) for Agile, specifically Agile Software Development, to succeed IMHO.

Filed January 19th, 2011 under methods, techniques, comparison, agile
  1. Nice, Paul.

    I don’t think that many people think that the inclusion of PM-focused stuff is diluting Agile, but that the necessary technical skills are often being overlooked at the same time as that inclusion.

    - George

    Comment by George Dinwiddie on January 19, 2011 at 6:01 pm

  2. Great points here!

    Comment by Agile Scout on January 22, 2011 at 12:41 pm

Leave a comment

To comment on this blog you will need to log in or create an account first.