Agile at Enterprise Scale: Pega’s Journey Beyond Frameworks

In this episode of the Scrum.org Community podcast, Dave West sits down with Brodie Green, Director of Agile Delivery Services at Pega, to unpack Pega’s two-decade-long agile evolution. From early whiteboard planning to experimenting with various scaling frameworks, Pega has continually adapted its approach as it scaled to over 6,000 employees worldwide.

Brodie shares why Pega ultimately moved to a hybrid agile model, how continuous six-week planning replaced big-room quarterly events, and what they learned about shortening feedback loops across complex product portfolios. The conversation also explores how Pega’s Scrum Masters act as Agile Delivery Leads—shifting the focus from team facilitation to solving complex business problems and driving change at scale.

The episode closes with practical insights on measuring impact, creating effective working agreements, and using AI as a true team-enabling capability rather than just a productivity tool.

Transcript

moderator: 0:00
Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. We hope you enjoy this episode.

Dave West: 0:25
Hello and welcome to the scrum.org community podcast. I'm your host. Dave West, CEO here@scrum.org Today, we're talking scrum master. We're talking scaling, and we're talking with one of the organizations that were one of the first organizations to do Scrum, oh gosh, over 20 years, maybe almost 30 years ago, and we're talking with Brody Green from pega systems, really excited to continue the conversation. Actually, we started just before, before the holidays, which is great. Brody is the director of agile delivery services based in pegas head office, which is in the Boston area. Welcome to the

Brodie Green: 1:07
podcast, Brody. Thank you very much. Dave, excited to be here. Yeah, it's great.

Dave West: 1:12
We just to bring our listeners up to speed. Brody and I bumped into each other. I think we've met before, but we bumped into each other at this event called Give thanks for Scrum. And we, you know, talked for ages at this event about the future of Scrum and the future of Scrum Master and why scaling is so hard. So I'm really excited to get him on the platform and to get him involved in the podcast, because I think, Brody, you've got a lot to say. So pega started their agile journey like a million years ago, not literally a million years ago, though it may feel that to many people. And in fact, Ken Schwaber and I was talking to him yesterday, we have a regular catch up and and Ken Schwaber, the CO creator of Scrum, did training and consulting. He couldn't remember, but he thinks somewhere in the sort of 25 year mark, which is crazy to think. I know, I know that's only 2000 so I guess it isn't that long ago, but it feels that way. So can you bring our listeners up to speed on the journey and where Pegasystems is at the moment?

Brodie Green: 2:23
Yeah, I'd be happy to So, yeah, as you had mentioned, pegas has been around for some time now. Was actually founded in the early 80s, and the main focus is on business process management. There's a core component of kind of CRM, some of our big competitors, you know, Salesforce, service now, Appian, many others. And we've been really focused on kind of a core target market of like that fortune, 1000 fortune, 2000 style companies. So with that, they have very complex, large orchestration systems behind the scenes. You'll see a lot of legacy applications just based on the sheer sheer size, and we're focused on, you know, digital transformation. How can we pull these various spirit systems together, make sure that they're talking to each other, in some cases, pull out, you know, replace them. And it's kind of interesting, because pega has been on the forefront of kind of this low code trend for a number of years their mission is actually to change the way that the world builds software. And that's kind of where my group has come into play. If pega is trying to change how everybody else is building software, we're kind of the engine that changes how pega builds software. That's the way that I think about it. And my role as the director of agile delivery services is to try and get high quality working software out the door as quickly as we can, and that has been an ever learning, you know, continuous growth mindset, as I'm sure many folks can can kind of relate to. We've had an interesting journey with Agile. You mentioned it's been at least 15 years. I won't go as far back as 20, but I think at least 15 years they started the Agile journey. And I wish I had the book with me, but somebody had written an internal book at pega with like, how we should build software, and it was kind of their own internal Agile Manifesto, which was kind of interesting, right? And there's still a lot of truth that comes from that. But obviously we've grown and evolved. The company has scaled pretty significantly since that timeframe, you know, and doubling or tripling in size. And as you add more people, you need to change what systems you're using. So just like you would grow from a small startup, from like a, you know, managing your books on Excel, you might start to use Quicken, or eventually some type of ERP system. And that's kind of the way that I've seen agile evolve at pega. People were planning on a whiteboard. And not to say that doesn't still happen, but over time, you're like. Hey, you know, how can I do, you know, capacity allocation, resource allocation. How can I demonstrate roadmaps in a global setting that doesn't just work on that same whiteboard? And I think that's where we've come in. So yeah, that's a little bit about what pega has done and some of the changes that have occurred over the last 15 or so years. And I think

