Gil Broza

Do your Daily Scrums feel like status meetings?

Do managers and stakeholders treat the Product Backlog as a project plan?

Does the Scrum Master mostly manage tasks and ensure process compliance?

If you’ve answered yes to these questions, let me take a guess at other symptoms of your Scrum. Team retrospectives don’t yield much improvement, members collaborate little, and there is no shared, solid definition of “Done.” If yours is a software development team, their automated test coverage is low, they refactor code superficially (and rarely), and deploying to production involves a lot of planning and caution. While you seem to be following the practices, you’re probably not experiencing much agility. How can that be?

To understand the situation, we need to know why Scrum Teams use particular practices, meetings, roles, and artifacts. Let’s first see what principles are at play when those tactics are used effectively.

Consider the Daily Scrum. It’s most effective from an Agile standpoint when team members collaborate and self-organize in order to get to Done on work that matters. They feel psychologically safe to be transparent and to participate fully and honestly.

Product Backlog is the ordered master list of potentially valuable work. When used as such, this simple artifact focuses the team’s work on meaningful outcomes. They can easily ascertain that they’re being effective and defer many work item–related decisions such as details, splitting, and acceptance tests to the last responsible moment.

The Scrum Master is a servant-leader who helps the team grow into a solid Agile team. They achieve this purpose by creating an environment of safety, trust, and respect and by fostering communication, collaboration, and transparency.

Scrum implements the above-mentioned principles (and a few others) because they support the four Agile values: adaptation, frequent value delivery, customer collaboration, and putting people first. People embrace these values—“optimize for them,” or have them guide everything they do—when they believe that’s how they’ll reach their objectives. Values and principles, along with beliefs, are the three elements of mindset.

When an organization adopts Scrum, it already has some mindset in place. While organizations have different starting points, their mindsets bear some similarity, which we might characterize as “traditional.” Their values tend to include: get deliverables right the first time, commit early, deliver on time and on budget, and follow standards. They act on those values with such principles as: plan the work and work the plan, limit change, and require sign-offs. They determine work centrally, have “resources” (people) hand off work to one another, and maximize their utilization. Pre-Scrum, they implemented these principles with such tactics as project plans, percent complete, frequent status meetings, and code freezes. What happens when such an organization replaces its existing tactics with Scrum tactics without changing its mindset to the one that gave rise to them?

Plan the work, limit change, and maximize utilization make the Daily Scrum a status meeting that ensures that everyone’s loaded; determining work centrally makes it a series of one-on-one exchanges with the Scrum Master. And, since safety and transparency don’t magically appear as a result of teams standing up daily, people will give lengthy accounts of busyness in answer to, “What have I done since yesterday?” and be reluctant to answer, “What’s in my way?” with, “I’m stuck and need help.”

Similarly, an organization’s mindset will color its use of any Scrum practice, role, meeting, and artifact. The further that mindset is from the Agile one that underlies Scrum, the more it waters down the Scrum tactics, leaves team members confused and disenchanted, and reduces actual agility. To achieve real agility, take on the mindset—it matters much more than practices.