Working Agile means working piece by piece

Prototyping and incremental delivery are major key factors in the Agile methodology. Prototyping is the creation of modules or screens that are as close to the finished product as possible. The full functionality might not be there, but prototyping helps the client to have a clear understanding of where the development team is headed.

This is why prototyping is done at the initial stages of a project so that if there are any issues, the red flag is raised at the starting point and not much later, when it’s a whole lot more expensive to go back and change things.

As to incremental delivery, it specifies that at pre-defined points in time throughout the project, the client will receive updates of the product. The set of requirements in each version that is delivered must always be agreed on during the planning phase. This way, instead of receiving one huge chunk of work at the end, the client will have the opportunity of seeing the project grow as it is being developed, thereby also being a part of the process.

It is common practice in incremental deliveries that the milestones are set weeks apart and not months. A 100-metre race looks much shorter than a 400-metre one. A close finish line is more manageable and easier to reach.

From a development and testing point of view, this is probably one of the main advantages. Imagine being on a one year long time box. The end would look anything but close, bringing about discouragement and disinterest across the team members.

One major setback that can also be avoided by using incremental delivery is client disappointment. If it is only after a yearlong project that the client sees the final product, there’s a good chance that what is delivered is not what is actually needed.

Believe you me, I’ve had my share of this too many times, especially before I started working in an Agile environment. I’ve seen too many very disappointed faces and not just from high ranking management people who think in numbers, but also from end users who hoped their life would be made significantly easier by using our system and whose hopes were cruelly dashed on the rocks.

Although it may only look like a collective team effort, from a software tester’s perspective one must work in a modular manner. It is very easy to get lost in the whole project and while testing module A you end up testing module D, even if you know that module A needs to be delivered next week and that is the most important thing on your plate.

The methodology applies throughout, so both testing and development should adhere to the project’s delivery milestones.

Both of these methods ultimately allow for better communication between the stakeholders and the development team in order to prevent unnecessary differences between what is required and had been agreed upon, as well as what is actually being delivered. The client can therefore collaborate more in the process and have a better sense of ownership for the product itself.

A happier client means happier management, meaning they’ll leave you to your own devices to work in peace, ergo, you can work better! Work Agile, piece by piece, and work better!

Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.