I recently met Dave West, CEO of Scrum.org. While not one of the founders of Scrum.org, West is the CEO and product owner at Scrum.org. Dave and I spoke a bit what is happening with Scrum.org and how it interacts with DevOps. If you are interested in Agile, DevOps and Scrum, this is a good DevOps Chat to listen to.

Here is the SoundCloud audio and the transcript is below:

Here is the transcript of our conversation:

Alan Shimel: Hi, Alan Shimel here for another DevOps Chat. And this DevOps Chat is with Dave West , product owner and CEO of Scrum.org.

Dave, welcome to DevOps Chats.

West: Oh, thanks for inviting me Alan.

Shimel: Thank you. So, Dave, I’m going to make a wild bet that most of our audience at least is familiar with Agile and Scrum.  But maybe some of them aren’t and maybe there are even some who aren’t familiar with Scrum.org and the role it plays within the Agile community. So why don’t we do a quick level-set of Scrum.org and how it relates to Agile and Scrum.

West: Yeah, thanks, Alan.

Yeah, probably. It’s definitely a confusing fragmented place, the Agile community. So Scrum.org is an organization—mission-based organization created by Ken Schwaber, one of the co-creators of Scrum. Him and Jeff created Scrum—interestingly, in the building that I’m talking to you from, over 21 years ago. The outing 21-year anniversary is in October.  Maybe it’s October the 19th. Interestingly. So they created Scrum.

Scrum.org is an organization that Ken created to, basically, focus on improving the profession of software delivery. We do that with a very large, active community—I suppose not very large—of professional Scrum trainers. About 170 of those. We do that with assessments; training and assessments around the world.

A significant number of people visit Scrum.org every day to either assess their knowledge or to connect up with a trainer or some training class. 

Shimel: Sure.  And Dave, one of the interesting things about the different classes and courses, if you will, that Scrum.org offers is the—there’s different sort of—I forgot the exact word, but there’s different roles. Right? Within the Scrum training.

West: Yeah, I must—what’s interesting, actually, Alan, is that particularly for this audience, one of the reasons why Scrum.org came into being was obviously, Ken created Scrum Alliance.

He left Scrum Alliance because they wanted to focus on the world of work. And Scrum.org cares about software delivery, and that’s a very important distinction. And so our professional Scrum developer class is actually—focuses on the practices for doing done software. And when we mean, “done,” we don’t mean, “almost done.”  We don’t mean, “Oh, well, it’s kinda done with me.”  We mean done. Meaning, potentially shippable. And when we mean potentially shippable, we don’t mean potentially shippable because operations haven’t looked at it yet, and that’s the potential. We mean, that the product owner can flip a switch and it’s live in the masses.

So ultimately, this technology focused class, PSD, is one of the reasons why Scrum.org came into fruition, and obviously Scrum Master Product Toner—that the three roles of Scrum—we have classes for all of those different roles, and they’re very team-based. And so that potentially you could have more than two roles in the same class, as well with our team-based classes.

So yeah, we definitely—we’re trying to improve the profession, Alan. So we have to provide training and certification. Third-party, validated certification on that profession and those professional skills.

Shimel: Got it. So, Agile’s been around now for a number of years and at this point, I don’t think there’s any doubt that it’s gone mainstream, obviously and has a tremendous impact across the entire software development world spectrum. But, Dave, specifically for as it relates to DevOps, often people say, “Well how do those work together?” Right? I’ve heard people say—actually DevOps.com before I had started it as a site, when it was just a blog, sort of said, “Picks up where Agile leaves off.” But I don’t think that’s necessarily true. I don’t think it was true then, it’s certainly not true now. How do you describe—let’s put it that way: How do you describe that relationship?

West: It’s an interesting one.  In fact, recently I was on a presentation with Ken Schwaber. It was a DevOps presentation at a DevOps organization and event and Ken and I were talking about DevOps and Ken’s perspective is very interesting and I think it sort of sums up the original signatures of the Agile manifesto’s perspective on it.

Ultimately, they believe and he believes in particular that we needed DevOps because nobody really got Agile. And it’s interesting because when they—when the Agile manifesto was signed one of the key terms was, “working software.” Working software. The 12 principles—working software frequently, delivering working software. That word, that phrase, “working software,” is frequently described in the manifesto.

