Why Agile doesn't work...

According to the developers, this set of guiding principles should lead to highly-skilled software development and boost the motivation levels of engineers and product managers. However, after analyzing the work of engineers in more than 500 organizations – conducting surveys and experiments – we found that what’s happening in practice is wildly different.

In a normal (non-Agile) operation, processes and equipment are viewed as driving forces and a means of effective collaboration. We looked at a Fortune 500 business where product managers and engineers communicate exclusively using their tools, which they use to form working teams. What we found was an efficient and motivated workforce.

On the other hand, one large Fortune 100 company told us, "we’re not allowed to question the Agile process" – a statement which suggests a rigid, non-cooperative model, as opposed to an “agile”, flexible operation.

Oddly enough, in most cases, written documentation outperforms software. For example, in one large tech firm, a product development team decided to take time to write down small requirements – “user stories” – ahead of project kick-off. These were placed in the application queue as an example task for the next available engineer to start working on.

The method proved so successful that it’s now become one of many small “waterfalls”, where work is transferred from the product department to designers and engineers. This kind of process is exactly what Agile tried to eliminate. The company’s technical director said, “my engineers feel like professional chefs preparing orders in a restaurant”.

The last Agile principle “responding to changes as planned,” has been misinterpreted (by Agile teams) as not needing to have a plan in the first place. In one fast-growing tech company, the Agile team didn’t attempt to understand the organization’s broader strategy. As a result, they focused on low-value or strategically unimportant functions.

In fact, many engineers operating under Agile now consider it inappropriate to have a time frame or common milestones. Without a well-defined plan, there’s no way of knowing how to prioritize and invest in actions.

It would be great if these principles really did improve the technical motivation and productivity of a workforce but, in reality, the opposite is true. When engineers work on Agile, their motivation levels nosedive because they lose their sense of inclusion and excitement. Teams aren’t allowed to experiment, manage their work or communicate with their customers. Instead, they feel only emotional and economic pressure from their management teams. This stifles their ability to adapt, learn and drive their own work forward.

It doesn’t matter if you work as an engineer or a manager, you can make changes in order to strike a balance and increase the motivation and productivity of your team.

6 essential principles for maintaining a motivated and productive team