Agile testing: “hold the front page”
Waterfall development has a drawback - it can be so functionally driven that testing of more abstract concepts such as “is the user interface any good?”, “can I migrate from version X to version Y” and “does my software handle failures?” can suffer. Why is this?
The core reason is that these concepts often span so many functional items, that they cannot be easily contained within testing of a single functional item. They tend to slot into the system verification test cycle - yet in the waterfall method this is at the end of the development cycle and probably subject to the tightest time constraints, when it is probably too late to fix any major architectural problems.
How can agile help here? I would like to see specific stories - and even specific sprints - designed entirely around these more nebulous concepts. This necessitates a “hold the front page” attitude: a willingness to stop development of new functionality, and instead focus on consumability/failover/documentation based on testers’ experience of earlier stories. Perhaps this is a way to implement SVT in agile…
August 6th, 2008 at 22:51
Surely “hold the front page” is precisely what agile development is all about. I believe this is particularly explicit in the case of Scrum (I haven’t used Scrum), with its prioritised stack. It is important to watch out for people whose waterfall mindset leads them to pre-plan what’s going to be in each iteration right from the start. It’s ok to have a rough idea of where you’re going, but even sticking to that is a bad idea when it flies in the face of reality.
August 7th, 2008 at 23:11
Interesting comment! I’ve been giving this area a lot more thought recently - so let me brain dump some thoughts here. Probably not novel - but it helps summarise my understanding so far… a bit like the pensieve thing in Harry Potter.
First, I agree “hold the front page” is what agile is about. My concerns here are whether we can realise it in practice - so let me explain…
Where “hold the front page” does work:
It’s not just the scrum itself that makes this work - but more about having such a short cycle that it’s impossible to ignore the sort of issues that can plague waterfall cycles. Here’s an example…
Consider a waterfall cycle where there is 3 week period of poor quality builds at the start of SVT. At the time this happens, only test are affected - and the project response may well be “we will try and fix stability as fast as possible: but there’s no justification to rework the plan as we have plenty of time to make up for this”. Inevitably this leads to pressure (and potential overspill) at the end of the test cycle.
With Agile, and perhaps 2 week sprints, the impact of this build instability on the delivery is much more immediate and pronounced. This can only lead to better and faster resolution of critical problems. (Of course, with Agile we should never get to such a position with code instability! But that’s another story…)
Where “hold the front page” may not work:
This all ssounds fantastic - so what’s the problem? Well, what actually is a “critical” issue? Here I would like to see agile teams be able to say “hang on - we really think consumability is a growing problem: let’s focus on it” as well as “hang on - we have no build stability: let’s focus on it”. Note that the immediacy of consumability issues is less pronounced - with a dangerous route to the waterfall mentality: “we can sort out consumability later…”.
Do these (late night!) musings help illustrate my thoughts?