The last months, I have started to see an increasing number of articles complaining about agile software development. Many of the articles have a similar tenure. On the one hand, they mention that agile is causing teams to be really stressed and constantly focusing on the next feature to deliver. And on the other hand, these articles sing the praises of traditional waterfall development and highlight how teams and individuals had time to think, properly architect and test systems and life was much easier.
First of all, the depiction of waterfall development in these articles is far from my experience with a host of companies. The final integration stage of a waterfall project where everything comes together, nothing works and stress levels go through the roof is an experience that almost everyone who has been in the industry for a while will recognize. It’s just that we tend to conveniently forget about the bad memories from the past.
Second, most people forget the continuous growth of the size of software in our industries. According to research, the size of the software in systems goes up with an order of magnitude every five to 10 years. That means that if you were building a 1MLOC system a few years ago, you’ll soon be building a 10MLOC system. And the architectures, ways of working, tooling and organizations that were already struggling with building the 1MLOC system are unable to build a 10MLOC system. Hence we need to constantly reinvent ourselves. And maybe you had a good experience with waterfall development in the past, but this concerned a system that is a fraction of the size of the system you’re building currently.
Third, and the most important thing that almost everyone forgets: it’s not about agile software development. Agile software development was never the goal to begin with. The real goal is business agility. Although I have written about this in an earlier article, it bears repeating: the goal is to achieve a situation where the business can pursue new business opportunities instantly. Stop investing in ongoing projects that no longer are as relevant instantly. And to use fast feedback loops to know what customers use and gives value and what does not.
In a fast changing world, responding slower than the market is a recipe for failure. As Jack Welch at some point said: If the rate of change on the outside exceeds the rate of change on the inside, the end is near. We need agile software development. We need continuous integration. We need continuous deployment. But we also need agile systems engineering. Agile product management. Agile business leadership. We need the entire company to be agile as learning from and responding to the market and customers faster than the competition is THE critical differentiator that companies have.
Concluding, stop complaining about agile. It is the best approach we have to maintain and improve competitiveness. Longing for the good old days when engineers were happy and had the time to do a proper engineering job is useless at best and counterproductive at worst. If only, because the good old days never existed in the first place. Instead focus on true business agility where software R&D may lead the way, but where the entire company needs to organize itself around sprints, fast feedback loops and cross-functional teams in order to deliver value to customers continuously.
Jan Bosch
IT Specialist
.jpg)
.jpg)
.jpeg)
