“Agile is a devastated wasteland. The life has been sucked out of it.” Those are the words of Kent Beck, creator of Extreme Programming, and co-signer of the Agile Manifesto. According to Kent, many development teams have adopted Agile methodologies without understanding their purpose. In today’s episode, we’ve recruited Aaron Foster Braylin and Steve Solomon for a deep dive into Agile, with a special focus on comparing Extreme Programming (XP) and Scrum. We begin by exploring what stand-ups mean for each guest before discussing Scrum’s openness to incorporate processes, so long as they work. We then talk about what it means that Scrum emphasizes product development while XP highlights the quality of life and software. Our next battleground of comparison relates to XP and Scrum values and how they lead to fundamentally different approaches to sprints. After drilling down into how the value of simplicity affects each model, we talk about pair-programs and broadening your agile approach so that non-engineering teams can be integrated into your process. Near the end of the episode, we look into the key difference between Scrum and XP. You’ll discover which method can’t be followed without subscribing to its values. Tune in for more from the ‘Agile Wasteland’ and find out if Scrum of XP is the right method for you.
Key Points From This Episode:
- Introducing today’s guests, Aaron Foster Braylin and Steve Solomon.
- Kent Beck’s hot take; Agile is a “Devastated wasteland. The life has been sucked out of it.”
- Exploring what stand-up means for each of our guests.
- The benefits of asynchronous stand-ups and ‘stand-downs’.
- Defining Scrum and XP and the different environments each was designed for.
- What the differences between Scrum and XP values tell us about each model.
- How Scrum’s value of ‘openness’ mirror’s XP’s value of ‘respect.’
- Commitment versus feedback and how this affects development.
- The many angles to adding simplicity as a core value.
- Broadening your XP or Scrum approach to include designers and other non-engineers.
- Why simplicity doesn’t mean the same things as easy or fast.
- How Scrum boils down to a set of practices, while XP can be reduced to a set of values.
- Why Kent Beck might be right about Agile methodologies.
Transcript for Episode 174. XP vs Scrum
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.3] DA: Dave Anderson.
[0:00:10.4] MN: And today, we’re talking about extreme programming versus Scrum, it’s the showdown of the century.
[0:00:16.2] DA: Yeah, battle for the ages, basically.
[0:00:19.8] MN: Who is the best Agile?
[0:00:21.7] DA: Well, I mean, we know that extreme programming is extreme but Scrum has no qualifier, so it really does not have the edge there.
[0:00:29.5] MN: There you go, we have two guests with us today, we have Aaron Foster Braylin and we have returning guest Steven Solomon. Good evening Solomon, how are you all?
[0:00:39.6] AFB: Great, how are you.
[0:00:40.3] SS: Doing pretty well.
[0:00:41.0] MN: We’re doing the best that we can. Let’s start with Steven. Steven, tell us a little bit about yourself.
[0:00:45.3] SS: Yeah, I’m someone who is very passionate about extreme programming, I’ve been trying to learn it for the past 10 years and while I’m learning it, I spent the past five years of my life teaching it to others so I’m very excited to chat more with you all about this.
[0:01:01.1] MN: Awesome, Aaron?
[0:01:02.2] AFB: I’m Aaron and I have been working in various forms of Scrum, XP, Waterfall, you name it, with various clients for about a few years. I think it’s been about 10 or 11 different companies that I’ve worked with. Excited to learn and chat with y’all about it.
[0:01:19.8] DA: This feels like every single one is like — do we need a separate label for this? Feel like so many.
[0:01:28.3] AFB: As soon as I can tell the difference, I’ll let you know.
[0:01:31.7] SS: That’s why I’m here.
[0:01:34.2] MN: This conversation kind of started because Steve mentioned before that he had a Kent Beck quote that was pretty spicy, you got a spicy hot take over there, Steve? You want to share?
[0:01:44.9] SS: I do, very recently, Kent Beck, one of the founders and consigners of the Agile Manifesto was asked about the Agile Manifesto and what he thinks about Agile now. He responded to that — and his response was as follows. “It’s a devastated wasteland. The life has been sucked out of it. It’s a few religious rituals carried out by people who don’t understand the purpose that those rituals were intended to serve in the first place.”
[0:02:16.0] MN: What?
[0:02:17.3] AFB: Wow.
[0:02:20.8] MN: What a mic drop, where was he when they asked him that, did he just walk off after the question?
[0:02:26.7] SS: Wherever it was, it was apparently a bad place.
[0:02:30.1] DA: You heathens.
[0:02:32.1] MN: Yeah, you don’t know anything, you understand nothing.
[0:02:35.9] AFB: Wow, it really sounds like there, he’s drawing some kind of value judgment part of the pun, but the value didn’t portray like the practices and the principles or values of Agile as a whole.
[0:02:50.1] MN: Yeah, I think it even eludes to when Aaron did his introduction, you say you did every single part where it was Agile, Scrum, off the book, and he maybe saying like, you know, insinuating that those companies that choose the different flavors may not actually do the right thing. May not be practicing what it should be by following the ceremonies and understanding what they’re doing. That’s kind of crazy.
[0:03:14.9] DA: I got to say like, I do stand-up every day. I do it every day, come on Kent. I’m showing up.
[0:03:21.9] MN: Yeah. I mean, I guess how are you doing stand-up? Is the question.
[0:03:26.3] DA: Intentionally?
[0:03:27.7] MN: Yeah.
[0:03:27.6] DA: I’m using it as a platform for my tight five, my company routines.
[0:03:36.1] MN: I’m going to be honest, I’m not standing up as stand-up at this point in time. It’s part of the pandemic, it’s got me sitting, stand-up can be sometimes a little bit longer than normal because everyone’s in now.
[0:03:47.1] DA: Maybe that’s what he’s talking about. People are sitting down during this pandemic, they’re not adhering to the vision of the Agile value of being stranded.
[0:03:56.7] MN: Right. What is the purpose of stand-up? I guess is the question and then maybe there are places that he may have observed in this particular example using stand-up that you know, while they are standing up and their words are rolling out of people’s faces. Is it really what was the intention of stand-up? I’ll ask, what does stand-up mean to you Steven?
[0:04:19.5] SS: Yeah, the purpose of which, I understood, as always to get folks on blocks. It’s definitely been on some teams that I’ve worked with and an opportunity for folks to check in and basically a status meeting. Which, as I understand, is not the point, what about you Aaron?
[0:04:38.0] AFB: Yeah, for me, I think the purpose of stand-up is a way to get a shared understanding of what the team is doing. It’s really easy to get isolated, especially now in the pandemic, like, stand-up is like, kind of even more important in that way. Because usually it’s just me at a desk but now it’s, like, me in another room. And so it’s a way to just understand what other people are doing. Make sure that we’re all aligned and also to get a safe place to raise concerns or questions or whatever.
On my current project, we have an asynchronous stand-up that everyone post the same copy, paste, little template that we do from the day before.
[0:05:18.2] DA: Yeah, some emojis in there.
[0:05:20.1] SS: Yeah, of course. You hit the nail directly on the thumb there. But because of that and because it’s just a team-wide thing — my actual track of work or the sub project, the track of work that we do, we now have a synchronous stand-up with only part of the team. Because, we have found the need to align to be like, “Okay, yeah, we have this in a really big story, you’re like where can — if you’re working on this part, I’m working on this integration. Let’s make sure we do this, we’re both having select conversations with this other team? What if we unify them into one conversation.”
On this team, it’s actually been really interesting to see like hey, let’s solve the dogmatic use of the async, let’s have an asynchronous stand-up. It solves it, we’re doing Agile, we have a stand-up. And then, to see it like re-emerge organically, because it’s there to solve a problem.
[0:06:26.7] DA: Feeling some pain and then you're like wait, how do we fix this, we talk to each other.
[0:06:30.8] SS: One of the best moments of stand-ups, I’d actually ever seen was at a client I worked with. And they had already gone from our office back to their office and we were working in their space with them and at that moment, they started not doing a stand-up. But instead doing a stand down where folks would check in with each other and share context at the end of the day, which was really fascinating.
[0:07:00.9] MN: That’s pretty awesome, yeah, because you know, you want to check in with the team and, like, just give an update on what happened throughout the day. And I like the term stand-down because it’s like, at the end of the day, it’s not like you’re going into work and potentially getting worked on or getting unblocked by an individual, by someone else. But more like, “Here’s where I am now and then we will regroup tomorrow.”
That team also has stand-ups, was it in the morning and then in the afternoon or was it just one?
[0:07:31.8] SS: That’s a great question, we had like a team stand-up and then they’re stand-down was just like, for the entire department. And the engineers were the ones leading that initiative of, like, “Hey, there’s context here, there’s things we want to make other teams aware of.”
Very much in line with the spirit of a stand-up and there were no managers, there’s no one outside of just devs getting together, saying, “Hey, this is going to be a problem we’re trying to do this integration next week and it’s going to impact your system and you should probably know about it.”
[0:08:04.0] MN: That’s awesome, yeah.
[0:08:05.2] DA: What do you think is the fundamental tension between, like XP, and Scrum in this context? Or is it more general than just XP versus Scrum?
[0:08:17.2] SS: Should we start out with defining those things?
[0:08:20.3] DA: Sure, yeah.
[0:08:23.0] AFB: I would fail to have a good definition of Scrum.
[0:08:24.8] MN: Well, don’t worry Steve, we got the internet, we’re going to read the definition right here from the Agile Alliance. I can start with the definition of Scrum and we’ll use — according to the Agile Alliance, “Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments.
That is, when the framework is used properly. Scrum is structured in a way that allows teams to incorporate practices from other frameworks, where they make sense for the team’s context.
That sounds like a lot of dev shops that I have worked at, they got the Scrum, this definition sounds like the thing that, you know, is backed by a lot of the ceremonies that we can discuss, right? There is the team stand-up to share and collaborate with individuals , what you did, what you're going to do and how you're blocked, simple.
Then there’s like retrospectives to talk about how things went during the sprint, if we’re doing sprint in that regard. There is post-mortem that sometimes happens in certain dev shops where you know, something broke, and we want to, you know, have a conversation about what happened and how do we fix it?
The idea of like, you know, having an idea, trying it out, assessing if it works and then reassessing the entire situation or something that I imagine, this definition is definitely captivating with the Scrum. Does anyone haven thoughts on that definition?
[0:09:59.5] DA: I feel like the last sentence, it really speaks to what Steven was like, you know what? I really couldn’t tell you what Scrum is because the lessons was like, in anything else you want to do, that’s okay too.
[0:10:14.0] MN: Yeah.
[0:10:14.7] SS: It seems to me as if the definition of Scrum in this context, it’s like a way to iterate. It’s a process of iteration whether, and like, I think that’s what they’re kind of getting at with the idea of hypothesis. And like you said, with like stand-up, and blocking, retro post-mortem, it’s like this, a way for a team to move forward. And then yeah, the lesson is like, “And anything else that you think of that would help in whatever your front may be, yeah, go for it. Also, Scrum.”
[0:10:46.9] MN: Throw it in the bag, don’t worry about it ladies and gentlemen, it’s all good.
[0:10:51.4] DA: Is Scrum like a trademark, or it’s such a specific word like —
[0:10:55.3] SS: That is a great question, I have no idea.
[0:10:58.5] MN: There is a little paragraph — for every couple of sentences, when it’s applicable for Scrum. And I could read that as this is probably pretty cool. “Scrum is best-suited in the case where a cross-functional team is working in a product development setting where there is a nontrivial amount of work that lends itself to being split up into more than one, two, to four-week iteration.
I guess, that’s the idea of when Scrum is applicable in a given organization, I guess.
[0:11:29.0] AFB: One thing I want to highlight here is that both in that, and I had forgotten this from when you read the definition the first time you said it, says — these are — “It is a system for product delivery.” Which, maybe this is a little bit of getting ahead of myself but I feel that pretty different than the goal of XP, which is something that I’m realizing more, now that I’ve heard the definition.
[0:11:57.0] DA: Why don’t we transition into what the definition of XP is to contrast that, so we can put that to focus.
[0:12:03.7] MN: Sure, I can — if you guys love the sound of my voice, I can definitely read the definition for extreme as well.
[0:12:10.5] AFB: The dulcet tones of your voice you’ve made.
[0:12:12.2] MN: Sure, I mean, this Audio-Technica microphone does a very good job, thank you. Audio-Technica, really appreciate you doing the work you do. The definition for Extreme Programming; “Extreme Programming, XP is an Agile software development framework that aims to produce higher quality software and higher quality of life for the development team. XP is the most specific of the Agile frameworks regarding appropriate engineering practices for software development.”
[0:12:43.0] SS: That’s a pretty stark contrast, already, we’re talking about what’s a good thing for the engineers and there’s no mention of product in that.
[0:12:53.2] MN: None, at all.
[0:12:54.5] SS: But there is mention of delivering a thing. Delivering working software to somebody.
[0:13:00.2] MN: Right.
[0:13:00.7] DA: Like, quality software, quality of life.
[0:13:03.3] MN: Yeah, it was higher quality for both software and life which is, like, really interesting.
[0:13:09.6] AFB: But only for the engineers.
[0:13:11.3] MN: Only for the engineers. Product people, go find your higher quality of life somewhere else. Yeah, I think with this, I can definitely see, like, you know, the idea that the higher quality of life with a software engineer in that, like, you're never isolated by yourself working on a project or rather working on a particular feature. Or, like, work by yourself, given that XP, like one of the requirements is that you’re doing, you’re peer programming with someone else. You're in the trenches with someone else, you’re not by yourself.
[0:13:45.5] DA: That’s part of the ‘extreme’ specificity, with the prescription for it. Like third practices and principles, like, ways do you work.
[0:13:54.9] AFB: One thing that my experience of applying XP has taught me is there’s so much emphasis in the XP community about values. There are two things that are constantly discussed is, “How do we deliver a thing to customers so they can start doing a thing, right away.” And, “How do we apply these five values in our context to deliver more effectively?”
[0:14:21.2] DA: I think that’s also, like, a thing that with Scrum and values, I came up kind of blank. Because it is like such a ‘grab-bag’ that it feels like it doesn’t have as much of an identity or an opinion. Although, when I googled it, they did have five values and they were slightly different than what’s from an XP which was interesting.
[0:14:46.2] MN: Yeah, I didn’t even know that there were values in Scrum and that there were five of them. I thought, when I had done the Google as well, I was like, “Oh yeah, there’s five, okay, yeah, I can see that. I’ll download that pdf, I’ll give it a read.”
[0:14:59.8] DA: Yeah, but like, I feel like I knew off the bat, being also, like someone new is like you know, an XP practitioner when the time arises, when I can, but you know, feedback of course is like one of the ones that always comes to mind about like, you know, pair programming, TDD, all those different practices. That kind of like tie in to like you know, getting something in front of somebody and getting the feedback early. And like, all of those levels and it’s so apparent.
[0:15:32.2] SS: Might it be worthwhile to kind of read through the XP and Scrum values and just kind of maybe look at the difference quickly.
[0:15:42.7] MN: Yeah. I’m going to read through the Scrum ones, just because these are fresh to me, right now, as I just Googled them and saw that there were five of them. I’ll read them down the list. Starting with “Courage, focus, commitment, respect and openness.” Those are the five Scrum values that people should follow when dealing with Scrum.
Does anyone have any thoughts as one of these values resonate with anyone in the room?
[0:16:16.4] AFB: Commitment is shocking to me as a value.
[0:16:20.5] SS: Plus, one.
[0:16:22.2] MN: Why do you think so?
[0:16:23.4] DA: You don’t believe in matrimony? Dude, you don’t want to go steady?
[0:16:28.7] MN: Yeah bro.
[0:16:29.8] SS: I don’t want to get married to the product.
[0:16:33.4] MN: Steven’s a wild child, watch out ladies and gentlemen, watch out. Steve’s out there — no commitment for him. Scroll out the window.
[0:16:42.5] DA: Don’t put a ring on it.
[0:16:42.8] MN: Don’t put a ring on it.
[0:16:44.9] AFB: I think what he means is, it’s really open to feedback.
[0:16:48.3] MN: There you go.
[0:16:50.7] SS: Yeah.
[0:16:51.5] MN: Openness, I felt was pretty interesting, I’ll try and put this image in the show notes, it’s just a picture of, like, a lock that is unlocked. And like it, has the lines of the ‘clicking out’ — and so this openness. And I never thought about the idea of like, being open with your team and discussing like, you know, if something’s difficult, you should be able to have the confidence to share difficulties amongst your team members. Because everyone is dealing with these challenges at the same time.
But like, the fact that it’s a value that is explicit in Scrum is really interesting to hear.
[0:17:27.0] DA: Kind of like the combat too, the idea of the projects, that’s a death march that no one even opens their mouths about. It feels like openness is like almost not enough, it’s like okay, it’s like a bare minimum.
[0:17:40.6] MN: Yeah, you got to have some openness at least, come on. The XP values are as follows, “Communication, simplicity, feedback, courage and respect.”
[0:17:59.2] DA: Okay, we should be brave and respectful, this is what I guess the logical extension of the Agile Manifesto is, it’s a bunch of courageous and respectful software engineers, that’s what I’m getting out of that at least.
[0:18:16.8] SS: Yeah, what I’m really fascinated and going to harp on right here is the — I see parallels between the commitment value in Scrum and the respect value in XP. Especially, given that respect, if memory serves, was a later addition to the XP values.
[0:18:38.1] MN: Yeah, that was the second addition they added it. At first, it was like what do they call that?
[0:18:42.6] SS: Assumed or something, implied.
[0:18:45.1] MN: Yeah, it’s like assume, implied or like, you know, we have respect but is that an official value and then the second edition is like all right guys, well, we’ll add respect to the list and then it became one of the five in XP.
[0:18:56.3] SS: Something’s got to keep courage in check.
[0:19:00.4] MN: Working.
[0:19:02.2] AFB: But I feel that there is that commitment and respect have a lot of similarities in how they function on a team. When I say, “Hey, I am going to do this much work this week and we have that binding blood oath that is a sprint commitment that no one can wrought asunder or whatever it is, I don’t know.
[0:19:30.4] DA: I mean that is the ritual goes.
[0:19:33.8] AFB: Only in the wasteland.
[0:19:35.2] DA: The wasteland, we combine our bloods into one.
[0:19:39.7] AFB: Yeah and Ken Beck looks down and shakes his head sadly. But I feel that the other way in the XP is that there’s that if we take that value of respect and apply it to that same situation of getting the work done that you need to get done — and that respect of the team working for each other. And I don’t want to be too tell teleological and keep using the word respect but that relationship of — you to the work to your team is different when you call it respect or commitment.
[0:20:16.5] SS: I think that commitment versus feedback differential is something that we can unpack too here like a Scrum sprint has this idea that you can break the sprint by adding more work. Or changing the priority of the work. There is such no concept in XP. In fact, there is a very explicit statement of “We want to embrace changes to the requirements even late in development. Is, there’s always we are willing to iterate and change what we are doing based on that feedback and start doing something else.” That is very different between the two frameworks, that kind of thinking.
[0:20:58.8] DA: Yeah that’s interesting. It always does feel like if you are breaking the blood oath of the sprint commitment then there won’t be a nation team that awakens and takes you. You don’t want to do it.
[0:21:16.3] AFB: I mean it is almost as if the post-mortem is about the mortem that occurs when you break that commitment right? It’s death.
[0:21:25.7] MN: Yeah, let’s analyze this person’s death so we don’t repeat it again. Always stick to the sprint commitment that is what we have to do. And post-mortem.
And one of the values that I like I find very interesting that’s in XP that I think is, maybe implied in Scrum, is simplicity. And I think the parallel value would be focus. Because, oftentimes you know, there may be a feature request and engineers go right into deep dive and how they planned to do this thing.
And like, “We’re going to build a module that is going to take in all of these different inputs” and will change drastically.” And it is usually not the simplest answer — is usually is that one. And I am curious, simplicity also, to me, sounds like delivering something very quickly so that it faces the users as early as possible. And I am curious if focus kind of encapsulates the idea that we should focus on the user and get the thing that we want out plus simplicity, like, talks to me as an engineer in building the most simple thing.
Does anyone have any thoughts on the simplicity? When I just feel like, that one feels like it’s out, like it feels weird when mentioned. Why is simplicity part of a value and then deep diving it? It sounds like you know, the simple answer is the best one until we may need another one or the next one?
[0:22:55.0] DA: I think there is a lot of angles with simplicity too, where like complexity leaks into all of the different angles of your process, which Scrum will happily lap up in order to have the commitment and consistency and whatnot. Where like, you know there are tools that you can have that define the story, set some criteria and you know, pull in the different details so that you can fill out, into the cards in the [inaudible], all the fields that are available in the [inaudible]. Like configuration that are complex but, on the other side of that is that the promise to just talk to somebody. And there is a placeholder for like, “Okay, we need to have an NAV book.” And then, you know, you can have more unless defined in that but you know, there is a simple promise.
[0:23:54.8] SS: But if we are going to take that example of using a NAV bar and the simplicity, if we look at XP as a system of how you, for engineers, whereas Scrum is for the product team, whatnot. How do we take that value of simplicity to the designer or to the product people who are doing user interviews. And what does that look like? And how do we take that value and should it be bubbled up into the greater team and to other disciplines besides, you know, engineers?
[0:24:28.3] DA: I think for design, I always like to establish for reusing things that already exist. Like, you don’t need to have everything having a unique form and function or a fancy animation or whatever. I am always threatening, whenever someone tells me like, “Oh we need an animation.” Okay, I’m like, “I am just going to have the whole page rotate. It is all going to barrel roll.” So if it works fine without the animation then, whatever, then that’s the first thing.
[0:25:03.1] MN: Yeah, I think to Aaron’s question, we don’t want to go away with whatever in the designer’s research into finding the information like the user experience and the user research and whatnot. But I think the designer should also ask themselves, “Is what the user wants to experience the most simplest thing that we can do?” They also need to encapsulate the values of XP to know that, “Hey do we really need this complicated NAV bar for example or do we really want just the hamburger, slides, out three different items. Or do we wanted to make it super fancy and whatnot?”
And the idea is that even before I get to the engineer, the designer would have to make — try and find the simplest solution to that. And if I ever wanted the team that is following the XP values. And I think that would come up, definitely would come up if people have the opportunity to pair program with the designer, right? If an engineer and a designer would have paired a program on something, the engineer is going to say, “Okay, why don’t we just try this NAV bar? Boom, boom, boom, hamburger, three items boom?”
What about this right now? Let’s see, is this good?” And like, “Okay, well let’s try adding X, Y, and Z and then if we find that it is a little more complicated, it muddles the user experience.” Then maybe the simplicity will win by being the most simple thing by pair program with the designer. The designer signs off and ships it. And then that is how the user gets that experience as fast as possible.
[0:26:32.4] SS: I think there is this clarification that we need to make between simple and easy. Because the original XP folks would say the mantra of “The simplest thing that could possibly work.” And simple in that scenario implies a thing that is well crafted and, like, high-quality. Not a thing that is hacked out and easy and fast.
[0:26:55.0] MN: Right, I should, yeah. I am going on speaker here to say that simplicity doesn’t always equal easy. It could be the simplest thing but it doesn’t mean it is the easiest thing.
[0:27:05.4] SS: Yeah, absolutely.
[0:27:06.8] DA: It is like the labor of actually refactoring something or coming up with an interface that is clean and works with design patterns and whatnot.
[0:27:17.7] SS: Yeah, simplicity takes great effort to get to a place worth the type of change we need to make is easy. And so often, it is the easy route that adds the most complexity. We can think of that, like, massive chain of nested conditionals. And the easiest thing to ship the feature is to go in and just chuck another line on there and say, “You know, if it’s Bob’s birthday, it’s, Boom, he gets the discount.” End of story, ship the ticket.
The simple thing is to actually take the time and extract out the different types of functions that could be there and say, “Here is what it means to have all of these different polymorphic options.” But that takes a lot of effort.
[0:28:09.2] MN: Oh yes, definitely.
[0:28:11.0] DA: Right. I mean how can they be 10X? Where is 10X in these values actually? None of these have 10X as value, so I am pretty disappointed.
[0:28:21.3] MN: Oh no, no 10X there.
[0:28:24.1] AFB: That’s actually what the X in XP stands for. It is the Roman numeral for 10. That’s the dirty secret.
[0:28:31.3] MN: Oh man.
[0:28:32.1] SS: It’s just 10-10?
[0:28:33.3] MN: Yeah, it is just 10-10. So what Steven? So we got these two values, what makes these two different in that regard and why would one choose one that we deemed more popular than the other in the first place?
[0:28:48.8] SS: There are some really interesting things we’ve talked about so far, like, what does it mean to apply any of these things? I think the fact that we’ve talked about Scrum and that Scrum is — it was surprising Scrum had values — is very telling. That Scrum really, is the way it’s lived out is as a set of practices. And let’s be honest, XP is less popular but XP is more about values and putting those values in context and trying to apply them and so like you know, if you want to be an Agile accountant it doesn’t mean you start pairing.
It means you figure out what it means to apply simplicity, feedback, respect, and communication into your context. As how might we use, like, how we might live out this value. And then use those as metrics to try different types of practices. I think those are two very different ways to look at the world and I think it is also interesting in that that is why one of these frameworks is popular and one of them is not so much popular.
[0:29:57.0] DA: So why should people care about XP or Scrum in 2020? Like values, practices, where does it all shale out?
[0:30:07.8] SS: It’s a really good question. In this moment where we are classifying the last 20 years culminating in a wasteland. And the dust has settled, Scrum is the predominant Agile methodology, barring some companies trying safe or something else like that. And XP is something that is really hard to do and it is relegated to the realm of consultants, those folks who can say — “It depends” and still keep their jobs. At the end of the day —
[0:30:43.4] DA: — My favorite thing to say.
[0:30:47.3] SS: I think we’re at this weird point where I think Ken’s right. I think we have lost our way and the difference between these two different frameworks is one is all about doing the thing that is prescribed. It is about doing the retro, doing this daily stand-up, having someone nominated as a Scrum master, just do this exact thing and you will get somewhere.
Versus XP, which is all about, “Hey, here is a set of values. Figure out what your context is. Figure out what you are trying to aim at, here are some — derive those principles and then start trying to do things to achieve those principles.” That is really hard and sometimes it manifests itself as pair programming, sometimes it’s something weird like mob programming, sometimes it’s con bon.
[0:31:43.5] DA: I think that is funny because when we think back to the definitions that Mike said in the beginning, it actually indicated that XP was the most specific way to go about things and Scrum has that clause at the end where it’s like, “Anything you want to, you do, and I’m cool with it.” But actually, XP, if you take it from the values, is very open-ended and a little scary,m maybe.
[0:32:16.2] MN: So I have a question then, are we, in the eyes of Kent Beck, are we all heathens now? Like called individuals who are running Scrum, you know, who aren’t following the practices and are just prescribing it. Are we in — is Scrum itself set up to be that way because you can do whatever you want if it works for your team?
[0:32:38.7] SS: Does it play out that way? I think there is something to be said about the way it usually goes when it is applied — is telling about a framework. You can call Scrums that are not fitting the definition of Dark Scrum. But if that is the way it goes most of the time and it very rarely goes in a positive direction, what can we learn from that?
[0:33:02.8] AFB: If I am understanding kind of the gest of what you are saying Steve, is that it is possible to — I am going to put words in your mouth, which is very unsanitary, but I am going to do it. But I washed my hands a lot and used sanitizer, don’t worry. But it is almost as if you can live out the practices of Scrum without having to follow the values of courage, respect, commitment and openness, and focus. Whereas, it would be nigh impossible to follow the practices of XP, of pair programming, of shared working space. I forget what the other ones are, without following and valuing tautological courage, respect, feedback, communication, and simplicity.
[0:33:52.8] SS: I respect you for having memorized both sets of those so fast. I think you get that way because one is fringe and one is not. You’re already a weirdo if you go to management and say, “I am doing Extreme Programming.” Like, you are already, — “What? What are you talking about?”
[0:34:15.5] DA: Just so punk rock and so much do.
[0:34:19.5] MN: Exactly.
[0:34:20.4] SS: You can’t see it but Aaron is the one with the Mohawk and not me.
[0:34:25.9] AFB: It’s true.
[0:34:27.6] MN: Yeah, I think one thing that I am definitely going to try and do is start a consultancy where I spread the knowledge of Dark Scrum. I think that was a great phrase-y used Steve. I may go places with that.
[0:34:39.7] SS: It is stolen from Ron Jeffries, one of the founders of all of this.
[0:34:43.7] MN: Oh man, no damn it.
[0:34:45.2] SS: Yeah.
[0:34:45.9] MN: You thought about it before me, spreading the knowledge of Dark Scrum. The darkness of Scrum. Yeah, I think we definitely had a lot to converse about just now, given the breadth of Scrum and XP and the differences and the values. So if you decide from Scrum you want to jump into XP and your boss is going to look at you weird, go for it.
I think, just know that those rituals and those practices are in place to be prescriptive. So that your team could be successful at the end of the day when you are delivering a product. And however you achieve that, whether it is Scrum or XP, those tools are there for you to do what is best for the users at the end of the day. If pair programming doesn’t really work for your team that’s okay. We could find another one and I am sure there are many other Agile frameworks that we could look through besides that of just Scrum and XP. It is just a whole lot, I imagine.
[0:35:52.6] DA: So many podcast episodes. Tune in next week!
[0:35:57.0] MN: While we figure out another one.
[0:35:59.6] DA: Roving the wasteland.
[0:36:01.0] MN: The wasteland that is Agile.
[0:36:05.6] AFB: Scavengers.
[0:36:07.6] DA: Like Mad Max, starring Kent Beck.
[0:36:12.5] SS: I would watch that.
[0:36:15.2] AFB: What kind of car would he drive?
[0:36:17.4] DA: Station wagon.
[0:36:21.4] MN: Oh man.
[0:36:22.2] SS: An extreme station wagon.
[0:36:24.3] MN: An extreme station wagon, yes. Gentleman, do you want people to contact you? Is that a thing that you are interested in having people do? Randomly, tweets, ‘at-s,’ and whatnot? Share them here. Go ahead.
[0:36:36.8] SS: I would be very interested if Kent ends up hearing this for a salty tweet at me about what kind of car he would drive through the Agile wasteland. My Twitter is @soonernotfaster and I have a website where I blog with the same name, soonernotfaster.com.
[0:36:56.3] MN: Also, do you have any interesting spelling for that or is it just in plain English?
[0:37:01.1] SS: In English, the word sooner, the word not and faster.
[0:37:05.5] MN: There you go. Just making sure, I don’t know. The startups these days do faster with no E it is just “fastr” you know I go to make sure.
[0:37:16.0] AFB: Yeah, you got to say sooner is four U’s and only one with an umlaut on.
[0:37:20.6] MN: Yeah, exactly you know?
[0:37:21.6] DA: Full glottal stop.
[0:37:25.3] AFB: As for myself, I am a hermit with no social media presence whatsoever. However if you are really interested, you could hit me up on my email. It’s email@example.com.
[END OF INTERVIEW]
[0:37:39.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources: