Part 2: Why Agile Software Development Doesn't Work

Of course, the somewhat provocative statement of this blog title should not be misunderstood. Agile software development can very well work: if all stakeholders and project participants understand what agility means and management allows them to really live it.

However, when agility does not work and what many companies stumble upon when introducing an agile approach, we have summarized them in the following pitfalls:

Too little commitment and understanding of agile methods

Mastering the transformation from traditional to agile project management requires commitment and the willingness to change things. And not just for developers and project managers, but at all levels - from interns to management.

In addition to a lack of commitment, many companies simply lack the knowledge of how agility can be successfully applied and lived.

The introduction of new tools and frameworks is not enough

Some companies assume that with the introduction of a daily standup and a Jira or Trello board, they are now agile. You guessed it: far from it. A truly agile approach requires much more than adopting tools or a framework such as Scrum (Caution! Scrum and agile software development are not synonyms. Scrum is one of several agile frameworks that help teams in a volatile, iterative and efficiently functional environment deliver software).

Savings in the wrong place

There is sometimes a perception that retrospectives or the use of the Scrum Framework by the Scrum Master do not create any business value. In many cases they are simply rationalized away. The same applies to code reviews or writing automatic tests. This is a mistake and can be fatal. While a user story generates new business value in the form of a new functionality immediately after implementation, retrospectives or the Scrum Master have a more long-term effect on the quality and also on the velocity (speed of the team). So if you save money here, you will spend even more money in the long term.

Too little collaboration between business and development

In the classic waterfall model, the development team withdrew after the concept and specification phase and only saw the customer again at the demo of the finished product. The business did not know where the team stood with its developments and the development team in turn did not know about daily business and any changed circumstances or requirements.

In order to be able to react quickly to these things, you need transparency. Everyone involved must be informed at all times about the project status, possible problems or changed requirements. This is exactly what becomes impossible if the development team is not involved enough and therefore has too little contact with the business.

Contracts and framework conditions do not allow agility

An agile approach and at the same time a precise project plan with milestones and a fixed price are often required. In order to be able to specify a fixed price, very precise requirements are necessary. As a rule, about 80% of the requirements must be known and clearly documented. If this is the case, an agile approach definitely makes no sense. Because one of the four basic principles tells us: "Responding to change over following the plan". So you should react to changing circumstances or priorities instead of sticking stubbornly to an original plan. A fixed price and project plans linked to it can make sense for projects with a small scope. However, agility has no place in these projects.

Relapse into "old" behavioral patterns

It's perfectly normal to fall back into old behavior patterns when you've worked many years after waterfall and realized projects with the help of milestones and fixed prices. It often happens that companies want to be agile, but do not react accordingly, especially in hectic situations.

Overriding the self-organized team by management

There are teams that have understood how to work according to the basic rules of the Agile Manifesto. For example, they implemented Scrum as a framework and found a way to make agility work for them.

As long as it pays off financially and everything goes according to plan, this is often approved by management with little experience in dealing with agile methods. However, if the company gets into trouble, that's the end of it. No matter how the agile project team's Scrum process is lived, management begins to intervene - and since it is management, unfortunately, it can - and takes control. This is exactly where agility stops.

That doesn't mean that leaders don't have a say in projects or in product development. But on the contrary. However, it is important that they also adhere to the defined processes and that they are not allowed to override the decisions of the Scrum team, even if they are located higher up in the hierarchy.

Conclusion

Do any of the listed pitfalls look familiar? Several? You are not alone in this. Many companies struggle with agile transformation and not without reason. Changing known project management methods and procedures, working agile is a challenge. Take your time and stick with it.

In the third contribution to our "Agile Software Development" trilogy, we show which tips you can use to transform to agile software development.