As Scrum Trainer I get to meet a lot of teams and hear of many different ways to do Scrum. Most are valid ways, yet some seem more aligned with the values of Scrum or the purpose of the specific Scrum Element.
I have my own biases, having seen co-located teams work very well and having struggled with “dislocated” teams, I often recommend my clients to reconsider “dislocated” teams.
I want to address those of you who don't really want the feedback. I mean, as important as feedback is, and as many times as you've heard that the central point of a Sprint Review is feedback…you're tired of it. It's pesky. And it just gets in the way of you doing what you know is right anyway.
At Amsterdam Airport Schiphol we're using an Agile approach to realize a large digital program. This program includes 5 value streams with multiple teams. Due to the increasing scale of the program, some challenges arise. For example:
This week I facilitated a Scrum Master training in which we gathered the most common pitfalls of the Scrum events. It resulted in a nice overview with lots of recognizable pitfalls. In this blog post I'll share the results with you, completed with some ideas of my own. As you will see, it's only a brief description of the pitfalls.
File this one under: “how do you do Sprint Reviews when you have lots of teams?” Indeed, the traditional presentation format gets long, boring, and ineffective when you have more than a handful of teams presenting at a Sprint Review.
Young Jimmy is in 3rd grade. He's constructed an immaculate paper-mâché volcano. It took every spare minute of the last to weeks to make. His mom carefully loads it in the back of the minivan.