Scrum is not a silver bullet, and it takes effort and practice to get right. Have you had a challenge getting Scrum working well for your organisation? Here we look at the 10 most common issues found when teams impement Scrum - Do any of these ring a bell?
#1: Your Scrum Master wears another hat
Perhaps its the name that is the reason why this role is misunderstood? What is it that Scrum Masters do anyway? Unlike ‘Project Manager', ‘Back-end developer’, or 'business analyst’ the name doesn’t really describe the role, so often ‘scrum masters’ wear it as a second hat to ‘Lead developer’, Analysis or other delivery role. And more often, organizations figure its a non-role and anyone can do it - we dont need waste a headcount….
Actually, the Scrum master is the 'Master of Scrum', and has authority over the Agile processes and practices the team follows. They guide and lead the team to view its delivery, productivity and impediments etc. and to act upon them, thereby improving productivity. This team-level viewpoint is often at odds with down-in-the-deatails view of delivery roles. Expecting one person to hold both these views simultaneously and have the skills to perform them well is unrealistic and will compromise both roles. Better to share a Scrum Master with another team, than make this compromise.
#2: Your Product Owner is not available
Where is the PO? Why are they so busy as to not attend most of the sprint meetings? POs should spend a lot of time with their stakeholders, but not to the detriment of the team….Is it because they are in constant communication with their management on deciding strategy, the big, up-front plans the checking of details…..?
Product owners need to be empowered to meet with their stakeholders and make decisions on their own, only taking direction and support from the leadership when needed. They must also have the time to discuss, negotiate and give feedback to their team constantly. So stop with the weekly department strategy meetings, the 1-2-1s with line-managers: They can start attending your backlog refinement and sprint reviews instead.
#3: Your Planning meeting is too short
At stand-ups, is your team asking about acceptance criteria? are you discovering work as you go along? Do stories get re-estimated during the sprint? Are you having design meetings to go over your backlog items? Do you carry-over work into the next sprint, like, all the time? These syptoms all point to not enough time in planning.
The output of sprint planning (alongside sprint goal and commitment) is a plan for each story in the sprint backlog - i.e. a list of sub-tasks that the team have agreed will more-than-likely implement the story. Sub-tasks should be less than a day’s effort. The thought process of creating these implementation plans, with the whole team’s input, usually negates the need for those time-consuming extra-scrum meetings listed above, and leads to better forecasting.
Spending time dealing with an incomplete plan takes much more time and effort than doing it right first time. In short: If your sprint is two weeks, you need at least two hours. Don’t skimp!
#5: You are not breaking your work down enough
The focus of planning is a moving picture: Your product backlog should predominantly be Epics and Users stories described at a high-level, ready for change and negotiable. Its only when we get to the planning meeting that details are decided and sub-tasks written to implement the stories - and only for those in your sprint backlog.
User Stories or tasks should be less than a week’s worth of effort, Subtasks less than a day. There are 3 good reasons for this: The though process of planning work at this level of granularity help to have a well-thought out plan that can understand the delivery, uncover dependencies or coordination and avoid problems. Second, during the sprint the team can see daily progress - or not - of their plans to prompt corrective actions. And third, understanding this level of detailed work allows the team to understand itself better, its preferences, impediments, skills, and other ways of working that remain hidden if not broken down enough.
There are many ways to break down work - see the excellent Richard Laurence’s blog at The Humanizing Work Guide to Splitting User Stories for several techniques.
#6: You don't protect the sprint plan
Does your team add work to the sprint backlog during the sprint? is anything removed to make space? does anyone raise a hand? does anyone care? If work can be added with no consequence to the sprint, doesn't that put the goal in jeopardy? and if so, why is there no push-back? Will work just be carried over to the next sprint?
Protecting the sprint means being focused on the work and what the team are delivering. If work must be added, then something must be removed to protect that delivery and by extension, the trust of your stakeholders. Being sloppy on sprint goals, delivery and focus erodes this trust and is very difficult to regain.
#7: You don't have stakeholders at your review
You are having reviews, aren't you? so who is attending? Is anyone representing customers beyond your PO? if not, then who can review your work? in what way will you check your results and get steer through feedback?
As a first step, identify your stakeholders. Find the nice ones, the ones whose feedback will be sympathetic and useful, then find the nasty ones. Who needs to be actively engaged to keep them on-side? A great technique here would be Stakeholder Mapping. With this done - hold them close, and keep communicating!
#8: Your Retro is boring!
Does your retro bring up the same issues time after time? have people stopped attending? have you dropped it completely? I find that much of the time, the issues discussed are the kind that can never be solved, or have a long-term solution only, like “moving to the cloud”, “wait for the next major release” or “hire a new architect”. These solutions are outside the team’s sphere of influence, and are not going to change anytime soon - so find another way to deal with it.
Instead, make sure you discuss improvements that your team can make - inside the sphere of influence. How can they make their situation better? What teamwork, communications or toolset changes can they make to have an impact - then, have that impact!
And while your about it, make sure the team is Reporting issues those long-term issues alongside their impediments to the middle management and leadership - they might be able to do something about it, so keep them visible.
#9: You don't follow up retro actions
Your Retros just sort of end. You’ve found issues, you’ve talked about them. You’ve said “This needs X”, or “We should all do Y !” but nothing is followed up (or only trivial ones)
The foundation of Agile is inspect and adapt - find improvements to try next time. That is what the retro is explicitly for - it is THE way to be Agile. Without implementing improvements, how will improvements be made? how will the team progress to high-performance?
So please, after every Retro, plan to have actions and volunteers to implement them. Set these expectations at the beginning of the meeting.
#10: You don't have sprint goals, or they are meaningless
Our sprint goal is to do the work we planned, right? Get stuff done, whatever the stuff is. Goals of this kind are mostly worthless - why bother with a self-fulfilling goal?
If this is your team, then be aware, because it is a sign of of having little strategic awareness. You may have good tactics to get stuff done, but to what end? for what purpose is the team working?
When teams use goals to strategically plan product deliveries, align to OKRs, and the product and organizational goals, your team will be aiming to meet them. Usually it is the lack of empowerment of the PO, or lack of clear product strategy that is stopping this from happening, so for all you Agile Leaders out there, its time to let the team’s decide.
Scrum is easy to understand but to implement is tricky and needs discipline and support. If you would like help with these problems, get in touch with us here at Manmaru wheere we can offer you support and coaching on these issues - tell us here: