Unknown Host (5:42)

Yeah, and when you say unleash the developers, I think there's, at least from my perspective it's important to kind of highlight that the idea here is not to abandon the developers, but rather to allow them to bring in the technical innovation perspective that only they can bring in. The BA or PO can never do that because they're not actually typing or testing the code. They can't come up with ideas that you would need to understand the code to come up with. Right. And I think that the beauty of Scrum is that you have these two sides that are working together. And the problem with traditional waterfall like approaches is that there's this clear separation of concerns where one sends over the wall the fully specced out functionality, not allowing there for the developers to take ownership of the work that they're doing and also to contribute their technical vision and innovation to what has been decided to be done. Right.

Joel Bancroft Connors (6:44)

Yeah. And it's the, it's. I think a product owner needs to recognize even though they're technically an equal to the developers and the Scrum master, the product owner has certain positional authority because they own value. And so if the product owner says do it this way, quite often we've spent decade decades teaching people in doing roles to do what they're do, do what the, what they're told. You say here, build it this way with the button over here and the developer is going to go, okay, great, I'll do it that way. What we want though is we want them to instead give them problems. Give them. Here is a canvas, here's what I'd like it to look like. Go create awesome and we'll give you feedback along the way.

Unknown Host (7:29)

Yeah, exactly. Go create awesome and we'll give you feedback along the way. That's a great way to put it. And also what the core of agile is, it's right there in the values principles. Do something quickly, show it to someone running, get feedback and then do the next iteration of it.

Joel Bancroft Connors (7:49)

Well, and that's why Principle 5 of the manifesto is my favorite principle. Build projects around motivated individuals, give them the environment and support they need to get the job done, I. E. Tell them what you want and then get the heck out of their way.

Unknown Host (8:04)

You know what, ironically, that's one of those principles that you could have asked from a project manager anywhere, even waterfall project matters, and they would probably agree with it, at least the good ones.

Joel Bancroft Connors (8:17)

Yeah, I think the principles of Agile are universal and in fact we're seeing this with Project Management in International with its strategic partnership with the Agile alliance and they're continuing work. In the 1990s they were big design up front and then as the 2000s came along they moved to rolling wave planning. But now they're recognizing that the power of Agile is continuous planning. And even PMI is promoting this concept and living into those Agile principles. You don't have to use Scrum to be agile. You can build a nuclear reactor using Agile principles. Because who can argue with motivated individuals? Who can argue with reflecting regularly on effectiveness, who can argue with the people doing the work are probably the best ones to say whether or not it's actually going to work?

Unknown Host (9:07)

Yeah, absolutely. Okay. But there aren't only bad product owners, some product owners out there are amazing and we owe them some debt of gratitude and therefore we want to highlight some of them. So Joel, share with us the best product owner that you've ever worked with. How did they work?

Joel Bancroft Connors (9:27)

So. Sure thing. So bear with me because it's going to sound like an anti pattern at first because you see there's these two product owners, only they weren't working on the same team. I was working with an organization they were doing, it was another insurance organization and they had been building, trying to build this new electronic flow. They'd been literally, you wanted to buy insurance, you had to go to an agent and they still worked on a green screen terminal in an agent's office. And the API people had said we have to do all of this stuff for months and months before anybody else can do anything. Well, leadership was frustrated, let's say and they want, they wanted something different. And I was brought in to coach and be the Scrum master for those two teams actually work with another, the on site Scrum master. And so we paired up together and we had a product owner from the business, but he didn't really understand Scrum and he didn't understand anything about product development. He knew insurance really well. And then we also. This was going to be a highly user experience, a lot of UX in it and we had this really brilliant designer who'd been working off to the side and had really great ideas and also was a really great personality. And we were going to have two scrum teams and it's like, well, what do we do? We're going to need two product owner product owners. And they said, well, we're going to have this person be a product owner. And it's like, I looked at this person, I interviewed them and I went back and I talked with the director. I said, he has no business being a product owner. He doesn't understand the why. He does, he doesn't understand anything about the product stuff. He's a project manager who has never learned the art of product management. And they said, well, who should be the product owner? I said, the designer. The designer doesn't know anything about the business. True. But the business guy does and the business guy doesn't know anything about how to build these products or whatever. Together though, they've got everything we need. We have two teams. We're going to make them product owners of each team. They're going to work together because it's a shared product goal. They had the same product backlog, the same product goal with two teams working on it. And so each product owner had their own team. The business person also focused at the strategic level of the overall product goal. And then the designer was focused on design across the two teams. And while it wasn't the, the perfect thing, them working together really caused these two teams to be able to work independently and yet very closely side by side towards that same product goal. And they were able to do amazing things and take something that some people had thought was going to take 18 months and build it in, I think it was about six months. Wow.

