Have you noticed the shift in attitude towards Quality in Agile teams?
To set the stage: I’m a Quality Consultant and I don’t usually participate in an Agile development team. So, not being a member of the team I felt often perceived as ‘pig’ or less: irrelevant at best, a counterproductive nuisance at worst. The prevailing notion was: why waste time paying attention to Quality, when Agile – remember, everybody tests! – Inherently leads to Quality? Or, to better reflect the Agile mindset: Agile inherently leads to customer value!
Lately, I’ve come across more and more developers that value testers or ‘Quality guys’ in their team, acknowledge our valuable, different perspective. For sure, the aphorisms “Agile fosters Quality” or “Agile equals Customer Value” remain true, but we’ve all experienced that true, 100% Agile – if that exists at all … – is hardly ever accomplished and it’s commonplace that Agile practices need to be combined or synchronized with non-Agile, Linear practices. This can be induced by ‘the business’ through an annual portfolio or budgeting cycle or by ‘IT itself’ through a back-end release cycle that allows for no more than two major release a year. At any rate, Value doesn’t just happen by itself, especially not in an Agile transition that invariably sets off with a hybrid situation that carries both Agile and Linear characteristics. Value must be actively and purposely pursued by all involved.
I’ve always found it very useful to support organizational changes by a catch phrase or logo, something easily remembered that acts as a placeholder for the most relevant concepts and notions.
My catch phrase for Agile transitions is “Value by Design”. It refers to intent, to upfront activities and purposely created artifacts, to not leaving matters to chance, to an array of ‘things’ that you need to do, to create, to think about when you enter a TOP* Agile transition process!
In the weeks to come Hans Lantink and I will post a series of blogs discussing how we implement Value by Design!
*the acronym TOP refers to the fact that any successful change process carries Technological, Organizational and Process-oriented aspects.
This article was previously published in SogetiLabs Blog
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing. More on Ben.
