Aspects about Scrum that I dislike and bad implementations of it

I have recently written two posts on Scrum. The first one was on mistakes I had seen people make when practicing scrum. The other was about how scrum can be great. In this post I will follow-up with some of negative things that I see in scrum. Yes Scrum has downsides as do any development methodology, whether it is agile or not. These are all my opinions and based on experiences I have had with Scrum over the years.

Sprints - the continuous starting and stopping

Sprints are great for creating focus and locking on to delivering exactly what is in the sprint backlog (focus is obviously a good thing). But why do we actually want to lock up the sprint?

I get it, completing a sprint feels like an accomplishment if you deliver everything in the sprint backlog - and a failure if you do not. However no one wants to fail. What I have seen is that most teams end up under committing which gives them an accomplishment every sprint. If they are lacking work at the end of the sprint then they just pick something from the backlog. But why plan a sprint then (usually a fixed length), why not just set up a goal and set a new one once that is completed. It is easy to be successful if you set the bar low. My believe is that we do this because the opposite is even more damaging for the morale. Over committing every sprint leads to burnout and as far as I have seen does not really give much extra.

So some teams do not over or under commit, which is great. Let us say that the team burns 20 points every sprint. They have planned 18 so far. When you look at the priority of user stories the next one is 5 points - which is already well refined. This would leave them at 23 points. The team does not over commit - which leaves them with a couple of options:

  • Put the story into the sprint backlog anyway but you know it will not be finished this sprint (over committing really)
  • Split the story even though it is not meaningful (nothing meaningful can be delivered to the users), put it into the sprint as "2" points.
  • Begin working on it during the sprint, but do not put it into the sprint backlog (makes it harder to track)
  • Do not fully commit (you will just deal with the above midsprint).
  • Make it a "stretch goal"

All of the above seem like a hack or a misuse of scrum. The problem is that we have to fit stories into boxes called sprints. I have seen teams waste enormous time on debating the above. Why not just do the most important thing first and keep the backlog prioritised?

It also seems less "responsive to change" to lock yourself in for a sprint (often 2-4 weeks). Yes I know, you can just terminate the sprint and create a new one. But very few teams do this, and do you then want a 2 day sprint or should the next one be 16 days? if you choose two, do you want to practice all the scrum rituals in those two days? - probably not.

Now to the title of this "the continuous starting and stopping". This is very opinionated but I wanted to add it. Sprints seem to give this feeling of a slowdown at the end of the sprint and a speed up at the start. In the beginning you have all of these tasks to choose from and there is so much to do (You only have 14 days to do it!). At the end of the sprint there is very little to do (even though the backlog might be full). In my experience it "feels" like stopping and starting again and again. I like the pace better when not working with sprints. To me it feels more like a sustainable pace.

Let us say you have a sprint of 14 days. But the feature you will be working on takes about 21 days (1½ sprint). You can release nothing useful after the first 14 days. Why not plan for 21 days, or just prioritise everything and release it when it is done. Why do we need 2 (1½) cycle to complete something that would naturally take 21 days? What I have seen is that the team makes some arbitrary goal of "We want to demo the front end but everything will be stubbed". It is great to demo things, but let not kid ourselves, the goal is deliver this to the customer. At the end of each cycle in scrum you should be able to deliver something. I know you can change your cycle from 14 days to 21 for a single sprint, again I rarely see teams do this.

In software development it is often seen that one team produces something that another team consumes - API's for example. However these may not be ready before you go into a sprint where you need it. What you are building depends on them getting their part done. Here I have seen several approaches:

  • Do not take it into the sprint, as it is not ready to be worked on
  • Take it into the sprint and fail the sprint if they do not get done in time.
  • Commit to create your part and mocking/substituting their part (get some work done, but might be the wrong work).
  • Under-commit and take it in if they get ready.

Only the first one in the above is in scrum spirit as I see it. As your sprint should be locked so that you can commit to deliver what is within the sprint backlog. However this is only a problem due to sprints. If working on this is the most important thing you would start working on it when it is ready - rather than working on less important things because it was not ready when you planned your sprint.

All of this leads to the question, why even have sprints? Why not demo features as they get completed, have retrospectives/refinement as needed and instead of sprints set up goals (and find new ones when the current one is met).

Do we really want to lock ourselves for a whole sprint, when the world might change tomorrow. That being said. If you have very small stories (they easily fit into sprints), you can deliver something each sprint and the priorities rarely changes during your sprints, then sprints may be a great fit for you.

Heavy on processes

