Professional Scrum and DevOps with Richard Hundhausen

[00:00:00] Richard Hundhausen: Scrum is a really, as you know, it's a really good framework within which a team can try things. There might not be anything new coming with Scrum but there's gonna be a parade of complimentary practices.

[00:00:15] Neil Benson: Good day and welcome to Amazing Applications, the podcast for Microsoft Business Apps builders who wanna build amazing, agile Dynamics 365 and Power Platform applications that everyone loves. Hi! My name is Neil Benson. You'll find show notes and a transcript for this episode at Amazingapps.show/136. I hope you'll consider following the show on your favorite podcast player so you don't miss an episode. And if you use an iPhone, and I know that lots of listeners do, it would be great if you could leave a rating and a review for Amazing Applications in the Apple Podcast player. It really helps other business apps builders discover the show and join our movement to build better applications.

[00:01:00] My guest in this episode is Richard Hundausen. He's from Boise in Idaho in the US. He's a professional Scrum trainer and a DevOps trainer. And as you'll hear, Richard doesn't have a background in Dynamics 365 or the Power Platform but he's no stranger to developing apps on Microsoft technology. In fact, he was a Microsoft MVP in Developer Technologies for 14 years and a Microsoft Regional Director. He's recently published a book, Professional Scrum Development with Azure DevOps. Richard was the second Professional Scrum Trainer at Scrum.org and he's the co-creator of the Nexus Scaled Scrum Framework. We have a fascinating discussion covering the use of Scrum, like when to use it, how to scale Scrum and when to scale it, how to find product owners when you're building Business Applications. We discuss the merits of big bang releases versus incremental releases, product thinking versus project thinking, and even when it's a good idea to have a project manager when you're using Scrum. Richard is full of great stories and very practical advice. I hope you enjoy this episode as much as I did. Here's Richard Hundausen.

[00:02:15] So, I'm here today with Richard Hundausen. Welcome, Richard, to the Amazing Applications Podcast. It's great to have you on the show.

[00:02:21] Richard Hundhausen: Hey, thanks, Neil. Finally get a chance to talk to you. I'm looking forward to it.

[00:02:24] Neil Benson: Yeah, me too. So, let me — for the folks that don't know you — let me give you a quick introduction and build you up here and then we're gonna dive into your origin story and find out a lot more. But you're in Boise, Idaho. Is that right?

[00:02:35] Richard Hundhausen: Boise, Idaho, yeah. We're in the Pacific Northwest of the US.

[00:02:38] Neil Benson: So, what time is it for you at the moment?

[00:02:40] Richard Hundhausen: It's 1:35 in the afternoon.

[00:02:43] Neil Benson: Okay.

[00:02:43] Richard Hundhausen: On a Thursday. So, it's what down there? Is it Friday already?

[00:02:47] Neil Benson: That's right. It's Friday here. I'm from the future. It's 6:35 in the morning. And you're a professional Scrum trainer. You're a DevOps expert as well and co-creator of Scrum.org's Nexus Scaled Framework, which I'd love to dive into. And your own business I believe — Accentient, is that how you say it?

[00:03:03] Richard Hundhausen: Yep. Accentient started with a business partner back in the early 2000s, primarily around training and consulting on software development, app lifecycle management. And I got the company in 2006 and since then, DevOps and Scrum since about 2009.

[00:03:22] Neil Benson: Great. And you were a Microsoft MVP in Developer Technologies for the longest time and a Microsoft Regional Director as well.

[00:03:28] Richard Hundhausen: Yeah, correct. I've been a software developer — I don't wanna say this out loud, but gosh — since the seventies. Getting paid for it since the 80s and found that in the 90s, it's kind of nice break now and then to stop and teach a class. So, I found that I had a knack to teach software developers new tools, new frameworks, new languages 'cause it turns out, Neil, that the secret to teaching software developers is just tell them what they don't know. Don't tell 'em anything they already know. Give them lots of sample code, places to go to get their questions answered, like a Stack Overflow, some repos on GitHub, and then just shut up and let them play with things.

[00:04:03] Neil Benson: Cool. The trick there is knowing what they don't already know before they step into your class, yeah.

[00:04:08] Richard Hundhausen: Which is really hard in the virtual world. In the in-person world, you can see that like question mark floating over their heads. But when the cameras are off, you've got no idea if they're getting it or not.

[00:04:17] Neil Benson: So, just before we get started, one of the things I'd like to know more about 'cause I think I heard in another podcast, you've got five kids at home. So, I'd love to know what your favorite Lego set or Lego theme is.

[00:04:29] Richard Hundhausen: Favorite Lego set. Well, we have so many Legos. We've got probably three or four of the large bins full of just raw Legos. But also, my boys got all the Star Wars ones up on shelves and we got a nice cool Vespa scooter for my girls.

[00:04:46] Neil Benson: Oh, nice.

[00:04:46] Richard Hundhausen: So, yeah, we're doing lots of Legos in this house and I'd say probably the big Millennium Falcon was my favorite.

[00:04:52] Neil Benson: Oh, I haven't got the Millennium Falcon yet. It's on my list. Great. Cool. I love illustrating my Scrum presentations with Lego mini figures, so we've got Wonder Woman as a product owner. A lot of my great product owners that I've ever worked with have all been women, so we've got Wonder Woman as our product owner. Superman is the Scrum master because the initials match and then we've got lots of other superheroes in the team as well. So, it's been fun.

[00:05:16] Richard Hundhausen: Oh, that's awesome. Quick story. Sprints — jumping right into Scrum here 'cause that's how my brain works. Sorry. You invited me on here. You get the whole package. Two-week sprints, 26 of 'em in a year, what else has 26 things in it? The alphabet.

[00:05:31] Neil Benson: Right.

[00:05:32] Richard Hundhausen: I don't know if the Australian alphabet has 26 letters. I'm guessing it does.

[00:05:35] Neil Benson: It does.

[00:05:36] Richard Hundhausen: So, I've worked with some teams before that instead of sprint one, sprint two, sprint three, they went through the alphabet and they named them after superheroes.

[00:05:44] Neil Benson: Oh. 26 different superheroes, each beginning with a different letter.

[00:05:48] Richard Hundhausen: Yes, and it's, it can be done. Wikipedia to the rescue. On odd years, they went with supervillains. So, I happened to be there I think in 2019, and we were arguing whether Venom was a supervillain or a superhero and I think ended up being a villain, so it fit the bill. But, yeah. I love the superhero themes. It works.

