10 things your Scrum team is doing wrong

In our latest blog we talk about 10 things your Scrum team is doing wrong.

#1: Your Scrum Master wears another hat

• Perhaps its the name that means this role is so misunderstood? What is it that scrum masters do anyway? Unlike ‘Project Manager', ‘Back end developer’, or 'business analyst’ the name doesn’t really help with understanding, so often scrum masters wear it as a second hat to Lead developer, Analysis or other delivery role.

• Actually, the Scrum master is the 'Master of Scrum', and has authority over the Agile processes practices the team follows. They also need to observe the team as a whole to view its delivery, productivity and impediments etc. This team-level viewpoint is often at odds with down-in-the-weeds main role which operates at a focused, fine-grained view of the work. Expecting one person to hold both these views simultaneously and have the skills to perform them well is going to compromise both. Better to share a Scrum Master with another team, than make this compromise.

#2: Your Product Owner is not available

• Where are the POs? Why are they so busy as to not attend most of the sprint meetings? POs can 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. 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 issues 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!

#4: You are estimating in your planning meeting

• The planning meeting is for planning, not estimation (Ok, only as a last resort). If the work needs explanation, consideration and estimation all in your planning meeting, that will take a long time - so when does planning get done? especially if you only have 1 hour (see above).

• Estimating work should be done as early in your process as possible, and should be done several times if the item is in the backlog. This is where a backlog refinement meeting can be useful. As the PO bring new work to the backlog, use this time to explain and explore it, and give your estimates free of the time-pressure of the planning meeting.

#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 your goals are worthless

• 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.

Learn more about Scrum

If you found this article useful and interesting check out our range of instructor-led Scrum Courses:

• Scrum kick-start
  
• Professional ScrumMaster
• Professional Scrum Developer (PSD.NET)
• Professional Scrum Developer  (PSD Java)
• Professional Scrum Product Owner