Scrum has many rituals (ceremonies): Demo, Refinement, daily scrum, planning and retrospective. They are part of every sprint and repeated. When a new team start to do scrum there is a lot of processes that need to be implemented. You likely did not know that you needed to do retrospectives and you were perhaps not interested in your throughput (velocity) before you started to do scrum. Scrum has a big package of rituals which you "must do" in order to do Scrum.

It takes a long time to learn these rituals and it even requires a member of the scrum team to be a "scrum master" in order to do it. That seems like a steep curve for something that is agile. There is a lot to learn and implement when starting with Scrum, which is probably why there are so many courses and certifications being sold - just to understand all of this. It should really boil down to:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I want to state that rituals are not a bad thing. I would encourage all teams to have daily meetings, refine tasks, be in close contact with the clients (do not wait for a demo day) and reflect on your recent work (and agile methodology / development approach). But I would rather implement these rituals as I need them and pick and choose. In this way it becomes a need or a want for the team.

Organisational requirements

Scrum also comes with two roles besides the ones residing in the development team. These are the Scrum master and Product owner. The product owner is very straight forward. Owner of the portfolio of products which resides within the scrum team. Some may see the product owner as just another term for project manager. But it is not, as I believe there is a huge difference between products and projects - which I have written about here.

It may require organisational changes in order to get these roles in place. A scrum master is often found within the team as part time or a full time employee who often have a couple of teams. I am often told that a scrum master should be full time. But I have seen it work with a part time scrum master (QA staff are excellent scrum masters). However it would be a disaster if the Scrum master ended up ignoring impediments due to work within the sprint backlog, that she or he has to fulfill.

A product owner can be harder to acquire than a scrum master. As this is not a project manager who gives the team tasks and leaves again when the work is done. Borrowing someone from another department to be product owner for a while is not in the spirit of scrum. The product owner stays within the team.

When the "project" (sprint?) is over, the outcome is a product which the product owner owns. He or she should still own it afterwards and should not just leave the team to do other projects. The team needs to be stable, that includes the scrum master and product owner.

It is also often seen that the two roles are merged into one. That I have not seen done well yet and it is definitely not how it should be.

So what am I saying here? It can be hard to get these roles in place in order to do Scrum "right". It often (always?) requires some organisational restructuring. I have seen this surprise people again and again. Especially in very project oriented departments. If the wish to do scrum comes from the leadership in the company this is likely easier to get implemented. However if you do not have these roles in place you are off to a bad start with scrum.

Estimates, burn down charts and velocities

There is a lot to estimates and they are used very differently from team to team. Not just the weight of the points but also their use and meaning. Sometimes estimates are used as forecasts, planning or arbitrary deadlines. Other times they are just used to have some sort of idea of the task at hand. Some teams do not even estimate, they just refine.

In scrum they are used for calculating how much work can be put into a sprint. This is a historic approach where we look at the amount of points we "burned" in previous sprint(s), to calculate how much we can get done in the next sprint. The estimates are also used to track the team's progress during the sprint. This is done by having a burn down chart where the scrum master can see if the team is behind. This seems to be a lot of management and tracking on the team. This is intended to be for the good of the team, however I have seen this used differently. I think Adam Ard puts this very well on his blog:

"Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a teams performance is represented (ie. Velocity)"

An argument for following-up on the amount of points burned could be to visualise sudden drops or spikes in productivity. This would be an excellent item for retrospective. But this should also be reflected in the customer getting more or less than was planned. Often the spikes or drops are due to: bad estimation or that something came up from the outside (for example a sudden production problem). On high performing scrum teams I often see that it is the latter. Leaving little reason to have burndown charts or calculate velocities.

Wrapping it up

I often read and hear that Scrum is micromanaging developers. Often I hear this from teams where the decision to practice scrum comes from management rather than the development team. The development team feels it's an unnecessary overhead rather than a process that gives them and their colleagues structure, control and empowerment.

I have been practicing Scrum for years and I have been on teams where it worked well and where it did not. Scrum is great if you can deliver value to your customers on a 2-4 week cycle, have the organisational setup for Scrum roles (PO and Scrum Master), have very few maintenance tasks in the team, have the right tools (Scrum board, backlog, sprint backlog, velocity charts) and the team is stable. But that is a lot of process and setup to start with for something that is "agile".

This was my post on some of the negative sides I have seen on Scrum. I hope you enjoyed it and did not see it as too much of a rant. The above was my experiences and opinions, if you have different opinions or experiences please let me know in the comments down below :)

Remember to do the most important things first, eventually you will never do anything that is not important.