Scrum focuses on it now. Many people get Scrum wrong because frankly, and I don’t know if you see this, Alan, and if other people have said this to you but, what most people do is they take Scrum and then try to put it into a Waterfall life cycle.

Shimel: Yeah. 

West: So they sort of create these things around Scrum and particularly in the DevOps world, the bits after—they have this whole set of processes after the Scrum and hardening sprints.  They have a release train that goes through, you know; Scrum’s just a series of stations on the release train journey and it ends up in operations and the like.

And so ultimately, Ken would argue that it’s just, unfortunately, people didn’t understand Agility or Scrum in particular and that’s what led to the DevOps movement.

I have a slightly different view. I think that the Agile was very focused on at least getting testers and requirements people and the customer and the developers together in some way. And by that focus—and that focus was important to get to improve how we’re doing software—it highlighted that we actually need other people involved and that led to this sort of movement; combined with some technology changes like stuff around the cloud and the ability to self-provision and all that kind of stuff.

So, it led to this sort of DevOps movement. I’m not sort of anti-DevOps. I think DevOps is an awesome set of ideas. I think people like Gene Kim and the Phoenix Project etc.—amazing stuff.  But ultimately, in my opinion, it’s all about improving the profession of software delivery and it’s all about Agile software and I see Scrum and a variety of other approaches really just being incomplete without the ideas of DevOps in them. And that’s certainly true of our PSD class. That’s certainly true of the message that we send to our customers. Sometimes they don’t like it when we say, “Okay, what does done mean to you?” and they say, “Tested.” And we say, “Not quite sure. There’s a few things after test.”

Shimel: Correct.

West: And they go, “Well, no.  There’s nothing after test to us. That’s when those ops guys get involved.”

Shimel: Yeah.

West: And they’re like, “Well, there might be a lot of—does ever defects come back into the process after test?” Well yeah, of course, you know, there’s – “And do ever customers have issues with it?” Oh yeah, and, “Do you ever get operations saying, ‘well we can’t get this to run on this environment?'” And do you ever say, “It works on my machine”?

And all of those things get in the way.  All of those things that, whether you call them debt, whether you call them quality issues, get in the way of delivery and working software that amazes the customer, and getting that feedback.

So DevOps is a great set of practices and ideas and a great movement than can make Agile even more successful.

Shimel: Absolutely. I call those things “life,” by the way. But, you know, life gets in the way of the best-written software.

So, a couple of things Dave. I have two specific questions I’d like to ask you.

One is, you know one of the things that—maybe it’s been a double-edged sword for Agile/Scrum movement—but in my mind it certainly had so many positives, was the whole idea of the Agile manifesto, right? And sort of codifying if you will. What it is; the definition is. And then I think that leads to the ability to really nail down roles and training and methodologies.

Well, as you know, in DevOps, there’s been a big resistance from even defining it officially. We never had a DevOps manifesto and there probably never will be one either. Do you view that as—let me contrast that with the Agile and Scrum experience— positive? Negative? Double-edged? Both ways? What do you think?

West: It’s interesting because I think a lot about how you drive change into the world and obviously at Scrum I spend—at Scrum.org I spend a lot of time thinking about the success of Scrum. Scrum, as I said, turned 21 or turns 21. It currently can’t drink but in November it’s gonna be crazy.

Shimel: Mm-hmm.

West: In October, it turns 21 and I think about the success and Scrum is practiced—I was talking to Ken this morning, and it’s funny because I said, “You do realize Ken that over a million people every day, do a daily Scrum.”

Shimel: Yep.

West: He said, “Wow, that’s a lot, isn’t it?” And it’s practice.

Now, whether it’s practice—well, Alan—whether they’re doing it right and whether that actually is good, and lots of questions.  But ultimately, you can’t argue with the success of Agile and Scrum. And you can’t argue with its—and so I often think about what makes it successful and is it the manifesto? I think in part it is.

