About this podcast episode

Gil Broza shares how Non-Software teams can use agile principles to transform how they deliver customer value.

In this podcast, you will learn the following:

✅ How Agile principles apply to Non-Software teams

✅ Common challenges and solutions for implementing Agile outside of tech

✅ Strategies for fostering an Agile mindset in any team

🎉 The transformative power of Agile for team dynamics and project management

Transcript

(transcripts are auto-generated, so please excuse the brevity)

[00:00:00] Welcome to Agile in Action with Gil Broza

Speaker: Welcome to the Agile in Action Podcast with Bill Raymond.

Bill Raymond: Hi, and welcome to the podcast. Today I’m joined by Gil Broza. Hi Gil, how are you?

Gil Broza: Excellent. I’ve been looking forward to this.

Bill Raymond: Me too!

[00:00:13] Introducing Gil Broza and His Agile Expertise

Bill Raymond: Gil, you are the founder of 3PVantage and author of Deliver Better Results, The Agile Mindset, The Human Side of Agile, and what we’re going to talk about today, Agile for Non-software Teams.

Bill Raymond: Before we get started, could you introduce yourself a little bit?

Gil Broza: Sure. I specialize in helping organizations deliver better results by upgrading their agile ways of working. That’s why we had agile in three of my book titles. The focus with my clients is on upgrading the entire system of value delivery. So not just one team or one function. Specifically by putting people before process and being intentional and explicit about choices.

Gil Broza: What I refer to as the mindset. My background is in tech, but a few years ago, I found myself working with more and more companies and teams that wanted to, or needed to, be agile with non-software work. And they really appreciated my unique perspective in it that I didn’t just copy paste frameworks and practices from tech.

Gil Broza: And that led me to write a book in 2019, just before COVID, on how to consider design, start and evolve custom fit agile ways of working outside of software. Other than that I’m independent. I’ve had an independent practice for the last 15 years. I live in Toronto, Canada, and I’ve worked with over 100 clients.

Bill Raymond: That’s wonderful. Thank you. I guess you already started down this path. So I’m going to continue just for a moment.

[00:01:40] Defining Agility: From Personal to Organizational Scale

Bill Raymond: Common question that I like to ask everyone on this podcast is what does agility mean to you?

Gil Broza: Okay, you ask 10 people, you get 20 answers, right? So for me, you’re going to get two . That’s the multiplier, right? So first, let’s talk about lowercase agility, right.

Gil Broza: The English word, we have agility, we’re being agile, when we move quickly without rushing, we’re attentive to change, and we respond to it as needed.

Gil Broza: But we’re, we do so economically and without drama. But it’s not just about speed. More importantly it’s really about always trying to do what’s right. So being right and not just being fast. And then there is capital A agile, right? Which is like the agile community version which I define and also define that this way in the book It’s really any way of working that is congruent with the four values in the agile manifesto. And in the book we’re talking about I generalize them to not to be so software minded.

Gil Broza: So really those four values are adaptation, customer collaboration. So really a two way street between the doers of the work and the people who benefit from it. Early and frequent value delivery and probably most importantly, putting people first. So you have capital A agility when you optimize your way of working to those four values.

Bill Raymond: We can easily list out those four values and say, yeah, we’ve got those covered. But how do you ponder how you’re going to be agile using those values?

[00:03:10] The Essence of Agile: Beyond the Visible Tactics

Gil Broza: Okay, so let’s first talk about how people usually start and the way they usually start is by looking at the visible sides, the tangible side of agile, which is, we have a cross functional team and maybe they use JIRA and they write their requirements just so they call them stories. They use cards, tickets, points, what have you, all the visible things, the teachable, documentable stuff.

Gil Broza: But actually, that’s not the part that matters. The part that matters is what gives rise to those tactics. For instance, in many organizations that are pre-agile, what do they actually value? They value predictability. They value standardization. They value getting stuff right the first time.

Gil Broza: They value staying within, schedules and budgets. And those are, of course, very different from the agile set that we talked about. So doing a compare and contrast really helps at this point. It helps because then you realize that it’s really again, what you optimize for that determines the outcomes that you get.

Gil Broza: So for everybody listening to this you have a way of working right now. Chances are it is not 100 percent perfect.

