Agile development. It’s great. It really does have so many benefits over traditional waterfall methodologies. Of course there is no single “agile” process, I believe each development organization adopts agile principles to varying degrees, also with very different results. But one thing is for sure, in most of these agile shops, they produce more releases than in the old days. It might not be moving to daily releases like some people are doing today, but it is also not doing 2 releases a year as with the waterfall initiatives and SDLC’s of the past. And I am not arguing that overall output increases, that may stay constant or even decrease unfortunately. The sheer number of releases tends to increase, as the very nature of agile is tighter, smaller releases. Releases increase in frequency. More releases, more moving parts. More moving parts, greater complexity. Greater complexity, less releases. 🙂
This story is best told in context of Malauzai and how we do Agile development. At Malauzai we run a hybrid agile/waterfall development process. We do 10-12 releases a year and support one year of historical versions. This works great as the typical bank or credit union updates their app 1.8 – 2.1 times per year. So everyone gets upgraded usually long before the oldest version faces being retired.
Monthly releases have led to great complexity. And the need to simplify. Sounds simple to run tight monthly development cycles. But it doesn’t actually work that way. Example. Planning. The planning for the release, including writing requirements, tends to happen BEFORE the month begins. Yes in pure agile, things are small, small enough to be defined within a week or two sprint cycle. Nope. If you did that, the thing would be mighty small. What we have found, lesson number one, is to deliver the right “chunk” of functionality. That takes about 2 weeks to get a relatively substantial new feature. Much less than two weeks, produces a new feature that is not really stand-alone, more akin to a minor enhancement for and existing feature, and yes, we do those too. So, you MUST do planning and requirements gathering prior to the month of development. Does that challenge the whole definition of agile? Again, Nope. Reality is this. Releases run in parallel. An actual release when you factor in planning, a month of development, then testing and product launch readiness, your looking at 3 months. One month of development yes but two months of other activities.
OK, so we have established that a) agile leads to more releases and b) agile releases run in parallel because they have to! They overlap. After all this is not waterfall. We think of it as parallel waterfalls. And the conclusion? Complexity. Increased complexity around tasks that in a waterfall environment were very straight forward. Regression testing. Requirements gathering. Managing releases in parallel, having to dedicate resources to planning, building and testing all at the same time. Great complexity.
The benefit of this Agile process “great complexity” is in fact a huge benefit over waterfall. The ability to deliver production ready code at any time with substantial new features. The ability to shorten cycles that have become unnecessarily bloated so we can release code much, much quicker. Huge. The downside? Too many moving parts. We have found at Malauzai that we need to strike a balance between the ability to stay agile and release often and the reality of managing complexity. Our answer: stay agile with monthly releases BUT cluster most production clients around a few key releases. This way, if a client wants something quickly, they can get it right away. We stay responsive and the clients gets to deliver innovation. Most clients are happy to take new features after they have been live for several months. Those we cluster around 2-3 releases a year dramatically simplify the process. It removes a ton of the moving pieces and generally has made our lives a lot less complex. Best of both worlds: agile development that produces timely innovation AND stable, production releases that allow for maintaining high quality solutions for all customers.
Who would have thought that in the end agile and more releases would eventually lead to greater complexity which we need to manage by trying to simplify? Welcome to the ever evolving world of software development.