Does Agile working make sense with fixed requirements?

Agile working offers the possibility of agility, certainly, but for me it is much more than just a methodology with which we work if we do not know the requirements well in advance or if it is permitted to change requirements during the process without the supplier immediately having to deal with additional work and breach of contract threatens. 

Suppose we have a project where really, really, really, the requirements won't change. For example, you want to create a calculator app with 20 fixed calculation functions. Or you want to transfer a legacy system one-on-one to a modern platform to increase stability and save costs. 

A waterfall approach now goes as follows: work out the requirements in detail, create an architecture of the whole, create a high-level and then detailed design and this package is delivered to the programmers. These build and integrate this. Then we test what we have created. Then comes the acceptance test by the users and if production also agrees, it can go live. 

The agile alternative to this is different: we always take a few requirements from the stack and do all the above steps, from architecture to acceptance or even live. In the agile Scrum methodology, this happens in a period of 1 to 4 weeks called a sprint. We then evaluate and, if necessary, adjust our working method. 

Flexibility by changing requirements now is not an issue in this blog. But does the agile approach bring us additional things here? I will mention a few points. 

If the result of the work done is already usable, then it already has potential value even after one or a small number of sprints. Perhaps you want to enter the market with a calculator with only 4 functions, to get ahead of the competition or to build up an initial customer base with a free version. Or you can phase out the first part of the old system and thus increase the stability or reduce some of the costs. And you can test how customers and users respond to the partial product. Oh no, that makes no sense, because we wouldn't change the requirements anyway! 

Is this true? Is the screen layout we devised useful, do they understand the tooltips, does it work conveniently? And does operations think that everything is also according to their standards? After just one sprint we learn these lessons and can make adjustments in our production process. With waterfall, these kinds of things only come up at the end, after everything has already been built. Changes can then cost a lot of extra. Or you can just leave it alone, but the system will then be much less useful in practice, and that is harmful. 

Are technology choices also good? With agile working we learn this from the first sprint, but with waterfall only in the implementation phase, after a large part of the term and budget has been spent. Or maybe even at the very end. I have experienced it in my own practice that only upon acceptance it turned out that the system that was “finished” was performing severely inadequately. In the construction environment where testing was done, things still went well. Result: major architectural changes, reconstruction, 2-year delay and severely disappointed customers and management. This replacement of this legacy system had exactly the same requirements, yet it went terribly wrong! 

And planned? Customers like to know how much something will cost and when it will be finished. The organization must be ready at the right time and requesting additional money is often possible, but not time and time again. With the waterfall method, many processes are completed at 96%, because the devil is in the tail. For example during integration, testing or when users and production finally see the system. Projects still run 50 to 200% late. If we work agile and have delivered 5% after the first sprint, we can predict that the entire system will be finished after 19 sprints, although based on N=1. As we get further along in the process, the estimate becomes increasingly accurate. Even if we make a lot of progress in the last sprints, which is very strange in itself, we will only finish a few sprints at most. This predictability is very pleasant for drivers, among others. 

Will one also build according to the requirements? A waterfall trajectory reminds me of my birthday parties from the past, where one child whispers a story to another, which is passed from child to child. It's hilarious what comes out at the end! That distortion and loss of knowledge are also present in the phasing of the waterfall. What do we do against that? Document! But... documents are often poorly understood, and writing them takes time anyway. Agile teams work together continuously in space and time and are not familiar with that effect. 

Finally: quality. An agile team will use resources to test the new and already built features every sprint (automatically). This ensures that the product consistently maintains high quality. In waterfall, integration and testing happen only once at the end. In my experience, by that point, the budget is often significantly exceeded. Sometimes there is no other solution than to throw it 'over the wall,' with all the consequences for operations or worse, the customer or user. 

My conclusion: Agile working has many more advantages than just being able to flexibly adjust requirements and work exploratively. Results are delivered from the very beginning, providing added value to users and customers. Plans become better and more reliable. Risks become smaller, more manageable, and easier to handle. There is continuous attention to quality, and overall it is usually cheaper due to less (documentation) overhead and rework. 

Even in situations where, or it is assumed that, requirements are fixed, an agile working method can be excellently applied!