How do you get meaningful input from an entire IT department without getting everyone in the same meeting or hearing only a few of the loudest voices? A few years ago, I faced that problem with a well-known consumer products company. The leadership team was creating a five-year IT roadmap and wanted input from developers, architects, business analysts, project managers and others across the whole department. A survey would have been easier. But would people participate? And e

AI can generate code faster than your team can review it. Especially with the latest iteration of Claude, the code comes packed with lengthy comments, voluminous release notes, and logic in a bunch of different places, all of which needs to be reviewed before it goes to production. The human in the loop remains essential for quality. But with so much work coming at us, we can quickly become a bottleneck, too. The counterintuitive answer is to limit work in progress and focus

This week, rather than sharing an article about a single idea, I want to share a passion project with you. I started Scrum Day Madison because I believe ideas matter. It is a chance to step away from the day-to-day and hear something worth considering from people who have real experience to share. I am selective about speakers. Over the years that has included Dr. Alistair Cockburn, a signer of the Agile Manifesto, authors I admire such as Stephanie Ockerman, Gunther Verheyen

When teams first learn that every Sprint they must deliver a usable, Done increment—including both development and testing—it can feel impossible. A common temptation is to develop in one Sprint and test in the next. Don’t. The extra cost is far higher than most teams expect. Here are the five biggest problems this creates. Administrative Burden You've just created a whole lot of administrative burden for the Scrum team. Now instead of keeping track of one Product Backlog it

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.

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