When introducing myself as a software craftsman, I often face surprised reactions. And when I talk about time spent to improve code quality, I sometimes hear : “So you refuse agility and deadlines?”

The way people perceive agile methods is very often misunderstood. For those still working with cascades and V-models inherited from last century industry, agility is often confused with the time management of projects.

I would like to expose here that agile methods have other purposes that being a way to put a team under pressure. It’s actually the exact contrary. That being said, we’ll then see why agility and software craftsmanship are relevant complementary approaches.


With the sole purpose to putting a team under pressure, agility only means that it has been misunderstood, whether ignorantly or intentionally.

The agile methods make it possible to manage projects in a pragmatic way. They involve more the project owner, making his requests better taken into account and allowing a greater reactivity. They are based on an iterative, incremental and adaptive development cycle.

They claim four fundamental values :

• Privileging individuals and interactions over processes and tools
• Shipping features over comprehensive documentation
• Enhancing customer collaboration over contract negotiation
• Accepting change over following an established plan

The confusion with the pressure aspect comes from the fact that, in a world where the “objective” notion is still too much and badly present, some people are sad when they do not achieve all the features provided in a Scrum sprint, for example.

But a sprint is not an end in itself. It’s an ambition, and a way to measure collective work. Missing your targets in a sprint is not a failure: it simply means that the workload has been underestimated. Then we will do better for the next one. The objective is to provide the project owner with an improved version.

Scrum, Kanban and Lean define the pace of a project. But they don’t necessarily guarantee to stick to a delivery date, since it depends on constantly introduced changes.

Conversely, they enable developers who think they needs more time to achieve a feature, to expose his point of view, share and explain to both the team and the product owner in order to finally obtain the necessary means.

Agility is meant to give a pace and collaborative approach to work. It should never imply to work quickly and badly. Remember that bad work only adds up to the technical debt.


While agile methods provide a framework that allows essential inputs, they do not guarantee the quality of the product. At most, development by testing can maintain consistency. But as long as it’s working, nothing prevents people from writing code any old how.

At the end of the 1990s, some teams began to introduce new principles within the agile methods. Those aimed at producing a code of better quality. An example is the eXtreme Programming (XP).

Then came the web 2.0 breakthrough, along with the advent of IT firms. Software development became an industry where quantity took precedence over quality, corrupting the nature of agility.

The Manifesto for Software Craftsmanship was published ten years later, in 2009. It reaffirmed that a software must only be functional, but also well designed.


Software Craftsmanship consists in putting practices neglected in agile methods back to the core of software development. It promotes a culture of improvement and knowledge sharing through practice. It is backed by a set of techniques and feedback in order to provide quality software. It claims that « non-quality » software induces a strategic and financial cost.

It is basically a return to the XP of 1999, and especially a reformulation of the four basic values of agility:

• Privileging individuals and interactions over processes and tools → hence the necessity to create a professional community
• Shipping features over comprehensive documentation → that implies the software to be well designed
• Enhancing customer collaboration over contract negotiation → to reach it, you have to know how to create productive partnerships
• Accepting change over following an established plan → this requires a constant added value.

It has become clear that software craftsmanship is ultimately a product and an extension of agile methods. By aiming for agile values, we find that the values of craftsmanship are essential.

It follows that Software Craftsmanship borrows from other agile methods and especially XP, through:

Quality: simple design, DDD, OO, refactoring, TDD (XP)
Humility: questioning and continuous improvement (retrospectives)
Sharing: pair programming and collective ownership (XP)
Pragmatism: I understand the constraints and I adapt (Scrum)
Professionalism: I treat my client as a partner (XP)


Software Craftsmanship and Agile Methods are complementary methods sharing the same philosophy. Craftsmanship improves the most popular agility methods, complementing them for the best and adding the dimension of responsible quality.

The debate around deadlines has nothing to do with all that. Neither agility nor Craftsmanship are intended to manage or accelerate the temporality of a project. This remains the responsibility of HR management.

The better the code, the better the quality of the product. Maintenance and addition of features will be greatly facilitated. The time invested in producing a quality code will ultimately save a lot of time on the delivery of a reliable and scalable product, resulting in a better customer and user satisfaction.