Openness in Scrum: Improving Collaboration

Do you always order your favorite dish at a restaurant? If so, you might be lacking in one of the five core Scrum values.

What is Openness?

Openness is one of the five core scrum values. The other four are focus, respect, courage, and commitment.

My first stop when I set out to understand more about some aspect of Scrum is always the Scrum Guide.

In this case, I find the Scrum Guide’s explanation of the values a bit weak.

“The Scrum Team and its stakeholders are open about the work and the challenges.”

-The Scrum Guide

Thanks for nothing, Scrum Guide.

My research uncovered two definitions for openness that apply in the context of the Scrum values.

Openness is the acceptance of or receptiveness to change or new ideas.

This first definition gave me a bit of a paradigm shift. I recognized that maybe I’m not as open as I’d like to believe.

After all, I often describe myself as a creature of habit. I thrive on routine.

When my heartmate takes me out for Mexican, I order the same meal every time: Pollo Bandito.

Do I have similar convictions that I apply without a thought in my professional career? Might I be limiting my team’s ability to experiment without knowing it?

The second definition of openness aligned more with my previous assumptions.

Openness is a lack of secrecy or concealment; frankness.

The story weaver is an excellent example of an anti-pattern to this definition of openness.

The story weaver is a persona that takes a situation and spins it to tell a story that paints them or their team more favorable.

Speaking of anti-patterns, I find it helpful to review a word’s antonyms when I’m trying to really grok its meaning.

Here are some antonyms for openness:

• dissimulation
• indirection
• reticence
• pretense
• duplicity
• deceit
• dishonesty
• deception
• deviousness
• misrepresentation
• sneakiness
• treachery
• cheating
• corruption
• falsification
• posturing
• frigidity
• restraint
• unfriendliness
• unapproachability

Is Openness the same as Transparency?

Transparency is the quality or state of being transparent.

Merriam-Websters second definition of transparent has a couple of different variations:

• a. free from pretense or deceit: frank
• b. easily detected or seen through: obvious
• c. readily understood
• d. characterized by visibility or accessibility of information especially concerning business practices

A team utilizing a Sprint Burndown chart could be an example of transparency. The team keeps the chart up to date, and everyone in the company can access the chart.

Now consider the following two leadership scenarios:

Scenario 1:

Voldemort the Manager: “I just looked at the burndown. We’re not going to hit the deadline. The developers need to work weekends.”

Developer: “We rushed to hit the last deadline, and we’re burnt out. Ron made some mistakes, and we had a bunch of bugs to squash this Sprint.”

Voldemort: “See that Ron gets written up. We need more accountability.”

Scrum Master: “There’s too much work in progress. Context shifting caused the reduction in quality. We should limit WIP and see if that helps the issue.”

Voldemort: “That’s the dumbest thing I’ve ever heard. How could we possibly meet the deadline if we work on less work?”

Scrum Master: “Actually, research shows… ”

Voldemort: “I don’t care about your theories. See to it that the developers write fewer bugs and hit the deadline.”

Scrum Master: “How would you suggest they manage that?”

Voldemort: “I don’t know. That’s what I pay them for.”

Let’s see how that could have played out differently.

Scenario 2:

Dumbledore: “The burndown has pushed beyond our target go-live date. Can you help me understand what happened?”

Developer: “We rushed the last release. We’re burned out, and it caused Ron to make some mistakes. We spent the last sprint squashing bugs.”

Dumbledore: “What can I do to help?”

Scrum Master: “We have too much work in progress. The context shifting has caused a reduction in quality. We should limit WIP to see if it helps.”

Dumbledore: “That seems counterintuitive to me. Can you help me understand how that works?”

Scrum Master: “Studies show that limiting WIP reduces waste caused by context shifting and improves quality.”

Dumbledore: “I’m open to trying it. What’s the worst that can happen? Hopefully, it will work, or we’ll at least learn something in the process.”

One of these examples embraces the concept of openness. Can you guess which one? In both scenarios, transparency instigated the interaction.

The difference between transparency and openness is that transparency is a state of knowing, and openness is a way of interacting.

Why is Openness Important in Scrum?

People low in openness tend to be set in their ways.

