A Craftsman Looks at the Agile Manifesto
I've been having a lot of conversations lately that have been rooted in the fact that people are starting to sour on Agile. There seems to be a groundswell of thought that Agile has finally Jumped the Shark. While I do understand the sentiment, what with the inundation of certification schemes and cargo cult approaches to agility, I don't believe the original intent needs to be lost. Movements like Modern Agile are bringing the intent and meaning back into focus. With that in mind, I thought it might be worth going back and looking at what the Manifesto means throught he lens of a Software Craftsman.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Ok, so we start with some rather profound ideas that get lost in some very unassuming text. The power of the manifesto is derived from the fact that this is *learning* that has resulted from *doing*. This isn't the result of a paper, or linkedin article, or even an attempt to sell a tool or services. As a Craftsman, I respect and honor experience. Yes, most of that experience is from doing something, in this case making software. But lets also note the value of "helping others do it". I learn so much from mentoring or guiding someone who has less gray hair, and that learning is always valuable.
Lets take a look at each value statement individually:
Individuals and Interactions over Processes and Tools
A Craftsman can often get really, really excited about his tools. We need to get just as excited about working with the people around us. Software development is a social activity. Focusing on how we work with each other will give us more freedom to make great software.
I suspect that when this was first posited, it was specifically about project management tools, but lets take it further. We often fall in love with our favorite <IDE/Language/Refactoring Engine/Pattern/OS>. And we get pretty adamant about them. So, as true Craftsmen, we need to know how to be dispassionate about tools, even while we have our
favorites. So not just "the right tool for the job", but "the right tool for the team" should be our mantra.
Working Software over Comprehensive Documentation
Ok, this one should be a slam-dunk for a Craftsman. A true Craftsman believes that the result of her work is the only true measure of her success. She isn't interested in having a big document, especially documents regarding what she is "planning to make". This does NOT mean we never document anything. It means we only write as much documentation as is necessary to help us reach our goal, which is working software.
By the way, this is a great way to overcome the common argument against Craftsmanship. As my colleague Joe Gee relates, some folks feel that Craftsmanship implies you are making a Ferrari with hand tooled leather seats, when what you need is a Toyota Corolla. As we point out that working software is our primary measure of progress, we show that our focus is on getting the great software out into our customers' hands, not working and reworking it until it is "absolutely perfect".
Customer Collaboration over Contract Negotiation
Still following that them that a Craftsman is here to provide the best possible software for his customer, we do this through collaboration. I am reminded of a story about how a master instrument maker created Wynton Marsalis' trumpet. He went to concerts with Wynton. He lived with Wynton, learning all of his habits and mannerisms, not just about how he played in performances, but in practices and even just doodling around. This took time, and also lots of trial and error. There was no talk around "I will deliver one trumpet: color, brass." Through partnership and collaboration, they created a trumpet that
is truly unique, that fits Marsalis perfectly, and he has used ever since. We can do the same thing, at a slightly smaller scale perhaps, in software. Learning what our customers need, and collaborating with them on how to make the result the best one possible for them, is the key to success for any Craftsman.
Responding to Change over Following a Plan
I often think this one value is really where the work Agile comes from. This goes beyond just saying "we will do two week sprints" or "We can change the order of the backlog before each sprint." Responding to Change evokes a higher level of individual professionalism and maturity. It involves being comfortable enough in the flexibility of your design and construction that you are ok changing based on the needs of our customer(see: Customer collaboration...). As Rudyard Kipling said in his great poem if: "If you can keep your head while those about you are losing theirs and blaming it on you..", you have achieved a level of Craftsmanship that inspires trust, as well as calm when things get a little crazy, as they often do in our profession.
That is, while there is value in the items on the right, we value the items on the left more
A Craftsman knows what the right balance of each of these items is. It is not always the same in each situation, but it is always important to find that balance.
In the end, a Craftsman needs to be able to apply these values professionally, calmly, and with a clear eye. So no, I don't believe the Agile Manifesto is obsolete. I do agree with Modern Agile and other lenses to look at the Manifesto, as they help us understand what this crazy ride we started 18 years ago was about, and get us past the cruft that has tried to build up over the years.