Why Scrum doesn't work?

Let’s start by saying that companies hardly do Scrum by the book. I will never forget a project manager, who, after he arrived to the office one day put a big “Scrum” on our whiteboard and announced that from now on we will be doing Scrum. You wouldn’t guess what we did afterwards. Every morning, he was assigning tasks for the day to team members which were supposed to be finished that day. And he would do it in sentences such as “you are going to do 978 and you 988”. Team work? None. Sprints? None. This is how much confused some people are, even if reading all about the process takes just a couple of hours.

There are of course many companies and teams trying to use the real Scrum for their work, but there are obstacles which makes using it a bit difficult.

Let’s start with specification. Tickets should be groomed (well specified), estimated and understood to reduce the chance that there are not any associated impediments. This is to know if the team can start working on the tickets and how much work they should try to do in a sprint. If there are dependencies for the work on people outside of the team, there is a high risk that such User Stories will not be finished in the sprint. The same goes for tickets too large that should be first studied a bit more before coming with more detailed specification.

However there needs to be some flexibility in the specification of User Stories. If something useful should be delivered at the end of the sprint, it doesn’t make too much sense to try to be 100% aligned with the specification. The team needs to be able to simplify things if necessary, so that there is something done at the end, even if it is not perfect.

Sprint planning is crucial. It should be done with the team, and it should be incremental. It should discuss all individual tickets going into the sprint one by one, as well as a higher goal or main goals of the sprint so that even priorities are well set in the sprint itself. Also, the team has to speak up and be firm in saying that the amount of work is enough. Too many times I have been part of planning where Product owner adds more and more tickets without discussion and the team doesn’t say anything. Also, it makes sense to further define tasks for each ticket or at least divide bigger ones into smaller ones and align the team in who will do what, at least at the beginning.

During the sprint, distractions and other responsibilities for the team members will kill your productivity, but on some projects or in some companies they are inevitable. Support will ask your team questions, bugs will be discovered in production, grooming, architectural or other discussions need to be done, unplanned work appears. Whatever it is, it will slow you down. Try to avoid this kind of distractions as much as you can. And when you plan your sprint, leave some space for unplanned work.

Another killer during the sprint is adding more work. This shouldn’t be done, of course, but sometimes priorities in the company change faster than sprints. Product owners should understand however, that the work should not just be added, but rather exchanged for something else that will not be done, and moreover he should count with the fact that changing the focus and attention of the team has its own cost.

After the sprint is done, try to do a demo for the Product owner. Maybe some of the things (bugs, etc.) are not easily demo-able, but try to demo at least the main goals of the sprint. Without demo, there is no sense of accomplishment and no sense of responsibility.

Some teams don’t work as a team. Sometimes, this is because of the nature of the tickets where a lot of mutually unrelated work is put in the sprint, which makes it harder to define a main sprint goal and align the team effort. Sometimes, it is a cultural thing where people care only about “their” tickets. Also, some tasks require domain experts and cannot be shared. Either way this is quite difficult to overcome and the bigger the team and the product, the more likely it is to happen.

Some teams are too big. When you start having problems with organizing and finishing the work in the sprint, there is a chance that your team is too large. The more people you have on the team, the more discipline you will need. As an easy example, think about stand-ups. With more people, the chance that one of them will digress during this simple report is significantly higher. Also, since the stand-up is longer, people often lose attention and just impatiently wait for their turn to speak, without really listening to others. However, while solving long stand-ups is fairly easy, organizing the whole team to coordinate in other areas is more difficult.

Even something as basic as to have accurate Scrum board is something that many people struggle with. A Scrum master can help with this and some of the mentioned problems. After all my experience with Scrum, I’d recommend having one.

Last, but not least, the number one killer of Scrum is when nobody wants it. When people don’t want to work in Scrum or don’t care about the process, the process will not work well. Some people are completely indifferent to the process used. This leads to small cracks here and there and in the end nobody respects the boundaries of the process anymore. This is true especially if process is violated by Product management or some other entity in charge*,* but bad practices can catch on between team members equally well.

Scrum can work, of course. I have seen it! It was when we were working on a completely new product from scratch, without any distraction by fixing bugs in production in the middle of the sprint, without any product changes during sprints, with good ticket preparation, including proper wireframes and time to nicely divide and organize tickets, it was in a team with people on a similar level of skill-set (everyone could easily work on everything), it was in a team that had a dedicated Scrum master and the process was followed strictly.

Scrum is just a tool. Use it as such. I believe that by using retrospectives and adjusting the process you should be able to find something that works for the team, whether that means that you will be doing something a bit different than Scrum or you will abandon Scrum altogether. The world has more colors than some of the agile consultants would like to admit and there is no reason to stick with something that doesn’t work very well for you.

Last updated on 5.5.2018.