They’re not interested in the input of others, especially if it differs from their long-held assumption.

Two primary attributes of Scrum are a shared team commitment and an empirical way of working. The stubbornness of the close-minded is conducive to neither collaboration nor experimentation.

A team member’s lack of openness directly contradicts Scrum in two principal ways.

First, their dogmatic belief in their assumptions and unwillingness to consider the input of others will squash collaboration.

Second, their unwillingness to try new things will limit their ability to experiment to find better ways of working.

What are the benefits of Openness?

Openness in Scrum enables six essential activities:

1. Teamwork
2. Decision Making
3. Empiricism
4. Continuous Learning
5. Radical Candor
6. Impediment Removal

Teamwork

A primary focus of openness involves sharing the details of your work, particularly your struggles.

It’s easy to just power through as long as you’re still making progress. If you’re not blocked, it feels like you don’t need help.

On an episode of Big Brother, I once watched contestants compete on an obstacle course. One of the obstacles was a caramel-filled pool. To get through the obstacle, they had to duck under a bar that required them to crawl through the caramel.

You might think that doesn’t sound so hard, but you’d be wrong.

When I see developers struggle through a feature, I always think back to this episode. Making progress in your work shouldn’t be as difficult as swimming through caramel. Sure, you’re still moving, but dang, it would be so much easier to just get some help.

Being specific about how your work is progressing can allow others to offer help. Pairing with another developer can transfer knowledge that empowers everyone to move faster in the future.

Decision Making

Those convinced their ideas are best are disinterested in the input of others. If everyone feels this way, it will be impossible to reach a decision. If everyone acquiesces to avoid conflict, no one is committed to the resulting decision.

Openness eases the way for shared decision-making. When you feel heard, it makes it easier to commit to a decision, even if it’s different than the one you proposed.

At times, stakeholders will need to make decisions based on the progress of the Scrum Team. They must have accurate information on which they can base their decision.

For instance, they may need to hire a temporary person to perform a manual process if the automation isn’t ready by a specific time. Or perhaps a feature will be ahead of schedule, and we’ll need to inform marketing so they can prepare creatives.

Being open with stakeholders concerning the Scrum Team’s progress arms them with information. With accurate information, we better equip stakeholders to make the appropriate decision.

Empiricism

Empiricism is working in a fact-based, experience-based, and evidence-based manner.

Everything is an experiment.

We tweak our processes to see if it resolves an issue we’ve identified.

If that doesn’t work, we’ll try something different next sprint. In this way, Scrum allows your process to become tailored to your team.

But this way of working requires that your team members have an open mind. Someone set in their ways will be resistant to working in this manner.

Another key to empiricism is solving the correct problems. Often, teams mistake the root cause of an issue. If your culture lacks psychological safety, team members may be unwilling to admit mistakes. This secrecy can result in the concealment of a significant problem or the misidentification of the root cause.

Psychological safety and openness go hand in hand. In an open culture, the focus is on learning and not on blame.

Continuious Learning

Where you’re open to the ideas of others and respect their skills, you create an opportunity to learn.

A whole team open to learning will increase cross-functionality.

By assuming your ideas are best, you close yourself to the experiences and viewpoints of others, hence cheating yourself out of a valuable learning opportunity.

When you realize that you can learn something from everyone, everyone will become someone.

-Unknown

It seems there is an age at which technology passes you by. Whether it’s setting the time on the VCR, learning which remote works the TV, or learning how to use apps on the phone, it’s as if each individual draws a line in the sand and decides: I’m not progressing beyond this point. The phrase “I don’t know anything about that” becomes a safeguard against learning.

As I’ve learned more about openness (or the lack of it), I’m convinced it plays a big part in the battle of age versus technology. I never want to be so set in my ways that it hinders my ability to learn. I may not live to be eighty, but if I do, I want to retain my ability to set my clocks, have food delivered to my door, and play Candy Crush.

Radical Candor

The values of openness, respect, and courage support Radical Candor. Radical candor is a way of communicating that cuts through politics.

We need the courage to say what others won’t. We need openness to say it in a way that isn’t vague or misdirecting. We need respect to say those things in a way that doesn’t make us look like assholes.

If you’re not familiar with Kim Scott’s book, she explains the concepts in the video below:

