How an output focus makes teams fail at Scrum

0
(0)

Outputs without outcomes & team engagement is a mistake.

I have been working in the Agile space for most of my career. And I am worried about the momentum of current trends. The recent patterns I am observing reverse our progress to Agility.

The unfortunate trend I see is in organizations using Scrum. They are deciding to try to get good at outputs before focusing on outcomes or team engagement.

For example, recently, I started coaching a team with ninety-six Sprints under its belt. It delivered working, high-quality product every Sprint. But the team didn’t perform Sprint Reviews or Retrospectives and did not know its customer.

The team had formed habits around a fixed mindset and did not embrace change. True, the team had reliable, predictable delivery. But without the two key inspection events, the team was not learning how to improve its product or its craft.

The team’s goal was reducing variance to plan, and this led to building features users didn’t need. Delivering the next item off the backlog had become the focus. The team had lost sight of “why” it was being built and “who” needed it.

“The emphasis should be on why we do a job.”
—W. Edwards Deming

Purpose was missing, value was secondary to delivery, and change was not embraced. This team was stuck in output mode and output habits had hardened. Shifting to outcomes was painful for this team.

At first blush, an output focus seems like a reasonable approach to take a baby step into using Scrum. But in effect, it drives us deeper into our status quo. Output-driven Scrum makes the goal of a self-managing, value-focused team harder to meet.

Let’s unpack the perils of an output focus a bit and come up with a better alternative.


The danger of an output focus

When we focus on outputs, we end up getting better at building more in a predictable, high-quality manner. At its worst, an output focus leads to tunnel vision and an unhealthy drive for better, faster, and cheaper. An output fixation promotes behaviors to prohibit change rather than embrace change.

Improving outputs has been our muse for decades in product and software development. The traditional, phased approach to product delivery drives to predictive, high-quality output. Predictive plans and a low tolerance for plan variance have driven our behavior for so long it is now instinctual.

When we focus on outputs as our first foray into Scrum, are we changing? Or are we diving deeper into our comfort space? My experience has shown it is more the latter than the former.

We are familiar with the output path. This path is comfortable, and we are quick to bring forth our well-worn behavior:

  • We split out strategy, discovery, or design teams separate from the Scrum Team to generate ideas.
  • A team other than the Scrum Team engages with the customer.
  • Backlogs filled with requirements not validated against customer needs.
  • The Scrum Team delivers a fixed scope with high quality by a fixed date. This becomes the team’s priority; value is not part of the conversation.
  • Maximizing output is the goal of the Scrum Team, rather than minimizing it to meet customer needs.
  • Plan, scope, and method variance becomes an unsavory cost teams avoid in every action they take.
  • Organizations emphasize their output metric tracking to an unhealthy degree. Measurement exists to manage and control output, rather than to learn.
  • The team finds itself in a feature factory, building the next item off the backlog. The purpose of the team is unclear, and they play little part in deciding what to build.
  • Teams settle into functional silos to maximize output efficiency and functional craft.
  • Batch sizes, feedback loops, and lead times elongate and hide problems.
  • Organizations tolerate dependencies to support worker output efficiency.

And the Scrum Team drones on in this cycle, disconnected from its customer and purpose. The team’s sole focus is building its product “right.”

In this output mode, the Scrum Team loses the chance to contribute to building the “right” thing. And the opportunity to form the “right” team engagement dynamic from the start passes by.

Once entrenched in output-based Scrum, teams face difficulty switching to self-pursuit of value. Now, they have to unlearn output-based Scrum as well as traditional behaviors. Such teams often find it would have been better not to start practicing Scrum in the first place.


The saner alternative—build an outcome-oriented, engaged team from the start

Last month, an updated Scrum Guide was released to the public, and it renewed my hope. Before this, I was feeling defeated by the overwhelming drive to output dominance. What parted my dark clouds was The Guide’s emphasis on an autonomous team capable to own the entire value chain.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

….

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

—The 2020 Scrum Guide

The 2020 Scrum Guide establishes the team as accountable for delivering value. The Guide requires all capabilities to do this be within the team.

An output orientation deemphasizes value and bypasses behaviors to influence high team engagement. Value accountability is the goal of a self-managing Scrum Team. Since this is the goal, starting teams without embracing this goal is short-sighted.

The genius of the “AND”

Jim Collins wrote about the “Genius of the AND” and the “Tyranny of the OR” in his book, Built to Last1. Jim’s extensive research shows that to achieve greatness, leaders must reject the “Tyranny of the OR” and embrace the “Genius of the AND.” This means executing more than one option at the same time without dilution of any option.

As an example, assume you are faced with a decision to deliver by a fixed date or deliver what the customer needs. The “Tyranny of the OR” focuses on either delivering on time OR focuses on delivering what the customer needs. But the “Genius of the AND” would seek an innovative, simpler option to deliver what the customer needs on time. 

We experience the “Tyranny of the OR” when we choose to apply Scrum only to outputs. As such, we postpone improving our outcomes and enhancing our team engagement. And the benefits of Scrum fall short.

The “Genius of the AND” when pursuing Scrum is to find the balance between output, outcomes, AND team engagement from the start. I have written about these three focus areas as the three “Right” ways to develop your product. Yes, you will stumble and hit obstacles, but this helps you find problems early and fix them early.


So, how do we go about this balancing act?

I realize focusing on output, outcomes, and team engagement at the same time is a big change for most of us. Choosing the “AND” here is a big ask.

So, when I coach this balanced, multi-faceted approach, I often get responses to slow down, such as:

  • “We need to crawl before we walk, and then, we can run.”
  • “Look at how far we have come in improving our output transparency and predictability. Why disturb a good thing?”
  • “We can’t disrupt our teams with change because they will miss their delivery commitments.”
  • “We need you to meet us where we are.”
  • “We are in change overload and can’t handle any new changes.”

The answer to addressing a big change is first to go small. If you are willing to run a small experiment, you will see success. This will build your confidence to go further.

When you start small, every small step you take should be in the direction where you want to be. Each step should aim to strike a balance between output, outcomes, and team engagement. Focusing on output steps alone does not do this.

Accept you will not get it right in the beginning, and practice your new habits with grit. Provide an environment of safety for your teams to experiment. And remember not every experiment will work; leave room for these learning moments.

And you don’t have to change every team at once. Starting small could mean only one team changes its behavior. Success by one team proves the approach can work in your context and builds momentum.

As a coach, I am always glad to meet organizations where they are. But if they are in output jail, I want to break them out and take them on an adventure.

Would you like to be in a better place beyond a singular focus on outputs? When will you start your journey to balance output, outcomes, and team engagement?


Related Posts

You can read posts related to this one below:

References

  1. Built to Last, Jim C. Collins and Jerry I. Porras 1994, 1997, Genius of the AND concept.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

As you found this post useful...

Follow us on social media!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Leave a Reply

Your email address will not be published. Required fields are marked *