In Adobe Professional Services, we are big on software craftsmanship. We are committed to clean code, T.D.D., the SOLID design principles, and the idea that craftsmanship will increase customer value. This is not always an easy crusade to be part of, largely due to the fact that our work is usually beholden to the needs of our customer. There are many cases where the customer may make demands that suggest we compromise our standards. For some, this is a cry to battle, and the ensuing tension can make a project troubled, to say the least. There are times when this seems to come down to an ‘all or nothing’ stand on quality, with ‘push back’ being the war cry of developers. I feel this is a common pattern in the software industry, but extreme stances are never a good way to get things done. This is where Agile comes in.
Agile is the rule of the land in Professional Services (and across many product teams at Adobe). There is an important aspect of Agile that may help move things away from an all or nothing dialog around the inclusion of quality in delivery. In general, Agile can be seen as guidelines for achieving balance. In Agile’s very definition, the things that are ‘favored’ (individuals, interactions, working software, collaboration, response to change) are just that; favored. They aren’t strictly demanded, and there isn’t a formula for measuring the percentage of implementation. Problems come when any one principle is ‘favored’ more than another. In this case, the ‘commit to technical excellence and good design’ principle of Agile can be taken to an extreme, while the customer may be taking ‘deliver working software of business value’ to their own extreme. If either principle becomes a goal in itself, this begins to limit the inclusion of other, equally important goals.
The frustrating thing for developers, especially those committed to quality, is that business value should ultimately be decided by the customer! In the end, we should strive to provide quality as a rule, but the customer keeps the lights on, so delivery should take precedence. If the customer is not giving enough allowance for quality, one approach is to help them see the business value of quality, rather than simply pushing back. However, Agile provides other ways for developers to shield themselves from focus moving too far toward delivery.
Another principle is the idea of “maximizing simplicity”, which is measured by the amount of work *not* done. Delivery of working software is supposed to be the *only* measure of progress. However, a good team can work within that definition to provide an adequate balance between value, architecture, and quality. Craftsmanship, pragmatically applied, is non-negotiable. The point of balance is to be doing just enough, while not becoming and end in itself. This is the same principle behind stories being a seed, rather than detailed requirements, and the deferred design that comes in sprint planning. The ‘just enough’ idea should be able to provide some padding for the dev team, so that quality doesn’t have to be completely dropped in the face of delivery pressure.
In the end, the tension between customer and developers is probably a good thing. A team with out constraints may tend toward over-architecting, and a customer with no technical resistance is likely to create low quality software. For me, a big selling point of Agile is how the principles work together to make life better for both development and the customer.