Michael Jebber (00:06):
Hello everybody, and welcome to episode 44 of Agile Meridians, Agile shorts. And we will do our best to keep this short, short that's, well usually one of our challenges, right guys? So I'm here, I'm here with my partner
Kumar Dattatreyan (00:20):
Here, .
Michael Jebber (00:22):
I'm here with my partners partners in business and crime, and we're here today to talk about the roadmap. Why? Because it's on the roadmap, dammit. That's why. And this topic is one that we run into a lot. We thought this would make a good short. It's something that is very often misunderstood and misused inside of especially lo locations that are coming from a more traditional planning and project based mindset and operational structure. And it tends to take people in the wrong direction when it really shouldn't. It's, it's, it's, it's really a valuable, useful tool, but it's only valuable and useful if it's used as it was intended to be used. So I'm gonna open it up to our our, our esteemed panel of colleagues here to talk about what is a roadmap and really what is the, the intent of a roadmap, Why does it exist and what was it meant to do
Kumar Dattatreyan (01:21):
Before, before we answer, did you say steamed colleagues? Ok, got it, Got it. ,
Michael Jebber (01:30):
I guess there are days where we are a little, but you know, it's not today. Today is it's a pretty relaxed day, so
Kumar Dattatreyan (01:36):
. Yeah. Yeah. So, you know, I, I'll just share this short story. Well, that's not a story, but just an experience. One of my, one of our clients they're moving to an agile way of working and they've it's a, it's a big modernization effort, a digital transformation effort, and they're trying to move all of their legacy applications to to the cloud, right? You know, better, more easy to maintain, and so on and so forth. Moving off of old legacy software into something new. And so they created this roadmap, and the roadmap extends out four years, and they did all that work without the advice or collaboration from the technology teams. They are gonna be actually doing the work. So this roadmap has been created, it's sort of, you know, etched in stone and with, before they even had teams. And I don't think that was the, that is the intent of a roadmap. It's
Michael Jebber (02:36):
Not the way that, that I was taught that it was. So I dunno, what, what of you guys wanna kind of chime in and say what your what your understanding of what a roadmap is intended to be?
Jolly Ranjan (02:47):
So I'll, I'll, I'll take a crack at it. I mean, it's, it's in, in my view and the way, and the times that it just worked really well, roadmaps have been a way to, to showcase or at least lay out the value that you're going to deliver to your, to your organization and to your customers, obviously. And how, how do you, how do you plan to get there? It is not a plan, right? I mean, it is part of the planning process but it is essentially a way to put the outcome that you are planning to deliver in the strategic context of the environment that you are in.
Chris Daily (03:28):
Mm-Hmm. .
Michael Jebber (03:30):
Yeah, absolutely. That's true. And, and, and this, this concept is, is a little foreign to folks. A lot of, a lot of companies that we all work with and we know others have worked with, really have a hard time understanding the difference between that and the way that they have been operating traditionally around a project plan. And, and in the example of what Kumar was giving the, the very long multi-year etch in stone, this is what we're going to achieve come hell or high water approach to getting work done.
Jolly Ranjan (04:04):
Right?
Chris Daily (04:05):
And I I, I wonder how many times they don't, or I wonder how many times they actually achieve the roadmap that they lay out, right? I mean, you know, it used to be that you could plan things out years in advance and you could try to execute to that. And in today's environment with things changing so dramatically mm-hmm. , you know, I, I don't know how people can expect to have a view into what next year's gonna, you know, what next quarter's gonna look like, much less what next year is, you know, And I try to encourage 'em to, to plan things out on the roadmap at three, you know, the next three months we're pretty sure of the next, you know, four to six months. Yeah. We're kind of sure, but you know, we're, we're, they could move. And then everything is kinda a big blob, right?
(04:58):
Because it, it all changes and let's just admit that it's gonna change, right? I mean, I think that they, if we would take, if they would take the time to revisit the roadmap, we'd get away from what Kumar described, right? I mean, unfortunately, what Kumar described about his client, you know, I've got two clients right now that are exactly the same boat, right? They do, they think exactly the same way. And I got a third client who won't, they don't do roadmaps because of what Kumar's describing. Hmm. You know, they don't wanna put, they don't wanna project anything out and give it,
Michael Jebber (05:32):
They're worried that they're going to get held to it in that way. Exactly. Yeah. What do they do instead?
Chris Daily (05:38):
They don't, they, the leadership talks about what they want and they just go, they just interest it's all which, which is not, you know, it's not very clear on what's happening. Sure. Right. And so the team is misaligned on what's, what's gonna be going on and what they're gonna do. And you know, it yeah, you, you put it up on the screen, right. That they're using it as a project plane, if you will. Right. It, they don't have their Gant charts anymore, so we're gonna use roadmaps
Michael Jebber (06:09):
Just in replacement. Right. I think, Chris, you said two important things. Visibility first and foremost, Right. Without it, the, the idea is to pre present visibility to the entire value chain around what that, as jolly described it, what, what that intended value delivery looks like over segments of time with it becoming less detailed as you go farther out because you don't know what's gonna happen. Right? Right. And I think the idea of revisiting it and the fact that it isn't static is, is the other key point. It was never intended to be that way. It was always intended to be a, a working model towards the most relevant things going on, taking into context what is happening and what has changed since we originally looked at this thing maybe a week ago, a month ago, six months ago, or whatever. So
Jolly Ranjan (06:56):
Yeah, I think, I think what, what all of us are saying is it is, I mean, one of the core tenets of being agile is the iterative and incremental approach to building things in general. And what we are all saying is roadmaps are just the same way. Right? Right. And this is something that we see in a, in a very narrow context as well. And between the four of us, we have all run our agile product owner training from IC Agile shameless plug. And, and one of the things that the students in the class realize is create a roadmap. Then you go and explore the impact and the story maps following it. Oh. And then it comes to them, Oh, we have to go back and update the roadmap now because we know
Michael Jebber (07:42):
More. You learned more, right? Yeah, yeah.
Jolly Ranjan (07:44):
You know more. And you had to feed that back in. And if you remove that static component from the roadmap and make that itself incremental and itri, and use that as mostly a communication tool rather than a planning tool, I think everyone is much better off.
Michael Jebber (08:02):
That makes a lot of sense. Not making in the variability or the adjustability to it would be doing it a disservice, cuz it really would become a whole lot less agile now, wouldn't it?
Kumar Dattatreyan (08:12):
? Yeah. I love, I love what you, the way you said that is, it's more of a communication tool rather than a planning tool. Right? And that's how it should really be because Scrum and Agile are, are really discovery frameworks. You might plan to do something, but then you discover that what you plan to do isn't feasible or it's gonna take more time. Or, you know, you, you, you don't have the technology infrastructure to, to do what you wanted to do and you didn't realize it until you actually peel back the onion and, and, and saw what's needed, you know, saw what, what's really needed. And so because Scrum and Azure are discovery frameworks, it allows you to discover things and then solve for those problems. Organizations that are more mature are are focusing more on what is the capacity of your team or your ad your team of teams to, to deliver value.
(09:02):
And there, there might create a forecast of outcomes that they want. They, they should do that, but then revisit that all the time so that the roadmap becomes more of a communication mechanism to indicate to everyone that this is where we think we are over the next three months, six months, nine months, and 12 months. Knowing that the further out you go in time, those are really just forecasts. It's not, not a commitment. And that's, that's the big challenge is to convince folks that especially in, in organizations that are less mature to, to, to understand.
Chris Daily (09:37):
Can you, Kumar, can you clarify what you mean by mature? Because a lot of the times the organizations I work with, the more mature in terms of age, the longer they've been around and doing things the same way, the more they have a roadmap issue. So could you clarify what you mean by more mature?
Kumar Dattatreyan (09:56):
No, I don't mean o like us. I mean, I mean like I, I'd say that organizations and the people in them we're talking about people after all. Right? Right. Who have adopted a more of a, an agile growth mindset, right? That understand that you can't possibly know something that is gonna be delivered a year from now. You can't, you can't possibly know that to be, you can't even know whether that's something that you need a year from now is gonna be needed a year from now because things could change, be
Michael Jebber (10:30):
Obsolete or less not valuable enough. Right? Right.
Kumar Dattatreyan (10:33):
And, and so when I say more mature, I mean organizations that have embraced adaptability as a capability. So they understand that they need to be adaptable, they need to be nimble, they need to forecast the outcomes that they're looking for, but willing to adjust the plans on the ground to to deal with the changes that are happening in the marketplace place.
Chris Daily (10:56):
Well said.
Kumar Dattatreyan (10:59):
Thank you. Mic drop. Boom, .
Michael Jebber (11:03):
So with that how would we, what would you suggest some people do in terms of some of these issues, right? If, if someone is experiencing some of these things which could also include not having the backlog built by someone on the business, not having it managed or, or kind of flushed and maintained and, and reorganized rehydrated from someone with business and, and outcome knowledge around the, the organization itself, not just the tech or, or, or the how side. What would you suggest that some folks do to improve some of these situations? Maybe just pick one and say, you know, in this case you might want to think about this
Jolly Ranjan (11:41):
One. One of the things that I definitely recommend to people that I work with is to make the roadmap outcome focused rather than deliverable focused, right? You, you don't want to put how you are going to achieve a desired outcome on your roadmap, but instead focus on the outcome itself so that your team as a whole have options to consider when you go for that outcome in that, that timeframe. It, it gives them options to op explore simpler ways of doing things or explore totally different ways of achieving the same result. So focus on the outcome is what I would do when creating roadmaps.
Michael Jebber (12:26):
You know, one thing to add to that jolly is that a Roman pitchler out of of Germany has been doing roadmaps for a long time and he has a a roadmap pattern that he uses called the GO roadmap. It's for goal-oriented roadmap, is what it stands for. And it's, it, you find a pattern like that to utilize if you're not using one that has goals in it, if it's just delivery focus, that could help you out as well to keep that at that goal-oriented focus on there to say, what are the outcomes that I'm looking for versus what is it that we're just trying to achieve in terms of deliverables?
Kumar Dattatreyan (12:58):
You know, it's, it's difficult though for people to shift their mindset from outputs to outcomes. Mm-Hmm. . It's, it's a real challenge for people even, even after they've been through workshops and training and things. It's, it's it's to Chris to your earlier point, you know, mature maturity can be thought of in one of two ways, right? So maturity is, I've been around in this organization forever and, and this is just the way things work around here. And you're stuck in a certain way of thinking that's mature also. It's just, it's just, it's the wrong kind of maturity because you're less open to different ways of doing things. So how, how would you help people shift their mindset from output oriented thinking to outcome oriented thinking?
Chris Daily (13:49):
I don't know. I haven't thought about that yet. It's a good question. Does anybody else got any ideas while I sit here and a minute?
Jolly Ranjan (13:58):
Another shameless plug here. As part of the AP Agile product owner course that we have, what, what the, the path that we take on take our take, take the attendees is to not just focus on deliverables, but to take a path to get there, right? Which means focusing on the outcomes first before you talk about the roadmap itself and talk about outcomes and customer outcomes and business impacts separately just for that reason. What is the outcome that the customer is looking for? And what is the impact on your business, which is what value is, right? Right. And, and based on that value, both the highest priority value, which could be highest outcome and highest impact on, on the roadmap, the earliest, so that you can deliver that outcome and get the maximum business impact that you're looking for a feasibility analysis could go along with it come out to your point when the delivery teams are not even involved in the, that really means a set of false promises rather than anything else. So involve them, do a feasibility versus value analysis and then put those outcomes on your roadmap which gives you a be much, much better chance of success.
Michael Jebber (15:27):
Yeah. You can use a com a little more detailed, kind of in depth way to come out with those outcomes with using leading and lagging indicators and different metric measures and some other things. In fact, our APO course, another shameless plug also help guides you through how to do that as well. And it's part of the process of getting to building a roadmap is finding out what those outcomes are before you even put the map together. Yeah. But there's some simpler techniques if you just want to try it. Even five why's, which most people have had experience with in the project world for a long time. Even if it was only through doing an RCA or an after action report or something like that where you're five ying a challenging situation or a problem, you can five y down to outcomes. You could say, Well, we're trying to do this and you can come down to some of these outcomes as to the real reason why you are doing something. And that could even be a simple way to just put high level outcomes together early and then figure out what things do, are we planning on doing that drive to these outcomes. So, so there's some simple techniques you could use. You don't have to be highly detailed, but there's a lot of different methods to go after
Chris Daily (16:35):
That. You know, the as as you're all talking, right? The thing that pops into my head is the reason why I think a lot of people don't want to go to an outcome based approach is I'm accountable. You know,
(16:54):
I put the business plan together and I've said, Well, we're gonna re, you know, we're gonna improve revenue by 10, 10%. Right? Well, that, that now they've got a milestone to go against as opposed to, Yeah, we're gonna increase revenue, right? Oh, we increased it, we put, you know, $2 million into this project or this effort and we, you know, we achieved a hundred thousand dollars. Woohoo. You know it, it's really, you know, going back to the organization, you have to get that accountability in there and figure out a way that they can do that safely. Cuz a lot of organizations, man, as soon as you put a number out there and you miss it, you're gone. Right.
Michael Jebber (17:37):
Or that's, that's psychological safety. Chris, you were talking about that group that you said that doesn't do anything. Yeah. Because there's no psychological safety in their group that they would feel comfortable in saying something and not be held to it. Right. And they don't, don't feel like they have a way to be able to accurately do that. So they're not gonna be held to anything, just not tell anybody anything. Right. So yeah, I think that environmental structure that sometimes a lot of times doesn't accompany the techniques that we add or the tools that we add can really cause those tools to underperform. Yeah. in many cases,
Kumar Dattatreyan (18:12):
I think you're on to something there. I think the reward models also prevent people from thinking in terms of outcomes, you know, and people are, are rewarded on the outputs that they produce. Right. It's easier just to think about, Okay, I'm gonna produce so many widgets rather than, okay, what's the outcome of the widgets? How will the customer use those widgets? Or, or is that even being, even being measured, right? So there's so much value that's lost because, you know, we're probably working on the wrong things or things that don't create a business impact or a customer outcome. Right? And so if we were able to, you know, I know the, the topic is really, it's on the roadmap, dammit. But, but it's, it you know, when you start to peel back the onion of that statement, it's on the roadmap.
(18:58):
Dammit. There's, there's a lot that goes into why people say those things. Yeah. You know, typically people I'll hear stuff like that from, from a, an executive or a business leader saying, Well, it's on the roadmap. Why isn't it built being built? Or why is it late? Or it's on the roadmap, dam it, why, why wasn't it done? Right? And, and that's because that's because, you know, it's again, those more mature organizations, you know, steeped in the way of doing things, an older way of doing things, aren't seeing the value of, of or, or they're not rewarded really for thinking in terms of outcomes for whatever reason. There's a lack of psychological safety. They don't want to be held to the chopping block if they don't, you know, meet those outcomes. Although I'd have to say that the outputs aren't getting mad either. So how are people surviving? You know?
Michael Jebber (19:50):
Yeah. You have that idea about, about me, the value being matched up with delivering value versus the value being matched up with completing the plan. And that changed. So once again, we have taken an agile short and made it an agile along. So we'll go ahead and stop here, but I wanna thank everybody for attending. Thank you for our panel for all of your input and knowledge, and we'll see you at the next Agile shorts.
Kumar Dattatreyan (20:17):
Awesome. Great. See you all. Bye. Bye. Bye.
This transcript was exported on Feb 24, 2023 - view latest version here.
It's on the #roadmap, dammit! Discover how #agil... (Completed 10/28/22)
Transcript by Rev.com
Page 1 of 2
