The Regenerate Web

Dave Thomas asked a question about mastery, especially regarding agile practices, in his PragDave blog.

I want to poke at the word mastery a little bit.  It is one of my favorite words because it describes something that we don't understand today, as well as we understood it before. This is especially true in information technology, where new ideas arrive at a rate where only those delivering these ideas to the community have time to achieve true mastery, but that is a different problem.

In the age when trades were regulated by guilds, rather than organized labor, there were specific requirements for achievement of each rank.  As I understand it, one of the requirements for mastery in most trades was the ability to construct one's own tools.  I learned this from my 8th grade shop teacher, who showed me how to sharpen wood chisels with a buffing wheel and jewelers rouge - he made me promise not to tell anyone because this was his trade secret.  After doing some basic research, I realize that this understanding is assumed in another - the master had to make their own tools, because they owned the workshop - a master was allowed to set up their own workshop.  Each master's tools were his competitive edge.  These tools and his mastery were his "trade secrets" and he guarded them zealously, because they key to his financial success.  At some point during the industrial age, tools became much more standardized and toolmaking became a trade in its own right, and tradesmen purchased their tools rather than making them, or working for a master.  

So what on earth does this have to do with agile, I can almost hear you asking.  Absolutely everything.  I agree with Dave when he says that "agility is all about the journey".  In fact, what agile practitioners are is navigators.  Agile isn't about the practices, the practices are merely the vessel in which we take the journey.  Not every vessel is appropriate for every journey, the master is one who can decide which practices make sense for this particular journey, and can adapt the vessel on the fly, tuning the practices to the specifics of the team or project.

Those of us who are less experienced with agile practices, having only implemented parts or aspects, or all of a single methodology on one or two teams or projects may try to repeat our experience and be frustrated when we don't repeat our original positive experience, are not masters, but journeymen, who need to borrow our tools from a master craftsman.  We need the experience of an agile coach who can see where we are missing the boat, so to speak.  

I am thankful for the masters who have gone before - the pioneers - Beck, Highsmith, Cockburn, Beedle, etc.  They have built ships that I can sail, and I need to learn from their experience.  I think that there are many, many more who have learned from the these masters, and have crafted their own vessels, sailed off to distant shores, but have not shared their saga with the community.  

I suppose that I disagree with Dave in his definition of mastery, that mastery is the point when one can say, "Now I know it all" is what I disagree with.  That would be like saying that a master carpenter will never see a situation that requires him to be "creative".  In fact, I would suggest that innovation comes from the fact that mastery does not mean "I know it all", but it means I can try something when what I have done before doesn't work.  I submit that one is a master of agile, when one can invent a practice that works where others fail, while maintain the tenets of agility.