Developing complex software for enterprises using Agile development methodologies has presented some unique challenges, especially in the area of regression testing. This is particularly true in the Financial Services sector where extremely thorough and extensive regression is required and, in many cases, dictated by Compliance and Regulatory needs. For legacy applications that have been in service for upwards of a decade or more, the regression test cycles can easily span several weeks, if not more.
In a Waterfall world, most enterprises typically had about 3 major releases a year and regression testing was baked into the planning process. Everyone understood the impact upfront and planned around it. Moving to an Agile model, enterprises are keen to not just replace one development methodology with another but also to get product out to their users sooner. Managers are demanding a move to monthly release cycles to truly reap the benefits of faster development cycles. This is particularly true as the demands for business participation in Agile has increased the amount of time their users spend in creating solutions.
In a Waterfall world, business input was typically required two or three times a year when detailed requirements were being drafted. These times were known in advance and could be planned for. However, in the continuous development mode of Agile, business interaction is ongoing and never really stops at any time in the year. As the level of interaction increases, business users want to see more immediate gains for their user community in the form of more frequent product releases. Absent this, they have just exponentially increased their time commitments to projects while still getting the same two or three releases a year they have always been getting all along. This clearly is not a good deal for them and not sustainable in the long run. Why would anyone spend more time, money and resources to get the same outcomes?
One of the main impediments in the way of faster release cycles is regression testing. The regression test times do not change whether you are doing one release a year or twelve releases. If a complete regression cycle is three weeks, it does not change just because you move to a monthly product release cycle. You can easily see how the situation becomes untenable. If you want to do twelve releases in a year, regression alone will consume about thirty six weeks leaving about sixteen weeks to do development for twelve releases! This is clearly absurd and impractical. However, reducing the number of release cycles brings us back to the same Waterfall cadence of product releases. And round and round we go.
How have enterprises dealt with this conundrum? I have seen two ways this has been handled. First, enterprises have made a conscious decision to take a higher level of risk by drastically redefining regression test cycles. Through a process of negotiation and evaluation of the risks, teams have redefined regression cycles. As can be expected, the maximum amount of angst came from the Compliance and Regulatory user community but they have reluctantly signed off hoping for the best in many cases. However, at the first sign of trouble, I fully expect these users to pull the plug on abbreviated test cycles, and rightly so.
The second approach companies have taken is to implement the ‘Wagile’ model. This approach takes elements of both Agile and Waterfall to come up with home grown hybrid models of product development. Agile purists howl whenever companies do this, but from personal experience I find that this is practical and gets the job done. Not being burdened with any kind of dictate to ‘get Agile right’, enterprises are finding ways of getting the best of both worlds. This results in about three or four major releases a year where a full regression cycle is run prior to putting the solution into production. These project plans look like Waterfall as one gets closer to the final phases and behave like Agile during the development stages. In addition to this, there will be three or four smaller releases that typically are very targeted releases of small functional improvements where the risk of doing much smaller regression cycles is acceptable to all parties.
There is no perfect solution to this problem especially in environments where regression cycles are much longer. I suspect that in the long run, ‘Wagile’ is going to become standard in enterprises with each entity coming up with a version that best suits their needs. Apart from enraging the purists, I see no harm in this. At the end of the day, all we are after is better software delivered faster while at the same time managing risk. If ‘Wagile’ gets us there, more power to all of us.
