I have recently written two posts on Scrum. The first one was on mistakes I had seen people (myself included) make when practicing scrum. The other was about how scrum can be great. In this post I will follow-up with some of the 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 belief is that we do this because the opposite is even more damaging for morale. Over committing every sprint leads to burnout and as far as I have seen does not really give much extra when it comes to what we deliver.
This 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.
Sprints - Cutting tasks and stories so they fit in
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 overcommit - 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)
- Split the story even though it is not meaningful (nothing meaningful can be delivered to the users) and 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 mid-sprint).
- 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 and I have seen teams waste enormous time on debating the above approaches.
Here I think it is important to remember to do the highest prioritised and meaningful task/story first and keep the backlog prioritised, independent of the approach you choose from the above.
Another observance I have made is that sometimes developers are so eager to "finish" their tasks within the current sprint that they cut corners. Have you ever said "I am going to write automated tests for this feature in the next sprint" and then moved the task or story into the done column? Did you remember to write that test? Well some do, but from what I have seen you do not get around to do it, instead you end up with a bug in your production environment and in your backlog.
Sprints - they are often fixed length
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½) cycles 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 on the backend". 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 meaningful. I know you can change your cycle from 14 days to 21 for a single sprint, again I rarely (never?) see teams do this.
Sprints - team dependencies
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 creating 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.
Sprints - the demo is at the end
I have always enjoyed close collaboration with users and customers. One thing I have seen over the years is that developers have a tendency to wait with demonstrating features until the demo session at the end of the sprint. It makes sense to show your users the features you make as soon as possible to get feedback immediately. However when we "have a meeting for that" we tend to wait until that time, especially if we are near the end of the sprint. The demo meeting makes sense if your users are often unavailable, but that is rarely the case in these days, they are merely a video presentation away.
Heavy on rituals
Scrum has many rituals (ceremonies): Demo, Refinement, daily scrum, planning and retrospective. They are part of every sprint and repeated. When a new team starts to do scrum there are 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, he owns 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 more 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 alternatively as a full time occupation where the scurm master has several 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). But the Scrum master should be careful not to ignore 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 with the team and its product.
When the sprint is over, the outcome is a product increment 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 sometimes 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 organisations. 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
Estimates are different 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 size/complexity of the task at hand. Some agile teams do not even estimate, they just refine.
In scrum estimates 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 sprints, to calculate how much we can get done in the next sprint. The estimates are also used to track the teams progress during the sprint. This is done by having a burn down chart where the scrum master can see if the team is ahead or behind schedule of the sprint. This can feel like a lot of management and tracking on the team, but it 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)"
The bottom line is that estimating work can be a great tool, as it gives us an idea on when we can move on to the next task or identify if we have enough to do in the coming future. The problem arises when velocities, burn down charts and performance starts to be communicated based on these metrics. This is an issue I often hear about from companies where the want to do Scrum comes from the organisations leadership, rather than the individual teams. This is not something that is wrong with Scrum, but rather a bad practice of it.
Burn down charts and velocities
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 and can kick off the discussion. But often the spikes or drops on the burn down chart are because something came up from the outside, for example a sudden production problem, somebody falling ill or organisational changes which are hard to do anything about. If the burn down chart looks good it is often because nothing unforseen happened. Most things the burn down chart can tell you, you already know and it can do more harm than help if it is used for measuring and reporting performance.
I have been on teams that have had excellent burn down chart on most sprints and I have been on teams that have never had a good burn down chart. When I think back I believe the latter was the most productive, as the focus was not on doing the process right, but delivering the most important and valuable to customers first. That is of course, a very unscientific claim.
Velocities are fragile in the short run (they get better over time). If the team picks up a new technology or has a product from another team added to its portfolio, the teams performance can tank. It can be hard to estimate tasks and stories and thereby have a successful sprint. Until there is a new normal the velocity can become close to useless, almost as starting a new team. The success of our sprints are highly dependant on a reliable velocity, which makes the overall concept fragile under "unstable" circumstances.
Besides being used for how much we can put into a sprint, the velocity often tells us that teams that stay together, have stories and tasks that are alike and have few outside disturbances perform better for every sprint. We see this as a rise in velocity over time, but this should not be a surprise. Instead of measuring "performance" using arbitrary points or hours, I personally would rather look into the value that the team brings. "Like this week we launched a new site that reduced the amount of calls to customer service by 90%", "we had 10% more conversions on our webshop due to our new call to action" or "we had no operational downtime this month due to our increased resilience we built".
Wrapping it up
I often read and hear that Scrum is sometimes micromanaging developers. Often I hear this from teams where the decision to practice scrum comes from management (top down) rather than the development team itself (bottom up). The development team feels it is 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.