Ten reasons why your Scrum might be “failing"

Failure. Understandably, that’s a word loaded with negativity. And in the business world, it’s also usually accompanied with feelings of fear and impending career-influencing consequences by those experiencing the failure. In large organisations or in complex, waterfall projects, cultures can often develop to be overly risk averse and to treat failure as something to avoid at all costs (or to apportion the blame for any failure to someone else).

But unless you’re working on truly mission critical projects where lives are at risk, there is an alternative viewpoint on the concept of “failure”. And it’s something that’s built into the core of the Scrum Framework: empiricism.

Empiricism in Scrum “asserts that knowledge comes from experience and making decisions on what is observed”. So essentially that is the process of making changes, assessing the outcome and then adapting future change based on what we’ve learned. And by wrapping a short, recurring timebox around that ‘experience, learn and adapt cycle’, you are reducing the risk of major failure happening because teams can learn and pivot rapidly.

Therefore, in Scrum, what might be considered "failure" can actually be a valuable learning experience, an opportunity to grow, and a pathway to success. 

Get in touch with us for a free consultation if you would like to explore any of the topics discussed below, or to find out how our enterprise Agile coaches could help your business to deliver faster, better and cheaper.

‍

Observed from our decades of working with teams that have transformed their ways of working to adopt Agile, here are ten reasons why your Scrum might be "failing" and how you can turn each one into a learning opportunity.

‍

1. The Sprint Backlog is Not Fully Completed:

• Why It Happens: Teams often focus on completing every backlog item instead of achieving the Sprint Goal, leading to perceived failure when tasks remain incomplete when the Sprint end date arrives.
• How to Learn from It: At Daily Scrum and at the Sprint Review, emphasise the Sprint Goal and recognise that it's not a problem if the backlog isn't fully completed so long as the goal is met. The goal is to deliver value; the individual task items are secondary. 

‍

2. External Stakeholders Add Extra Work on Top of the Sprint:

• Why It Happens: Lack of clear boundaries and communication with stakeholders can result in unexpected additions to the Sprint. It’s also likely that many senior stakeholders are not familiar with Scrum - they may be clinging on to legacy ways of working whereby they shout “JUMP!” and the team must immediately respond with “How high?”.
• How to Learn from It: Have the Scrum Master educate stakeholders about the Scrum Framework and its benefits to those senior stakeholders. Ensure clear channels of communication exist between the stakeholders and the Product Owner. Make the Product Owner the gatekeeper of the Product Backlog to ensure that changes are appropriately considered.

3. The Team Doesn't Make Time for the Scrum Events (Meetings):

• Why It Happens: Lack of commitment or understanding of the importance of Scrum events can lead to skipped or rushed meetings.
• How to Learn from It: Reinforce the value of Scrum events and ensure full participation. Facilitate understanding and agreement within the team about the purpose and value of these essential events. And finally, setup recurring invites for all the Scrum events so that people can manage their diaries well in advance to reduce the likelihood of future meeting clashes.
  

‍

4. The Team Forgot to Account for Other Work Outside the Sprint When Planning:

• Why It Happens: Insufficient planning and foresight can result in overlooking external commitments, leading to overcommitment within the Sprint itself. For example, a Developer that has their own team to line manage must presumably make time for one-to-ones with their team members. Plus, there could be company meetings that need to be attended, or public holidays coming up.
• How to Learn from It: Consider all commitments during Sprint Planning. Engage the team in a holistic planning process to ensure that all work is visible and understood. During the Sprint Planning session, the team should always ask themselves questions such as: “What other responsibilities or meetings do we each have outside of the Scrum that we need to allocate time to?” and “Is anyone on leave or do we have any public holidays during the next Sprint?”

5. The Team Was Unsure if the Sprint Goal Was Achieved:

