Agile software development has become very popular over the last twenty years. Today, you’ll be hard pressed to find a company which openly admits that it’s non-agile. However, when looking beneath the surface, you’ll find that not all companies which claim to be agile actually are. In this blog post, I’ll explain what prevents these fake agile companies from becoming agile and how the employees and managers in such a company should deal with this situation. But first, what exactly is agile software development?

Agile software development is characterized by:

  • Continuous delivery: Software is delivered to the customer in small, frequent increments, allowing for a quicker response to requirement changes.

  • Cross-functional teams: Teams are typically composed of individuals with a variety of skills which enables the team to build its part of the product independently.

  • Customer involvement: Customers are involved throughout the development process, providing feedback and input to ensure the software meets their needs.

  • Continuous improvement: The development process is constantly evaluated and improved, with a focus on learning and adapting to changes in the environment.

While agile software development is often associated with specific methodologies, such as Scrum, Kanban, and Extreme Programming it is not enough to just follow such a methodology. For example, a company might use Scrum, but if it only delivers twice a year it doesn’t use continuous delivery and as a result cannot be considered agile. It’s easy to create a mismatch between the used agile methodology and the non-agile reality as being agile is hard. Continuous delivery requires very efficient processes and high-quality software. If software quality isn’t on point, it will be tempting to release less and less often which will make the company less and less agile as a result. Customer involvement is also difficult to achieve in practice, especially in bigger companies with more layers between the developers and the customers. Continuous improvement is challenging as well as many companies tend to stick to their current ways unless something dramatic happens.

Any company which is agile on paper but not in reality is a fake agile company. However, while some fake agile companies are just unaware of their shortcomings and hence genuinely believe that they are agile, others are aware of their deficits, but don’t address them. While the first kind of company might eventually become agile, the latter will remain in its current state as it doesn’t want to change. This might seem hard to believe given how popular agile development is. However, agile development isn’t as popular in practice as it is in theory: Any top-down company with little trust in its employees will reject agile. Empowering the teams (and thereby giving up control) is at the heart of every agile method, but this clashes violently with the top-down company culture. As a result, agile will only be implemented superficially while under the hood everything stays the same. Without changing the company culture, it is impossible for such companies to become truly agile. Naturally, this isn’t something a company likes to admit. As a sidenote the infamous waterfall development model is a great fit for such a company as it is openly top-down: The experts in charge plan everything and the developers just have to implement.

So, how can you know whether a company is truly agile or just pretending to be? I don’t think it is possible to understand this by looking at a company from the outside as you cannot rely on the company to be honest about it. Some fake agile companies even hire agile coaches to (officially) help them become agile, just to (unconsciously) sabotage these coaches. It is important to note that not everyone in a fake agile company is consciously sabotaging agile development. Many will probably be completely unaware what agile actually means and that they prevent it with their behavior. The only way to find out whether a company is a fake agile company is to use the principle of revealed preference, meaning that you can only rely on observed behavior: If someone tells you how important agile is while working in a top-down-manner, he either doesn’t know how agile works or doesn’t want to become agile. In a top-down company, any agile coach will be ineffective and my recommendation is to look for another job if you’re in this situation. Also, if you’re a developer in a top-down company, you’ll have to accept that you’ll never work in an agile fashion. It is no use to point out when you’re deviating from textbook Scrum or whatever other agile methodology you’re using. The problem isn’t the methodology or its implementation, the problem is the company culture and the people within the company. You can either accept the status quo or join a different company. That said if you’re a manager or a product owner in a top-down company, you can improve things by empowering your team even if you can’t change the rest of the company.

Conclusion

Fake agile companies claim to be agile, but aren’t and sometimes even have no intention to become agile. You should be aware that such companies exist and avoid them both as developers and as agile coaches. As a manager or product owner you should try to empower your team even though you can’t change the rest of the company. If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.