Agile Does Not Mean “More Efficient” or “Faster”
It’s a common misconception that agile means “more efficient” or “faster.”
It actually doesn’t. Agile actually means “more flexible to adapt to changing conditions,” which, on its own, can actually be more inefficient and slow you down instead.
One of the reasons that agile can be less efficient is due to fixed overhead. A prime example is deployment. A shorter delivery cycle means your fixed overhead will increase in proportion to the feature delivery, i.e. you are spending more time overall in deployment (because there are more of them due to the more frequent cycle), and therefore have less time to work on the feature themselves. The same applies to planning, code reviews, and other fixed overhead.
The hope here is of course you would be able to get more efficient on these tasks, and automate them fully if possible. Of course, that’s a set of additional tasks to do as well, which would take time away from feature delivery.
Another reason is that by being adaptable, agile allows changing the project direction quickly. This change of direction can actually cause work to be thrown away, which is an inefficiency.
Of course, it’s better for the project to change direction and introduce small waste, rather than continuing the (wrong) path, which can increase the waste to be large. However, sometimes the change of direction is to address short-term needs, instead of fully changing the long-term direction. In such case, the short-term change can be thrown out later, and can therefore be seen as a waste.
From a business perspective, such a waste is valuable, because it serves a short-term business purpose. But from Engineer perspective, it’s a “hack” and a technical debt that needs to be later removed, and therefore it’s easy to think that if we didn’t have to do this hack, we can get to the long term solutions faster, and this short-term solution means we are taking the longer path, hence slower.
The way to overcome this line of thinking is of course to recognize that serving business needs short-term is important (especially for businesses that literally fight to survive another day) and therefore valuable, and that takes priority over the theoretical efficiency that can be achieved by only addressing long-term. That way we wouldn’t think of it as inefficiency or slowing down.
However, it’s important to recognize that agile alone doesn’t mean “more efficient” or “faster”. Holding those thoughts, and propagating them can be dangerous by creating unwarranted expectations at the stakeholder level when they hear the word “agile” that is intuitively connected to “fast”. The development teams need to work hard to overcome these natural assumptions and tendencies.