By offering just enough structure, Scrum enables teams to work together effectively while promoting innovation and adaptability.

Let’s explore four ways Scrum Teams can manage production support in Scrum effectively.

A good Scrum Master is like a Swiss army knife, able to adapt to any situation and provide the team with the tools it needs to succeed. 

The phrase 'accountable but blameless' is my new favorite phrase because it captures so much about positive team culture in Scrum.

Scrum is the most popular Agile framework. According to Digita.ai’s 16th annual report, 87% of organizations using an Agile framework use Scrum. That’s up from 58% of Agile teams using Scrum, as documented in the 14th annual State of Agile report. 

​​​​​​​Agile coaches have long recognized that busyness does not necessarily equal success. Checking off a to-do list does not mean you are adding value.  You might accomplish many organizational tasks, but the activity likely has little benefit if these tasks don’t contribute to the company’s goals, support operations, or customer satisfaction.

The individuals involved in these and other Scrum Events must face complex challenges and ask and respond to difficult questions. We can make the process easier with a positive mindset.

When Scrum Teams experience a work quality issue, they sometimes shift the responsibility for quality control to the Product Owner as a solution. Not only is this impractical, but it's also anti-Scrum. Here's why.

A dogmatic approach to Scrum tends to close down discussion and inhibit collaboration. If it’s in the Scrum framework described in the Scrum Guide, it’s there for a reason. But if it is not outlined in the framework, Scrum teams can innovate how to apply Scrum in their unique environment.

How do the Product Owner and the Scrum Team navigate unexpected customer requests? What happens when a high priority customer issue is discovered mid-Sprint? Should the Scrum Team ignore the emergency or interrupt the Sprint? Like so many things in Scrum, the answer is that it depends.

Sentiment surveys at the Sprint Retrospective can be an early warning indicator that something is wrong.

In Scrum, the Product Owner’s purpose is to maximize the value of the Scrum Team’s work (the product). Delivering value to the customer (beneficial customer outcomes) is the ultimate measure of success for the Scrum Team, including the Product Owner.

A very interesting (and sad) piece of news made headlines in Spain recently that provides some lessons about agile product development and incremental delivery. 

Self-managing doesn’t mean that the Scrum Team — or the Scrum Master — is all-powerful.  (Sorry, not sorry!)  It means that the organization gives the Scrum Team the mandate to deliver value according to the product vision and goal within a set of guardrails.  

The PO must consider the impact of each stakeholder request on the overall goal and vision for the product, as well as the available resources and time constraints. Sometimes the best response to stakeholder requests is "no".

Several years ago, I was the Scrum Master for a team working on a technology product.  Two of the team’s Developers told me they would like to try pair programming.  

What happens when a Scrum Team becomes overwhelmed with requests that stakeholders make directly to the Developers instead of the Product Owner?  

Sprint Planning is one of those events that even experienced teams don’t use to its fullest potential.  Here’s why. Many teams see the Sprint Planning event as the time for selecting which Product Backlog items (PBIs) they will deliver in the upcoming Sprint.  And that’s it.  There is so much more that teams can do to maximize the value they get from Sprint Planning.

During refinement, the team discusses what we will deliver with each Product Backlog item. Although it's easy to drift into sorting out how we will deliver each PBI during these discussions, planning at this stage is a mistake. 

Every Scrum event has a maximum allowable time period to carry it out, called a timebox.  While Scrum events have a maximum amount of time, they do not have a minimum amount of time. Let’s look at all of the event timeboxes and how they make Scrum Teams more effective.

Let’s look at how as a Scrum Master, you can facilitate a self-organization session, because the most empowered Scrum Teams determine the structure and organization of the team.

No matter how much a Scrum Team plans, there are times when someone asks them to undertake unplanned work mid-Sprint. In this article, we will discuss how to handle unplanned work in Scrum.

I gotta say, refining work items is usually, by far, the Scrum Team’s least popular activity.  No one gets up in the morning saying, “I can’t wait to refine the Product Backlog!” In this article, we will discuss five reasons why refining your Product Backlog is worth the time.

According to the Scrum guide, Scrum teams typically have 10 or fewer people, including Developers, Scrum Master and Product Owner.  But what happens with a Scrum team that includes more than 10 people?  What if the Scrum team has 10, 15 even more people?

Understanding the “why” behind the Scrum framework can help Scrum teams improve their ability to deliver value to the organization.  We previously discussed the purpose behind each Scrum event and the purpose behind each Scrum accountability.  In this article, we’ll take a deep dive into the purpose of each Scrum artifact. 

​​​​​​​Scrum Teams that understand the “why” behind the Scrum framework can better increase value delivery to the organization. Internalizing the purpose behind the events, artifacts and accountabilities of Scrum allows the team to get the most benefit from them.  In this article, we will discuss the purpose of each of the three accountabilities in Scrum.

​​​​​​​According to the 2020 Scrum Guide, “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”  Scrum Teams must take the Retrospective seriously to achieve these outcomes.  In this article, we will look at four tips for getting the most from your Sprint Retrospective and provide several agenda ideas that you can use to keep this event fresh.

In this article, we will discuss how limiting Work in Progress can help teams deliver a done increment which meets the Sprint goal.

The Scrum framework is not a set of work instructions; instead, the framework is a guide within which teams learn how to work together to deliver value to the organization and discover which complementary practices work best for them.  However, some see Scrum as a rulebook and take the guidelines too far.  Others consider one or more of the complementary practices as “required”.  In this article we will discuss a few of the common missteps that give Scrum a bad name.