[00:06:07] Neil Benson: Yeah. Cool. So, tell me about your Scrum origin and how you got started with Scrum. And also I'd love to hear how the MVP award weaved into that as well. So, tell us how you got started.

[00:06:17] Richard Hundhausen: I've been a Microsoft fanboy since the mid-90s. You know, Visual Basic 4.0, Visual Basic 5.0, Visual Basic 6.0, SQL server 6.5. 6.0 didn't last very long. 6.5 came out because the internet came out and there was the internet connectors and all that was SQL. So, I was a VB SQL developer and a VB SQL instructor. Microsoft Certified Trainer since about '96. And enjoyed it. Enjoyed it. And I stayed very tight with the Visual Studio product and product group. In 2004, I'd written I'd co-authored a couple of study guides for the VB certification test back in the late 90s and then I just approached Microsoft Press and said, "Hey, I'd be interested in writing a book on Visual Studio 2003 Enterprise Architect Edition." It's $10,000. Everyone's buying it. They don't even know what they're getting. I'd love to write a book that says, "Hey, you just spent a bunch of money. Let me tell you what it does. And they came back and said, "No. We'd rather you write a book on Visio. I said I don't wanna write a book on Visio. They said, well, the Office group's got lots of money. You can just jump right in and write us a book on Visio.

[00:07:18] Neil Benson: What?

[00:07:19] Richard Hundhausen: Which any tool that can help model your databases and also help you landscape your backyard is just not for me. Too versatile. So, he said, "Well, hold on a second. I just heard about something code-named Burton, like Burton snowboards. Let me get back to you." So, this was 2004 I think it was. Turns out, Burton was the code name for Team Foundation Server. Microsoft had hired Brian Harry. He brought Source Safe over. Source Safe kind of morphed into fused with Source Depot and some of the other internal tools. And they came out with this offering I think in part to compete with Rational that was just purchased by IBM back then.

[00:07:56] Neil Benson: Yeah.

[00:07:57] Richard Hundhausen: Code name Burton ended up becoming Team Foundation Server 2005 — the first edition, first version. And then the ALM tools, back then it was called SDLC. In Visual Studio, there was the test edition and the architect edition and the database edition, the data dude. So, I hung out with the SDLC tools. I created Courseware. I would doing talks at TechEDs on TFS and customizing it. And, as you know, when you're talking about tools, process naturally comes into it. There's right ways and wrong ways to work as a team with the tools that you're using. So, I gravitated toward Agile. I'd heard about it. I'd learned XP in the late 90s. Hadn't really worked with any teams doing XP but started running into more and more teams doing Scrum. So, at about 2007, I found myself, you know, talking about how to do Scrum and TFS. I'd used some of the Scrum for team system templates that were out there and actually helped Microsoft create the current Scrum process in Azure DevOps in 2010. So, that led to a phone call in 2009 from Ken Schwaber, co-creator of Scrum said, "Hey, did you happen to read Martin Fowler?"

[00:09:05] Neil Benson: Martin Fowler, yeah. Okay.

[00:09:07] Richard Hundhausen: Martin Fowler wrote a blog post simply titled Flaccid Scrum. People are going and taking the two-day class. They're bringing their ticket back. Look. I'm a shiny new CSM and nothing's changing. No software's getting done. Releases are delayed, yada, yada. So, Ken said, "We need to address this by going at the developer, not the Scrum master, but the developer and the development team." 'Cause back then it was still called the development team. This was pre-Scrum guide, right? I think the Scrum guide was just coming out. So, I call this the Dark Ages of Scrum because Scrum was whatever you learned in the last class from the Scrum trainer that you had or Ken's last book that you happened to flip through and — gosh, was it called an event or was it called a ceremony? Was it called a standup or a daily Scrum? And it was like —

[00:09:51] Neil Benson: There's been a few changes of terminology, yeah.

[00:09:53] Richard Hundhausen: Exactly. And the terminology being all mixed up made it hard to really lock in on what was and what is not Scrum. So, started working with Ken. We mapped out what a Scrum developer program training and certification would look like. Ken fell apart with Scrum Alliance. There's a whole story there. I won't get into that. It's available at Scrum.org to some degree if you wanna read about the origins of Scrum.org. But Scrum.org rose out of the ashes, replacing Certified Scrum with Professional Scrum. And that's Scrum according to the Scrum guide with a focus on empiricism and a focus on the Scrum values and a focus on continuous improvement, which you can't do Scrum without all of those and like what some people in the world will say.

[00:10:33] Neil Benson: I've done both my CSM with the folks over at Scrum Alliance and Professional Scrum Master as well. So, a foot in both camps. These days, I prefer Scrum.org's focus and their mission, so focusing on that stuff so.

[00:10:47] Richard Hundhausen: Yeah, it's nice to hear that. So, yeah. 2010-ish, I was a Professional Scrum Trainer. I was the first PST, you know, aside from Ken who, as soon as he had the idea in his head, he became PST number one 'cause he's Ken Schwaber. And it's been a good ride, Professional Scrum. I don't teach all the classes. I'm probably not your guy for product owner. I'm probably not your guy for, you know, some of the UX stuff. But I love developer. I love scaling. I love, of course, the intro class, Kanban, and to some degree the Scrum Master bits.

[00:11:15] Neil Benson: I'm fascinated 'cause I haven't taken the Professional Scrum Developer course or certification yet. I have taken a Professional Scrum Master and Professional Product Owner. There's about 80% overlap in those two courses. They're both very introductory to Scrum. There's a bit more of an emphasis on the backlog, on refinement, on prioritization for product owners in the PSPO class, as you might imagine. What's in the developer course that you wouldn't learn as a Scrum master in the PSM course? Where's the focus?

[00:11:44] Richard Hundhausen: So, it's the only three-day class Scrum.org offers, and it's essentially an immersion into Scrum. There's three or four sprints where you're actually on a technical team, working in code, using your own IDEs of choice, using your own pipelines, and all that if you wanna set it up. We have a common case study with I think 10 different languages and we can even mix it up in class. I've run classes recently where we've had two Java teams, a C# team, you know, and over here is a Python team. And they can all have the same backlog and they all have kind of the same-ish starter to bring to market. But we're learning topics in the PSD program. It's now called APS-SD. It's Applying Professional Scrum for Software Development. But the certification is still called PSD, Professional Scrum Developer. And we're learning things in there — how to meet the definition of done, how to work as a team, considering writing tests first — all the classic XP things come to bear.

