Shorter, focused events create better inspection, better adaptation, and higher engagement. Longer events that wander tend to do the opposite.

In the Professional Scrum Master class, one of the activities we do is to ask participants to remember a time when they were on a truly great team. We then ask the question, what made that team great? I hear lots of answers. People talk about having a clear and meaningful goal. They mention a positive attitude. They highlight strong collaboration and mutual respect. But by far the most common answer I hear has to do with leadership. Again and again, participants describe lea

I've been teaching Scrum for a while now, and the same questions come up again and again. So if you're new to Scrum or just thinking about making the switch, here are five of the most common questions I hear about Scrum and how I answer them. 1. Do we still have managers in Scrum? Yes, managers are essential to the Scrum team. What changes is how they lead. Managers of a high-functioning Scrum team are freed up to step away from day-to-day task management on how the work gets

You hired smart people, so let them do their job. When managers rely on command-and-control leadership instead of empowering the Scrum team to solve problems, they stifle creativity and limit the value the team can deliver. Scrum is designed for complex environments: places where creativity, adaptation, and real-time problem-solving are essential to delivering value. In that setting, leaders need to lead differently. Rather using the force (or velocity) to choke their underli

When we say that Scrum teams are self-managing, we don’t mean that they don’t have a reporting structure or that leadership is not necessary. In fact, the best Scrum teams that I have ever worked with were supported by outstanding leaders.

Digital AI’s annual State of Agile report is a survey that has global participation from small, medium-sized and large companies. It asks questions such as what Agile frameworks are being used, and what are the biggest problems Agile teams face. But one of the most interesting questions - to me - that they ask is this: Why are you using Agile? In almost every single one of those years the number one answer has been SPEED. But why? After all, Agile teams don’t code any fa

"This much positivity in the morning is a lot to take!”

Being a great Scrum Master is all about balance. The Scrum Master coaches the team in self-management, but they also are responsible for helping the team focus on value by improving the adoption of the Scrum framework and removing organizational impediments. They ensure that the Scrum events are positive, productive and kept within the time box, but they don't have to attend every meeting.

A strong Product Owner can successfully work with multiple Scrum teams—especially when those teams are truly cross-functional and aligned around a shared product or value stream.

If your Product Backlog contains hundreds of items - many that are years old - and even the Product Owner isn’t sure what all is in there, it may be time to do some clean-up.

One of the great things about Scrum that is not talked about enough is the fact that — done well — Scrum is an engine for continuous improvement.

When a Product Owner spends most of their time writing detailed user stories, they may be focused too much on the tactical work of their job while neglecting product strategy.

If your AI has read-only access to your email, Teams messages, and calendar, try starting every morning with these questions:

I keep my "to do" list in AI

Great Scrum Masters pick their battles. You can’t fix everything at once. Sometimes you have to pace yourself. But where do you start? Here are some of the first things I look at when I am thinking about how to improve the adoption of Scrum. 1. The Scrum Values This one is the most important - even if it is a "soft" skill. Respect, Focus, Openness, Courage, and Commitment aren’t just words. They are the foundation that makes everything else possible. Because Scrum is a

When you modify Scrum, you’re usually hiding problems.

A fictional - but realistic "day in the life of a Product Owner" is provided below. Last night I couldn’t sleep. I was thinking about how to get a key stakeholder on board with my proposed approach for the product. This morning I met with them. The meeting went well. They smiled, nodded, and said they agreed with the plan. By the afternoon, I found out they were already taking actions behind the scenes to undermine it. Welcome to being a Product Owner. The Real Work After th

The Product Owner exists for one reason: to maximize value. That means creating and maintaining a clear vision, setting strategy, making tough prioritization decisions, and ensuring the team is always working on the most important things. This is real strategic work. It’s hard to do it well when the role is treated as a part-time side job. You have an entire team of developers working full-time to build the product. Doesn’t it make sense to have someone fully focused on decid

Sprint after Sprint, a lot of work remained unfinished at the end of the Sprint. Instead of returning that work to the Product Backlog or discussing next steps at the following Sprint Planning event, the vendor simply left the previous Sprint open. At any given time there might be four or five Sprints open for the same Scrum team. Don’t do this!

If you’re bringing in an external vendor to do Agile software development, you need to set things up so that you’re not stuck with poor performance and big bills. Here are a few practical tips I’ve learned the hard way.