B (2:47)

We used Tsunami way back when.

C (2:50)

Yeah. So the Product owners who don't understand the whole system and who don't understand that they need to be saying no, they need to be saying no politely are really kind of the anti patterns that I see. So one of the things that I teach product owners is a few polite ways of saying no. So I've got these on the powered by Teams YouTube channel and we've referenced that earlier in our recordings. You can get to it poweredbyteams.com YouTube. I've got one video up there. For four polite ways of saying no. The first thing is have a goal. Okay, so this is. I've referenced this in our other conversations. Unclear intent is probably the big problem that I see. No clear vision. No clear product goals. No clear sprint goals. So with product owners, make sure you have a product goal. If you don't have a product goal, it just becomes a task list. And so when something comes up, how does this fit with our product goal? If it doesn't fit with the product goal, great, it should move someplace else. So that's a very gentle way of saying no to situations. So product owners that just keep saying, yes, yes, yes, yes. Those are the ones. Okay, so that's one pattern that I see. Another pattern that I see, which is comes from good intention, but can often come where the product owner is perceived to have positional authority. So I had a client where the team manager was acting as the product owner. And they kept. Now this was somebody. It was a 900 person publicly traded company. The person carried a senior director title. They had come in at the founder level of the company. And so they had some authority. They kept interrupting the team's daily scrum. Now, with a product owner, I'm good with that, but with the team's manager, not so much. Because what that did is it shut the team down because of power, distance. Because that positional authority of their manager, the team just started waiting for direction. And so the product owner was a little too domineering, but this was largely because they held the positional authority. And so this is a coach, the product owner situation. I had to pull them aside. Now, I got really lucky, Vasco, because the two of us had really good rapport and their heart was in the right place. So we had to have a frank conversation. And my conversation was, do you recognize you're interrupting the team? Yeah, I do. Okay, you recognize you shouldn't be doing it? Yeah, you're right. Okay. What would you like to do instead? I don't know. Would you like some help with that? So if you're going to coach always ask permission. They're like, yeah. And so I told them, I tell you what, if, if you interrupt the team again, this is what I'm going to do. I'm going to do it in front of everybody, okay? And they were on board with it because their heart was in the right place. So this is a situation of using the situation to help the team and to help the product owner. Next daily scrum comes along, they interrupt the team, I glare at them. We're in the same room, they're not getting it. So it's in front of everybody. And they got the message. Even though the eyes in the room got really big, they shut up. Now the really interesting thing came the next day when I came in and said good morning to that team. And the team's eyes got really big and they're like, your badge still works.

B (6:01)

You didn't get fired.

C (6:03)

Yeah, exactly. See, I knew because the two of us had really good rapport and their heart was in the right place. This was a great opportunity to demonstrate courage to the team and to like we've talked about earlier, like, help them to get to see that they could expand what they could control, what they could influence by demonstrating that by being a servant leader and showing them the way to do it built a ton of confidence in that team and it also helped that product owner get over the, the anti pattern of being overbearing and over controlling on a team. So those are, you know, those are two of the anti patterns that, that.

B (6:37)

Great story to illustrate that last one. Amazing. But of course there aren't only bad po anti pat, there are also some amazing product owners out there. So Bernie, the best product owner you've ever worked with, how did they work?

C (6:54)

So this is, this is one where it's. The best example I can have was when I was at TiVo. I was brought into TiVo on a stealth program and it was chartered by Jim Barton, who was one of the founders and was the CTO at that time. So he recognized that TiVo's recording intellectual property, the patents were going to be running out and they needed to create some new intellectual property. And so what he did is instead of telling the teams, go build this gave them a problem to solve. Now it was a very broad problem. We need to go create some new intellectual property. That's really broad, but that's better than what most product owners do, which is here's solutions to build because this is what the organizations are telling us. Vasco. I talk about agile in three dimensions. So I'm going to talk you through it here and hopefully paint the picture verbally for everybody. Most organizations only use Agile in one dimension. They're really only using Agile for delivery agility, they're only focused on outputs, okay, which is turn the crank faster, turn the crank faster, better. Organizations, and we talk about this in Agile, are focused on outcomes for your customer. That's a second dimension. So if you can imagine like a three dimensional little box that you're drawing here in your head as you listen. So outcomes are a second dimension and outcomes are about how are we going to solve a problem. But really the third dimension, which I call strategic or business level agility, is about the impact that you want to have and that's about what's a problem worth solving. This is the way startups here in Silicon Valley actually work and this is the way high performing teams need to work. What's the problem that we're, you know, that's worth solving here? We may be chartered for get this problem done, but is this a problem we're solving? Should be the first thing that you're answering. The next thing that you should be answering is how can we solve that problem before you go run off and build it? Too many organizations and I could go way deep on this. Again, the talk that I'm giving about a month from when we're recording this is going to go way deep on this. Too many organizations just give their teams solutions to build rather than problems to solve. One of the other ways I relate this is with the Mobius loop from Gabby Benefield, who's an agilist out of the uk. So everybody can imagine a Mobius loop. So a two lobed, you know, infinity sort of a symbol. Most organizations only use half of it. The whole build, measure, learn, build, measure, learn. Melissa Perry calls this the build trap because most organizations just give their team solutions to build. The other half is actually about discovery, discovery of the problem to solve and who to solve it for. And that honestly is the big part of what a product owner should be doing is they, I coach product owners towards. You want to drive uncertainty out of the system. And some of that uncertainty is, is this a problem we're solving? Is this a good way to solve the problem? You know, and when teams start talking about spikes, I talk about those as technical uncertainty. I don't get wrapped around the axle out, oh my gosh, we got to put a spike in here. No. Okay. There's technical uncertainty that we got to resolve in this situation. So the really good product owners. They're the ones who are looking at things as problems to solve. And is this a problem worth solving? As one of the first for me.