Impediment Removal

One of the primary responsibilities of a Scrum Master is to remove impediments for the team.

Removing these blockers is a much easier task when the team points out their impediments.

If a team lacks openness, they tend to avoid discussing the elephant in the room.

The unintentional concealment of information can also contribute to long-lived impediments. It might sound absurd, but people get too involved in their work and forget to communicate with their team members.

The best example I can share of this is a clip from Hell’s Kitchen. This exact situation plays out every season.

A team that embodies openness endeavors to overcome these mental checkouts. By making communication a priority, everyone has the information they need to reach the Sprint Goal.

How can each Scrum Role Exemplify Openness?

Each Scrum role has different opportunities to exemplify openness.

Let’s discuss each role, and then we’ll look at some role agnostic examples.

Developers

According to the Scrum Guide, a developer is anyone on the team that helps build the Increment.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

-Scrum Guide

As a developer, you should strive to be open about your work’s complexities, progress, and struggles. A shared understanding helps team members identify opportunities to contribute.

Letting the team know “I’m still working on ticket 1234” in the Daily Scrum doesn’t provide a lot of value. As an alternative, “I finished the algorithm, and now I’m starting on the UI” provides more context. In the second example, it gives someone a chance to say, “I’ve got mad React skills. I can help with that.”

If you’re struggling with something, you might say, “I’m making progress, but it’s slow. I’m not as familiar with this part of the codebase, and the logic is complex.” Which gives a subject matter expert a chance to pipe up and say, “I know that code well. I’ve got your back.”

Although sharing context is essential, you should learn to do so in an efficient manner. When you see the eyes of your team members start to glaze over, you’ve said too much. Seek to learn to strike a balance between too little and too much information.

Sharing your skills and limitations is another way to apply openness. If your SQL skills are rubbish, but you rock at React, make sure your team is aware.

They’ll know that if they need a SQL guru, they should hit up someone else. They’ll also know who to turn to when they’re stuck on a React issue. Sharing this information may also lead to mentoring opportunities.

Knowing the strengths and weaknesses of team members help reduce waste. It becomes more apparent who I should ask for help given my specific issue. This knowledge can also help the team target work that is more suited to their skills or identify opportunities to learn new skills. Being a bit more strategic about who picks up what work can lead to increased efficiency.

Scrum Master

There are two main areas where scrum masters can practice openness.

The first one is in giving honest feedback to team members, even when it’s complicated. Mentoring and coaching are aspects of the Scrum Master role. We should help the team to be the best that they can be. In doing so, we’ll need to be willing to have difficult conversations. Avoiding these conversations does no one any favors and goes against the value of openness.

The second area where a Scrum Master can practice openness is in sharing information. Your involvement in various conversations will provide context for what is happening across the organization. It can be hard to remember not everyone on the team has that same context. Strive to make it part of your daily routine to identify the information you possess that your team lacks. Share that information with the team as you become aware of it.

Product Owner

Sharing the logic for the prioritization can boost openness. Communicating why one product backlog item has more value than another can provide valuable context to the team.

The team may also be able to offer insights that the Product Owner hadn’t considered.

Overall, this sharing will lead to better decision-making and higher commitment.

Scrum Team

Regardless of our role on the Scrum team, there are some general ways you can exemplify openness.

The first is by being receptive to change via experimentation. Scrum is intended to be a series of experiments. This Sprint, X happened; we’ll try Y to see if that alleviates the issue next Sprint. Y caused the unexpected Z to happen; we will put A in place to prevent Z. Over time, the process tailors to precisely what the team needs the process to be, but only when we’re open to change.

The second opportunity to exemplify openness is by building relationships that facilitate learning. Whether we want to believe it or not, we are all on a continuous learning journey.

Smart people learn from everything and everyone, average people from their experiences, stupid people already have all the answers.

-Socrates

Everyone on your team is human. They come equipped with their own background and experiences. Approach your teammates as humans and not just cogs in a machine. Building these relationships opens the door to learning something new from them.

Openness and the Scrum Artifacts

Some of the Scrum artifacts, by their very design, encourage openness. The Sprint Backlog, Product Backlog, and the Definition of Done that governs the increment are a few examples.

