Common Challenges in Scrum

Scrum is not a process – rather, it’s a framework which provides a lot of visibility to the team, and a mechanism that allows them to “inspect and adapt” accordingly. Scrum works by making visible the dysfunction and impediments that are impacting the team’s effectiveness, so that they can be addressed. For example, most teams are not good at estimating how much they can get done in a certain period, and so will fail to deliver what they committed to in the first Sprint. To the team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about their commitments, and also being even more committed to delivering what they signed up for. This pattern – of Scrum helping make visible dysfunction, enabling the team to do something about it – is the basic mechanism that produces the most significant benefits which teams using Scrum experience.
One very common mistake teams make, when presented with a Scrum practice that challenges them, is to change the practice, not change themselves. For example, teams that have trouble delivering on their Sprint commitment might decide to make the Sprint duration extendable, so they never run out of time – and in the process, ensure they never have to learn how to do a better job of estimating and managing their time. In this way, without training and the support of an experienced Scrum coach, teams can morph Scrum into just a mirror image of their own weaknesses and dysfunction, and undermine the real benefit that Scrum offers: Making visible the good and the bad, and giving the team the choice of elevating itself to a higher level.
Another common mistake is to assume that a practice is discouraged or prohibited just because
Scrum doesn’t specifically require it. For example, Scrum doesn’t specifically require the
Product Owner to set a long-term strategy for his or her product; nor does it require engineers to seek advice from more experienced engineers about complex technical problems. Scrum leaves it to the individuals involved to make the right decision; and in most cases, both of these practices (along with many others) would be well-advised.
Something else to be wary of is managers imposing Scrum on their teams; Scrum is about giving a team space and tools to self-organize, and having this dictated from above is not a recipe for success. A better approach might begin with a team learning about Scrum from a peer or manager, getting comprehensively educated in professional training, and then making a decision as a team to follow the practices faithfully for a defined period (say, 90 days); at the end of that period, the team will evaluate its experience, and decide whether to continue.
The good news is that while the first Sprint is often very challenging to the team, the benefits of Scrum tend to be visible by the end of it, leading many new Scrum teams to exclaim:
“Scrum is hard, but it sure is a whole lot better than what we were doing before!”

Daily Scrum

Once the Sprint has started, the Team engages in another of the key Scrum practices: The
Daily Scrum. This is a short (15 minutes or less) stand-up meeting that happens every workday at an appointed time, and everyone on the Scrum Team attends; in order to keep it brief, everyone stands (hence “stand-up meeting”). It’s the team’s opportunity to report to itself on progress and obstacles. One by one, each member of the team reports three (and only three) things to the other members of the team: What they were able to get done since the last meeting; what they’re hoping to get done by the next meeting; and any blocks or impediments that are in their way. The ScrumMaster makes note of the blocks, and then helps team members to resolve them after the meeting. There’s no discussion during the Daily Scrum, just the reporting of the three key pieces of information; if discussion is required, it takes place right after the meeting. The Product Owner, Managers, and other stakeholders can attend the meeting, but they should refrain from asking questions or opening discussion until after the meeting concludes – everyone should be clear that the team is reporting to each other, not to the Product Owner, Managers or ScrumMaster. Some teams find it useful to have the Product
Owners join and give a brief daily report of their own activities to the team, though this is at the team’s discretion.
After the meeting, the team members update the amount of time remaining to complete each of the tasks that they’ve signed up for on the Sprint Backlog (figure 5). Following this update, the ScrumMaster adds up the hours remaining for the team as a whole, and plots it on the
Sprint Burndown Chart (figure 6). This graph shows, each day, how much work (measured in hours or days) remains until the team’s commitment is completed. Ideally, this should be a downward sloping graph that is on a trajectory to hit zero on the last day of the Sprint. And while sometimes it looks like that, often it doesn’t. The important thing is that it show the team their actual progress towards their goal – and not in terms of how much time has been spent so far (an irrelevant fact, as far as Scrum is concerned), but in terms of how much work remains – what separates the team from their goal. If the curve is not tracking towards completion at the end of the Sprint, then the team needs to either pick up the pace, or simplify and pare down what it’s doing. While this chart this can be maintained electronically using Excel, many teams find it’s much more effective to do it on paper taped to a wall in their workspace, with updates in pen; this low-tech solution is fast, simple, and often more visible than an electronic one.