Scrum pitfalls
How to identify, avoid and solve.
My journey with agile started in 2011 when I was a student and started to read articles about software development. Soon I noticed that people are writing about agile, Scrum, kanban, XP and various methods used to deliver software that I was not aware of and I was not being taught at university, so I began my journey of learning and “trying this at home”. In 2017 I acquired Scrum certification and I understood it only shows that you can read Scrum guide and all the hard work needs to be done afterwards through practice, practice and some more practice. I will share some of the common pitfalls I noticed when I start working with a new team, project, clients and try to introduce Scrum.
Agile/Scrum/enter trendy word here does not work
I can bet you have seen this click-bait headline hundreds of times, and that is good — everyone can have their own opinion, based on their own experience. Though what you should expect is people who don’t like change and want to work the same way they always did, will start sharing these articles with you and spreading negative emotions in the team, even though they had no real experience of Scrum / of working with that methodology. “My friend said”, “In my past company”, “I read that” — these are the arguments they will try to use to defend their point of view. In reality, it is a view formed by others and they actually rarely read the whole article they just shared because thoughts like “Agile does not work if you use it wrong” or “Scrum does not work if you do not have an agile thinking” which usually follow the clickbait headlines are not important for them. The best thing you can do here is to try to understand where that negative thinking came from — is that their personal view, have they had a bad experience or if it someone else’s idea planted in their head. Find out the root causes and why previous experience might have gone wrong and explain how it should have worked in the first place, try to teach them what actions will be taken and how they can take part. This leads to my second point.
Only parts of … works for us
One of the biggest mistakes people can do when they try to start practicing methodology on their own is not only still working in non-agile mindset but also cherry-picking established basics, that are there for a reason. People with little practice start using only planning (because they are used to some sort of planning in the waterfall/go with the flow approach) and maybe will do some grooming once in a while. That is where all the horror stories and articles originate from. There is a reason behind saying that Scrum is simple to understand, but difficult to master. My advice here is to really push through and start using each and every Scrum event there is, you can only break rules once you know them by heart.
Evangelists
At another end of the spectrum, there are people who swear only by a pure agile/Scrum that has to be used 100% for a team to deserve to be called a Scrum team. Myself, I tend to be on this side too — but mainly because 99% of time people want to start by messing with the basics in the first place. I believe Scrum is focused on continuous improvement not only on services, products but also on its own ways of working, even though that it is stated that :
“Scrum’s roles, events, artifacts, and rules are immutable”
I have noticed that the guide changes over time too. Review timebox was defined as follows:
“This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter”
It evolved into:
“This is at most a four-hour time-boxed meeting for one-month Sprints.”
It is a subtle change in wording, though it brings a lot of power to the team to decide on its own required length and it is no longer set in stone. Which might seem like an obvious thing, though not to an evangelist that would plan 4-hour meeting and no less.
Also, product backlog used to be defined as:
“The Product Backlog is an ordered list of everything that might be needed in the product”
And it changed to:
The Product Backlog is an ordered list of everything that is known to be needed in the product.
This changes the way we work with the product backlog. It is no longer seen as a never-ending list of things that might be done. This approach eventually bloats into an unmanageable list of requirements, that might never be done. This change implies that this is no longer case, PO should really think through and evaluate if the new request from outside/new idea really worth adding into the backlog. Maybe just have a separate idea document, rather than filling it to backlog right away.
That said, make sure that by improving ways of working you are not cherry picking and reverting to only parts of the framework. What I suggest here is to discuss how to improve existing events/artifacts and collaboration between team members. If you have a coworker or Scrum master who is an evangelist and you feel that this is it becoming a roadblock for future improvements I would suggest to challenge that person and have an open conversation or even a workshop, where the team could discuss why we have this situation, maybe consider what are possible outcomes, risks or even better — agree to try suggested improvement for a trial period — this way everyone is committed for short-term and if something goes wrong, you will be able to recover and if it goes as expected — you can continue the practice. Nonetheless, this is a slippery slope so make sure you try this only when you have practiced something for a long time, confident to make this step and people are really aware of risks this might bring.
Misinterpretation
Guilty as charged. Just like miscommunication, misinterpretation is one of the root causes of all the things that can go wrong. It can happen to anyone — newbie or professional. Scrum guide is barely 16 pages and people interpret it in different ways. It covers basic principles and there is a lot of space for discussion. Some of the examples include cases when people are against modifying sprint items and once they commit to the plan, nothing can change. While the Scrum guide says that:
“During the Sprint: No changes are made that would endanger the Sprint Goal and Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned”
So while people try to be agile, they do lock down sprint backlog items and don’t want to change them, if they eventually do change it and sprint fails they would blame sprint changes for that failure.
One more example is that:
“Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it.”
What the Scrum guide says is that increment may, but not must, be released at the very end of every sprint and this is product owner responsibility to decide. Too many times I have seen the sprint timeline being stretched just to accommodate a few more days for a few more little features that need to go into that end of sprint release while instead what we should do is finish sprint as expected, accept quality increment and agree with PO that with a few additional tasks from sprint, we shall release. Or even better — release increments as soon as possible. Releases are one of the most important parts of the development cycle, yet guide talks vaguely about it. So use your best judgment here. We are aiming to move to continuous delivery and ship increments as soon as possible, we try to determine during sprint plannings what features could go on as “hot-fixes” and what must be checked and demoed for PO and need their approval.
Having all this in mind, what I suggest is reading the guide once a year to remind yourself and others what it is all about. Try to look at it from another angle, I am sure — once you had more practice, you will read and understand things differently.
Scrum for everyone
I personally believe it is not the case. Scrum should be used where it is needed and brings value, not because everyone is doing it right now. Scrum is not just a fancy word that you can take and tell everyone that you are now agile (though this is exactly what the majority is doing). You have to really believe and think in an agile way, you have to be excited to make changes, you must be happy to do mistakes and learn from them. If you are a type of person who does a feature and the second someone says to change it you get frustrated, it is not for you. You must be able to give and receive feedback and be open-minded about it, you must be willing to change and we all know that is a hard thing to do. I also believe that while tools and methods can make good teams great, they can not help the poor teams, so make sure you have a solid team in the first place.
P.S Tools
People always end up using some tools to track their progress and gather requirements. At the beginning Excel or maybe Word is used but as time passes by it becomes overwhelming and unmanageable. At this point, it is usually decided that a more powerful tool is needed to organise the data. We opt in to use a preferably out of the box tool. We don’t want to think about the configuration or setup, so we pick a simple tool such as Trello or Asana. We start with the most straightforward setup, and for some time we are happy with it. We might continue to be satisfied if we are a small team, the project is not complex or if a client is not involved in the process and it is just an internal tool that we touch from time to time. Though if we grow and we have a complex project, large team, and a client who wants to be part of the team — this simple tool can suddenly become a burden. We need to upgrade once more.
I always suggest picking a tool that has more functionality that you currently need, if you are on the right track with your ways of working and you expect to grow you will soon need more functions that will make your work easier, like automatic task transition depending on pull request status. Do not settle with a simple option if you see you can do better and need more.
On the other hand, we have people who opt-in for a highly customisable tool like Jira and end up using only 10% of its functionality for years, even though they have the power to configure it themselves. They end up complaining and searching for alternatives. When you have a powerful tool, you have to keep an eye on new features and decide which ones to use. If you launched a project three years ago and hadn’t changed a thing in the process or the tool you are using, you might need to rethink whether you are really agile.
Last but not least, if people are frustrated with a tool, and it hurts more than it helps — make sure it is really the tool that people are complaining about. Most of the time it is the problem has more to do with people themselves rather than the tool. When the development team is disappointed with the backlog it is usually not the tool’s fault — maybe the PO did not write down proper description, or did not sort it properly. Maybe automatic task transition does not work because developer is creating 10 pull requests for a task and task is moving to the next phase too early, in this case we need to rethink how we split tasks and sub-tasks, and cases like this should be rare in the first place. Tools should help us and not stop us from moving forward
