Scrum as an agent of culture change part 2

In part one of this series, we defined culture. We also described why it is both critical and hard to work on. Finally, we left you with a teaser that there is a pretty good pattern we’ve seen for how to kind of hack your culture for the better.

Scrum as a Culture Change Agent

I have seen a pattern emerge at several organizations where I’ve worked or coached. A team starts using Scrum. When they use it effectively, they start to think differently about the way they work. They build different social structures. They value different outcomes. They alter decision making structures. And the culture starts to change. We are rewarding different behavior, at least for that team. If they can stick with it long enough to solidify the new set of behaviors, the culture change lasts. When those teams are successful, other teams in the organization start wondering what they’re up to. They learn about scrum, try it out, and if they do it purposefully, the pattern repeats itself. Scrum becomes an organizational change agent.Scrum-Culture-SpreadScrum is based on a cultural mindset that is often different from the existing cultures where it is introduced. In my experience, there are at least four specific characteristics of Scrum that help it to spread within an organization: Quality, Value, Team Focus, and Trust. Below, we take a quick look at each of these aspects of Scrum, describe why each matter to the key stakeholders in any effort, and how it helps to spread a new cultural mindset with its related behavior patterns.

Using Scrum to Improve Quality

The Adobe Audition teams started using Scrum in 2005, and I acted as the ScrumMaster. Our goal was to get to releasable quality each four-week sprint throughout the course of an 18-month release. While Scrum felt much better to the team, some people in our organization asked if we had any hard data. That’s tough to get since many of the things we would have tracked prior to using scrum didn’t make sense to track anymore. One exception was the total number of open bugs at any given point. I created a graph showing the total number of open bugs over time for the previous release compared to the most recent release using scrum:

The graph shows that we had 33% of the open bugs at the peak compared to our previous release. Of course, the real measure of quality was in the response from users, who consistently rated the product highly on ease of use and reliability. We had customers that trusted it enough to use very early “pre-release” builds for real audio production work, where errors and usability would have cost them time and money.

The graph had a big impact on other teams. When they saw that we had kept our bug count so low, they got curious. They became even more interested when, during the “end game”, the last few months prior to the big release, our team was out playing whiffle ball on the lawn while they were in full-on crisis mode trying to get their products ready for release, working nights and weekends.

Stakeholder Benefits of Improved Quality

  • Employees have a stronger sense of satisfaction in their work. Nobody wants to build a shoddy product – scrum tends to give teams permission to do the right thing even in the face of pressure to go faster.
  • Customers are more satisfied with the product and can provide better feedback on the actual features rather than just defects, leading to stronger adoption and higher loyalty.
  • Executives get higher revenue at a lower cost. There is strong anecdotal evidence that quality issues become significantly more expensive to fix the longer we wait. Scrum’s focus on getting to releasable quality every sprint leads to a lower overall cost to build the product. The higher customer satisfaction leads to greater adoption and revenue.
  • Shareholders get higher ROI as the organization improves, leading to higher valuation of the company.

Cultural Impact of Improved Quality

Almost every company says that it values quality. Scrum gives a simple rule that helps to enforce it: get releasable every sprint. When teams follow this rule, “quality is the top priority” often shifts from something that we say but don’t follow through on to the reality of our everyday work. When quality is valued, people also take more pride in their work. There are no longer any cultural barriers to doing the right thing. People start to trust that there is alignment between what we say and what we do. This leads to increased trust between management and employees as well as higher engagement all around.

Higher quality also results in fewer crises. In the example of the Audition team, it helped us reinforce the value of working at a sustainable pace. No extra hours were required.  This experience led directly to three other product teams adopting scrum for their next releases.

Using Scrum to Deliver Value Quickly and Continuously

In a traditional project, we invest money over time, and don’t deliver any real value to the business or users until the whole thing is wrapped up and delivered. On a Scrum project, we can deliver value almost immediately, and then again after each sprint. This approach is great for getting early technical and user feedback, but it also makes great economic sense. Let’s look at the difference between a traditional six month project and one using scrum.

Teams using Scrum begin delivering value to customers after just a few weeks, accumulating value throughout the remainder of the project and beyond. Teams using a traditional approach deliver no value until the overall project is complete. This creates gaps both in time to market and accumulated value over time. Finally, the traditional project is accumulating risk and sunk cost that is much greater than that of the scrum team. Notice the gap between the red (cost) line and the blue (traditional value) line. The growing gap represents an investment with no return, which is correlated directly with business risk.

Stakeholder Benefits of Improved Value Delivery

  • Employees get a much tighter feedback loop with customers, leading to a stronger awareness of what problems are most important to solve, and to seeing their solutions actually make a difference for their customers. Empathy for user’s problems is a key determinant in the success of any product or service. Theresa Amabile found that the highest predictor of engagement is “small wins“. Early value delivery connects the team directly to multiple small wins.
  • Customers get their problems solved much earlier and can provide feedback along the way. They don’t have to wait months or years for the highest priority solutions to be delivered.
  • Executives are measured and compensated based on their ability to increase shareholder value, which means they need to deliver as much value as early as possible at the lowest cost possible. Scrum helps executives meet this goal, making both them and their shareholders happy.
  • Shareholders love the improved time to market and better product/market fit based on early feedback. They also benefit from decreasing risk and opportunity cost by increasing revenue over the course of the development effort, rather than waiting until a big bang release.

Cultural Impact of Improved Value Delivery