I think it provides a set of principles and ideas that sort-of provide the social system as it were to the practices that Scrum encourages. And I think things like the Agile conferences and that continues—you provide a place for people to talk about it, which is good. I also think there needs to be a very effective commercial model and when I mean commercial model—a commercial model around driving, making people go to pay their mortgage and put food on their table using Scrum to help them do that. Whether that’s through training, certification, writing books—there’s over a hundred books with Scrum in their title just on Amazon. There’s like 130 and I got bored counting. And I didn’t count the foreign books obviously because I’m English, and that’s against my principles.

But what’s interesting is that—so that commercial model is incredibly important and I think also ownership. I think the one thing that we’ve found with the Scrum community is that Ken and Jeff have continued to really push it and drive it and that ownership connected with certification, assessments, training, books, community—strong community—simplicity, because I think that’s a very important idea that comes out, have allowed Scrum to be successful.

So, I look at DevOps. And DevOps is very fragmented—even more-so than Agile. Vendors tend to have taken it and defined it to their own needs. You know, the Scrum Guide is the definitive definition of Scrum. It’s about 16 pages. It’s translated into over 40 languages and you can’t—it tells you what Scrum is. And if anybody says, “Oh, well, to do Scrum you have to do Jira and Jira does this,” I’m just using Jira as an example; it’s an awesome tool. No, actually, no, Scrum says this and yes, you can have ways of doing the daily Scrum with your Jira board and whatever, that’s cool. But Scrum is Scrum. And the problem is we’ve got all these vendors defining DevOps to be what they want it to be. To sell some software. All good—I mean, fair play to them. I would do exactly the same.

So, without that sort of body of knowledge, without people sort of saying, “Hang on a minute,” sort of leadership, clear leadership. Without a commercial model that’s driving DevOps into organizations, or Scrum into organizations is another example. I think you have some significant challenges. I’m not sure they need a manifesto Alan, I’m not sure they need—but they definitely need a definitive what it is, however that’s done. It could be done with a guide. Or it could be done with something else. And I think that it needs that sort of leadership as well. And Gene is awesome—Gene Kim and the guys. There’s some really good thought leaders, but again, they’re fragmented as well.

Shimel: Sure.

West: Is Jez Humble a thought leader in it? Yes, he is. But he talks about continuous delivery. He doesn’t really talk about DevOps and ….  That’s challenging.

Shimel: Yeah, I know, Dave. So just, my 2 cents on it is, it’s very much a two-edged sword. In some ways, it’s been its biggest help and in some ways its biggest hindrance.

I’m just back from London with Gene Kim’s DevOps Enterprise Summit, London took place and I interviewed all the speakers there and we did a ton of video and speaking with people and what’s interesting is by its lack of definition, the DevOps way if you will—the DevOps way is whatever you—sounds like something out of the Dune movie, the Weirding Ways. But, the DevOps ways are that patterns or whatever you want to call it is moving even beyond Dev and Ops. Dev and Ops working together to encompass security, QA, other parts of the IT stack and even beyond the IT stack, we heard stories of marketing and biz and HR even, teams that are starting to use Kanban and stuff like this because it helps them. I mean, look: Here at DevOps.com, we do a 9:30 standup meeting around the table every day, right?

And you know, I don’t consider us a software company, per se, or that we’re developing software but the entire on-prime staff is in that meeting. And we do our check-in and so forth. But that being said, that lack of definition has almost, I think enabled DevOps to move beyond pure Dev and Ops. But you speak to—you talked about Jez Humble—you speak John Willis for instance; another DevOps, kind of, personality who’s been around a while and John says, “No, I’m more of a purist.” DevOps is about Dev and Ops. Right? I don’t buy into that whole kind of thing, but that all being said, that kind of helped it not having that definition but to your point, it hindered it in that you can’t really put your thumb on it and it’s nebulous and a lot of people say that. Right?

West: Yeah.

Shimel: And it’s this—

[Crosstalk]

West: It might be good and it might be bad. What ultimately all of us are striving for is the values of the Agile manifesto.

Shimel: Sure.

West: And DevOps is doing that as well. It’s about delivering done. And it’s about breaking up batch sizes to smaller increments of value driven by hypotheses or experiments or ideas and it’s about delivering practices which the DevOps community have in spades of actually being able to do that.

Shimel: Yep.

