Based on what I've been writing and training about for the past 10 years, you can probably imagine where we ended up. But where ended isn't the point of this story. The point is that when we started this experiment on various approaches to estimating, I had an idea of what would work. I told myself, You know what? I could be wrong. So we start experimenting. And it turns out I was wrong, But you know what I learned from being wrong? Enough to write Agile Estimating and Planning. You know, what else? Parts of this book could be wrong. In fact, pages 238 through 240 are, as are other pages. I wrote them because they're what believed then, but they are not at all what believe today. And that's the key to success. not just in this story, but with Scrum, with Agile, and with life for that matter, being willing to learn. Everyone in that company knew we were not good at estimating and we wanted to get good estimations. During the process we had some very fierce arguments but we didn't let those arguments get in the way of learning from what we're doing. In putting this talk together, I was at first reluctant to call these team members open-minded, because I remembered some of those fierce debates. But I looked up open minded in a dictionary, and it just means willing to consider new ideas. And yes, fortunately, just about everyone on the teams in this story was willing consider ideas, even those who were very opinionated were at least willing And you know what? That's all we needed. The courage to say, hey, I could be wrong. I think it's vital that we approach Scrum with an open mind. Fine. Go into a situation thinking you're right. Think like I did, that experienced senior programmer days is going to be the answer. but reserve that little bit of open-mindedness that says, hey, I could be wrong. What was the last thing about Agile that you changed your mind about? It could something relatively small, like deciding one week sprints are better than two week Sprints. Or it could it be something that required a leap of faith, Like including your product owner in your retrospectives. Whatever it is, Can you think of something that you once firmly believed about how to run an Agile project that that no longer believe? This type of openness is important to the progress of Agil. Think about Scrum would look if early Agiles had never thought, but hey, I could be wrong. I asked a few prominent Agilles for things they changed their minds about. I want to share a few with you. Ron Jeffries and Chet Hendrickson are well known for having abandoned estimating. That's like a dagger to my heart. They used to advocate estimative product backlog items in story points, but they thought, hey, we could be wrong. And now coach teams not to estimate at all. Ken Rubin, who gave the 2014 Scrum Gathering keynote in New Orleans, was once adamant that the scrum master not also be part of the team. He now says a scrumb master can be a development team member. Mitch Lacey, author of The Scum Field Guidebook, like many of us, took the daily scrumm as gospel. You have to do it daily. He's since told himself he might be wrong about that and says that some high-performing teams can get by without a daily scrum because they're essentially doing it every minute of every day. Robert Martin, Uncle Bob of the Clean Coder Videos, who pushes all programmers to take their craft seriously, has told me he was a complete skeptic about test-driven development when he first heard about it. He was so skeptical he flew to Oregon to pair program with Kent Beck and try test driven development. he says that experience rocked his world and he changed his mind. Jeff Sutherland has always stayed open-minded, and he adjusts his recommendations based on what he sees working and not working. When Jeff invented Scrum, he established the goal for teams of being able to release at the end of a sprint or perhaps every few sprints. By 2005, though, He'd started to write about the importance of decoupling releases from sprint boundaries. In his first book on Scrum, The Black One, Ken Schwaber wrote that one of the main duties of The Scum Master was to make sure there were enough chairs at The Daily Sc rum. I'm sure Ken doesn't believe that anymore. Gene Tabaka, author of Collaboration Explained, used to focus on sprint planning and sprint reviews as a team's main inspect and adapt checkpoints. But she's told me she since learned that for teams she works with, that isn't usually enough. And they benefit from a form of mid-range planning or road mapping in order to really create awesome products. Henrik Nyberg, author of the Scrum and XP from the Trenches book and the great Spotify culture videos, once believed that each team needed a dedicated Scum Master. But he told himself, hey, I could be wrong. and now says it's fine for a full-time scrum master to perhaps work with up to three teams. Henrik also once believed that teams should be stable with the same team members from sprint to sprint. That's something I still believe. But Henrik is one of the most open-minded people you'll ever meet and says, sometimes it works really well to have dynamic teams where people switch around as needed. He's got me saying, hey, I could be wrong about this one.