During the last few years, I’ve worked in teams following the Scrum agile process framework. While I’m a strong opponent of waterfall software development and everything with the same mindset (e.g. big software design upfront), I’m not a fan of Scrum either. To be more precise, I think that Scrum can work very well in certain circumstances. However, it is not a panacea. Sadly, many people are not aware of Scrum’s prerequisites and hence have limited success with it. In this article, I want to list seven signs that your Scrum isn’t working properly.

Sign number one: You don’t have direct access to your key stakeholders/customers. Scrum is based on the idea of having small iterations called sprints. At the end of each sprint, you are supposed to get in contact with your key stakeholders and check whether what you’ve built matches their expectations and requirements. Furthermore, the next top priority needs to be worked out in this meeting so that it can get tackled in the next sprint. This works fine if you are in close contact with your key stakeholders, ideally, they are available on site during the development process. However, things will get very hard if there are too many layers between the key stakeholders (i.e. the ones paying for the product) and the development team. In this case, it will be very hard for the product owner to gather the detailed requirements and to verify that they are fulfilled.

Sign number two: You have very diverse skill sets in your Scrum team. Scrum assumes that all developers in the team are able to pick up all required tasks. If skill levels and/or knowledge levels are very diverse in your team, you’ll have trouble assigning the upcoming tasks to your team. Say, for example, that you are an eight-person team, but only one of your developers can do front end tasks. Now, what do you do if you have two UI tasks assigned to the same sprint which cannot be done by one person due to capacity constraints? You can either push one of the tasks into the next sprint or assign it to one of the less suitable developers hoping that he can get the job done. Neither is an ideal solution. It is dangerous to have bottlenecks like this in your team as the high impact developers might get sick or switch jobs. However, it is also very difficult to spread knowledge evenly in your team, especially because the skilled developers likely have to do the knowledge transfer which will slow them down. I’ve written about the problems with knowledge transfer meetings before and I think that many development teams don’t have the luxury of spreading knowledge evenly in the team. And let’s not forget that the amount of output and the quality of said output differs greatly between developers. If you only have one star in your team, you will not be able to replace him. Scrum offers you no way to track these bottlenecks and doesn’t properly work in this situation. You can only track the poor overall team performance via the sprint velocity but this velocity is overly impacted by your single star. If he’s on vacation, velocity will take a sharp dive. This inconvenient truth isn’t reflected in Scrum and rarely talked about.

Sign number three: You have a full-time Scrum master. The role of the Scrum master is a weird beast. According to Robert C. Martin, it was originally intended to rotate in the team and was only supposed to be used during the ramp-up period of Scrum, i.e. the time a team needs to get used to the Scrum processes. However, the role turned out to be highly attractive to former project managers and also provided a great opportunity to sell certificates. As a result, the role is now permanent in most teams and some teams even have a full-time Scrum master. This is a warning sign that your Scrum processes are too verbose and bureaucratic. According to the official Scrum guide, the role of the Scrum master is as follows:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

Your team must be very bad at Scrum if that requires a permanent dedicated full-time employee. Also, these tasks seem rather vague. A more detailed list of daily tasks is given by Scrumhub:

  1. Facilitating (not participating in) the daily standup
  2. Helping the team maintain their burndown chart
  3. Setting up retrospectives, sprint reviews or sprint planning sessions
  4. Shielding the team from interruptions during the sprint
  5. Removing obstacles that affect the team
  6. Walking the product owner through more technical user stories
  7. Encouraging collaboration between the Scrum team and product owner

Again, this is a very “soft” list. Points four to seven can mean anything while points one to three require minimum effort if your tooling is on point. It is hard to justify dedicating a full-time employee to these tasks. Hence, I think it is best to have a part time Scrum master or none at all. Remember that according to Parkinson’s law, work expands so as to fill the time available for its completion. Hence, you will end up with a heavy-weight Scrum if you have a dedicated Scrum master. Most likely, this isn’t what you want.

