The top 5 reasons why Scrum and Agile fail

As useful and innovative as it can be to work with agile methods such as Scrum and Kanban, there is also a great risk of failure. But why is that and what are the most common reasons?
On the platform, Georg Maureder ponders this question. His core topics are application platforms and enterprise software, and he has been working in management consulting for a decade. Agile methods such as Scrum and DevOps keep him busy every day. How can it be done faster, how can it be done better, how can it be done agilely? Why do agile methods fail? In the following, we summarize his theses for you.
A man's glasses reflect lines of code

Agile - still the future

The idea behind the use of agile methods such as Kanban, Scrum or even Extreme Programming is the use of software in an iterative process in which feedback from users is continuously received. The approach is in contrast to the traditional variant, where basically a final product, a finished solution is presented. The waterfall method, in which a project phase always begins when the previous phase has been completed, is a thing of the past because it is simply far too cumbersome and slow. No one can afford to spend years developing a product anymore, and thanks to agile methods, no one has to. A huge advantage of agile methods is that all user requests can be captured and directly incorporated. In addition, errors are detected and corrected more quickly. Using Scrum as an example: In addition to the product owner, the Scrum master and the team, the user plays a decisive role in the development process.

Error prevention in agile development

Like all new models, Scrum, Extreme Programming and Kanban had their teething problems. The models are no longer in their infancy and are used by millions of companies worldwide. In many cases with terrific success. Nevertheless, there are still the typical stumbling blocks that cause one or the other project to fail. Therefore Georg Maureder has collected the five most frequent and fatal mistakes. Although every company deals with Scrum differently, there are commonalities that Maureder has observed several times in his career as a corporate consultant.

1) Lack of communication

Inadequate communication and lack of trust within the team can deal the death blow to an agile project. Even in a well-oiled team, communication can be lacking under high pressure. Team members often have to create new features within a week or two, and communication can suffer as a result. So leaders should make transparent and timely communication of deadlines and other important information a top priority. Emphasize once more rather than once too little that you are all in the same boat and pulling together!

2) The Scrum Master does not fulfill his role

The Scrum Master is responsible for the stakeholders and for managing the team. It is his responsibility to get hurdles out of the way and to have the team's back. Coaching the product owner is also part of the Scrum Master's duties. Issues of company policy should always reach the Scrum Master and not even reach the individual team members. Micromanagement is definitely the wrong approach. As a Scrum Master you have to learn to trust your team and find the balance between integration into the team and a good overview.

3) The product owner cannot get his way

Georg Maureder emphasizes that the product owner must not let himself be pushed around under any circumstances. Give clear instructions. You are the interface between users and the team. You need to understand user requirements but also manage them and then pass them on. Don't pass user feedback to the team unfiltered and unorganized. Make decisions and stick to the product vision!

4) The requirements are too complex

Quite a few projects have failed because user requirements were simply too complex. There is a list of 84,766 elements that need to be incorporated into the software? Preferably on an equal footing as well? There has to be a clear no here. Or a sorting, a filtering, a decomposition of the requirements into bites or steps. Stories, as the Scrum inventors say. Depending on the complexity of the project, the timeframe for testing may need to be adjusted. Keep the overview!

5) The team is more agile than the tools.

If your tools are not as agile as your team, that could also be a problem. Use development tools that match the state of your agility and try to offer your team the appropriate features and programs. Nothing is more annoying than a super agile team that is slowed down by technical capabilities. You don't need the most expensive tool or the most agile tool, you need the exact tool that best suits your team. Every team is different and every company has its own culture. This is where a little experience, trial and error, and good will are needed.
Author: IAPM internal 

Key words: Project management, Agile project management, Scrum, Tips

The IAPM certification

The certification can be taken via a reputable online examination procedure. The costs are based on the gross domestic product of your country of origin.

From the IAPM Blog

Become a Network Official

Do you want to get involved in project management in your environment and contribute to the further development of project management? Then become active as an IAPM Network Official or as a Network Official of the IAPM Network University. 

For better readability, we usually only use the generic masculine form in our texts. Nevertheless, the expressions refer to members of all genders.