West: So if you have the principle of delivering software frequently, and observing it’s use by customers—if that’s a principle that’s driving your delivery mechanism then it’s crucial that you get that transparency. You instrument etc. You do it frequently, you get the batch size smaller, etc. Those principles—and they all trace back to that ultimate set of Agile ideas—and those ideas are basically all in response to the fact that we’re working in environments where there’s a large amount of unknown. Whether that be technology, whether that be business. And those unknowns require us to work in a different way.

The traditional, very efficient, big silos, clear hand-off, control points, get in the way when there’s a large amount of unknown and where variability is the currency of the entire operation. And when you do that, you have to work in different ways. And all those practices, make it so much better. And I think that’s what we need to concentrate on.

[Crosstalk]

Shimel: Those are the universals. Dave, I think that’s universal. Yeah.

West: And I think that’s what—and I think, to be frank, most of the—I know Gene definitely is very, very conscious of that. Obviously, protecting his brand as he needs to. Yeah, I just love the fact that all these vendors positioned DevOps for their own means. Yeah, so, I don’t know. What I do know is that Agile isn’t versus DevOps and Scrum.

[Crosstalk]

Shimel: Certainly not.

West: And Scrum isn’t versus DevOps and we need to stop thinking about the Sprint Review as a phase gate to release to operations. And we need to think about it as a mechanism for learning, inspect and adapt. Learning at the boundary of the Sprint. So, we’ve got this chunk of work—two weeks of work—we’ve delivered some software and production hopefully during that two weeks of work. Operations is part of our Dev Team. There just—whether that be directly or indirectly. Obviously, we know that if it’s indirect, cues are bad because that reduces Agility.

So, we need self-serve, we need automation that allows them not to be a bottleneck. We need to be able to get RVMs when we need RVMS, etc. And we need mechanisms in place that get rid of all the overheads to the delivery teams. And I say delivery, not development. It’s everybody that’s needed. We need some mechanisms in place that get rid of the inhibitors to delivering working software as frequently as we need to, to get that inspection working for our business.

That’s what ultimately we need to do and sometimes DevOps—it’s a great movement. Sometimes, it gets in the way because we go, “Oh, wow now I’m DevOps, not Scrum.” And I don’t give a diddly if you’re Scrum or DevOps. All I care about is delivering frequently to learn so that I can improve and deliver value faster to our customers.

Shimel: Got it. Well, Dave. I hate to do this to you, but we’ve run over schedule here. But it happens. I told you before we got on, that it goes quick. We’re well past it at this point. But, one last question that I like to always ask guests, and that is: Can you recommend one book to our audience that they should read?

West: Yeah, Alan, I don’t know if I can recommend a book to read, but I can tell you the book I’m currently reading.

Shimel: Fair enough.

West: And it’s interesting because there’s lots of great books, obviously. A wise man once said to me, “I don’t mind if you read my books, as long as you buy them.” So there’s lots of great books, but I like the book I’m reading at the moment. It’s called, “Turn the Ship Around.” And it’s a really interesting—it’s a true story of this—basically, this guy that’s running this nuclear submarine by this gentleman called David Marquet. And it’s really very interesting because a nuclear submarine you would think has got as much in common with a software delivery project as—I don’t know—as something that doesn’t have much in common with something else.

But ultimately, you learn a lot about how you can get autonomy, get self-direction in your teams, how you can keep people happy when you’re in this, sort of, steel coffin under the water when you’re not talking to your loved ones for thousands of hours because you’ve got nuclear weapons on, and you have to be hidden somewhere in the Atlantic or Pacific. And it’s a very interesting book and I’m about halfway through, so I can’t tell you if it’s the best book in the world but I can tell you the first half has started very, very well. “Turn the Ship Around.”

Shimel: Got it. Sounds like a good and I will see if we get any feedback from the audience.

Well, Dave, so we totally blew through this, but it’s okay. It was a great interview and I hope people enjoyed listening to you continue success with Scrum.org and maybe we could have you back on at some point; we could continue this discussion.

West: I’d love to Alan. Love to. It’s been an absolute pleasure.

Shimel: Okay. Dave West, product owner, CEO of Scrum.org, thanks for being this episode’s guest of DevOps.com

This is Alan Shimel for DevOps.com.