Sprint Backlog

The Sprint Backlog is where our Sprint Goal lives. The Sprint Goal is intented to be negotiable. We want to set a target but leave some wiggle room for how we go about achieving that target. This wiggle room left in the Sprint Goal is an example of openness. We’re open to alternative implementations as long as we achieve the desired outcome.

Scrum is also open to rebooting the entire Sprint Backlog in rare cases where it’s necessary. We refer to this as canceling a Sprint. We reserve this option for extreme situations, but it is still an option. In a manner of speaking, we could say that the Sprint Backlog itself is open to change.

Product Backlog

We keep the Product Backlog ordered by value, with the highest value items appearing at the top. Sharing the product backlog with stakeholders demonstrates openness. We’re communicating what we are (and more importantly, what we’re not) likely to select for upcoming Sprints.

With this knowledge, stakeholders can make better plans. They may need to hire a part-time person to process work that is unlikely to be automated soon. If we deliver a feature early, they can notify Marketing to get the creatives ready.

Increment (Definition of Done)

The Scrum Guide defines the Increment delivered at the end of the Sprint to be one of the three Scrum artifacts. We know what we’re ready to deliver this Increment when it meets the Definition of Done. The definition of done helps us remove obfuscation around the true status of work.

I can’t tell you how many times in my career a team member has misinformed leadership that a feature was ‘done.’ The work was “dev complete,” but it hadn’t yet passed testing. There is no guarantee that the change will pass testing on the first attempt. This fact indicates an unknown period during which the feature will cycle between development and QA.

But leadership is under the impression that the feature is available in production. That’s how they translate “done.” When they find out that is not the case, they’re upset, and rightly so.

The Definition of Done establishes a standard meaning of “done.” When I say done, that will mean the same thing when Harry says done. This standardized view of the status of work eliminates obfuscation and embodies openness.

Openness in the Scrum Events

The Scrum events themselves grant us an opportunity to amplify openness.

Openness in the Sprint

People who lack openness tend to be uncomfortable with change. The only way to get comfortable with change is to do it.

Luckily Scrum has a built-in mechanism that forces change - the Sprint. The Sprint is a timebox during which we try to achieve the Sprint Goal. At the begging of every Sprint, we develop a new plan based on the most current information we have at the time. At the end of the Sprint, we evaluate what we learned in the Sprint Retrospective and identify action items to change our processes. This cycle allows us to get comfortable with change and amplifies our openness.

Openness in Sprint Planning

The third topic covered in Sprint Planning is how the work will get done. Typically this is accomplished by decomposing the Product Backlog Items into tasks.

We need openness to reach a shared understanding of the work that needs to take place. Being receptive to the opinion of others increases the likelihood that we’ll account for all the work.

As part of Sprint Planning, we will need to estimate our Product Backlog items. This estimation lets us gain confidence in our capacity to complete the work. To estimate our work with any accuracy, the Scrum Team requires both openness and respect. If we don’t respect our team members, we won’t be open to their point of view. We must be open to the point of view of others so they can point out instances where we may have under or over-estimated.

Openness in the Daily Scrum

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

-Scrum Guide

There are four primary opportunities to leverage openness in the Daily Scrum.

1. Make impediments apparent
2. Be explicit regarding skill deficiencies
3. Value accomplishments over status updates
4. Be receptive to trying different formats to achieve the purpose

Make impediments apparent

Sometimes we tend to be vague about impediments. We mention them as an aside, or we downgrade their significance. Strive to call them out as impediments and ensure the Scrum Master acknowledges the declaration.

Be explicit regarding skill deficiencies

Don’t allow hubris to delay the development of a feature. We all can’t be rockstars at everything. If you’re struggling with implementation, call it out so someone on the team can plan to help.

Value accomplishments over status updates

Saying “That’s in progress” provides next to no value for anyone. Share with the team what work you’ve been able to complete and what is still outstanding. Do this in a concise manner that provides the most information without droning on. This information allows other team members to adjust their plans if needed.

Be receptive to trying different formats to achieve the purpose

