Podcast Host (5:37)

Coordinate the process work, right?

Chris Sims (5:39)

Yeah, we'll do it. And so that is how I became a Scrum Master, because stream programming, at least the way we practiced it, was Scrum, right? It was Scrum plus a handful of technical practices that made it really robust for software product development. And so, yeah, I just kind of stumbled into being the Scrum Master.

Podcast Host (6:02)

And when you talk about XP being basically Scrum with a few practices that, that give it the robustness that you were referring to, one of the things that comes to mind, of course, is that okay. But that also means that in your experience, that aspect is often overlooked in Scrum meaning the engineering practices. And without going into too much detail yet, I would like to ask the next question because it may be related to this. I don't know. We haven't prepped this before the next question, of course, it's the failure question, because it is failed Monday here on the podcast. And I was wondering if those engineering practices have anything to do with it, but without judgment or assumptions. Do tell us that story, Chris, the story of a difficult moment you had as a Scrum master.

Chris Sims (6:57)

All right, well, so my story is from that first team. So we had the engineering practices. So the, the failure is not about that. Although I will just anecdotally say for quite a while early in my, you know, Agile coach career, I was not super keen on Scrum at least versus xp, because I thought, well, XP is obviously so much better, at least for software product development. And I frequently held the belief in, stated the belief that Scrum was becoming more popular than XP because it was easier, right? The price of admission was lower. You didn't have, you didn't have to adopt all these technical practices. You could just do the kind of, you know, planning, inspect and adapt cycle and, you know, theoretically the teams will discover and implement those practices and then practice. Not always, right? So, but, so my failure moment was this. So we were practicing xp. It was early days, right? Those of us practicing were communicating back on Usenet, news groups and sharing practices and all of that. At the time we were doing relative estimation, kind of relative estimation, but we didn't have story points yet. And so we were using ideal days as our estimating unit. And the concept was, oh, if everybody left you alone so you could focus and everything went perfectly well. How many days do you think it would take to do this? And those of us on the team understood that, right? We knew that it was like, yeah, but in real life there's interruptions. In real life, unexpected things happen. And so this is just an estimating unit, but that's what we estimated in. And then we had a velocity that was, you know, so many ideal days per week. And, you know, it ended up being something like, you know, two and a half or something like that, you know, team days, if you will, ideal team days per week. And it worked great, right? We had good predictability. We could tell our stakeholders, give our stakeholders good guidance about what they were going to get. It was working great until a VP was kind of cruising the, you know, the, the intranet and discovered the spreadsheet where we tracked, right, what we were committing to and what we delivered and all of that. And they were outraged that this group in California because the main company was based in the East Coast. We were an office out in California doing this wacky XP stuff. You know, we were only working two and a half days a week. And, you know, I got this call from this.

Podcast Host (9:47)

Oh, no. Yeah, I can imagine the conversation.

Chris Sims (9:50)

And we had been kind of, you know, like a. Under the radar, using xp. Like, the people in the California office knew it, right? My manager knew it, but we weren't broadcasting. We weren't saying much about it. So this VP calls me up and says, hey, I hear all of you out there in California are doing extreme programming. And I'm like, oh, yeah, it's. It's great. Blah, blah, blah, blah, blah. And they were like, you know. But, you know, I actually, this conversation had two parts. Oh, I forgot the other part. So this was a financial software company, right? Like, our customers were investment banks, money management funds. And so at first, this VP is like, chris, I don't think you understand what's at stake here, right? We do financial software. Our customers are these, you know, big important companies. We don't want extreme programming. We want conservative programming. I was like, oh, so. So first I had to, like, explain how, like, the practices we were doing were actually, like, ensuring much higher quality than kind of the standard practices. And so they. They eventually kind of calmed down about that a little bit. But they. They still didn't like this notion of extreme. They had this vision of people like, I don't know, coding while we were on surfboards or something. And. But then they said, okay, well, but I just found this document that, you know, shows that the team's only working two and a half days each week. What's going on out there, right? And it took a long time to explain this whole relative estimation and the concept of ideal days and blah, blah. You know, eventually the VP wrapped their head around it and they were like, okay, I kind of get it. But then after the call, right, it's like, oh, good, right? You know, dodged a bullet there. I kind of figured out, right, it probably wasn't the vp just with nothing better to do like searching around on the Internet, looking at random files, right? It was probably some other person, right, who found this and then shared it with whoever and shared it with whoever. And probably out in the main office, there was all this talk about the crazy California team that only worked two and a half days a week. And then it eventually bubbled up to the vp, and so it actually probably put A black mark on the whole group for quite a while in terms of there being a bit of a even bigger cultural divide between the main east coast office and this smaller California development group. If I was going to look back on it and say, well, what would I do differently? I would say, number one, probably socialize things a little bit better, right. So that it wasn't so under the radar. But number two, do it in a way that's meaningful to those people outside the group. Right. So for example, you know, the tool that we're using for how we're getting our predictability, nobody outside needs to know that, see that, or even understand it. But what we need to do is make sure we're communicating with our stakeholders very vigorously in ways that they understand, publishing things that say, oh, here's what, expect what's expected in this time frame and you know, really focus on what they care about, which is, you know, what are they going to get, when are they going to get it and really communicate in ways that's meaningful to them. Right. Because like for us we were excited about extreme programming, but to people who hadn't heard about it and didn't know what it was, right. That was just a scary sounding label. Right. So we probably should have been communicating more about like, oh, we're doing test first development and this is giving us like higher quality and you know, faster turnaround.

Podcast Host (13:38)

And you know, that's definitely something that we in the Agile movement need to realize that the way things are conveyed, messaged has a direct impact on, on how they are accepted. And of course extreme programming, that's an easy one. Eventually later on it was called xp and XP actually was, thanks to Microsoft, a good name to have. But we had the same problem with Scrum, right. Like Scrum was labeled Scrum specifically because of the origins and then Scrum Master was, was labeled Scrum Master because they wanted to have a name that was outrageous. Which is all good and well when we are starting off right, like we're, we're in the niche but then when we, we go mainstream, like we are now, we need to start understanding what this means. And there's been quite a backlash. For example on the grooming meeting, which is now refinement or Scrum Master because of the word master. Those all things have impact, right. And it's okay, like we don't need to get things perfect the first time, but as you said, it's important for us to know who we are talking to and to shape our, our message and our conversation that way.

Chris Sims (14:52)

Yeah, yeah, and I'm definitely one of the people in the camp of, you know, renaming Scrum Master is long past due. Right. I've got clients who like Scrum Coach that I love. That. Right. Or just Team Coach. I found some places to go with Agile Manager. I personally don't love that as much, but the places that do it advocate for that because they say, well, it gives that person maybe more prestige by having them manage your title as part of their title. But yeah, I'm firmly on board that it's time to move beyond Scrum Master. And honestly, even Product Owner is a little problematic.

Podcast Host (15:38)

We have the suggestions by Chris, do send all your suggestions to me as well. You can just if you got this over email, just reply to the email if you're listening in your podcast app, Spotify, whatever, just go to the website and leave a comment on this post and let's get the conversation started. Chris, thank you very much for sharing those insights with us.

Chris Sims (16:07)

Oh, my pleasure.

Podcast Host (16:10)

Hey friend, thank you for staying here. Is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from Agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen In Tallinn, Estonia, May 18th 18th. That's the workshop day. Then 19th and 20th, the conference day. And Tallin, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events. Events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on, for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about, for example Open Strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendeet's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations, Agile Product for product managers, product owners and innovators and Agile Developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn by challenging the ideas that don't work anymore. At the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now@globalagilesummit.com I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.