Incremental delivery - or delivering value frequently - is a core concept of Scrum and yet it is so often misunderstood. Some might argue that it's wasteful to not make a few additional small changes or updates when you're already deep in the code. However, this perception is often rooted in a misconception. In reality, not using incremental delivery can be far more wasteful and inefficient.

Scrum is utilized in various industries, and as a result, leaders from diverse backgrounds are tasked with guiding Scrum Teams. While technical expertise can be an asset, it's not always a prerequisite for effective leadership in an Agile environment.

One question that often arises in the context of Scrum is whether individuals can be part of more than one Scrum Team. While there is no explicit rule against this in Scrum, it's essential to explore the implications of such arrangements on productivity and adherence to Scrum values.

In a world marked by constant change and complexity, effective facilitation has become a critical skill for individuals and organizations alike. Whether you're leading a Sprint Planning event, a brainstorming session, or a strategic planning workshop, the ability to guide conversations, foster inclusivity, and elicit valuable insights is paramount. Facilitation is not just about orchestrating discussions; it's about creating an environment where everyone's voices are heard, ideas are explored, and decisions are made collaboratively. This is where Liberating Structures come into play, offering a toolkit of powerful facilitation techniques that can transform the way groups work together.

The Product Owner is the bridge between corporate strategy and the Scrum Team. The Product Owner must balance the demands of users against the need to ensure that the product remains up to date from a technical perspective. This often means that the Product Owner may need to choose between developing new features to satisfy customer requests and fixes for technical debt.

In this article, we will explore some complimentary practices which the Product Owner might use to as an input when deciding how to order the Product Backlog.

Coaching plays a pivotal role in guiding teams toward greater efficiency, collaboration, and overall success. It’s important to remember that you can't coach people out of every bad practice all at once. This article explores the wisdom behind focusing on the highest impact opportunities rather than attempting to create a perfect team overnight.

At the heart of Scrum lies the Retrospective, a crucial event where teams reflect on their work and identify areas for improvement. One often overlooked opportunity at the Retrospective is measuring employee satisfaction. This article highlights the opportunity of incorporating employee satisfaction measurement into Retrospectives and how it can contribute to team success.

Defining requirements up front is not compatible with Scrum, because Scrum teams don’t deliver value in one “big bang”.  Scrum teams deliver value incrementally.  In this article, we will explore how defining requirements up front limits the Scrum team’s ability to learn, inhibits incremental delivery, and ultimately clashes with Scrum.

The concept of limiting work in progress revolves around the principle that focusing on fewer tasks at a time leads to better outcomes. In a Scrum context, this involves setting a cap on the number of user stories, features, or tasks that the development team is actively working on during a sprint. By doing so, teams prevent themselves from spreading thin and promote a concentrated effort on a select number of items.

How do you uphold Scrum without becoming a Scrum dictator? How do you lead the Scrum Team to ever greater adoption of Scrum within the organization… without direct authority? This article explores the challenges faced by Scrum Masters in their balancing act and how they navigate through it to ensure effective team performance and continuous improvement.

At the heart of Scrum is a unique and indispensable accountability: the Scrum Master. This enigmatic figure may not possess the traditional authority associated with managers, nor do they hold executive powers. Yet, they play a vital and indispensable accountability in the success of the Scrum Team and the organization as a whole.

In this article, we have crafted interview questions to help identify the best Product Owner for your Scrum team.

The purpose of the Scrum Master is to enhance the efficiency and productivity of the Scrum team. It’s an important accountability for the success of the Scrum team, and yet, it is surprising that many people are uncertain about the qualities they should seek when hiring a Scrum Master. In this article, we will present ten interview questions that will aid you in selecting the perfect Scrum Master for your team.

The purpose of the Scrum Master is to improve the effectiveness of the Scrum Team. And yet, so many people don’t know what to look for in a Scrum Master or how to evaluate the Scrum Master’s performance. A great Scrum Master possesses a unique blend of technical expertise, leadership skills, and interpersonal qualities. In this article, we will explore the ten characteristics that define a remarkable Scrum Master.

According to the 2020 Scrum guide, “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” But what does that mean, exactly?

There are certain misconceptions and patterns that can hinder the effectiveness of the Product Owner and lead to conflicts within the Scrum team. In this article, we will explore three common anti-patterns related to the Product Owner's accountability in Scrum and discuss strategies to overcome them.

Escape the Rinse and Repeat Cycle with 5 Sprint Retrospective Ideas

Nexus is a scaling framework that can be used to scale Scrum when there are three or more Scrum teams working together on the same Product. Teams using Nexus create a Sprint goal not only for each Scrum team, but also for all teams working together in the Nexus. This shared Sprint goal is called the Nexus Sprint Goal, and it should not be skipped.

In this article, we explore the concept of catharsis and how its intentional, occasional integration into the Sprint Retrospective can foster emotional release, team bonding and ultimately drive higher team performance. We’ll also look at a practice that supports catharsis called the silent retrospective.

The Product Goal is a powerful magnet that propels Scrum teams towards value delivery. It guides efforts, prioritizes activities, fosters collaboration, and ensures focus on delivering value to customers. Regular evaluation and refinement are essential to maintain its effectiveness in driving value.

In the agile world, Scrum stands out as a Goldilocks framework. Scrum strikes a delicate balance, providing enough structure to guide teams without stifling their creativity and adaptability. Unlike traditional project management methodologies with rigid processes and exhaustive documentation, Scrum empowers teams to find what works best in their unique environments. Let's delve deeper into what makes Scrum the Goldilocks framework: Not too rigid, not too loose, but just right.

In Scrum, the emphasis is on collaboration and flexibility. In this context, a cross-functional team refers to a group of individuals with diverse skills and expertise necessary to complete a software project. These teams self-organize and self-manage and are empowered to make decisions collectively.

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.