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

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.

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.

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!

Do they prefer Kanban? Let them use Kanban. Do they prefer Scrum? Let them eat cake (I mean, let them use Scrum.) Scrum with Kanban? Well, that's the best of both worlds—let them do it.

Limiting work in progress makes everything better.