Craftsmanship - the Fifth Agile Manifesto Value?
At his Agile 2008 keynote in Toronto, "Uncle Bob" came forth with a proposal that the Manifesto is due for a fifth value: "Craftsmanship over Crap". As he explained, the value signifies that it is more important to pay attention to good craftsmanship in software development, most notably when writing code, than it is simply to crank out working, but "crappy", code.
A week later Bob took the opportunity to clarify his intention, revising the new value he had put forth in Toronto:
The problem with my proposal is that it is not a balanced value statement. In the other four statements we value the second item. We just value the first item more. But in my proposed addition, we simply don’t value crap at all.Many people have spoken up in response to Bob's posting, proposing their own revisions to the original devalued item "crap". Among these responses were: ["Craftsmanship over..."] Heroics, Production, Engineering, Hacking, Brinkmanship, Efficiency, Quantity, Toil, Yield, and even Scrabble.
So I hereby change my original proposal, which was made for dramatic effect, to:
Most software development teams execute, but they don’t take care. We value execution, but we value craftsmanship more.
- Craftsmanship over Execution
Not long ago, Brian Marick made similar suggestions that agile teams should value, in addition the current inclusions of the Manifesto, Skill, Discipline, Ease, and Joy. For many years, Pete McBreen has been using the term "craftsmanship" to emphasize the importance of people's skills when it comes to software development. Sean Hanly spoke of "Quality over quantity" and how agile can support "Craftsmanship" in his article Zen and the art of software development. Over the years, many have made similar statements in one form or another about the essentiality of recognizing "software as a craft".
In short, the idea that agile software development place an increased attention to "professionalism as a programmer" is not an entirely new one; XP comes with a long list of technical practices purposed purely at this goal, Scrum emphasizes attention to "technical excellence", and the list goes on. The question: why does it seem so many teams don't necessarily achieve this? Is this too implicit? Would adding a fifth Manifesto value help make this a reality? Would it hurt? Speak up and share your thoughts on the subject.
This is something that...
Don't get me wrong, I don't take it personally or anything, but the funny thing is, this is status quo. What I mean is, this is probably one of the most important topics of our industry (unfortunately), has been for oh so long, but nonetheless always seems to be something that gets little explicit attention (even more unfortunately). And as a result, simply continues on and on as "one of our biggest problems". Chicken, or the egg?
In other words, art imitating life. Neat-o! ;-)
Can has craftsmanship
Principle number 9 might not be enough
Continuous attention to technical excellence
and good design enhances agility
Having it in the main body of the manifesto would bring it the importance it deserves.
Re: Can has craftsmanship
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014