Gil Broza: Okay, I’m not saying broken, but it doesn’t have to be broken. It’s probably not perfect, because we’re human. And we work in complex environments, and stuff changes all around us. Okay, what are the pain points associated with how you work? For instance, your customers and stakeholders? What are they not getting from your team?

Gil Broza: Okay, where do you get all sorts of repetitive issues from working the way that you do? if you look at the outcomes that your work produces, and the impact of those outcomes, basically how the work makes a difference, much of a difference does it actually make? And this is a really fine point because, we have people, they mean well, everybody’s doing work, it all seems important, a lot of it was asked for, but it’s always the case that some of it really doesn’t need to be done, there are better things to do, or some of it could be done differently and achieve different results. But we don’t notice this. We don’t notice this because how we work tends to be a blind spot. And this can be really at the level of little things and of bigger things.

Bill Raymond: What are some of those things that you might see being different before you start down this agility path, and then after you go down the agility path.

Gil Broza: So when we talk about a way of working and an agile way of working is one example of that, technically everything about it could be different. It’s what you commit to, how you plan, how you decide what work to do next. Who will do what, when, how you engage individuals, how you engage teams, how you perform tasks, how you check your work, how you adapt to changes. So we could look at each one of these and ask prompting questions about the way things are right now and really look for opportunities there. For instance, the the prompt I gave first, it’s like what do you commit to? We know from a lot of organizations that their commitment cycle is a year. They do some sort of annual planning. Part of it is budget. Part of it is content, what we will achieve roadmap, list of projects, this and that. Okay. What are some of the positive outcomes you get from planning yearly? What are some of the negative outcomes you get from planning yearly?

Gil Broza: One reason agile is what it is that when you commit yearly, you’re less likely to change things as you go. Also, if opportunities arise you can’t really seize them. Okay. Again, thinking of like a non-software function budgeting, right? we can take budgeting for example. I’ve had, I can’t even count how many clients that said, yeah, we need to hire you, but not this year because we didn’t budget for it. and it’s not like paying me is going to break the bank. But they are not set up to get budget that wasn’t predicted a few months ago. Now, sometimes they have all sorts of change requests and specials and escalations and this and that. But can you imagine the cost to the system of entertaining those change requests? So there is an opportunity here maybe you want to do your budgeting a little more frequently and have it not look that far out while still thinking about the future. Okay. So there’s a whole body of work known as beyond budgeting that does exactly that. Okay. That’s a form of agile. Or if we look at how we engage individuals and teams. The way it is in most organizations is they have what they call teams, but those are not teams. They’re actually work groups. There are a bunch of individuals with different skills and accountabilities who happen to have the same boss and usually the same or overarching work plan, but that does not make them a team.

Gil Broza: It’s just a word we use all the time. And so what are the missed opportunities there? Now, maybe it’s good. Maybe the people won’t get along. So don’t make them a team because they’ll just be in each other’s face all the time. Okay let’s imagine that’s not the situation. But what if there is actually an opportunity here to catch misunderstandings and to help people really play to their strengths, to lift each other up. The goodness that we know about teamwork, but we’re not getting it because we have set ourselves up so that teamwork doesn’t actually happen. You see this in standup meetings, for instance, people go around and they say, Hey here’s what I did. Here’s what I’m going to do. Here’s what’s on my plate. And it’s all I, even though presumably they’re a team, they do stuff together, but no, they’re not. And the same happens whether it’s software or non-software.

Gil Broza: It doesn’t even matter.

[00:08:36] Adapting Agile for Non-Software Teams

Bill Raymond: So if we take this and step back for a moment I really like the way you’re describing everything, because this really does apply to anyone, right? Now, certainly the agile manifesto, as we like to refer to it, it’s really called the Manifesto for Agile Software development, MASD.

Bill Raymond: And that really did come out of an engineering problem that software developers could not get their products out to customers and review them fast enough. And so they said, you know what, we’re taking the reins and going with this new approach and here are the values. And then someone else said let’s take some of these concepts around scrum and let’s build that.

Bill Raymond: And now we call that agile and it’s synonymous with software developers. That doesn’t mean that other teams aren’t having the same exact problem that software developers are having.

