Is your process working? Is your backlog process the way that your team receives work? The way that your team determines what to work on, when to work on what? Is it working? Now, you may have an immediate answer. Most people listening probably have an answer that sounds either. It will sound like one of these three things. Either one, no, absolutely not. It's very broken, and we know it. You may answer with, it kind of works. It's a little annoying. It's frustrating. It's difficult, but we do get work done. Or possibly, and this is a very small sliver of people, you may say, yes, we've got it dialed in. Our team is productive. We're happy. We know what the priorities are, et cetera. Now, there's a very important aspect of getting to a yes for that question. Getting to the place where you and your team would all agree on a yes for that question. That important aspect is simply the outcomes. What is it that you are measuring to determine whether your process is working? Now, you may say, well, it's hard to measure exactly whether a process is working because, and fill in the blank with some excuse. You may believe that it's hard to measure because part of the answer is how people are doing. It's not. It's how people are feeling. But the truth is that you can measure how people are feeling, especially if you're a manager. That should be part of what you do in your one-on-ones with your various reports. So if you haven't decided on what you're going to measure to determine whether you are going to be successful, and it's likely that what you've accidentally done is you've fallen into a trap of habit. We're going to talk today about what that trap of habit might look like and the simplest way to get out of it. Right after we talk about today's sponsor, Miro. If you've been listening to the last couple of episodes, then you know my genuine excitement about today's sponsor, Miro. And that's because I genuinely use this tool multiple days a week. Sometimes it's every day. It's a lot of work. It's a lot of work. It depends on what phase we're in as a team, especially if we're in any kind of planning phase. Any kind of planning phase, we use Miro pretty heavily. This is a wonderful place to do planning because it is so flexible. The thing that my team loves about it is it allows us to do things like a quick retro. We can do an ad hoc retro. We can upvote items. We can send those items over to our JIRA board if we want to. We've modeled these major, major systems, huge events of multiple service connections, like a multi-service environment, all of the events getting passed around. Miro can handle all of it. And it does so with excellent performance. So as an engineer, I'm very happy to use the product because it never really lags on me. Now, if you've used charting software before, if you've done anything with developing process charts or anything, you might feel a little bit of a problem. You might feel a little bit intimidated or like you're going to have a ton to learn. The truth is, no. Pretty much all of the engineers on my team were able to pick it up and learn it in process. There are absolutely tons of things that you can learn about Miro. It has a lot of power, but it's also incredibly intuitive to get started with. And that's my challenge for you. It's free. It's free to get started with. Your first three boards, which, by the way, a board can hold a ton of information. Your first three boards are going to be a lot of information. Your first three boards are free. Head over to Miro.com. That's M-I-R-O dot com slash podcast to get started today. That's Miro, M-I-R-O dot com slash podcast. Thanks again to Miro for sponsoring today's episode of Develop a Team. What is the habit trap that we're talking about with backlog management? Well, you've probably been on a team that has experienced this. You get into a rut. Maybe you set up your calendars so that you have your recurring meetings. Your schedule is set. Everybody knows what time standup is. Everybody knows when you're going to do planning and all of this stuff. And then you don't really revisit that. Maybe you even hold retros, but the retros are not necessarily translated into any kind of process improvement, any kind of feedback into the team's way of operating, especially as it relates to the backlog. And so you end up with this inertia that comes as a result of forming habits. Everybody gets used to that schedule. Everybody gets used to the way of doing things. Let's say, for example, that you're using a backlog that has user stories. Those user stories get broken down into tasks and the tasks have acceptance criteria on them. You probably have done something like this. If not, this is just another way of saying requirements for that work. It's very possible that. You're going to have a backlog. You're going to have a backlog. You're going to have a backlog. You're going to have a backlog. You're going to have a backlog. If you're like most teams, you've allowed your quality on those requirements to slip over time. This means that you're not as stringent on entering all of the details that you can whenever you are refining that backlog, whenever you're actually going through and saying, this is ready to be worked on. The quality of those requirements may not be as good as it can be. That would be a symptom of falling into these habitual motions. The idea is that the habit is what you're satisfying. Think about this for a second. The habit is what you're satisfying, not the actual needs of your team. Your backlog is suffering even though you're consistent with all of the things that you are saying are going to help you with your backlog. So what's the fix? What is the fix to getting out of the habit trap? What is the fix to getting out of the habit trap? There's going to be two things I'm going to recommend. Two things I'm going to recommend. The first is to adopt a standard process. Adopt a standard process. Don't allow yourself to fall into the illusion that your team is too special for a standard process. Adopt a standard process. What does this mean? It means something like Scrum, something like Kanban, extreme programming. Whatever your program is. Whatever your particular paradigm is. Adopt it and adopt it completely. That means do all of the, you know, kind of follow the letter of the law for a little while. Now, that's not because I believe any one of these frameworks is the end-all be-all answer to all of your problems. Instead, what this does is it forces you to follow something rather than following your habits. You're following a procedure. This is a procedure. This is a subtle shift, but you're following a procedure, which means you're going to be more mindful about what you're doing. Okay? If you have a procedure that you're already following, then go back and identify spots where you've kind of gotten rusty and use the documentation for that procedure so that you're actually bringing that documentation out during those particular meetings. So, if you are supposed to do a retro, go back. Okay? Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. So step two, and this is part of why we're saying adopt a consistent process that has good documentation. For example, Scrum is a good example of this because you have the Scrum Guide, right? You can bring up the Scrum Guide. You can identify, am I or am I not following this process pretty clearly? Why are we doing this? To create that procedure following rather than habit following or breaking out of habit as the arbiter of whether you're doing the right thing or not. Instead, you're following the procedure. The second piece of this is you're going to adopt the specific metrics, the health metrics, the outcomes from that procedure that you're supposed to be paying attention to. So instead of allowing your success metrics to be implicit, or saying that, well, it's too hard to measure, therefore we're not going to measure it. Adopt the ones that the framework you're using says identify whether you're successful or not. On top of this, over time, initially just take the ones that are in the framework. Over time, you can determine what are the outcomes that we care about. Beyond the framework, beyond these specific measures, whether that's velocity or whatever it is that you're measuring, what are the outcomes that we actually care about for this team? And start measuring those. Now, once you get really good at making the outcomes your habit, this is the thing I want you to focus on. We're taking habit out of the process, and instead we're making outcomes and checking against the outcomes, changing our process, changing the procedure, in response to measurements on the outcomes. That's the habit to build. We're trying to break the habit of automatic procedures for the sake of procedures. One time we thought they were good, we started doing them, then we never revisited that decision. We're going to break that habit. We're going to focus on outcomes, measuring outcomes, and then evaluating our process and adapting our process because, because of those outcomes, because of the measurements that we're doing on the backside. Not because we're feeling like doing something different. We're going to adapt our process over time and treat the process as exactly what it is. It's not a habit. It is procedure. It is a tactical way to achieve outcomes that you care about. That is how you get out of the habit trap for your backlog management. Thanks so much. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Miro. That's M-I-R-O dot com slash podcast. Miro is giving you three free boards. By the way, you can do like a ton of stuff with three free boards. That's M-I-R-O dot com slash podcast. Get started today for free with your first three boards. Thanks so much for listening to this episode. If you enjoyed this discussion, I'd encourage you to join the Developer Tea Discord community. Head over to developertea.com. That's developertea.com slash discord. Thanks again. Until next time, enjoy your tea.