Scrum’s strength is that it makes difficulties visible faster so the team can address them. While the framework helps to resolve many things that might not be working optimally, it doesn’t eliminate every issue. Let’s look at three problems Scrum doesn’t solve. 

The best Scrum teams that I have worked with were supported by management leaders focused on removing impediments, providing resources, and promoting an agile mindset and culture that supports the Scrum values. It’s not an easy job. Making it more challenging are the agile leadership myths out there that can get in the way of being effective. In this article, we’ll look at three common agile leadership myths and how to move past them.

I think of the three accountabilities in the Scrum framework as creating a balance of power.  But what happens when an individual fulfilling one (or more!) of the accountabilities in Scrum gets a bit — um — power hungry?  In this article, we will discuss a few examples of how people fulfilling each of the three accountabilities can overstep their bounds. 

Epics and features are complementary Scrum practices that some Product Owners use to organize their Product Backlog. Like a folder structure, they are a convenient way to group PBIs into meaningful groups.

Many people using Scrum today have no formal training or are new to agile frameworks. It’s the perfect environment for myths and misconceptions to spread.

As a minimalist framework, Scrum contains only what is needed. Every piece of the Scrum framework is there for a reason. When teams modify any part, they won’t get the full benefits of Scrum. In this article, we will discuss three of the worst Scrum “customizations.” Warning: don’t try these in your organization!

As a project manager, I have delivered many complex initiatives, from re-platforming a consumer products website to doubling the size of a line of business.  My most successful projects have one thing in common; I used an agile approach to deliver them.

According to the Scrum Guide, Scrum teams are typically 10 or fewer, with a preference to the smaller size.  When Scrum Teams become too large, they should consider re-organizing into multiple Scrum teams supporting a single product.  When this happens, the Scrum Teams should share a single Product goal, Product Backlog, Product Owner and a common Definition of Done.  

Scrum and Kanban are two different frameworks.  But did you know that your Scrum Team can use some of Kanban’s crucial elements to optimize workflow and deliver value sooner?   Combining Kanban with your Scrum practice doesn’t involve replacing events, accountabilities or artifacts.  It’s about integrating Kanban’s complementary tools to achieve better outcomes with Scrum.

I confess that the first time someone told me that Scrum is based upon empiricism, I thought they were a little pretentious.  After all, it’s a five-syllable word for a framework with only five events.  Why make it so complicated?  But as I’ve coached more and more Scrum Teams over the years, I have learned that empiricism matters. It’s not just a fancy word; it’s the foundation of Scrum.

During the first year of the pandemic, Scrum adoption more than doubled for software development teams. According to the 15th Annual State of Agile Report, the use of agile approaches for software development grew from 37% in 2020 to 86% in 2021. This means that agile adoption for software development doubled in a single year — the first year of the pandemic. I don’t think that is a coincidence.

In our recent article “Why You Shouldn’t Modify Scrum,” we discussed five reasons why modifying Scrum is counterproductive.  We’ll expand on the topic in this article by exploring five more ways organizations sometimes change Scrum and the impacts they might experience as a result.  

​​​​​​​According to the 2020 Scrum Guide, a Scrum Team should contain members with all the skills necessary to create an Increment of usable product each Sprint. Teams that approach their work from a product perspective find this cross-functionality easier to achieve than teams that organize around the technologies required to deliver the product. Although having some technology teams in your organization might be necessary, product teams should be the default because of their many advantages. This article will discuss the five benefits product teams have over technology teams.

The Scrum Framework is very lightweight, and it seems to get less restrictive with each release of the Scrum Guide.  What is included is really important, though.  Every piece of the framework is there for a reason.  In this article, I will discuss five common ways that teams modify the Scrum framework and the negative impacts of each.  

When people ask me the best way for their team to transition to Scrum, I have to tell them that there isn’t an easy answer because every organization is unique.  Keeping that in mind, here are some general steps to consider if implementing Scrum is on your horizon.

There are five events in Scrum.  But just going through the motions and having each of the events on the calendar is not enough.  To get the most out of Scrum, your team needs to understand the purpose behind each of the five events.  

One of the first things that I usually hear after describing the Scrum framework and its five events to someone new to Scrum is, “that’s a lot of meetings!” I get it — at first glance, it seems like a lot. But it really isn't when I get the person to take a closer look. This article provides a description of each event and how you can reduce the need for other meetings by practicing them.

​​​​​​​In my experience, it’s the Sprint Retrospective that teams are most likely to skip, berate, or otherwise bash.  When I hear teams talking about dropping it to “save time,” I want to pull a Darth Vader, shake my fist in the air, and say, “You don’t know the power of the Sprint Retrospective!” and then demand that the team meet anyway.  Alas, I am not Darth Vader.  But hear me out to consider these five reasons for never skipping a Retrospective.  

Once the team has selected a point system, they need to decide which types of items to classify as a 1, 2, and so on. In this article, we will provide an exercise that can help your team create a point system organically no matter what’s in the Product Backlog.

The Scrum Guide doesn't provide a complete list of the skills required for any of the accountabilities on a Scrum Team. For example, it doesn't specify that Developers must use Java or C# code. The Scrum Guide simply states that Developers need all of the skills to deliver a Done increment of product each Sprint. We intuitively know that the skills required depend on the product. 

In Scrum, part of the Product Owner accountability is to provide a forecast that sheds light on possible answers to the when will we get there question. In my last post, we discussed three ways to size Product Backlog items (PBIs). Today, we’ll discuss ways the Product Owner can use this information to create a meaningful forecast.