Learning how to cook

My favourite cookery writer is Nigel Slater. The reason for this is that Nigel, by his own admission, rather than providing a set of recipes to follow, instead aims to teach the reader how to cook. His opinion is that there are too many variables in play in the preparation of a meal for the blind following of a recipe to always produce a successful result, instead he aims to provide the skills required to apply to allow us to handle the variables and still produce good food.

My stance of software development and testing is very much on this basis. We cannot expect a single approach or set of technologies to be universally applicable to every development project. Instead we must use the skills and experiences that we have developed to try to apply the most appropriate processes in any given situation. In this I find myself aligning very strongly with the Context Driven approach to software testing advocated by Cem Kaner and James Bach.

Although in my current organisation we are striving to work in an incremental agile scrum approach, I know that some of the methods that we use do not align with the 'classic' approach to Agile. Whilst some of the differences may indicate 'bad smells' that we should aim to resolve, in some cases it is simply the nature of the product and the needs of our customers and the rest of the organisation that dictate our approach. For example, our customers do not want high frequency deliverables of small amounts of new functionality. Given that each release that they receive must be run through their own thorough test processes prior to a significant upgrade process on multiple client sites, they want major functional changes delivered in their entirety on longer term release cycles. We still aim to deliver working software at the end of each sprint but, for most sprints, this software will not be delivered to the customer.

Does the fact that we deliver large scale changes to the customer on an infrequent basis mean that we are not 'doing agile'? I do not believe so. We still produce working software regularly, verified by continous integration builds and nightly regression tests. We aim for continous improvement with daily standups and sprint end retrospectives with a team that is empowered to make decisions on how to run itself. If we have some aspects that do not fit perfectly with someone else's idea of an agile development process, I am not overly concerned, after all as Nigel Slater says "Blindly following a recipe as if it were a chemical formula is not really cooking, it is just going through the motions"