Scrum is often described as an empirical framework, meaning that it provides transparency with frequent opportunities to inspect and adapt. Delivering working products and services early creates a cultural shift from predicting to testing hypotheses in the market. This shift to an empirical approach significantly reduces power imbalance between the managers and the teams. It creates a new mindset of “let’s try it out and see what we learn”, rather than a mindset of “I made this prediction, you’d better make it happen”.

Using Scrum to Create Team Focus

Traditional organizations tend to structure around areas of expertise. For a software organization, this might mean that all of the coders have one boss, the testers a different boss, the product managers a different one, etc. These different silos of expertise then need to coordinate their efforts to deliver value. This silo approach also tends to result in a focus on improving a single piece of the value stream over optimizing the flow of value through the value stream. Coders focus on churning out more code faster, testers focus on executing more and better tests, etc. This can lead to queues of work between the stages of development, something that we know from Theory of Constraints and Lean Thinking (see a nice comparison of the two here) will lead to quality problems, slower delivery, more difficulty adapting to change, and higher frustration as an organization.

From a social standpoint, the traditional approach tends to create teams of similar experts, who work together to get better at their area of expertise, but often end up working in isolation on their piece of the puzzle. Scrum focuses on creating cross-functional teams made up of experts in all of the different areas required to deliver value. This shift to cross-functionality then shifts the focus from “improve my area” to “improve our ability to deliver value”. The entire focus of the team switches to a broader perspective, and in my experience, this leads to a more rewarding outcome. After all, if I got into computer programming, I probably did it because I loved solving interesting problems in a way that made someone’s life easier. Scrum re-connects the work I do writing code to how it solves a customer’s problem.

This shift in focus from “me” to “team” also asks people to work on their social connections in a way that the “throw on the headphones and code away on my assigned task” approach doesn’t. Social Connection is critical to a healthy, happy life. Recent studies in neuroscience, psychiatry, and psychology are showing that humans are meant to be social, that it creates resilience to stress, resistance to addiction, and higher life satisfaction in general. Scrum teams learn to balance the need for individuals to get into flow states with the need to keep connected to each other.

A recent study confirmed what many team experts have been teaching for decades: effective teams voice and work through differing opinions about how to get work done, but do so in a way that focuses on the problem to be solved, not the people solving the problem. Scrum tends to emphasize this approach, leading to higher engagement, team satisfaction, and better business results.

Stakeholder Benefits of Improved Team Focus

  • Employees get a stronger connection to each other and to how their work affects customers and users, resulting in higher engagement and job satisfaction.
  • Customers get better results from teams focused on delivering value to them, rather than getting better at their area of expertise.
  • Executives benefit from the higher engagement of their people, higher retention, and higher customer satisfaction.
  • Shareholders benefit in the same way as executives.

Cultural Impact of Improved Team Focus

Shifting the focus from “me” to “we” is a key cultural benefit of Scrum. No longer are we solitary heroes or zeroes, but engaged members of teams focused on delivering value to customers.

Using Scrum to Build Trust

When teams regularly deliver value, sprint after sprint, the traditional “plan and control” efforts become superfluous.

  • We no longer need weekly status reports to make sure things are on track, we simply go to the sprint review and see what the team has built.
  • We no longer try to shift “resources” around to deal with the crisis-du-jour, we simply pass urgent needs on to a stable team, whose process is built to address such work.
  • As teams build the technical infrastructure to do automated testing and continuous integration, we trust that we can change plans whenever we discover a more important need.
  • As teams work together, inspecting and adapting their process to improve value delivery, they build trust amongst each other that they’re all in it for the same shared purpose, and will contribute wholly to the effort.

The net result of all of this is trust, perhaps the most powerful catalyst of cultural change.

Trust allows people to feel safe trying something new. Maybe it will work, maybe it won’t, but with trust, we’re willing to give it a shot. The fear of failure is mitigated. Without the willingness to experiment with new ideas, behaviors, and processes, we are simply allowing water to flow down the same path as always. We need to dig a little canal, maybe dam up another area, throw some rocks in another – something to see if we can find a better way to deliver value.

We want our culture to exhibit what author Nassim Taleb calls “antifragile” characteristics; that is, the culture improves in the presence of stress and change, rather than breaking (fragile), resisting (robust), or flexing for a moment only to return back to normal (resilient). If we aren’t experimenting, we are not improving, and scrum is built to experiment and build the trust required to try new things. It’s one of the few reliable patterns I’ve seen for creating lasting cultural change in an organization.

Want Help?

If you are interested in trying this out in your organization, Agile For All has helped hundreds of organizations implement scrum as a first step to improving the overall work culture, helping leaders balance culture and strategy. Feel free to contact us, or email me directly at to learn more about how we can help!

Related Articles


  1. Like the post but thought it was interesting you state Scrum is the culture change agent and not Agile. You mention Quality, Value, Team Focus and Trust. Do you have to be doing Scrum to find these benefits? Or will Kanban or another Agile process help encourage the same attributes. Scrum helps support Agility, its true, but the Agile traits we’re trying to teach shouldn’t be limited to a single process. That’s when we start hearing people say they are doing “Agilescrum.” Equating one with the other. Once the framework appears to not fit their worktype, they say Agile doesn’t work as opposed to adapting their process and applying agility.

    1. Hi Robert,

      I share your concerns with the conflation of agile and scrum. In the specific examples I’m providing, the framework happened to be scrum, so that’s what I went with.