Gil Broza: Okay. Software development has some really unique parameters. It takes a whole lot of people. Usually all those people actually work on one big thing, and it is like really big. As opposed to, for instance, sales or marketing or HR where you can parcel things out a bit more and that would be okay, right?

Gil Broza: Whereas a product that’s, you have two people out of 50 in development, what the two people do, that’s not going to be the product. It’s going to be a piece of the product and not viable on its own. There is a whole lot of continuity in software development, right? We develop those products for a really long time.

Gil Broza: And something we have learned from agile, it’s not an agile invention, but we have learned from agile, is that it’s not enough to check the box on the tasks being finished. But the work has to matter. It has to matter to that person. And In many cases, we also have to be ready to change that work, maybe because it fell flat, or conditions changed, or they changed their minds, or they never knew what they needed, whatever it is.

Gil Broza: The big fancy term for this is that controls the cost of change, is relevant for a whole lot of pursuits inside an organization. And in fact, when you look at what makes up an organization, there are very few areas where if not many parts of agile thinking just would not apply.

Gil Broza: A prime example of where they don’t is accounting, right? So you do the books. And you’re basically just looking at the past. You’re not looking at the future, like budgeting. You’re just, you need the books to be right. There is no customer to change their minds. You just need the numbers to be right, or you’ll be in trouble. It’s as simple as that.

Gil Broza: But for so many other functions and business units, yeah. Definitely lots of use for agility and it doesn’t have to look like tech. And often it shouldn’t look like tech because again, the contexts are so different.

Bill Raymond: Yeah.

[00:11:18] Agile in Marketing: A Real-World Application

Bill Raymond: I’ve just wrapped up with a client who’s in the marketing division within a tech company, but their point is that they’re marketing the product and they had a lot of work going on this big machine, trying to push out all of these marketing campaigns in pursuit of new sales.

Bill Raymond: And that’s where they started to realize that there needs to be a better way. And I think if you take a look at to borrow from software development, you don’t need to have any software developers to do this, but. One of the things that we defined was this concept of a product owner and a product manager, where there’s some collaboration to figure out what is the value that the product provides, and then figure out what is the right messaging.

Bill Raymond: And very often, it just got to a point where we have this new feature in a product, just send it over to marketing. And it’s the same questions that you just asked before, which is how do you make sure that what you’re doing adds value? Can you measure it? Can you make sure that you aren’t overloading your teams with a bunch of work just tossed over? And you have this concept now of people that actually help prioritize with the business and the customer and granted that customer is the person paying for it for marketing, but very often the end customers sales because sales needs those leads coming in and marketing is an engine for that. And so it’s just very interesting to watch them go through that transition.

Bill Raymond: And every time that a new thing happens there would be this bottleneck of first we have to run things through legal. And

Gil Broza: After that happens, it comes back to us. We re-work the copy, go back and forth, and they’re different teams. What happened? They organized into individual teams where now there isn’t necessarily Let’s say a legal organization that they go through. They’re team members that are on the same people writing that.

Gil Broza: And the same thing with the copywriters and the artists, they’re all incorporated in that together.

Gil Broza: Yes. When I worked with the marketing team, it was the exact same thing. Look, I actually want to give up another example based on that. Because often when we think agile, we think there is a team and yes, it makes sense.

[00:13:31] Agility on a Personal Level: Job Searching and Book Marketing

Gil Broza: And then corporations, yeah, you’re going to have more than one person, but you can be agile as an individual, right?

Gil Broza: And an example that everybody listening to this would be familiar with of how you have been agile is last time you looked for a job. Think about it. It’s not like you made a list of job finding activities. Check check. And then you just wait for it to be done and hey, pronto, you got a job.

Gil Broza: It doesn’t work that way, right? And you need to adapt your resume and your cover letter and how you approach people and all of that. This is being agile with a team of one. For a totally personal reason I’m experiencing this myself now. So the new book, Deliver Better Results came out two months ago, and I did a ton of preparation and strategy for marketing it, but I’m finding myself adapting the strategy and therefore also the actions based on how things have actually worked out. Which, I, some of them, you need more time before you know how they’ve worked out. But there are some leading indicators and there are elements of the strategy that I am beefing up and others that I’m just postponing because I don’t think that’s where the value would come. That is so different from just again, studying everything, producing a big task list, and just, knocking the tasks off.

