Agile is a hot topic and is having a major influence on how we all think about software, both as developers and as consumers. The idea of capability arriving in huge waves is set to become a thing of the past, as we adopt techniques to stream capability in line with consumer expectation. I see this transition in two parts:

• Embrace new software delivery models.
  From requirements and user stories to iteration commitments and user deliverables.
• Retain flexibility as a core software design concern.
  Smart design is essential to ensure there is an architectural framework to support iterative delivery.

So what does this mean? Well, we know a lot about these things independently, the exciting part is in putting the concepts together. This got me thinking; we’ve spoken a lot about testing within an agile delivery model, but maybe we should consider testing to determine how Agile the deliverable is. One approach is for the SVT team to put in a request for an additional user story, or story variation, and measure the resulting impact in some way. For example, number of additional story points, estimated delivery date, or impact to the backlog etc.

(more…)

In discussion with a friend it hit me that one of the biggest obstacles in going Agile is trying to convince people to deliver “little and often”.

What this means is that you deliver just enough code to get the feature working and leave out any “I’m gonna put this here for later use” code. You also accept that this may lead to re-writes of that code in later iterations. This implies that your code is not designed to be extensible from the outset.

On the opposite side is that of having a long delivery time for your feature. This gives you the flexibility of spending a considerable time up front designing the infrastructure to support any code that will follow in that release. Unfortunately with this approach you get the inherent problems of having a long waterfall release; little customer interaction and often it’s too late.

Now, what does this mean for Test? Well, going back to the first statement in this post. I think in the transition to Agile it can be really tough to break a developers’ mentality to write extensible code. Thus from a Test perspective you get elements of both extensible and time-to-market, meaning…

Too much to test in too little time.