Value by Design

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 VisserBen 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.

When is the DoD “Done”?

What do you think of “Definition of Done” items like “All source code has been reviewed” or “All user stories have been tested”? I think they are poor, to the point of being useless …

Not everybody agrees with me on that. Actually, these are real life examples, so there are entire Agile teams that disagree with me ;-). Read more


ben visser noviembreRecognize this? It’s that time of the month again: time to regression test the monthly and quarterly batch jobs. No one has touched the code, but somehow there’s always some inadvertent error that has found its way into the ‘not changed’ code. So, here you go again: setting up the regression test environment, preparing and loading test data, checking interfaces to back-end systems… Two days of painstaking hard work requiring undivided attention, to prepare the test run that takes ‘only’ 4 hours – and then another 2 to 3 days to verify the results. Read more

Proper preconditions: vital to (test) success

Recently I entered a project that was well underway for a while already and I was given an elaborate test plan and some recent progress reports to get up to speed. I’m not a big fan of elaborate test plans. Test plans, especially the elaborate ones, tend to end up at the bottom of a pile of ‘to do documentation’ or in the proverbial bottom drawer. But this time I was pleasantly surprised, because of the way preconditions and assumptions were stated and because they were addressed persistently in the progress reports. Read more

Agile Test Improvement: contradiction or two sides of a coin?

How valuable is thinking about test process improvement in a time and age where Agile is rapidly becoming the dominant mindset for software development? Are we evolving so fast that an approach towards test process improvement like TPI NEXT®, which was successfully launched in 2009, has become all but obsolete 4 years later? I think not. Read more

The tester’s hammer

Would you hire a carpenter who doesn’t know how to use his hammer? Strangely enough, this is more or less what a lot of companies do when they hire a tester! That is to say, they hardly check whether or not the tester knows how to use his ‘hammer’ or his ‘screwdriver’.

Read more