TRANSCRIPT
PETER LIJNSE: Welcome to BRM Cafe, Episode 10. In this episode, I talk to Aaron Monroe about Agile and business relationship management. Topics we discuss are: role clarity around product manager and VRM, different frameworks within the Agile environment, the challenges for BRM’s working in an Agile environment, his role as a transformationalist. We’re talking about business value and product management. And of course, let’s not forget Aaron’s great discussion around lasagna.
PETER: Welcome Aaron, to the podcast. Can you please tell us a little bit about your background?
AARON MONROE: Certainly. I’m currently the VP for Agile Transformation for T Rowe Price and that’s primarily my focus from a perspective of helping the organization transform from Ad Hoc and waterfall to Agile. Prior to that portion of my career, I spend a long time actually standing up, building, growing business relationship management groups. I like to say “back during the Wild, Wild West”, before there was a BRM Institute and before there was really a discipline, if you will, that was codified. I’ve spent a lot of time doing that and a lot of time in that space. That helped me to transform and move towards doing things with the Institute as well as blending both business relationship management Agile concepts together. PETER: I think that’s going to be the topic of the session here is around BRM and Agile. Does it work together? Does it need to be separate? Is it two different things? That’s what I really would like to hear from you when we go into details, etc.. So let’s start with that first question. BRM and Agile- what are the differences from a perspective of business? AARON: Great question. The way that I often explain it when I talk with people who ask me that question is- when you think about traditional Agile, so Scrum or any of the traditional Agile mindsets and the practices- it’s really focused on delivery and execution and making sure that you deliver a high quality product or solution. And in these days, it doesn’t necessarily have to just be a technology solution, it could be any type of solution. It also has to be something you want to do fast, you want to do incremental, and you want to be able to iteratively evolve that solution. It’s really primarily delivery-focused and really about trying to get that vision that someone has actually to the market as quickly as possible, be it internal or external. From a business relationship management perspective, it’s really about understanding what that item is, or what that value is– what that strategic value is– and being able to decompose that in a way that it can be then picked up and taken and driven and executed in increment. So there’s a bit of a partnership that you have to have– and I shouldn’t say ‘a bit’– there’s a broad partnership that you have to have but business relationship management is really focused on trying to be able to understand the value, the strategic items that you want to deliver and understand how you’re also going to find out, whether it be tests or return, whether it be brand or something like that. How you’re going to get that value back, how you know you’ve gotten it and Agile’s really focused on the execution perspective, understanding what that value is, and then the best way to deliver it. PETER: Great, for that description, that means BRM is more on the strategic side. It is more continually and Agile is more, looking from a business perspective, how we’re going to execute it, how we’re going to deliver that. A lot of BRMs are still struggling to become that strategic partner, sometimes not on the strategic level. I think when we get into the tactical level BRMs that are quite often more focused on the project etc, that it becomes very difficult to marry that Agile and BRM, I think, because that causes them more overlap because they’re starting to be involved more in the delivery. Is that what you see as well?
AARON: Yes, traditionally, what’ll end up happening is when it’s more of a tactical approach, it ends up being “well, we’ve got BRMs over here, so let’s just make them product owners and have them make sure that the delivery happens”. And if you’re working at that tactical level, it seems to make sense and it looks like it’s the right thing to do. And in a lot of ways, it might be, because even though– I like to call it ‘BRM in name only’, you’re playing a BRM in name only– you really are doing a lot of those things that, from an Agile perspective, is more like product ownership and a product owner on the team. But if you’re truly strategic business relationship manager and you’re truly partnering to understand how an organization recognizes value, understands it, can deliver it, then you’re really further away from that tactical perspective and you’re really looking at short- and long-term business objectives, strategic goals. And you’re really looking much broader and in ways that you really can’t align and assign to a tactical approach. Often, when I talk with BRMs and they say “well, this is what our organization is doing.” The first thing I talk to them about is trying to understand how is the BRM capability, and how are BRMs seen in the organization? And often it’s because they are seen as kind of tactical executors and deliverers versus strategic partners.
PETER: Okay. What you said, they’re becoming more ‘product owners’. Can you expand a little bit of what a ‘product owner’ is? Because some other people that are listening to this might have something like this. What do you mean by that?
AARON: Right, absolutely. Product ownership and product owners truly are, from a business sense and an Agile sense, the idea of someone who understands an area. If you’re in finance and you say “Hey, we’ve got a 401k product,” or if it’s any type of product that’s defined in your organization, you want to have a person that understands that from a business perspective that can actually then make ‘go, no-go decisions’, make determinations on taking a vision where senior leadership says “We want to go in this direction,” or “Here are strategic goals,” and really turning that vision into actual value to make it real. So they’re the ones, from an Agile perspective, that would help to write user stories, define them. They would be the ones that ultimately accept the solution that’s developed or designed. And they would be the ones, if you will, that represent all other business stakeholders and parties to the Agile team so the team doesn’t necessarily have twenty or thirty different people coming and telling them things to do.
It really comes through that one person who represents the business. But you don’t want that person to just be a ‘pass through’ or somebody who is just running back and forth and a go-between. They have to be empowered; they have to be able to make those decisions, to make those tough calls, and be in a position where they can say “Yes, this is something that is good for us,” or “–not good for us.” If we have to make a decision, these are how we need to make those decisions. And that’s a very different skill-set and a very different need than when you talk about something where it’s more of a business owner or product management or something further up where you’re strategically talking about “What is it we want to do with a product? Do we want to invest in another capability? Do we want to decommission something? Do we want to offer certain processes?” It’s a very different skill-set and a very different view and focus. They’re both needed and they’re equally important. It’s just a different way of looking at it.
PETER: Just for my clarification, you talk about two different viewpoints. Are both, in the market, called ‘product managers’ or ‘product owners’? AARON: That’s primarily the difference is that– and this is one of the things that sometimes, in the industry, gets confused– people will ascribe all different types of responsibilities and things like that to this thing called a ‘product owner’. From an Agile perspective, a product owner is somebody that’s on the team that actually helps to execute, and really, deliver value and understands business practices, business needs and things like that. From an Agile perspective, outside of that, there really isn’t anything else. But the challenge is that we all know that many of the environments that we work in, if we’re a company of any size, it doesn’t just stop there. There are a number of other people that are involved from marketing and sales and all that kind of stuff that actually have to also come up with a vision and shape and everything. That’s traditionally more aligned with what– if you work in a business environment– is called ‘product management’ which is a person or a group of people who are responsible for guiding and driving a product or something that’s of business value to a company. Those are two separate pieces; one would be an Agile product owner that works with a team and executes some things like that, and then it may be a person or people who guide and create vision and do more product management.
PETER: I think this is what I also see from a BRM perspective. That challenge of role clarity, etc. but that helps really, from my understanding, to actually start figuring out “Okay, how can we actually do that?” because I have a lot of BRMs that at this moment have some “Yeah, we have an Agile group and somehow, we need to actually work together with them.” And we are struggling with that. AARON: One of the first things that I would always say is if you’re struggling with that, to stop and try to get the role clarity, like you’re pointing out, to really try to understand what is it that an Agile team is looking to do and needs to do, and what is it that another role or multiple roles need to do rather than thinking of it as “Well, I’ve got a job description. This person’s got a job description and these are the things that they do.” What I often find is there are people that are in certain roles that are called certain things, but their responsibilities kind of overlap and meld. So it’s really more about having that conversation, and it’s not really doing a RACI chart or that kind of stuff. It’s really more just understanding what it is each person does and that might lead to more broader definitions or clearer definitions of things but it’s not like what you would do in a project world, which is “On this project, we do this, then the other thing.” It really is more along the lines of “How do we define roles when we’re trying to deliver value and take something from a strategic goal or business objective to a number of smaller, value-deliverables,” and “Who’s responsible for those things? How do we understand it? Who do we talk to about certain things?” Getting clarity on that and understanding where those things overlap and where they might not is a really good first step. PETER: You mentioned RACI charts, I hate those. It’s a good dialogue sometimes, but it’s a discussion that can go on forever and never actually ends up with a real, clear understanding of it. We normally talk about mandates, basically. “Give me three to five key points that you do and what someone else does and let’s make sure that that is clear.” My problem is and– and this is me basically trying to actually figure out all of this, I’ve read books around this. I did try to read some books from Reinertsen, which I’m always struggling basically halfway through you have something that has way too many politics issue.
But there’s a lot of different things. Like, we hear in the market around Agile, we hear DevOps, we hear SAFe– though I have heard some very negative things around that. What do you see all the different methods that are in the market? Are you using all of them or are you focusing on certain ones?
AARON: I would say I’m using all of them and I would say, for what I do as a transformationalist, that’s one of the things that we have to be able to do is understand what areas make sense and what scenarios make sense. It’s not a one-size-fits-all. You really have to be a pragmatist. You’ll have other people who say “No, this is the way it’s structured and you need to go do it. You need to conform to those things.” And what I would say is this, in my view on this is as such. Anything you talk about, from an Agile perspective, there’s a reason why it’s called a framework. There’s also methodologies in there in the sense that they provide you a backdrop and a number of tools and practices and mindsets and things like that to be able to solve a problem. It’s, to me, no different than if I was a dot net developer or a Java developer. I’ve got a number of ways to solve a problem. It doesn’t mean I have to use them all, and it doesn’t mean that what makes sense in one instance and one company makes the same sense in another instance and another company. For example, often I hear people talk about the Spotify method. It’s one of those things where “Hey, we’re adopting and applying the Spotify method,” and the challenge with that is that, unless you’ve got the culture and the practices and the approach of Spotify and the structure and all the things of Spotify, you can’t apply the Spotify method. You won’t get the same results. That’s what happens when you work in an empirical space versus a defined space. An empirical space is you’re doing testing and learning no matter what you do because people are involved in it. You can’t just automatically get the same thing out as if you were working in a manufacturing environment or something. That’s what all of the different frameworks and methodologies, from SAFe, to XP to Scrum to DevOps to any of the other ones that you might hear or think of and stuff like that. What makes most sense would be to look at your environment and look at what you do and start to apply some certain things to that.
I went to a conference a few years ago and one of the keynote speakers said “If you’re trying to cook lasagna and you had no idea how to cook. What you’re going to do is you’re going to go find a recipe that’s going to make lasagna at the end. It might be not exactly what you’re looking for, but you know at the end you’re going to get something that’s going to be lasagna. And then after you use that recipe a couple of times, maybe you like it a little sweeter or not a little sweeter, or more tomato-y. You start to adapt that and adjust that recipe to how you work and how you eat and your taste and your palate.” And the Agile frameworks and methodologies are very similar. There are certain things you have to do, just as there are certain things you have to do to call something lasagna. You have to do certain things for it to be Agile, but there are very few of those. Everything else would be the extra ingredients and the things that you would do for your own palate. So start with a recipe if you don’t have somebody who can coach you and help you, guide you and at least you’ll start with something that will get you there. But then improve and focus on understanding more to build more so that it adapts and works toward your environment. PETER: Regarding the coaching, you coach within an organization. Do you coach the BRMs as well or…?
AARON: Yes. I do two-fold. One, I work for a company. I coach internally and I do transformations for about six divisions of T Rowe Price, so I’m responsible for transformation, if you will, from an Agile perspective, about 3 500-4 000 people. In there we have BRMs who are both named BRMs and then we also have a lot more people who have the BRM capability if you will. They might be in a job called business relationship management, but a lot of the role that they play, a lot of the things that they do, they have to focus on having strong capabilities. So I coach them and help them transform, change mindsets, and things like that. And then also, being on the board and part of the BRM Institute, I often speak with a number of BRMs who reach out and have questions and would like to get some insight on certain specific areas or things that they have. I also do that as well, to help understand what they’re going through and things that they’re dealing with and provide guidance and insight as I can. PETER: Without saying names, can you talk about some of the challenges you’ve encountered and how you’ve helped them? AARON: Absolutely, yes. The biggest challenge that really– I want to say there’s six or seven different BRMs from different companies that I’ve worked and helped over the last few months– the biggest thing is really exactly what we started out talking about. Helping them get a way to talk about the fact that business relationship management is different than Agile and being a product owner or Scrum master or something like that. To really explain the value and the difference between the two. Through all of them, that’s been one of the conversation pieces. And then the second piece that all of them have had conversations about have been “How do we work together? How will the BRM group work with the Agile, whether it be technology folk or business folks. How do we actually have that conversation and say this is the way that we can work or should work or go about figuring out how they should work?” Those would be the two big things that a number of conversations are around is figuring out how the two can work together because, very often, outside of business relationship managers, the thought is that once you go Agile, you don’t need this anymore or we’re going to convert all of them into this group because we don’t need that.
PETER: That’s what I hear from some people in the market as well. That’s predominant. Some of them are really scary, actually, that they suddenly start to realize “Hey, they’re going Agile and they don’t need us and what is our role?” Anything else that came up that maybe more on a detailed level, that you say “Hey, that was a challenge.”
AARON: The other thing that’s coming up is that when I talk with BRMs, they are really interested and want to understand Agile more detailed and better because part of what they have to do is they have to work with these groups and have to work with these teams. I’ve had conversations about the idea of utilization versus throughput. I’ve had conversations with BRMs on “My companies applying SAfe, what does that mean for me and how do we work in that regard? What do we do with that?” I’ve had conversations, some where it’s Lean. So it’s a Lean conversation where they’re saying “Hey, somebody’s told me about Kanban and they said we need to put up a Kanban board. What is Kanban, what does that mean?” The other part of it, if I grouped it all together, is just more knowledge and just more understanding and what it means to be in an Agile environment and an Agile group and when somebody says “We’re going Agile, are there things to watch out for? Are there things that we should read or find out or places we should go to get more informed?”
PETER: What are some of the sources that you normally use? That’s of course the question I immediately go to. AARON: (laughs) Right. What I say is that obviously there’s a number of podcasts out there. There’s Lean Startup podcast, there’s Agile Startup podcasts. There’s some of those things there. But also actually something very interesting and a place you can go is Harvard Business Review actually does a bunch on Agile and teaming and things like that. And they have a number of free articles that you can do. Forbes does a number of items as well, that you can do and look at. And then you have things like Medium, if you go to Medium, which is kind of a blog amalgamation site, I guess would be the best way to say it. They have a number of authors that write on it. So that’s basically what I do is I’ll start with that and then they’ll reference something or somebody else and I’ll follow up and go on that. Go further through and just keep reading and understanding. PETER: You mentioned earlier, ‘transformationalist’, which I wrote down because something like this, it’s a great word.
AARON: (laughs) I’ve got to earn my money somehow.
PETER: Transforming. Everyone’s talking about digital transformation. I’m talking about it as well. I see the transformation happening within organizations, from being more that sort of provider to becoming more of a value-focused organization where everything is around value. I work with a lot of BRMs ect. I think, to be honest, strategic partnership is a requirement when we actually get to digital transformation. Your transforming organizations– from an Agile perspective– I think is the same. You’re trying to accomplish the same things. What are some of the things that you have really seen as successes from the work you’re doing in transforming the organization?AARON: The biggest success and the biggest thing is obviously delivering more business value. Being clear on what that business value is and delivering more business value.
PETER: Before we go on to that, do you feel that it’s easier to get more value out of Agile than from waterfall? AARON: In certain instances, I do. I would tell you that there are instances where it doesn’t make sense and waterfall actually does make sense that you can use a waterfall approach– they’re very few, but they can– I would say they can but in a broader context, really as an organization, what you’re looking for is higher agility. Which is one of the reasons I’m a transformationalist versus a coach or things like that is that really the focus should be on increased agility, overall agility. And it shouldn’t just be on Agile itself or on this method or framework or things like that. It should be, as a company, how do we get more business value? How do we deliver more business value that’s higher quality, that’s faster, that’s more predictable, and is repeatable. Agile is a portion of that, but there’s a whole lot more outside of that and often people get mired into camps. “I’ve got this discipline,” or “I’ve got this methodology,” or “I’ve got this framework,” or these things. And they lose sight of that overall picture of saying “No, we’re actually trying to deliver more value in a more effective and efficient way.” And I think numbers bear doubt and information bears doubt that doing an Agile, and take the name out of it and saying smaller increments with clear defined value where you team and you have a clear objective and you know how you’re going to figure out or test whether or not you got that value. Whatever you would call that, I think we all can agree that that’s the right way to go. Now if you call that Agile or if you call it whatever, that’s the right way.PETER: Okay. And that’s immediately showing the success mostly from business value perspective need as well. AARON: I want to add one thing too, which I think is important. You asked me that question about ‘transformationalist’ and transformation. A lot of people are saying they’re going through transformation and this is one of the things that I talk to a number of the BRMs with when I talk to them about that is the idea that often you hear transformation language. People say “Yes, we want to change our culture. Yes, we want to change the way we do business and we want to do all these grandiose, great things and really transform an org,” but when you actually look at the approach and what they’re trying to do, it’s really more of an implementation approach where we’re just going to plug some practices in. We’re just going to do some other things. We’re going to kind of lay on top of what our existing org and culture stuff is and call that transformation. And that’s really often a challenge, whether it’s BRM or Agile or anything else. It’s that if you truly are transforming, you’re truly trying to change the way that you do your business and run your business, and you have structures, you have to actually do that. You don’t have to do it all at once in a big bang explosion if you want a light switch type of thing. But you do have to have a vision of that, and then you do have to be working toward it versus just saying “We’re just going to layer some practices in, or some mechanics in on top of what we do. Maybe twist a couple of things differently and call us transformed.”
PETER: I think one of the key part that a lot of people actually are missing is the changing behavior that is required. That’s for a lot of people. Something like “I don’t know what to do with that.” One of the things I’m doing, I’m writing the book on value management basically for the BRM Institute, and one of the things I constantly encounter is “Okay, it’s totally different behavior that we’re looking for.” By looking at that behavior, how is that going to change? We might be able to actually get the transformation happening, but I see too many people in the market at this moment just throwing technology at stuff just to make sure and that they’re hoping that will have some result from that. That’s just frustrating sometimes, as well.
AARON: Yes, absolutely. PETER: Let’s briefly talk about behavior. What is some of the behavior that you say that needs to change? AARON: I think some of the behavior that need to change would be the, what I would say, control mindset, if you will, of “I need to have this,” or “Somebody has to report to me,” or “I have to have some type of control and manage it.” If you look at the Kotter Institute, they’re the premiere people on change management. They look at it and they talk about about change management and change leadership. Change management is what you do if you want to limit change, control change. You put a person in charge of it and they govern that change. Change leadership is something where you put a small group together and you set guardrails and you allow those people to drive change and it’s actually exponential change. It’s explosive change, meaning you move a lot faster than you would if you did otherwise. And it’s really more about setting a structure of autonomy of like “Here are the things we’re going to focus on and not and that are out of bounds.” So really focus on leadership versus management is one of the behaviors that needs to change. One of the other things is we’ve gotten away from, what in the Agile space we talk about, a tolerance for ambiguity. Everybody needs to know to know clearly, ‘sign on the dotted line or else you’re going to get in trouble’, five months from now or six months from now. There’s very low tolerance for ambiguity. From a project perspective, I have to tell you today based on this limited bit of information that you’ve given me– that you aren’t really sure what it is that you want and need– that I’ll be able to deliver this to you in seven months at this budget with no change. And there’s no tolerance for the fact that it’s progressive elaboration. Things we’ll find out as we go forward. I know the least amount about whatever it is I’m asked about or working on today. Tomorrow, I’ll know a little more about it and the day after, know a little bit more about that. The ability to delay some of those decisions until the last possible responsible moment. Saying “Well, if we don’t need to know that answer for two weeks and make a decision for two weeks and we’re still okay, well then let’s wait for that. Because that will be when we know the most information.” And those are some of those key behaviors that really have to start changing and focusing in a different way or saying “I need to know enough to make this next decision.” One of the other behaviors that needs to change is the idea of having something, putting so fine a point on something that you don’t have to at that certain point. If we can whiteboard something and come to an agreement based on that whiteboard versus having to write a document and get 57 people to approve it and make 12 different rounds and make sure the whole world is signed off on something, then let’s just whiteboard it and get to a point where we say “Hey, this is good enough,” and now we can start circulating that stuff and getting more feedback and more information and more insight from other people. But we don’t have to do that formal structure right away. PETER: That aligns to some of the things I’ve been reading recently. I’ve read a book from Jurgen Appelo around Management 3.0 and one of the things he says is “We’re living in an age of complexity,” and I think exactly what you just said as well. You will not have all the details. You will have to take it a step at a time to be able to actually get to the next phase because new information will be unearthed to be able to make a better decision for the next step. And that’s a totally different leadership style, absolutely. Do you have any questions for me? AARON: I do, actually! You said you’ve been reading Reinertsen a lot lately. It took me about four months to get through The Principles of Product Development Flow and I was a good soldier and kept slogging through it. From your perspective, what do you think are the overlaps or the things that BRMs and the Agile methodology or Agile-ists see in common or differently?
PETER: I see the need for being more strategic, and that’s what we talked about already. The reason why I started looking into product management, really, is that I see a move away within the market around less being a service provider, more being in that strategic partnership where we’re talking about products that support a team. And a team that is both business and IT skill sets combined. And quite often, that is where I see the need for product management and a different approach to how we’re doing things.
One of the frustrating things I find with services, we do a lot of service definitions, but when I look at product management–that’s why I started to read Reinertsen, the product flow. I didn’t get through all of it. I still have to. (laughs) But some of the things like economic life cycle of a product’s features, for instance, I hear a lot of BRMs struggling with “What is the cost of an additional feature? What is the value of an additional feature?” For me, reading into value management, I find that the whole product management policies from Reinertsen fit very well into the whole value management side. But it’s a different thinking than what a lot of BRMs have been doing right now. A lot of BRMs at this moment are mainly only looking at “Okay, what is the cost of this overall change that we’re doing?” And we’re looking at ROI, but we’re actually but we never really look back. And when you start looking at measuring value, you find that you need to have a better understanding of product management. That’s where my interest came.
It started with How to Measure Anything by Douglas Hubbard. That’s a great book, but every BRM I tell to read this, they come back and say “This is difficult.” (laughs) “Takes me forever to get through this.” And I have some that are like “Yeah, I’ve read it three times now and I still don’t get that completely but let me do that, but that’s really where my interest came from. The value measurement, measuring intangibles. Through that, I found that having a better understanding of product management and policies around that, that got me the understanding of “Okay, which direction do I need to take?” And that’s where a huge growth market is from a BRM perspective because we don’t see a lot of BRMs having that skill set at this moment. That’s what I’m looking at.
AARON: Perfect. And what I would say, to add on to that, if you’re a BRM and you want to be able to prove your worth and some value pretty quickly, find a way to identify and quantify in your organization, the cost of delay. Be able to say “If we do this versus this, this is what we’re potentially losing out,” or “If we wait X amount of time”. Reinertsen has a great intricate formula that you could leverage. I guess you might probably have to be a mathematician like he is, an economist, to be able to do it, but even if you just define it in your org as “Hey, we said the value is this, and we’d get it in this much time.” You just divide that and say every month we wait, this is potentially how much we’re losing. Get to a basic way of identifying the idea that there is a cost of waiting to deliver value. That’s a huge step forward in being able to increase agility and prove your strategic value and your strategic thinking capability. PETER: Absolutely. And I’ve worked with certain BRMs around that, where we talk about “You’re supply-constrained.” When you’re supply-constrained and you say “I can’t find a manager for three months,” what is the cost of delay on that and go back to the business and lost that. When they say “A couple of million dollars,” then maybe we should find a project manager. (laughs) Awesome. It was great talking to you, Aaron. Really good information and I loved your thing. I have a feeling we can talk a lot longer, and maybe we should have a second session eventually where we go into even more detail. Thank you very much for doing this and I’m looking forward to hearing some of your presentations around this topic. Thank you very much. AARON: Sounds great, thanks Peter.