Your company or team has tried everything. Scrum, DevOps, Lean, SAFe, coaches, external help, internal help, and fill in other options you tried. Still, you keep having the same problems. Maybe they even become worse. What are you doing wrong?

First a note in the beginning. I am not an Agile expert. I am an analyst. I have analyzed all Agile projects and teams I have been a part of or in any other way worked with to see what worked and didn’t work. That is what I based this blog on. If that is not enough for you, just don’t read this blog.

Second, I am purposely going to use the word ‘Team’. That is because I do not want to suggest only managers or leaders can prevent Agile failures. Everyone can. But where I write team, you can also read department, company, or every group of people you can think of.

Why the failure

What I see a lot in the implementation of the Agile method, is that methods are introduced, but the real problems are not being handled. Which makes success almost impossible. This is also because of the way many Agile methods are sold. Just do as we say and your problems will be solved. If this doesn’t happen, you didn’t do what we said.

So, here is my opinion about the problems you should solve before Agile can become a success. No matter the method. I will also use them to explain why so often Agile projects keep failing. The problems are prioritized based on my experience. Because I really believe if you have not solved the first one, you cannot solve the second one.

Problem 1: Ask the right questions

I am a tester. So, it might not surprise you I want a tester on every team. And I really stand for this. But if I am honest, I have to admit something. I have seen teams without a tester delivering very good quality. And teams with a tester delivering very bad quality.

Many times teams are checked with questions like “Do you have a tester?”, “Do you have retrospectives?”, “Do you have a Scrum master?”. But a tester that doesn’t test properly, a retrospective that doesn’t improve anything, and a Scrum master that doesn’t improve Agile, it doesn’t add any value. If you ask questions like this, you might miss what is going well already. Teams might have found other ways to improve, by just talking to each other day to day. But you might also miss what is going wrong. Just because the team is doing retrospectives, doesn’t mean the team is growing and learning.

The questions mentioned are asking about solutions. A Scrum master by itself doesn’t improve your team. What do you want to achieve with this Scrum master? You might want a Scrum master because your team isn’t working well together. Then the right question is “Is the team working better together?” This is a question about the problem. It gives people the freedom to find solutions they believe will work the best. And it gives people the freedom to say “Our Scrum master isn’t helping to solve this problem”.

If you do not ask the right questions, you cannot find the right problems to solve. And you will create a distance between yourself and the other members of the team. Because you talk as if you have no idea what is really happening in the team.

Problem 2: Are you and your team learning and improving

I believe in the retrospective as an important tool, but I have almost never seen it implemented in a manner that really helps the team. People agree to improvements, do them for one sprint and then stop doing them. Or they don’t even start. And in the next retrospective, another problem is discussed, so no one notices. 

You can have any evaluation moment and tool you want, if you or your team are not motivated to learn and grow, it doesn’t help. You say ‘Yes’, you do ‘No’, and most of the time no one notices. They have moved on to the next problem they have seen.

If you want any Agile project to succeed, you and your team must be willing to learn and improve. So you can start solving problems that are hindering your work and your team. And make your job easier and more fun. And give you the opportunity to finish your project in the right way.

So, first, look in the mirror. Do you accept good feedback from your manager? Do you accept it from other team members? From other persons with the same functions? If you are a manager yourself, do you accept good feedback from people below you? Do you have any people that give you feedback in your environment? Are there other ways you evaluate your own work? When something goes wrong, do you most of the time say “Nothing I could have done” or do you seriously look at what you could have done better? In short: how do you find out if you are doing something wrong?

And what about your team? Is your team improving the way they work? Is the product improving? Or are you talking a lot, but in the end don’t change anything? And keep working as you worked before? And because of that keep making the same mistakes over and over again?

The most important thing you must believe is: learning and improving is not something you do for your manager or your company. You have to do it for yourself. To be better in your job. To enjoy your job more. To make your job easier. The reason doesn’t matter, as long as it is a personal reason. So you do not need retrospectives or any other tool or person to remind you to keep doing improvements. They just help you to find what to improve.

Problem 3: Are you working together?

In one company I worked for, I and some colleagues did Jigsaw puzzles together. In the kitchen, on a table, the jigsaw puzzle was available for everyone to just take a short break and lay some puzzle pieces. That was fun to watch, certainly when people started complaining about each other. One person started by sorting out the border pieces. And then another one started sorting the pieces by color. I have no idea which method was better. But it was very clear that following both methods at once really didn’t help in solving the puzzle.

What I have learned is that very often it doesn’t matter that much what the best solution is, what matters is that your whole team agrees. The best solution will not matter if even 1 person doesn’t want to do it. But the worst solution will bring improvement if everyone agrees to it and follows it.

So, how is your team doing? Are you and your team members constantly trying to convince each other that your problem is the biggest problem? Or your solution is the best solution? Do you feel like your team members are making your work more difficult? Do you get told that you make the work of your team members more difficult?

Or are you and your team members able to agree on what path to follow? Do you find yourself fighting for a problem of another team member? Do you notice other team members helping you with your problems?

What is very important is, that you and your team members stop seeing each other as obstacles. Realize that if you are not able to agree as a team, nothing will ever change. Not for you, not for your team. It’s not about the best solution, it’s about being a team. That is the only way to improve anything.

Problem 4: Can you and your team prioritize?

Yes, I have met him. The manager tells team A “Your work is important”. And then telling team B “You do not have to help team A”. Most of the time prioritization problems are that obvious, but it does happen. And it is an example of why prioritization is very important to do in the right way.

When you and your team are willing to learn and are working together, the next problem is questions like: ‘what should we do first?’ or ‘what should we solve first?’

In my experience prioritization can have three main problems. The first one is that discussing it can take a very long time. Everyone finds one thing more important. For this the solution is simple: before you prioritize, agree on how you are going to prioritize. Are you going to trust 1 person to do the prioritization? Are you going to give an estimation of risk, impact, and needed time and prioritize based on a calculated score? Are you going to reserve a certain amount of time for every group like product improvements, bugs, and process improvements? After you have agreed on that, only then start the prioritization. You will find agreeing on “Risk is 3 out of 5” is easier than “Priority is 3 out of 25”.

The second problem is not prioritizing everything. You prioritize the improvements from management, but do not prioritize the bugs mentioned by the service desk. And because of that you never have time for them. Result: a very low quality. Or you only prioritize changes on your application, never maintenance tasks. So, you never do it. Result: building takes more and more time and the number of bugs increases. 

You can recognize this when people in your team or people outside your team start saying “I feel treated as if my work/department/function is not as important as ……..”.

The third problem is having different prioritizations, that conflict with each other. One person is working on refactoring the code that another person needs to change for a functional improvement. Both want to finish their task as soon as possible. But they cannot both succeed. Or a person needs help from someone in the team, but that person is working on something else. So, doesn’t have time. These kinds of prioritization problems must be resolved in a way the person whose work gets the lower priority understands. But also the rest of the team understands why that person is not finished or finishes later.

In general: how to prevent failing

If you want any Agile method to succeed, you must have a good team. A good team is a team that is willing to learn and grow, listen to each other, and does not hinder each other. This is not something that can be created by introducing Scrum, DevOps, Lean, SAFe, or any other Agile method. I really believe that you first must have a good team and only then start with the introduction of any Agile method. If you do not agree, at least be aware that this needs attention while introducing a new method. If you do not and one of the problems above is there, you might get an ‘A’ in following the method, but the result will still be an ‘F’.