In this episode

• What motivated the invention of the Scaled Agile DevOps Maturity Framework (SAD MF)?
• How Convoys are superior to Trains for agility
• An overview of some of the new Agile Ceremonies introduced by this innovative framework
• The benefits of Scrum of Scrum of Scrum of Scrums
• How SAD ensures that we build quality in, via the ceremony of the Tribunal
• How to guard psychological safety of leadership
• How a SAD MF certification badge exemplifies the value of certification badges
• Why you should absolutely be SAD MF certified, even if you already have other certifications
• Why executives love SAD MF: No risk of culture change!
• Why the titles provided by SAD MF instill confidence in the heirarchy
• Why nobody dislikes SAD MF
• The amazing metrics mandated by SAD MF which make manager's lives seem easier immediately
• How the SAD MF QA Team frees coders from worrying about user requirements, and whether their code works
• What changes are coming up in SAD MF 3.0?

Resources
Scaled Agile DevOps
Minimum Viable CD and (Tiny DevOps Episode #21)

Guest
Bryan Finster
LinkedIn: bryan-finster
Medium: https://bdfinst.medium.com/

Transcript

Speaker: Ladies and gentlemen, the Tiny DevOps guy.

[music]

Jonathan Hall: Hello, everybody. Welcome to the first episode of Tiny DevOps for this new second quarter of 2022. I'm really excited to about today's episode because I've recently come across what might be the most exciting advancement, if you will, in DevOps and in agile in probably years, maybe longer. What's better is I have the author of this new amazing framework on the show today to help explain it and explain to you why you should start using this new framework. Bryan Finster, welcome again. You're the first second-time guest on this podcast, so welcome back. I'm so excited to have you.

Bryan Finster: [crosstalk] I'm deeply honored, Jon. Thank you.

Jon: Great. For those of you who are not watching the video, Bryan is wearing an amazing t-shirt that touts the benefits of GitFlow.

Bryan: Yes, GitFlow is the the ultimate branching strategy for when you need to deliver eventually.

Jon: I love it. Bryan, tell us about this framework that you've invented. What's it called and what does it do for us?

Bryan: There's a lot of scaling frameworks out there if we're trying to scale agile or scale DevOps, but the one thing that all of them have in common is they're incredibly expensive. I thought, what if we came up with just something that was more nimble than a lot of them, but also cheaper? We came up with scaledagiledevops.com, and it lays out all the things you should need to really drive real DevOps.

Jon: That's really good. It's Scaled Agile DevOps. Is that the full name? Do we have an abbreviation.

Bryan: Oh, there's a shortened version for people who, like me, have trouble spelling, is SADMF.com.

Jon: SADMF. I think I can remember that one. SADMF. Okay. The idea here is that scaling agile and scaling DevOps is complicated and expensive if you go through all the trainings and all the certifications, so now you don't have to. You can get, I guess, the same or more benefits through this framework for less cost. Is that how that works?

Bryan: Yes, it's basically the things you really need to know without all the fluff, and so, of course, the cost is less.

Jon: Nice. Let's talk about some of the things that this framework provides.

Bryan: The thing that really differentiates, there's a really popular scaling framework out there that has release trains to make sure that all of the things deliver at the same time on this release train, but the weakness with the train is it's not very agile because it can't turn. What we have done is we've come up with the release convoy. That's the central theme of what we have, is the release convoy, because with the convoy, yes, it's large and cumbersome, but you can also turn, and so it's more agile.

Jon: That's amazing. Just by changing the metaphor, you're able to- [crosstalk]

Bryan: You become more agile. Exactly.

Jon: That's such a simple change, but so profound. I imagine, good agile is always surrounded with ceremonies and rituals. What rituals and ceremonies are involved in the convoy?

Bryan: With the release convoy, there are several. I won't go through all of them because I think that they could just go to the website and read them, but I think that some of the ones that are most important, you have the captain's mast, and to be clear, this is a naval convoy. This is not convoy with trucks, this is [inaudible 00:04:11] [crosstalk].

Jon: Okay. Good clarification.

Bryan: That's important, and the logo, I think, on the site reflects that as well. The captain's mast, and I'll just read it because it's short. This is a ceremony where anyone who wishes to change priorities is set in convoy alignment, files a PCR to represent it, to change for approval, so that the the signals officer can adjust the completed versus committed goals of the convoy to ensure it does not reflect poorly on the commodore who's leading the convoy. You have to file-- It's really to make sure that we don't have the metrics make the leader look bad because we've changed priorities.

Jon: Okay. That's really good.

Bryan: Yes, and of course, you've got the scrum of scrum of scrums to make sure that we effectively communicate things.

Jon: Everybody knows that scrum is good, so more of it is better.

Bryan: Yes, more scrum. Basically, at your scrum meeting, you elect to tribute to go to the scrum of scrum meetings, and from that group, also Alexa tribute to go to the scrum of scrum of scrum meetings to communicate everything. That's to make sure the broader organization knows what's going on, [crosstalk] be forever in your favor.

Jon: Does that scale infinitely-- If you have a big enough organization, can you have a scrum of scrum of scrum of scrum of scrums?

Bryan: Oh, I'm sure. Yes. It [unintelligible 00:05:47] because really-

Jon: You could just go as far as you need to?

Bryan: Yes. Those meetings are super important.

Jon: Awesome.

Bryan: I think the most important thing is there's lots of principles in DevOps. One of those is build quality in. In Scaled Agile DevOps, we recognize that there are certain things that cause poor quality, and that to build quality in, we need to relentlessly remove the things that cause poor quality. For that, we have the tribunal. In the tribunal ceremony, what we do is, after every convoy is deployed, we identify the person who created each defect and we offer them opportunities to explore other opportunities outside of our organization. That way, by relentlessly removing the things that cause poor quality, we increase the quality overall.

Jon: That sounds, again, so simple yet so profound. It's amazing others haven't thought of this already.

Bryan: Yes, and too, psychological safety is also incredibly important.

Jon: Of course.

Bryan: Because we're identifying who is creating each defect, we can automate the HR effort of offering them new opportunities outside the organization. That reduces any conflict that a manager might have by asking them to leave, and improves the psychological safety of the leadership.

Jon: That, of course, is important because psychological safety, as we all know, just trickles down.

Bryan: Absolutely.

Jon: If the boss is happy, everybody else is happy too. That's why we give the boss a new car every couple years, right?

Bryan: Yes.

Jon: Good. One of the things that really struck me, when I was first looking into SADMF-- first on background, we know there are thousands of certifications out there for all things, and there are some really popular ones among Agile practitioners. Would you say that it's true that the SADMF certification badges, at least the ones I've seen as displayed on LinkedIn, are immediately recognizable as representing a certification?

Bryan: Absolutely. They exemplify the value of certifications.

Jon: If anybody's concerned that, "Maybe my boss won't recognize that this is a certification," I would bet my last dollar that when they see that badge, they'll know it's a certification?

Bryan: Yes, that you're absolutely SADMF.

Jon: Okay. That's awesome. What if somebody listening is already certified in some other framework, should they consider getting this? They've already paid that cost, so should they consider getting this certification too?

Bryan: They've paid that cost, but our framework, just most of those other frameworks, is versioned.

Jon: Oh.

Bryan: The certifications expire when the versions change and you need to get, recertified for the next version, but again, because our framework boils it down to just the stuff that's very, very important, we can keep the cost low, which means it's less expensive as we continue to version and collect the certification fees.

Jon: That's great. [crosstalk]

Bryan: If they have a certification now, they would still have to go and recertify in their current framework. It's just that we're a less expensive option.

Jon: Great. What are the users of SADMF saying? What positive feedback have you gotten? I'm sure it's only been positive.

Bryan: Oh, executives love SADMF. One of the key things about SADMF is it enables enterprise transformation without risking culture change. That makes it easy to adopt by executives and they love it. We get rave reviews about how you easy it is to take their current system and then apply SADMF to the current system and business as usual.

Jon: You basically change a few names, give some people new titles. I love that commodore title, by the way. I would love to become a commodore.

Bryan: Yes. The commodore title-- There are several titles, the line to a hierarchy that makes people very comfortable.

Jon: That's great. We talked about the positive feedback. What are stupid idiots saying when they don't like this? What stupid crap do you hear from idiots?

Bryan: Oh, no, because the tribunal helps resolve that problem. There's no stupid idiots left because the tribunal offers some external opportunities.

Jon: That is so clever. I don't know why I hadn't thought of that myself.

Bryan: Right? It's just continuously improving the organization.

Jon: One of my favorite features of SADMF is that it provides some clear simple-to-measure metrics, which I have no doubt would make any manager's life seem easier immediately. How did you come up with these metrics?

Bryan: Oh, from experience, for example, lines of code per coder to individual developer productivity is incredibly important for organizational outcomes. By measuring how many lines of code each coder delivers, we have those key leading indicators for organizational outcomes along with defects created by coder, which is incredibly important input for the tribunal. Of course, the SADMF maturity score for how well you're executing the Scaled Agile DevOps Maturity Framework, that's a core metric that must be tracked.

Jon: I just have a couple more questions. I think I could talk for hours about this because it's such an engaging topic, but we need to keep it short for a podcast. I just have a couple more quick questions. I really like that SADMF mandates equality authority or what you call a QA team, which I thought it was just brilliant the way that that alleviates the need for coders to really have to think about user requirements. They just focus on their code.

Bryan: I agree. It increases developer productivity if they don't have to worry about is this really what's needed or is it working correctly? As long as all developers have to do is just type code, their productivity just skyrockets.

Jon: Exactly. You did mention this SADMF is versions, and I think right now your version 2.5. Do you have any big changes coming up for the next version?

Bryan: If I told you, it wouldn't be a surprise.

Jon: That's true.

Bryan: We continue to refine our framework as we go along. Of course, a major release, I'm sure, will be coming soon. Look for 3.0. Okay?

Jon: Yes.

Bryan: All of our SAD-certified 2.5 practitioners and fellows out there, make sure, keep track, 3.0 comes out, open your pocketbooks.

Jon: But that's not to deter anybody who might want to get 2.5-certified? You'll take their money twice, right?

Bryan: Oh, for sure. You've got to start. The best time to spend money was 20 years ago, but the second best time is today.

Jon: That really brings me to what might be the most important question here, and that is, Bryan, what personal value have you gotten from this framework?

Bryan: We have an international community of certified practitioners and fellows, and that has allowed me to buy at least two bottles of bourbon.

Jon: Cheers to that.

Bryan: Frameworks are stupid. Frameworks solve someone else's problems. The reality is that, honestly, everything in here is a not very far distantly removed thing that actually happens in some organization. This has come from things that I've experienced, this has come from things that friends of mine that have experienced, and if you just read and think about some of these things, you can recognize some of these behaviors and organizations, every single one of these.

None of these is based off of, "Oh, would it be terrible if somebody did that?" It's like, "No, it's terrible someone's doing this." This framework here is complete satire, but any framework is designed to solve somebody else's problem. In some cases, it's designed to solve the problem of, "I don't have a Tesla yet, so I need to sell the framework." [laughs] Frameworks don't solve your problems. What solves the problems are our organization is focused on delivering some value to somebody.

How do we improve our ability to do that? How do we remove the constraints from the flow of value delivery? How do we organize better so that we can do that without incurring extra cost and bureaucracy process, having kingdoms inside your organization and treating each other as adversaries? These add cost and reduce your value delivery. They don't help you and they don't help the end user. How do we reorganize things and remove processes that don't add value, add automation for things that are taking people with brains and having them just toil some activities that make no sense?

It's completely contextually organization. You don't need an agile certification to get this done. You need to understand what agile actually is. It's trying to overcome the problem that the requirements are wrong, or we misunderstood them, or they're going to change before we can deliver. That's just the reality of every product. It's not even software, it's just everything. If we're developing new products, those three things are true. Go watch the Simpsons episode where Homer designs the Homer car, bankrupts his brother because the requirements are wrong, or misunderstood, or changed before he delivered.

This is just the reality of it. All you need to do is say, how do we find out as rapidly as possible how wrong we are about this thing that we're trying to deliver and solve that problem? How do we get that feedback as rapidly as possible? That's the only framework you need? How do we get feedback as rapidly as possible?

Jon: I think that framework is called the scientific method, if I'm [inaudible 00:16:39]

Bryan: Maybe. In software delivery, the implementation of that is actual continuous delivery. If you want a real website, there's another website that I contribute to that's MinimumCD.org. It talks about, "These are the behaviors that are the minimum viable continuous delivery, and if you've solved the problem of why can't we do these behaviors, it will improve your organization."

Jon: Yes, and of course, that was the topic of our previous conversation a few months ago. We'll have a link to that in the show notes, of course, if anybody missed that. If your boss is addicted to frameworks, give them that one and tell them that Minimum CD is a framework. It really isn't, but maybe if you squint enough, it looks like one.

Bryan: Or you can just tell them you're SAD-certified. "Look, I have a certification with Scaled Agile DevOps Maturity Frameworks, I know what I'm doing."

Jon: Exactly. Nice. Do you have any advice, Bryan, for anybody who is in an organization that is using a framework that's not working? What can they do?

Bryan: Subvert it in small ways, and identify things that don't make sense, and ask questions. Suggest improvements, "Hey, we're in PI Planning and we're assigning stories to everybody for the next coder." What if we focused on trying to get a thing done as a team and then the team focused on delivering something as a team so that in case this person here that the story is assigned to in week five of the coder is not available, it still gets done and we're still able to deliver things. Just small improvements over time. Find more allies who want to help make things better. Don't try to tear down the framework, just tear it down a little at a time.

Jon: Really good advice. Ironically, that's the same thing I suggest people do if you're not using a framework, fix one thing at a time.

Bryan: It's amazing, if you just go, "Hey, we're going to make one thing better every single day," suddenly, things are just better.

Jon: It's complex, but it's not complicated. There are so many moving parts in building software and the complicated ones are the people you're working with. Getting better, you don't need a fancy, complicated system, you just need to improve one thing at a time.

Bryan: The truth of this is that you don't need a transformation office that's telling you that you think that this is a project where there's a beginning and an end, and this takes time. You can't just say, "We've got this scaling framework for agile, and we bought Jenkins, and next year we're going to be DevOps because we're a DevOps team." All of those things are wrong. [laughs]

Jon: Exactly.

Bryan: Organizational improvement takes time. It's adjusting the culture, it's adjusting how we work, it's learning as we go, because it's only contextual to our organization. You can't buy it. There are no silver bullets, except Scaled Agile DevOps Maturity Framework, which was absolutely a silver bullet. It'll solve all your problems, just send me money. There's enterprise licensing as well. It's work, but it's worthwhile because not only does it help us deliver things better, help our bottom line, but it also helps everybody in the organization, becomes a more humane place to work. People want to work there. You attract top talent and you retain good people because it's just a better way of working for everybody.

Jon: I agree. I don't think I can argue with you on that one. One last question, Bryan. I saw a comment on LinkedIn responding to somebody, probably you, posting about your framework, and they pointed out this sad irony that SADMF has different connotations in American English than in other dialects. Was that intentional?

Bryan: Can I tell you a little bit of a story about how this came to be?

Jon: Absolutely.

Bryan: I'm a member of the Enterprise Dojo Consortium, which is a group of people who work on Dojos in their company. It's a training for how to deliver better for teams. We had a conference in 2019. [unintelligible 00:21:29] was there. It was amazing. It was very small. There was like 60 of us there. At the end of it, we're like, "Great, we have a conference and we're talking to each other, how do we help the rest of the industry?" We had a board post-its everywhere with the ideas on how to help the industry. The website came from that and other outreach items came from that.

While we were standing there, I was like, "You know what we really need is a scaling framework," and of course, people started throwing things at me. Then at dinner, Ross Clanton, who's currently VP at American Airlines, and Ross started the Target Dojo at Target. He's deep into this. Then, I was sitting there next to Ross at dinner, drinking beer, and Ross said, "Scaled Agile DevOps Maturity Framework, so you too can be a SADMF," and I went, "Ross, that's brilliant." As soon as I got home, I registered the URL, and that was 2019. I've been very busy, but this past year, I started working on this content, and so all credit to Ross Clanton for that idea.

Jon: Thanks, Ross. All right, Bryan, anything you'd like to add before we sign off today?

Bryan: Just repeat, the rules are how do we make things better? That's the rules. The reality is that we're probably wrong, and the sooner we find out that we're wrong, the faster we're not wrong. Just focus on helping people instead of trying to impose rules on people that don't work.

Jon: Great. Well, thanks again, Bryan. The website is scaledagiledevops.com. You can also visit MinimumCD.org. How can people get in touch with you if they're interested?

Bryan: They can reach out to me on LinkedIn. I'm active out there ranting or putting my ideas out there. I also have a blog on Medium. It's a five-minute DevOps. The URL's clunky because it's my old user ID at Walmart, but it's bdfinst.medium.com.

Jon: All right I'll put a link in the show notes. Cool. Well, thanks again, Bryan. I hope to talk to you again soon.

Bryan: Yes, absolutely. Thank you, Jon.

Jon: Cheers. Bye.

[music]

[00:24:17] [END OF AUDIO]