The three-question agenda seems to be the most popular for standups. This format can have some unintended consequences, which lead to its removal from the Scrum Guide in the 2020 updates. Be open to using another format that might provide more significant benefits to the team. Amplifying openness is our first line of defense against common dysfunctions of the Daily Scrum.

Openness in the Sprint Review

We should be forthright concerning the progress we’ve made (or lack of it) in the Sprint Review. This statement is especially true concerning organizational impediments.

Do not use impediments as an opportunity to deflect blame onto other teams. If the product fails, we’ve all lost.

The purpose of discussing impediments is to get them resolved. The odds are good that the stakeholders may have more influence to remove blockers than members of the Scrum Team. When we bring issues out in the open, it increases our chances that someone will make progress.

The Sprint Review is an opportunity to receive feedback on the most recent product increment. If we’re dismissive of feedback, stakeholders will stop providing it. Therefore, to ensure we’re building the best product, we need to be open to feedback.

Traditional project management tends to lock down the scope. Project managers dictate that changes go through an arduous change management process. You can think of the Sprint Review as a lightweight change management process. Instead of limiting ‘scope creep,’ we want to maximize feedback. The Product Owner will incorporate that feedback into the Product Backlog. We continue to implement functionality as long as it makes sense to do so.

This means that the direction of the product is ever-changing. Thus we must be flexible and open to change. If we are brittle and stuck in our ways, we will be quick to break.

Openness in the Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

-Scrum Guide

The Scrum Team requires openness to fulfill the purpose of the Sprint Retrospective. We increase quality and effectiveness by experimenting with process changes. To be successful at this, we need to be welcoming of change and open to trying things differently.

Establishing a willingness for experimentation is the first step. Next, we’ll need to identify a potential process improvement. This determination will be most successful with input from all team members. This level of collaboration requires openness to the ideas and suggestions of others.

We also need to ensure that we’re solving the right problem. That requires all team members to demonstrate openness when discussing process issues.

When it comes right down to it, openness is a requirement of a constructive retrospective.

Backlog Refinement

Even though Backlog Refinement isn’t a formal ceremony of Scrum, we’ll cover it due to its broad adoption.

When we refine the backlog, this can be a chance for us to exercise openness. We have an opportunity to stamp out this fantasy that we’ll ever focus on the 500th product backlog item.

I once worked with a team that maintained three separate backlogs. The first was the product backlog, exactly as you’d expect. The second was nick-named “The bottom of the backlog.” We called the third backlog “The bottom of the bottom.” These last two backlogs contained items that we all knew we’d never reach. We perceived these bottom dwellers to have a low return on value versus effort.

Once a quarter, we’d have a meeting to review these backlogs. Fear of missing out in combination with a lack of openness resulted in the culling of zero items from the list.

The maintenance of these product backlog items was a waste. The quarterly meetings to discuss them were even more ludicrous. In hindsight, it’s easy to see that someone should have spoken up and said what I’m sure we all were thinking.

Why are we here? We’re never going to get to this work, so why discuss it? Let’s archive these tickets and go on about some more meaningful work.

When the Product Owner refines the backlog with ruthlessness, they exemplify openness. By collaborating with the team, they practice receptiveness to the ideas of others. The Product Owner also demonstrates honesty concerning which features will make it into the product.

Discard everything that does not spark joy.

-Marie Kondo

Works Consulted

• Courage Exists in Many Forms
• Deep Dive on Scrum Values With Sam Falco
• How to Apply Scrum Values in the Day by Day?
• Living My Values
• Maximize Scrum With the Scrum Values: Openness
• Openness Is About More Than Transparency
• Openness: The Big Five Personality Types Explained
• ‘Radical Candor’ Is About Respect, Courage and Openness
• Scrum Guide
• The Three Pillars of Empiricism
• Scrum Values Through the Eyes of an Agile Team
• Understanding Scrum Values: Openness
• Updates to the Scrum Guide: The 5 Scrum Values Take Center Stage

TLDR

Openness in Scrum is about more than sharing information with your team. It’s more than not being shady with your words. Openness in Scrum is also about being receptive to new experiences and learning from others.

In the interest of openness, I will admit that I have no intentions of forgoing the Pollo Bandito at my next date night. I am, however, making a conscious effort to be more open to the suggestions of my team members and embracing experimentation wholeheartedly.