Self-organization is not something that needs to be earned. And besides that - to be honest - deciding what teams' people will work on is not rocket science either. By trusting the team to own how they work together to deliver the product, the organization is empowering them to figure out the best way to deliver the product.

What do to about the Sprint schedule during the holidays?

If your Sprint Review is starting to feel a little pointless, ask yourself: Do we have a clear direction? And are we collaborating together to adjust course and find the best path to get there?

In last week's Professional Agile Leadership class, I asked leaders to share what interview questions that they would use to find a great Scrum Master. With their permission, I’m sharing the questions that the group came up with.

When you’re kayaking in fast whitewater, the boat tends to go wherever you look. That's because when you look at something, your whole body tends to lean that way without you even realizing it.

The most successful Scrum Teams adopt the product model by organizing their Scrum Teams around products. Because dependencies are the bane of value delivery!

Scrum Teams don’t exist in a vacuum. The Scrum team's success—or failure—is heavily influenced by the broader organization around them.

For more than 40 years, business experts have emphasized the importance of efficiency, specialization, and keeping people busy. The idea was that if we optimize our processes we can deliver value sooner. And for certain kinds of work, that approach works well. But not for creative work.

Slack time is not wasted time. It is the breathing room that allows teams to step back, adapt, and grow. Not to mention the ability to deal with any emergencies that happen to come up.

When you’re kayaking in fast whitewater, the boat tends to go wherever you look. That's because when you look at something, your whole body tends to lean that way without you even realizing it.

In this fast-paced world, we need Scrum more than ever. From the transparency created by artifacts to incremental delivery that keeps us on track, Scrum gives organizations a way to adapt and thrive. AI is a powerful tool, but instead of replacing Scrum, it makes the framework even more essential. Here are five reasons why Scrum is more relevant than ever.

Is your Scrum team just going through the motions of Scrum without using it to focus on continuous improvement? Then coach the "fluffy" Scrum values to help turn them into a team focused on value.

Sometimes Scrum gets a bad rap. When I ask why an organization struggled with Scrum, I almost always hear something like “there was too much overhead.” But when I dig deeper, I usually find that the organization had imposed extra rules—rules that have nothing to do with Scrum. In other words, when Scrum “doesn’t work,” it’s almost always because the team wasn’t actually using Scrum well.

One of the key aspects of Scrum is that each Sprint should result in a Done, usable increment of product. But what happens if your team struggles to achieve this? Here are ten practical ideas that your team may consider adopting to help improve your ability to get to Done.

Digital.ai releases an annual 'State of Agile' report which I am eagerly anticipating. While I wait for the 18th report to be released, I want to take a moment to look at how we have talked about Agile has changed over time.

The belief that working in parallel through silos is efficient is a myth. It doesn’t speed things up; it throws up walls between teams and creates a tangle of dependencies, misaligned priorities, and extra overhead.

One practice from Kanban that I think is often overlooked is related to the flow of work. Work on the Scrum board should flow from left to right - but it shouldn't flow backwards.

When I first started working with Scrum Teams, one of the things that struck me most was the Product Owner accountability. The Product Owner is accountable for maximizing the value of the product. It is simple but profound - they are ultimately accountable for the value that the product delivers.

If you’ve ever been a Developer on a Scrum Team, you’ve probably experienced this moment: you’ve completed all of the work you originally planned for the Sprint, and there are still a few days left. What now? It might seem like a good idea to just pull more work into the Sprint, but that sometimes causes more harm than good.

If you are thinking about "saving money" by eliminating the Scrum Master, think again! They are the glue that holds the Scrum Team together. What are good communication, effective events and a focus on value worth, after all? A pretty penny, I'd say.

There is an annual "State of Agile" report which has been produced by Digital.ai for the past 17 years. One of the most interesting questions that is asked in this survey is "Why did your company adopt Agile"?. What I find fascinating is that for 14 of the last 17 years, the answer has almost always been something along the lines of "Accelerate Time to Market" or "Accelerate Software Delivery". Last year, for the first time, the answer changed pretty significantly.

In the world of Scrum, we love to say that the Product Owner is accountable for maximizing the value of the product. But what we don’t say enough is how they actually do that. Spoiler: it’s not just by writing user stories and keeping the Product Backlog tidy, although those things don't hurt. A great Product Owner creates alignment—between strategy and execution, executives and developers, vision and reality.

The Scrum Master’s purpose is to improve the adoption of Scrum. Sometimes that means facilitating Scrum events — when asked or when needed. So yes, that often puts me - as the Scrum Master - in the position of leading the Daily Scrum.

Handoffs happen when teams are told to “be Agile” but are organized according to an old way of thinking. Instead of assembling cross-functional teams focused on delivering end-to-end value, many organizations organize Agile teams into technology silos—backend, frontend, database, dev ops - each focused narrowly on their own technology area. While it may seem "efficient", what this really means is that teams have built-in walls to value delivery.