Dave West: 5:22
you know from my exposure to pega, the the kit, the core business you know this, ERP business process tools incredibly complex. Most of your clients are heavily legislated, heavily compliant, and that level of complexity sort of has forced you to work in a in a very agile way, because you though people think they know exactly how things work, until you deliver something, you never really totally and you expose it to your clients, and they say, well, that's not so that kind of more iterative, incremental process. So exactly as you scale, and, you know, I guess 20 or 1520, years ago, it was a lot of people in the Boston area. Now you've got a global footprint, you know, developing in India, etc. Talk a little bit about some of the characteristics of that scaling. What? What have you seen that have been the biggest friction points that have really made, you know, these very because you did have, well, from what I've observed, very autonomous, very smart delivery teams working away, and they were working great. But as you scale that, there's obviously some friction points. Talk a little bit about that.

Brodie Green: 6:41
Brody, sure, yeah, it's kind of like we had Boston area. We also have offices located in the Netherlands, Poland and a big development center in India. So if I look at the numbers more recently, we have probably close to 6000 employees, and of that, we have probably 1500 developers. And with 1500 developers in our product engineering organization, that's a lot of teams that you put together. So we have well over 100 teams, probably close to maybe 130 140 teams just doing development in our product engineering organization. That takes a lot of coordination, and folks don't want to have a heavy process associated with it. So if you want to be able to move fast, pivot quickly respond to market changes, like we've seen over the last couple of years, with the real boom in AI, obviously your product roadmap is going to change. And if we had kind of this, I would say older style waterfall approach, it would be very challenging to move that ship. Don't get me wrong, even with the agile approach or even some hybrid ability, it's still challenging. So we've gone through a few iterations of different scaling practices. The first one that I was close to was actually implementation of the Spotify model. So we went for Alliance tribes and squads that actually gave us a lot of structure, and we found that it helped articulate clear visions for different parts of the organization, some of that we still use today in terms of kind of a recording style model, but we also found challenges with it. And you'll you'll kind of tease this out throughout the course of the podcast here. Pega has tried many of these different models and tried to pick and retain what we've learned from each one. And I think each kind of theory will have something new that you're going to go through that you can keep and then something that you've said, you know, this doesn't quite work for us. So with Spotify model, part of that challenge was we started to create silos. And I'm sure you've heard this from many different groups. So we said, All right, let's see what else is out there. We moved to the safe model about three years ago, started implementing trains. We started using release train engineers. We had another set of very defined groups that also caught a lot of momentum. And at that point in time, pega was, I think, really chugging along, and we actually introduced a new product. So we had pega infinity, which is our core platform. That's the one that's been there for 15 years. You'll see that in all of our marketing. You go to pega.com all that type of stuff, they came up with a new product during our, you know, R and D phase, and that really was kind of the trigger for us to evolve our agile practices, because we had the train set up for one product, right? You think of it how this route solution train level. When the second product came in, we needed to adapt, and that changed, like, in hindsight, it's simple. You think about like, oh yeah, we needed to do something different for the other product, because they have a totally different life cycle. But we didn't realize that, I think, at the time period, and people started. To sense, again, a sense of friction, like, hey, you know, the train model is not working for me. I have groups that are, you know, splitting time. I'm swivel sharing between the new product that we're building our existing market leader. How do I work in this type of organization? And more recently, we've actually kind of grown out of safe. And I would say we have kind of a hybrid model today that basically is applying some of the Spotify model type of stuff, some of safe and then some also pega type of learnings, where we're just trying to, again, get back to that core mission of building high quality software, getting

Unknown: 10:35
out to the door. I