Bill Raymond: I think that’s a really good point right there. I love the example of searching for a new job, as consultants, we have to do that too, right?

Bill Raymond: We have to market ourselves. And if our marketing isn’t working, then we just shift gears and we say, what, why do I keep doing this thing when it’s, when it’s not working, so you change, and I love the concepts that you’re using there where you just sit back and think about yourself first, but now let’s talk a little bit about organization, right?

Bill Raymond: If we aim to be agile,

[00:15:22] How to Know You’re Being Agile: Evaluating Your Approach

Bill Raymond: How do we know we’re being agile?

Gil Broza: Okay. So let me start by saying how not to answer this question.

Bill Raymond: Perfect.

Gil Broza: Two things. One is don’t look for compliance with a framework or someone else’s checklist of roles, practices, artifacts, and meetings. The other thing that I don’t want you to be looking for is what’s called evidence of agile behaviors. And the reason I’m saying this is because your way of working my or your ideal one that is might actually not be fully agile in the first place. Okay, so you don’t necessarily see behaviors turn out quite the same way. Assuming that there is some ideal set of values, beliefs and principles, whether it’s basic agile or your own design, that should get you the outcomes you need, look at what you actually have and see if they match that idea.

Gil Broza: How do you do that? you reverse engineer your tactics. So let’s say, let’s take as an example, that you’ve chosen to do sprints. Okay, I don’t care if you’re following Scrum or not, you’re doing sprints, right? that’s a very common thing to do. So at least from a process standpoint, you want to look at your sprints and say are they not too long? I don’t care if they’re two weeks, maybe they’re a month, but by your standards and by what you need to accomplish, they’re not too long. Are there minimal interruptions to your sprints, right? Or maybe there are lots of interruptions to your sprints. And then the sprints are basically just a planning artifact with no value whatsoever. Inside of a sprint, do the teams actually understand the value in what they’re doing, right? So again, it’s not just knocking off tasks, but it’s tasks with a purpose. On the people side of things, when you’re thinking about your sprints, do people feel safe to participate? Do they feel motivated to engage?

Gil Broza: Are they being treated as resources that transform requirements into output? Or do they actually engage as colleagues who care about the result? And in one more point, I would say about this is look at the people and consider what gets them to do the work, because a lot of times I’ve seen that I’ve seen this and it just totally grates me people bring sprints in thinking that the process will compel people to do work. Instead of having this long winded project with 527 tasks, We do things on a two week basis. And so now we’ll have accountability. Now people will be busy. We will see what everybody’s on and we will track this and thank goodness for Jira, Trello, Asana, you name it. No, not at all. The point of the sprints is to allow adaptation and responding to change and different needs and new things.

Gil Broza: Not to compel people to do work. That is in violation of an agile value that people before process. So basically you look at this sprint is, and it’s not about to do you do sprints or not. Or do you do them the way scrum intended or not? Do you do sprints in a way that achieves for you the value of adaptation? Do the sprints really live up to the idea of we don’t actually know how things will turn out so we come up for error every little while to check and adapt, right? That is the agility as opposed to the doing agile.

Bill Raymond: Really good thoughts there and I think one of the points that you made was around safety. And I think one of the things that makes agile when it’s working and when you’ve adopted it and you’ve defined your core values around how you want this to work.

Bill Raymond: One of them, if it is safety, then you will have team members that can say, should we be doing this?

Bill Raymond: Because very often, the big train is going down the track and a bunch of people are just starting to assign work because it’s just two weeks, people keep turning things out. And then you get back into your old habits and start sending requirements down that don’t necessarily get to the value that you’re looking for and to enable your teams to stop that traffic, to stop the train and say, we have to take a look at this, a better look at it, that’s another if you will signpost, it says you’re doing good in, in adopting agile.

Gil Broza: Yeah. And by the way, speaking of safety, here’s another one. Let’s say you’re doing daily standups, huddles, whatever you want to call them. When they’re done well and in a true agile fashion, people feel safe to engage. And so when you get to this question of what are your impediments?