Unknown Host (12:12)

And this actually brings to my mind this idea. I mean, in Agile we always talk about collaboration, right? Like collaboration is important. You need to get people in the same room or virtual room in order for them to talk to each other, understand what needs to be done together and so on. But one thing that we very often don't talk about is this idea of complementary skills. Collaboration can emerge in a group of people that have the same skills. But it really shines when you need to have complementary skills because that's where collaboration really, you know, it's, it's a question of the sum of the parts or. Yeah, the sum of the parts being much better than the two parts. Right. Like it's, it creates something new. And those two perspectives, the designer with the user centric perspective with the usability and interaction and Experience, perspective, the business person, we understanding of the business. These two working together can create something that neither of them apart could, nor two business people, nor two designers could.

Vasko (13:21)

Right.

Unknown Host (13:22)

And I think that this is a beautiful example of that idea that collaboration really shines when you have people with different skills that are collaborating on something where all the skills are needed.

Joel Bancroft Connors (13:36)

Yeah, the business person and the designer both got better. The business person understood more about user experience and everything. That business person, they knew insurance products, they didn't know anything about even what the mainframe that people were using in the insurance offices. The designer, though the designer knew computer products and new user experience and what users were expecting, he didn't know anything about insurance. And in fact, when we did a team liftoff for these teams using the book Liftoff by Ainsley Nees and Diana Larson, that was one of the first things we did was we spent a half a day with the director of the organization, organization coming in and literally what is an insurance product? What is it we're selling? Why is this important? What do we have today? And from that we created a Persona with the team that was in part informed by the business, in part informed by the UX guy who knew how to do create Personas. And we literally had the Persona up on the wall and the developers started referring to the Persona by name in these refinement sessions because we created, we connected it all back to start with why. And so it goes all the way back to my book on Tuesday of Start with why. Simon Sinek.

Unknown Host (14:53)

Yeah, absolutely. And this beautifully wraps up the week in this what I said, you what I told you in the preparation, like you really wrapped up the message so beautifully in this week. There's so many angles on the same message that you brought. Start with why, understand why we're doing the things we're doing so that we can show the value. That's a beautiful way to wrap it up, Joel. Thank you very much. But before we go do share with us, where can people find out more about you and the work that you're doing?

Joel Bancroft Connors (15:26)

Absolutely. So I do have a website, thegorillacoach.com I post article, longer form articles and facilitation guides such as a team estimation facilitation guide. I post every single day. I have posted since the beginning of the year. I posted every single day without fail on LinkedIn on practical stuff. Right now I'm doing a series on Mondays, a Sprint in the Life of the Scrum Master. I just finished a whole 15 part series on a Sprint in the Life of a product owner. Fridays are my facilitation Fridays I always post a facilitation technique and Sundays are always my funny where I take a look at some absurd way that we are doing Scrum or Agile and try and make light of it. So follow me on LinkedIn. And of course I also do teach certified Scrum classes, csm, cspo, all of the advanced certifications and you can find me scrumaliance.org if you look under training and you filter by Joel Bancroft Connors, you can see all my training classes and reach out to me for a discount code.

Unknown Host (16:27)

Absolutely. And we'll put that note in the show notes everybody. The links will be in the show notes for you to easily find them, of course. And why not reach out to Joel, start up a conversation and asking about some of those funnies. Sunday funnies sounds like a great way to start the conversation. Joel, thank you very much for your generosity with your time and your knowledge.

Joel Bancroft Connors (16:51)

Thank you Vasco. It's been an honor and a privilege to be on such a well regarded podcast.

Vasko (16:59)

All right, I hope you liked this episode. 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 and 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. Slack.

Unknown Host (18:51)

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.