Dave West: 10:36
think that's a really important message, and it's something that I've heard in many organizations that are quite mature in terms of their agility and how they look at delivery this idea that ultimately it is unique to you and you need to build on the practices of many different approaches, because, depending On the situation, for instance, obviously, your new product, it has a the release trains, probably you were revolving too quickly. Your trains, your trains were sort of in the station, and you really like, no, no, no, no, no, we need it to leave. Now you're like, we can't leave. Now there's another, you know, the trains, it's incredibly complicated. And you know, the catering is not on the train, and nobody's cleaned the toilet yet. I'm probably overusing the train analogy here, but I'm British, and we have fabulous trains that are always in the station and never on time. So anyway, so the you've got that, and then you've got this existing product, which has a very defined customer base, very they expect releases in a I mean, yes, you do have continuous delivery, but that there's a very marketing driver, you know, it's got a regular cadence. And these two worlds clash, so you have to build what you're something that's unique for you. How did was that? Was that as painful as it sounds, or what would what? How did you manage to sort of go, Okay, we're doing bits of safe, we're doing bits of Spotify, and we're actually doing something of our own. How did that work? Because people like their dogma, don't they? Unfortunately, yeah, I think folks,

Brodie Green: 12:21
it's it's, it's challenging, right? Because if you consider yourself a change agent within the organization, you're naturally going to be seen as the person that's like bringing in these new things all the time, and there is a balance, right? How much can you introduce at a time period? How long should you wait? So if you're going to swap between, you know different things, you need to have a very clear direction, and it needs to be supported all the way up through your leadership level. I think that's part of the challenge that we had had at that point in time, is we didn't get the full buy in that we needed, even if the teams were ready with it, even if our middle management was maybe, you know, senior leadership had a slightly different idea, or it could have been the opposite. Senior Leadership believes in one approach and our team level, it has got something going on. It's a little bit different. So being the conduit between those two sides of it as also between kind of the technical approach and what the business wants, has been, I think, a critical component. It was painful, but it was also a great growing and learning opportunities. So you touched on it a little bit, but our existing product was basically once a year type of release, you know, you put it out the door, big marketing announcement. There's quite a bit that goes into it, even though we have continuous integration, continuous deployment going on in our internal systems, when you have that big, you know, once a year type of release, everybody's going to jump on that new product, and you're going to have to support it. From a maintenance perspective, that's a lot different than like a pure SaaS solution, something that has microservices in the background. You're deploying to production. It could be daily. It could be more frequent than that, and just based on the nature of that delivery, we had to think about what approach would fit for for each product,

Dave West: 14:08
yeah, and obviously, it's funny, you mentioned Brody, the importance of keeping everybody going in the same direction. You know, the teams have a have a capacity of for change middle management and the systems around that, whether it's recruiting, whether it's incentives, or whether, you know, HR, whatever, have a capacity to change. And then you've got the leaders, the executives who have a capacity to change. All of those groups have focused on different things, usually, right? And so I guess that's your job, right, as Director of agile delivery, to sort of try to get them all to be, maybe not all on the same page, but at least in the same book, and bring that. Any tips for our listeners to how did you do that?

Brodie Green: 14:58
One of the biggest. Things that I found successful was convincing folks on the value of upfront planning. We were like, kind of behind the eight ball with this. And I'm sure many groups were where we would have a release start, and two months in, we would finally get our set of like, this is what we should be working on. So if that two month gap hits, you've already lost a bunch of time. You know folks are doing they're still working on things, but it may not be what you ultimately need to achieve. So aligning on those outcomes up front was really critical. So we moved from like this once a year type of big room planning, where everybody comes together and you're sitting on a whiteboard or sticky notes or whatever, and moved into, at the time, a quarterly planning cadence. And that was, like, mind blowing for people. They're like, Oh, quarterly planning, like, I can't get together this often with folks and like, this is not going to be valuable. We were doing it for like, two or three days at a time. I mentioned the geographic differences. There's a lot of time zones that come into play, and you want to be able to communicate effectively with people. So we eventually convinced everybody, like, let's try quarterly planning. We'll do things like, say, do ratio all these types of commitments. And that was like, Okay, I think it was better than the once a year stuff, but it was still like, super process heavy, and we got so much feedback, like, I can't sit here, is this valuable, all this type of stuff? And I had to do almost, like, a little bit of salesmanship internally to say, like, here is the benefits of this, right? Here's the predictability that we've achieved as a result, and here's what I think we can do next. And the what's next? Piece ended up being more of a continuous planning model. So we broke it up from quarterly into basically a six week cadence, and we made it much smaller, right? People just got together for three hours maybe instead of two full days, and they said, here's what we're doing next, here's what we're thinking about, and then we just use kind of our sprint planning sessions to let the teams refine that so that transition from once a year to quarterly to continuous was, I think, the most valuable thing that we've done over the last five years.

