Every software team is different and requires a tailored approach to thrive. It’s essential to discover what works for your specific team to achieve product perfection. This week, we have a rare go-to subject matter expert on our podcast to help you get there!
Meet Kent McDonald. Kent is a seasoned freelance product manager and writer with a background as an agile coach. He has served as the past chair of the Agile Alliance Conference and is a Co-founder of the Agile Project Leadership Network. Kent is also a prolific author, having written numerous books and articles on agile methodologies, business analysis, strategy roadmaps, and product management. His extensive experience and insights make him a respected figure in the Agile community.
In this episode of Scaling Tech, Kent and Arin dive into the best agile principles in software development, differences between product roles, and tips for improving productivity within a software team. And that’s just the tip of the iceberg!
Join us today and get ready to make notes as we explore product management and best agile practices.
Read Kent’s blog post about Moving from Business Analyst to Product Owner to Product Manager
Listen on Spotify
Listen on Apple Podcasts
Watch the video:
Key Insights with links to jump ahead are below
About Guest:
Name: Kent McDonald
What he does: He’s a Freelance Product Manager, Writer, and Former Agile Coach.
Company: KBPMedia
Where to find Kent: LinkedIn | Website | Newsletter
Key Insights
⚡Agile methods should help reveal and address inefficiencies in workflows, not create them. It’s essential to allow teams enough time to focus on what truly matters in their organization and make a meaningful impact rather than just keeping them busy.
Kent explains, “What happens is then, especially in organizations that are just getting started out, is that the folks that maybe look like they know what they’re doing because they’re actually moving along and progressing things, then other parts of the organization start asking, ‘So what are you doing and how are you doing it?’ And then they pass along this advice like, ‘Well, we’ve got this very long backlog that it works great because we always have something to do.’ Thethe point they’re missing there is that chances are 50-60% of what they’re doing is probably the wrong thing and isn’t necessary. And they’re emphasizing producing output and keeping busy over doing things that actually make a difference.”
⚡What’s the difference between a product owner, product manager, or business analyst? Although these roles seem similar—and are often confused—they each serve distinct purposes within an organization. Kent explains,
“Product management is probably closely related to a job title that does the full set of figuring out what problem we’re trying to solve, how are we going to do that, working with both the market and the development team to make it happen. Product owner, as it was initially defined, was a role, specifically the product aspect of working with the development team. And then, in some cases, as I mentioned, product manager fills the product owner role. […] And so that’s kind of how I look at it. To roll the business analyst into it, as I mentioned before, they’re the folks, the good ones are the ones that understand the business rules, processes, and data that an organization needs to operate.”
⚡ How to manage external stakeholders effectively? It’s vital to analyze stakeholders’ requests carefully and not take them at face value. Kent explains, “Oftentimes when you’re getting stuff from stakeholders or users, they’re phrasing the request in the form of a solution. ‘The system should do this. The system should have a red button that spins when you press it and whatever.’ But by having those feedback separate and actively doing some sort of analysis, as you’re saying, does something actually apply, you’re able to go through it and throw it against some filters to say, does this actually make sense or not. So, as part of that, you can handle your things from those stakeholders along those same lines. And you may weigh the feedback from certain stakeholders higher than others, depending on the subject matter of that request.”
Episode Highlights
Prioritize meaningful work that adds value.
A common mistake that product owners make is allowing unnecessary backlog to accumulate, which inevitably wastes the team’s time and prevents them from creating real value.
Kent says, “If I hear the terms shovel-ready, backlog, or people passing advice that says you need to have six months’ worth of backlog items in your backlog, my first piece of advice to the folks is to actually, I just look them straight in the eye and say, ‘You need to burn your backlog.’ And then, what that’ll usually do is probably start some kind of convulsions, or the eyelids will start twitching or everything. And the reason for that is because chances are that when you have, and there’s no magic number, but if you have more backlog items in your backlog than you can get done in a month, everything past that is going to be inventory that’s most likely going to go stale before you can even get a chance to use it.”
Productivity in software development often involves mental work that’s not always visible.
It’s essential to recognize the nuanced nature of productivity in software development. Oftentimes, developers need time and space for deep thinking and problem-solving—forms of productivity that aren’t immediately visible.
Kent explains, “A busy developer does not look like a busy person on the factory floor. The person on the factory floor is, and especially, for example, when Saturn was a going concern, and most car manufacturers do this is you’ve got someone, you’re actively putting a wiring harness in, and you’re standing on the platform that’s moving down the assembly line. You get the wiring harness put in then you walk down and get the next car, and you start working on that one. A very busy developer might be sitting there staring at the ceiling for half an hour, trying to puzzle through something. And someone looking at it from the outside is going to be thinking, ‘Well, that person’s not doing anything.’ When, in fact, they’re seriously burning some mental calories trying to figure out some big problem.”
The importance of collaboration and flexibility in agile teams.
When team members work openly together and share their expertise, they can create better solutions and respond more effectively to changes. This collaborative approach is one of the core agile principles.
Kent explains, “I look at even job titles and roles as suggestions or as a starting point to say, here’s what we kind of expect different folks to do. But everybody comes to the job with their own background, skills, experience, knowledge, biases, all of those kinds of things. So one of the things I first like to do is sit down, say, ‘I know that I should be doing these things, and you should be doing these things. But let’s talk about what you’re good at, what maybe some of your weaknesses are where we may complement each other, and let’s figure out, granted, that’s what the roles should be doing, let’s figure out what we’re actually going to do and who’s going to own it. Where are we going to cooperate? Where are we going to share? Have that discussion early on and then be willing to reflect on that on an ongoing basis. And not being so precious about my territory near territory, but more along the lines of how can we work together to make sure we ultimately get that outcome accomplished that we’re trying to get to.”