[00:12:35] Neil Benson: Oh, sorry. Okay. So, more of the technical practices. A lot of which are borrowed from from XP, right?

[00:12:40] Richard Hundhausen: Oh, yeah. And that's because they work. I'm a huge fan of XP. I just would prefer them sitting as complimentary practices on top of Scrum as opposed to just doing all the bits of XP.

[00:12:50] Neil Benson: That's very cool. When we think about applying Scrum to Microsoft Business Applications, one of the challenges I have the community has is Scrum isn't always the right choice of framework or approach because a business application can be a complex mission-critical enterprise application that it takes a big team of people many years to deploy or it can be a simple productivity app that I can build for my team in a couple of days. And so, that we run the gamut from very simple up to extremely complex. And Scrum I believe is great at helping me understand, break down, iterate on complex work. And it's maybe an overkill approach for simple work straightforward work where the requirements are pretty well known, where I have a good idea of what the solution's gonna be before I start building it. And teams don't quite know where to apply Scrum, where's — what's a good set of criteria that I should check before starting a new project with a new team and going, let's use the Scrum framework as our approach for this project? What are your guidelines for helping a team decide when to adopt Scrum?

[00:13:55] Richard Hundhausen: That is a good question. It's not an easy one to answer. I actually wrote a blog post a few years ago for Scrum.org. I can get you and put it in the show notes. But I just go down through a series of questions, maybe ask five or six questions. If the majority of the answers are yes, I would suggest Scrum. First of all, I'm not one of these,h ey, let's do Scrum for everything. Let's get all of the accountants in the building following Scrum and doing sprints. I have met organizations that every department is on the same sprint so that the CEO can feel good about we're all goal-oriented and on the same cadence here. But you gotta wonder if some of those departments are just going crazy.

[00:14:33] Neil Benson: Swearing uphill.

[00:14:35] Richard Hundhausen: So, some of the questions I would ask is number one: are we building a product? I don't know how it is with your clients, but I'm constantly trying to get them to switch from project minded thinking to product minded thinking. I said, you can keep the project thinking. We're just gonna start calling them sprints. It's a timebox — you know, period of time that has a goal that you can work on items that you want to in that little mini project. But are we building a product? And I'm a software person, so primarily, I'm working with software teams and it's pretty easy to figure out what the product is there although not always. Sometimes, you have to ask the users or the codebase or the developers and you might get different answers as to what the product is. So, there's actually some workshops I've led to start as broad as possible and narrow down. It could be that the organization itself is the product. I know that sounds weird. But most banks, for example, no matter what we're doing, the product is an account. Just an account of account, you know, whether it's a loan account or a savings account or whatever. So, are you doing product development, you know? If you're just trying to do a list of work that may or may not be complex, that's great. But are you building an increment? Can I take the work from sprint five and is it additive to the work I'm gonna do in sprint six?

[00:15:45] Two: do you have a minimum number of technical people? The old Scrum guys were pretty cool. You needed at least three people to be on the team, at least three developers. I still kind of use it as a rule of thumb. If it's just you and you're working on a product in your garage, I don't think you need Scrum if you're just a team of one or two people. You can just talk to each other. You can know in real time what the risks are. But if you have more than 10, which is the kind of the new upper limit of the Scrum team, you can still do Scrum. You just might have a couple different teams.

[00:16:12] Neil Benson: So, I've worked at both extremes. I've worked on a Scrum team with one developer to start with then it became two. It was a little — it felt very odd. Kind of worked but it did feel strange. And there was reasons why we wanted to use Scrum 'cause we wanted to — it's all about educating the organization. Other bigger teams are gonna adopt Scrum. We were kind of a pilot. And then, I've run other projects, other or built other products where, you know, we were at the upper limit and I had to split into multiple teams and that's an interesting challenge I'll get into as well. You've got some expertise there. So, there's a couple of good tests. Anything else that people should check themselves?

[00:16:45] Richard Hundhausen: So, the work itself. Is the work itself like big enough and complex enough that you need a team of people to work on it? And this is where, I don't know when it comes to the low-code/no-code business apps world. If you really need two or three people working on these features, creating this capability, and maybe you do, you know? I get asked a lot, hey, should we use Scrum on our SAP system? I'm like, what do you develop in SAP? Well, sometimes we'll like upload some new like forms to type into or something and then we run through some sample data. I'm like, that sounds kind of like code and test. So, maybe. But it also might be overkill if it's all stuff that one person can do in four hours and you're done, gosh, I don't know that you need Scrum for that. So, you know, the nature of the work.

[00:17:31] Neil Benson: We definitely have low-code/no-code folks who've got expertise in composing business applications rather than, you know, cracking open Visual Studio and developing things from scratch. But we're trying to create such a large volume that we have three or four of those people in our teams and we still need to analyze the requirements a little bit, design which components are going on, how they're gonna work together. And I would need to test them and validate that they work and verify that they can be deployed into production. And we still need developers there to help us when we reach the limit of what the low-code application builders can do and we can extend that with custom code and we need to integrate with other systems or migrate data. And quite often, a code first approach is quicker than a no-code approach when it comes to integration and data migration. So, yeah. We've got these fusion teams composed of lots of different skills, just like any other software development team, I think.

[00:18:20] Richard Hundhausen: Okay. Yeah, so it sounds like you've got a pretty well-set up cross-functional team and work that requires that. One final one I was just thinking of: is the majority of the work plantable? Do you have a backlog? Do you have a product goal you're trying to chase down that you can take concrete steps towards with sprints? Or is it just coming at you like, hey, fix this bug. Hey, here's an outage. Hey, do this custom script real quick for the boss, you know? Or is it plantable work? So, the majority of the work you have is plantable. It's complex. You're building a product. You've got enough people. I'd say, you know, let's party on and do Scrum.

[00:18:53] Neil Benson: Worked on a couple of products where we've done several releases into production. We're all live, all the users are happy, and now, we're transitioning into the kind of a support environment and we've tried to keep going as a Scrum team but it just doesn't work. The work is not plantable, right? Or we're just dealing with how many of these bugs can we get fixed in the next sprint? Well, what's our sprint goal? It's to fix these bugs. Like, oh, that's not really a sprint goal. We're beginning to fall apart. And so, we transition into Kanban at that point and manage the flow of work.