In a recent conversation with an executive leader, she shared a very interesting insight: “Leadership is a lot like being a glorified Scrum Master.” It may sound surprising to you at first, but the more I think about it, the more it makes sense to me.

As a Scrum trainer, I get the chance to speak with people from many different industries—finance, healthcare, tech, education, government. Because of my unique position, I get a chance to notice trends in the industry. Here is what I am hearing a lot about lately.

As a trainer, I have the unique opportunity of hearing from a lot of people practicing Scrum in many different organizations. One of the recent trends that I am thrilled to hear about is that many organizations are - at last! - starting to take note of the importance of defining their products.

There’s a reason we often say, “Trust but verify.” It's because trust is important — but to build and maintain trust we need transparency. In Scrum, the Sprint Review gives us a way to practice that idea consistently.

When a new Scrum Team first starts working together, they go through some common growing pains. Knowing what to expect for a new Scrum Team can help make things go a little smoother.

Organizations define Product Manager and Product Owner roles differently. Company size, industry, and structure all play a role. Scrum makes the Product Owner accountable for maximizing value, but many companies add a Product Manager alongside—or instead of—a Product Owner. This creates variations in how the roles function.

The purpose of the Scrum Master is to improve the adoption of Scrum. So, it makes sense that the Scrum Master should ask the question What does a high-performing Scrum Team look like

Scrum actually has very few rules. It’s a simple framework with just enough—but not too much—structure to help teams work together. It’s flexible. It’s lightweight. And it gives teams the space to learn, adapt, and improve continuously.

According to the Scrum Guide, a Sprint can be cancelled—but only by the Product Owner, and only if the Sprint Goal becomes obsolete. But what does that even mean?

In Scrum, “Done” means done. Not halfway done, not “almost there,” and certainly not “we’ll get to it next Sprint.” Yet, many teams find themselves with a growing burden of unfinished work. Over time, that burden starts to feel like a monkey on the team’s back—heavy, distracting, and hard to shake off.

One of the biggest mistakes I’ve seen in Agile adoption is the separation of design and development into different teams, each with their own Product Owner and their own Product Backlog.

It isn't just individuals who can suffer from burnout. Sometimes, it's the whole Scrum Team. PST Mary Iqbal explores this serious problem in her latest blog post.

New Scrum Teams aren't perfect, but when you use Scrum to get better, you get better at Scrum. So often, when you first start using Scrum, it can feel like you're just going through the motions. And while that can be frustrating, it's also a part of learning.

Let’s set the record straight: Scrum Master is not a dead-end job. In fact, it might be the best stepping stone to real leadership you could ask for.

It may be tempting to push the team to deliver more by overloading the Sprint with extra work. But don’t do it! One of Scrum’s core values is focus, and that value exists for a reason. A team that focuses on delivering a reasonable amount of work will accomplish more than one that tries to take on everything at once.

Points are not for measuring individual performance. Points are for forecasting future delivery. We don't need to fake the data to make developers look better, because that's not what points are for.

Some teams are obsessed with documenting everything. They create tickets for tracking time, logging meetings, or even planning how to plan. They think they’re being transparent. In reality, they’re just adding layers of clerical work that don’t actually help deliver value.

Scrum Masters can sometimes fall into the trap of managing the process rather than coaching the team. While it might seem helpful to update tickets, close backlog items, or move tasks around, this kind of administrative work actually disempowers the team and takes the Scrum Master away from their real job: helping people grow, removing obstacles, and improving the adoption of Scrum.

Using velocity to measure the success of a Scrum team is like measuring a machine by a single cog in the wheel. The cog may be important, but it’s not the same as the value the machine produces.

At the end of our first Sprint, during the Retrospective, someone pointed out that the Daily Scrum alone would add over 250 meetings a year. It felt excessive. We were already frustrated with too many meetings, so why would we willingly add more? But as we kept going, something changed. We started seeing the benefits—not just in theory, but in practice.

Myth # 39: Technical Debt is the Developer's Problem. They caused it, so they should fix it on their own time.

At Argus, the maintenance team in Edmonton faced a challenge: ensuring consistent, high-quality repairs while dealing with an unpredictable workload.

How can you focus on continuous improvement if you think everything is already perfect? Scrum Masters who become too emotionally attached to their teams can lose the ability to assess improvement opportunities objectively.

In some of my classes, people tell me they are using Scrum—but they can't call it Scrum. Why? Because someone in their organization had a bad experience with it.

Many Scrum Masters see their role as protecting the Scrum Team. But when protection becomes isolation, something is wrong. Shielding a team too much from stakeholders isn't helpful - it hinders collaboration, stifles feedback and erodes trust.

Scrum - when done well - actually promotes even greater accountability than waterfall, because the Scrum team is accountable for value delivery. And great Scrum teams measure - and reflect upon - customer outcomes so that they can adjust course and improve their ability to deliver value.