Dave West: 17:11
And do you still do a quarterly kind of Business Review, priorities, direction, kind of stuff, or have you completely gone, which is, I mean, that's the Holy Grail, by the way, Brody, I'm loving what you're putting down here, but the you, how do you keep the business? Because the quarters are really important for business. They love their quarters. So when I was running an engineering organization, I toss top, I ended up connecting my cadence to their cadence because it was any time we could actually all get together with oh, this is how it went. This is where it's going. This is what we need to do next. Do you still do a QBR with the business? But then that filters into the six week planning with the teams, the product team,

Brodie Green: 17:59
certainly, the sales cycle is still there, right when you talk about whether it's annually or quarterly targets that they want to hit. But I think within product engineering, we've found that we're just trying to shorten those feedback loops, like that's the key piece of it. And I'm not saying we're great at this yet, but at least folks are thinking about it, and we want to get there. I don't have any reason to wait for the next quarterly business review to go talk to, you know, stakeholder feedback that comes through. We want to hear that early and often. Certainly, there's forums that are set up for that, and we have a very, I think, good relationship with our go to market staff and Product Engineering. The tighter that that relationship gets, the better and more receptive we're going to be to what the market needs.

Dave West: 18:46
That's an awesome message. I aspired to that I never, never really, even a really small organization as well. It was just, yeah, maybe I could have done better. Oh, well,

Unknown: 18:59
I'm sure we can too. So it might sound better, actually is,

Brodie Green: 19:03
I'll say that when folks come in new to the organization, for example, if we're hiring somebody for program management or scrum master role agile delivery lead, I will mention to them that peg has gotten to a certain level in agility. So if you're looking to, like, do some type of transformation from, you know, we're introducing agile. That's not where we're at. I want us to be from, like we're doing well, to best in class in the industry. That's the jump that I'm looking to make. And those are the type of people that we're looking to pull in. Luckily, we've had some really good hiring, and we've had some great opportunities from other folks that have come in, and they're bringing insights from outside and from the industry. So that's the type of stuff we're trying to do.

Dave West: 19:46
Sounds awesome. All right, so let's move on and talk a little bit about Scrum master role, because you've had SCRUM masters for a long time and and you. You know, many people in the Boston area. Obviously, ScrumOrg is based in the Boston area as well. You know, many people have that have been to pega or fidelity, that's kind of like that is kind of or both on liberty, mutual occasionally. So there's these companies that have sort of become such important, sort of like enablers for agility in the Boston region and Scrum Masters kind of went to these. Yeah, they sort of made the circuit, I guess, or some of them did. So I'm really interested in the evolution of of that, that that sort of capability in your organization. Can you talk a little bit about that?

Brodie Green: 20:40
Brody, yeah, definitely. So we have now probably somewhere around 40 Scrum Masters in the traditional role, I would say, kind of spread across the organization, in a few different, few different groups, maybe a little bit more. And that role has been critical for a long time, right? Because you're helping teams be self sufficient, you're going to try and increase velocity all the stuff that a lot of people talk about, the interesting trend that I've seen more like over the last couple of years has been actually demand for more above the scrum support. So whether that's helping coach on, you know, projects or initiatives. It could be technical or non technical. It could be working directly with product management or an engineering manager and coaching on a specific skill set. It could be, you know, hosting workshops that are focused on specific, targeted, you know, efforts, some type of core challenge that we're facing. But really the trend has been, how can we move beyond the team level, above the scrum, to influence agility at scale? That's what I've really been interested in more recently, and that's what I think we've actually been able to deliver more impact to the organization. So that's probably the biggest part.