[00:19:22] Richard Hundhausen: Which is unfortunate 'cause you've got a, it sounds like you've got a well-oiled machine there. You should get a different product, different product backlog and keep rolling. And, you know, you could still make some space in your sprints for supporting the old system. But I talk about this. Once you become a high-performance professional Scrum team, don't disband it. Don't break it up like little seedlings and try to plant them in other teams. Keep them together, keep them happy, keep them fed with high quality work, you know, in the backlog.

[00:19:49] Neil Benson: What tends to happen in our world is that a Microsoft customer will hire us to build this application. We end up becoming a high-performing Scrum team. We're all working together. We've been there for a year or two and it's gone really well. But the customer has achieved their goal of developing this application, releasing it into production. They've maybe got some of their own team now supporting it. And as a Microsoft partner, I wanna take my great performing Scrum team and just go find another customer with a similar challenge and plunk them down there and do the same again for somebody else in a similar industry with a similar challenge and keep that team together. And that's what I've been able to do for the last four years for three or four different customers is take the same Scrum team that I've got and we just keep rolling.

[00:20:26] Richard Hundhausen: Yes. You know what I'm talking about. You wanna just keep that rhythm, keep that flow.

[00:20:30] Neil Benson: Right. Yep. And when we think about what's our definition of done, well, let's take a look at the one that we've used the last three years. Do we need to tweak it for this environment, for this customer, for this challenge? Oh, yeah. Let's add a couple of extra criteria to our definition of done. How do we think about our DevOps approach here? Well, they wanna manage their environments in this way and they wanna use, we use Octopus Deploy over here but here we're gonna use Azure DevOps. So, similar kind of pipelines but we're just gonna use a different tech.

[00:20:53] Richard Hundhausen: You got a good thing going there. I wish more companies would get that.

[00:20:56] Neil Benson: I think about that interplay between Scrum and DevOps. There's some people saying we don't need Scrum anymore. DevOps is the future. It's a culture as well as a set of tools and technologies and we can just focus on continuous integration, continuous development, and a couple of extra technical practices, you know, TDD and those things. And let's not bother with with Scrum but focus on DevOps as an approach instead. Is there any validity to that?

[00:21:21] Richard Hundhausen: Kind of. I hear it the other direction as well. First thing is I always say is what is the definition of DevOps? Everyone's got a different definition. Is it — it's the union of Dev and Ops. I'm like okay. Most of my clients can't even get Dev and Test together yet. Why are we jumping ahead to Ops? So, I like Donovan Brown. He was the sort of chief evangelist of Azure DevOps at Microsoft. I'm not sure what he's doing these days but it was the, you've heard of People, Process, Tools. That's a common alliteration. Well, he made it more of an alliteration: People, Process, and Products because also Microsoft sells products to enable the continuous delivery of value to the users. And I'm like, gosh. That sounds like Scrum. So, back in 2010, 20 11 when the D-word started emerging, I'm like this is just professional Scrum with specific XP practices that the team chooses and kind of an adherence to technical excellence, which is in the Agile manifesto. There's nothing new about technical excellence. Personally, I think Scrum and XP and people and culture is hard to change, as you know. So, I think there was a whole movement to like let's just go get tools to solve it for us. So, to me, DevOps sounds like tool vendors are here to save the day.

[00:22:34] Neil Benson: Yep. Or just buy Jira. It'll all be okay.

[00:22:37] Richard Hundhausen: Just buy Jira or just buy Microsoft. I mean, we're fanboys but we gotta admit that they did a cool thing. They stuck Azure and DevOps in the name, so you're like, oh, wow.

[00:22:46] Neil Benson: Yeah, that's so smart.

[00:22:48] Richard Hundhausen: Maybe you have a few disenchanted Amazon people going, oh, I'm not gonna use Azure DevOps. But then they figure out that it works pretty well for them or GCP or whatever. One more thing is if you look at the Three Ways of DevOps, that's just Scrum. You know, one is establishing and shortening those feedback loops. So, not just time to market but, you know, cycle time and fast feedback, fail fast — all those things we do in Scrum. Then also, getting that feedback back so that the product owner and the Scrum team can work on it, as well as enabling a culture of learning. That's the Scrum values. That's the retrospectives and focus on continuous improvement. So, when I hear DevOps, I think this is professional Scrum with XP and technical excellence.

[00:23:28] Neil Benson: And a product underneath that just to help us manage our work, right?

[00:23:31] Richard Hundhausen: Sure. But honestly, at scale you can probably just use Mural or Miro or one of these tools and maybe just have wiki or an online spreadsheet. You don't — I'm a fan of the less framework, large-scale Scrum Craig Larman and Bas Vodde, who I've met both several times. And they've always said avoid tools that have the word "Agile" in its name. Jira claims to be an Agile project management tool. Okay. Get rid of it. Let's just go with something completely lightweight that we can do however we want with.

[00:24:03] Neil Benson: I've definitely used some very lightweight tools that I really enjoy. tinyPM was one. Pivotal Tracker's another, yeah. And they just don't have all the features that these enterprise tools have and it's just a beauty in the simplicity and a focus on the work and everything else is a noise we can just —

[00:24:20] Richard Hundhausen: Well, and you being in Oz, you have to use Jira, right? That's the rule, isn't it?

[00:24:24] Neil Benson:  I was doing a project, a CRM project, for the University of New South Wales down in Sydney and I was having a crack at Jira 'cause I'm not a Jira fan. It's got a user interface its mother couldn't love. And I think I probably made that kind of comment and the product owner said I think.

[00:24:38] Richard Hundhausen: Who was in the audience.

[00:24:39] Neil Benson: Yeah. She said I think you better keep your voice down 'cause the founders of Atlassian paid for the building that we're sitting in.

[00:24:44] Richard Hundhausen: Ouch.

[00:24:44] Neil Benson: They were former students at the university and huge benefactors so.

[00:24:50] Richard Hundhausen: I love that. I was doing a conference talk somewhere that's been 10 years ago but I was talking about like TortoiseSVN or something like that, some, you know, Windows shell interface. I'm like, yeah, you could always download and install that. It works pretty well. And someone in the back row's like, "You're welcome." The developer who built it was in the talk that day. Kind of fun.