Gil Broza: What’s in your way? People feel safe to answer this and not just look busy because looking busy, It’s self preserving behavior. So look at your standups and see, are people actually being honest? Or do they always say, yeah, it’s fine. It’s fine. It’s all fine. I’m good. I’m good. No problems, no issues. Right?

Gil Broza: So it’s again, the agility here isn’t in, oh, we meet daily. We’re supposed to, and we do, Hey, 15 minutes. We’re done. We’re going to have a talking stick. On Zoom, but whatever. No, it’s not about that. It’s about, are you actually getting good planning out of this meeting? Because people actually say what their problems are.

Bill Raymond: I think that’s a really good point. And, I’m also thinking about when we talk about frameworks that keeps coming up, right? You’ve said frameworks and scrum a few times, maybe I did as well. There’s goodness that comes out of these, right? Because one of the things that happens, and one of the reasons why people say maybe we should start thinking about adopting agility is because things seem to take too long or because you worked so hard on a project and delivered it, and then realize that by the time it was done, it was doomed to fail or the market changed. And even though it was the right thing now, it wasn’t back then.

Bill Raymond: I suggest that if you want to adopt some of those little, if you will, things that everyone else does around, for example, sprints, we have this thing called a retrospective.

Bill Raymond: And, a lot of times teams focus on the retrospective to improve the team coordination and, see what can be modified or tweaked for the next sprint. But you can use those as real learning opportunities to say, we just accomplished this sprint. Yay. We did it. But now let’s step back and say, did the work that we do meet our values?

Bill Raymond: Did the way that we interacted together, meet our values? And really focus on that as the core element of your retrospectives and don’t skip it because that’s what’s going to ingrain this into your culture.

Gil Broza: Yes. And once again, what we’re just talking about here, only transferable outside of software, right? So you don’t have to be a software team in order to do this. We used to have project postmortems, right? Terrible word. And they’re done too late and the team has turned over and whatever.

Gil Broza: So retrospectives are like this on steroids and actionable. But again, you can do retrospectives and not really make much of a dent. What you described now, is how we can make a dent. just meet and say, Hey what what needs improvement, which I don’t, I no longer recommend because they’re too superficial and they jump to conclusions too quickly.

Gil Broza: But instead, no, let’s talk about, okay, how how have we worked together over the last few days, two weeks, what have you. And where did things go wrong? What did we do really well that we want to capture? But it’s not oh, the detail on the story was just right. No, but we also questioned some of those stories and some questionable ones did not make it to the plan.

Gil Broza: That’s a win. That’s a much bigger win than, did I have the right details on the story? Absolutely.

Bill Raymond: One of the things that I think you’re really good at doing is not just thinking about, oh if we do agile, we have to do scrum, you’re giving this concept of here are the things that you could do to make improvements in your team without even following any kind of a framework, which makes that concept of agility may be a little bit more easy to understand, but I’m listening to the podcast right now and I’m thinking this all sounds really interesting and I think it’s something I want to pursue.

[00:23:19] Making the Business Case for Agile

Bill Raymond: So what is the business case for doing this? I want to sell this to my senior leadership team or to my own team.

Gil Broza: Probably don’t sell it, but maybe try to get people on your side.

Bill Raymond: Fair enough.

Gil Broza: And the way, by the way you broach this with your team is totally different than how you broach this with your leadership. There’s a whole chapter in my book, just about objections. But now let’s talk about the business case, right? So let’s say you are leading some function or business unit or a non-software team and you’re thinking about doing this. Your team or function or business unit is there to help the company achieve its mission and objectives. So we’re not arguing about that. But what we can ask is what will achieve that? How should we operate so that we’re best poised to help the company achieve its mission and objectives? Mission is relatively constant. Objectives change from time to time.

Gil Broza: And in some cases, really what you need to do is to just, serve some of your internal customers and stakeholders. Other times it’s more outward looking. But the answer to what will achieve that is your motivation for agility. So I’m going to read out a little list that I made ahead of time.

Gil Broza: It’s actually partly mentioned in the book as well of common motivations. And I invite, the listener to think, which of these matters to me, that’s the one I’m going to pursue. So one is fulfilling customers needs earlier. Another one, adapting quickly to business changes, which could be a much bigger deal now in 2024 than it was five years ago. Making customers and stakeholders happier. Another one delivering solutions and deliverables in general that solve actual problems. Increasing transparency within and across functions, making better use of team members, skills, and smarts, increasing people’s engagement, being more efficient. making the culture healthier.