• Why It Happens: Ambiguous or unclear Sprint Goals can result in confusion and lack of alignment within the team. An increment gets delivered but nobody really knows if it is valuable.
• How to Learn from It: Clearly define and communicate the Sprint Goal, making sure it's understood by all. As a team, consider setting a Sprint Goal structure (e.g. make it SMART) and check that it is tied into the overall Product Goal (which in itself should be tied to overarching business objectives). The Sprint Goal should be the focus of the Daily Scrum event.  Remind yourselves of the Sprint Goal regularly throughout the Sprint to maintain alignment and focus.

6. The Team Does Not Stick to Meeting Timeboxes:

• Why It Happens: Lack of discipline or understanding of the importance of timeboxes can result in prolonged or inefficient meetings. For example, people treat the Daily Scrum as an update meeting and deep-dives into specific topics occur.
• How to Learn from It: Enforce timeboxes strictly and educate the team on their significance. Utilise visual aids or timers, and cultivate a shared responsibility for respecting the timebox. Also, remind teams that the Scrum Events are not the only time that the team should meet to discuss topics - they are free to arrange meetings as needed outside of the Scrum Events, and that they should involve only those team members that are required.

7. A Key Stakeholder Was Underwhelmed at Sprint Review:

• Why It Happens: Misaligned expectations or lack of stakeholder involvement can result in dissatisfaction during the Sprint Review.
• How to Learn from It: Engage stakeholders regularly and set clear expectations. The Product Owner should provide stakeholders with opportunities to provide continuous feedback to ensure alignment with the Product and Sprint Goals. And make sure that these underwhelmed stakeholders have the opportunity to explain clearly what their expectations are so that their needs can be assessed for future sprints.

8. Stakeholders Wouldn't Engage with the Scrum Framework:

• Why It Happens: Resistance to change or lack of understanding can create barriers to stakeholder engagement.
• How to Learn from It: Educate and involve stakeholders in the process. Provide transparency and regular updates to build trust and understanding. Demonstrate the value of the Scrum Framework and how it can help them to achieve their goals (after all, who wouldn’t like to lower project risk, reduce waste and gain better visibility over progress?)

9. The Sprint Overran Its Timebox:

• Why It Happens: Unrealistic planning, external interference, or lack of discipline can lead to Sprints extending beyond their timebox. Also, a team may focus too much on the Sprint Backlog and the need to get everything ‘done’.
• How to Learn from It: Plan more realistically, considering potential disruptions and uncertainties. But be strict and end the sprint when the end date arrives. Commit to the timebox and use retrospectives to uncover and address the root causes of any issues that the team identifies (e.g. over-commitment or failure to achieve a Sprint Goal). And use the Sprint Goal as the focus point - not the Sprint Backlog.

10. Perceived "Failure" Resulted in People Blaming Each Other:

• Why It Happens: A culture of blame instead of collaboration and learning can lead to finger-pointing and divisiveness. This is usually a result of the organisational culture in which that team is operating - perhaps it’s very hierarchical/top-down or one where leaders are quick to highlight what they perceive to be failure.
• How to Learn from It: Foster a culture of trust, empathy, and continuous improvement. Encourage a focus on solutions and learning rather than assigning blame, and when issues do arise, the team should take collective responsibility. Although Scrum is non-hierarchical, it’s often good if the most senior person on the team (as defined by their job title or grade within the company) leads by example here. Being transparent about mistakes or struggles can encourage others to follow suit. Utilise retrospectives as a safe space for open and honest reflection. If your project is particularly high risk or where there is potential for the blame game to arise, consider using short sprints to increase the opportunities to inspect and adapt. If you make a bad call at the start of a 1 week sprint, there’s only so much work that can be done before that mistake is identified and can be corrected in the next sprint.

‍

In conclusion, "failure" in Scrum is not necessarily a bad thing. Instead, it is a chance to learn and grow. Remember, Scrum is about empiricism: experiencing, inspecting and adapting. 

‍

Viewed in this light, there's no failing, only learning.

‍

If you’re involved in a project that is struggling and is experiencing high levels of perceived failure, get in touch with us today to book a free 30 minute consultation to see how we can help you.