[00:25:09] Neil Benson: At least you said something nice about it. Always works. In the business apps community, we have a couple of challenges applying Scrum that — I'm not saying they're unique to business applications but they're definitely quirks and I'd love your perspective having worked with hundreds or thousands of teams and professionals at this point. The three challenges that I get asked about are our product owner is a domain expert. That's somebody from sales or marketing or HR or operations. They're a manager or an executive. They've got the authority. They've got the vision. They understand the business processes and the existing systems. They're gonna be a great product owner except they've never been a product owner. They know nothing about software development. They have never heard of Scrum. How can we help them become great product owners? Have you seen product owners in that sense work? Or is it better to go and find a career professional product manager who's done this lots of times before, who doesn't have maybe the domain expertise or knows the existing culture and people in politics? Which do you think makes a better product owner?

[00:26:06] Richard Hundhausen: It's not that easy. Let me just tell you some experiences I've had. Product owners who are too technical — maybe they used to be developers or maybe they created V1 of it and they want to hang around because it's still their baby. As long as you can keep them out of the code, if you can keep them focused on the "what" and stay out of the "how," they can be successful. I like what you said, though, is the person you described has vision and authority. To me, that's table stakes for a product owner. You know, the whole organization's got to believe in them and let them make their own decisions. So, the first two things sound pretty good to me. Now, if they're trying to push down, here's what I want and here's how I'd like you to do it, that gets to be a problem, like that fine separation of what and how. I have worked with teams who — so, quick story. It was a pharmaceutical company in Tucson. They had nine product managers. They were client relations managers. They were building backend software for CVS, Krogers, Albertson's, and, of course, Walmart. So, of the nine, there was, you know, whenever Walmart wanted something, they would they could literally stop the sprint. Walmart wants this, you know? Stop the sprint. This just became your priority one, you know? Go do this. And everyone was like losing morale. And it was great because Lord of the Rings was popular at the time, so we called them the Nine Ringwraiths and we needed to hire a product owner and give them the ring of power over those nine ringwraiths. And they literally went — I think they found some tester in the organization 'cause testers had pretty good domain knowledge. Didn't have any particular politics; didn't — couldn't be swayed by any of the nine ringwraiths. They gave him the backlog. They gave him authority. Sent him to some Scrum product owner training and proceeded.

[00:27:51] Neil Benson: Very cool. I love the analogy of the ringwraiths. Amazing. Okay, so you reckon we can work with the whoever's gonna be in that hot seat as a product owner, teach them the Scrum framework as we go along, help them understand the empiricism and getting feedback.

[00:28:05] Richard Hundhausen: And we changed roles to accountabilities in the last Scrum guide and people are like whatever. I'm still calling them roles. The big thing I've been explaining that to people is you can still call the person the product manager. You can still call the person Bob. It doesn't matter what their name or their title or their role is but they do take on the accountability of maximizing the value of the product by the work of the Scrum team and other things like that, the voice of the stakeholders. And as long as the whoever it is you're talking about has that mentality, then great. Yeah. Technical skills, I don't think they need them.

[00:28:39] Neil Benson: I think it's better if they don't, yeah.

[00:28:41] Richard Hundhausen: Yeah. I think it's better if they don't. Remember to, they don't have to be the one that writes the stories or drags the things around in Azure boards or does the typey typey. That can all be delegated, but the product owner's accountable for what's in there. Yeah.

[00:28:53] Neil Benson: The switch from roles to accountabilities threw me a little bit in 2020. It's mostly because — not for product owners. That fits really naturally as an accountability. But it's mostly for Scrum masters 'cause there is a lot of people with a job title of "Scrum Master" and that's maybe confusing and it's just it's a byproduct of Scrum having been around now for 20 years. But I enjoy working with teams where one of the developers just stands up and say, hey, you know what? For this next couple of releases, I'll fulfill that accountability and I'll help facilitate the team. And I might have another accountability as a developer. And, you know, sometimes there's a bit of that. But you don't have to be a career Scrum master to hold that accountability.

[00:29:34] Richard Hundhausen: No. The only issue with that — I'm with you. For years and years and years, I was like just let one of the devs do it as a part-time thing and obviously, if any Scrum mastery things pop up, that needs to take precedent over writing code or running tests or whatever. Except that it's very clear in the latest Scrum guide that one of the accountabilities is to the organization. And I see this as lacking in a lot of Scrum teams. That Scrum master there may locally optimize their Scrum team and get their product owner squared away and the developer squared away and do a good job of being a, you know, a sheep dog, keeping the bad things away. But are they working with the organization to help them understand and enable empiricism? Are they working with the organization to lead workshops? Like, hey, we're doing Scrum now. What are your touchpoints? How does this change things? If you're having a dev do part-time Scrum master work, I don't know that they're going to even have time or interest or maybe they're not even extroverted enough to go and talk to the bosses. So, that's the only risk there is that the attention to the org might get missed if the dev's doing part-time scrum master accountabilities.

[00:30:36] Neil Benson: Alright. All makes sense. One of the other challenges that we have with business applications is this notion of a big bang release. We're coming in to replace the Oracle or SAP accounting system. We wanna release iteratively and frequently into production and get feedback. But my CFO is gonna crucify me if I try and replace accounts receivable this year and accounts payable next year. That's not gonna work. We're gonna have to wait until both AR and AP are done before we can release. So, we're gonna have to package up bigger releases less frequently and go live with those when it makes sense. But it might be a release every year, not every other sprint. Is that an acceptable approach? Can we still call ourselves a Scrum team when we're doing reasonably large releases into production very infrequently as long as we're, for example, releasing into pre-production environment every other sprint to get that kind of feedback? What's your take on those big releases?

[00:31:32] Richard Hundhausen: Sure. I would say that I have a feeling that your executive is gonna crucify you if it sucks, even though it's all released together. So, you could get mini crucified along the way or you could get majorly crucified if the big bang sucks as well. "Sucks" is not a Scrum term, by the way. So, when you release, how often you release is not even part of Scrum. There's nothing about release in the Scrum guide. The closest we get is saying that the increment is potentially usable in software that's releasable. But it also doesn't exclude being released continuously. Finish a PBI. Meet the definition of done. It goes to production. Feature flagged off if you want. So, I would — I don't know enough of the technicals of what you do, but is it possible to feature flag things? Like it's deployed but it's feature flagged so only 10% of the people, you know, the users that we trust that are in the beta test group see the new thing and everyone else sees the old workable thing.

