Stop Talking About Agile

This week I spent time at several conferences and I noticed something surprising: Almost 20 years after the publication of the Agile Manifesto, there are STILL people talking about their agile transformation and consultant companies talking about the challenges of adopting agile practices. What in heaven’s name is going on here?

Let’s be clear here: unless you have some very good reasons why your organization should or could not use agile, you should have adopted agile years ago. And if you’re still struggling with that transformation today then, as a leader, you’ve been sleeping at the wheel and failed to live up to what can reasonably be expected from you. There is no reason why a company, in 2019, would not be using agile.

The argument that some business leaders bring up is that agile is just a way of developers to get away from providing accurate long term estimates and predictions and to focus on their own priorities rather than the business. This is, of course, an incorrect viewpoint. The main advantage of agile practices is that these provide the starting point for shortening the feedback cycles in the organization and between customers and the company. In an earlier post I outlined why fast feedback cycles matter.

In a paper that we published in 2012, we introduced the typical evolution path that companies evolve through when it comes to software R&D. As shown in the figure below, adopting agile practices is just the first step after traditional practices. The next steps are concerned with building up the continuous integration & test infrastructure and continuous deployment to customers

The second argument that still comes up is that our customers don’t want agile, but instead want yearly release cycles. Again, that is an incorrect interpretation of the situation in almost any company: everyone likes their systems to get better all the time. The main reason that they don’t want more frequent updates is twofold. First, the quality of new releases is poor and companies run into all kinds of issues when upgrading which is costly and bad for productivity. Second, the amount of effort associated with upgrading the software is significant to the point that your customers can’t afford to upgrade frequently.

For both concerns, modern companies use the same solution: automation. Continuous integration and test is concerned with ensuring that software is always at production quality. Every time an engineer checks in code, within minutes, hours or a day, the quality of the checked in code has been confirmed or it has been removed and returned to the developer. Similarly, deployment of software should be automated and require no or minimal human involvement.

Interestingly, our research shows that automating parts of the process has significant side benefits as well. Automation requires standardization of practices and clear interfaces between different functions. In many ways, it forces the entire organization to become more professional and structured.

Of course, implementing changes inside the company is hard. Implementing changes in your business ecosystem, such as the interface with customers, is in many ways even harder. As a leader, however, it’s your responsibility to prepare the company for the future and minimize the risk of disruption. Failing to implement important industry best practices such as agile, continuous integration and continuous deployment is a failure of leadership. It’s your darn job to implement these changes!

Concluding, today in 2019, adopting agile practices is a no-brainer and if you haven’t done so, then there is good reason to question your choices. Not because agile makes developers happy, though it does, but because it simply makes business sense to have fast feedback loops instead of slow, yearly cycles. It’s time to stop talking about agile and instead focus on the next steps of moving towards continuous deployment as industry, these days, has a need for speed.

To get more insights earlier, sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).