← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Keeping Backlogs Lean With The Now-Next-Later-Never Roadmap Framework | Kent McDonald
00:41:41
BONUS: Keeping Backlogs Lean With The Now-Next-Later-Never Roadmap Framework with Kent McDonald In this BONUS episode, we explore the art of backlog management with product management expert Kent McDonald. As someone with decades of experience in...
Loading summary
Transcript53 lines
- [00:07]
Host
Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode, so stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon. Hello everybody. Welcome to this very special bonus episode. For this bonus episode, we have with us Kent McDonald. Hey Kent, welcome to the show.
- [01:13]
Kent McDonald
Thanks. How's it going?
- [01:16]
Host
It's a pleasure to have you. We're going to talk with Kent about why backlogs get too big and what to do about it. Kent has decades of experience in software product development. He's a go to expert in product management and agile strategy. Also a seasoned consultant and author of three books on agility. He helps teams cut through clutter to focus on what truly matters and when not optimizing workflows. He's been exploring national parks in the US that's 52 out of 63. That's quite a respectable score there. Or grooving to some jazz tunes. So Kent, we're going to talk about backlogs and why they get too big and what we can do about it. And this started because I saw a post from you on Substack and we'll put Kent substack link also on the show. Notes when you think about it from your experience, the work that you've done, what are some of the key reasons why our backlogs end up becoming too big and hard to manage?
- [02:23]
Kent McDonald
Yeah, I think there's a couple reasons for it. One of them is that a lot of teams have built up this work avoidance mechanism so that when one of their stakeholders or customers or something comes with a suggestion, they'll try and placate them by saying, oh, we'll put that on the backlog. Basically it's just a means of saying, you know what, yeah, we'll get to it. And then they never do because they never had any intention of getting to it anyway. So that's kind of the cynical perspective as far as why backlogs explode. The other thing is that is the case of actually diving in and splitting up bigger chunks down too soon, where there's this. And often that is a result of the team feeling that they need to know a little bit more about an item in order to size it. So if they're being asked how long is something going to take, and their usual approach to sizing things is get them kind of formed into user stories and then having a planning poker session, the team will go and do that and then they find out they're not going to be working on that for a few weeks, months, hopefully not years, but sometimes that even happens. Then the other thing is the backlog becomes the dumping ground, not only for stuff they get from stakeholders, but also the ideas the team themselves have is that they'll be sitting there chatting and someone says, oh, we ought to do this. Yes, I'll put it on the backlog. And then again, it just kind of sits there and festers, waiting for more action to happen with it.
- [03:55]
Host
Now, of course, we brought you to this episode, of course, to talk about what we can do about it. Right. And in that post and conversation on Substack, you, you mentioned using this Now, Next, later or Never roadmap to keep things manageable. Could you walk us through how that works in practice?
- [04:15]
Kent McDonald
Sure. So the idea behind the Now, Next, later roadmap, and then sometimes with never added on, came from Jana Bastow. She's the CEO and founder of Prod Plan, which is, strangely enough, it's a product management roadmapping software. But the premise behind it is instead of roadmaps where you're. Which technically wouldn't be roadmaps, they'd be more like release plans, where you kind of have things split out by quarters because everyone wants to know, when are we going to get it? The idea here is that you want to just kind of group things together based on roughly when you're going to attack them. So just like you size items in relative size, this is more looking at things relative time wise. So the now category is this is the stuff the team is actively working on right now that we're building and we're attacking those things. The next are the items that this is what we're intending to get to next when there's open. When there's space open up in the now column. The later stuff is these are things that we might potentially do down the road. But there's no saying that Just because it's in later doesn't mean it's actually going to happen. And then I have found the Never column can be helpful by basically being very explicit about these are things we're not going to do at all. We're just intentionally saying this is something that's really not intended for what we're doing right now. Now the nature of what these things are is they're bigger efforts. You're not going to be putting like any bugs that pop up on your roadmap. That's something for later. This is really an idea of kind of just giving a bigger overall view of what your intended work is. Ideally these things are more stressed in terms of outcomes or problems you're going to solve, more so than specifically features you're going to deliver. So we're going to tackle how we're going to do. X Next is kind of the thing that you'd have it at. You don't always get there right away. So sometimes it might be features you're going to deliver or bigger chunks of work that you're wanting to do so for. As an example, I was working on rebuilding an existing pricing application for an agriculture company. And so we went through and kind of got an idea of what the process was that we were doing, the data and the rules and all that. And then we split out the work to identify how we were going to attack it in the major areas of functionality of that tool. We kind of created in a Now Next later roadmap just to kind of keep track of where things were at.
- [06:43]
Host
Yeah, that makes sense. But there was something I wanted to understand better. So when you talked about the now, I thought you were going to say category, but you call it column. So let's dive into that a little bit more. What does that mean? Right, like you talk about having the now column, the next column, the later column. Are we talking about Kanban style, Kanban board style columns? Is there a limit to the size or the number of items in each column? How do you implement this in practice?
- [07:15]
Kent McDonald
So if you think about Now, Next later, it's kind of a reverse Kanban board. So the now call and I gotta make sure I'm doing this right. The now column would be over to your left, so it's the leftmost column that you got. And then you go over to the right for things that are going further out in time as opposed to Kanban, which is switched the other way around. You can or may not have a limit. Although if you really think about what the now column is so these are, like I said, these are things the team is actively working on. And for me, when I say that it's thinking of that, that's the point where we actually bother to split it down into smaller bits and where the team is doing active development work on it. That's kind of what my criteria are for things to fit into the NOW column. Other teams might have a little bit different ways of doing it. And that's basically especially since we're talking about keeping the backlog manageable. That's one of the ways to do that is you're not really creating more refined backlog items until you get stuff popping into that NOW column.
- [08:26]
Host
And the other aspect, if I understand you correctly, what you just said, is that the stuff that is in NEXT is not supposed to be broken down any further. These are big items that are outcome style items. So let's tackle those two aspects now. Ken, so you're saying only items in the NOW column get broken down and all items are described in terms of outcome. So translate that for us. What does that mean in practice?
- [08:59]
Kent McDonald
Both of those are aspirational things and they're guidelines. Sometimes you can break from that. And then in some cases I have started breaking things down as they're getting closer to the top of the next column. If we know we're going to be bringing them in, just that we can keep things running. As far as expressing things in terms of outcome, it's what, you know, it's stating things. It's like what you're trying to accomplish. So as an example, what I'm. The thing I'm working on right now, we're working on some websites that sell added services for people that own vehicles. And so one of those might be things such as we want to be able to make, make it enable changing price prices more easily. So we, we have a lot of involved calculations with our prices and a lot of attributes that we can change and levers we can pull to to make changes in the prices so that the item basically sitting there is how can we make that more flexible? The actual work underneath it is that we're trying to get such that we can change those variables without having to do code deploys. But the actual item is listed as making pricing more flexible. That's an example.
- [10:17]
Host
So when you talk about outcomes, you're talking about something that will be true once the work is done, but not the list of work items to be done.
- [10:27]
Kent McDonald
Right. And the reason you do that is it gives the team more flexibility to apply their knowledge and Figure out what's the best way to solve this based on where things are at right now and based on what we've learned doing previous things. So when teams identify specific features they're going to do or specific solutions they're going to build, and those solutions are identified way early on, what was true when they identified that those solutions may no longer be true once they're actually going and implementing that thing. So you're basically saying we want to accomplish this, but we want to make sure we're able to use the most up to date picture of where things are at in order to figure out what's the best way to do that.
- [11:11]
Host
And the other aspect that is interesting is when do you define that? Okay, this needs to be broken down. So, okay, you already told us that in the next column there might be things that are getting to the top of that column that you may want to break up ahead so that the team has some work to refine already. But how about the now column? Do you break down all the items in the now column? Do you break them down as you start working on them? Like, how do you manage? Because we still have the same problem as we had with backlogs, which is that your NOW column may explode in size as well. Right.
- [11:47]
Kent McDonald
Well, and that goes back to your question about limits as far as how many things can be in the column. So it might be that your NOW column has one thing in it because that's the entire focus of the team. Or it might be there's one thing in it because the team is also incorporating some things that happen, like addressing some production issues that come along, addressing some bugs that pop along, some smaller changes that don't warrant getting listed on the back on the roadmap, but certainly things that we want to tackle. So a. And this is, this is one of those things where the team has to kind of just have some little bit of discipline around it to say, we're not going to overload now with a bunch of stuff that we're going to work on. Let's use that to provide our focus. Which means your next column might be a little bit longer. Or yeah, it might be a little bit longer, but really kind of keeping it focused on. We're only going to really work on a specific number of things that match the capacity of the team in that now column.
- [12:42]
Host
And now, as you describe this, I also imagine that we may use historical data to decide what is in the now versus the next versus the lane later column. Right. Like, for example, if we say that Any average item in the next column gets delivered six months later, then of course, there's no point in overloading the next column because it doesn't fit the now, because then we are going to create a much bigger and exploding list of items also in the next column. Right. So this limiting the number of items in each column is actually something that needs to eventually be done for all of the columns in that now, next, later roadmap.
- [13:26]
Kent McDonald
Yeah. And by virtue of the items being expressed as outcomes on the roadmap, you're inherently keeping the number of items that are going to pop up lower. Because one of the other things that contributes to exploding backlogs is having a lot of different ways to solve the same problem, sometimes might be one of them. And so if you're just saying we want to tackle this problem and just leave it at that for the time being and say we'll dive into more detail on it when we get closer, that inherently prevents backlogs from exploding that way as well. Or if again, you're not splitting them out into smaller bits too soon, that helps keep things to a manageable number.
- [14:12]
Host
And the other aspect. So that's a great tip, by the way. Right. Like expressing these items in outcomes is already a great way to reduce the risk of explosion in your backlog. But the other aspect I was thinking is, okay, but then how do we move items from one column to the other? Right. Because when we think about, for example, the now column is the stuff we're handling now, but how do we decide to move stuff from next to now or later to next? Is this really just kind of a kanban queue that has limited size and when one item comes out, another one pops in? Or how do you manage that in practice?
- [14:52]
Kent McDonald
To a certain extent it is that. And the other thing with the next and the later and the never columns, those are effectively there for expectation setting. So your particular team might say, you know what, we're going to kind of use the next column to set expectations about within the next three months, next six months. These are the things we're thinking we're going to work on. And then later is everything after that. Or you may have a narrower or wider time frame, but that's kind of a way for you, for the team to figure out what kind of expectations do we want to set to let people know? This is what. Right, as of today, this is what we plan on working on next and things are going to flow. And when I've used this mechanism before, things have gone from later to next and Back to later, depending on the situation and what overall things are happening in the environment and what are the problems we think we need to solve and what we think we need to solve next today may change a couple of weeks down the road.
- [15:58]
Host
So what you're saying is that items can move columns because it gives stakeholders a much clearer set of expectations of what is actually going to happen. Right, Right.
- [16:09]
Kent McDonald
Mm.
- [16:10]
Host
And one of the things that I was. I was considering, as you were describing, is, okay, but is there, like, kind of a process, like every month, every three months, you review the items, or is this something that happens all the time, and then if it happens all the time, then, you know, how often is it once a week or once every two weeks or whatever? Like, how do you keep that backlog? Assuming the columns have limited size. Right. Like limited number of items per column, how do you keep that constantly up to date? Because we certainly don't want to do a Now, Next, later only once a year, right?
- [16:45]
Kent McDonald
Yes. Although people do. I wouldn't recommend it.
- [16:51]
Host
Yeah, that's the unfortunate reality. Some people end up doing the now, next later only once a year. Yeah.
- [16:57]
Kent McDonald
So when in a previous gig that I was working on, where we had a. Was working with a particular business unit, we made it a practice to kind of visit the Now Next, later roadmap explicitly, roughly monthly. If you find it careful, find it useful, you may find that a good activity to do during Sprint reviews might be a quick, let's check the now next, later. Let's check the roadmap to see where things are at and if they need to be moved or whatever that might be too frequent or. So maybe it's every other review or something like that. You kind of have to, I would suggest, definitely building a habit around it, but the habit you build really needs to vary depending on your situation. So with the gig I'm on currently, I kind of make it a point to check it out about roughly monthly, But I might be glancing at it more frequently than that. It just really does vary on the frequency of when new. Hey, we ought to do this. Come popping into your vision. Yeah.
- [18:13]
Host
So I think that you made a great point, which is that if a stakeholder comes up with a great idea, whatever that might be, that we can then translate into outcomes and add the roadmap, then of course, we're going to review the roadmap at that time. That's clear. But there's a lot of, let's call them smaller decisions, maybe that even teams make on their own, and when they don't have that view of what's coming. They may make those decisions which contradict something that is later on in the later or even next column. Right. So I think that one of the things that you said of building the habit of regularly looking at that now next later roadmap is actually quite important because it's one of the goals of having that kind of roadmap is that it makes it much easier for us to visit the expectation of future deliveries than if you would have had. If you would have everything in a very large backlog.
- [19:05]
Kent McDonald
Right, right, yeah. It provides things. And the best thing. And the best thing about the now next slider backlog or roadmap is it's much better suited for talking with stakeholders, people outside the team who aren't thinking at the level of detail that backlog items usually end up being at. So it's in fact, the previous gig that I mentioned, we had, the main business unit director that we were working with and building products to enable had a habit of coming up with all kinds of ideas. Some of them were great, some of them not so much. So whenever he come up with those things, we found that it was very helpful to use our roadmap to have discussions about. Okay, so you've suggested we had to tackle this thing next. Where does that fit in relative importance compared to these other things that we've lined up to tackle next? And one of the things we always made sure of doing is that we pretty much kept now sacrosanct, meaning if we started working on something, unless there was something that we found that it didn't make sense to continue doing it, we weren't going to necessarily hamper progress on that. And so those discussions were usually. Are we switching things between next and later? Right. Because once we kick things off, unless there is something that's saying no, there's something is extremely important, we really want to make sure that we get that done right, finish that stuff off once it made it to the point of being in now.
- [20:33]
Host
And actually, you're making a great point, we need to make sure that the now column is kept to whatever limit we said it was going to be kept and that it's not constantly being reshuffled, because that would, of course, kind of defeat the purpose of having a null column. But that also highlights how important it is to often revisit the items in each of the columns. Because if we never revisit, there's going to be even higher pressure to shuffle the items in those columns. So what are some of the triggers that you would say, okay, if these things happen, then we must sit down and look at the now, next, later roadmap and make sure that is still coherent.
- [21:14]
Kent McDonald
So most of my career has been working with internal products. So it's things we're building to support business processes. There may be customer interaction, maybe not. So things that have always proven it's time to have that discussion is if any new surprise regulations come into being, that we have 60 days to meet this particular regulation. If we're finding that there is. And hopefully our business unit is doing a lot of measurements and keeping track of how things are going. If there's a sudden change in the performance of the process, that we say we got to make some changes to fix some issues that we're running into that might encourage things to change. If there is a new opportunity to introduce a new product, a new service, or revise the process to improve things, even better, that might be another reason to shift the order. It's basically what changes are there in business conditions that we need to address, opportunities to exploit our problems to solve that kind of change the overall perspective of what we were doing compared to what we did when we originally put the plan together.
- [22:27]
Host
So this talks about two different types of or actually even three. Right. Like ad hoc requests may require us to look at the balance of things in the now next, later columns and see does it make sense to take it now. Should we reshuffle something then regular cadence of reviews like, you know, once every sprint, once every two sprints, looking at it. And then also this kind of larger maybe resets or refocusing that happens as normal course of business where we might say, hey, our strategy is about to change. We should look at the now next later and review that it's still aligned. Or if not, then change the items on those columns. Right?
- [23:09]
Kent McDonald
Yep. So, and some of the things that show up might feel like ad hoc, but might also be described as business changes are. I've been in a few organizations of late where executive leadership is looking at the overall picture of the organization and saying, we got to make some significant changes. And so you have these proclamations coming down from on high. They're completely shifting up what different business units are doing, completely shifting their focus. And in cases like that, you have to react. Be able to react to that pretty quickly. Right. So that's another thing that would come into play that says, oh, we need to change what we're doing. And then what the nice thing about the roadmap is that things are high enough level, but hopefully everyone kind of knows what, what, you know, what the intent is of those things, so you can have the discussion about, okay, so now we're hearing that this is very important. How does that relate to these other things? And we know we can't get all of this done, which it's important to go in those conversations with that explicit mindset that we can't just keep adding stuff in. So what needs to go out from here to satisfy the things that are popping in.
- [24:23]
Host
Yeah, and that kind of conversation is so important. Right. And we hope that introducing something that like the now, next, later triggers and facilitates those conversations rather than, you know, puts us in antagonistic positions where we can't help each other anymore. But before we can get to the now, next, later roadmap, we have to face the reality that many of our teams are already swimming in backlog items. So if you would have to help a team that is in that kind of situation where the backlog is unwieldy and really long and hard to have conversations about, and you wanted to help them move towards this now, next, later style of backlog, where would you start?
- [25:12]
Kent McDonald
I have had the opportunity to, because back in the day I was an agile coach for a while. And so one of the things when I was coming in and starting work with a new team, depending on how large their backlog was and if they were complaining about how hard it was to manage and everything, I would probably, I would look at them with a completely straight face and say, well, you should burn the backlog.
- [25:35]
Host
That didn't make too many friends, did it?
- [25:37]
Kent McDonald
Select all delete. And then I gauged their reaction to that as far as, you know, what do we do next? So oftentimes, if they grew very panicked by that suggestion, I would say, well, what you could do and what I've done before most tools have this capability is I would set up a status that doesn't show up on the board display, like removed or something, and say, move everything to that so you don't have to keep looking at it.
- [26:04]
Host
And then I call that the museum.
- [26:06]
Kent McDonald
Right.
- [26:06]
Host
Like you can go in and look at the artwork, but you don't need to live there.
- [26:10]
Kent McDonald
Right. And basically, so you talk through the fact that it's actually okay to remove those items from the backlog, basically because they're not getting done anyway and you're not fooling anyone to think that they are going to get done. And I basically have that conversation as just as a kind of to level set that says just because it's on the backlog shouldn't mean it's a guarantee that it's going to get done, because in real life it's not right. And if it does, by the time you get to it, people have probably forgotten they've requested it and it's not going to have the impact it was originally thought to. So then to go in a little bit more productive manner, it would be just sitting down saying, what are the big chunks that what are the main outcomes, main problems that we're trying to solve, and what's the most important thing? So let's figure that out and then say, what is it that we need to do in order to accomplish that? So it's really to. And there might be some value in looking at those big items or looking at all the little items, but the trouble is that there's so much there, people get overwhelmed. So it's helpful just to kind of have everyone sit back and say, what are the main problems that we're trying to tackle? And what those look like differs depending on the type of effort you're looking at. So if you're rebuilding an existing system, which for some reason I've had the opportunity to do several times, that's really identifying what are the main areas of functionality that exist in the current system and which of those still are actually relevant. Because a lot of things might have been built just to account for cruft along the way, and in what order do we need to introduce those things in? If you're working with an existing system that you're not replacing, but you're just looking to optimize, that's a discussion about what's the biggest problem we want to tackle right away, what's the optimization that we want to focus on first, and then kind of identify those types of things. If you're building something completely from scratch, it's a matter of what is it ultimately we're trying to accomplish and what's the smallest amount of work we can do right now to accomplish that and then move into an optimization mode. So the goal there is in all cases is to get to a smaller set of bigger items and then getting a sequence down to say which do we want to start with? It's also having the tough conversation to say. We have to be very clear about what we are going to do, what we're not going to do, and we have to be willing to say we're not going to do that. And if you have to say we're not going to do that right now, because especially in it focused Teams, they've been spending years upon years trying to be heroes and claiming they can get all of this stuff done when everybody knows it's impossible. So it's a matter of changing the discussion to say we're going to just admit right up front that we can't get this all done. And saying that at the beginning of the year is usually probably going to be there, might be a little bit uncomfortable, but it's going to be much better received than getting to November and saying, yeah, you know, all those things we said we were going to do, yeah, we can't get to them.
- [29:21]
Host
Right. Talking about having smaller backlog items now that you talked about this in November, having the discussion of we couldn't do in our substack conversation, you said that your team had at that point just 23 backlog items across three brand websites. Now, I don't know about you, but for me that's pretty lean. I'm used to hundreds and in some cases even thousands of items on the backlog. So what are the routines you effectively put in place and the guardrails, the practices you've put in place to prevent that backlog from bloating?
- [29:59]
Kent McDonald
So a lot of, a lot of it is all governed by having a pretty staunch filter as far as what can actually get on the backlog in the first place. And the thing I'm working on now, fortunately, I have quite a bit of control over that and my situation is probably a little bit unique because the team that's working on this, they're all part time contractors. So which is why we can get away with having 23 items on the backlog because there's just not that much capacity, you know, to get things done. But those 23 items are crossed all the way from I'm refining the item all the way through, it's ready to be moved into production and all the stages in between. So that, that is kind of where, where it's at. And, and basically it is saying.
- [30:46]
Host
I.
- [30:46]
Kent McDonald
Am trying to be just a little bit ahead of where the team is going to be working on things. Part of it is not feeling the overriding pressure to keep people busy. And it helps because they're part time, they're working on other things. So it's not like, and you shouldn't have this compulsion anyway. But I know a lot of teams have this compulsion that we got to keep our developers busy 100% of the time, even though that is not a healthy thing to do either. And one of the other things I forgot to mention about why backlogs explode is because for a while there, there was this advice going out there, the concept of shovel ready backlogs where you needed to have at least six weeks worth of backlog items set up. And even that I think is going too far because things can happen quite rapidly in six weeks. And so you flesh these things out and by the time you get to getting to develop them, conditions have changed or we've made other decisions in other parts of the system that those things are now stale. So I take it to a point to be make sure that we don't have a lot of things even getting ready, just so that when we are getting them ready, we can reflect the most recent state of the system that we're building into.
- [32:02]
Host
Yeah, absolutely. I really like the comment you made on the job already backlogs, because having six weeks of work already ready sounds quite reasonable if you look at it from the perspective of keeping the developers busy. But as soon as you start digging into it, you will find out that of course developers are busy because they're now refining backlog items for the next six weeks. They're not busy because they're developing anything. Right. Like there's a, there's also a cost in having six weeks worth of work refined and ready to go.
- [32:36]
Kent McDonald
Yes. And again, I think the biggest, biggest issue ever into is they get stale and they expire. So I would say in many cases backlog items, especially the ones that are kind of at the level that the team would work on, are probably closer to milk or eggs than fine wine. Right. They don't age very well and so.
- [32:59]
Host
They don't age very well. No.
- [33:00]
Kent McDonald
Yeah. And being someone that is spending a lot of their time and getting the backlog items ready for the team, I would prefer not to redo work because I made assumptions or based my effort on old information. Another key part of this is having a good understanding amongst the team as far as what's the right level of information in backlog items for the team to be effective in moving forward. Right. It's that balance between not over speccing so that the team has some flexibility to develop the solution in the right way possible, but at the other token not keeping it so vague that they have to continuously ask questions or make up a lot of assumptions and then they assume incorrectly and kind of go off in a different direction. And the way I approach that is just by having a discussion with the team when I start working with them to say, what do you think is the right level of information for you? What kind of piece of information do you need? And then making a point to adjust on that as we get some experience working through some items. Some teams I've worked with, a very brief description was sufficient. Other teams, they like to have as much information as possible.
- [34:13]
Host
And we need to adapt, as you said. That's a good point. And also the more information that is needed in order to consider something refined or quote unquote ready, right? But many teams still have the definition of ready there. The more information you need for an item to be ready to go into development, then of course the less into the future you should do that work because otherwise it's not just wasted work, it's also time away from developing the other items that were already refined. This is of course a huge topic. Managing backlogs is a full time job, right? Product owners spend a lot of their time doing just that and so do teams and so do stakeholders. But if people want to dive deeper into this topic of managing that backlog, keeping it usable and effective, what is a resource, a video, a blog post or a book that you could recommend for teams that want to to get better at their backlog management?
- [35:14]
Kent McDonald
This is going to be a selfish suggestion, but in the in my Stack Substack newsletter, Inside Product, I'm actually going to going through a series of weekly articles right now about that exact topic that are probably going to be pulled into a more consolidated resource here shortly. So I would suggest folks go out and sign up for Inside Product.
- [35:39]
Host
Absolutely. We'll put the link to that on the show notes so that people can easily find. And for those of you who haven't checked out Substack yet, please go. There's a lot of great people writing really insightful articles. You can easily follow those that you most connect with and find the most similarity and get sparked and motivated. And of course we'll put Kent's substack newsletter inside Product. The link will be on the Show Notes for you to be able to quickly subscribe and follow him there. And Kent outside Substack if people want to, you know, reach out, connect, ask a few follow up questions, where could they go?
- [36:23]
Kent McDonald
So certainly sign up for the newsletter. But Also I'm on LinkedIn, that's kind of my social media home of choice right now because of where the others have degraded to. So probably LinkedIn. Kent J. McDonald Absolutely.
- [36:39]
Host
I will put the LinkedIn page also in the show notes. Kent, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [36:47]
Kent McDonald
Yep, thanks for having me on Appreciate it.
- [36:51]
Host
Hey friend, thank you for staying here. Is all you need to know about the Global Agile Summit if you've ever suffered or know people who are suffering from Agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen in Tallinn, Estonia May 18th. That's the workshop day. Then 19th and 20th the conference day and and Tallinn, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Appello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sig Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with a contract negotiation? How Agile is that? But there's more. We'll cover engineering practices in our developer track with talks on for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about, for example open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendit's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations Agile Product for product managers, product owners and innovators and Agile Developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world, people who just like you, want to grow, want to share and want to learn. By challenging the ideas that don't work anymore at the Global Agile Summit, you'll get new connections, fresh ideas, and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now@globalagilesummit.com I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.