[00:32:28] Neil Benson: We definitely have some challenges like if you're deploying a call center application to give a new application to 10% of the call center operators is challenging because there are, there's gonna be business processes missing from the release one of the new application and there's gonna be integrations missing to other, you know, inventory systems or whatever else they need to do their jobs. So, we have to try and balance it. And certainly once we're in production, we can rapidly roll out new features sometimes behind a flag or with a security rule. Say you don't have access to this until we've given it. Got some feedback from some users over here who have the appropriate security rule who've got the new feature, so we can do some of that stuff.

[00:33:07] Richard Hundhausen: Well, and Microsoft does that with the rings. You know, there's a Ring 0 and Ring 1 and Ring 2. And you can opt into the early adopter rings and, you know, if you've got that much time and patience. But sometimes, things break. You know as well as I do, the only way Scrum works is with feedback. If you can still set it up in a way where maybe it's not released but it's runable in a test environment to where actual people can give you feedback on it, not just devs to each other, although that's valuable, too, then I, you know, as long as you're taking that feedback and it's got close enough sample data to the real stuff, that might be as good as you can get. And then as the modules come online, then you can decide when you wanna release them all together. But you know that they meet the definition of done all along the way and the feedback comes in and then your product owner can make the decision. Yeah, I think there's enough goodness in here to actually release it to production. I think it's ready.

[00:33:55] Neil Benson: I'm switching gears a little bit. One of your — you're the co-creator of the Nexus Scaled Scrum Framework. I've had to work in environments where we've had multiple teams. Sometimes, it's my Dynamics 365 team. There's been a systems integration team building logic apps and also things to do integrations. Then there's been another vendor and another in internal team doing something else. So, three or four teams, we've gotta coordinate all of our work. Nexus has been a blessing for coordinating that kind of work. We're trying to use the Nexus framework but not all of the teams are necessarily practicing Scrum. Not all the teams are doing things the same way. For example, when they get slightly different definitions of done, they've got slightly different estimation methods, and that was a bit of a torture. But coming together in the Nexus integration team and applying those principles and a little bit of extra framework on top really helped us manage dependencies and map those and reduce them and get more work done. So, tell me about the origins of the Nexus Scaled Scrum Framework and where it's headed next.

[00:34:53] Richard Hundhausen: Sure. So, prior to what the mid-2010s, if you wanted to scale Scrum, it was called the Scrum of Scrums. And most of the world got it wrong. They said that that's where the Scrum masters get together and synchronize stuff. A good friend of mine, Charles Bradley, who I think I learned a lot of professional Scrum ideas from him. He's actually over in the Denver area. He did a blog post called "The Much Maligned Scrum of Scrums." He revisited it and said, by the way, just like the daily Scrum is for developers, the Scrum of Scrum is for developers. And it's messy and it's technical and it's tactical and it's not a status meeting. So, you know, all those things come out at scale. What was the origins of Nexus? Well, it was safe. I'll just be clear. Scaled Agile Framework came out and Ken immediately saw it for what it was. I'll let your listeners go and look for the article "unSAFe at any speed" by Ken Schwaber. But essentially, it was anything but Agile, you know? Here was one of the co-creators of RUP repackaging up.

[00:35:57] Neil Benson: Well, it is. It's just a rational unified process — a wolf and sheep's clothing, right?

[00:36:01] Richard Hundhausen: That's what I think, too. I'm trying to be nice here. But Ken saw it for what it was — a giant, complex thing that cares more about alignment through all the programs and enterprise than it does about enabling the teams. I forget what we're working on at the time at Scrum.org. Some — oh, I think it was the Agility Index and some of the EBM stuff, the early, early days of that. And we just put it on a shelf and we said, look. We gotta come out with something. There's gotta be a Scrum.org answer to SAFe. And we started putting together this thing. Ken came up with the name Nexus, you know, an intercommunication pathways of communication with a bunch of people or things, which we didn't like the name because everything was called the nexus. Google had a phone called the Nexus. My favorite nexus reference is the replicants in Blade Runner were called Nexus-6. So, anyway, if you look at the Nexus Scrum Framework and kind of squint a little bit, it's just Scrum. The process model looks very much similar. We added an extra event. We made cross-team refinement required because, well, it's like you said. The purpose of scaling framework is to identify and address dependencies. It's not about getting your architectural epic runways aligned with your program level this to get your team level that. No. It's just let's find these dependencies, which are killers at scale. And by the way, dependencies are not just technical dependencies. They could be people dependencies, domain experience dependencies. They could be, hey, team two doesn't have access to team three's repo. Security dependencies. But light those things up and don't just stare at them but mitigate them. So, that's where our cross-team refinement comes in. That's why we have the pre-daily Scrum. That's why we have the pre-sprint retrospective and the pos-tsprint retrospective so that we can do this bottom-up intelligence so as a nexus, as a team of teams, we can improve overall. And it's pretty simple. It's just Scrum. Nexus is just Scrum.

[00:37:59] Neil Benson: Yeah. That's what I love about it. I didn't have to learn anything new. I read the book and went, okay. We'll just add an extra ceremony here. We get technical people. I got a representative from each of the team or a couple of people. Maybe once or twice per sprint, as often as we need to, figure out what those dependencies are and come up with a plan for mitigating them and getting rid of them. Stick that thing in your product backlog and make sure you do that before the next sprint and when do you need that API? Okay, well, aim to have that done by sprint four so you can build a user interface on top of it in sprint five and we're all good.

[00:38:24] Richard Hundhausen: Yeah. It's funny how many times I've flown across the country to just tell people to talk to each other. It's like, well, we brought you in as a Scrum expert. Tell us what we need to do. Well, why don't you get together and talk to each other? Brilliant. Thank you. You're worth the money. I'm like, you're welcome. Nexus is no different. Just talk to people at scale. Talk to the right people.

[00:38:44] Neil Benson: So, when's the right time for a larger team to consider adopting some of the Nexus or at least a part of it adopting Nexus? Is it when they're at that 10-people stage and they wanna go faster and they wanna grow the team beyond kind of 10 people? Okay. We're gonna think about splitting the team.

[00:39:00] Richard Hundhausen: Our guidance is three teams or more.

[00:39:03] Neil Benson: Right.

[00:39:03] Richard Hundhausen: Two teams, they can just work and do a Scrum of Scrums, the proper way to do Scrum of Scrums, and keep synchronized that way. The complexity starts to hit at three teams. So, Nexus is really intended for three to nine Scrum teams working on the same product, one product backlog, one product owner.