B (10:20)

One of the most cur, and sometimes frustrating, mostly surprising and confusing realizations is that we're still talking about how important it is to define the problem to solve. And I was thinking, I mean, many of us come from an engineering background and for us it should be second nature to think about understanding the problem, framing it from the problem's perspective, rather than rushing into solution description. Do you have any insight as to why we're still in this jump to solution asap, even before we understand the problem that is worth solving? Perspective?

C (11:01)

Yeah. Yes. And again that, that's my talk next month in at the Scrum gathering in Banff. But let me give you the condensed version. I referenced this elsewhere in what we've talked about this week. So the whole Prussian system of education, educating people to be good soldiers and then good factory workers has an industrial mindset to the way a lot of education is going about. Just find the right answer. That's what we're graded on, school, find the right answer. Now, the Montessori system is about getting people to expansively see the problem, which is why that does so much better in this fast, fast moving situation that we find ourselves in. Most organizational cultures were formed before the Internet. When things move slowly and you could plan and predict them. The organizational culture is one of the first things that I look at and it's not age of people, it's not age of organization, it's age of culture. Because there are 100 year old companies that have made this leap. So most organizations are born before the Internet and they've got this really plan and predict mentality. And so people are just, just go build it. Just go build it. Just go build it. Organizations that were born in the Internet but not the cloud, they also struggle with agile. There are several here in Silicon Valley that I could name, but I won't that were formed in that period before we really got articulated about the whole sense and respond. Okay, organizations that were born in the cloud. Some examples here. Stripe Square are a couple of payments companies here in the Valley. Organizations born after the manifesto in around 2000, which is about where cloud started to really rise. They're almost natively agile and they're thinking about this. This is the way a lot of startups think. But remember startups, if you follow Steve Blank, Steve Blank is a great reference for product owners to follow and that's worth putting in your show. Notes Steve Blank talks about the whole job of a startup is to find. To find a problem worth solving that can scale. And this is where most startups fail is they don't know how to scale. They know how to start the system, but they don't know how to scale and run the system. And that's why they either go out of business or they get bought out. Large organizations, they know how to run an organization, but they don't have this creativity. So they've got this mentality of we just want to exploit a known problem instead of explore a new situation. And that's the thing that has to come into corporate innovation is that tolerance for making new mistakes that we referenced earlier on. So it's running those experiments and finding out is this new problems to solve. So a lot of this is cultural Vasco, at a huge, huge level. And it's corporate culture. Yeah.

B (13:45)

And that aspect is really important. I was just going to add that we have an episode with Elliot Parker. Pardon me, Elliot Parker. The link is in the show notes where he talks about exactly this and makes a very good point about the distinction between large established organizations or. Or even small. But established organizations versus startups, because they function on different assumptions about the world, right? Like one, the traditional largish organizations, they focus on getting one thing done very efficiently while startups focus on the impact of finding the right problem to solve. And those are completely different perspectives. And in the second one, it's pretty clear why it's important to experiment because you don't know what the problem is, you don't know what solution will work. And even if it will work, know what solution will scale. Right. And all of this needs to be solved. So it's a really great point. Thank you for sharing that. Now, Bernie, we're almost at the end, but before we go, where can people find out more about you and the work that you're doing?

C (14:51)

So my website is powered byteams.com and you can find me on LinkedIn under my name, Bernie Maloney, if you reach out to me on LinkedIn. I really appreciate when people do reach out, but I like to meet people before I accept LinkedIn invitations. So I would suggest follow me to see if there's anything there. I don't post a whole lot. I need to start posting some things like Vasco. Doing this is inspiring me. I want to start a podcast series that I'm thinking of calling Fueled by Leaders. Because leadership is probably the key to what's going on. So I gotta do a little disclosure here. My spouse is the current CEO of the Business Agility Institute. And the Business Agility Institute was founded by Evan Laborn and Evan has a theory of agile constraints. So any system has a bottleneck. Twenty years or 25 years ago, the bottleneck was in the creation of software. Agile came up relieved. That bottleneck theory constraint says it moves someplace else. Fifteen years ago, that was in the delivery of software. Okay, and that's where DevOps came up. And now the bottleneck has moved further upstream and it's really into the business level of what are the problems we're solving. And I think AI is going to accelerate this. It's going to surface so many the way Scrum surfaces problems. AI is going to surface problems in figuring out what the problem to solve is and some of these leadership aspects and it's going to surface them really fast, which is a great opportunity for people. So it's really going to be coming into how do organizations get led in this even faster paced world? And so like, I'll probably start a podcast series. My YouTube channel you can find@poweredbyteams.com YouTube is another way. I occasionally post, but I need to start posting more on that. So those are three ways like follow me on LinkedIn, you can go look at my brochure website of Powered by Teams. And then you can also plug into the YouTube channel and okay, maybe I'll create more.

B (16:53)

And all of the links will be in the show notes everybody. So make sure to check it out. And why not ask a few follow up questions From Bernie on LinkedIn, comment on his posts, learn more about his ideas. So Bernie, thank you very much for your generosity with your time and your knowledge.

C (17:09)

Thank you for having me, Vasco.

A (17:15)

All right, I hope you liked this episode of but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers, practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.

C (19:05)

Slack.

B (19:07)

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.