Dave West: 22:02
And tell me about that. Are they still called Scrum Masters? Are they? I mean, they're still focused on effectiveness. It's just more than it's about delivering more value quicker with, you know, with the teams ensuring that they're in delivering on that cadence, and teams of teams and the line, but as as their job title changed, Have you measured them? Changed what? What's happened? Talk a little bit about that birdie.

Brodie Green: 22:29
So with the kind of safe model that we use from a couple years ago, we had introduced like that RTE release train engineer type of approach, and that's kind of what unlocked some of this, and that was more of a role, rather than the job title itself. But that got people thinking about, you know, all right, we have team level support. How else can I utilize these skill sets? And if you become, I'll say it again, that conduit between leadership and the teams, or business and the technical side, you start to be able to identify gaps, mitigate risks that other people aren't seeing, because you have a better picture of the whole ecosystem. And once we saw the value that people were getting out of that, we actually did go through a rebranding effort. And this happened roughly q3 of 2025 just about the time period that we were talking at give thanks for Scrum, we were actually going through that rebrand, and the way that we had gone for it was basically evolving the scrum master role, the traditional title, into an agile delivery lead. And that approach kind of coupled together some of the core skill sets that you would have already expected, in addition to, you know, that above the scrum impact and even a little bit of blending of project and program management as well, yeah,

Dave West: 23:49
and the reason why in the scrum guide, it is a set of accountabilities of Scrum Master, is exactly that reason that you know, Ken and Jeff never thought that it would be a job title. It's good that it's a job title, because it certainly helped our business and paid my mortgage. So thank you for that. But the but the it is a set of capabilities, and then you have to extend those capabilities depending on your situation or your context and and it's about that, that sort of scaling that, I think so, a key, key idea that you've really, really latched on to, and I think that's super important. So if I'm an agile delivery person, am I, how am I measured? Is it, is it delivery capability? Is it, you know, is it just product delivery, you know, how does that? How does that work? Brody, this is

Brodie Green: 24:47
a challenging part, right? So I think with folks that are hands on keyboard, you know, peer developers or other roles, you might be able to say, like, here is your specific you. Outcome or target. And what I've seen during this rebranding effort is a lot of thoughts around, how will I be measured? You know, end of the year talent cultivation cycle is happening for a lot of companies, including ours. It's a great time to think about, all right, what's the next step for different folks? And they want to say, like, how can I be if I'm, you know, this job level, how can I be at the next level. How do I know that's true? And what I've found to be even more successful than like, a generic one pager like on measuring folks, is trying to align our people to the product deliverables and the success of a project. You know, there can be some in between, but if the project's successful, and you've contributed to that, then you're going to be successful. If the project's not going well, let's look into it a little bit more, right? And we'll understand, hey, what happened in these different areas? How did you perform? It really comes down to your working agreement, and I think with each of our stakeholders, we want to set that up pretty clearly. If we have two teams. One team is brand new. One team is very mature. You're going to want to give them a different set of services, right? You're not going to want to say for both teams, standard approach, I'm going to run your daily stand up. I'm going to run your retro I'm going to do whatever other ceremonies. You're going to want to tailor this So kind of going through like, almost like a consulting type of approach, but from an internal perspective, that's really the route that we've gone through. But I won't, I won't lie, it is challenging to find consistent ways to measure the impact.