[00:39:19] Neil Benson: Okay.

[00:39:19] Richard Hundhausen: I sometimes get the opposite question, which is: hey, we've got 300 people in our check development center. How do we bring the Nexus in there? I'm like, well, why are we starting with the number of people? Why don't we start with the products? Start with the product and go up. Figure out the minimum we need. Because our number one rule of scaling, Neil, as you know, is don't scale. Don't scale. As soon as you add a second team, you're gonna have friction. You're gonna have these dependencies — just, it's just natural.

[00:39:45] Neil Benson: How much can you get done with a small team, yeah.

[00:39:47] Richard Hundhausen: I propose if it's a professional Scrum team that adheres to XP practices and what we call professional Scrum developers, you can get a lot done. You can get a lot done.

[00:39:58] Neil Benson: One of the challenges I've had with those kind of scaling situations is we end up with teams of specialists. Like in the example I just gave you, where we had the Dynamics 365 team, the systems integration team, and other teams of specialists, maybe an ERP team. And we're now all completely dependent upon each other. Whereas if we'd organize ourselves into three mixed teams and set up some different boundaries and said, oh, you work on this module or that domain and we'll work on this one, we probably would've been able to go a lot quicker. But it felt very unnatural for us to mix people with completely different technical backgrounds together in one team. And you might have seen it in a kind of classic software development. You've got a front-end team and a middleware layer team and a database team. And it just doesn't work, right? You're better to take a vertical-sliced team. We've got all the skills to take an idea into production.

[00:40:47] Richard Hundhausen: Oh, quick story. I was brought into a online travel company in Bellevue, Washington. I can't mention the name but they're one of the Big Three. Microsoft paid me to go in there 'cause I was the TFS expert. All I know is I was supposed to go in there and help them with their source control and help speed things up a bit. And in the morning introduction, the room was crammed. There was like 30 people in there and they're like, well, Richard, we understand you're the expert. Here's the problem. Any new feature that wants to go into our website like if we just want a button that when you click it, it says "Hello, world," it takes 47 days from the green light to production. I said, why does it take so long? Well, it's gotta go to the front-end team and then to the data team and then to the security team and the web team and, you know. I picture back to Lord of the Rings, you know, the fellowship moving through all these lands and through these tunnels and getting to Mordor or whatever and throw it in the volcano. They said, we're told that you could come in here and introduce a branching strategy that would get this down to seven days. And I said, wait. So, first of all, in my head, I'm thinking, oka., you're telling me the "what" and the "how." Why am I even here? Just go do a branching strategy. But room full of people. I said that's gonna take it to 67 days. You want to go down, right? If you want to get single-digit cycle time, you need to rearrange your teams. You need feature teams. Take one web person, one security, one data, and put them on a team. Give that team some generic name like The Avengers. Give them some authority. Give them all the passwords, all the systems that they need. Don't require them to play politics. Now, you can get "Hello, world" out the door in seven days or less. And like everyone in the room, Neil, was like pretzeling up. Like this guy just recommended me losing my head count. So, yeah. But that's the answer. Make things less complex and you need less teams.

[00:42:34] Neil Benson: I think it's tough, though. Those organizational boundaries are built with solid concrete often and they're hard to break down.

[00:42:40] Richard Hundhausen: Yeah. Larman Craig Larman has got larmanslaws.org. You should check it out sometime. But it's essentially, if you as a consultant or a coach or Agile transformation specialist whatever that means, come into an organization, the resistance you will meet is enormous because you're talking to the people whose jobs are in peril. You're talking to the middle managers who may not have a future in a truly self-managing Scrum of Scrums or Scrum teams. And then if you can get by that, they'll essentially say, yeah. We like that. And they'll just take the nouns but they'll ignore the verbs you're bringing in. They'll say, okay. Well, we'll call this person the Scrum master. We'll call that person — which is kind of what SAFe does, right? It gives the existing people new names. It's like Oprah. You get a name and you get a title and you get a new role. If they're okay with the nouns and the verbs, then those people that used to be there, they'll come back up as Agile coaches or they'll be part of the transformation so that once you're gone, they can slowly subvert back to the way it was.

[00:43:41] Neil Benson: Good stuff. Richard, just before we close, I'd be interested to get your thoughts on what's next with Scrum. Jeff and Ken have carried the baton for a long time. We had the last iteration of the Scrum guide in December 2020. Here we are in 2023. I'm not sure if there's another version planned or what might be in it. I really like some of the changes that have been made over the last couple of years. Where do you think it's headed next?

[00:44:03] Richard Hundhausen: Well, Scrum the framework itself, you know, the empirical process control nature of Scrum hasn't changed since the beginning. They might have changed a few nouns or changed a few numbers, roles to accountabilities. It's essentially the same today as it was in the original vision of Jeff and Ken, which was just their kind of repackaging of the new new product development game for software and that's great. Stand on the shoulder of giants and keep moving.

[00:44:29] Neil Benson: I just wish Nonaka and Takeuchi who wrote that paper, knew a little bit more about rugby because Jeff and Ken picked it up and they don't know much about rugby either. But there's a whole bunch of rugby metaphors in there that don't — Scrum is not when a team is aligned and carries the ball up the field. It's a very contentious head-to-head clash to restart the ball after a set piece. So, anyway.

[00:44:55] Richard Hundhausen: I wanna run my definition of Scrum by you. See if it jives with somebody who actually lives in a country where Scrum is or rugby is played. The fat guys all run into each other while the slightly slimmer guys stand in the line watching them. Eventually, the fat guys get tired and have a lie down on top of each other. The ball comes out the back of this lie down and the skinnier guys kick it back and forth to each other for like half an hour. Then the fat guys wake up again and start running around into each other again. Every now and then, the referee stops play because someone dropped the ball and turns out that's the only thing you're not allowed to do in rugby. Everything else seems to be okay. Sometimes, one group of fat guys pushes the other group over the line and there's some manly hugging. No shifting or changing sides like in soccer, though. And then after 80 minutes, they add up the score and New Zealand wins.

[00:45:42] Neil Benson: That's pretty close.

[00:45:43] Richard Hundhausen: It's pretty close? Okay.

[00:45:44] Neil Benson: Except you can drop the ball and it doesn't necessarily count as a fall as long as the ball goes backwards. It's only if the ball goes forwards but it's not a lot. I do know some pretty large — I'm not gonna call them fat guys — large rugby players who, if they live in Boise, Idaho, boy, you're in trouble.