Sign number four: You lack clear focus in your Scrum rituals. This problem often affects the review process. In Scrum, the product owner decides whether a feature was developed in a satisfactory manner. This review can be organized any number of ways, but it is important that the focus remains on matching expectations with results. In some teams, newly finished features are presented in a demo meeting to both the product owner and the rest of the team. The idea is that the product owner can do his review and at the same time the rest of the team can get educated about the new feature. While this sounds enticing, it is not a good idea as it tries to solve two problems at once. The product owner needs to closely look at the new feature and cross check the requirements list with what exactly was developed. This takes time and is most likely too involved for a demo meeting where the rest of the team is present and where several topics are supposed to be discussed. If you want to spread knowledge about a feature in the team, you should document it on a wiki page and/or host a separate session. Mixing goals in meetings is never a good idea. All of your Scrum rituals should have an observable impact on your team. For example, if the problems addressed in the retrospective don’t get solved afterwards, the meeting is just a place to vent your frustrations. While this can be cathartic, it is a poor use of your time. The daily Scrum is another repeat offender in this regard. The point of the daily is to plan the work of the team for the next 24 hours. Sadly, in reality it often turns into an unstructured waste of everybody’s time. Many developers feel pressured by the daily and will say anything which comes to their mind to justify their work (or lack of it) in the past 24 hours. Also, I find it hard to believe that a team has such a dynamic planning that it needs to revisit it every day. Aligning two to three times a week should be enough in most cases.

Sign number five: You focus on sprints even though it is not appropriate for your situation. Sprints are the iterations in which you deliver your work. Each sprint is supposed to have a goal and at the end you are supposed to review whether you’ve achieved it. If not, you’ll either have to continue with the work in the next sprint or come up with another, less work intense idea. Also, the end of the sprint is the point in time to get in contact with your key-stakeholder/customers to check whether what you’ve built matches their expectations. That is all well and good, however, it comes with some overhead. Tasks have to be sized so that they can be tackled in one sprint. This means that you may have to artificially break down tasks if your sprints are too short for them. Also, you have to keep track which tasks are assigned to which sprint and whether they are actually completed on time. If you don’t deliver (i.e. ship to your customers) software each sprint, this overhead might be not necessary. If you only ship software every three months, it doesn’t matter whether a new feature is finished in the very first sprint or the very last. Nevertheless, the sprint structure might be beneficial for internal synchronization between teams. In the end, all that matters is that a feature is included in the release. Hence, you should verify that the sprint structure provides benefits in your situation and not just blindly follow it.

Sign number six: You are frequently blocked due to external factors. There are many external factors which can mess with your progress. Maybe you work in an high bureaucracy area where progress can grind to a halt because some “necessary” approval processes are taking much longer than planned. Or maybe you frequently deal with tough and time critical customer issues which cannot be delayed. Or you are depending on some other team which is notoriously bad at delivering their already committed features on time. If you are very unlucky, you will have a combination of all of these. Such a situation is far from ideal for Scrum, as there is no point in setting a sprint goal if there is a significant chance that you’ll miss it due to no fault of your own. Also, there is no good way to model these bottlenecks in Scrum. You can slap a “blocked” post-it on the appropriate task on your Scrum board, but this isn’t very helpful. For example, you might run into the same problem in a sprint with two of your tasks, because they depend on the same overloaded central team. Setting the first task to blocked, doesn’t make it clear that you’ll also face the same issue with the second one. Here, something like Kanban might help, because it allows you to model these critical external resources as pipelines.

Sign number seven: Your backlog refinement process is very heavy weight. Backlog refinement means transforming the raw, coarse-grained “epics” in your backlog into smaller work packages which can get tackled in a Sprint. Some teams like to do this with the full team present. From my point of view, this is not a good idea as it is extremely expensive and often very unfocused. Instead, the refinement should be done in small groups of two to three people. If another teammate is interested in the details, he should be able to get them from the tasks themselves. This negates the need for any preemptive knowledge transfers.

That concludes the list of signs I’ve seen in the past. Hopefully, this list helps you pinpoint some problems in your Scrum and will inspire you to address them. If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.