Gil Broza: So all of these are reasons that people have given over the last couple of decades to wanting agile. And the reason I gave this list is because for most people, it’s not like the entire list is what they need. They just need one or two. And with that, they can go to their VP or C level and say, look, we have issues on that front, we could be better.

Gil Broza: And what’s preventing us from being better is because we work in a certain way. And this is really interesting because every company has ways of working right now that are presumably right for the job, or they wouldn’t be in business. So maybe things are not quite broken, or maybe things are a lot of agile and software started because things were broken, like slow, late, expensive, all of that.

Gil Broza: It may not be broken for you, but it may not be great. Maybe you’re losing people. Maybe yes, you produce the right deliverables, but their quality is not really all that great. Look at where the pain points are, but also the opportunities. So nowadays, companies are really not growing all that quickly anymore and not spending a whole lot of money.

Gil Broza: Do you know for a fact that what you are spending right now operating your team, department, business unit is well spent? And the answer of yeah, we do important work and everybody’s busy. That’s not a good answer. And I’m not looking for a way to cut down half the staff. That’s totally not what I want.

Gil Broza: But what I do want is I want you to be able to free up people’s time and effort so that it goes to more important things. That really make a difference to the company. Not just the checking off of work.

Bill Raymond: That’s great. I appreciate the checklist that you provided there.

[00:26:52] Getting Started with Agile: Practical Steps and Resources

Bill Raymond: I always like to ask if someone’s listening to this podcast right now, what are one or two things that someone could do so they could get started right away?

Gil Broza: Okay, so at the beginning of our conversation, I talked about, being aware of the agile values beliefs, what you have right now, where you might use it. And so this is where I would start. And that’s why we have something to give our listeners, right? So I’ve made available chapter four in the book which is really the kind of getting started chapter.

Gil Broza: And so anybody can get it. There’s a URL. It will help you know where to apply Agile for the first time, understand how useful Agile thinking would be for that work, and also frame the work in such a way that facilitates optimal process design. Because really and, you mentioned this before I’m not just about, pick a framework and bend reality to do what the framework wants, whether it’s scrum or safe or you name it.

Gil Broza: I’m all about designing a way of working that works in context. If it happens to look like one of the frameworks, go for it. There are really good ideas there. But the idea is to come up with something That’s right for you. This recommendation is true both in software and outside of software. But I think outside of software, it’s even more important, because those popular frameworks don’t actually work that well outside of software.

Gil Broza: They’re touted as if they are, but in reality, not entirely.

Gil Broza: Yeah.

Bill Raymond: I appreciate you offering that to our listeners for free. But after you read that chapter four, you’re going to want the rest of the book, I promise you. Is there some way that people might be able to reach out to you if they want to continue this conversation?

Gil Broza: The easiest place to find me is on LinkedIn. There’s only one Gil Broza, G I L B R O Z A. And here we are. I just gave away that I’m Canadian. I believe.

Bill Raymond: Yep. With the Zed.

Gil Broza: With a Zed.

Gil Broza: Please send me a connection request. Put in a note. In other words, do it from your laptop where you can put in a note in the connection request and not on your phone where you can’t.

Gil Broza: The other place to go is my website, http://3pvantage.com and just contact me.

Bill Raymond: Wonderful. Thank you. And of course, all of these links will be available on the https://agileinaction.com website. They’ll be available on any podcast app you happen to be using right now. And if you’re watching this video on YouTube, just go down to the description and it will be there. Gil Broza, once again, thank you very much for your time today.

Gil Broza: My pleasure. Thank you.

Speaker: Thank you for listening to the Agile in Action Podcast with Bill Raymond. Subscribe now to stay current on the latest trends in team, organization, and agile techniques. Please take a moment to rate and comment to help us grow our community. This podcast is produced in affiliation with Cambermast LLC, and our executive producer is Reama Dagasan.

Speaker: If there is a topic you would like Bill to cover, contact him directly at Bill.Raymond@agileinaction.com.