[00:46:03] Richard Hundhausen: I wouldn't say they're fat to their face but, you know. It's all muscle I'm sure.

[00:46:07] Neil Benson: And if you just did that whole thing with pads and helmets, it's a pretty good approximation of football, right?

[00:46:12] Richard Hundhausen: Yeah, that's true. I suppose. So, back to your question, though, what's next? Scrum is a really, as you know, it's a really good framework within which a team can try things. There might not be anything new coming with Scrum but there's gonna be a parade of complimentary practices, some technical, some people soft skills that are showing up, you know? Mobbing for example or a hypothesis-driven development. DevOps has given us, you know, sort of an appetizer platter of things to try on a Scrum team. I'm a fan of Jez Humble and Jean Kim and I read their books and there's some cool things in there.

[00:46:45] Neil Benson: They're the Phoenix Project guys?

[00:46:47] Richard Hundhausen: Yeah, Phoenix Project, the DevOps Handbook, all of that. So, I don't know if what next for Scrum. I do know like from Scrum.org we are mindful of the community and we are trying to answer the calls for help that we see. Managers, you know, trying to give them some hope like, hey. You need to refactor your thinking into how I can become a capability manager and maybe an impediment remover but we don't need tayloristic managers anymore. So, maybe some training around that.

[00:47:19] Neil Benson: And, you know, they shouldn't be standing there with a clipboard, wondering what your velocity was last sprint and — just on that, I quite often find particularly in larger teams where there's maybe two or three Scrum teams that we are still looking for somebody to take hold of systemic risks, contract management, vendor management, resource management, getting doing hiring and that kind of stuff, and looking after the budgets. And what we end up doing is say, hey. That sounds a lot like a classical project manager kind of responsibility. Why don't we go and find ourselves a project manager to support our Scrum teams? And it's worked really well for me. I kind of keep it secret because, you know, project managers and Scrum sometimes have a bit of a contentious relationship but I love it. I think there's a great role for project managers to support us and maintain their professional integrity. They're great at that kind of stuff and communicating plans and schedules back out to the organization. As long as they can let go of the command and control assigning things and telling people what to do, it's worked really well. Have you seen that work in other organizations? Have they kept on project manager to assist the Scrum teams?

[00:48:26] Richard Hundhausen: I have. I have heard of the shifts. You know, they still have a PMO, but they're an Agile PMO, which — here's the thing is everyone can say we're an Agile PMO but until you're an invisible person standing there watching how they work sprint after sprint, you don't really know if they're Agile or not. The proof's in the pudding. If they're truly hands-off like you're suggesting, I'm a fan. Again, I go back to what Craig says. I think for every 100 developers, you know, so 10, 15 Scrum teams or more, you need one manager and that manager is not a traditional manager clipboard like you're saying but they're a capability manager. They're a capability builder. What can I do? How can I help? What new things do you need? Let me see your list of impediments that I can maybe help remove. Let me go get some more budget. I'm kind of naive in my thinking about budgeting. But gosh, it's pretty simple. You've got a Scrum team. You know what the run rate is. It's gonna be the same this year as next year, you know, plus any overhead that might change. Just fund the team and keep their backlog fed with high-quality work and you don't have to do any projects anymore. Just fund the teams and then trust the product owners.

[00:49:30] Neil Benson: That's the way I like to think about it is how much does this thing cost? Well, we think it's gonna last about a year and a half to get from here to here and it's gonna cost $75,000 a sprint. And after that, 90% of the value that you think you need today will have been delivered. And then, you can go for a $10,000 per sprint team. Skinny it down, do less stuff, but don't think of it as a project that is concluded 'cause it's a product that lives forever until you replace it with whatever's next.

[00:49:55] Richard Hundhausen: I love it. Yeah. That's the shift in thinking that needs to happen. If you can get project managers that can see that vision, you know, think of value instead of scope scheduled cost, then yeah. You're in a good spot.

[00:50:05] Neil Benson: Good stuff. Richard, it's been a fascinating conversation. I've really enjoyed having you on. Hopefully, we'll get you back on to the show one day. Until then, where can people follow you, find out more? You've got an amazing book on Amazon. It's Professional Scrum Development with Azure DevOps. How many buzzwords can you cram into a book title? That's an amazing job.

[00:50:22] Richard Hundhausen: Well, let me tell you. This was the first book I've written where I didn't stick a version number in the title. So, this actually might live for a while. My last book was Professional Scrum Development with Visual Studio 2012.

[00:50:34] Neil Benson: Oh, okay.

[00:50:34] Richard Hundhausen: I think it was the only time ever Microsoft had a version for one year. So by the time the thing came out, it was 2013 and I was already outdated so. LinkedIn is good. I'm not doing much on Twitter these days but LinkedIn, I'm always getting into conversations about Scrum or Agile practices and talking about the Nexus or telling people they're wrong, which kind of is a hobby of ours sometimes. Oh, and there was this guy from Oz that was talking about all these great kinds of tests that they run on their product and I gave that my endorsement as well a couple days ago. You might know him.

[00:51:06] Neil Benson: Appreciate that. Thank you very much. Yeah, that's — yeah, I really enjoy our interactions on LinkedIn, so thank you for that. I'll make sure your LinkedIn profile and everything's in the show notes. Thanks, Richard. Appreciate you and thanks very much for joining us. Appreciate you, Neil. Scrum on.

[00:51:17] Richard Hundhausen: Appreciate you, Neil. Scrum on.

[00:51:18] Neil Benson: Keep sprinting. Bye for now.
 
[00:51:21] Thanks to my guest, Richard Hundhausen. It was a blast meeting you, Richard, and chatting with you. And I hope we get to do it again sometime soon. Thanks to you too for joining me on another Amazing Applications adventure. If you enjoyed this episode, head on over to the Customery company page on LinkedIn where you'll find a post for this episode. Remember to follow the page and please leave a comment on the post and let Richard know what you learned. Check out the show notes at amazingapps.show/136 for links to Richard's social media app pages, the Nexus Scaled Scrum Framework, and his book Professional Scrum Development with Azure DevOps. I've got more solo and guest episodes in the pipeline. I hope you can join me again. Don't forget to subscribe or follow the show in your favorite podcast app. Until then, keep sprinting.