Dave West: 26:32
Yeah, I think the consistent things the challenge. I think that the the model that you describe Brody is something that that I've seen very successful, where ultimately you you build, I don't want to call it a contract, but you know, each engagement, you have a contract with very clear, measurable outcomes that you're focused on. And you as a as a delivery leader or a scrum master, or as a coach, or whatever the job title is, you go and you find your stakeholders, and you build that contract, make it transparent, and then you incrementally deliver against that contract, and just like a product, you may discover along the way, that something that you're aspiring to, maybe it's about, you know, create, making the team more autonomous so they're less dependent on shared services. And maybe it's about speed, maybe it's about, you know, maybe it's about product and clarity of goal and stuff like that. Whatever those things are, as you push into it, you'll discover, because the nature, it's a complex system right, that might be wrong, and then that gives you ability to redo that contract, but it's a very disciplined approach. And that can be a challenge, even though, you know, Cobblers, children, maybe we encourage everybody to be very disciplined. You know, build a group backlog. Everything's in the backlog but ourselves. Oh, dear, that can be there. So discipline is a key aspect of that, have you found that as well?

Brodie Green: 28:02
Ready? Definitely, especially with like, I'll say, cultural differences, right? So there's different ways that each of these ecosystems are functioning. And when I talk to our team in Europe, it can be every very different, even between Poland and the Netherlands, right on you. They want to tell you what's going on right away, right to your face. And if you use that same nomenclature, I'm speaking to our team in the Netherlands versus India, it's quite different. And you can say the exact same message and have two totally different responses. So that's where I've certainly found challenges. And I'm trying to, like, have our group go out and build that working agreement and then maintain it consistently. But it is hard, right? You need to rely on different folks. You have to empower them that they're going to make the right decisions. And I think that has been another key aspect, is not to be a bottleneck on that and try and, you know, trust them, verify that things are going well, check in with the different stakeholders to ensure we're supporting their needs. But yeah, that's basically the way that we're thinking

Dave West: 29:10
about it. And then obviously one of your key jobs is to ensure that the executives, as it were, the people that are ultimately paying for these or agreeing these things are paid for, are on board, because I've had many executives. Why do we need these delivery leads? Again? We've got engineering management, we've got product. What are these people doing and ensuring that they understand that these people are very focused on the system that binds these two groups as they were

Brodie Green: 29:44
definitely that's a challenge I think we probably all faced, regardless of the company. And I think it's actually a fair ask, right? If you have $100 to spend, and you can spend it on anything, you got to know where you're getting your return on investment. So. So amplifying that impact, identifying it and making it very transparent to show is what has been kind of part of the reason we went through that rebranding effort. We wanted to not only be seen differently internally, but also kind of showcase that skill set to our leadership and also change our mindset for our team members.

Dave West: 30:20
I think that's a really important message for our listeners. You know that rebranding can sometimes help to do that, because you use that as a catalyst to advertise, to have a conversation, etc. So obviously, it wouldn't. This wouldn't be a 2026 gosh, I haven't said that yet on a podcast. You're on my first podcast in 2026 thank you for that new year. Yeah, happy new year. It wouldn't be a 2026, podcast without the words AI in it. Do you feel that these agile delivery leads, that that's an that's helping extend their sort of like value, almost, because, I mean, you're a very egg is a very AI literate company. Anyway, it's always been, well, we used to be called data and analytics and machine learning, but now it's called AI. You've always been at the forefront of that, in terms of technology, but in terms of your products, but the driving in as the you know, all these new ideas, whether it's the use of Gemini copilot, whatever. And you know, I have to say software engineers are the least receptive people that I've come into contact with with the use of AI, I'll be honest, product people are pretty close to that, by the way, as well, and it tends to be just random people that use it much more. So are these people kind of helping to drive improved adoption of not, I mean, AI is just the latest technology, but any automation and any enablement,

Brodie Green: 31:50
I think it's a core, core focus for this year. Definitely, I would say, you know, this has moved so quickly, but last year, our focus was really setting a baseline for everybody you talked about the literacy level. Are you using these tools in your daily basis? Are you familiar with them? Are you interacting with them? That was kind of like the core baseline thing. Now we're beyond that, and I'm trying to find tangible use cases that we can actually impact. So I'm sure there's folks out there that want to have a scrum master, AI agent, right in their group. I think you can get them in copilot or other places. The key piece is, what can you bring to your team or your immediate group to kind of amplify not only your own baseline learning, but can you also bring that into your team? And I think during that gives thanks for scrum events that also became pretty clear from many other folks that they're thinking about, that how to make AI a team member, if you will. And that's something that we're starting to iterate on.

