"Framework Dissonance"

When a Scrum Team is struggling to deliver high quality product increments they might be in a state of what I call "framework dissonance."

Scrum is a framework for developing complex products using agreed upon values, roles, rules, events, and artifacts to deliver those products in increments. When a team is performing below expectations it could be due to what I call framework dissonance which is much like cognitive dissonance where inconsistent beliefs and hardened attitudes affect the ability to make positive changes. If any of the mechanisms that aid in inspection, transparency, and adaptation are not functioning due to a misunderstanding of the tenets of Scrum then the team and product will fail to improve incrementally.

Getting the framework back into harmony:

Let's start with Scrum Values which are the 'true north' on a successful Scrum Team's compass. Reviewing the values as a team will reset the understanding of 'why' the team is doing Scrum. I recommend this exercise to other Scrum Masters; set a time-box of 15 minutes, have the values (commitment, courage, focus, openness and respect) written on sticky notes. As a team prioritize the list on a whiteboard or flip chart, then record the team's input on ways to practice each value on a daily basis next to each one. If possible incorporate the insights into the team's working agreement.

Next let's talk about Scrum Roles and why it's important to 'stay in your lane' on a Scrum Team. The Development Team is self organizing, cross-functional, and accountable as a team to deliver high quality product increments. The Development Team relies on the Product Owner for product vision, product knowledge, and product backlog prioritization. Both of these roles rely on the Scrum Master to remove impediments, help the Product Owner get the most value from the backlog, be an agent for change, and to coach team members and the organization on the practice of Scrum. If someone is outside the Scrum Team they play the crucial role of Stakeholder and can help by supporting the Scrum Team's efforts and by providing feedback on the product increment. Each of these roles depend on one another so when team members attempt to perform dual roles the product quality suffers.

Scrum Events are like gears in a car, if a gear is removed the engine might run but the car will not move as expected. Imagine a development team wants to experiment with fewer Daily Standup meetings and the product increment quality is subsequently low. In the Retrospective meeting the Scrum Master can help the team realize the value of daily interactions and how it helps teams to know what needs to happen to finish the sprint as planned. The Sprint Review is a team's chance to put finished product in the hands of customers and stakeholders and to get instant and extremely valuable feedback. During the Sprint Review make the most of having stakeholders in attendance by enlisting their help in prioritizing feature requests. Sprint Planning is a chance for the Product Owner and Development Team to get in sync on the acceptance criteria and to define 'done'. Any details missed in Sprint Planning will most likely become impediments later. The Development Team should whiteboard the plan, notes, and pictures and everything should be documented in backlog items. A Backlog Refinement meeting helps the Product Owner to make product backlog items 'ready' for future sprints and can often uncover future risk.

By implementing the pillars of Scrum - inspection, transparency, and adaptation - the framework will regain harmony and the product increment quality will improve.

How has your Scrum Team dealt with "framework dissonance?" What are some ways a Scrum Team can improve adherence to Scrum Rules or enhance Scrum Artifacts?

Epilogue (4/23/2018)

After sharing this article I've had some time to think about my definition of Framework Dissonance and it's overall use as a term. I believe the steps I prescribed will help a team get back on track with Scrum and are valid. What I failed to see is that dissonance is actually feedback in it's true form and instead of a team getting back into harmony a team may decide to change how they operate entirely with or without the Scrum Framework. There are many different paths a team can take and the important point is that they decide together on what path they choose to reach their goals, as a team, and for the betterment of the product increment.