Dave West: 32:52
And agile delivery leads are the catalyst for that introduction from our experience, because everybody else is either too close to the works. They're like, yes, they they're obviously using AI to improve their emails and and even their code and doing tests, etc, but the ability to stand back from it all and say, Okay, so let's get an agentic agent, an agent to, yeah, some sort of AI to be a team member, to step back from the I think agile, from what I'm seeing, agile delivery leads or SCRUM masters are a great set of people to drive that, and that's something that I'm definitely pushing in 2026

Brodie Green: 33:35
Yeah, definitely. I think just being the change agents in the organization, there is an aspect of most art. It's definitely a skill, almost, art to communicating effective, you know, organizational behavior and change. And if you kind of put AI in that same bucket, it could be just like a process improvement. It could be just like something else, and you need to roll that out effectively, make sure people understand what you're trying to achieve. You want to do it in a way that's receptive, allow them to be part of the decision making process, and, you know, allow enough time that you're not getting that that change fatigue. So certainly a big

Dave West: 34:13
aspect of it and manage those fears that obviously, as a software developer, we're very cognizant of the fact that large companies are laying off massive amounts of software developers with the idea because of its AI. So, you know it, it is managing that balance between delivering value, etc. Okay, well, ready. Thank you for spending the time as we, as we bring this podcast to a close. I'd love you to sort of, if you know, we've got listeners throughout the world who are, maybe some of them work at pega, pega systems. So I would love, what would you know? So what would be your words of wisdom, particularly with respect to the Scrum Masters you know, you've done this research. Recent rebranding, you've sort of like tweaked their role to be cross product, cross team focused on trying to drive real business change. What would be the sort of words of wisdom you would leave our listeners with,

Brodie Green: 35:17
I want to be seen as the first person that you go to, or first group or first role that you go to when you have a challenging business problem to solve. I do not want to be seen as here's the process people right here is the, you know, X, Y or Z, you know, interject whatever you think there. So when I've seen the most success is people are, you know, knocking on our door saying, I've got a really hard challenge and I need help. What can you do for me? And the wider your skill set is, the more agile background you have, the more project management background you have, the more people you know, communication skills that you have, the more successful you'll be in that. And I think you just go out and solve some of the hardest problems, and people are going to keep knocking on your door. That's the advice that I would give. Wow, that's

Dave West: 36:09
that's actually awesome, because that's exactly what I believe Scrum Masters in particular, that should be what they spend every day. They are the problem solvers inside organizations, to make those organizations more effective, to deliver more value and to and to make them more humane as well. I think that, because I think those two are linked, I know there's much debate in the in the world now, but I honestly do believe that happier people deliver more stuff and better stuff, based on my experience in restaurants, in particular, if you get a grumpy server, the last thing you're going to do is have a fabulous experience in that restaurant. So So I think that acting as that catalyst, and that's great words of wisdom, Brody. I really, really appreciate that. And thank you for spending the time today on this sunny January morning in the Boston area.

Brodie Green: 37:02
Thank you very much, Dave. I appreciate it, right?

Dave West: 37:05
And thank you listeners for spending the time listening to this podcast. I was very lucky today because I got to talk to Brody Green from pega systems. He's the director of agile delivery services based here in the Boston area, and he was sharing his insights, or pegas, I guess Becker systems insights on their very long journey around agility, really the challenges of scale, and ultimately, I think the message that he sent was, it's not one framework, it's not one approach. You have to build your own, sometimes, unfortunately, that requires you to experience using those approaches as one and then seeing how that goes, which is, which is, which is interesting. And then he moved on to talking about the scrum master and how it's evolved into the Agile delivery lead, and how they are the they should be in your organization, the go to people for really solving those tricky problems that are stopping your organization from being absolutely amazing and delivering a lot more value and changing the world that it works in. So pretty good messages from Brody today here in the podcast. If you liked what you heard, please subscribe, share with friends, and, of course, come back and listen to some more. I'm lucky enough to have a variety of guests talking about everything in the area of professional Scrum, product thinking. And, of course, agile. Thanks everybody. And scrum on foreign you.