Agile Mentors Podcast from Mountain Goat Software

#111: Adapting to the Future of Work with Heather McGowan

Explore the dynamic future of work with Brian Milner and Heather McGowan as they discuss the essential shifts in mindset and culture needed to thrive in the augmented era.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner interviews Heather McGowan, a renowned future of work strategist, about the rapidly changing landscape of work in the augmented era.
Heather emphasizes the importance of adaptation, empathy, and human connection in response to technological, societal, and cultural shifts. They discuss the pervasive issue of loneliness in the workplace and the critical role of leaders in fostering a culture of trust, agency, and high expectations to drive performance and productivity.
Heather also shares insights on finding personal purpose and intrinsic motivation to excel in the future of work. This conversation provides valuable strategies for individuals and leaders to navigate the evolving work environment successfully.
References and resources mentioned in the show:
Heather McGowan
Heather’s Website
The Adaptation Advantage by Heather McGowan & Chris Shipley
The Empathy Advantage by Heather McGowan & Chris Shipley
The UpSwing by Robert Putnam
Agile Training for Teams & Leaders
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Heather McGowan is a leading strategist and keynote speaker on the Future of Work, known for transforming mindsets and organizations with her insights on continuous learning, leadership, and culture. Her groundbreaking approach has empowered employees, enhanced leaders' effectiveness through empathy, and driven businesses to achieve their goals in a rapidly evolving market.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We're back with you for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today we have someone I'm very, very excited to have on. She was the keynote speaker that kicked off our Scrum Gathering in New Orleans this year. It's Ms. Heather McGowan. So welcome in, Heather.
Heather (00:20)
Hey there, thanks so much for having
Brian (00:23)
I'm so excited to have Heather in. If you're not familiar with Heather's work, she has, think, the best job title I think I've ever heard. She is the future of work strategist. And like I said, that's awesome. I love that. But beyond that, there's a lot that I could say about Heather to introduce her to you. But I'll give you a couple of things just so you kind of understand the perspective of her coming home. First, She was named one of the top 50 female futurists by Forbes. So let that sink in. She also has two incredible books out there. One called The Adaptation Advantage. has more than two books, two recent books. The Adaptation Advantage, Let Go, Learn Fast, and Thrive in the Future of Work. That's one. And her latest one that just came out recently, it's called The Empathy Advantage. leading the empowered workforce. And I'm very, excited to have her on because her talk at the Scrum Gathering really captured my imagination. And I think everyone's imagination there. so let's just dive in, Heather. Let's talk about this whole concept of the future of work. And I think one of the ways you started in the presentation, I think, was really important to try to understand where we are on the timeline of the work. the way we have progressed through ways of working. So where are we? Where would you put us on the timeline?
Heather (01:57)
Yeah, so first of all, the title, Future Work Strategist, was not something I applied for. It's a title.
Brian (02:03)
Really? Because I want to fill out that job application.
Heather (02:07)
It's a title I created because I felt like there was a need for many of us to be working in looking at the future work, which is something that will never be done. It often gets conflated with being about where we work or DEI issues, but really it is about those things. But for me, it's about leadership, it's about workforce, it's about learning, it's about adaptation, it's about purpose. It's about adapting right now pretty rapid changes that are not only technological, but societal and cultural and demographic and generational. And we're wrestling with just a lot of change at once. one of the things I say to folks is sometimes I think that the majority of what we're going to be doing in the near term is helping each other adapt. Because we're to have to adapt at a clip we've never had to adapt to before. Prior generations had maybe one paradigm shifting change in a generation. Now we might have three or four.
Brian (03:02)
Yeah.
Heather (03:03)
So in terms of where we are, we had the agricultural era and the industrial era and the information era. Well, we're now in the augmented era. So we're dealing with technology consuming tasks that we do at a faster and faster clip. And a lot of people kind of catastrophize it about technology taking away jobs. We're the only species that would invent things to make ourselves irrelevant. that's how what people, but it doesn't make any sense. What we're really doing is inventing technologies that augment our potential. And it requires us to not only learn and adapt and think about differently about who we are, which is what the adaptation advantage was really about, but how do we relate to each other? How do we get the best out of each other? And that's really what the empathy advantage was about. So we're in the augmented era. Technology is going to continue to come at a faster and faster clip. But it's more important for us to think about how we learn and adapt and how we lean into our uniquely human skills. Because... The technology can provide the answers, but it's up to us to find the questions.
Brian (04:04)
That's awesome. Yeah. I think that's such an excellent point that, you know, just trying to think about the fact that, yes, in previous generations, there may have been one paradigm shifting kind of change that comes through a lifetime in the way that we work. But in our lifetimes, we've dealt with the Internet coming on board and we've dealt with multiple revolutions since then, mobile and AI. And these things happen. it's such a greater clip that it really does shift even even things like COVID changing, a lot of places working from home previously was always in the office. It seems like change is the constant now and that change is kind of the thing that we need to get good at is being adaptive and able to change. Why do you feel like, I'm just kind of curious of your opinion on this, why do feel like we're so resistant as humans to just change in general?
Heather (05:00)
I think we have a fear of obsolescence. then in times like right now, I delve into this sometimes in some of my talks, is we're going through some pretty significant division and polarization. It's really acute in the US, but it's happening all over the world. You look at the elections in France and the UK recently. I think it's important to understand how that happened because a lot of people think that's just social media. And technology did come into play, but if you look back in the US anyway in the 70s and 80s, that's when we started to see a real erosion in our social fabric. We started having fewer people over for dinner and being part of fewer fewer clubs, talking to our neighbors less. So we got more and more isolated. And then we had a loneliness epidemic that's been around for at least a decade or so, which, and when you're lonely, your amygdala, the kind of reptilian part of your brain goes into overdrive. So you go into fight or flight mode. So you have a lot of change, isolation, fight or flight mode, and then you throw in social media that kind of catastrophizes things. And we're all in this us versus them mode. And we've stopped seeing, hearing each other. And one of my messages in almost all my talks is we have so much more in common than we have in difference. They show lots of studies from it. So if we just could start talking to each other again, we may not vote for the same candidate. We don't vote for the same teams, but we both love the sport. And that's what we need to get back to is understanding how much we have in common because so much of the work we're going to be doing, especially when technology comes in, is communication, collaboration, exploration. And all of those things require us to relate to each other because you're going to see something that I don't see. And if I only hired people who think like me, it would be tragic because I wouldn't see the entirety of the opportunity. So if you want to really drive profitable growth in your company, you want those diversities of inputs and you want to set a culture that has people see and hear each other so you can see optimally the opportunity space. And because that's what we're going to be doing. It's most of the work we're going be doing.
Brian (06:55)
Yeah, yeah, this is a fascinating fact to me because I, one of the things I start in your presentation is just this idea about loneliness. And I absolutely agree. You know, there's, I think we all can kind of recognize that even though we've tried to create these social media companies that to try to, you know, get a, gain a stronger sense of connection in some ways it's driven the opposite of this sort of loneliness factor. But I'm curious from from some sort of a sociological perspective, that has, it seems, transferred into our workplace. And I know one of your stats there was about how we feel more lonely at work. And I'm just curious, what do you think is driving that, the kind of sense of loneliness that we have while at
Heather (07:48)
Yeah, know, some folks will point that to being about where we work. That's not my area of expertise. There plenty of people who look at where we work. That may be a factor for some folks if you're working remotely and you don't see other people, certainly a factor. But what I think what's really happening is we've outsized what work is in our lives. So community used to consist of social interactions, religious affiliations. clubs and groups we belong to, all of those kind of, if you think of them as circles, because everything's visual to me, all those circles shrank and work became bigger. So now part of it's generational change, but more and more people are looking for work to provide their purpose, work to provide most of their relationships, work to fill these. So it's a little bit in terms of how we're interacting with each other that's causing the loneliness, but it's also an outsize expectation we have around work. So now it becomes table stakes for a lot of organizations for work to be my self -expression, work to be my sense of purpose, work to be where I think about my values. And it wasn't like that a few decades ago.
Brian (08:49)
Yeah. Yeah, that's, I just, I love that point. think you're absolutely hitting the nail on the head with that. And, and, know, just so everyone listening doesn't, doesn't misinterpret this in any way, you know, we're not, we're not saying in any way that those other kinds of organizations like churches or community groups or anything are bad or that you shouldn't see community and those kinds of things. It's just that our society has sort of moved away from those as being the foundational, places where we get community and you're I absolutely agree. is, work has sort of filled that. Sort of analogous, I think, to the way that police have become the front line of our mental health,
Heather (09:27)
Mental health, yeah, exactly. Exactly, and that's not fair to the police and they're not prepared to do that and, you know, we suffer. I think the point with work is that that is where we are. So if you're leading an organization today, that is a reality. I hope that changes. I'm a big fan of Robert Putnam. He wrote Bullying Alone in the late 90s and he pointed out the sort of phrase we're having in ourselves, of fabric. He had another book that came out in, I think it was 2020 or 2021, in the middle of pandemic where he... which was called the upswing, where he says we go through these kind of, you you think about it like a pendulum, we go through periods of high collectivism, you know, the kind of the eye to the we. And we're at the highest, you know, the lowest level of the we and the highest level of the eye in terms of being isolated and all that we do. And we're primed to go back into a we phase. So I'll be interested to see what forms of community start to emerge because we're primed to have that happen. Soon, like I notice is a, live most of the time in Florida, part of the time in Massachusetts. It's a restaurant I go to in Florida. And I was like, why do we love that restaurant so much? I do like the food. It's very good. But it has a situation that an empty seat is is a, is anywhere you could sit. So if I come in by myself or with one other person, they would sit me at the table with one other person or two or 300 people. It's community seating. So you end up sitting with people that you don't know having conversations. It's kind of like a forced community. It's fantastic.
Brian (10:53)
Yeah, that's awesome. I love that. I mean, I will say, you know, the introvert part of me is like, I don't want to sit down. Right. Yeah. I identify with that. Yeah. Awesome. Well, so if we have this problem, right, we're dealing with, with a fear of change. We're dealing with a work in place that is lonelier than it's ever been. And we were dealing with a population that's seeking belongings, sinking.
Heather (10:59)
I'm an introvert too, but when I'm forced, it's good for me.
Brian (11:23)
connection and community while at work. I think you're right that that has a profound impact on the way we work even. And I know you talked a little bit about just kind of the main drivers of productivity, the main drivers of being successful. And I think that this is maybe counterintuitive to what some people think. Help us, talk us through that a little bit about what you found as far as what really drives productivity.
Heather (11:58)
Sure, so just to give you a little background on me that relates to this point. So I spent the last, prior to when I started speaking full time, which is about 10 years ago, I spent 10 to 15 years working on the corporate side, industrial design, product design, design strategy, so new innovation stuff. And every organization I went into, I felt people really weren't equipped. to propositionally think. They could reiterate on the existing solutions. If they had a product, they could make another version of that product, but they couldn't jump entirely to a white space and think of something where we didn't have a contextual reference. And then I found myself working in higher ed because I had a mentor who became president of university and he said, I want to create a new college focused on innovation. And I think you understand it better than anybody else. So I built a new college focused on innovation. From those two sides, I saw the supply and the demand side of talent. And what I saw happening, and this is what kind of led to my speaking career, is we're not preparing people to do the kind of work we need people to do. We're hiring people based on past skills and experience degrees. We've now like edged all the way up to skills -based hiring. But what that really is, is hiring somebody who can demonstrate that they can do something you need them to do. What happens when they get there three or four months later and you need them to do something that's never been done before? So we need to prepare more people to do work that's never been done before. And how do you do that? I think you look more at behaviors. And then how do you activate those behaviors? So what you look for in people is some level of skill, but also behaviors that will tell you what they'll do when they don't know what to do. And that is basically what culture is. Culture is collective behaviors. So that's how you screen for people. And then how do you set the conditions to activate those behaviors? What we've done in the past is hire the skills and exert some hustle culture. And that's going to rev the engine of productivity. We did that until we hit burnout and we're still hitting burnout and we're still hitting burnout and unhappiness and disengagement. So we went from hustle culture to going, we need more engagement. we need shared purpose. we need psychological safety. Well, what's behind all of that is we need humans who feel seen and heard. Somebody cares about me. I trust my leader. You set those conditions to people who have agency and they'll activate those behaviors for which you hired them. And so they have some of the skills you need. They're going to have to acquire so many more because you don't know the work they're going to be doing. So we got to focus on what I say is culture and then people who want to build their capacity.
Brian (14:29)
Yeah, yeah, I love that point. And I think you're absolutely right. I'm kind of so we've been building towards skill based kind of hiring instead of behavior based hiring. And we should be looking more at building people who have the right behaviors to learn and grow and change and adapt. So I'm kind of curious your take on this, because I know that in the past few years, especially, I don't know if you've seen this, think I've noticed this in multiple sections, but there seems to have been sort of this segment of management that has returned a little bit, kind of tried to turn the clock back and gone back to a little bit of Taylorism and kind of the idea of, you you need to push and drive your employees to work harder. And I even see that in some job postings and things about how, you know, there's sort of a rise more traditional project management, is really more based on pushing and driving than enabling. I'm just curious, what's your take? Why do you think that's resurfaced?
Heather (15:41)
I think we got a lot of fatigue coming out of COVID. I remember us doing the sort of the press tour and everything for the Empty Advantage last spring. one, I was talking to a group of CEOs and they said to me, you know what, we're just tired of caring. And because they were being honest with me. And I said, well, explain to what you mean. And they said, well, I get it. We have to be empathetic and we have to feel bad for people and expect less of them. And I said, there's compassion and you should have that instances. And there's empathy and they are not the same thing. When I'm talking about empathy, it's about understanding the people that you're hiring and what motivates them so you can help them become what I call self -propelled. Because you cannot get people to learn and adapt at the speed, scale and scope we're gonna need through just extrinsic pressure. And there's a return to that right now. I think it's some COVID fatigue of just, you know, exhausted because people did have to care a lot for their people. But you know what, we had higher levels We had higher levels of engagement. had higher levels of productivity at the height of the pandemic because we were caring. And that was a little care fatigue. so the care fatigue hits a little economic uncertainty. We've been waiting for a recession. Inflation's been sticky. It's harder to run your business tomorrow than it was yesterday. Again, all those things. But a return to kind of the beatings will continue until the morale improves has never worked. But there is certainly a push to try that now. And I get But you're not going to get the performance out of people that way. just don't believe it. A very small percentage of people that works on most of us work best when we feel like we can trust our boss. We have agency. We have high expectations. I mean, all the studies that I've seen, the best jobs people had with the highest level of performance were when they challenged themselves, they had respect, they had autonomy, and they had agency.
Brian (17:33)
Yeah, yeah, absolutely agree. It just, it fascinated me when I saw that kind of return and rear its ugly head again and think, and my thought was, we've tried this, you know, like this is, it's not that this hasn't been tested and tried, we've run this experiment and it failed and we've progressed into this new era. And I think sometimes there's a leadership kind of misunderstanding that we're just trying to be nice. Like people just want us to be nice. And it's just about being kind of more friendly and kind. And that's what all these management consultants want us to be. there's a purpose behind it. It's because it works. It's not because it just makes you a better person, though it does. But it actually is better for your business to do
Heather (18:21)
Yeah, I think what happened is we had such a long stretch of Taylorism that we presume that that is the model that works. had four years of caring and we had good performance. And that gets sort of conflated with where we work, which I think is a completely separate thing. I think we've got to return to, not return to, we've got to go forward and to say, what did we learn in those four years? What are the things that really worked? How did we really better performance out of people. Because at the end of the day, it's what you're to do. It's why you run your organization. We are in a capitalist society. You're going to run your organization getting the highest level of performance. Highest level of performance and productivity is getting the highest level of performance out of your people. Highest level of performance out of your people comes when you trust them, they have agency, you hire for the right behaviors, you set the right conditions, and you encourage them to do things they never thought they could do. And that's what comes out of all the studies.
Brian (19:11)
Yeah. Yeah. And I know you, you, you drawn kind of this, this really interesting connection, I think between performance and, and mental health and sort of the idea of, you know, that we, again, building on what we've said, right? If our organizations are where we're seeking community and we're feeling lonely, then that this does impact how we work. so it shouldn't be that far of a leap for people to understand how, Hey, if, if, our work environments are damaging people's mental health, that directly impacts performance.
Heather (19:47)
Yeah, and you just look at the studies like, know, the companies that are ranked best places to work, they're ranked best places to work by the employees, because the employees are happy there. And you know what? Their performance is something like 16 % higher than the companies that are on the list. So it's pretty clear. You're getting the performance when people are happy, not you're going to get the performance. You're going to be happy when you get the performance. It's the other way around. We're looking at it backwards.
Brian (20:12)
Yeah, I agree. And one of the stats that jumped out at me in your presentation was this stat about how big of a role your direct manager or leader has on your mental health, just in general and overall in life. So tell us a little bit about
Heather (20:32)
Yeah, there were three different studies I think I cited in the piece you're talking about. First, the employer has a greater influence on your mental health than your spouse, partner, or therapist if you have one.
Brian (20:46)
That's so, I just got a full stop there. Like that is so amazing to me. Your boss has more impact on your mental health than your spouse. That just blows my mind, sorry.
Heather (20:57)
And the greatest source of stress in your life is your job. And then there was another study, which I thought was fascinating, and it was looking at lower paid workers generally not highly educated. The relationship, this was a longitudinal study, and it was only like four or 500 people, but they looked at your relationship with your direct supervisor. If your direct supervisor treated you with respect, gave you agency, gave you autonomy, you trusted them, you went home and raised your children such that they had higher levels of economic, social, and financial success. So not only is your boss influencing your life, you're influencing the next generation and thereby the next workforce. So there's a lot more we should be doing preparing these leaders for having this what is now an awesome responsibility. It's a really profound responsibility. And it's because I think work has become so outsized in our lives. And it's going to be. It's going to continue to be.
Brian (21:58)
Yeah. Yeah. So no pressure, leaders, right? I mean, no pressure on the fact that not only are you concerned with your business and your employees, but the future generation of workers. Right.
Heather (22:09)
And we need to help those leaders. We need to help them put on a gas mask before they try to help anybody else.
Brian (22:14)
Yeah, absolutely, absolutely. So, you know, we're in this, first of all, I think this is this huge dichotomy of, you know, as we said, we're in the age of people feeling lonely at work. While when we look at our process kind of evolution, we're in a teaming phase of process. We value, especially here, you know, an Agilist and people who practice Scrum. We're all about teamwork. It's all about working together as a team. So I'm curious, kind of your take on that. Why do you feel like we still have this sense of loneliness, even though we're trying to move more and more of our process towards being collaborative and team -based?
Heather (22:58)
I think we forgot to know how to connect to each other. And we can't get it all from work, but since we're looking to get so much of it from work, we need to figure it out there. I mean, how many, you know, they found these studies that, you know, you're happier at work if you have a best friend at work. It used to be that people met their spouse or partner through church work, or I can't remember the third one. Now it's mostly online. So even though we're in work, we're not. forming our social circles around work as much anymore. And it's not really, because this started long before the pandemic, so it's not just that we're working remotely and that's why our social circles aren't happening there. I think we forgot how to connect with each other. We forgot to say, how are you and mean it, instead of just waiting for fine. We forgot to have conversations that had something other than to do than what we're doing. We just forgot how to be human and have meaningful connections. And I think when you start having conversations with people about that, like I was just in Prague last month for a talk, and there was another speaker. And we connected beforehand, we sort of knew each other, and his talk was on human connection, my talk was on the future work as human, because all my talks are bespoke to the audience and what they need. And so we coordinated our two talks. And then while I was there, in his talk, he talked about how both of his parents died suddenly, within like three months of each other. And it was a really impactful part of his talk and an impactful part of the most important conversations you have in his life, in your life, et cetera. And then when I was in Prague, I got a call that said my father was dying and I had to leave. And I messaged him. And now we message each other every single day to check in with each other. It was a catalyst for a human connection you don't normally have when you share a stage with someone for five minutes. But I'm noticing more and more that people are trying to do They're trying to make more meaningful and lasting connections that are, you know, we talk about speaking, but really we talk about how are you? What are you going through? How's your breathing going today? What do you have on store for the weekend? And I've done that with a number of speakers who've become close friends. And I think more and more folks need to be, feel comfortable just reaching out and doing that and having a real connection with folks that doesn't have to do with a product that's due or a deadline or a financial goal or what have you, but has to do with. What we all want is humans, which is ultimately connection.
Brian (25:14)
Yeah, boy, I can't agree more. Well, we're getting towards the end of our time. before we wrap, one thing I wanted to ask is, we have listeners here that are leaders. We have listeners that are involved in Scrum teams. We may have some Scrum masters and product owners that are listening. And they're hearing this, probably agreeing a lot with what they're hearing from you. So my question for you then is if you were to talk to that group, if there were some advice you could give them, tips you could give them to better prepare them for the future of work, for where we're headed, what kind of advice would you give people currently working on Teams?
Heather (26:02)
I think the most important thing to figure out, and some people take a lifetime doing it, some people are born doing it, is what do you really care about? What kind of impact do you want to have on the world? How do you like to work? What kind of problems do you like to work on or find or frame? Where do you like to work in the process? Because more self -awareness you have about what really drives you, because that's really your fuel source, the better you're going to be in whatever you do. We tend to tell people, funnel people into careers based on what they're told they're good at, or more likely what they're told they're not good instead of focusing on what gives them energy. Because if we're going to have to learn and adapt, and we are, then we ought to be learning adapting around something we're intrinsically motivated to do.
Brian (26:46)
That's awesome. Yeah, I agree. It sounds very close to, you know, Simon Sinek's kind of find your why basis there of just, you know, that being so important in what drives us. So couldn't agree more. That's that's awesome. Well, I want to be respectful of your time and our listeners time. So, Heather, I can't thank you enough. Every time I hear you talk, I feel like I've taken another leap and have more stuff to go research and and study based off of it. So.
Heather (26:53)
Sure.
Brian (27:15)
Thank you so much for taking some time here to talk with us on the podcast.
Heather (27:19)
Thank you. And I just want to close with one thing because I'm a belligerent optimist. So we have some hard problems ahead of us. We've got division, we've got technology, et cetera. But we have done more in one human lifetime to improve the human condition than all of human history. We've more people out of poverty. We've almost solved literacy. We've connected the globe. It's time for us, in the words of JFK, take longer strides and do hard things. We are up to and we are more than capable of this. So I'm really optimistic about the future that's ahead of us. I think we just have to face some of our challenges. So thank you very much for having me.
Brian (27:53)
Amen, amen. All right. Thanks so much, Heather. I appreciate you coming on.
Heather (27:58)
Thanks a lot for having me. Take care.

#110: Overcoming Organizational Dysfunctions with Lucy O’Keefe

Explore the hidden barriers to successful Scrum adoption as Brian Milner and Lucy O'Keefe dive into organizational dysfunctions and cultural impediments in this insightful episode of the Agile Mentors Podcast.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner sits down with Lucy O’Keefe to unpack the organizational dysfunctions highlighted in their talk at the Scrum Gathering.
They delve into how culture can significantly hinder Scrum adoption and discuss other common impediments like resistance to change, command and control leadership, and siloed teams. Emphasizing the importance of transparency, inspection, and adaptation, Brian and Lucy offer actionable insights to help organizations overcome these challenges.
Listeners will also learn why leadership understanding and stakeholder participation are crucial for successful Agile adoption and the necessity of training in Agile values and principles for true organizational change.
References and resources mentioned in the show:
Lucy O’Keefe
Dart Frog Consulting
Path to CTC - Monthly Cohorts
#109 Leadership and Culture in DevOps with Claire Clark
Agile for Leaders
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, Scrum Master, and now, Certified Scrum Trainer® (CST) where she uses her experience to ensure each student has a great training experience.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner, and we have a favorite back with us today. We have Ms. Lucy O 'Keefe with us. Welcome in Lucy.
Lucy O'Keefe (00:12)
Thank you so much, Brian. Happy to be here again.
Brian (00:14)
Very happy to have Lucy back with us. Lucy and I saw each other recently. Actually, I think it was the first time we saw each other in person, right? Yeah. We finally saw each other in person at the Scrum Gathering that took place recently in New Orleans. And I had the pleasure of getting to see Lucy's talk that she had there at the Scrum Gathering. And...
Lucy O'Keefe (00:22)
It was the first time, yep. Finally.
Brian (00:41)
She gave a talk with Joe Miller called, Scrum Unmasked, Unveiling the Dysfunctions Within Our Organizations. And I thought it would be a good opportunity to bring Lucy back and talk a little bit about this topic, because this is an important topic. And it was a packed room, it was full of people that wanted to know about this as well. So I thought it'd be a good chance for us to share this with the audience. But to start this, actually, before I even begin, I get ahead of myself. myself here a little bit. For those who maybe haven't heard Lucy on the podcast before, Lucy is a CST. She has a CTC. Her company is called Dart Frog Consulting. And she also has started recently this mentoring program with a new smally that is kind of a really interesting concept. It's a CTC mentoring cohort. So if that's something you're interested in, We'll put links into our show notes that you can get in contact with her about that. But if you're interested in pursuing certified team coach certification with the Scrum Alliance, that's a really great way to do that. You get a group of people around it and kind of go on that journey together. But let's talk about this topic. And I thought a good way to start was actually to be a little bit meta about this. I want to go behind the scenes a little bit. and think about where this topic came from, what's the genesis of where this came from and how you and Joe hooked up on this. So give us a little bit of the backstory of where this idea came from.
Lucy O'Keefe (02:20)
So to start, Joe and I have worked together. We worked at a consulting firm together. And funny enough, we actually were both speakers at a virtual conference a few years ago. He was on the panel and I was an actual speaker, but we never met. Back then we met actually when we started working in the same consulting firm. And of course I left the consulting firm a few years ago to go independent, but we just kept in touch and we always wanted to do something together. so when, when I was trying to figure out topics for the scrum gathering in New Orleans, I reached out to him and I asked if he would want to do a talk with me. A lot of times it's much easier to do it with somebody else. And I thought it would be fun because he and I see eye to eye on a lot of stuff. And I think we, we complement each other pretty well. But when we were talking about what topics we'd want to talk about, I kind of always go back to the things that I've experienced when I've been in organizations. And I think, I think a lot of us have experienced kind of something, something similar where people are going to say, scrum just doesn't work for us. Right. I actually, it was actually one of my first blogs that I wrote probably six, seven years ago was about that, about people saying, it just doesn't work for us. There, you know, it's not something that we can do. So I kind of got this idea that this is what we should be talking about. And I always go back to. Ken Trebers quote, and I said this during the talk, you may recall, you know, scrum is like your mother -in -law, it points out all your faults. So this idea that scrum is holding up this mirror, you know, to the organization is something that I always talk about. And I think it's important for scrum masters and others in organizations to understand that, no, it's not scrum that's the issue. It's that we have all this stuff that's not, going well in our organizations and we're just putting Scrum on top of it without fixing the issues, right? So we're trying to put a band -aid on what's going on in our organization instead of looking at the root cause. So I just thought that that would be a great topic to talk about.
Brian (04:27)
I love that. And I think that's a great way to look at it because you're right. It's not something that's going to fix everything, but it does make it very revealing. I remember the phrase I've always heard people use is it's not a silver bullet, it's a silver mirror. You know, like it's going to reflect back very honestly to you what's going on. Awesome. Well, that's that. Thank you for the backstory. I really appreciate that because I know a lot of people, you know, if you're listening to this, you may be considering, you know, do I want to submit and try to speak at a conference? So.
Lucy O'Keefe (04:41)
Yep.
Brian (04:57)
just to give a little background to where those kind of ideas come from. I thought that would be interesting little sideline there. So let's get into our topic. Let's talk about some of these dysfunctions because I know the main point of this was talking about organizational dysfunctions, kind of some common problem. So hit us up. Give us a few of these big organizational dysfunctions that you guys talked about.
Lucy O'Keefe (05:22)
So I think the main one and one that's probably going to resonate with a lot of people is culture. For me, culture is always the biggest issue. People are the biggest issue, right? You know, as you know, you probably remember this, right? In the previous Scrum guide, it would say, Scrum is simple to understand, but difficult to master, right? Or difficult to implement because it involves people. So culture is the biggest issue and culture encompasses... quite a few things, right? It could be resistance to change within an organization. It could be a lack of empowerment. It could be command and control, which I'm sure you've seen in plenty of organizations. I've seen plenty of organizations, even though we know that we are hiring the best people, a lot of leaders or managers actually I'll call them, you know, still want to be in control, still want to be the people telling people what to do. And it's very hard to go to... to a way of working where it's like, okay, I need to remove myself from the equation and trust that these people are gonna do what they should be doing. So I think culture encompasses a lot of the other things that we talk about when we're talking about organizational impediments. Another thing is organizational structure. Are we highly hierarchical? Are we a matrixed organization? Do we still have these silo teams, right? That work on just specific skills? And I'm sure you've seen this. I'm sure you've worked in waterfall just like I have in the past, right? You have your business analysts on one side. You have your designers on another side and then your developers and then your testers, right? And they're all reporting into a business analyst or tester or developer or anything like that. So there is no cohesive team that has one. focus or one objective. You know, we're matric, you know, getting these people out of that matrix and putting them into a team. But they're all just interested in their own thing, right? It's a very siloed way of working. So it's very hard to make that transition into, okay, we are a product team and we work together. And we have to be dedicated and stable. Because we're not used to seeing that in a lot of organizations, people are not dedicated to teams. And we're talking about waterfall. I have barely seen any of that. I used to have a team where, and there was already a scrum team, but we had three BAs on the team and they were each 33%. And that's something that is very normal. And even when I'm teaching my classes and I'm sure you have the same questions or comments, a lot of people are like, well, this is very hard for us because we have John Doe here who, you know, he's in five different teams. How is he going to go to all these events? So that's definitely another organizational impediment, which for me kind of goes back to culture as well. Right? So those things are big things. Leadership not understanding. Yeah, sorry. Yeah, no, go ahead.
Brian (08:10)
Yes. Yeah. I was thinking, I was thinking, sorry, I didn't mean to interrupt you, but I was just, I was thinking the same thing that when you said that, that just, yeah, it is very, the hierarchy of the organization is very cultural. And if you, you know, if we're, we're trying to empower teams and instill in them this idea that, Hey, you need to, in order to move fast, you've got to have autonomy and you've got to have the ability to go and make decisions. that's, that's very. much ingrained in how we structure our organization. If I have to get approval for everything I do, that's going to run counter to what we're trying to do in a Scrum environment. So I love that you made that connection. I absolutely agree with you. It's a very cultural thing.
Lucy O'Keefe (08:59)
It is, it is. Yeah. And as I said before, I think a lot of the impediments we see go back to culture, leadership, understanding leadership participation, a lot of organizations when they're thinking about agile, they're thinking about scrum. It's like, okay, the teams need to do that. All right. Let's, let's start in IT and our IT teams are going to start doing scrum and who cares about the rest of the organization. We're going to keep thinking the way that, that we've always been thinking. We're going to keep budgeting the way we've always budgeted. And then we have. We have a lot more resistance, a lot more conflict because we have a team that's trying to work in a certain way. And then you have stakeholders and leadership that are expecting things to be the way that they always were. So stakeholder participation, for example, you know, a lot of stakeholders are going to be like, well, I already told you what I want. Why are you coming to me every two weeks or, you know, however long our sprints are, you know, for to get feedback. You know what I want. I shouldn't have to talk to you about it. Right. So there's that lack of understanding of what's in it for them. So back to culture again, right, understanding that this is a whole cultural shift. It's not just a team shift. So leadership needs to understand that. And of course, as you know, you know, we have, you know, certified agile leadership programs that I'm trying not trying to do a plug here for those classes. I don't even teach them. But.
Brian (10:03)
Yeah. Ha ha ha.
Lucy O'Keefe (10:22)
it's so important that leadership understands what it means to be an agile organization and what it means to lead in an agile organization. And I think when they do that, when they're able to get that understanding, it's going to make it a lot easier for everybody to succeed. So once again, that is another big impediment that I've seen is the lack of leadership and stakeholder understanding.
Brian (10:46)
Yeah, absolutely agree. I mean, it's almost like the concept seems to be more, like you said, we'll start from the team and build up when really it should be more of a from a top down or even not even kind of whole, right. Right, it's kind of, it's a whole organization thing. And if we try to compartmentalize it and say, no, we're just gonna do this group.
Lucy O'Keefe (10:57)
up and down. Or even from both extremes and meet in the middle. Right? Yeah.
Brian (11:13)
then we're already kind of setting ourselves up to fail a little bit because I can't change the culture of just one segment of my organization. If I do that and they have a different culture than the rest of the organization, then we have cultures at odds with each other and they're set to fail. The more dominant one's gonna overtake the lesser one, which is usually gonna be the scrum side of things. So yeah, I completely agree. Yeah, yeah, frustration.
Lucy O'Keefe (11:37)
Exactly. Yeah. And it causes a lot of frustration. Yeah. It causes a lot of frustration for the team. Right. So I was actually at a, I was contracting at an agricultural manufacturing company. I may have brought this up before, but like the, the stakeholders didn't understand why they had to come to sprint and review, why, why they had to talk to the product owner instead of just talking to the engineers themselves. And it wasn't until I had. the lunch and learn with the stakeholders and help them understand what's in it for them because that's what's so important. How am I going to, how is it going to improve things for me if I abide by what you're trying to do? It wasn't until we did that, that they were like, I understand now why I need to talk to the product owner. I understand now why I shouldn't be dealing with the developers or the engineers themselves. I understand now why my feedback's needed. Yeah, it's great that now I have a say in the process. I have a say in the outcome. So it's not like people are trying to just be difficult. They just don't know any better, which brings us to one of the other organizational impediments, which is lack of training and understanding. Cause we can't just train the team. We have to, yeah, I mean, we don't have to train everyone in, you know, a CSM or anything like that. That's, that's not it. Right. But they need to understand the basics of how, how agile works. What are the values? What are the principles? What, what are the benefits of working in this manner? Right. It's, it's not about doing the thing, but it's how is this going to impact who is and how, how are things going to be better after you start working this way?
Brian (12:52)
Yeah. I've had a lot of conversations about this in the CSM class of just talking to different people and saying, you look at these agile manifesto values and principles and if we can't get an alignment on these things, right? If we can't look at these things and say, yeah, I agree. My philosophy is one of that's responding to change over following a plan. I believe that you should be more. able to respond to change, then you should be about following a plan. That's a fundamental kind of core value. And if my organization or if leaders in my organization, that's kind of the key here, right? If the leaders in the organization think, no, no, no, it's about following the plan. We have to establish this amazing plan and then follow the plan. Well, it doesn't really matter what we do at the team level because... somewhere up the chain of command, we're going to have to have that perfect plan that we try to execute on and the leadership is driving that. So we have a mismatch on just our core kind of understanding.
Lucy O'Keefe (14:26)
Exactly, exactly. So when I go into a new organization, one of the first things I do during my assessment phase, I actually go through every single one of the values and principles with leadership and with the teams. And I ask, which one of these are you doing well? And then we talk about that it's the minority usually. And then it's like, okay, what do we need to do to ensure that we are responding to change or following a plan or that we are... you know, focusing on working software instead of measuring something different. So we go through every single one of those because, as you said, that's where the value is. Understanding those values and principles, it's not about doing scrum, kanban, whatever it is. But if we are following those values and principles, then that's when we're truly going to be algebra and that's when we're going to see the benefits of working in this manner. It's not about the practice, but it's about your beliefs as an organization.
Brian (15:24)
Yeah, yeah, there's no practice that we're gonna put in place that's gonna solve it all, right? I mean, there's practices that can assist and help us, but the practice isn't the cure, right? The practice is just something that can assist. It's like having crutches, you know? The crutches aren't gonna heal you.
Lucy O'Keefe (15:30)
Not at all. A way to get there. Yeah. Exactly. Right. Yeah, yeah, yeah. The practice just a vehicle, but you have to do the work to get there for sure.
Brian (15:51)
Yeah, that's a great point.
Lucy O'Keefe (15:53)
Yeah, so I think those were the main ones that we talked about there. You know, of course, we only had an hour, so it wasn't, there wasn't a lot of time to talk about every single one. But I think that, you know, and you were there, of course, but a lot of people came up with their own impediments that they were seeing in their organizations. And I think a lot of them aligned to what we had to say as well, because I think it is pretty standard in organizations that are just starting out.
Brian (16:02)
Sure. Yeah.
Lucy O'Keefe (16:22)
that you are seeing a lot. I mean, not just starting out actually. I mean, I've seen an organization that they say they've been agile for years and they still have a lot of these issues. So it's pretty clear that the culture again is the biggest issue with being able to adopt Scrum correctly or adopt an agile way of working correctly.
Brian (16:43)
Yeah, and I think you hit the nail on the head with the fact that it's just, there's not the time always spent to try to get to the root cause. We're a culture of quick fixes. We want to find something that's going to put in place and take this pill, do whatever, and then it's just going to be solved and everything's going to be fine. But you know, it... For instance, we've used this analogy quite often, the idea of weight loss. There are things that can assist you with that. There are things that can give you help along the way, but there's not a silver bullet to do that other than changing the way that your lifestyle is. You have to change. And please, anyone who's listening, don't think I'm saying this because I have this perfect, because I don't. I'm very bad at this. But I know that the way that I change You know, my overall health is by changing the lifestyle, changing what I eat, changing, you know, my exercise patterns. And that's hard work. It's hard to change that kind of core value in my life, but that's what actually makes the impact. The other things are dressing around it. Right.
Lucy O'Keefe (17:58)
Yeah, that's what's gonna make you change. Exactly. I mean, think about people who go for, and just staying with the same topic, right? For some bariatric surgery, right? So a lot of times, like the doctor will say, I used to watch my 600 pound life, don't judge me, a little bit, just because it's kind of, it's interesting. And yeah, I mean, they'd have to lose weight before they had the surgery.
Brian (18:06)
Yeah, yeah. Hahaha.
Lucy O'Keefe (18:25)
And the majority of people after they had the surgery and kind of lost weight, they just went back and balloon back up because they didn't change their lifestyle. So as you said, yeah, it's great that these band -aids exist, but if you're not going to do the work yourself, then it's really not going to work. So what is the root cause in this case, right? We're eating badly and we're not exercising. So that's what we need to change and not just, you know, take a pill or do a fad diet or get a surgery that... It's not gonna work if we don't change our ways.
Brian (18:55)
Right, and just for the listeners too, I mean, Lucy and I are not medical professionals in any way. So, you know, we do not mean in any way to try to belittle, you know, treatments and therapies that people use for legitimate purposes and all that stuff. Please understand, right? Gotta make that disclaimer. But I think you're right. You know, like I know in my life, there's been times when I thought, there's some diet supplement or there's something else that, you know, is gonna...
Lucy O'Keefe (19:01)
No. No, no, no.
Brian (19:25)
be the thing that really cures this and changes it. But what I've experienced time after time is, no, you really just got to do the hard work. You got to go to the gym and you got to get up and you got to change what you eat and that kind of stuff. And that's what really makes the impact. Well, the same thing here with our organizations. There are practices and the things we can put in place. And there's always hot ones that will be the hot one of the day. I remember when DevOps was kind of the... And we just talked about DevOps in our last episode. It is an important thing. It is a very important thing, and it can give you a lot of boost. But it's a set of practices. And our last guest, when we talked about this, talked about how it's really more of a mindset. It really is more about how we have to change the way we see things. So even there, when we approach things like DevOps, yes, there are practices, there are tools we can put in place. But if we don't change kind of our approach to how we do things, then it won't matter. It's just another thing that we have to learn and put into the workflow.
Lucy O'Keefe (20:32)
Yeah, yeah, exactly. I mean, you know, the definition of insanity, right? Doing the same thing over and over and over again and getting the same results because that's what happens if you just keep putting band -aids on things, you're going to end up, you know, encountering the same issues over and over again. So if we don't have that mindset that we are going to make the change and the foundational change to ensure that everything works out, then, you know, then it's we're going to keep having the same issues and we're going to keep hearing this crime just doesn't work for us. Right.
Brian (20:37)
Ha ha ha.
Lucy O'Keefe (21:02)
So, yeah.
Brian (21:04)
There's something that also comes up in classes sometimes that I think one of the things that I found is that getting back to that transparency inspection adaptation, that if we as an organization really value that process and value the idea that, hey, we're going to be transparent about how we do things. We're going to not just ignore when there's a problem, but we're going to inspect it and get to the root cause. And then we're going to find a new way of doing things. that we can just latch onto that. That's a huge cultural change, right? And just kind of buying into those concepts. And what I found is in a lot of instances, I talked about this in the ACSM, a lot of instances, you can directly relate it back to a lack of one of those three things. Are we not being transparent? Are we not actually inspecting? Are we not actually adapting?
Lucy O'Keefe (21:57)
Yeah, yeah, yeah, those three pillars are definitely important. And I think that they're the foundation of what we are trying to do. And you're right, if we're not being transparent, inspecting and adapting, then we're not being agile, first of all, but that's something that needs to exist throughout the organization, not just within our work, within our teams, but are we being transparent in our relationships? Are we inspecting and adapting how we are dealing with our employees? Are we inspecting and adapting how we are budgeting? I mean, everything, right? We need to be... using that empiricism on a daily basis to ensure that we are headed in that direction. And if we do that, as you just said, the culture will shift organically when we're employing those three pillars, for sure.
Brian (22:42)
Yeah, absolutely agree. Well, let's, I want to meta this a little bit more here at the end, because I want to know kind of how it, how the fallout from this happened. So, so you, you have this idea, you work with Joe, you, you come up with this topic, you go, you present this. What kind of a follow -up did you get from this? Did you get a lot of good questions from people afterwards? How did the talk go? What did you, what, what, what kind of learnings did you take away from it after you gave the talk?
Lucy O'Keefe (22:47)
Yep. So I think it was received very well. There were quite a few people that came up to us afterwards and started asking questions to the point that I was actually late to a meeting after that. But anyway, I've had quite a few people reach out to me on LinkedIn, you know, talking about, we really loved your topic. And I actually, I got my reviews from it. And I think a lot of people appreciated that we had action items at the end.
Brian (23:22)
Hahaha.
Lucy O'Keefe (23:38)
So for those of you who are listening, we actually had an action plan where people could create an action plan on how they are going to start dealing with the organizational impediments in their organization. So a few people appreciated that. So it was pretty good, you know, pretty good feedback, I think, that we got from that. I would have loved for it to have been a little longer, so we could have gone a little deeper because it is, there is a lot that we can unpack. when we're talking about organizational impediments, one hour just isn't enough time for that, especially when you're trying to make it a more engaging session and not just talking at people. But I think if I had to do this again, I would probably try to do a little less and maybe go a little deeper instead of trying to talk about maybe so many things and barely touching the surface. But I think it was...
Brian (24:28)
Yeah.
Lucy O'Keefe (24:36)
I think it was pretty good. I know you're there, so you let me know.
Brian (24:38)
It was great. Yeah, no, it was great. And so, yeah, I hope you're encouraged by that. But yeah, it was a great talk. And like I said, I heard a lot of good comments from people afterwards. And I think that's pretty natural for us as speakers to kind of rethink afterward and say, maybe I could have done this a little bit different or I could have done this a different way. But, you know, it's tough. Like you said, you've got an hour. And within that hour, you're trying to work in some... interactivity, so it's not just you talking the whole time and you're trying to keep the group engaged. But then you get a lot of information and you just, I got to share all this stuff and I only have an hour to do it. Especially, as CSTs, we're used to talking for two days at a time. So, yeah, an hour is like, you know.
Lucy O'Keefe (25:26)
Exactly. So an hour is nothing. Yeah. Yeah.
Brian (25:32)
the break or something, but yeah, you're not used to trying to fit all that information down into a one hour stretch.
Lucy O'Keefe (25:40)
Yeah, and for me it's like I love answering questions. Like if I could do a talk and then do an hour of just answering questions, I think I'd be like really, really happy because I mean, even when I've, you know, taught with Mountain Goat and all that, you know, being able to answer questions at the end of class, that's like my favorite and I do that in my classes as well. So not being able to give time to actually answer, you know,
Brian (25:47)
Yeah.
Lucy O'Keefe (26:04)
questions from the people who are having the issues for me was very difficult not being able to do that because that's something that I enjoy. And, you know, but at the end of the day, I do love speaking. You know, I just, it's one of my passions now, which is kind of funny because I used to be really introverted. But yeah, I think, I know it was a really good experience. It was my first time speaking at the Scrum Gallery. I've spoken at smaller conferences before, but that was my first big one. So it was, it was great.
Brian (26:19)
Ha ha. Awesome.
Lucy O'Keefe (26:34)
I hope I'm able to do it again.
Brian (26:36)
Awesome. Well, it was great. It was a great talk. And I appreciate you coming on and sharing this information with us, because not everyone can come to the Scrum Gathering. And that's one of the reasons why we try to have some people come on that do speak at it, so we can share some of that information in these small little podcast windows. So. Well, Lucy, thank you again for coming on. I appreciate you sharing your talk with us and kind of the behind the scenes of it. And hopefully we can have you on again soon.
Lucy O'Keefe (27:11)
Thank you, Brian.

#109: Leadership and Culture in DevOps with Claire Clark

Join Brian as he chats with DevOps expert Claire Clark about the cultural and mindset shifts needed for successful DevOps adoption, the concept of 'shift left,' and the crucial role of leadership support.
Overview
In this episode of the Agile Mentors Podcast, Brian and Claire Clark, founder of Sienso, winner of the The Great British Business Woman Award, and freelance software development executive, delve into the world of DevOps.
Claire explains that DevOps is far more than just tools and processes—it's about fostering the right mindset and cultural shifts within the team. They discuss the 'shift left' approach, emphasizing the importance of considering end stages of software development early on.
Claire highlights the critical role of leadership in supporting DevOps principles and aligning team goals. She also shares strategies for measuring success through a maturity matrix and underscores the importance of continuous improvement. This conversation provides a holistic view of DevOps, integrating both technical and cultural aspects.
References and resources mentioned in the show:
Claire Clark
Sienso
#108 Adaptive Organizations with Ken Rickard
Mountain Goat Software’s Working on a Scrum Team
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Claire Clark is a multi-award-winning transformational leader and Chartered Engineer with over 20 years of experience in Software Engineering. Specializing in leading high-performing teams, Agile transformation, and DevOps, Claire has successfully managed complex projects across various industries, including cybersecurity, logistics, and financial services.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. And today we have a very special guest with us, someone I've been trying to get on for a while. We have Ms. Claire Clark with us. Welcome in, Claire. Glad you're here. Claire has been in our world for a while here at Mountain Goat. And she's had lots of interactions with us and Mike and over the years.
Claire Clark (00:13)
Hi, hi, good to meet you.
Brian (00:29)
And just for people who aren't familiar with Claire and her work, she is, I guess the best way to describe it is kind of a freelance software development executive. She kind of comes in in high level, kind of more temporary positions, would you say, Claire? Okay. Yeah, kind of coming in on the spot positions to help get people over the hump and get them situated and set up the way they need to be from an executive level.
Claire Clark (00:44)
Yeah. Yeah.
Brian (00:56)
Her company is called Cienso and she's won numerous awards over the years, but most recently she had a really huge honor. She was the winner in the engineering category of the Great British Businesswoman Awards. So first of all, congratulations on that. That's awesome. And the reason that we wanted to have Claire on was...
Claire Clark (01:15)
Thank you.
Brian (01:22)
just to share a little bit of her knowledge with us, and particularly the area of DevOps. She's done a lot of work with teams and building the teams. And we've had some really interesting discussions offline about this area. So let's start and just set the table a little bit here, Claire, for everyone. When we're talking about DevOps, first of all, let's just kind of explain what that means for people who aren't familiar with it.
Claire Clark (01:47)
Yeah. So I tend to describe it as it's a way that teams collaborate for the continuous delivery of a product from end to end, to get the value of the product to a customer. So it, it's not a specific process, a specific tool. It's a little bit around the mindset and approach to things. And how you get that continuous development and delivery of a software product, for example, to a customer. So yeah, I think people often tend to see it as possibly it's a tool thing or it's a process thing. And it's not quite that, it's all elements of that and a mindset side of it as well.
Brian (02:42)
Awesome. Yeah. That was the thing that I found really interesting in our conversation. And some of the things I've seen you write about this online, it's just the concept here that DevOps is really kind of a mindset. It's kind of a cultural thing. It's kind of culture first. And a lot of times we think of this as a set of practices. So let's get into that a little bit. How does the adoption of DevOps kind of change the culture?
Claire Clark (03:03)
Yeah.
Brian (03:11)
in an organization.
Claire Clark (03:12)
Yeah, I think in terms of changing the culture, it taps quite a lot into the agile side of culture, I guess, in that it promotes that collaboration and the continuous delivery of an integration of software, of a software product to a customer. So what I found is that, for example, with agile, That brought together a big collaboration with development and test and your product function. And then the DevOps kind of movement, I'll call it, sort of come to life a bit more. And that's where it then changed the culture again in terms of extending, I guess, the kind of agile side of things, but embedding the continuous integration and delivery into what the software engineering team does. So the operational aspects of the software. become more forefront into the, into like the team's thinking. They become like shift left. Do you think about this earlier? How are you going to maintain and deploy systems and how are they going to integrate? And I think that's where it's really shifted the culture quite a lot where instead of it being the, you know, we create, create the software and now there's an operational aspect of how we then deploy and integrate some of the dev op development and test aspects. into that. So I feel like it's really got into the mind, a lot of people's minds that we need to think of the full end to end when we're talking about building and delivering a product. It's everything and it's how you can make that pipeline that chain through that development team more of a continuous approach. So teams that have succeeded with Agile tend to be able to approach. embedding that DevOps mindset that bit more because there's a lot of overlap between some of the principles and the mindset needed between the two. So.
Brian (05:16)
Yeah, no, I absolutely agree. And you mentioned a term there that I've always loved in the DevOps community. And just in case people there aren't familiar with it, when you talk about shift left, what does that mean to you? What do you mean by shift left?
Claire Clark (05:32)
So for me, it means if you took a typical software development lifecycle and there's requirements, development and test and so on, it's very sequential and it typically follows the order. And what the mindset brings with DevOps and shift left, and you see this a lot with testing the term shift left is think about the latter stages up front. So the more you can think about some of those end, stages of software development and deployment and integration to customer systems, the more you think about them upfront, the more you start to design the way of working in what you're doing through agile and your continuous approaches, you start to embed that earlier. So it becomes a thought right at the front instead of being an add -on at the end. So shift left in essence being... what normally you would have done in a sequential manner and ends up far down the chain, you start trying to identify how could we do, how could we bring this earlier? What, you know, you start thinking about earlier, start looking at the practices and tooling and all those processes that people are doing in the software team. You start then to identify that can change the test, your test and your design. That can change then what you've. product functionality and non -functional requirements need to be. It's always about making sure that them later stages, what traditionally were later, are thought about upfront at the start, designed, planned in, and continuous efforts all the way along the software development lifecycle to embed them. So it becomes an easier stream from end to end and more automated and more, I guess, more constant flow through the system. So yeah, shift left is think about the end at the start as much as you can.
Brian (07:37)
I love that. Think about the end of the start. Yeah, that's a great way to phrase it. I love that. So when you we've talked about kind of the mindset behind this, the culture behind it. So when you when you come in and work with a new group, do you start with kind of a more culture approach and work on mindset first or you kind of go right into practices and let it kind of flow along the way? How do you approach that kind of shift when you start to work with a new New team.
Claire Clark (08:07)
Yeah, it's interesting because it's the balance because when you're introducing any of these practices, it means typically it would mean there's some form of change for a team and change itself is difficult for people to go through at times. And in terms of embedding some of the success of the frameworks and the processes, you can only really succeed if people are coming at that with the right mindset. because otherwise you can get people who say, I don't want to change. I don't understand why I need to change. So you can explain the kind of value in why to do some of these things. But fundamentally, what underpins that in all of this is a mindset. And in Agile, I've talked before on some presentations about how important an Agile mindset is. So being able to sort of... accept that, you know, change will happen, you know, change is the only constant that happens and the more that people can start to understand, I guess, appreciate that and then come up a new thing, a new challenge, start coming at that with how can I make that work and it's then subtleties that if you don't challenge the two together,
Brian (09:11)
Right.
Claire Clark (09:34)
you won't succeed in getting the benefits from Agile and DevOps. You could have the best processes in the world, but if the mindset's not there, you're never going to reap the benefits of what you're trying to achieve. So I try to work with teams on both fronts at the same time, because like I say, you can have the right mindset, but they might not understand the process or the right process. If the mindset's not there, the implementation won't come to fruition.
Brian (10:02)
Yeah, we actually just had another episode that was, I think it was our last episode actually, looking at the order of this. But when we were talking, we were talking with Ken Ricard about the overlap between change groups and the lean change overlapping with Agile and how really that ability to shift and adjust and change is really at the central core of it. What other kind of key cultural shifts do you feel like are necessary when a group starts to adopt DevOps practices that they really need to get a handle on?
Claire Clark (10:43)
Yeah, I found that some teams really struggle with the concept of the shift left side of it. So it tends to be, we've always done it this way. And because it's become second nature to do certain aspects, you know, certain aspects of the software delivery and development in a certain manner, that trying to open up people's minds to say there is another way and it's different.
Brian (10:52)
Yeah.
Claire Clark (11:13)
And it will feel different, but you've got to be open to trying that. And here's why. So I think the cultural side of it is I still see at times some teams that are really focused on DevOps tooling. And it's, I think the mind set shift, the cultural shift is it's not, that's a part of it. Part of DevOps is the tooling you have to do that. And same as when people struggled on the agile journey initially is, you know, thinking agile was, you know, user stories and Jira and yeah, Jira and things like that. And that's, that's a tool that facilitates you to work in that way. But having a tool like that, a Camman board it or so on, doesn't make you agile. And it is that.
Brian (11:50)
Sure. Right. Right.
Claire Clark (12:08)
It's that same thing with DevOps. There's some brilliant tools out there now and we are getting that shift left approach and using them tools to integrate at different stages of the software development more of the operational aspects and getting that continuous integration. But I think with Agile, people, a lot of teams have gone over time now and through the great work like what Mike does, helping people understand how to. to really come on board and get the best out of an agile way of working. It feels like with DevOps, we're in a similar spot where some people have really got it. They get that mindset, they live and breathe the kind of DevOps side of it. But there are still a lot of teams that you come across and DevOps is still a tool. It's still a thing. And maybe they get that tool in place and hey, presto, we're DevOps. And it's like... Some of the subtleties that you don't see, it's not in a process, it's not in a tool. That behavior and that mindset is what I think there's still a bit more of a journey to go on across the industry with that DevOps side of it. It just feels so similar to when Agile sort of come out and the challenges people were facing there and what we believed Agile is and what Agile really is.
Brian (13:29)
Yeah, that's a great analogy. I love thinking about it that way. I mean, it's like if you have a boat that's in a garage, you can get in the boat, you can turn it on, you've got a fantastic tool, but if you don't ever put it in the water, it's not going to really live up to its purpose. And that's kind of the way people, I think, sometimes look at some of these tools is, well, we got the tool, so we're sailors now, right? We can... We know how to drive our boat because we have a boat. No, you got to put it in the water, right? You got to actually know where to use it.
Claire Clark (14:01)
Yeah. Yeah. Yeah. One example I always think of is it's a bit like having a scenario where there's a driver and there's a really fancy, you know, car, but it's got no engine. So you can have all of these elements and you could say, I'm a racing car driver, I've got this really fancy car.
Brian (14:18)
Mmm.
Claire Clark (14:25)
It looks great and you know, it's got all the features on it and all of the buttons you can press, but, but underneath the core of that is the engine. And I liken it to like with Agile and DevOps, the core underneath this is the mindset. And it's that, it's that hearts and minds of the principles behind DevOps principles behind Agile that if people buy into that, the rest is a bit easier to implement. But often people can have tooling shoved at them or a nice fancy car in that scenario. But it doesn't come with the fundamental, the heartbeat, so to speak, inside that really embraces the principles behind some of these things. And it's that where the cultural side comes in that people really do not just read the words and say collaboration. They act it. They do it. They...
Brian (14:54)
Yeah.
Claire Clark (15:21)
you see them behaviors and I think sometimes with Agile and DevOps some of the principles or the value that you get out of them once people describe them they love it, they say it sounds great yeah we should do at DevOps we should do Agile but if they're missing that connection to the heart underneath the value is the principles. even if they sound great, if they don't exhibit the behaviors, that will affect the culture. And you often can see that in teams where, you know, the quote processes, quote tools, but then the behaviors are almost opposite to some of the values that underpin agile and underpin DevOps. And then, yeah, for me, I would say you've got to try to tackle both together.
Brian (16:08)
Yeah.
Claire Clark (16:13)
And you just won't really get the success and the team won't enjoy it. Yeah.
Brian (16:19)
Yeah. So I think one of the things I've seen too, when people implement DevOps is they kind of miss, it seems like they miss the heart of it, the point. If you had to sum it up, what would you say is the purpose? Why do we need DevOps? What is the purpose that the DevOps, a good DevOps team, what's really their driving purpose?
Claire Clark (16:29)
Yeah. You see it work really well with teams, the successful teams, when their focus is about continuous integration and delivery of functionality to customers as quick as they can, not, but without, you know, still with the quality and the stabilization. But they, they focus quite a lot on that optimizing that, you know, how soon can we break something down, prove it, test it. And get that out to the customer so the customer can realize the value. So for me in the, in the DevOps, it's where the teams really focused on making that, that channel of that functionality is seamless as possible and making it as efficient as possible so that, you know, it is from end to end, create the product and it's good to go as soon as possible. So. It's less about when you hear people talk about tooling. It's more when you hear them, the thinking shines through in what they're saying. In how can we get that sooner? How can we, how can we use the principles to get value to customers and prove what we're doing is right along the way.
Brian (18:05)
Yeah, and it overlaps perfectly with what we're trying to do in Agile with delivering value. And I love that kind of marriage that it seems to have there. How about from a leader's standpoint, what is important for leaders to understand? How can leaders better support DevOps in their organizations?
Claire Clark (18:28)
found that from a leadership perspective, and I've supported teams on this, is being open about how different it might feel and how different that might be in terms of where we're working. And having an initial discussion to check with people, their understanding of what DevOps is before you start going on that journey. So one exercise I did once was, just simply to ask everybody in the room before we started going on that kind of DevOps journey. What is DevOps? What do you believe it is? And the responses in one team alone was incredibly different. How they described it, someone said, it's someone's job over there. It's to do with, it's like that way. And then, yeah, described it as it.
Brian (19:18)
It's Jenkins.
Claire Clark (19:24)
It's nothing to do with me. I'm software engineer or I'm tester. It's more business and support type things. And I think doing that exercise at the start was really good to sort of understand and appreciate where we're actually starting on that journey and where even misconceptions have come in or where people have not had the opportunity to somebody to share and explain to them what. What in essence is DevOps? And, you know, same response again, a lot of names of toolings come up and, you know, there's this tool, this tool, this tool. And so with Agile, I tend to talk about things like there's the principles, the values, frameworks, and, you know, when we started to describe DevOps in a similar way to the team, they were able to relate that to that structure that you get with Agile. where I was saying, in essence, there's some principles behind this. There's some aims, some aspirations, some goals that we're going for. Just put the tooling aside for the moment. We can change the tools, whatever tool we want, but if we just focus on that. So I've sent her a lot of the discussion around that initially. And from there, that's when as a leader, you can start to then move on to some of the processing tooling. But I think you've got to really listen to the team. understand the challenges they've got in how they work now and what would it mean on a change management perspective to migrate to that kind of more DevOps way of working. So you've got to listen to your team. You've got to understand the products at hand that you're working with and support the team as much as you can on that, both from process tooling, but on that mindset. because of us, if you don't, what you end up with is a lot of friction in a team and a lot of friction against the thing like DevOps and pretty much what I think you saw in the industry when a lot of organizations moved from waterfall to agile. There was some people who, you know, they read about it. They loved it. They're on the journey. Let's try it. Let's go. I get it. And then there was some people where they just had that struggle that, that.
Brian (21:26)
Yeah.
Claire Clark (21:48)
What do you mean? So if I'm in traditional way of working, how does that translate to the new way? And you've got to take that time as a leader to allow people to have that open debate around it and support one another to really understand that fundamental side of it. And I think often a lot of organizations hear about DevOps or hear about Agile. And within a couple of months, that's it. The one agile in DevOps in get all the benefits. It sounds great. But as a leader of a software team where you're trying to introduce that you have to appreciate that every team's journey is different and approach it as needed. And that it might not be a quick five minute. If it definitely isn't to turn that around. And, and you can start getting some of the benefits incrementally along the way. I was like agile, I would say. And eventually you'll get the full benefits that people buy into when they hear about these amazing ways of working that will bring them so much better opportunity.
Brian (22:59)
Yeah, I think it's such a great point too, because like you said, if you have a misconception about what this is and what our purpose is, where our point is, we talk about individuals and interactions over processes and tools, and we look at that and we actually dissect it and start to think about it as an organization and decide, you know what? No, we really are more process than tools over individuals and interactions, then that's going to be a problem.
Claire Clark (23:26)
Yeah. Yeah.
Brian (23:28)
You know, that's gonna be, we're not gonna be successful because we don't have that cultural value that underpins kind of why we're doing things the way we are.
Claire Clark (23:40)
Yeah. Yeah. And, and exactly that, when you say about the, the interactions and then behaviors and so on in, in a team and then over, you know, processes and tools, it's, it's often that side of it. What in some organizations is the afterthought and you know, the tooling space, just get this tool and it'll help us with this. Then get the process on the tool so we can get the benefit from the tool. And then afterwards it's, let's help the people who are not on the journey with this, are struggling with the journey and so on. And, and I tend to think it's, focus on, on what their understanding is, the alignment, get that shared understanding. like what we do through our job as working, get the shared understanding. And then once you've got that alignment as to what it actually means in principle and. everybody can feels they can understand and appreciate that. That to me is where all the other aspects just become easier. But naturally it tends to be focused the other way around on get the benefit. We need to get the tool, we need to then get a process for the tool and then let's work out where everyone's happy or not.
Brian (25:01)
Right. So you've done these kind of transformations in multiple places. How have you traditionally tried to measure success? How do you know where you are in your journey of this DevOps transformation and what are you aiming for as a successful endpoint?
Claire Clark (25:20)
Yes, I often, I sort of built, maturity matrix on a lot of these things. So from agile and DevOps, and in there, I cover that human side of it. There'll be heavy side. And from a maturity perspective, I kind of benchmark it at the basics and then eventually it gets more mature and eventually it becomes self kind of, I guess, running and organizing and. There's certain behaviors and process, maturity that you expect to see at each kind of stage of that journey. So you might start off at the beginning, it's chaotic, there's that misalignment on what everyone thinks this is. and you know, you build on that over time and you just keep rechecking on that maturity kind of this and that score. Where are we at across all of those different things? And it's quite easy then to assess and say, was, was, was, we're getting better, but we're not a kind of self sufficient, systems running. Everything's quite independent kind of model. And then obviously you get to the point of utopia where it's smooth, it's running. We're constantly looking at how we can improve this. and we take action, self -action to do that. So I tend to like look across the horizon of agile and DevOps and team culture. and behaviors. And at that, that's where I kind of understand then what level we are at the moment, where, which areas in particular do we need the most support? And that then kind of shapes how I approach things with that team, the speed at which you maybe then try and bring some of that change in. But importantly, what actions I need to do to, to support that team on that journey of maturity. And like I said, each team different and some it's easier to move up through that maturity across all those pieces than it is for others. But you've just got constantly like with Agile and DevOps looking at how can you improve what you're doing now? And it is a journey you can always improve. And to get there, you've got to have that goal. You've got to have something to aim for. What does good look like? and have that as a common goal across the team. So we know what the North Star is, we know what we're aiming for, we know that, you know, we really, really are agile, really are doing boxing, getting benefits out of this. And then really be honest about where you are as a team and then work with that team to support them on listening to if they've got ideas and perhaps, and best practices in there that they've maybe done somewhere else before they want to apply. But... For me as a leader, the biggest thing I can do is all those learnings that I've got from all the different experiences is to bring that to that team, share that and say, I've seen an example like this before. This is what we've tried. How would we want to try that here? Because along my journey to success and like you said earlier, winning these awards and so on, it... It's been a challenge, you know, without doubt it's, it's, it's software development can be difficult. Developing teams and bringing changes into business is not easy. And along the way I've learned, you know, some really good practices. And I think as a leader, you've got to really be able to come in, appreciate the team and the scenario that you're in and work out the best path forward. And every path of every organization is different. but you can use your experience to work out how to navigate through that journey. I think the key thing to do as a leader is to appreciate that every team, every organization you work with has a different journey. But what you have learned along the way as a leader is where the wrong turns are, where you can get the most efficiency, where common problems are, but importantly, how you've managed to overcome them. How... You know, learning that is difficult, but using that and having that appreciation with the team to impart your experience and share that with them. Listen to them. And the biggest thing I ever says, I'm on this journey with you. I'm not here to do this journey at you. I'm here to help you on that journey. I can show you what a kind of good Northstar looks like, but I'm in this with you. I will support. We're in this together.
Brian (29:52)
Yeah.
Claire Clark (30:05)
And as a leader, I'll do what I can to help you on that journey with the experience I've got. I'll make it as easy as, as it can be. And so, yeah, I think that that's the key thing that I've kind of led from, I guess, in my leadership side of things is it's not you come into an organization and take them on an agile journey, take them on a DevOps journey. You're going on that journey with them.
Brian (30:32)
I love that. Yeah, that's a great point. That's such a great leadership point. Well, Claire, I can't thank you enough. This has been so eye opening and there's so much great information here. And easily could go on for another hour talking about this stuff. But thank you for taking your time and sharing your wisdom with us and with the group here at Agile Mentors.
Claire Clark (30:55)
Thank you. Thank you so much for having me on the podcast. Yeah, I've really enjoyed it.

#108: Adaptive Organizations with Ken Rickard

Join Brian and Ken Rickard as they delve into why agile transformations get stuck and uncover strategies for creating adaptive, resilient organizations and people.
Overview
In this episode, Brian sits down with coach, author, and Lean Change agent, Ken Rickard to explore the common pitfalls of agile transformations and the commodification of agile practices.
Ken emphasizes the need to focus on people rather than processes and introduces the art of change, which includes self-awareness and adaptability. And shares the six big ideas of adaptive organizations, such as sense-making strategies and leadership agility.
Tune in to learn how to navigate transformation challenges and create an environment that fosters resilience and adaptability.
References and resources mentioned in the show:
Ken Rickard
Insight
The Six Big Ideas of Adaptive Organizations: From Frameworks to Sensemaking by Ken Rickard and Jason Little
Agile Manifesto For Software Development
Lean Change
Mountain Goat Software’s Agile for Leaders Training
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Ken Rickard is a spark for transformative good — a change alchemist, deep thinker, and a catalyst for personal growth and organizational evolution. With over 15 years in the agile community, he's honed the art of navigating change and embracing adaptation as the true essence of agility.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a really special guest with us. I have Mr. Ken Ricard with us. Welcome in, Ken.
Ken Rickard (00:12)
Thank you. Nice to be here.
Brian (00:14)
Glad to have Ken here with us. Ken recently spoke at the the global Scrum Gathering, in New Orleans that I was at as well and had a really interesting, actually had a workshop slot there for a workshop titled Humans Agile and Change, How to Get Your Transformation Unstuck. And wanted to have Ken on to kind of talk through that a little bit. But before we do, for those people who aren't familiar with Ken, let me give you a little bit of an introduction here. Ken is an enterprise coach and change alchemist. I love that. At a company called Insight, he co -authored a book called The Six Big Ideas of Adaptive Organizations, which I know we're going to get into here in this conversation. He's a licensed facilitator of Lean Change. He's an IC Agile authorized instructor. So he's got just a load of credentials and a load of experience to bring to the table here with this. So Ken, let's get into this. Let's talk about humans agile and change and how to get transformations unstuck. What do you think is the main cause of transformations getting stuck?
Ken Rickard (01:31)
Yeah. So I think, you know, we're all feeling the effects of the high of agile. And I think now we're, we're starting to come down a little bit in the industry. I think everyone's feeling that effect. I mean, I see so many agile coaches on LinkedIn that are still looking for roles and whatnot, scrum masters, you know, a good bit of that, though, I think it's a blowback from the industry and just companies in general who, when they need to tighten the belt, they're actually beginning to look at the roles they've got and figure out which ones that they can do without for now. Or maybe they can do with roles they've already got. And so the effect of that, I think is coming from this idea that, you know, the agile industry, let's even narrow that a little bit more and talk about scrum specifically, has really kind of in the industry has become commodified around this idea that it's a process. And that we just like, we used to do this thing over here and we can just go to the shelf and purchase like scrum in a way. And then like. take that and just drop it into the spot and the practices we used to do. And so when it was only viewed as a process replacement for what they're doing now, it's very easy when, things get rough or tough in the industry as they've been over the past year, year and a half, two years, that our natural, you know, kind of inclination is to kind of hunker down and that hunkering down is to go back to what's comfortable to us, which is typically non -agile, non edge. things because that edge is actually kind of uncomfortable. And so we want to kind of go back and go back into our hole and actually like do the things that we're most comfortable with as an organization or as leaders. And so, yeah, I think that's been kind of what's been happening. And it's just, you know, the follow up from that, I think it's just now hitting the industry, I think in the current times now.
Brian (03:10)
Yeah. Yeah, I agree. I mean, you talk about it being a commodity and I can definitely see that across the different organizations that do certifications with this, and we're both trainers, we both do trainings. The hard part for me as a trainer is that I don't wanna... discourage people from getting training because I think the training is an important step, right? I think it's you know, you got to know the basics before you can play a sport and You know, if this is the team sport, but it's it's so much easier for me to tell someone all right Well, there's these roles these events and these artifacts
Ken Rickard (03:49)
Mm -hmm.
Brian (04:05)
and they can just go, you know, start putting it into their schedule. Here's the events we're going to do, and we have these meetings at this time. It's easy to do that, but it's hard to say, all right, what is openness? And how do we operate in an open environment, you know, or how do we treat each other with respect as we go through this kind of thing? That's hard to train, you know?
Ken Rickard (04:10)
Right. Right. Yeah. Yeah. Yeah. And coming from the, you know, I've spent a three and a half, almost four years now, I think with lean change and Jason little, and, and obviously we co -wrote co -wrote the, the book together, but the, I think the thing that I've learned from all that is, I mean, I want to say that at the beginning, the intention of the folks that created the agile manifesto for software development, their intention was really to help the industry change, but from a software development and probably an adjacent request would have been that the project management kind of behavioral patterns that were there and existing already. They could have actually kind of caused that trajectory to start to shift. And they obviously did over time. I think the one thing, if I had a time machine and I could go back and I could just plant a little seed with those 17 folks, it would be to not look so narrowly at the organization, like just the software development part. Because I think that's what's caused agile and scrum to become that thing that those IT developers do. And it's actually in a way done a disservice, I believe, to the industry at large and then just kind of the trajectory over time and where we kind of landed over these past few years. And it's why with lean change, what I'm trying to do, and I'm not the only one trying to do this. There's a number of folks out there trying to do this as well. But I think Jason and I, what we're trying to do and all the lean change facilitators is to get people to realize. that at the end of the day, everything is really about change. So scrum is just a process. It has all these, like behavioral patterns that come along with it. You're going to need to change, but those things aren't laid out necessarily exactly explicitly in the scrum guide. So you can read through that with your current understanding and your current lens of the world. And you can go, okay, I got this. And okay, all I need to do is go and create a scrum master position and I need a product owner and we need to do these events and then we need to set up these artifacts. And, and that can very easily lead to that kind of mechanical approach to scrum because that's kind of the world they've come from, right? If they've come from kind of project management world where everything is very laid out, very kind of straightforward and linear and then sequentially executed. And I think what we would all probably agree is that what's really missing is that mentality shift and. and the perspective shift. And to get there, we got to really focus on people change. Like, and I don't mean just like, Hey, we're doing a new process. So what do I need to do differently? Or, Hey, we put, we installed this new piece of governance software. So what buttons do I need to push differently? I'm talking about like actual evolution of the individual, their beliefs, their behavioral patterns, and the rituals that match up to those behaviors and beliefs that set underneath them as a person.
Brian (06:52)
Yeah. Yeah.
Ken Rickard (07:14)
And so that's what we're really trying to focus on from Lean Change is we're really trying to help people understand that, that to do those things well, to do things like Scrum well, you really have to focus not just on the process change or the technology change, but actually on the people change. You may even have to focus on structures and strategies as well.
Brian (07:31)
So I'm trying to channel my inner listener and try to think of what they might be asking or thinking about in hearing this. And I mean, what I think about is, all right, well, let's say I'm an organization and I buy an end to all this stuff. And I'm like, yeah, yeah, yeah, we've tried that. We've tried to implement this stuff and it's all about process and we'd rather not do that. We want to do it the right way. Where do you start? How do you start to...
Ken Rickard (07:38)
Yeah. That's it. Yeah.
Brian (08:00)
you come in and just say, hey everybody, we're gonna change how you think and how you, how do you start to get the organization to shift like that?
Ken Rickard (08:06)
Yeah, that's tough. Yeah. Yeah. And I would actually, I would point the finger right back at ourselves first. I mean, this is the journey I've been on for the past five years. You know, I mean, I, I actually talked about this in the session at the global scrum, scrum gathering. I told the crowd there. I was like, like five years ago, Ken, like if anybody challenged anything or didn't understand how scrum worked, I would essentially kind of like,
Brian (08:14)
Ha ha ha.
Ken Rickard (08:34)
just picture this idea of Ken taking them by the arm and leading them over to the Scrum Guide and being like, look, here's what the Scrum Guide says. And that was kind of my go -to thing in a way, variations on that, obviously. But at that time, it was mentality -wise, I was just like, okay, well, we just need to do Scrum. If we just do it well and we do it like it says we're supposed to do it, then it'll fix all the things. And that didn't really get the best response out of it. everyone. You know, it wasn't until I started to shift myself and my own perspective and start to really understand that, okay, I'm not the snake oil salesperson that they probably think I am. I'm actually somebody who's trying to help them change. And so if I look at it from that perspective, now it becomes less about the process or the framework and all the specifics of the framework. And it becomes more about, okay, where are they now?
Brian (09:18)
Yeah.
Ken Rickard (09:29)
What mentality do they have now? What are the attitudes that they have about the things that I would hope to put in front of them? Like, are they, are they like, yeah, this is great. Let's do it. Or are they like, no, I don't know. Not so sure. Or are they like, no, that's a stupidest thing I've ever heard of. Like we would never do that here. so better understanding them as an individual and then being able to better show up in a way that is going to be conducive for them to see the need to change is actually the very first.
Brian (09:42)
Yeah.
Ken Rickard (09:55)
best thing that I ever did in the way that I shifted my own perspective and how I showed up. And then that started to actually unlock them and their ability to actually pay attention and realize how they needed to change. And then therefore the change started to go. It's a much slower route because you can just go take stuff off the shelf and be like, Hey, we need to do it like this. And you probably will get some traction with some folks, but you're probably going to miss a good bit of them too. So.
Brian (10:20)
Well, let me, let me ask you this because this is something I've kind of been wrestling with with some other guests on the podcast as well. It's just this, this concept that, you know, partly, I think what's behind some of the problems with this is, is also the short kind of nature of, of how we view change in organizations. And, you know, we want quick results. We, you know, we have a change initiative to do something and we want to see that, that, that benefit of that change in the next three months.
Ken Rickard (10:42)
Sure.
Brian (10:49)
And all of a sudden things are going to be completely turned around and we're going to do things differently. But that's driven a lot from this short -sighted nature of, you know, we got to increase our profits quarter by quarter. We got to, you know, please our shareholders and they don't have the long vision that we used to have in companies of, you know, 10 years or something.
Ken Rickard (10:54)
Yeah. Yeah. Yeah, I'm going to, I'm going to say something and I'm going to meet it in a completely different way. Planning. Let me explain what I mean by this. all right. And I don't want to make this into the lean change show either, but I'm going to talk about a concept, from lean change real quick. so bear with me, but, so there's this idea that has been created in lean change. It's called, we, we, we refer to it as a big next now. Really what it is is it's like.
Brian (11:17)
Okay? Hahaha.
Ken Rickard (11:42)
Think of like an overarching rainbow at the top of like, Hey, what's the largest, biggest thing we're trying to accomplish? And what's the strategy around that? And if we can define a high level strategy around that, it will help us be, get like an orientation towards what outcomes are trying to seek it at the grandiose level. Let's say it's an agile transformation. All right. Underneath there are like a series of smaller humps that are like, okay, what are the goals we might want to actually achieve? Let's make sure those are really loose. except for the ones that are in the very beginning. Does this sound familiar? I'm basically describing breaking down and iterating incrementally changing the organization, right? So, underneath that you'd have like what's referred to as like the lean change cycle. This idea that we go out and actually look at the organization and get data back on what might need to change instead of actually telling people what needs to change. Like, Hey, we're becoming a scrum team, or this is what scrum is, and this is how it works.
Brian (12:21)
Yeah, yeah.
Ken Rickard (12:41)
well, what if they just start where they are and maybe the first thing I add is like a daily, you know, maybe they don't have any kind of coordination events at all right now. And then their tolerance level to change is just minimal. So, okay. So as a coach or as a less even a scrum master, the first thing I might help them do is to actually just put in some frequency of a regular sink. That could wind up turning into something that we would recognize as a daily scrum or a daily standup, but. In the beginning, maybe they don't have the tolerance to go right directly to the thing. Maybe they'll reject that or resist that. So as, as a coach or as a scrum master who's focused on change and not the process of the framework, I would go in and actually help them figure out what the best changes for them right now. And that's the approach I've been using and it just works. It works pretty well. versus coming in and being like, Hey, here's what scrum is. Here's how it works. Let's go through this training. You know, we got to get all these things set up. We need, here's what perfect looks like.
Brian (13:14)
Yeah.
Ken Rickard (13:39)
guess what we can't get there. So yeah.
Brian (13:43)
Yeah, I mean, as I'm listening to you, I'm thinking, you know, it's a difference of listening versus telling, you know, like there's a, there's kind of a telling mindset of going in for a lot of coaching of, you know, what we would typically frame more as a consulting approach. You know, I have answers. Here's the answers for you. Just do the way that I've always done it and everything will be fine versus let's actually hear what your situation is. And.
Ken Rickard (13:59)
Yeah.
Brian (14:10)
what your needs are and what you're seeing going wrong and how can we address those issues? I love that. Yeah, yeah, exactly.
Ken Rickard (14:14)
Yeah, and experimenting through it and honestly showing up, showing up as, or knowing when to show up in a coaching stance, who is going to be more empathetic and more understanding and not going to give them all the answers and it's going to let them explore and figure it out. And it's going to shine the light in the dark corners of the room versus the consultant stance, which is going to show up in more of an advisory. Hey, If I see you all struggling, I'm going to kind of tell you what to do or show you what to do. And they may not be ready for that. So it's about knowing when to actually do one stance or the other and be able to be very fluid in those things.
Brian (14:47)
Yeah. Yeah, there's a, there's a phrase I'll use often in class when I talk about the coaching kind of mindset to say, you know, what we're trying to do is not build knowledge, but build capability. And if you build the capability, then people can then adapt and change when, when something similar comes along or something in the same realm, they can say, yeah, I remember last time when we had something like this, here's how I responded. So that, that ability, I think to. deal with change like you're saying. And if we have it ingrained in our mindset that, hey, we identify problems, we inspect them and we adapt as we go along, to me, that's so much more important to build into how we do things than it is to know, we got these four meetings or five meetings that we're gonna make sure we hold at a certain time. Awesome. Well, you know, I'd like to hear a little bit because I know, you know, your talk is somewhat loosely based on your book as well. And, you know, with a title like the six big ideas, help us understand. We may not have time for all six, but give us some of these big ideas.
Ken Rickard (16:00)
Yeah. Yeah. Sure. Yeah. Yeah. I'm also still, I think Jason and I are still trying to figure out if, how the word or the phrase big ideas is resonating with folks too, because in the agile community, you know, big, big is not a word that I think people will gravitate to very quickly, but, we're also trying to straddle the fence on the change community and the agile community. Honestly, what we're trying to do is I was joking around and I think we, I'm.
Brian (16:21)
Yeah. Yeah.
Ken Rickard (16:31)
might've wrote this either in the book that's out now or the bigger book that we're working on for later this fall. But I wrote somewhere that really the change community and the agile community should really go on a blind date because they never should have really been two separate communities in my opinion. And I think Jason would hold the same opinions and a lot of our lean change facilitators, I think would hold the same opinions. So yeah, so the book is really about trying to get Agilist to understand that their role is really about change.
Brian (16:47)
Yeah.
Ken Rickard (17:02)
They already know the agile bits and the iterative incremental and all that kind of stuff. And that the change community really needs to better understand the agility community and take some of those practices and apply it to the change. And if both sides do those things, we're going to wind up in the middle and everybody's going to be the same type of person or the same type of thing. Because at the end of the day, getting to agility, like this idea of the characteristics of being nimble and being able to adapt to what's going on with a certain grace and resilience.
Brian (17:25)
Yeah.
Ken Rickard (17:31)
that set of characteristics is really, I think what the agile industry is hoping to go for. And yet a lot of the folks that find these things come to it with their current understanding and they don't really, aren't really looking to change themselves and how they see things, their perspective. And so that's how we get into this commodified kind of off the shelf version of it. And so I think we're just trying to get people to realize that. Look, if you look at these big, these six big ideas, which are really just sense making strategies. At the end of the day, that's what they are. You should be able to sense your way through what your context, your organization, given the changes that are going on. you know, what are those circumstances? How well do you know those circumstances? If you can understand those things in a sense making way, you'll be able to show up in a way that it actually be conducive to help that organization change, no matter what the scope of the changes. Let's say you're a store master. It could be your scope of your change is essentially your team or teams.
Brian (18:25)
Yeah.
Ken Rickard (18:29)
And the product that they're building, let's say you're an agile coach. Okay. Maybe it's somewhat wider than that. I don't know. I'm still on the fence about what the difference between agile coaching and scrum master is. That's another podcast though. I think, or let's say you're somewhere higher up in the organization. So whatever your purview is, whatever your scope is, that context is really what we're trying to do. We're trying to help you and the others around you understand what it is that you're not paying attention to, what it is that you don't understand.
Brian (18:39)
Yeah.
Ken Rickard (18:58)
or that you might think you understand about your organization. So it's really six ideas to help people kind of unravel that about their organization and themselves. Because like, for instance, one of the six big ideas is something that Jason had created quite a long time ago called the four dimensions of change. And what it says is that there's four things that you really probably need to focus on as, as a agent of change. And that is yourself. So like,
Brian (19:07)
Yeah.
Ken Rickard (19:26)
Your set of beliefs about things, you know, how you show up because how you show up actually affects how others receive or perceive you. And then that impacts your ability to influence others and actually help them change. And then it goes on to say there's, the big ideas or strategies that you can deploy from, from a change perspective, typically minimally viable practices, or strategies. And then the last bucket in that four dimensions is, tools and practices. You know, the things that we have the most affinity for and tend to go to first, and kind of ignore the other three things. So it's, so that particular big idea is trying to get people to recognize that, no, there's like a bigger kind of art and science here to helping people change. It's not just about the science, like the strategy and the tools and practices to be good at those things. Most likely you got to focus on the art of change, which is yourself and your stance or how you show up.
Brian (19:59)
Right. Right. Yeah, I'm gonna share one of my geeky subdivisions here in making this quote, but it reminds me of in the musical Hamilton, there's a line in there that George Washington says to Hamilton where he's talking about, you know, Hamilton has these visions of going off and dying like a martyr and George Washington says, dying is easy young man, living is harder. And.
Ken Rickard (20:30)
Yeah. Yeah.
Brian (20:51)
That's kind of how I see this. I'm not saying we're dying or making a choice between dying or not, but I am saying that the practices side of thing, practice is easy young man, culture is harder. It's just harder to try to implement those things. And I think a lot of times, I don't know if it's, I think individually sometimes as coaches we can get lazy.
Ken Rickard (20:55)
Yeah.
Brian (21:18)
and go to the things that's easier to tell people about. But I also think that it's an institutional thing because it's much easier for me to certify somebody or give them a credential saying that, hey, this person knows their stuff when I can test them on facts and figures and how long is that meeting and that sort of stuff versus.
Ken Rickard (21:20)
Mm -hmm. somebody. Yeah. Please.
Brian (21:41)
you know, how do you change the mindset of the culture of the organization when they're really into quick solutions and they're into trying to get things out the door as fast as possible and not focus on quality. It's harder, right? It's just, it's more difficult.
Ken Rickard (21:55)
Yeah. Yeah. Yeah. Yeah. Yeah. You're hitting on one of the other six big ideas right now. Actually two of them, but we can start out with the explain the one. So there's another one that we made called the, the two change strategies of effective organizations. And so what this one says is that there's two ways that you can probably improve or change your organization. And that's a fractal statement in an organization because again, we're only talking about whatever context you have.
Brian (22:06)
Hahaha.
Ken Rickard (22:27)
Cause if you're a SCAR master, we're talking about the context you have of the teams you're working with. Agile coach or something higher up than that, whatever context you have. So, okay. So within your context, you probably have two ways to think about and try to help your organization change. And those two ways are either optimizing what they already do to make it better, faster, cheaper, or evolving the way they think about what they do so that they can actually succeed in ways that they never have before. And I'd be, I'll go out on a limb and say that every, at the very least, every single company I've come across that's doing agile and whatever way they call it, is really trying to do it from the purpose of the optimization, better, faster, cheaper. I think there are very few companies around the world that are actually taking it seriously enough to do the evolution part to actually change the way they think about how they do things in such ways that they're actually elevating. their set of beliefs and behavioral patterns, not just as individuals, sorry, as individuals, but as a collective and then ultimately as an organization. And so it's really trying to get you to, to focus on what is it that we actually are trying to improve? Is it just that we're trying to optimize what we're doing now? Cause that's a take scram off the shelf and just drop it in, you know, or that's send people to training and like come back and be like, cool, you're certified.
Brian (23:33)
Chief.
Ken Rickard (23:49)
But if we don't ask the hard questions around, okay, well, what are you gonna change about your behaviors? Then they're likely not focusing on evolution. And if we're not coaching them through that, yeah, not really going anywhere.
Brian (24:01)
Yeah, do you think organizations just don't know what they don't know? I mean, because I know you're right, they do want better, faster, cheaper. And that's sort of the end goal that they're coming at a lot of this stuff with. They just not recognize that it's really the change capability that they should prioritize.
Ken Rickard (24:05)
It's like. Well, I think it's because they focus. So what's really easy for a lot of organizations to change. There's a, we're going to keep tying these five, sorry, these six big ideas together, I guess, because there's another one called the five levers of change. And what that one is, is a, it's a circle of five things with people being the biggest circle in the center. And then on the four corners of it, it's basically process and technology strategies and structures.
Brian (24:32)
No, that's great.
Ken Rickard (24:48)
And so if we look at that as a systems approach to changing an organization, the reason why it's called the five levers is because they can pull any levers in any combination they want in order to try to change their organization. But the easiest levers to pull are process and technology. So, Hey, let's do scrum and we need to install Jira or Azure DevOps. Right. And that's generally where these kinds of things start because it's within the control of the teams oftentimes to make those changes. It doesn't impact a larger organization to, well, it can, but probably to a lesser extent initially. So the teams have some level of autonomy or local control to start making those changes. They don't run into problems or impediments or just kind of organizational dysfunction until a little bit down the road so they can kick that can down the road. And so I think it's, I think it's that that causes us to gravitate towards a process and then just pull that lever pretty easily. And, and that's an optimization lever. So if you tie those two ideas together, it takes the other side of those five levers, the structure and the strategies, which are all built on beliefs. You know, like if I'm a leader in a hierarchy who's worked 20 years to get to my lofty management position, I'm going to be a lot less likely to take a empathetic kind of delegated approach to my management style because I put in a lot of hard work to get to where I am now. And there's no way you're going to tell me now.
Brian (25:48)
Yeah.
Ken Rickard (26:18)
20 years that I now have to change the way I operate? Like, no, I'm in control here. So I think we're also battling that a little bit too.
Brian (26:20)
Right. Yeah, what I've done got me here. So why would I do something different now? Right?
Ken Rickard (26:32)
Right. Exactly.
Brian (26:34)
Yeah, I've battled that in multiple occasions, for sure. One of the places I worked was a newspaper. And if you want to talk about people not wanting to change their mindsets of, hey, what do you mean that people don't want to have delivery of their newspaper on their front doorstep every day like they've done their whole life? Yeah, it's crazy. Well, this is great stuff. I'm really enjoying this.
Ken Rickard (26:49)
Yeah. Yeah.
Brian (27:03)
Do you have one last big thought, big idea to leave us with here? Because we're almost out of time, but what have we missed in these big ideas?
Ken Rickard (27:13)
Yeah, probably the other big one that comes up a lot. one of the other six that I haven't talked about yet is the, what I call the three agilities. And we'll tend to focus on the delivery agility, which is like, Hey, we, we can help you team better and people better at the team level where you're delivering. And we can help you become more product led. And we can also help you with your technical excellence, you know, like DevOps types things, right?
Brian (27:21)
Okay?
Ken Rickard (27:38)
And I think we could probably draw a circle around those three things and go, you know what, for the vast majority of the agile industry, this is what they think agile is. But in my opinion, that's only one of the agilities an organization needs in order to actually possess the characteristics of agility. And the other two would be change agility. The idea that we are adaptable to the change that we cannot control and that we actually can adapt well in a resilient way to the change we can control within our organization. And that we're constantly evolving to get better at that so that we can sustain change in a graceful way over time. So that's change agility. And then the third one is probably possibly the most important one. And that is leadership agility. This idea that if we don't create the environment for change to take place in a conducive way that is productive and adaptable. then we won't change and we'll stay stagnant and we'll stick to our standardized approaches in a stagnant way. And then delivery will suffer even though we can put new things on top of it and we can call things new words, it won't actually change. And the leadership agility is really about not just trying to teach leaders to be more competent. That's generally what management consulting and a lot of other folks are focused on. It's really about trying to help leaders address their ability. to actually have a consciousness about themselves, that they can show up in ways that are actually enabling and empowering the organization to be adaptable and flexible and to be able to deliver and change in ways that are graceful and resilient. And so in my opinion, it kind of starts there even though a lot of them don't start.
Brian (29:14)
I love that. No, I love that. I think that's great because, you know, a lot of times you hear the complaints of people who come through classes that are kind of more team level in the organization. And it's, there's a lot of complaints about how management just doesn't understand, or we're bumping up against the glass ceiling, you know, kind of in our organization, we can't really Institute change or make the change permanent because, you know, leadership still wants things exactly in the old way. They haven't actually shifted. how they think about things. So I love that, I love that concept. I would agree there. Well, this is great stuff. And obviously, like I said, the workshop that Ken did at the Scrum Gathering was an hour and a half. And this is just a short little taste in half an hour. So there's no way we're gonna be able to cover it all here. I strongly encourage people, if they're really interested in this topic, if they're really interested in what Ken is saying,
Ken Rickard (29:53)
Thank you. Yeah.
Brian (30:15)
Check out the book the six big ideas of adaptive organizations. It's a great book And it'll go into detail on all of these these six big ideas that we talked about here And what we're gonna put lots of the links in our show notes here so if you want to just head on over our show notes you'll find links over not only that but to to Ken's organization the six big ideas network and you can find the website there and find the the
Ken Rickard (30:24)
Mm -hmm.
Brian (30:44)
classes and trainings that Ken is doing in this area. So we'll make sure that everybody can get to that. Ken, I can't thank you enough. Thanks for coming on and sharing your knowledge with us today. Yeah.
Ken Rickard (30:54)
Yeah, thanks for having me. It was fun.

#107: Transforming Organizational Mindsets with Bernie Maloney

Join Brian and Bernie Maloney as they explore the transformative power of mental models, emphasizing the shift from a mechanistic to an organic mindset in Agile organizations.
Overview
In this episode, Brian and Bernie Maloney discuss the profound impact of mental models on organizational culture. Bernie delves into how our beliefs and assumptions shape our thinking and behavior, particularly within Agile environments.
He discusses the importance of transitioning from a mechanistic to an organic mindset, focusing on problem-solving rather than merely delivering solutions. The conversation also highlights the role of psychological safety in fostering a culture of experimentation and learning.
Bernie shares valuable resources, including Amy Edmondson's 'The Right Kind of Wrong,' to further explore these concepts. Tune in for insightful strategies for enhancing your organization's agility and effectiveness.
Listen Now to Discover:
[1:03] - Brian welcomes Certified Scrum Trainer® and Principal at Power By Teams, Bernie Maloney, to the show.
[2:15] - Bernie delves into the concept of mental models, sharing the origins of his philosophy of "making new mistakes" developed during his time at Hewlett Packard.
[5:55] - Bernie illustrates the power of mental models and belief by sharing a compelling example that brings these concepts to life.
[13:46] - Join us for a Certified Scrum Product Owner® Training, where a year of coaching and development with Mike Cohn, Brian, and the Agile Mentors Community of Agile leaders is included with your training.
[14:39] - Bernie discusses how applying mental models can enhance the effectiveness of Agile transformations, creating a naturally adaptive and innovative climate.
[18:12] - Bernie offers language as a powerful tool to support the shift to a new Mental Model.
[23:30] - Bernie demonstrates the use of mental models for product owners through the Mobius Loop, providing actionable guidance and examples
[26:27] - Brian shares a big thank you to Bernie for joining him on the show.
[26:59] - If you enjoyed this episode, share it with a friend, and like and subscribe to the Agile Mentors Podcast so you never miss a new episode.
[27:27] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership to that site by taking any class with Mountain Goat Software, such as CSM, CSPO, or Mike Cohn’s Better User Stories Course. We'd love to see you in one of Mountain Goat Software's classes. You can find the schedule here.
References and resources mentioned in the show:
Bernie Maloney
Power By Teams
Mobius Loop
The Right Kind of Wrong: The Science of Failing Well by Amy Edmondson
Agile Teams Learn From Spikes: Time Boxed Research Activities by Mike Cohn
Certified Scrum Product Owner® Training
Certified ScrumMaster® Training and Scrum Certification
Mike Cohn’s Better User Stories Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Bernie Maloney is an Agile leadership coach and international speaker, leverages his 25 years of engineering and leadership experience to help teams and organizations unlock their full potential. Known for his engaging workshops and impactful coaching, Bernie believes in making performance breakthroughs both achievable and enjoyable.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors Podcast. I am with you as always, Brian Milner. And today I have a very special guest with me. I have Mr. Bernie Maloney with me. Welcome in, Bernie. I am.
Bernie Maloney (00:14)
Thanks, Brian. Happy to be here.
Brian (00:16)
Great. I'm so excited to have Bernie here. Bernie and I have touched base for years over conferences. We've run into each other and had chats and shared our shared passion for Hawaii and other things. But Bernie was speaking at the recent conference and we've gotten into some conversations. I wanted him to come on because I wanted him to, first of all, if you're not familiar with Bernie, sorry, I see, I just want to jump right into it. If you're not familiar with Bernie, Bernie is a CST. He works at a company called Powered by Teams. He teaches classes, Scrum Master product owner classes and leadership classes and other things as well. But he is a principal at Powered by Teams. So just wanted to give you the basics there before we dive into anything. But the topic that we started to talk about that just as a jumping off place for us is a topic. the topic of mental models. So Bernie, why don't you explain to everyone how you define that, mental models.
Bernie Maloney (01:23)
So, Brian, this is a great topic. I find myself talking about it all the time. And y 'all, I warned Brian, like, he can press play on this, and it might be 15 minutes before he gets a word in edgewise here. It touches on mindset. It touches on a lot of topics. My talk that Brian was referencing at the recent Scrum gathering in New Orleans was make new mistakes, leadership lessons from an Agile success. which goes back to where I really kind of cut my teeth in Agile at Hewlett Packard. See, I'm a mechanical engineer by training. And I cut my teeth in Agile in the consumer PC division at HP about, this is scary to say y 'all, okay, about 27 years ago starting at this point. And some of the fun stuff, it was a bang up enterprise. It was the fastest business in HP's history to hit a billion dollars. And it was just...
Brian (02:05)
Yeah.
Bernie Maloney (02:18)
a great proving ground. We had hardware, we had software, we had distributed teams where volume manufacturing was in Asia, engineering was here where I am in Silicon Valley. Go -to -market for Europe was in Grenoble, France. We had high volume. Some of our products had 100 ,000 units in a single model run, with like 200 models in Europe on a quarterly basis at times. So high volume, high mix, tight margins from a business perspective. A lot of technology products want to have 20 % to 30 % gross margins. That's before you start taking off deductions like expenses and salaries and things like that. On a good day, we had 8 % gross margins for Christmas products, maybe 2 % gross margins. We used to refer to it as we were shipping rotting bananas. And like I said, I was there. When I started, we were shipping six products a quarter. We grew to 20. By the time I left after eight years, we were doing 200 products a quarter in Europe alone.
Brian (03:04)
Ha ha.
Bernie Maloney (03:16)
hardware, software, distributed teams, high volume, high mix. And we did all that with weekly iterations of a plan. At one point in my career, I was tactically responsible for the delivery of 2 % of HP's top line revenue with zero direct reports. And part of the secret sauce of success in that organization was really that mental model of make new mistakes. So that's where the talk title comes from. And in fact, makenewmistakes .com will point to poweredbyteams .com because I own that domain too. But that mental model really helped the organization thrive and not just survive. We went from like a number one to a number five share. Sorry, from a number five to a number one the other way around. Because the founding executives recognized that in that tide of a market, mistakes were probably going to happen. And so what they did is they established the psychological safety. Wow, look, there's another great topic. Make new mistakes. You knew that if it was an honest mistake, it would be forgiven. Just don't make it again. Get the lesson is one of the things that they said. I can even tell you the story about the weekend I blew a million dollars of HP's money and I was forgiven, but you'll have to come to a conference talk for that. So that was just like a great experience. And...
Brian (04:32)
Wow.
Bernie Maloney (04:39)
After that experience, I went on to TVs. Another part of my background is I shipped the very first internet connected TVs. Look it up, the Media Smart 3760 from HP. It shipped even before Apple TV. It bombed. Okay, it was way ahead of its time. But I recognized that that had been such a joyride. And then I recognized some other stuff that really gets into the psychological, the mental aspects of leadership, high performing teams. And I could, Brian, I could talk about that too, but okay. But that kind of got me to recognize that with those skills, the success that I had experienced at HP could probably be replicated. That's kind of been the path that I've been on for the past 15 years is really helping organizations go along that path. So mental models can be really big. Let me give everybody here an example. And so Brian, I'm going to speak to you as a way of illustrating mental models. So imagine you are physically where you are right now.
Brian (05:24)
Yeah.
Bernie Maloney (05:37)
but it is 150 years ago, okay? Imagine you're physically where you are right now, but it's 150 years ago. Now, Brian, let me ask you, can man fly?
Brian (05:47)
boy, you're testing my history knowledge.
Bernie Maloney (05:52)
Okay, make it 200 years ago, okay? That makes it easier. Okay, cool. Great, now fast forward to the present. Brian, let me ask you, can man fly?
Brian (05:54)
No, yeah, no. Yes.
Bernie Maloney (06:02)
What changed? Nothing about the laws of physical reality. It was just your mental model of what for man to fly means. That's the power of belief, okay? And belief limits a whole bunch of stuff in the way that people behave. So you'll hear Agilent talk all the time about, this is all about changing mindset. I'm probably, Brian, gonna give your listeners some ways of.
Brian (06:06)
invention.
Bernie Maloney (06:30)
changing mindset as we go through this, but that's going to illustrate the power of mental models. Now, a big one that I like to use that's specific to Agile comes from Gabby Benefield. She's an Agilist out of the UK, and it's called the Mobius Loop. And I think she's got the domain mobiusloop .com. So everybody can imagine a Mobius Loop. Okay. And what I really like about this model for her...
Brian (06:32)
Sure, yeah, please. Yeah.
Bernie Maloney (06:56) i
s the right -hand half is what a lot of organizations think Agile is. Build, measure, learn, build, measure, learn. The whole idea of the build trap that we talk about in Agile. It's all about the delivery of a solution. Okay? But the left -hand half is all about the discovery of the problem. Okay? And the discovery of the customer. And that's a part of Agile too that most organizations overlook. So you got to ask why. And it comes down to kind of mental models. So when I was at Persistent, if you go look me up on LinkedIn, you'll find some of my employment history. I was at Persistent for a while. They had a really good mental model. And it's something I still use when I go into a client. And they would talk about there's kind of three eras of a company culture. And so culture is really the environment that an organization lives within. And there's an era. where cultures were formed before the internet. So things like finance and government and mining and manufacturing and oil and gas field developed. I mean, I've had clients in all of these areas. And in that sort of an environment, okay, it was, well, an era. One of the things I'll ask, and Brian, I'll kind of like let you represent the audience. Would you say in general, the people that you work with, the markets that they serve, Are they moving faster and all up into a thumbs up, slower, thumbs down, or about the same, thumbs sideways? Are the markets moving faster, slower, or about the same as they were, say, five or 10 years ago?
Brian (08:32)
I think everything's moving faster, yeah.
Bernie Maloney (08:34)
Cool. Okay. Now, how about the technology that your clients use to solve problems for that market? You know, moving faster, thumbs up, slower, thumbs down, or about the same as it was, say, five or 10 years ago. Faster. Yeah, cool. Okay. Now, when things are moving faster, thumbs up for yes, thumbs down for no. Do they always move in a straight line?
Brian (08:46)
No, faster. No, not always.
Bernie Maloney (08:56)
Okay, cool. So now things are moving faster, but they're not moving in a straight line. So let me ask you, do most organizations try and plan and predict? Is it possible for you to plan and predict when things are moving faster and they're not moving in a straight line? Is it easier or harder to plan and predict?
Brian (09:19)
I think it's definitely harder.
Bernie Maloney (09:21)
Yeah, but organizations are trying to do that, aren't they? And it's because their mental model is as a machine. So organizations born before the internet have a mental model of the entire organizational system being a machine, the industrial age, which you can plan and predict. They treat people like cogs in a machine. In fact, the thing that us Agilists will say is, when you say resources, did you mean people? See, that's...
Brian (09:35)
Yeah.
Bernie Maloney (09:50)
That's kind of now we're starting to get into some of the culture aspects of this because language actually forms culture. And so you'll hear Angela say, did you mean people? Like when that whole word of resources comes up. But organizations born before the internet, they've got one culture. Okay, they were born in an era of plan and predict. They've got a mental model of the system being a machine. And your listeners would probably agree most of them struggle with Agile. Okay, now there's another era born in the internet but not the cloud. So some examples like here in Silicon Valley, Cisco, PayPal, okay, lots of us have had exposure to them and lots of us recognize they still struggle with agile because agile wasn't really fully formed and articulated. Then there are organizations that were born in the cloud and so places like Striper Square and I use payments because I've had... clients in finance across all three of these eras. So Stripe or Square, they were born in the cloud where things were almost natively agile because the Agile Manifesto had been published by that point. They just inherently get agile. So these mental models of your organizational system being a machine get reflected in the language. So things like people or resources, it turns them into objects. It enables something I've heard called pencil management. Wear them down to a nub, go get a new one. In fact, if you do the research on where the word resources was first applied to human beings, it might shock some people. So I don't talk about that openly. They'll have to find me privately. I'll be happy to point you out the reference. And once I do, it's like, ooh. But one of the jokes I'll crack. And this is one of the ways that you can start to shift the language. If people call you resources, because you know that turns you into an object, start calling them overhead.
Brian (11:23)
Yeah. Ha ha ha.
Bernie Maloney (11:48)
Okay, it can kind of make the difference there. Okay, so, but you know, if things are moving faster and they're harder to plan and predict, that mental model needs to shift. In fact, in agile, we talk about you need to move to sense and respond. When things are moving faster, it's kind of like Gretzky, skate to where the puck is going. You need to sense and respond to the situation. So a better mental model instead of a mechanism is an organism. Because think about organisms, like cut yourself, it heals, okay? It senses and responds. Or like a forest fire comes in, wipes things out, and nature always kind of fills things back in. Sense and respond. This gets reflected in the language. So Brian, do your clients talk about metrics?
Brian (12:37)
Of course, yes.
Bernie Maloney (12:38)
Okay, cool. So do they talk about efficiency?
Brian (12:41)
I would say a lot of businesses will talk about that. Yeah, sure.
Bernie Maloney (12:44)
Yeah, cool. That's the language of machines. Probably better language is diagnostics instead of metrics. That invokes some of the curiosity. And probably instead of efficiency is effectiveness. One of the things I'll say is scrum is not efficient. It's not about utilization of capacity. It's about the production of value, which is all about effectiveness. See, efficiency or effective. Do you go to your doctor for an efficient treatment? or ineffective treatment, Brian.
Brian (13:16)
Effective, hopefully.
Bernie Maloney (13:17)
Awesome. Do you go for blood metrics or blood diagnostics?
Brian (13:21)
Yeah, diagnostics for sure.
Bernie Maloney (13:23)
Yeah, so now you're starting to get some hints about how you can start to shift the mental model. What you're really doing with Agile, y 'all, is you're shifting the culture, and culture is hard because it's not visible. The tools, the processes, the practices that folks like Brian and I will teach and coach, they're super visible, they're super valuable, but they're often not enough to start to change things. So, Brian, would you say most of your listeners are familiar? familiar with the language of Tuchman of forming, storming, norming, and performing.
Brian (13:56)
I'd say there's probably a good percentage, yeah.
Bernie Maloney (13:58)
Cool. I actually like to draw a Satir curve. So Bruce Tuckman, Virginia Satir, they were contemporaries. They were both just researching human systems. So Virginia did a performance axis on the vertical and a time axis on the horizontal. And the way Virginia described it is you're kind of going along in a certain status quo. And so you're kind of along that baseline. And then a foreign element enters and some change. And then you descend into chaos. And you can't see it. like your performance goes down until you have a transformative idea and then through some practice and integration, you rise to a new status quo. This happens to people all the time when they introduce changes in their life like New Year's resolutions. I'm going to get fit and healthy this year. You know, it's a beach body time. And you start doing it and it's like, this is so hard. You're in chaos. And what human beings want to do is they want to go back to the way things were instead of moving through. OK, this happens when you introduce agile into your organization. You'll hear Agilist talk about this as the Agile antibodies. You introduce it, this is so hard, and people want to go back to the way things were instead of kind of moving through. So the tools, the processes, the practices, they're really good, but they're not powerful enough. You got to start changing the culture. Culture is like what we all swim in, but climate is something that you can start to affect. So climate is a little bit closer in to your team, and you can start talking about these mental models. Like when I was at TiVo, I was hired into TiVo to bring Agile in because I had shipped TVs, I knew about Agile. And I was hired in on, I think I can say this now because we're more than a decade past. Have you all ever streamed anything? Yeah, okay. So TiVo was working on that in like 2009, 2010. I got to see that stuff and I was like, really wish I had taken off for them. But that program...
Brian (15:42)
yeah.
Bernie Maloney (15:54)
disbanded, okay, and the culture kind of spread in the organization. And I knew that this was a possibility, so when I brought it in, I made sure I didn't just work with my team that was doing a Skunk Works project, where we were just kind of doing some internal development that we weren't, you know, or stealth is probably a better word these days. So a stealth program inside of TiVo that you couldn't talk about. I knew that... when Agile would spread, it would hit some of this resistance, these antibodies. And so I made a case for bringing in people from outside my team so that it was familiar. And when that program disbanded, it organically spread on the cloud side of TiVo because of some of this stuff. So within your own team, you can kind of create a climate. And then when you start to see results like that, that's going to start attracting kind of the rest of the culture that's there. But these mental models, like shifting from mechanism to organism can really help an organization recognize where their limiting beliefs are about how things go. And it's going to be reflected in language. So if you like dive into anthropology a little bit, you're going to recognize that it's really well established. You can change a culture by starting to change the language. And all of us, okay, if you're observing what's going on in Eastern Ukraine here in 2024, that's what's going on. with the Russian occupation, they're changing the language because that's going to change the culture. That's why they're doing stuff like that. So, and even language starts to shape the mental models that you've got. A good example of something like that was when European, you know, when European explorers is the language I'll use, came to the Americas, the natives didn't really have a language for ship. And so they saw these people coming in floating on the water. And that was the way that they could describe it. So even language kind of gets into a cultural sort of a thing. So these are techniques that you can put into your toolkit. Start shifting the language to start shifting the culture, which can kind of help with the mental models. When you got the mental models, that's where the language starts to come from. If you don't have the mental models, you're probably not going to have the language. And I encourage all the folks I work with, start shifting from the whole idea of mechanism to organism. Okay, Brian, was that 15 minutes? Did I go on for as long as I predicted I would?
Brian (18:27)
About 15 minutes. Yeah. No, but I think that's a good point. There's a thing that I'll talk about a lot of times in my classes where I would all say, you know, the waterfall paradigm is one that's based on manufacturing. And there's a false understanding of what we're doing as manufacturing and it's not. It's more research and development. So you have to kind of shift the process to be one that's more conducive. to research and development. So that's very much in line with what you're talking about here. I love that.
Bernie Maloney (19:01)
Yeah. Do you think people would appreciate some book references that can kind of like help you? Okay. So specifically on that whole ethos of experimentalism that you just touched on, Brian, I'm currently going through Amy Edmondson's The Right Kind of Wrong. Really good book. Now, Amy is well known because she helped establish psychological safety as a super important topic in organizations.
Brian (19:07)
absolutely. Absolutely.
Bernie Maloney (19:30)
So she was coupled, I think, with Project Aristotle at Google. And in this book, she unpacked some really interesting stuff. She talks about failure, and there's types of failures. There's basic, there's complex, and there's intelligent failures. OK, intelligent failures, they're just native to science. You know things are going to go wrong. You're going to have Thomas Edison, the I Found 1 ,000 Ways. to do a light bulb wrong, sort of. That's like intelligent failure. Basic failure, she breaks down into, let's see, neglect and inattention. And those are the things that you really want to start to squeeze out of a system. With that mental model of a mechanism, I would say a lot of, call it management, tends to think of a lot of failures as basic failures. And that's where blame starts to come into a system. Okay, so now we're back into psychological safety. Okay, where you want to establish, you know, that was an honest mistake. Hence the talk title of make new mistakes. Okay, so you can have processes and procedures that can kind of squeeze out some of those basic failures. Complex in the middle is really interesting to talk about. As I'm getting into the material, she unpacks... Now, complex failures are those chain of events, you know,
Brian (20:30)
Yeah. Yeah.
Bernie Maloney (20:54)
This thing and this thing and this thing all had to line up and go wrong at the same time for this catastrophic failure to go on. And in medicine, which is where her original research was, they talk about it as Swiss cheese. And she says, if you go into a lot of medical administrators' offices, you're going to find some model of Swiss cheese there. Because they talk about it's like all the holes have to line up for something to go sideways on you. So complex failures. It's a chain of events, a bunch of little things. And she points out that in the research, these often happen when you have an over -constrained system where there's no slack, where you're trying to operate with, get this, Brian, 100 % efficiency. You're trying to load everybody up. So that is just like, it's not just juice on psychological safety, but like, looking at the whole idea of intelligent failures that we want to encourage versus constraining out basic failures versus working to reduce those complex failures and not just thinking complex failures are basic failures, but they're systemic failures that then might be part of the system, might be part of the mental model that's going on that's there. So super juicy stuff.
Brian (22:11)
Yeah, yeah, that's really good stuff. I've always loved Amy's work and I feel, you know, silly calling her Amy. But Amy Edmondson's work has always been great. Yeah, Professor Edmondson. She, the work on psychological safety, I think was just amazing. And the examples she used in her research are amazing. And, you know, all the stuff with Project Aristotle.
Bernie Maloney (22:20)
Okay, Professor Edmondson, yeah.
Brian (22:36)
I love the concept of psychological. I mean, again, not to make this the topic of our podcast, but, you know, I love the idea that they, they, they found that psychological safety was, so foundational that nothing else mattered. That if you didn't have that, that not no matter what else you layered on top of it, it would not fix the problem that you didn't have psychological safety.
Bernie Maloney (22:58)
Yep. And that's one of the reasons why I say Agile is actually a social technology more than anything else. I mean, that's why it's people and people over processes and tools. This is really a social technology that we deal in.
Brian (23:10)
That's a great way to put it. I love that social technology. Awesome. I love that.
Bernie Maloney (23:14)
So kind of talking about Amy and psychological safety and kind of all these systems that we're talking about, another mental model that I like to give particularly my product owners, going back to that Mobius loop. and like on the right hand side is all about delivery, okay, that's where you give team solutions to build. That's what a lot of organizations do. Versus on the left hand side with discovery, it's all about problems to solve. So I like to encourage my clients to instead of just giving people solutions to build, give them problems to solve. Now, for product owners, if you imagine like an onion that's kind of stretched out left to right, so kind of an odd long little onion.
Brian (23:41)
Yeah.
Bernie Maloney (23:58)
and on the far right is your sprint. And then as you go to the left, you're at a release, and further out to the left, you're in roadmap, and way further out into the left, you're into these vague things like vision. So product owners kind of deal with this whole span of things. And in between, product and sprint goals start to make things a little bit more concrete. Okay, and... One of the things I'll do for my product owners is I'll take that Mobius loop and I'll overlay it on a planning onion like that and go, do you get to see how, like what we're talking about here, you're starting out way vague in discovery and you're getting way more concrete as you get into delivery and into the sprint. And really the job of Agile and Scrum is both. It's not just about turn the crank on the machine. In fact, I think it's unfortunate that there's a book title out there of twice. the work in half the time. I actually like to pitch this as more it's about twice the value with half the stress. Okay, now as you imagine that Mobius loop kind of overlaid, one of the things I'll unpack for folks is when you're way out in that vision area, there's a lot of uncertainty that's there, okay? And you're actually going to have to do discovery. You may have to run some experiments.
Brian (24:58)
Yeah.
Bernie Maloney (25:24)
Okay, and it's only as you get closer into delivery that you want to get closer to certainty. And really, that's kind of the job of a product owner is squeezing uncertainty out of the system. Initially through discovery of the problem to solve, who to solve it for, what the market is, but it's the job of the whole team in Agile to squeeze that uncertainty out of the system. Brian, I'm sure you've had folks like talk about spikes. You ever have people get wrapped around the axle about like including spikes in their product backlog?
Brian (25:48)
Yeah, for sure. yeah, for sure.
Bernie Maloney (25:54)
Cool, the way that I frame that up, okay, so here's a mental model. That's just technical uncertainty that you've uncovered. Great, okay, so now we've got to go squeeze that uncertainty out of the system. So stop getting wrapped around the axle on stuff like this. Just like stop trying to plan and predict things. Instead, kind of get into sense and respond on all of them. And there, I've kind of brought it around full circle for you, Brian, for where we started.
Brian (26:09)
Yeah, no. No, that's great. That's great stuff. And I love the fact that we can bring it back full circle. Well, this is fascinating. And like you said, we could press play and go on this for another half hour very easily. But we'll be respectful of people's time here and keep it to our normal time length. Bernie, I can't thank you enough for coming on. I really appreciate you sharing your experience with us. And... what you've learned over your years of working in this profession.
Bernie Maloney (26:50)
Thank you so much for asking me, Brian

#106: Innovating Through Economic Downturns with John Barratt

Join Brian and John Barratt as they delve into the current state of the agile industry, exploring the impact of economic downturns on agile coaches and Scrum Masters, and discover innovative strategies to navigate these challenging times.
Overview
In this episode, Brian and John Barratt dissect the current state of the agile industry, focusing on the effects of economic downturns on agile coaches and scrum masters. They discuss the reasons behind organizational layoffs and cost-cutting measures, emphasizing the need for innovation to thrive during challenging periods.
The conversation shifts to redefining the roles of scrum masters and agile coaches, highlighting the importance of delivering value and outcomes rather than merely facilitating meetings. John introduces two essential resources—the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics—to support agile practitioners in their professional development.
The episode concludes with a discussion on the significance of mentorship and continuous improvement within the agile community. Tune in for invaluable insights and practical tools to enhance your agile journey.
Listen Now to Discover:
[1:08] - Brian welcomes Certified Scrum Trainer®, Certified Team Coach®, & Certified Enterprise Coach®, and host of the Clean At Work podcast, John Barratt.
[4:42] - John reveals the core issues behind struggling organizations and shares how innovation can allow an organization to thrive during challenging times.
[5:50] - Brian and John analyze the impact of economic downturns on organizations and agility, offering strategies to navigate these challenging times successfully.
[10:04] - Brian and John explore the role of Scrum and Agile in an economic downturn.
[16:08] - Join Brian and the Mountain Goat Software team for not only a Certified ScrumMaster® class but a full year of membership, learning, and support from Mike Cohn, Brian, and the Agile Mentors Community. You don’t have to lead alone.
[17:09] - Brian poses an opportunity to expand the definition of done of Scrum leadership.
[19:43] - John introduces the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics as powerful resources to help Agile practitioners and leaders enhance their skills and progress in their development.
[23:42] - John shares the tool of Agile Scoping, based on From Contempt to Curiosity by Caitlin Walker, to lean into Scrum success within an organization.
[32:25] - Brian shares a big thank you to John for joining him on the show.
[33:04] - We invite you to share this episode with a friend and subscribe to the Agile Mentors Podcast.
[33:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[34:16] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
References and resources mentioned in the show:
John Barratt
Clean At Work podcast
Scrum Events Meetup
#93: The Rise of Human Skills and Agile Acumen with Evan Leyburn
The Agile Army - John Barratt
Agile Coaching Growth Wheel
Agile Coaching Code of Ethics
Agile Scoping
From Contempt to Curiosity by Caitlin Walker
Agile 2024 - The European Experience - Manchester
Agile Coach Camp UK
Certified ScrumMaster® Training and Scrum Certification
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
John Barratt is a Certified Enterprise Coach® (CEC) and Certified Scrum Trainer® (CST), passionate about helping individuals, teams, and organizations achieve their best through agile coaching approaches. With a background in the military and a keen interest in systemic modeling, John constantly seeks new ideas and innovations to support organizational resilience and agility.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We are here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner, and with me today, I have a good friend of mine that I've been trying to get on the show for a while. Mr. John Barrett is with us. Welcome in, John.
John Barratt (00:14)
Thank you for having me Brian. It's been a while. We've been trying. We're here today. I'm really pleased.
Brian (00:18)
Yeah, very, very excited. John and I have seen each other at conferences for years. We've crossed paths. And I kind of jokingly said to him, I'm threatening to have a conversation with you not at a conference at some point. And that was kind of how we started this. For those who aren't familiar with John and his work, John works with a company called Agile Affinity.
John Barratt (00:34)
Hahaha!
Brian (00:43)
He is a certified Scrum trainer, a certified team coach, and certified enterprise coach. So he has the holy trifecta of Scrum Alliance certifications there from the guide community. He's a coach and trainer. Couple of interesting things. First of all, we'll talk a little bit about this, but John has his own podcast called the Clean at Work podcast that we can talk about here a little bit. But another interesting thing that he told me before, I didn't realize this, but John actually started in the military. So do you want to say anything about that? How long were you in the military?
John Barratt (01:19)
Yeah, so I was in the military for six years, joined accidentally when I was 18. So I went into the career office with a friend who was joining. And they were like, you're a bright lad, you can earn all of this money. So it was either go to university and getting lots of debt or join the army, get lots of training and get paid and see the world. So no thoughts of joining before that day accidentally joined. Did six years including a tour of Iraq. And the important thing about that for me is when I left, I felt really isolated. So Army is all about team, right? Team focus. Left the Army, was in IT, and it felt totally different. People were there stabbing me in the back, not supporting me. And then I found this thing called Agile, which was about teams again. And this thing called Scrum, where it was a team game. I was like, this is what I've been missing. Where's this been for the last two years since I left the army? And the rest is history. I did do a keynote at Central Agile Spain. I'm not sure what year, but it is on YouTube for anyone who's interested in hearing more about how the army is actually rather agile in my humble opinion.
Brian (02:22)
Yeah. That's awesome. We'll find that and put that in the show notes here. So if people are interested in finding that, they can go and watch that.
John Barratt (02:45)
Yeah, we'll have to dust it out of the archives.
Brian (02:48)
Well, yeah, yeah, I'm sure we can find it. But we were talking before this about our topic and I think this is going to be a topic that's interesting to a lot of people. Really, really kind of diving into the state of the industry right now and what we're seeing as far as the economy in the agile industry. You know, there's there's several organizations that have laid people off You know, there's there's less demand at the moment in the coaching kind of realm So kind of what's behind that the the shifts and you know What might be driving this kind of thing? So I know John you got some opinions on this. So let us have it
John Barratt (03:18)
Mm -hmm. Yeah, so I don't want to talk too much about the global economics. I don't pretend to be an expert on why we're seeing a recession. We can talk about, you know, COVID and the cost of that and also the war in Ukraine and, you know, all of the pain and suffering that that's caused much more than, you know, what we're seeing, which is, you know, a few people being laid off. So I don't want to go into that. But what I do want to really explore is, so if an organization is struggling, there's two elements. for that. Do they try and cut back as much cost as possible or do they try and innovate themselves out of that recession? Do they try and do something different and in a unique way? Unfortunately what I'm seeing a lot of is the first one which is cut back, reduce cost as much as possible and that's to the detriment of the the Scrim masses and and agile coaches that we see and I'm going to talk a little bit why they are the ones that often are in danger in a minute. Instead of where they should go, which my bias opinion should go, right? What I'm trying to do in the company that I run is to actually lean into that as an opportunity and try and innovate and see, well, what is possible in this new, exciting world that we're perhaps moving into? Where do we need to go when organizations are struggling? What are the opportunities, an example, AI that we've seen and what difference will that make in the next few years? I mean, who knows?
Brian (05:14)
Yeah, yeah, I think it's fascinating and you know, there's something I've talked about with some friends for several years and that is that I think there's sort of a, boy, I don't know how deep we want to go on this, but you know, you have a lot of executives now that get hired to come into a company and it's gamesmanship because the idea is I've got to increase our... our stock price by however many percentage points. And my bonus is tied to that. The more I can increase it, the more I get a bonus. Well, it's kind of like if you go to a team and tell them, hey, can you do more story points? They can certainly game that and all of a sudden have more story points. Well, the same thing with a short -term kind of executive. If you're in an organization and you're only going to be there for a couple of years, And you know your site is, if I can raise it three percentage points, I get a bonus. Well, there's a lot of easy cuts I can make that all of a sudden I've gone up three percentage points. But the long term of that company has not benefited. It's only the short term. And it just feels like, I don't know if it's a day trader thing, if that's really why this is kind of becoming more prevalent or not. But it seems like investing is kind of more of the short term. Now, and it used to be when you buy a stock, you'd buy it for 10, 20 years because you believed in that company and you expected to pay off over the long run. There's still a little of that, but it seems much more short -sighted. And I think that's trickled down to our, like I said, I don't know how deep we want to get on this. I think that's trickled down to our executives. And I think from the executive, that's trickled down to the employees. And that's really affected how...
John Barratt (06:41)
Mm -hmm.
Brian (07:06)
you know, when we've had layoffs and we've had downturns in the economy that just, hey, this is an easy way for us to show an increase in profits.
John Barratt (07:15)
Yeah, I think that's a really good point. It reminds me of Craig Lammon's laws, structure leads culture. And when we talk about structure, we don't ever just mean the hierarchy, we mean the bonus system, how people are rewarded and paid and all of those things. And so if you're rewarding shortism by giving these execs bonuses based on
Brian (07:34)
Yeah.
John Barratt (07:41)
profit for this year or as you said stock increase by 3 % then they will cut costs because what looks good for short term and for stocks is to have the minimum operational expense possible right if they can keep that as low as possible then that looks like a solid company because they're keeping controlling costs they talk about and and If they're working on margins and profits start to go down, which is what we're seeing as a trend at least UK, US, I can't say if it's completely global, but it seems like a large percent of the company and the organizations are going in that way, then what they do is to keep their margins so that they get their bonus is they start to reduce that, right? Because they need to keep that buffer. If they were to do what I'm suggesting, which is to lean into that and perhaps spend a little bit, spend some money to make some money, or at least keep it lying and try some innovative stuff, then that's high risk for them. Hmm.
Brian (08:50)
Yeah. Yeah, I've seen things before that have said that when there is economic downturns, that their evidence shows that the companies that invest more during the economic downturns actually end up increasing their positions to a much greater extent when the downturn starts to turn around because...
John Barratt (09:02)
Mm -hmm.
Brian (09:14)
they haven't just set idle or they haven't tried to reduce, they've tried to invest and now they're positioned to really take advantage of it once the economy starts flowing again. I'm not like you, I'm no economic expert, I'm no economist. So I don't know all the ins and outs of what's causing that. But it certainly has caused pain in our sector. And I think a lot of sectors, because I have I know lots of people who have gone through layoffs, not just in the tech industry recently. So I guess kind of the question that I ask about this as far as the agile community is concerned is, if we were delivering value, right? If it was undeniable that what we were doing was increasing profits, increasing value to our customers, I think that would make it a lot. harder for these kind of layoffs to happen. So I don't want to entirely say, hey, it's bad leadership, right? I think we have to take ownership a little bit.
John Barratt (10:23)
Yeah, and I'm going to say something I think is quite controversial here, which I actually blame servant leadership for this. So I know in the latest version of the Scrum Guide, we use the word true leadership, but I still like the word servant leadership. And I've actually changed my mindset and how I teach these things over the last few years because of this, because we've started to see this trend.
Brian (10:28)
Go for it. All right.
John Barratt (10:51)
And I've seen it in organizations where I've worked, I've left one year later, and then they've made all the agile coaches redundant. And I think it's down to how we use and perceive servant leadership. So historically, I was always, you know, Scrum Master or Agile Coach is the great person in the background. They let everyone else take the credit. They're there to help and support the team and to do all of that stuff, which is great, right? until someone with a balance sheet comes along and goes, what are all these scrum masters who aren't delivering any value, right? They're an overhead. They're seen as an overhead. Not delivering any value. No one can even tell me what value they've created. These developers over here, they're doing great. And the product owner is really maximizing the value of this product. But these scrum masters, they don't add any value. Because that's what we told them to do, right? We taught them to...
Brian (11:29)
Yeah.
John Barratt (11:49)
give everyone else the credit and serve everyone else and be in the background. So I think we've got a lot to blame, Brian, as trainers for, well, I don't know how you've taught it in the past, but I feel a little bit guilty. Don't worry, I've got the answer, but I just want to hear from you, what you, where you are with that one.
Brian (12:04)
No, no, no, no. Yeah. I'll tell you my opinion and you'll tell me if I'm correct or not. Yeah, no, I agree. I definitely think that's part of it. But maybe this will be a little controversial. I kind of spoke about this recently at the Scrum Gathering in my talk. In the trend that we've seen, John Barratt (12:15) Yeah!
Brian (12:40)
that I kind of talk about the diminishing of the perception of value of the Scrum Master. And I think that there's kind of multiple parts to that. I think part of it could be, hey, leadership doesn't really understand the value. But I think that there is a secondary part of that, that they're not seeing the value. And if they're not seeing the value, then I think that that's
John Barratt (12:48)
Mm -hmm. Mm -hmm.
Brian (13:08)
that rest on us. I think that we have to partly do a better job of helping them to understand it, but partly doing a better job of delivering it. And again, don't want to get too controversial here, but in our industry, in our training industry, You know, we've done lots of two day classes. We've done lots of things where we get people out the door and then they're in place and they're doing things. And the follow -up, you and I both know the follow -up is so important. You can't just take a two day class and then you're set for life. It's two days, but that's a kickoff and you got to continue that. and if I, if I take a two day class and I kind of slide backwards a little bit from that class and I get in and I'm a scrum master, there's, John Barratt (13:43) Mm -hmm. Yeah.
Brian (14:01)
Unfortunately, I think there's a lot of scrum masters out there who see their job as meeting scheduler. I'm here to schedule meetings, and that's the value I bring. Well, I can't blame a leader for letting that person go, because anybody can schedule meetings. It doesn't really take a lot of skill to do that.
John Barratt (14:08)
Mm -hmm. Yeah.
Brian (14:26)
The skills that we should be adding are those soft skills, the conflict resolution and understanding the personality types that make up our team. And essentially what I talked about in my talk was that first phrase of the Agile Manifesto, individuals and interactions over processes and tools. It's about individuals and interactions. We have to know the people that make up our team, not every team in the world, but our team. And we have to know. how they work best together. And I think people who do that, there's enormous value for that. So I would propose to you there's a shared blame, right? I think there's a blame there that we need to do a better job of showing the executives, but we also need to do a better job of actually providing value for the executives. John Barratt (14:58) Mm -hmm. Yeah. Yeah, yeah, I'm just, I was just, you know, I'm new to running CSMs and things like that. And one of the things I've brought in is a follow -up session. So, you know, a month after the training, they can have 30 minutes and we can talk about stuff. And that's really where you appreciate that the CSM isn't enough, right, to be a Scrum Master because you... There's only so much you can do, but the thing that always lacks, at least I haven't managed to perfect it yet, is those soft skills, right, which are the things that are important because you can't cover that in half an hour, an hour, right? All of those things are a full one, two, well, I'm being generous, just touching the sides with a one, two day course in some of those. And it's good to see the Scrim Alliance moving into some of those, you know, competency based or what they call skills based. courses where we can go a bit deeper into those key things. Because they're talking about, well, how can I do this? And in my head, it's obvious, but it's clearly not. So there's a huge gap between putting someone on a two -day course and thinking they can be a scrum master. And we do see a lot of bad scrum masters in the industry. And it certainly does cost everyone, even the good ones, some credibility. Right? Because... And if there's more ones, and it's not bad because they're bad people or trying to do a bad job, it's just that they haven't been equipped to do the job, right? Yeah, it's as simple as that. Brian (17:03) Yeah. At one of the tables I was at at the recent guide retreat at the Scrum gathering, we were having a discussion around this. And one of the things that kind of struck me as that was going on was, you know what it sounds like? It sounds like we don't have a stringent enough definition of done. Like when we think about someone who's you're now ready to be a Scrum master, well, that definition of done right now is a two day class. Right? And.
John Barratt (17:22)
Mm -hmm.
Brian (17:32)
I think we have to put in the expectation that, no, this is a component of that definition of done, but there's actually more that you need in order to, you know, this is an important role. This is somebody who is shepherding and guiding a team to be successful in this. So if someone's not qualified in doing that, it's no wonder that we see a bunch of bad scum out there because the person leading it isn't qualified, you know?
John Barratt (17:38)
Hmm. Yeah, and actually, I was just thinking an apprenticeship approach would be a much better idea, right, for this type of work. I often give the metaphor in my classes that agile coaching is a craft, Scrum Mastery is a craft. And imagine you're a carpenter, you don't get better at being a carpenter by reading lots of theory about good joints and all of this stuff. You know, you pick up a few things, you get better at Scrum Mastery or agile coaching.
Brian (18:07)
Yeah.
John Barratt (18:29)
by working and getting feedback. Our work is with the people, right? And people are a lot more complex than would, so we have to do even more of it to get any good. And of course, in carpentry, you wouldn't think about, we'll do a two -day training course. You would do an apprenticeship, right? And they do it for years before they become like a master carpenter. Yet we have scrimmasters after two days.
Brian (18:58)
Yeah. Yeah, no, I completely agree. And for the organization, I know when you've seen organizations that have sort of that layer, that hierarchy of we have Scrum Masters, but we have coaches, and we have enterprise coaches. When you have that kind of structure where you can have the phrase we use as mentor and be mentored. And if you can be in that place where you mentor others and you're also being mentored,
John Barratt (19:21)
Mm -hmm.
Brian (19:28)
That I think is really key to reaching the next level, to being able to kind of grow into what it is that you want to become in this industry.
John Barratt (19:39)
Yeah, I mean, I can't solve that problem very easily myself. You know, we've got a certified team coach and enterprise coach in the Scrim Alliance. It needs to be a bit more of a gap, I think, between that and CSPSM and we'll see what comes out in the next few years. But there is a couple of resources that I have worked on to try and help with this. So I've been on a mission to try and professionalize the world of agile coaching for at least five years. And the two things that I've found that have helped most people, is something called the Agile Coaching Growth Wheel, which you may have heard of. We'll put the link in the chat to that, which has kind of all of the competencies that we think you need in Agile Coaching, which is the set of competencies that a Scrum Master needs. So not Agile Coach, Agile Coaching, Scrum Master, Agile Coach, or any, you know, job title could be anything, right? It doesn't really matter. So that's a really useful tool. gives you all the areas, but it also gives you guidance, like a one to five guidance that almost uses the apprenticeship type thing. I can't remember all the levels, I think it uses like the Drift for scale, but it says at level one, you should be able to do these sorts of things. At level two, you should be able to do these sorts of things. And that gives people at least a starting point. You don't know what you don't know, right?
Brian (20:58)
Right. No, I think that's awesome. And we definitely will put that in our links and make sure that people can find that. Yeah, you're right. That kind of apprenticeship idea, I know that I could not have gotten to where I am without the mentors I've had.
John Barratt (21:15)
Mmm.
Brian (21:18)
And it's people who have, for no benefit of their own, have taken their own time to say, I'm going to invest time in this person and help them reach the next level. And I've tried to carry that forward as I've grown in this career as well, because I think it's important. I think we have to help the next group that's coming along. Yeah.
John Barratt (21:44)
Mm -hmm. I was thinking becoming a CST is almost like that apprenticeship type system, right? Where you have to do the co -trains with different people. They're like mentors, right? Different diversity, different types and groups. And you learn, both people learn from doing the co -train. And I think personally, it'd be a shame if they ever...
Brian (21:54)
Yeah.
John Barratt (22:16)
remove that concept because I think it's the closest we've got to an apprenticeship.
Brian (22:21)
Yeah. Yeah, and it works, right? I mean, I think that it does a good job of getting people to the level they need to be. There's still a lot, I mean, that doesn't do it all on its own, but it is, you know, I think anyone who's been through it, I think you would probably agree with this as well, is, you know, that was a foundational part of becoming a CST for me, is being able to observe and watch others and learn from them and... get feedback on how I was doing it. So I think you're right. That could be a very intriguing addition if there was someone who kind of incorporated that into the process. And I think that would give organizations kind of a confidence to say, I can trust this person.
John Barratt (23:10)
Which is what we really want with the CCCTCs, right? It's that stamp. I can trust that person. Second tool I wanted to highlight was the Agile Coaching Code of Ethics. So this was an initiative we did with the Agile Alliance. And the beauty of when we created this code of ethics, it was for people who were just starting out as well as experienced professionals. So you can read through that and that's kind of your rule sheet of
Brian (23:25)
Yeah.
John Barratt (23:40)
I'm new to this. This is the minimum standard we expect from a Scrum Master or an Agile coach in this industry. Because you don't know what you don't know again. But we've tried to make it as simple as possible. A simple list of these are the things you should definitely do if you want to be ethical in your work.
Brian (24:00)
Yeah. Yeah, that's a good resource as well. And we'll make sure we have that linked. Was there another resource as well that you wanted to mention, or is it just those two?
John Barratt (24:12)
So it's the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics. So we've talked a lot about the problem of where we're at, and we've given a couple of pointers. I wanted to talk a little bit about how I've changed my direction from this original kind of servant leadership type focus, which seems to be having some...
Brian (24:36)
Yeah.
John Barratt (24:40)
traction and benefit and value to people. And it's a couple of tools combined. So I created something a couple of years ago called Agile Scoping, which was based on Clean Scoping. So Clean Scoping is something that Caitlin Walker created based on Clean Language around how she scoped out a new piece of work. If you want to know more, then I highly recommend her book from Content Curiosity.
Brian (24:44)
Awesome.
John Barratt (25:10)
Bit biased, but one of the best books I've ever read. Not an agile book at all, but just a truly incredible story about how she's used clean language and something we call systemic modeling, which is using clean language in groups, with youths that have been kicked out of school, for example, and how they went from all individuals to suddenly kind of helping and supporting and understanding each other.
Brian (25:31)
Hmm, yeah.
John Barratt (25:40)
So great book. But anyway, Agile Scoping was based on that and it starts off with a discovery phase. We call that initial scoping, which is setting out kind of, is this work set up for success? So is the person in charge actually got enough influence over the system to actually make any change? So if you are doing Scrum. Do they have permission to actually change the structure into something that is actually going to help Scrum succeed? Have they tried different things before? And also this thing called congruency. So it's what they're saying aligned to what they're doing. So asking for those examples of, okay, you're saying that this, have you tried that before? Those sort of things. Very high level, just checking it out. And you can do that in an interview as well. So this isn't just for an external person. I always think that interviews should be two -way, right? It's not just a one -way thing. I want to check that if I'm signing up 40 hours a week or however many, that this is an organization that actually wants to be agile. I mean, I always put my hand out to the people on my training and people I meet at conferences where they're really struggling, right? And it's a really hard environment. And I always think, wow, you've got way more patience than I have. I really respect that. but my patients' levels are very low. So if I'm going to work with a client, I need to have a feeling that they can work at a pace, right?
Brian (27:20)
Yeah, right. Right.
John Barratt (27:21)
So that's level one and that's fine. Then we do an organizational scoping phase where you work with as many people as possible. You're looking at the problems that the organization says they've got, what the culture is now, where they want it to be, running some workshops, finding out what's happening. And again, we call it scoping because you can scope it to the level that you've been brought into. So if you're a Scrum Master working with one team and it's... One product owner, small product, that's fine. That's your scope if it's a whole organization, much wider. At the end of that, you create a coaching plan with the organization. So you have a session and you agree up to four outcomes is what I've found. So we move into outcome -based approach. So even if you skip all of the other stuff, what I would say is move away from any output thinking. As a scrum -rosterer,
Brian (28:10)
Yeah.
John Barratt (28:18)
even if it's just in your yearly appraisal, make it clear these are the outcomes that we're looking for. And these are more business related outcomes or things that are going to actually make a difference to the organization. So it could be things like make more money for the organization, could be increase employee engagement, increase customer engagement, number of active users in your mobile app, whatever those are. But they're nothing to really do with Agile, they're to do with...
Brian (28:42)
Yeah.
John Barratt (28:47)
that the organization wants to set. Those go into a coaching plan. We have a coaching agreement canvas that you can use to put all of that in. And then it's really clear, like these are the things that I'm going to help and support you with as a Scrim Master or Agile coach. There's a bit more risk, right? Because if you don't meet them, then you've got to have a conversation, but at least then it's visible, right? These are what I'm saying I'm going to help with. This is what you've said you want help with. And now we're going to do a number of experiments to try and get there. And that's where we get into that continuous improvement cycle of trying to involve, adapt, inspect, work on all of those things that are happening within your team, within your department, within your organization, depending on where your scope is, constantly evolving and looking at. where we're at. We might have some lead -in indicators as well, perhaps in there to help us cycle time, lead time, throughput. Those can be useful, but really we're looking at end value and we're measuring our performance of a Scrum Master Agile Coach based on the value being given. We're not letting the product owner take all of that praise and credit. Of course, we don't want to be too arrogant and go too far the other way. It's a team effort. but we're at least putting our, you know, more, I think skin in the game is the thing. What I've seen in the past is, you know, bit of a puppy dog type thing, Scrum Master, ooh, shiny over here, great, shiny over there, no, skin in the game, this is a partnership, and we're gonna work on this together. Sorry, I spoke for a long time, though.
Brian (30:16)
Yeah. Love that. No, no, no. I love that. You were saying great stuff. And I mean, I love the bit about outcome -based kind of approaches to it. I think that's really, really important. I've always thought, you know, like the performance, I'm always really hesitant about performance -based kind of metrics. And I always want to shift more to output outcome -based kind of metrics, not output. And I think that because that's, You're right. A business doesn't care how agile we are. A business cares if we're increasing our bottom line, if we're increasing our membership, all the business goals that you might have. That's what they care about. And agile -ism means to that.
John Barratt (31:17)
Yeah, I have a big shiver when teams have like agile maturity models. Like the word maturity, first of all, like if I say to you, Brian, you're immature, Brian. You know, that's just like, why would you do that? And also if I, you know, it's many people have said agile is never the goal, right? We're never trying to be agile for agile sake. We're doing it to help organizations and, you know.
Brian (31:23)
Ha ha ha.
John Barratt (31:44)
Therefore, why would you want to know how mature a team is when that's not actually that important, right? Could be a very leading indicator, perhaps, of where you're trying to get to, but it scares me when I see those sort of things.
Brian (32:04)
Yeah, this is great. This is great stuff. And there's so I mean, from what you've said, there's so many good links that we're going to be able to put in our show notes for this. We'll also, by the way, make sure that people can get in touch with you, John, if they want to follow up and learn more individually from you, because that's always really important here as well. And I know it's conference season. There's a lot of conferences going on. And you were telling me you're going to be at the Europe.
John Barratt (32:12)
Mm -hmm.
Brian (32:33)
Agile 24 conference, right?
John Barratt (32:36)
Yeah, so I've decided to do my part for the environment and not fly out to America for the third time this year. So I'm going to be in the Agile Alliance Manchester in July. I'm doing two sessions there. One looking at product refinement using clean language and the other one how to help and support self -managing teams with Caitlin herself. So if you like the idea of the stuff I was talking with Caitlin. and that's the session for you. Also going to be in Agile Prague this year, Agile Coach Camp UK, which I run, but unfortunately that is full. So there is a waiting list if you did want to try and sneak into that. And I'm sure I'll be at a few other places as well. There's also my monthly meetup that I run with a number of other colleagues called Scrum Event. It's actually the second largest Scrum Alliance user group in the world.
Brian (33:33)
Awesome.
John Barratt (33:34)
and we tend to have some pretty cool speakers there, so watch out for that.
Brian (33:40)
That's awesome. Yeah. We'll try to link to all of that so that people can find it. But yeah, if you're going to be at any of those conferences or if you're on the fence about going to the conference, you can hear great speakers like John there. So make sure that if you do, that you go up and say hello and tell them that you were listening to the podcast and heard this and were interested. And that's why you're there. Well, John, I appreciate your time. We're recording this on a Friday afternoon for you. And I know that's really precious time at the end of a week. So I really appreciate you giving us your time here and sharing your knowledge with us.
John Barratt (34:19)
Thank you for inviting me and having me. It's been a blast.
Brian (34:24)
Absolutely.

#105: Scrum Conferences & Neurodiversity with Brian Milner

Join Brian as he delves into the powerful response to his talk on neurodiversity at the Global Scrum Gathering in New Orleans, which emphasized small but significant changes to make environments more accommodating.
Overview
In this episode, Brian shares his memorable experience at the Global Scrum Gathering in New Orleans, emphasizing the event's stellar organization and inclusive atmosphere. He reflects on the success of his talk on neurodiversity, which resonated deeply with attendees and sparked meaningful conversations.
Brian also underscores the importance of attending conferences for networking, learning, and expanding professional connections. Encouraging listener feedback and engagement, Brian hopes to inspire more inclusive practices within teams and the broader Agile community.
Tune in for insights on fostering inclusivity, the value of professional gatherings, and much more.
Listen Now to Discover:
[1:08] - Brian warmly welcomes listeners and invites you to join an engaging conversation about the value and insights gained from Agile conferences.
[2:45] - Brian kicks off with heartfelt gratitude to the behind-the-scenes teams whose hard work and dedication ensure these conferences run seamlessly and effortlessly.
[5:04] - Brian celebrates the often-overlooked joys of conferences, from hearing fresh voices and engaging in hallway conversations to making meaningful connections and sparking innovative ideas.
[9:57] - Brian highlights and commends the Scrum Gathering for its intentional efforts to accommodate and include attendees with neurodiversity and those with additional needs.
[14:15] - Brian shares that the goal of his talk was to demonstrate how small changes can create a more inclusive environment, such as playing neurodivergent-friendly music, dimming bright lights, and establishing quiet spaces.
[20:18] - Brian discusses the overwhelmingly positive response to his talk and expresses his hope that these inclusive practices will be adopted widely, transforming the way we all work with our teams.
[23:08] - Brian encourages listeners to attend future conferences to gain new insights, broaden their horizons, and forge valuable connections.
[24:20] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. If you’d like to continue this discussion, join the Agile Mentors Community.
[24:33] - We invite you to like and subscribe to the Agile Mentors Podcast and pass this episode along to a friend.
References and resources mentioned in the show:
Slide Deck From Brian’s Talk
#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell
Scrum Alliance’s Global Scrum Gathering
AJR Brothers
Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Auto-generated Transcript:
Brian (00:00)
Agile Mentors, how the heck are you? How's your week going? Hope it's going pretty well for you. I wanted to spend some time with you on this week's episode because I just had an event that took place that was really, really a phenomenal event. And I wanna kind of share with you some personal insights that I had from it and just sort of give you a picture of what it's like. If you've never been to a conference before, Maybe I can entice you to maybe go to one. I think you'll benefit from it. And I think you'll kind of see your career maybe even go in new directions if you decide to go to one.
We just had the global Scrum gathering that took place in New Orleans. That was the 2024 conference. And the Scrum Alliance has changed things up a little bit. I don't know if people are familiar with this or if you're aware of this, but... Scrimmelines used to have two conferences every year. They used to have one that was somewhere in the US, and then they would have another one that was mostly in Europe. But now they've kind of switched up their strategy.
They're going to have one in the US one year. And then next year, it'll be somewhere else globally. So they're really leaning into that global title here for global Scrum gathering. Next year's, I believe they announced here at the end of our conference, is going to be at Munich. So still staying within Europe, but that's not always going to be the case. So there won't be one in the US next year. It'll be the first year that that happens. So every two years, if you're here in the US, you get a chance to attend. If you're somewhere else in the world, maybe there'll be one that appears in a location near you. And that might be a little bit more convenient for you to attend.
But I want to talk about this one that was in New Orleans. And I have to start by just, I want to say to all the support staff, to all the people who volunteered their time from. from the teams that helped set up the rooms to the program team that helped kind of put this all together and create the environment and select the talks and everything else. Phenomenal job. Just phenomenal job.
I couldn't have asked for it to have been run any better. I saw zero hiccups in my time there and just had a fabulous conference. It was a great time. Enjoyed the heck out of it. Enjoyed New Orleans. It's always great to realize I had not actually visited New Orleans prior to this of all the places. It's not very far from where I live, but for whatever reason, it was just one of those black holes in my map. It was one place I had never been to and it was a place I loved. I thought it was just amazing to meet some of the local people there. and to get a flavor of what it was like on Bourbon Street and Frenchman Street and some other parts of the town after the conference. It was just a really great experience. I was very pleased with the whole thing. And so I just want to make sure that that's out there, right?
There's a lot of volunteers that go into working for a conference. I've been a part of that group from time to time. I've reviewed different submissions. If you're not familiar with that process, Speakers at a conference submit their ideas. It's no guarantee anyone's going to get picked. In fact, it's a very, very small percentage. They end up getting picked. So it's a very tough process for the reviewers. And it takes a team of them. They have different tracks that they take submissions in. And they kind of have to whittle those down.
One of my friends who was on the team was describing to me, you might have one talk on, or you might think about a topic like daily scrums. And you might have five submissions on daily scrums that are all amazing talks. They all sound like they'd be incredible with great speakers. But somehow they have to whittle that down. They can't have five talks on Daily Scrums. They've got to limit it. And they've got to have talks on things that they feel the majority of the visitors are going to be interested in. So it's a thankless job that goes on behind the scenes.
And I just want to publicly thank them. I know I got to rub shoulders with several of the people on different aspects of the teams and just really, really appreciate all the work that you guys did to make it such a successful conference. I really always enjoy the scrum gathering conferences. I think they're, they're, they're a fun event. they, they always have a Monday mingle kind of activity.
That's always, something you, you write home about if you will, just something fun to do. this year we had a location was not very far from, the hotel so we could walk there. And just had lots of things that were going on there, food and drink and that sort of stuff. But it just gives you a nice kind of off campus place to unwind and interact with other people and kind of maybe meet some people that you wouldn't get a chance to otherwise. So I always appreciate some of those social events.
Even though I'm an introvert, I just enjoy having different space, kind of a different opportunity to do that sort of thing. And I just want to say, you know, the talks I heard this year were incredible. I heard some really good first time speakers that had never spoken before. And I love the fact that, you know, they're doing that, that they are expanding and it's not just the same crop of people that you hear every single conference. You know, it's a different set of people and it really depends on your topic. It depends on what it is you're trying to talk about.
So I was really thankful to get to hear some new voices there in our community. And the only thing that I wish I could change about that, and this is the same no matter what conference it is, every conference I have this issue, it always seems like the ones you want to go hear the most are if you're speaking, they're happening when you're speaking, or they're all grouped into the same time slot. And you'll get three or four talks that you really wanted to go to. And you got to pick.
You got to choose one of those that you can go to and kind of just plug in there. I'm not one that likes to bounce between the different rooms. I don't have any problem if someone does that. I don't have any problem if someone does that in my talk. But I just like to commit. And that's kind of the way I look at it, is when I come in there, I'm committed, I'm here, I'm giving my full attention.
I want to learn from this person. and leave with something I didn't know in advance. So really, really enjoyed that. There was a talk that was put on by women in Agile that was three new speakers that were three women who had not spoken before. Really enjoyed that and loved their approach. They have a mentor for each person that kind of helps them prepare and get ready for it. So that was awesome.
Really enjoyed listening to that. And just... I don't want to call out any specific talk because they were all so good. I will say there have been years in the past when I have had sort of slots where I've thought, there's not really one I want to hear in this slot. So maybe I've set out or I've done something else. That wasn't the case for this one.
Every slot had something I was like, I've really got to go hear that. I've got to hear that person talk or really want to hear about that topic. So just really enjoyed that.
Couple milestones, kind of, I noticed that happened here. One of my mentors and someone I've had in the podcast, David Hawks was there and he's kind of publicly announced this now that he's retiring, he's stepping back a little bit from doing this stuff and he gave his last conference talk. So it was neat to be there to see his last one. He's a really engaging speaker and always has really deep kind of... needy content for you to chew over that you leave thinking about. So it was kind of an honor to be there for the last thing that he did at a conference.
And the other thing to say is that I really kind of just enjoy the one -off conversations, the hallway conversations. There's breakfast and lunch every day. And when you do those, you sit down at a table, you've got to find a spot. And sometimes I'm just trying to find any open spot. But what I'm trying to do is find the table with people that I don't know, that I haven't met before, that I want to. maybe rub shoulders with and learn a little bit more about what they're doing their organizations.
So those are a great time that they're kind of built in naturally to try to meet some new people. And you know, I'll tell you, I wore a little thing at this conference before it broke on me, but I had a little pin that was kind of my emotional, no, it was my social meter. That's what it was. And it had like a high and a low ranking on it. And you know, I'd start out every day with it on the high ranking. I'm ready to go. I'm excited.
And as the day went on, it would kind of go a little bit further down. And by the end of the day, I was spent. I didn't really have any more I could give out. And I just wanted to wear that sort of a visual fair warning to people. If they saw me and they saw where my meter was, they could say, OK, Brian's kind of running low. Maybe. Maybe I'll wait till tomorrow and have that conversation.
Not that I'm going to be mean or rude to anyone, but just there are times when you just are all empty. You're just out, and you don't have anything more that you can give. And that's certainly the way I feel sometimes at the end of some of these long days. I've been known sometimes to just go up and spend time taking a nap in my room, maybe doing some emails or something, just something to give me a break to go away.
And that's sometimes something I need in these kind of big social environments. I do want to really, really congratulate the Scrum Alliance on one thing that I noticed particularly here in this conference. They clearly made an effort to make some accommodations for some different personality types, neuro types, and you know, I've shared with this podcast before that my talk here at the Scrum Gathering was on neurodiversity and how to be more inclusive of different neurotypes in your teams. I'll get to that talk in just a second.
But there were things that I had been studying and learning about that were small accommodations that people could make that helped some of these different neurotypes. And it was clear that the Scrum Alliance had deliberately made an effort to do that. One thing that I didn't know was going to happen until I got there, for every keynote presentation they had on their big video monitor, they had transcription.
So there was closed captioning of anything that was being said, which is a very important feature for some various neurodiversity types. And I was very, very pleased to see that. I just thought that was a good change that they made. Small change, not really anything big that they had to do to do that, but it makes a big difference for a segment of the population.
And I'm really thankful that they did that. The other thing that I noticed that they did was they had a quiet room. There was a room that was right in the mix of all the other conference rooms where presentations were going on that was a quiet room. It was dim lighting. They had some nice cushy soft like beanbag chairs that were in there. They actually had like some soft quiet like atmospheric kind of effect noises going on like waterfalls and that sort of thing. Rain rainfall, ocean waves, things that were very peaceful and quiet.
And they also had made available in that room earplugs for people. And for those that have noise sensitivities, sometimes you can walk into these conference rooms and I can say, I've been guilty of this as a speaker. I want to create an exciting atmosphere. So I blare the upbeat music as people are coming in just to get people in the right kind of excited mood.
Well, if I have noise sensitivities, that's going to not only not be exciting, it's going to be painful. And having the ability for someone to self -regulate that and say, I'm going to put my earplugs in for this, because it's just a louder place. It's a louder room. Even just listening to certain talks, you would hear a talk next door where a speaker would just their plan for their talk was much more interactive. So there'd be a lot of audience participation and shouting outs and clapping and laughing and that sort of stuff.
And it can be disruptive for the room next door. I don't fault any rooms for being more interactive or fun for the attendees, but you know, noise has a bleed through effect. And I was just happy that they thought that far ahead and said, you know, we're going to have some people here who might have that sensitivity to noise. And it doesn't cost very much for us to provide a handful of earplugs.
I don't know how many of them were taken, but I would imagine there wasn't a ton. They didn't run out, as far as I know. But having a place like that, I took advantage of the quiet room. I knew that it was a place where I could go and collect my thoughts. And I would sit down with my laptop and maybe just make some notes of things I wanted to make sure I captured. No one was going to interrupt me.
That was kind of the rule of the room. There was no talking in that room. So I could focus. I could come in there and do what I needed to do without disturbing anyone and really kind of recenter before I headed back out. There were some who used it for meditation and other things. And I have no problem with that. If that works for people, then I'm happy for them to do that.
For me, it was just a quiet space. And I just needed a quiet space, somewhere away from all the hustle and bustle, what was going on. So just kudos to the Scrum Alliance there for that. I think that they made a couple of really intentional moves there to be more inclusive. And I, for one, as part of that neurodivergent community, really, really appreciated it.
So thank you there to the Scrum Alliance. If anyone here is from the Scrum Alliance listening. Big kudos there for you on that. The other thing here is I do want to talk about my talk just briefly. And just to let you know that I did a lot of preparation for this talk. It really was the culmination of about a year's worth of research. I've done talks at other conferences before.
I tried to let people know that this one was different for me. This one was very different because it was very personal. I was gonna be sharing things about my own medical diagnosis. And that's just not something that's common that I have in conference talks. I don't normally go into a conference talk and say, hey, here's what I was diagnosed with.
So that made it very, very personal. But it's also something that is prevalent throughout my family. So I was sharing information from my family as well. Again, like I've said here on the podcast, I wouldn't share that if I didn't have permission. I don't volunteer that for others in my family. If they say that it's OK, then I will. If they don't, then I don't share that information. But it was very personal. And I was much more connected, I think, to the material. I really, really had a vested interest in the outcome.
You know, I wanted to show some real practical ways that people could make small changes and become more inclusive. So that was my goal. And one of the things I tried to do, if you attended my talk, you may not even recognize all these things, but I wanted to first teach by demonstration. I wanted to kind of have things in place that... that would show that you can make small changes to be more inclusive.
So just a couple of things I want to highlight here. One was a very, very, very subtle thing that I don't think anyone caught. But I did have music on that I turned down fairly quiet. I didn't want it to be that loud. I wanted to be loud enough for people to hear, but I didn't want it to be very loud. And I just had a playlist that was playing where I was playing one band in particular. I was playing a band called AJR.
Some of you may be familiar with them, some of you may not, but AJR is a trio of brothers who are neurodivergent and their music is very neurodivergent friendly. They've sort of been seen as kind of, I don't know how to put it, but... figureheads, I guess, of neurodivergent movement. There's lots of neurodivergent people who go to their concerts.
There's lots of commentary and stuff about how they're very open about that in their lyrics. So that was a slight little nod there. If anyone caught that, then congratulations. You caught the most subtle way that I did that. But that was one of the ways I was trying to make it a little bit more friendly. One of the other things I did, I turned down the lights in the room.
There was overhead cans that you would have kind of typical in any kind of conference room. But they also had some like a chandelier that was over the middle of it. There were kind of some circles. And I found the light control panel and found out I could turn off the cans that were in the room and just have the overhead kind of chandelier. And it really kind of brought the light level down. It wasn't dark. It wasn't... so dark that you couldn't see in the room or anything like that. It was still enough that you could see. No darker than you would find in maybe a restaurant, right?
But it was a lower level of light. And that was very intentional. I was trying to help people who had light sensitivities to not have to struggle or worry about that. So that was something I did intentionally. I. Probably the biggest thing I did was I set aside two tables at the back of the room that I call quiet tables. Most of the time you go to a conference, there's an expectation that you do some interactive kind of work there.
I had a lot of data to get out, so I couldn't do as much interactivity as I normally do in a talk. But I did have one big activity that I did kind of towards the back part of my talk. And I wanted to have a couple of tables that if people just were not comfortable, group participation. They didn't want to have to talk to others. They wanted to just come and show up and take in the information.
I wanted them to be able to do that. So I set aside two tables. I put a little sign on the table that said, this is a quiet table. If you sit here, please understand these seats are designated for people who don't want to be a part of group activities and would rather just sit quietly while we have any kind of a group activity. And I set those aside. And I.
As people were coming into the room, I saw people that were starting to sit at those tables and I walked over and I just wanted to check on the people that were some of the first people sitting there and saying, I don't want to interrupt you.
I just want to make sure that you've seen the sign so that you know what to expect here at this table. And I had these three wonderful women that were sitting at one of the tables and they responded very emphatically like, yes, no, we absolutely read that. We loved it and we felt like, hey, he gets us. And that just made my day. I was just so excited that they felt that way and they felt welcomed, right?
That's kind of what I was trying to do is create a welcoming atmosphere that nobody felt left out. Everybody felt included, normal. I did some other things too, like we put out some little badges that said, embrace neurodiversity, that people could put on their name badges, just to kind of raise awareness across the conference from that point on.
I also put little fidget toys at each spot that people could take with them. Just a small little fidget keychain kind of thing that people could have. Not anything terribly elaborate, but just a small little thing. So all these things were just ways I thought of in advance to try to make it a more welcoming environment for people to participate.
Getting to the talk itself, as a speaker, I'm pleased with how it went. It kind of went the way I'd hoped it would go. One small technical thing with a poll that I did at the beginning, but you know now I'm kind of insider baseballing this and I don't really Didn't really Contribute hugely in any negative way. I was able to call out the numbers and we just moved on right
That was not a major part of the presentation anyway So, you know, I'm I'm as pleased with how it went as I probably could have been for anything like that I I could tell things were resonating with people. I got nods.
I got verbal agreement from people in different parts of the talk. So, you know, and we stay within our time box. We met that the way we needed to. So that all went pretty well. But you don't really know until after. And it's after that really kind of made my conference for me because... not just immediately after, but for the remainder of that conference. I spoke on Tuesday. It went on, the conference was Monday, Tuesday and Wednesday.
So for the remainder of day on Tuesday, into the night on Tuesday, and then before I left on Wednesday, I just had random people that would come up to me at various points and thank me for giving the talk. I had one person tell me, thank you and said, I felt seen. And that just almost brought a tear to my eye. I was so excited to hear that.
And that was part of what I was really attempting to do there, is I wanted people to understand that there are differences in how people process things and how people's brains work. And hopefully we can take that back to our teams and change how we approach how we work with our teams. I'm not going to go too much into the detail of the talk. We will make the slides available here in our show notes. So if you want to see the slides like I gave the presentation, I gave it the presentation, we'll make that available for you.
There's no recording of it, unfortunately. The Scrim Alliance doesn't do that. They don't record them and then publish them later. Some conferences I know do. do that, but the Scrum Alliance is not one of them. But I will make the slides available to you if you want to dig into that more.
The other thing I'd say is if you really want to dig in the topic more, find my previous podcast episode, which we'll also put in the show notes. That was with Susan Fitzell. She is a specialist in that area and helped me to understand some things. And that was a kind of key episode. on that topic.
So those are some places I can point you to if you want to get into that, the heart of that, that topic area. But, you know, hearing those kinds of things, those personal kind of congratulations and just people who I didn't know who'd come up and say, you know, they felt seen and that just made the conference for me. I was so pleased that that was the case.
Because just as it was very personal for me, it was personal for them too. It connected to them on a very personal level. And I hope that that can make a change in our teams. I hope that that's something that some of those people who are in the room can take back and implement just one thing. One thing they can change in how they work with their teams. All in all, it was a great conference.
I really enjoyed it. And Scrum Alliance just put on a great conference this year. as they always do. They always put on a great conference. So thanks to my friends at Scrum Alliance for inviting me and having me there to speak. Thank you for all the volunteers who worked on it. Thank you to each person that I had a conversation with, especially the new friends that I didn't really know before the conference.
I... I really enjoy, and the ones that I haven't seen for a while that I kind of got to rub shoulders with there. Again, I really appreciate you coming up and saying hello. And I did have a few people from the podcast who came up and said, hey, listen to the podcast. That's always a pleasure when that happens.
It just helps me to know that, hey, this is actually resonating. This is making an impact for people. So. I heartily appreciate that. If you ever see me at a conference, please do. Don't hesitate. Come up and say hello and tell me that you listen to the podcast. You'll make my day if you do that. So that wraps up Scrum Gathering 2024, New Orleans.
I should say global Scrum Gathering. And if you didn't attend this year's, if you're in Europe, maybe consider attending the Munich one next year. I don't know where the following year is going to be in 2026, but it will be back here in the States somewhere. And we'll have to wait and find out where that's going to be.
On my calendar, the next conference I have coming up is an exciting one for me. It's Agile 2024 that's taking place in Dallas. So if you go to the Agile Alliance, agilealliance .org, you can find information about that conference and join me there. I'm going to be talking about conflict and how we can have conflict competent teams. So I'm excited to talk about that and dive into that topic with everyone in Agile 2024. So.
Just wanted to give you a brief recap of what happened there and what it was like, and give you an insider view of what it's like. If you haven't ever attended a conference, I encourage you to give it a shot, especially, you know, I'm based in the Dallas area.
If you happen to be in the Dallas area and you're on the fence about attending the conference there in July, you got no excuse. It's in your backyard, right? It's right there. You'll hear some amazing speakers. You'll widen your network.
You'll be surprised at kind of the connections you make and what you walk away with from a conference. So just highly encourage you to give it a shot. So that'll wrap us on this episode. It was just me, so I won't do a separate little closing thing. If you wanna give me any feedback on this, just reach out to me and send me an email podcast at mountaingoatsoftware .com and I'll get that.
Or you can go to our Agile Mentors Community and post in our discussion forum there. That's a place where you can interact with me. As always, like and subscribe, all that social jazz. Make sure that you... You keep this in your inbox. We always appreciate that. And as we always ask, tell a friend. If you liked the episode, if you liked any of our episodes, pass that on to a friend and let them know about this podcast that you found. That's it for this time. We'll see you again on another episode of the Agile Mentors Podcast.

#104: Mastering Product Ownership with Mike Cohn

Join Brian and Mike Cohn as they dissect the vital roles and responsibilities of the product owner, from story mapping to stakeholder management. This episode is a treasure trove for anyone looking to sharpen their Agile skills and understand the nuanced demands of a product owner.
Overview
In this insightful episode, Brian and Mike Cohn explore the multifaceted role of product owners in Agile development, discussing everything from market analysis and vision creation to the nuts and bolts of sprint planning and retrospectives.
Emphasizing flexibility and adaptability, Brian and Mike offer a comprehensive look at how product owners can excel by focusing on strategic planning and fostering strong team dynamics. This episode is essential for product owners seeking to enhance their impact in Agile environments and drive successful outcomes.
Listen Now to Discover:
[1:07] - Brian welcomes special guest Mountain Goat Software and Agile Alliance founder Mike Cohn.
[1:31] - Brian introduces Mountain Goat Software’s What Happens When for a Product Owner, and Mike flips the script, setting Brian, as the creator, into the guest seat on this episode.
[3:16] - Join Brian as he explores the vital, behind-the-scenes efforts of product owners that set the stage for Scrum success, all before the first sprint begins.
[6:24] - Brian explains the dynamics of crafting a product vision, clarifying how much responsibility lies with the product owner and how much is shared with the team.
[7:46] - Brian offers expert guidance on the optimal timing for creating a story map within the Scrum process.
[9:46] - Brian and Mike explore the optimal quantity of backlog items to have ready before adding them to a sprint.
[13:45] - Join Brian as he explains the importance of setting a product goal in Scrum, detailing how it enhances functionality and guides the development process.
[17:03] - Brian invites you to download Mountain Goat Software’s What Happens When for Product Owners, a comprehensive guide designed to support your Scrum journey.
[17:43] - Brian explains how to effectively integrate road mapping into the Scrum process, ensuring it adds valuable foresight and preparation without causing shortsightedness.
[19:55] - Mike suggests a strategy for managing stakeholders who overemphasize the product roadmap, offering a creative approach to preserve the flexibility and adaptability that effective road mapping allows.
[22:48] - Brian delves into the critical role and strategies of effective sprint planning, essential for driving successful Scrum projects.
[24:20] - Brian offers his perspective on the significance and involvement of the product owner in the daily scrum, detailing their role and contributions.
[26:15] - Mike recounts a memorable story about receiving exceptionally impressive customer feedback at trustworthy.com, highlighting the impact of genuine client interactions.
[28:30] - Brian emphasizes that the product owner is an integral part of the team and its goals, underscoring their collaborative role rather than being separate.
[29:18] - Brian explores the crucial involvement of the product owner in the backlog refinement process, detailing their responsibilities and impact.
[30:48] - Brian explains why he views the sprint review as the product owner's event and offers strategies for executing it effectively.
[32:17] - Brian delves into the product owner's essential participation in the retrospective, emphasizing that their insights and experiences are crucial for the team's growth and improvement.
[34:10] - Brian outlines ways the product owner can proactively prepare for the next sprint, ensuring a smooth transition and effective planning.
[35:27] - Brian discusses a key pitfall that product owners should avoid to ensure success in their role.
[37:35] - Brian shares a big thank you to Mike for taking over this episode of the show.
[37:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[38:08] - We invite you to like and subscribe to the Agile Mentors Podcast and share the episode with a friend who could benefit.
[38:56] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
References and resources mentioned in the show:
Mike Cohn
What Happens When For Product Owners
trustworthy.com
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors, we are back. We are here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and today I have the big man back with me, the OG, we've got Mike Cohn in the house with us. Welcome in, Mike.
Mike (00:15)
Hey, Brian, thanks for having me back.
Brian (00:18)
Always happy to have Mike here. Always a pleasure to have him here and learn from his experience. And really, really grateful he's here. We wanted to have Mike on because we have something that we put together recently. Honestly, it's kind of been something we've been talking about we just haven't put together. We had a document that we had out there called What Happens When for Scrum Master. And we just didn't have one of those for a product owner. So I did some work there on the side on that and put it together. And we're getting that out for people so that you can find that and download it from our site. And we wanted Mike to come on to share his wisdom in that area as well, because a lot of this is stuff that I put together. But we wanted to get Mike's insights on these areas as well. Does that sound about right, Mike?
Mike (01:11)
That's what we agreed to do, but it's not what I'm going to do.
Brian (01:14)
Okay. Sounds good.
Mike (01:19)
I'm going to turn the tables on you, Brian, because it's your PDF. It's your document. You're the ideas behind this. So I kind of want to turn it around and take over. I'm going to kind of interview you, ask you things. I mean, I'll chime in with opinions here, of course. I can never shut my mouth long enough to not share an opinion. But it's your PDF. I want to ask you some questions about it, if that's OK with you. And I assume we'll have the link for this in the show notes for folks. They can get the.
Brian (01:41)
Sure, fair game. Yeah, absolutely. Yeah, they'll be in the show notes. Anyone can find this. If you want to download it now and follow along, just pause, you know, go find that in the show notes and you can follow along as we talk through this.
Mike (01:55)
Great. So Brian, you separated the document out into things that a product owner does. And of course, I mean, kind of naturally you did it by timeframe, right? Do this before you even go and do this every sprint, things like that. I want to talk to you about some of the stuff that we do before the project that a good product owner should do before a project. You had in there a couple of things like do market analysis and create a vision. You tell me more about what you would expect of a great product owner in that world.
Brian (02:25)
Yeah, that first bullet point, what I was trying to capture is that there's some behind the scenes kind of product, standard product work that we don't really account for in a scrum sense. Things like market analysis and trying to understand the competitive landscape. There's a whole discipline there of activity and work that goes on behind the scenes. And I think it's important to understand, that Scrum isn't in any way saying throw that out or that that's not needed, that is something that would come, in my opinion, before you even begin this kind of work. Scrum does not include in it a process that would say, let's verify that they should fund this product. Let's do a pitch. So the CEO of, you know, here's why you should have this product. That's what I was trying to capture in that first bullet point is just understand there are some standard kind of product development work that goes on that we're not, we're kind of skipping over a little bit.
Mike (03:36)
That's one of the things I've always loved about Scrum is that Scrum is silent, deliberately so on many topics. And occasionally I will have somebody that I'll meet and they'll say, Scrum doesn't say how we should do product envisioning, right? It doesn't say how we should do that. So I guess we don't do it. It's like, well, Scrum doesn't say that you should code, right? Nowhere in the Scrum guide does it say code your software product, right? Yet if you're doing a software product, somebody's coding, right? Somebody's doing something. And so I like that Scrum is deliberately silent on a lot of things like this because you're talking about doing this market analysis. I work with plenty of companies that are doing internal software. And if we're doing internal software, we're not going to do a market analysis, just kind of internal user needs analysis perhaps, but it's going to be very different. And so I do like that flexibility there.
Brian (04:13)
Hmm, yeah. Yeah. So that's a good point, though, is depending on the product, it is sort of more as needed or as it would fit. Like you said, if it's an internal product, it's going to look very different than if you're doing a public -facing one.
Mike (04:40)
I think for any of the steps that you've outlined, I think they can vary. I'm sure some are going to be the same for everybody, but I always think of it as commercial development, right? We're making Microsoft Word, right? I think of it as in -house development, right? We're making a payroll system to pay our employees or contract development are kind of the three big branches to me. And then things get very different within those three types of development. I'm thinking more product development there specifically, but of course we can be using this for non -product things.
Brian (05:10)
Well, and I do want to say that that second bullet point, they're talking about vision. That's where I honestly, from my perspective, that's where the product owner portion of this begins, right? Because that's sort of the first thing you need to do. And in fact, when we teach our CSPO class, this is, you know, if you've been through a CSPO class with us, you will recognize this order because that's exactly how we go through it in our CSPO class, very deliberately. You know, that
Mike (05:39)
I'm sorry, I was getting off there, but I was getting interested in something you're saying there. So product owner kind of starting with the vision. I know that the team can influence the vision, right? But where would you draw the line or how much of the vision is the product owners? Is it like, you know, I'm the product owner dictator. Here's my vision, shut up and build it.
Brian (06:02)
Yeah, I don't know that there's one answer there. I mean, I have seen in certain situations where it's more of a group effort. And that might be part of that earlier genesis of the product, where we go through an effort to define the vision with other key stakeholders, with leaders in the organization. I do think that there is sort of a separate activity that I would take with the team itself. So I might spend a deal of time with key stakeholders developing a vision, but then I might also then have a separate meeting with the team once that's established to say, you know, here's kind of what we're defining it as. Let's walk through this. Tell me if you agree, disagree, or how you might improve or change this. Just so that we, you know, part of our job as a product owner is to cast that vision. and help people get caught up in the excitement for what it is we're trying to do. So that's kind of the purpose there I see of doing that.
Mike (07:04)
Yeah. Yeah, the more excited we get people about it, the better off we're going to be throughout the course of the project. You also have some things in here about things to do before the first sprint about identifying users, possibly go into the persona level, but then also story mapping. I want to ask you about the story maps for a second. What's your guideline? Because somebody asked me this recently, I'm curious on your answer. What's your guideline for when we should create a story map? Do you do always, only at the start, only in the middle? What's your advice?
Brian (07:35)
Creating it, I always created at the start. I mean, my, just, and again, this is my experience, right? But what I have found to be useful is to do it at the beginning. And it's sort of right in that order, right? I've done the vision, I've talked, I figure out who my users are. And then I wanna know what the general big picture is for my product. I wanna be able to step back from a 50 ,000 foot view and say, all right, here's kind of the step by step of what we're gonna be doing. Because, you know, kind of like a product backlog, it's a living, breathing document. It's not done, you know, we do it once at the beginning of our product and then it's done set forever. It's constantly adapting and changing as we add new feature areas, as we, you know, understand differently how our users would interact with the product. We're going to adjust and change it. I want it to always reflect reality.
Mike (08:30)
Do you, so let's talk about reality there. I mean, I agree with that, but what I see is story maps that are hard to keep up to date. Are you seeing teams that really succeed at keeping them up to date all the time? I know the living breathing thing for like a couple months and then it's like the dusty old story map, right?
Brian (08:47)
Yeah, well, this is kind of one of the things where it was kind of hard for me to put this in a time frame because there's really two time frames that I would like this to appear in. Yes, I do think we should do it before the first sprint. And by the way, again, there, I would do this in multiple rounds with different sets of stakeholders. But then once it's established, I kind of would slide that into that quarterly kind of activity to say, we may not touch it every quarter, but every quarter I would want to...
Mike (09:03)
Sure.
Brian (09:16)
check in on it and just say, is this still accurate? Do we need to adjust it? Do we need to do anything different about it?
Mike (09:16)
Okay. see that. A couple of the things on the before the first spring here, you've got identify assumptions, possibly test some of those, and then create a product goal. And then the last couple of you got, you know, get enough of the backlog written to get started. And a sprinkle, how much of the backlog do you think a team should have to get going? I mean, I know it's probably not like seven and a half items, but you know, you're looking for, you know, one sprint, one or two sprints, eight sprints.
Brian (09:45)
Bye. Well, no, Mike nailed it. It's seven and a half. Seven and a half items. No, just kidding. Now we can start. No, yeah, I mean, it's, you know, that's why I use the term enough, right? What is enough? Well, you know what enough is, right? You kind of know what that is. There's a, you know, there's a goal that we have in general that we've, lots of us trainers and coaches have put out there to say,
Mike (09:52)
seven and a half backlog items. There we go. Once you've written seven and a half, we can get started.
Brian (10:14)
you want to aim for about two to three sprints worth of items that are in ready to go shape. They're ready to move into a sprint and start at any given time. I don't know that you need two to three sprints to start. Yeah, I mean, I think you need, I think there's sometimes a hesitancy in teams to get everything documented upfront. And I'm trying to help people kind of push past that to say, no, we don't need to have everything.
Mike (10:25)
That's a start.
Brian (10:42)
We just gotta have enough to start. And when I'm working with a team, I wanna get them into that first sprint as soon as possible because they're gonna learn much more from just doing it than they are from talking about it beforehand. That's why I've never been a real big fan of like a sprint zero or something like that because it just doesn't take a whole sprint to do everything that you need to do to get ready for your first sprint.
Mike (10:58)
Right. Yeah, I think you're right. I mean, to me, I always put it in terms of like, we're gambling our time, right? Is it worth gambling more of our valuable time writing more backlogs, or should we just play and get started? And if we're a company whose name is invoices are us, right? You know, should we go ahead and write some stories about the invoicing part of the system? Yeah, I bet we should. But if we're not sure that, I don't know what we're building, but if we're not sure invoice is going to be part of it, don't write anything about that on the backlog yet. Just put one big item, do invoices, right? Break it down when you get there. So.
Brian (11:36)
Yeah. Yeah, I mean, you typically know where you need to start. You know, there's a million things you could do. But when you have a big idea for a product and you're starting fresh and you're starting new with it, at least in my experience, again, I found like, I always know where I'm starting. And that's what I would encourage you to do is just get it out there, get it started. Even if you don't have all the different features and aspects of it thought through, that's OK.
Mike (11:44)
Right.
Brian (12:05)
You just want to start making progress so you learn.
Mike (12:08)
That reminds me of something I've shared with a lot of leadership teams that I've met with over the years, which is that I'll tell them that they're basically solving the wrong problem. And they're trying to answer the question of what should we build? What should the product be? And that's totally the wrong question. The right question is what should we build next? What's that next one or two steps that would tell you what the next four or five steps will be? And so simplify the question, not what are we building, but what are we building next? And I think you're right there.
Brian (12:26)
Yeah, yeah.
Mike (12:36)
one sprint worth is enough and put in the backlog if you need to write more backlog items. Go from there.
Brian (12:41)
Yeah. And I don't want anyone to hear us incorrectly here. I mean, part of the reason that we had them there to identify assumptions and try to test hypothesis is I don't want to open a, the silly example I always use in classes, I don't want to open a store that sells lip balms online and not test whether people want to buy lip balm online or not. There's some fundamental assumptions that you're going to have to test and know.
Mike (12:48)
Thank you.
Brian (13:11)
probably before you're gonna even get with a team and start getting up and running on this. And that should happen here.
Mike (13:16)
Yeah. I was with a company, this is years ago, they were in Boston, we finished the engagement, I'm walking next to my rental car, and one of the guys walks out with me, one of the like VPs, and he's like, I got a question for you. He says, how often should we cancel projects? And I said,
Brian (13:34)
Seven and a half.
Mike (13:35)
I don't know, seven and a half. I said, I don't know. So I don't know how often, but you should be canceling a fair number of projects. You get started, you find out it's going to take twice as long as you thought, or you get started, and it's not really going to deliver the value that you hoped for. So you stop. And he's like, I thought so. He said something like, I've been here, I think, eight years, we've never canceled a project. And it's like, OK, that's bad. You should get into these and find out your assumptions are wrong.
Brian (13:51)
Yeah. Wow. Yeah.
Mike (14:04)
I want to talk about your quarterly items on here. And you've got a couple, let me just kind of read some of these here. So you've got establish a product goal. That's a relatively new thing in Scrum. I mean, I still think of 2020 as relatively new, but as a old timer with Scrum, product goal is one of the newer enhancements. You've got doing the story writing workshop. So you're supporting what you said there. Talk to me about the product goal here.
Brian (14:19)
Yeah. Yeah, so I feel silly talking to Mike Cohen about what a product goal is. Product goals are just that neck, they're a milestone, right? And that's typically the way I talk about this in class is to say, especially when you're starting something new, you may not know everything that you're gonna do, but you know the next big thing that you need to accomplish. You know the next big mile marker that you're gonna hit in the life of your product.
Mike (14:56)
Mm -hmm.
Brian (14:59)
And that's what we want to establish with the product goal. Something that's going to take longer than a sprint, multiple sprints to do. I've got this in the quarterly section. And that's kind of how we tend to talk about it a lot here at Mountain Goat. But even in class, we'll even say quarterly -ish. Right, right, bigger than a sprint. And sometimes it'll be longer. Sometimes it'll be shorter. That's OK.
Mike (15:16)
It's the bigger than a sprint section, right?
Brian (15:25)
You just want to have that big thing that the team can keep their eyes on and kind of know, you know, here's, you got a sprint goal that tells us why what we're doing in this sprint is important and how my small task feeds into that. And you've got this product goal to say, how does the sprints work fit into this bigger picture of what we're trying to do? So you're making those...
Mike (15:47)
Yeah.
Brian (15:50)
connections consciously for the developers so that they are not just, hey, here's a laundry list of stuff to do, but here's the objective we're trying to accomplish.
Mike (16:01)
Yep. I think it's important to have something that's out there bigger than a sprint. A sprint is just, it's just kind of suboptimizing, right? I think about if you're climbing a mountain and a sprint is like, what's the highest thing I see and just always walk into the highest thing you see. Meanwhile, those are all false summits. The real summit is, you know, behind some valley, but you don't see it because you don't set out that bigger goal. And I like how you talked about it quarterly because if the goal's too big, if it's too far out there, we're not going to feel very motivated. about it. I had this the wackest example of this. I hope the guy's not listening. Actually, I hope he is. But he was told me he was on a project with the large particle collider. And he said his whole project won't be due for 40 years, right? I mean, I don't get it. But it's like they've got to run like 40 years worth of data before it's like totally done. And I just picture myself showing up for work on a 40 year project, right?
Brian (16:31)
Right. Yeah.
Mike (16:57)
I know you, you're going to be reading Dallas Cowboys news for the first 35 years, right? You know, sports news and you know.
Brian (17:04)
That's a 40 year project too.
Mike (17:07)
Well, you're not going to take it serious for 35 years. Then you're going to wake up and go, the deadline's only five years away. I better get to work on this. And then what I would do is realize, wow, I'll be retired after 40 years. So anyway, I've been silly. But I mean, you're on a project with a 40 -year deadline. How do you say motivated? And I think three months is a really good time where I can see a bigger impact than a sprint. But it's not so far.
Brian (17:15)
Right. Right, right, exactly. Yeah. Yeah.
Mike (17:34)
that that student syndrome kicks in and I feel, I don't really have to worry about it. Let's go to a long lunch. We'll get to work on it tomorrow. So I do like the quarter -ish approach there. You mentioned here a couple others here. These are probably straightforward, but manage and maintain the economics of your project, assess stakeholder relations, and road mapping. You want to talk about any of those, maybe road mapping especially?
Brian (17:46)
Yeah, yeah. Yeah, road mapping, I think, is an important aspect. I mean, it kind of goes along with that product goal. But I do get people who come through a product owner class that will say, I don't like this approach because it seems like it's all so short -sighted. And we're not really having the big picture of where we're going. And in my world, we have this year -long thing, or 10 year. I've worked with some teams that build automobiles and they're on a three -year release cycle. They're working on the model year that's three years ahead. I've worked with some teams that do aerospace kind of stuff and they're working on a space launch that's multi -years out in the future.
Mike (18:34)
Yeah.
Brian (18:43)
And when you ask them, how certain are you that you're really going to be working on this five years from now? Pretty darn certain, right? Because it's there. We're building toward that launch date's going to be there. So I think that that roadmap is an important step for a product owner. Now, I just want to be clear about this. When I say a roadmap, I'm not talking about setting hard and fast dates and saying, we're going to be here by this date. We're going to be there by this date.
Mike (18:50)
Yeah.
Brian (19:12)
It's okay for us to say, here's kind of where we feel things are gonna fall, but I really am a strong proponent of the forecasting method, like kind of looking ahead and seeing, you know, kind of based on yesterday's weather kind of thing, right? Here's what the weather was like at this time last year. So it's probably a good indicator of where we're gonna be at this season this year, that sort of thing. So I'm a proponent of the forecasting forward. And I think a roadmap can fall very well in line with that because we can slot things and say, here's kind of this quarter's, here's the next quarter kind of things that we're thinking that are gonna take place. And if one thing moves forward or backwards, one of those sections, that's not a big deal. It's not gonna change earth shatteringly the course of our product, but it does allow for preparation. And that's what I think is the most important thing that people lose sight of in sort of forecasting and projecting forward is why do we do this in the first place? Well, we do it most of the time because there's someone else who needs to get ready. They need to be prepared. They need to be ready when this is delivered to do XYZ. And that's what we're trying to accomplish with this. We can do that with forecasting.
Mike (20:32)
Yeah, I think you talk about taking those things seriously. And if we miss one, it's not the end of the world. Except there's always somebody in an organization who's going to say it is the end of the world. The danger for me with roadmaps is how serious people take them. They'll look at it and go, we got a roadmap. It says we're going to come out with this in 12 months. I bet we're going to do exactly these 12 things. And so that literalness to a roadmap.
Brian (20:50)
Yeah.
Mike (20:59)
is scary. I've only done this a couple of times, but I like the result is I put together roadmaps for with teams in a couple of organizations. And we kind of modeled them on the idea of the old, I don't know, 200 or 300 year ago, 400 year ago maps, right? And you would have like, you know, the. horrible map of what the world looked like, right? And there'd be Darby Dragons right on the edge of the map. And we actually did that on a roadmap, right? It had stacks of items are going to be delivered. You know, this, this six months, this six months. And then below there, we had just put a few things in kind of an unreadable font at Darby Dragons below there. Trying to reiterate that you can't take this that literally, but there often is somebody who's like, my annual bonus is tied to that box on the roadmap.
Brian (21:24)
I'm going to go ahead and close the video. Right. Well, you can see this in, you know, I'm not going to get on a tangent here on safe, but you even see this in safe when people do things like PI planning and they plan out the next quarter. One of the pitfalls that I think a lot of organizations fall into when they do that is that they see it as a commitment. That the team is making a commitment to getting all that work done in that PI, in that program increment. And that's not the way it's intended. It's intended as here's our loose plan. We know what we're going to do in the next sprint, but the other sprints are
Mike (21:48)
Right. Yep.
Brian (22:17)
more fluid and we'll adjust as we need to.
Mike (22:20)
Yeah, I've written so many times about a plan is not a commitment or commitment is not a guarantee, right? You know, I can make a commitment to this. I'm going to commit to do my best. We're going to commit to try to achieve these. But I love a Clint Eastwood quote, one of his movies. He said, if you want a guarantee, buy a toaster. Right. So. Those are the days when supposedly banks used to give you a toaster when you open a new account, right? That.
Brian (22:25)
Yeah, yeah. you can guarantee a toaster in today's world. Well, we joke in our family because my wife's grandparents have a, well, they're no longer with us, but they had a refrigerator that was from the 1950s that was sitting out in their barn that still worked perfectly. But we had, you know, our refrigerator is, you know, five years old and it's already breaking down and you have to consider replacing it. So, yeah, yeah.
Mike (22:49)
precede my day, but I... Wow. It's all the electronics in them, I think, right? So I want to move on to the sprint planning. So from the quarterly planning. So in sprint planning, you've got this broken out by what people do in the planning meeting daily during the sprint. So I want to start in the planning meeting. You're proposing a goal and work with developers to kind of improve that, answer questions about backlog items, and talk about your schedule as the product owner share your schedule. You want to elaborate on what you're thinking about with these sprint planning activities?
Brian (23:15)
Yeah, yeah. Yeah, I mean, so I think a goal is important for the sprint. I think that gets us all on the same page and it's kind of one of the teaming aspects of it. We want to all have our eyes on the prize of what it is we're trying to accomplish together so that we're not all just in different places working on different things. I think it's important that we're there in sprint planning to answering questions because that's when they come up. We're making our plan for when we're going to do something. So I think it's important that we're there to kind of help them plan how they're going to accomplish stuff.
Mike (23:59)
Yep.
Brian (24:08)
We're not telling them how to, but we're giving them the information they need to determine how. And then, you know, as far as our schedule is concerned, I think it's a great idea for a product owner in sprint planning to say, you know, here's the next two weeks of my calendar. Here's where I'm going to be out of the office these days. I'm going to be at a client site on these days, just so that people can prepare. If I'm a developer and I know I need to get approval from my product owner and I know they're going to be out for the next two days at a conference or something, well, that might... guide me in how I'm going to plan and arrange my work.
Mike (24:38)
Yep. Some of my favorite POs have been ones that have done something like said, look, between one and two o 'clock every day is total team time. I will never schedule a meeting. I'll always be available if you need me from one to two or one to three or eight to nine, whatever it is, but they'll have some sort of window there that is basically guaranteed access. Doesn't mean that's the only time they're available, but it's a guaranteed time, which is nice. I think it's nice.
Brian (25:04)
Yeah, I love that too.
Mike (25:06)
Talk to me about the daily scrums and what you'd expect out of a product owner during the daily standups.
Brian (25:08)
Ha ha ha. Yeah, daily scrums are kind of a controversial thing here for lots of reasons, but I mean, there's some who would say a product owner doesn't need to be at a daily scrum. I disagree. I think product owners do need to be there. I don't think they're required. Actually, if you want to ask me my opinion, the only people I think are required are the developers, because it's for them, it's by them. You can't have it if they're not there. If anyone else is not there, you can still have the meeting.
Mike (25:14)
Thank you.
Brian (25:38)
But the product owner, I think, is important to try to be at as many of these as they possibly can. Because just like in sprint planning, they're making a plan for what they're doing, here it's immediately before they're going to be doing this work. So it's the time when the rubber meets the road. And here's where they're going to have some real practical questions. And if you're not there to answer them, you could hold them up. You could delay them.
Mike (26:04)
Yeah.
Brian (26:05) I also, like you said, I like to use this as an opportunity to say, here's when I'm available today.
Mike (26:10)
I wake that product owners attend because of the message it helps sends as well. If the PO never goes, is this project important, right? Or team members start to think, we have to show up daily and say what we did yesterday, that that person never has to do this, you know? And we started to get some resentment towards them. So I strongly encourage product owners to attend. I'm like you, that don't require, but my requirement test is always, would I cancel the meeting if this person had a dentist appointment, right?
Brian (26:16)
Yeah.
Mike (26:41)
If the product owner had a dentist appointment in the morning of planning, I'd probably say, can we do it in the afternoon? My product owner can't make the daily scrum because I've got a dentist appointment? well. We're still doing the daily scrum. But you're right. If all of the teams, this will be silly, but if all of the team members were all having dentist appointments, yeah, we'd cancel the meeting. There'd be no point. So.
Brian (26:53)
Right. Yeah, the Scrum Master and Product Owner can't have a daily scrum, just the two of them.
Mike (27:07)
What should we make them do? Let's talk about what to do during the sprint. You talked about kind of ongoing research. So you don't want to do all the research upfront on this.
Brian (27:09)
Right, exactly. Right, no, it's a continual thing, right? I mean, if I'm working on my product and my competitor comes out with a killer feature that's starting to gain traction, I can't do that research upfront. That's something that becomes apparent as the product kind of goes along. So I think it's important that we keep in touch with what's going on in the real world with our product and the competitors.
Mike (27:43)
Mm -hmm. through the marketing, through the market. The thing you had next here was about connecting with customers to hear feedback. I want to share a story on this one because it literally just happened. I told you I was out of the office. I got back like 15 minutes before we wanted to do this recording. And I'd been gone all morning, so I talked to my wife for about five minutes. And she and I had come across some software recently that we're using that looks kind of interesting. It's things like, you know, when you die, who gets access to your Facebook?
Brian (27:57)
Yeah.
Mike (28:18)
password, right? And most of my friends are pretty shifty. So I don't want to give my Facebook password now because they'd probably go post weird things. But I want you know, when I die, I want that to happen, right? And so we're looking at various software that does those things like who do you notify when after you died?
Brian (28:19)
Yeah.
Mike (28:35)
And we signed up with this company. I'm actually going to share the name because I like them so much here in a minute, but let me say why I like them. My wife and I both had interactions with them by email about totally different things. One was a little bug that I came across and then something that I think she was asking about how does the future work. But here's what I love. They contacted her today and said, can we get on the phone with you and hear what you think about our product? They're a fairly new company, I believe. what you think about our product and what you think about how we've, in particular, have like the three tiers of service that we offer, right? You know, this feature, this feature. And I just love that they're doing that, right? Because not as many companies do that as they should, right? As they should. Because I love that company, so I'm gonna mention their name, trustworthy .com. Probably nobody listening needs them, but they are just this kind of like, you know, I don't wanna say like death planning, because they're not like playing your funeral, but it's like.
Brian (29:23)
Hahaha.
Mike (29:28)
Who gets your Facebook account? What bank accounts do you have? So your heirs can figure it out. Right. So, so.
Brian (29:34)
Yeah, yeah, that's great. No, I love having that mission if they're, they have good customer service. Yeah, definitely. Let's, let's mention them.
Mike (29:40)
Yeah, and my wife and I favorably disposed of them, and that just put me over the top with them literally a half hour ago. You talk about checking in with the Scrum Master, about how you as a product owner are doing, but also staying in touch with devs.
Brian (29:46)
That's awesome. Yeah. Yeah, I mean, I think that it's important for us to understand that we are not somehow separate from the team. We are part of the team. So we have the same goal as everyone else, and that's to deliver as much value as we can to our customers. We have a specific role, a responsibility to play in that. But I think checking in, partly I put that on there because. checking with a scrum master. That's something that we have on our scrum master sheet is to check in with a product owner. And I do think that those two need to kind of work hand in hand over the course of a sprint. And on an ongoing basis, kind of touch base to see how are things on your end? How are things on my end? And how can we help each other to kind of achieve our goals here?
Mike (30:24)
Yeah. Yeah, you often notice something about somebody else before they may notice it themselves, right? We've got a couple other meetings that I'll move on to. So let's talk about refinement. Can you share what your thoughts are for a product owner's responsibilities during refinement?
Brian (30:43)
Mmm. Yeah. Yeah, I mean, refinement, I always hesitate to even think about it as a meeting because it's kind of more of a series of activities. And you might have multiple meetings that would need to take place here. But yeah, I think that there's a lot of prep work that goes into. If I'm going to have the stakeholders come in and help me prioritize, I've got to prep a lot of that work. I've got to have the stuff that's ready to go prior to that meeting. I can't just show up and go, let's see what we got in our backlog. And we'll just kind of wing it.
Mike (31:02)
Good point. if What do you think about this product owner? I don't know. Let me think now. Yeah. Did I write that one?
Brian (31:21)
Right. Right. I don't even know what that is. I don't know. Let me read it. Right. That's just going to waste everyone's time and frustrate people. So I think there's a lot of prep that goes into that and prepping to go into anything like estimation. Do we have the right sort of things that are going to be estimated? I don't want to waste my team's time estimating stuff that's maybe really a long way in the future. And I'm not going to look at it for a while. So, you know, I think there's a lot of prep time that goes into that. And I think that, you know, we're at the center, at the focal point of any kind of refinement activity. as a product owner. So that's going to be, I don't really know exactly how those meetings are going to play out for you, but I think that there is some configuration there that you got to plan for.
Mike (32:02)
I'm hearing your message. There is the old boy scout motto, be prepared, right? It's a new product owner motto, right? We'll, we'll steal it from the boy scouts. you have any, that's true. Just don't take away my Girl Scout cookies. So let's talk about the, the sprint review. what do you think a great product owner does then?
Brian (32:06)
Yes, yes. Yeah. Well, that's okay, because there's no more Boy Scouts. So you don't have to worry about that. Right. wow. So this is our event. I really think of this as the product owners event. Yeah, exactly. I think you're the emcee. I think you show up, you host it, you send out the invites for it. What I typically tell product owners is kick it off with kind of a look back at some things that have been done recently by the team. Here's some features that we developed in the past three to six sprints and maybe even show some statistics about the impact those things are making.
Mike (32:30)
you Showtime!
Brian (32:56)
on the product and the market, on the customers. Our customer satisfaction has gone from here to there as a result of releasing these features, those kinds of things. So I think that the meeting opens that way. Then we move into the demonstration of the work and what we've done in that sprint. And yes, I would turn that over in large part to the developers so that they can demonstrate. But then I think it circles back at the end to come back to the product owner to say, all right, let's take a peek ahead. Let's look ahead what's coming up in our product backlog. Here's what our... looking at as candidates for the next sprint. And I think that's really important. It gives the stakeholders a chance to speak up and say, hey, what about this thing that I had that was really important? I don't see that prioritized. I really need that in the next sprint. I want to have those conversations in advance, not after sprint planning, when it's sort of locked in. Yeah.
Mike (33:45)
Tell me about the retrospective. One of the things I noticed you had in there was that you want product owners to attend every retrospective. There's going to be pushback on that from some teams. What's your thought there?
Brian (33:59)
Yeah, my thought there is, again, kind of reiterating that point that we are on the team, we are a team member like anyone else. And again, we have different responsibilities. We have a named kind of set of accountabilities that we have that may differ from others. But I kind of consider it like this. If I'm on a, in the US, we'd say soccer team, but if I'm anywhere else in the world, I'd say football team. If I'm on that kind of a team and I'm the keeper, the goalkeeper. I've got a very unique role, right? I mean, there's a set of things I do that no one else does. I'm allowed to do things that nobody else is allowed to. I'm allowed to touch the ball with my hands. Nobody else is, right? But if there's a team meeting, you're not gonna have a team meeting without your goalkeeper. They're an important vital part of your team. And that's what this is. It's the team meeting to get together to say, how can we get better? How can we improve? What's going on? What's wrong? What's right? And what do we wanna focus on?
Mike (34:36)
Right. Yeah.
Brian (34:58)
So I think it's vital for a product owner to be at every one just because like I said, we're a team member.
Mike (35:04)
I agree. To me, it's always like, if you don't feel comfortable having your product owner at the retrospective, that's the first thing I want to talk about at the retrospective. Right? It would figure out why we're not comfortable with that so we can move past that. I do like here in the retrospective, you talked about having the product owner commit to making progress on the improvement items, which I think is important because sometimes it is product owners who have to improve. Right? So.
Brian (35:31) Yeah. Yeah, I mean, one of the things we'll talk about in class is how the product owner is a vital communication relay point. They are the, I call them kind of the, it slipped my mind. What's the stone that had the different languages on it from Rosetta Stone, sorry. They're kind of the Rosetta Stone, right? Because they speak tech with the developers. They speak. Mike (35:36) Mm -hmm. Rosetta.
Brian (35:57)
business with the stakeholders and they translate across those two groups. So I think, yeah, I think it's important that we're there to try to, if there's communication issues with us and the developers, this is the place to work it out, right? This is the place to say, what do you need from me so that it's more clear the next time I write stories.
Mike (36:02)
Yep. Yeah, that's a good point. What about for the next sprint? What should product owners do this sprint to be ready for the next one?
Brian (36:24)
Yeah, excuse me. Yeah, I think it's important that we really get a handle on what should be prioritized, that we have a good understanding of what's going to be coming up, that we have that idea of what our next proposed sprint goal might be, where we're focused on stuff. And as I said, I want to check in with my stakeholders, especially my key stakeholders, on that prioritization so that it's not a surprise to anyone. I don't want to. I don't want anything to be a surprise when it gets to sprint planning. By the time we circle back around in sprint planning, I want my developers to have looked at these things multiple times before they see it in sprint planning. We've had estimations. We've had discussions about these. So there could have been multiple times we've had conversations about these. So by the time we get to sprint planning, it's not the first time we're looking at these things.
Mike (37:00)
Yeah. Yeah, it should be a surprise.
Brian (37:15)
And that's kind of what I'm trying to allude to here is that there's a series of activities that just are kind of the glue between one sprint to the next sprint. And if we kind of drop that ball in any way, like I said, I can't show up at sprint planning and sort of just say, well, let's see what we got, guys. I have no idea what we're going to do, but let's just take a look. Yeah, I can't wing it.
Mike (37:30)
Right. Yeah, wing it. Yeah, that's not a good approach for things. Brian, you told me a lot of things that product owners should do. I want to twist it a little bit and ask you for one thing product owners should not do before the sprint, during the sprint, before the project, whatever. What's one thing, the one thing you would tell product owners to not do?
Brian (37:57)
Wow, that's such a great question. I think probably the number one thing that I would say is to understand the boundary between the what and the how, and really to try to stay out of the how. What I mean by that is we're in charge as product owners of the what side of the equation. What is it that we're going to be doing? What are we focused on? The developers are in charge of the how. How do we accomplish this? What's the best way to deliver this? And I... I know as a product owner in my past, I've always struggled with that balance of, yeah, but I've got a vision in my head of exactly the way I want it to play out. And I have to kind of rein myself back in a little bit and say, yeah, but kind of remind yourself that that's not really my role here. My role is not to explain exactly how the page is going to need to look and exactly how this feature plays out. If I have no really discernible reason that I have to have it one way over another, right? If there's not like a legal reason or compliance that I've got to do it one way, then I want to as much as possible stay out of the house so that the developers really get to exert their expertise.
Mike (38:59)
Right. Yeah, that's where they're going to be, they're going to be best at. I was describing it as that there's, there is a fine line between what and how, which is why people often will struggle with it. the way I think about it is like every time we dip into that, how at all product owners dip into that at all, they start to kind of take away degrees of freedom from the team. The team has less maneuvering room on how they're going to solve the problem. And great, take away one degree of freedom here and there. It's not going to be the end of the world. Take away too many, and you over -constrained the solution. The team doesn't engage as fully. All sorts of negative things, as you've touched on.
Brian (39:39)
Yeah.
Mike (39:40)
Brian, I want to thank you for letting me take over and turn the tables on you and ask you the question. Since you had made the PDF, I wanted to be the one asking you what your thoughts were on your great PDF that we have for folks. So I'll turn it back over to you. Let it be back to your show now.
Brian (39:41)
Hahaha I... Yeah, no, well, thank you very much. This has been a pleasure. It's been really fun to have to see what it's like on the other side of the table a little bit. So thanks for being willing to do it, Mike, and thanks for being willing to share your insights as we walked through this.

#103: Developer Relations and SQLMesh with Marisa Smith

Join Brian and Marisa Smith as they dive into the world of developer advocacy, the challenges of agile methodologies in data engineering, and the vital role of open-source communities. Discover how to better support and communicate with your developers in this insightful episode!
Overview
In this episode, Brian Milner interviews developer relations expert Marisa Smith to explore the vital role of developer advocates in bridging the gap between companies and their users.
Marisa shares her insights on the challenges of communicating with developers, emphasizing the need to create a welcoming environment for questions and feedback. She also discusses the unique difficulties developers face when implementing agile methodologies, particularly in the realm of data engineering.
They highlight the significance of open-source communities in fostering innovation and collaboration and provide a preview of Marisa's upcoming talk at Agile 2024 on enhancing data pipelines with SQLMesh.
Listen Now to Discover:
[1:08] - Join Brian in an engaging conversation with Dr. Marisa Smith, PhD, Developer Relations Expert, Developer Advocate, and Speaker.
[2:43] - Marisa Smith sheds light on the crucial role of a developer advocate, explaining how they bridge the gap between developers and the wider community.
[3:49] - Brian digs into common mistakes in how we communicate with developers and poses the question: what are we getting wrong in our interactions?
[5:57] - Marisa outlines the hurdles developers face in a Scrum team environment, shedding light on common obstacles.
[12:00] - Marisa explores the hurdles in developer communication, offering insights into improving dialogue and understanding.
[12:55] - Mountain Goat Software offers Working on a Scrum Team, a private class to help Scrum teams foster a team dynamic that supports the whole team, including bridging the gap in communicating with developer teams.
[15:00] - Marisa discusses how SQLMesh has empowered data engineers to streamline their tasks, sparking a sense of 'Marie Kondoing' their work.
[24:11] - Marisa emphasizes the vital importance of open-source developer communities for fostering innovation and teamwork.
[26:51] - Brian shares a big thank you to Marisa for joining him on the show.
[27:50] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[27:54] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
References and resources mentioned in the show:
Dr. Marisa Smith, PhD
Join the SQLMesh Community
Agile 2024
SQLMesh
Working on a Scrum Team
Subscribe to the Agile Mentors Podcast
Mountain Goat Software’s Private Training
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Marisa Smith is a Developer Relations expert who bridges the gap between the community and development teams, addressing problems and promoting open-source software. With a Ph.D. in Computational & Theoretical Physical Chemistry, she has a background in simulating radiation effects in water.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one, the only Marisa Smith with us. Welcome in Marisa.
Marisa (00:13)
Hi, thank you so much for having me.
Brian (00:15)
Very excited to have Marisa with us. If you're not familiar with Marisa, her title is Developer Relations Expert. So right there, that's an episode, right? We could talk just about that. And we'll get into that a little bit more, but there's a lot of really interesting stuff here about Marisa. She has her PhD in theoretical and computational physical chemistry. So...
Marisa (00:41)
Yeah.
Brian (00:42)
Again, wow, right? I mean, this is amazing stuff. She's worked at Streamlet. She was their very first developer advocate there. And she has since, Streamlet's been acquired by Snowflake. And you founded Tobacco Data, is that right?
Marisa (01:07)
Uh, no, I, um, I am their first developer advocate at Tupiqium data. Yeah. No words.
Brian (01:11)
OK, gotcha. Sorry about that. Messed that up. So very, very interesting background. And one of the things that caught our notice, Marisa spoke last year at Agile 2023 and is speaking again this year at Agile 2024. So again, if you're going to come out, I highly recommend you attend her talk. Her talk is called Marie Kondo. your data pipelines with SQLMesh, which I think is really, really interesting. But I'm talking too much, and I want to turn it over to Marisa here. Help us understand developer relations expert and developer advocate. What does that mean?
Marisa (01:59)
Yeah, so I am, what I always say is that I am the person that connects your company to the people who use your product. And it just so happens that the companies that I work for are companies that work in the tech industry. They're building some sort of piece of the tech stack. So the people that use it, their customers are other developer, developers essentially, or technical people.
Brian (02:22)
Yeah, so you're an expert in the...
Marisa (02:27)
in the art of, in the art of like, how do we communicate with other developers? How do we pass that information back and forth between the developers that are making a product and the developers that use a product. And how do we make sure that, you know, we're getting, we're, we're getting the best out of our, out of our users and that they're getting the best out of the technology that we're trying to build for them.
Brian (02:49)
That is so, so interesting. And so I'm sure product owners are listening going, yeah, help me. Help me. I want to understand. How do I talk to developers? So gosh, there's so many directions we can go with this. What do you think people misunderstand most when they try to communicate with developers? What do we get wrong?
Marisa (02:55)
hahahaha Oh, wow, that's a great question. Let me think about this for a second. I think, I think from, from, from my perspective, as somebody who spends a lot of time, like running different communities, especially open source communities, I think that people get the wrong idea in that. Yes, these developers are your customer, but a lot of the time they have very limited time. They come in, they look at, you know, maybe your open source product or, uh, you know, your free version or something that they're trying to see if they can integrate this in their own stack. And I think people can. or companies can come at them a little bit too quickly, a little bit too salesy, right? And then that ends up driving them away. They're like, no, no, no, I'm really not interested in any of this. I'm just trying to figure out if this is the right technology. A lot of developers like to iterate. They try things out, right? And so I think if you come at them too early with, oh, here's our sales process. Here's this, this is how much this costs. It's like, no, no, no, I'm like... way early, I'm MVP POC type of thing, trying to see if I can understand, or if this works with my team, my workflow, my current pipeline, the other technologies that we use, you know, that, that type of thing. I think that's one of the biggest mistakes that you can make, especially when you're talking about open source, which is kind of like my bread and butter.
Brian (04:28)
Right, right. Yeah. And you know, the communication, especially, I mean, because we talk about Scrum and Agile here on the podcast, you know, that relationship between the business side of the house and the developer side of the house, it's almost like, you know, Romeo and Juliet and the two houses, you know, they speak different languages. They want different things. They see the world in a very different way.
Marisa (04:34)
Mm -hmm. Mm -hmm.
Brian (04:58)
And yet somehow these two groups have to figure out how are we going to work together to really deliver something that is valuable, right? So you work with a lot of developers. You talk with a lot of developers. And I know there's lots of different kind of practices and things that are out there that developers are using these days.
Marisa (05:09)
Yes. Yeah.
Brian (05:26)
When you talk to them about something like Scrum, or when that kind of process comes up, what are some of the chief complaints that you hear from developers when they talk about working on a Scrum team? What are they not like about it?
Marisa (05:44)
Ooh, interesting. Yeah, I would say. I would say, I mean, in the area that I'm working in right now, I'm working pretty deep in the data pipelines. So Tobico data runs these two open source projects, SQLMesh and SQL glot. And it's essentially your T of your ETL pipeline, right? We're using SQL, we understand SQL and we're transforming your SQL queries into these tables and we're helping you manage these pipelines as they evolve over time. And so, um, and so I think, you know, in this space, what happens is when you're talking about, you know, working with scrum teams and stuff like that, one of the pieces of agile is trying out new things and iterating. And that can actually be super difficult for a lot of like these data engineers and developers to do, because you have accountability at the end of the day, right? If you're changing up your data, you're mutating some, some SQL query that changes some model that changes your data pipeline downstream. And then all of a sudden. you know, you've pushed it to production and, uh -oh, this data is not what you expected. It's not what you had like originally tested for. And that's because, you know, teams have to work across many different, um, they have many different like iterations that they're working on and many different teams are, you know, making changes potentially simultaneously. And so I think that for, for developers, when you talk about scrum and you talk about agile, particularly if you're talking about like, adjusting tooling or trying out something new again, coming back to this fact that like, you know, they're just there to test things out. They have very limited time and that's because they get stressed out. It's like, well, I don't want to break production. We have to protect production, your production environment as much as possible. And, you know, part of agile and part of doing all these things is trying, trying these new tools, trying these new companies, trying these new methods. And you can get a lot of resistance from that because. they know this method works, they know that they have accountability and they know that production will be fine if they use this methodology that they've set up. Sometimes it can be a little bit of a matchstick thing in the back end.
Brian (07:47)
Yeah. Well, and I mean, just hearing you talk about that and thinking about it, I know one of the big friction points between the business side and the developer side is take SQLMesh. If that's something that my team has never worked with and I have someone on the team who is interested in that and wants to, thinks it might give us some benefits, There's friction there with the product side to say, product has all these things they want, and they want to push these things forward. But I think this bit of adding this to our stack is going to improve things. But how do I communicate that to the business to give us the time to do this? Because it's not directly leading to a feature, but it will improve things moving on. How do you? How do you balance it? How do you have that conversation with a product person or the business side of the house to really say, Hey, this is worthwhile.
Marisa (08:50)
Yeah. Yeah. Honestly, it's super difficult. And I think it's really a balance of, you know, having to have these engineers dedicate some time to new tooling and testing things out. And then once you have done that in their schedule, you know, I don't know how frequently you may want to do it like once a month or something like that, where they, you know, take a day and just review what new is out there. What else should we be looking at? What other tools, what other... You know, with, especially with the emergence of AI and all of that recently, that changes a mile a minute, I think. So, you know, keeping on top of that is, is, is a huge burden on these engineering teams. And so time needs to be dedicated for actually getting that kind of stuff done and the freedom to actually try these things out and do like just a minimum viable product, right? Just a tiny POC with like a little Tinkit data set. And then on, I think there's some.
Brian (09:23)
Ha ha.
Marisa (09:45)
there's some weight of this on the company that's developing these open source products or new tooling, that they have to start communicating and figuring out their business value as well. Because those developers cannot, with this little example, show all of the benefits that you would get. What cost savings do you get? What efficiency savings? What increase in productivity? All of that has to be done by the company and you need to have that ready. so that you can back up your developers that are trying out your product and your open source projects so that they have something to go off of. They're like, hey, look, I made this. It took one week or something like that. And I got it to a place where it's really good and look at all these cool features. And this will make us so much faster in our pipeline. And then here is the company's documentation or case study or whatever it is that says this should increase our productivity approximately this much. And... that these other big companies that are similar to us have this sort of success with it. And, you know, it, I think those two combined can really help alleviate these pressure that the developers feel and give them the time to actually try out new tools, which in many cases they love to do. They love to try new things. They love open source, right. And they will be your best advocates. If you spend the time talking to them, communicating with them and giving them the things that they need to be successful.
Brian (11:12)
Yeah, I would think that's kind of a, there's a duality to, I would imagine your role in speaking with them about your product, because in one case you have to sell them on, hey, look how beneficial this is. This is, you should add this to your stack. But on the other hand, you've got to equip them with the, the, uh, the sales pitch, I guess, that they can then make to their business to say, hey, you should allow us to do this. You should give us the, whether it's finances to do this or the time or the resources to do this, that, you know, it does benefit you as well. So that's gotta be a really difficult part of that communication is kind of, you know, getting people who are not really salespeople, you know, having been a developer, I know I kind of get, you know, the personality type. Uh, and you know, we, we don't want to have to talk to people. We want to be able to put our headphones on and get our work done. Uh, but now, now I'm in the position where if I want to do this thing, I know it is the right thing to do. I've got to convince others and that's not really my strong point. So how do you, how do you help them with that?
Marisa (12:24)
Mm -hmm. Yeah. Yeah, it's definitely a long road. I would say, you know, it's not done in a split second, especially when you're talking about larger companies, like any sort of fan company. They will take a lot of time to make this decision. So you have to be really committed, I think, to each person that you're talking to and each person that you're trying to help get moving with your product to really make them successful. And... For us, what we've been doing recently is we go in and we help them with that communication point, right? Like our developers know our tool the best. And so if there needs be, like we'll stop and we will actually go in and do a presentation to the wider team and be like, okay, you guys have set up this POC. You've tried it out. You really like it. Here are the benefits. Here are, you know, here's how we describe it. Here's how, you know, We have seen other companies succeed with this and we have some decks that are basically ready to go. So we can go in and actually help them with that communication stage as well.
Brian (13:34)
Yeah, that's awesome. Well, then let's, because this is fascinating, and I really enjoy kind of the idea of trying to be an advocate for the developers. But I'm curious as well, with your upcoming talk at Agile 2024, by the way, just I don't think I've said the date, but July 22nd through 26th in Dallas, Texas, go to. AgileAlliance .org. You can find out more information about it. I think I've told everyone here on the podcast, I'm speaking there as well. So come and see both of us in my hometown in Dallas. So Marie Kondo, your data pipelines with SQLMesh. Tell us what was the idea behind this, where you got the idea for this talk, and what it is you're trying to get across in it.
Marisa (14:18)
Thank you. Yeah, absolutely. Well, here's the story. One of our users, I was doing case studies for our, for us, because we need to understand our business value. We need to show people that like they can get this, these, you know, these cost savings, these productivity savings and things like that. So I've been doing interviews with some of the companies that currently use SQLMesh. And one of the, one of the interviewees, we were just chatting and he was like, oh, You know, he brought Marie Kondo up and he was like, yeah, like SQLMesh just brings me joy. It brings joy back to my data engineering. And I'm like, well, wait a minute. What, wait a minute. What do you mean? mean? like, oh yeah. Well, I mean, you know, we spend all of this time. Fretting Fretting about these data pipelines, getting the correct data down the pipeline, getting the business needs on the timeline that they need them, you know, updating your production value or your production environments with, with anything new that's been requested. And.
Brian (15:01)
you
Marisa (15:21)
there isn't really a proper process for data deployments, right? Like for code, you know, we have GitHub, we have Git, we have all these things, right? You make some changes, you save it, you test it out, you make some more changes, you save that, you test that out, right? Like all of these iterations, they create all these versions and these checkpoints. But on the data side of that, there is nothing. It's just like match disks and toothpicks that hold up some of these.
Brian (15:30)
Yeah. Hahaha.
Marisa (15:49)
some of these pipelines, right? And that's become the standard. I'm not saying that this is particular companies that are doing this or something like that. It's pretty much everybody. And all of this falls on top of your DevOps engineers or your data engineers that are a very small percentage of your company. And they're treading through this escalating technical debt, right? Every time you add a new table, every time you add a new dashboard, that's a new backend that they are managing, right? It becomes very stressful for them. And... This individual was saying that he had lost a lot of the joy out of his work and you spend how many hours a day working, right? This is a huge chunk of your life that it's just like, oh my God, I don't want to do this anymore. I don't want to make that change because the pipeline currently works. It's not broken. It's not broken. Don't change that type of thing, right? But this isn't what business is. This isn't what agile is. You're supposed to iterate. You're supposed to make these changes. You're supposed to investigate.
Brian (16:24)
Yeah. Right.
Marisa (16:42)
find new things and find new insights. And you can't do that unless you start changing things. And so he had said that once they started implementing SQLMesh with the different features that it has with this virtual data environments and these data versionings, and we have these data contracts that essentially allow you to turn, have checkpoints for your data and have essentially unit tests for your data. He was like, oh my gosh, now I can not have to worry about it. I can just try something, see if it works. And then if it doesn't, it doesn't matter because I can roll it back super easily and things like that. So that's really where the inspiration came from.
Brian (17:21)
That's awesome. Yeah, that's such a huge hole and it's such a needed kind of component to the stack, as you said, because, you know, I mean, you're right in kind of a programmer world. And, you know, if you're outside of the database world, there's all these tools you can use and put in place and test and see how things are going. But that fear that you have when you work in the database world where if I make the wrong error here, It could mess up all our data. It's not just that it's going to present it in the wrong way, but it could actually damage, which is a valuable asset. It's a hugely valuable asset, the data that the company has, maybe one of their most valuable assets. So yeah, that's an amazing tool. And...
Marisa (18:10)
Yeah. Cool. And these days, yeah.
Brian (18:16)
So this is also an open source project, right? So tell me how that's been interacting with the community on this and working in a corporate environment, but also it's an open source environment on this product that you're a developer advocate for.
Marisa (18:19)
Mm -hmm. Yep. Yeah. Well, I love it. I love open source. As I mentioned before, open source is kind of my bread and butter because Streamlit, you know, was essentially the other end. I've gone from the dashboard side, which Streamlit is basically a free open source dashboarding tool that's built just in Python, to the side of the tables that make that, and the SQL that makes those dashboards possible in the backend. And so this, it's something that I really love about my job because... I've been lucky enough to work with a bunch of tools that are super useful and that people really love, uh, and that they have that they, you know, people who co -founded it, that there are co -founders all came from huge fang companies, right? SQLMesh was basically born out of these data problems specifically to solve them because they had been literally experiencing them at these companies themselves. And they, you know, went out and were like, okay, what's the solution out there? And, you know, uh,
Brian (19:21)
Yeah.
Marisa (19:31)
There's this, there's another company called dbt. They were pretty much the first one on the scene. They've been around for like, I want to say like 10 or 15 years and they changed the space. Like they really did make some huge advancements. But the thing is, is they came at it from a completely different angle than we're trying to come at it because they came at it from the almost like the data science and data analytics side. And they weren't necessarily thinking about future, how big these data sets were going to get with.
Brian (19:52)
Yeah.
Marisa (19:58)
these different like Netflix, Airbnb and stuff like that, right? Their data sets are huge. They're parsing huge amounts of data. And, you know, in the current tools, the systems that you have, you have to refresh your entire data warehouse every time you want to make a change to production. If you have a terabyte worth of data that you're trying to refresh every single time you make a change, that literally, you're just, you're twiddling your thumbs. Your analysts are just like sitting around waiting anxiously to find out.
Brian (20:03)
Yeah.
Marisa (20:27)
you know, if those changes they just made to the sequel is actually viable and good, right? So, sorry, I think I lost. I think they lost the train of the question I got all passionate about.
Brian (20:32)
Yeah. No, no, no, that's fine. That's fine. No, I mean, I was just, I was asking about, you know, kind of the interactivity with the community on that and working with, you know, these open source projects, you know, you have volunteers, you have people who are giving up their time for free, basically to improve your product. That's got to come with a whole just mess of other considerations and concerns and how has that been?
Marisa (21:07)
Yeah, yeah, yeah. So that's been good. And where I had been going with that point was that I've been lucky enough to work with companies and tools that are super useful, that were developed out of pain points that other people have experienced. So that side of things has been really great. When you're trying to develop a community, I just try to make the most welcoming space so that people feel comfortable in asking any sorts of questions. Right? Because that is the only way that you kind of surface some of these things that might've been otherwise hiding. Right? If people are nervous to ask questions, then you're not going to really have a proper conversation around, Oh, well, wait a minute. How did you get to that point? Like what led you to use it this way or to do it this way or something like that. Um, and so, yeah, there's lots of considerations, but we've been lucky enough that the, you know, a lot of our users are very happy with it, but also are.
Brian (21:38)
Yeah.
Marisa (22:01)
because of that, they're very vocal and they are very happy to, you know, take that five, 10 minutes, fill that survey in or meet with me and talk through, you know, a case study or like how they found SQLMesh and how it's going and stuff like that. So I think that the real balance comes in as to how much time do you want to dedicate my time? Do you want to dedicate to doing these interviews and getting this feedback versus Like, oh, we've already got like a pretty large signal that the next feature they need is this. Like, let's just run and do that feature and get that out for them, as opposed to continuing to bog up their time with interview questions or survey questions and bog up my time with it as well. So I think that's more the balancing point is when do you start acting on the signals that you're starting to see from your community versus like just constantly collecting data?
Brian (22:56)
Yeah. And I love your point there about kind of creating that welcoming environment. It's very similar to what we talk about with just teams of the whole psychological safety kind of aspect of it. And if I feel like I can't say something without being made fun of or feel like I'm made to look stupid for my question, then you're right. I don't surface the things that I should, even if it's, you know, just, hey, I'm not sure how to do this and getting help for that kind of thing.
Marisa (23:22)
Mm -hmm. Yeah. And I mean, I feel like with open source communities as well, they're all online. And this is a, I like that psychological safety and I like to try and promote this friendly environment because there's no guarantee that the person on the other end even speaks English. They might be running it through a translator, right? Like you have no idea. So they need to have like that safe place that they can just be like, oh, Hey, I tried this, but I couldn't get it to work. Right. And then that's when you can start to expand and be like, Oh, okay. Well, actually this person is from.
Brian (23:39)
Yep.
Marisa (23:54)
I don't know, like France, they speak French, right? So you're trying to translate kind of back and forth, either in your head or with a tool. And it's kind of like, okay, well, what else can I do to help them? Right? It's like, oh, well, what they need is a more in -depth, like getting started guide, right? We need to add these steps in or put this little note in there that's like, hey, if you get tripped up and you get this error, that's because of this and this is how you fix it type of thing, right? So that you just kind of like fill in those gaps of knowledge.
Brian (24:23)
Yeah. I mean, there's probably so much that we could extract just from the remoteness of the team that you work with, because open source is an area where there is no office. It's not like we all come into the same place. And yet, it works. So for people who think it can't work if you're remote, well, open source is proof that it can. Yeah.
Marisa (24:37)
Yeah. Yeah, absolutely. And not because of that, our team is a hundred percent remote as well. Right. Like our entire Tobacco team works async, right. And we're only able to do that because of different tools and processes that we have put in place and, and that we do have this community and our community is a, is a Slack community. We actually, we could put a link in or something so that people can check it out if they were interested. But, but yeah. And, and that community isn't just about.
Brian (25:11)
Sure, sure, sure.
Marisa (25:16)
that specific tool. And I think that's also another thing that you want to surface when you're talking to developers is that this isn't just a space to ask questions about SQLMesh or SQLGlot, it's a space to talk in general. What are some of the best practices around evolving your data pipelines? What, you know, do you have any questions about your DevOps? Like, you know, what, what are people using for their cloud service provider? Why? Like, you know, did you switch from this to this and, you know, What was your thoughts around that? And, you know, what do people do with a dataset that is, you know, 300 rows and, and like 700 columns, like, how do you deal with this size of data? How do you want to, like, how do others mutate it? Like, do you incrementally load it? So just like try and load in the newest data. Do you only re when do you refresh these, like all these questions and all of this conversation needs to happen because we need to start deciding on a proper process and. DBT had started doing that and we're trying to continue this conversation.
Brian (26:16)
Yeah, I would imagine that's working with the product as well, that that's very beneficial to even product development. Because you can hear from them, even if it's not part of your product, but if you hear those questions about, hey, well, how have you handled this, or what do you do in this kind of scenario, I can imagine that would lead you to maybe new product ideas based off of some of those conversations. Yeah.
Marisa (26:43)
Oh, absolutely. 100%. I don't have like a specific example at the top of my head, but I definitely...
Brian (26:48)
Right. No, no, no. Yeah. Yeah, it could come from this. So it's community, right? I mean, it's just the importance of having that community and not just being, no, we can only talk about this one product here, but no, we're a supportive community and we help each other here. Yeah. Awesome. Well, this is fascinating. And I could talk with you about this for a long, long time. I'm looking forward to your talk.
Marisa (26:55)
Mm -hmm. Mm -hmm. Yeah. Yeah.
Brian (27:16)
So I haven't checked the schedule yet, but I'm gonna, hopefully it's not on one of those times when like, normally, I don't know if you find this as well, but it's like the ones that I start and think, oh, that's the one I really wanna go to, turns out to be the one where you're speaking or somebody who's a lifelong friend is talking at that time. You're like, I can't miss that person's. So I'm hoping that's not the case, cause I really wanna come and hear this talk and hear more about it.
Marisa (27:17)
Great, thank you. Yeah.
Brian (27:45)
Thank you for giving us your time and helping us to understand this, Marisa. I really appreciate you coming on.
Marisa (27:49)
What? Yeah. Thank you so much for having me.

#102: Communicating Agile Transformations with McCaul Baggett

Join Brian Milner and McCaul Baggett as they explore the power of empathy and storytelling in successful Agile transformations. Learn McCaul's five-step approach to effective communication and discover strategies to overcome common pitfalls in organizational change.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner sits down with McCaul Baggett, Chief Agile Officer at CAVU, to discuss the intricacies of communicating change within organizations.
They delve into common pitfalls in Agile transformations and highlight the importance of empathy and storytelling in engaging teams. McCaul shares his five-step approach to effective communication, emphasizing the power of testimonials and spreading awareness.
Tune in to gain valuable insights and practical tools for navigating and leading successful Agile transformations.
Listen Now to Discover:
[1:10] - Join Brian as he welcomes McCaul Baggett, Chief Agile Officer at CAVU and a master of Agile transformation, to delve into the secrets of successful Agile transformation.
[3:15] - McCaul emphasizes the critical role of storytelling in engaging and guiding teams through the process of Agile transformation.
[5:57] - Brian addresses a common challenge in Agile transformations: navigating the unknown and its impact on team dynamics.
[8:01] - McCaul explains how effective communication and a compelling narrative can help teams grasp their value during a transformation.
[10:40] - McCaul advocates for going beyond the basic 'why' by incorporating testimonial narratives to create more meaningful connections.
[14:39] - Brian suggests using these tools to foster empathy, advocating for their use in both top-down and bottom-up approaches when initiating a transformation.
[16:29] - Dive into Mike Cohn's book, Succeeding with Agile, for practical advice on navigating your transformation. Discover strategies for communication, overcoming resistance, and other key aspects of Agile success.
[17:54] - Brian inquires about effective ways to connect with and engage resistant individuals within the team.
[22:49] - Join McCaul and Brian as they discuss the importance of creating specific best practices that suit the unique needs of this particular team and organization.
[28:07] - Brian shares a big thank you to McCaul for joining him on the show.
[28:33] - Join Brian in attending Agile conferences to connect with and learn from Agile experts and peers, fostering valuable discussions and insights.
[29:53] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
[30:35] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
References and resources mentioned in the show:
McCaul Baggett
Communicating Change Made Easy with McCaul Bagget and Tom Bullock
Succeeding with Agile by Mike Cohn
Agile 2024
Subscribe to the Agile Mentors Podcast
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
McCaul Baggett is the Chief Agile Officer at CAVU, specializing in Agile transformations and effective communication strategies. With a focus on empathy, storytelling, and practical tools, McCaul helps organizations navigate change and foster sustainable Agile practices.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one and only Mr. McCaul Baggett with us. Welcome in McCaul.
McCaul Baggett (00:13)
Hey, thanks Brian, really glad to be here.
Brian (00:15)
Very excited to have you. For those who aren't familiar with McCaul, McCaul is the chief agile officer at Cavu. He has been working in transformations for quite a long time doing some large-scale transformations at different organizations. One that he is allowed to publicly mention is John Deere, but there's others that he's been a part of as well. You know companies are funny that way. They don't always necessarily want you to publicize things for some reasons. I don't know why.
McCaul Baggett (00:43)
Yeah.
Brian (00:44)
We were joking about that earlier. But I wanted to have him call on because we were both at the Agile 2023 conference, and I saw him on the agenda, and it was one of those sessions I didn't get a chance to go to, unfortunately, but really thought it was an interesting topic. I wanted to have him come on and kind of chat with us a little bit about this. So his topic was about communicating change and communicating change in an easy way, you know, kind of making that an easy process. So let me start there with you, McCaul, on this is, what do people get wrong when they're going through a transformation and we make the decision to go through a big change in our organization? What are some of the common pitfalls organizations fall into when they make that decision?
McCaul Baggett (01:34)
Well, let me start by saying it wasn't me solely that was doing the talk. I did have some partners there with me. And if you look it up, you should definitely speak to them as well or look them up as well. Dana Dismukes is a transformation lead for Dell. Tom Bullock is the chief storyteller for Scrum Inc. And really the academics of the talk came out of Tom's brainchild. But through my work, I got a chance to apply it. And it was precisely because of this very issue, the ch- the- non-working approach that many organizations take to communicating about change. There's a tendency in a lot of change management structures to discuss the need for communication, but as Agilists, we don't inherently do a lot of study of the nature of communication. And so I would say probably the biggest, most common error that people in a transformation of any kind and most close to my experience in Agile transformations make in communicating about change is going about it from a way that is, from the perspective of trying to reassure their teams, their departments that this is something that has leadership endorsement by communicating from the top down. I mean, please forgive the hierarchical metaphor, but getting some senior leader to say, hey, this is gonna be great, you can do it, we're gonna do this. When in fact, the most effective way to communicate to someone, especially someone who's not fully bought in, is by telling them a story of someone who is like them, has experience like them that they can relate to. And that storytelling perspective is what we talk about in this talk, Communicating Change, maybe.
Brian (03:16)
Yeah, there's a lot just in there to unpack. I mean, just the idea, thinking about, I've talked with a lot of organizations and a lot of people have come through classes and stuff that I've talked with who are going through changes like this, but then they're not really even sure how much their leaders are on board with this. They just, they have some layer of management who says, yeah, this is what we're gonna do, but do the people at the top really feel that way? Do they even know what it is that we're doing?
McCaul Baggett (03:34)
Sure. I mean, that's even tougher. I would find it hard to even consider it a true transformation if you can't be sure your leaders are bought into it. But you're not wrong. It is stunning how often you get these folks that you run into and they say, my leadership may be willing to do this. I teach a lot of Scrum at Scale. And so we talk a lot about executive Metascrums and executive action teams and prescriptions about how involved the leader should be. And people will sort of stop and say, wait, you want a leader to meet about team obstacles every day? And I say, yeah, or however long those executives are willing to let their teams go without support to removing their obstacles. Like, what is it that they're doing that's more important than clearing the impediments for their teams? But that does tend to be the perspective is, I don't know if my leaders even bought into this change. That's tough.
Brian (04:34)
Yeah. Yeah, it is. And I think that speaks to some of the fundamental flaws, I think, that people have with transformations before you even get to communicating, right? Just do we know why we're here? Do we know what it is we're trying to do? Those kinds of things. I like to focus on the communication, though, here because communication is such a
McCaul Baggett (04:46)
Yeah, that's true.
Brian (04:56)
delicate beast. I mean, it just, you know, when you're trying to speak with another human, even if it's just within your team, you know, it's difficult because we're different personalities and we have different backgrounds and everything else, much less when you're talking about it over an entire organization. I would imagine, and you, I mean, correct me if I'm wrong on this, but I would imagine that one of the biggest sources of kind of consternation or, you know, anxiety I think when these kinds of things happen is the unknown, just not really understanding how do I fit in and what does this mean for me.
McCaul Baggett (05:33)
Yeah, I think you're absolutely right. Sometimes it's phrased that it's termed what's in it for me. And I think that's the wrong perspective to take. People aren't often necessarily, people are not always looking for some kind of payoff for the transformation. They don't need to know sort of what they get out of it. But I think that you really put your finger on a lot of the reason that we see trepidation with a transformation is because it implies that
Brian (05:38)
Mmm.
McCaul Baggett (06:00)
Business as it had been occurring before was not acceptable. What you'd been doing previously was not good enough. And now we need to get you to do it another way. That inherently sort of fundamentally starts with a position of questioning whether or not your position is stable. And that gets, you get some amygdala hijack stuff going on. You get the brain started worrying about existence, not just change. So you're right, contextualizing.
Brian (06:26)
Yeah.
McCaul Baggett (06:29)
your communication about this is really important. And I think taking a perspective of empathy and meeting especially resistance in a change environment, a changing environment, meeting resistance with an attempt to understand the perspective really fundamentally underpins any successful communication you're gonna have about change management in general, but communication in particular.
Brian (06:52)
What do you think about that, McCaul? I mean, if you're a leader in that kind of organization and you recognize this and you see, people are gonna, I'm gonna send people into a little bit of a panic, right? Because you're right, there's no way that I can hear that message, hey, we're gonna do things differently than the way that we've been doing them without kind of self-internalizing, well, that means that something I've been doing has not been acceptable, it's not been good enough, it's not been what the organization needs. How do you communicate that in a way to say, no, it's not you, right? It's kind of a process thing. It's not that you did anything wrong. It's that we found this is a better way of working.
McCaul Baggett (07:30)
Yeah, so I think starting with that fundamental basis of why this is occurring is really key. But even before you get to the communication about why, it's really important to figure out who it is you're speaking to. So going back to that sort of, that empathy piece, there is a need to get that communication about, okay, it's not that you did anything wrong. and here are the reasons why we're doing it, that is the message we're looking to communicate. But at a communication level, like understanding even how to begin that communication really requires us to take a step back so that we can consider the people we're telling that story to. So just to connect this to the topic that actually came up in the talk about how we do that communication, it's really fundamentally about, and just a quick aside about that talk. So in the Agile 2023 conference, we actually applied for a longer workshop, like 120 minutes, 160 minutes, one of the long time boxes. And they'd come back to us and said, why don't you do one of these 30-minute segments? So we really pared down a lot of the things that we wanted to say. And so to connect back to what really, what emerged was actually, it was actually probably a better talk than if we'd had a longer period of time to do it. We just, we had to cut everything until we could come back with just,
Brian (08:36)
Yeah. Hahaha. Mm.
McCaul Baggett (08:58)
the real good nuggets. And what stayed was this. In order to communicate effectively when you're going through any kind of change management process, first of all, having a change management process and a plan for how you're gonna manage that, that's your beginning. But to get a little bit more particular about how we communicate about that change, there is one technique which we agreed was probably the thing to focus on so that it would be most universally helpful. in any stage of a transformation that was going on. And that was creating a, finding a way to create a narrative, a personal narrative that could connect to the various people that you're trying to connect to, right? So to create a testimonial. And so we spent our time in that talk discussing how to really get a useful testimonial. And then once you've... got that how to do something useful with it. And we outline kind of five steps for how to think about this. Brian, tell me if I'm getting too deep or you kind of want to... Okay, cool. And I don't know that these are the only five steps. We try to make it easy to remember. The takeaways that we were trying to give were, you have to be first thoughtful about what it takes to make a compelling testimonial. So this is where I mean, you can't start with why.
Brian (10:00)
No, no, this is awesome. Go for it.
McCaul Baggett (10:21)
we're doing this, you have to start with who you're speaking to about why. Because the why shifts. If you're speaking to stakeholders, there's one why. And if you're speaking to the organization, to your employees, to the people that are doing the work, it's not that the why is different, but the way that you talk about it may be different. So once you know what it's going to take to make the testimonial, the next step would be to think about how you can work. how you can set yourself up ahead of time to maximize the potential to make an impact with your audience, to plan. how you're gonna get the story, the testimonial that's gonna resonate. Which is the story that I wanna tell? So fundamentally what we're doing here is we're assuming that, testimonial, this is only one way to communicate, but it's a fairly useful one universally. If you're going to try to get that testimonial, what are the questions that are gonna be useful to the who that you've identified ahead of time? What is the story you need to find to tell? Then step three is actually. having the conversation. So you've already done a lot of pre-work ahead of time before you even begin the process of the discussion. And then once you've started the discussion, once you've got it, using that testimonial, which is typically recorded kind of like this, grounding that in a way that doesn't sound overly positive and really connects with reality, and then using what you've got to spread that awareness as broadly as possible. So five steps. Know, think, get. ground and grow. I don't know if that's a useful mnemonic of any kind, but that's what we came up with.
Brian (11:59)
That's awesome. No, like I said, easy to remember. Just a few things to kind of keep in mind there. Yeah, I love the concept of telling it as a story, that we're not just, because that makes it much easier for me to see myself then fitting in there. Like we talked about earlier, right? If I have a fear of, oh my gosh, does this mean that I'm gonna lose my job? Does this mean that I'm gonna have to... McCaul Baggett (12:03) Yeah, just five steps.
Brian (12:24)
now do something that's very different from what I've been trained for or what I'm used to doing or what I wanna do as a career, telling it as a story can kind of allow me to see myself in the story.
McCaul Baggett (12:37)
You are exactly right. Not only does it allow you to do that, we as humans are wired to do that very thing. We do it all the time. In fact, when you're listening to a podcast like this, you'll often sort of have the sense that you're sitting at the table, thinking through, like you're literally exercising pathways in your brain as if you were participating in the conversation. And that direct involvement allows you to mitigate some of the inherent resistance that you. that you find, that amygdala hijack, that fight or flight response is not present because you're following along in a story, hopefully about a successful element of the transformation. So you really engage that piece right from the very beginning.
Brian (13:20)
Yeah, I love this and understand to the listeners as well, right? I mean, we're speaking at like a neuroscience level here and trying to understand that, you know, the preparation that needs to be made so that, uh, like McCaul is saying, there's not that amygdala hijack going on of just saying, uh, oh my gosh, I'm panicked. I can't get past this panic. Uh, you know, in my, that's going on in my head that has to be stripped away. That has to be. resolved so that now I can start to learn, now I can start to see and form, like you said, the new pathways. And that is, you know, physically what's going on. We're forming new connections in our brain to say, oh, I've never seen it this way, but let me try to make this connection and see it a different way.
McCaul Baggett (14:10)
Yeah, not only is it important to do that, we as humans, now I'm stepping a little far beyond my training, so I'll be careful. My understanding is that fight or flight response really lives in an entirely different system, in the limbic system of the brain, much earlier part of the brain. And in order to engage the neocortex at all, or in any significant way to create those
Brian (14:21)
Ha ha ha.
McCaul Baggett (14:39)
pathways to be able to see a perspective of the other than our own, we have to kind of dampen that limbic response, that fight or flight. Will I, won't I have a means to feed myself beyond this space? Am I safe before we can start to begin that conversation, to begin that connection with someone we want to connect to?
Brian (14:59)
Absolutely. And I think this applies not only, I mean, we started in kind of approaching this from sort of a high level top down, like you said earlier. But I think it applies even if you're a Scrum Master, or maybe you're part of a small group in the organization. Maybe you are in an organization that's not agile in any way, but you've gotten permission to have a pilot, to just have a pilot team.
McCaul Baggett (15:08)
Sure.
Brian (15:28)
and your desire is to grow this in the organization, or maybe they're doing it poorly and you wanted to have one pilot team that does it the right way so you can start to spread this out to other places. All this applies, I think, to you as well because you're gonna be communicating this and you're gonna encounter the same resistances, right? You're gonna have the same kind of skepticism. You're gonna have the same kind of possibility have someone have amygdala hijacks going on thinking, Oh my God, what's this guy doing? What's this woman doing? Why is she trying to make these big changes in the organization? Is she gonna try to change my job? Yeah, am I under threat? So while we started top down, I think it applies bottom up as well. They're all principles I think we have to think through before we even start to try to communicate with this.
McCaul Baggett (16:05)
Yeah, am I under threat? Oh, absolutely. I mean, any good scrum master is gonna be thinking and hopefully practicing their ability to deal with any tense conversation. And so that limbic engagement, that epinephrine and adrenaline start coursing through the brain. And you can see it in many people when you're looking at group dynamics, regardless of large or small group dynamics, but any group. that shutdown of the ability to really process new information and assimilate it, you have to start by working past the threat. You have to get people beyond that sort of defensive place before the conversation can even begin. Yeah, I agree.
Brian (17:01)
Yeah, yeah. Awesome. Well, in how we're talking about this, I kind of had this one scenario in mind I wanted to kind of run by you because I know I've encountered this before. I know, you know, I've encountered this in classes before. So I'm curious kind of how this communication approach would kind of adjust for this kind of individual. But what about the person who just sort of is crossing their arms
McCaul Baggett (17:11)
Sure, hit me.
Brian (17:28)
And they kind of take the approach of, ah, this is a fad. It's not so much as an active, hey, I'm gonna really counteract you and go against you to try to dispreview, but I'm just gonna, you know, I'm not budging. I'm gonna stay here, because I know this is a fad and it's gonna change eventually back to the way I wanna do things. So you do whatever you wanna do, but you know, I'm not gonna get on board with you because. I've seen lots of things come and go on this is just another
McCaul Baggett (17:59)
I think that takes a couple of forms. Certainly some of those, and particularly when I've been asked by an organization to come and do training, you get a lot more of those because, nope, they didn't raise their hand to come and join a public class or something. I think there's really two significant flavors of that engagement. One is, as you described, someone who's just sort of like passively waiting for this to sort of blow on by. And that's a lot more tricky than the one that's actively pushing back. By far, I prefer someone who's willing to stand up and say, this is not going to work here and here are the reasons why. Because to come into the space of someone who is not choosing that engagement is inherently threatening. So you've picked a very challenging person to get through to, um, because directly calling them out and being like, Hey, Brian, you've been really quiet. What do you think of what's going on? when they were not inclined to share that, sort of already starts to engage that, am I prepared to risk saying out loud what I think is gonna happen? And it also, it could inherit, it could just by the nature of asking them to speak out loud that they don't believe in what's going on around them, sets them apart from the rest of the group and could mean that makes them something of a target if they don't feel like their culture is a safe place to speak. So, That is your problem Often I have found that a testimonial based approach, one where you can tell someone's stories about someone in a similar position, not stories about why this is going to work from a leadership position, but a testimonial based communication campaign is one of the best ways to reach folks just like this. You don't need to directly address them. You don't need to confront them. It's fine. If you're not, if you're not buying this, that's okay. Why don't I tell you about where it's happened elsewhere? And frankly, that thing is one of the things that training in person used to be so great for, because you could stand away and kind of watch these people who weren't necessarily bought in, sit back and just study what was going on in front of them. It wasn't being forced on them. They could just sort of watch their teams and you'd do something silly like.
Brian (19:58)
Yeah.
McCaul Baggett (20:17)
play any number of the Agile games that are meant to demonstrate things like small batch processing or teaming, right? Team dynamics and that joy that human collaboration and competition can bring in a really small scale in a very short amount of time and like a magic trick you could be like was that fun? Was folding these paper airplanes and throwing them across the room fun? And they'd be like yeah it was fun it's paper airplanes whatever I'm not working and then you could take a step back and say okay Was it fun because you just love folding paper airplanes or was it fun because you were making connections with people that you don't get to do in your daily job? And just sort of, again, the story here is, look what's over there. Look what this says about the nature of communication. It's not testimonial based per se, but it is lighting that fire, that inspiration that I always loved about training. And it's not just in person, but it really... I do miss that about in-person training because you could really connect really well.
Brian (21:19)
Yeah, I mean, we're talking about communication in general and we can't escape the Agile Manifesto comment about it. It's best done in person face to face, right? So it doesn't mean you can't in another way, it just means it's best that way and it works easiest that way, right? Yeah, I completely agree. Yeah, I just wanted to just, go ahead.
McCaul Baggett (21:28)
That's right. That's right. I'm sorry. Not to go too far off topic, though, but to that very point, we see this request of many executives later, the return to the office movement being another form of, is that the best way to communicate? Yeah, it is. Is it the only way to communicate? Should we be seeking that to the detriment of our work forces at scale? And there are many reasons that people are choosing to encourage their. employees to come back to the office. But I think part of that is because leadership is also far easier in person. So we're missing some opportunities for leadership to understand how to lead remote teams and may have caused that sort of same challenge. Anyway, another topic.
Brian (22:23)
No, no, I agree. And I think that part of that as well is just kind of the general whole. I've talked about this a couple of times in the podcast where we, we seem to be stuck in a cycle of trying to find out what is the way to do something versus what is the way for this team, for this organization to do something. There's lots of data out there that we can get, can inform us. Just like if I'm a product owner. There's lots of data that can inform me about the market, but ultimately I've got to make the call about what's right for us to do next. Same thing with the organization, same thing with the team. What's going to work in this instance?
McCaul Baggett (23:03)
Absolutely. It's probably one of the biggest challenges that I think, uh, when we see transformations, not even transformations, when we see an agile, um, enthusiast really go off track and good. I did it for sure when I was a new scrum master. Like this is how the scrum guide says we're supposed to do things and we're not doing these particular things. We need to do scrum the right way. that sort of the willingness to take a step back and say, well, there are a lot of better practices. Is there a best practice in our case that is true? Actually, the challenge is not, is there a better practice in all cases? And almost certainly not, but there may be a better practice in our case, even a best practice in our case, but you have to be willing to let go of the dogma of this is the way it's meant to be, and instead seeking, seeking to be informed by these, yes, science-based studied practices. It is better to be in person, but let's not fire all our remote employees. Let's, let's figure out another way or let's make teams that can figure out other ways to do it.
Brian (24:11)
Yeah, absolutely. Yeah, we're in an interesting time, I think, as far as that's concerned, because like you said, it's the dogma, I think, of pragmatism and what's gonna work best in this scenario. Yeah, I struggle a lot in classes, even, when people will bring up certain topics, to ever say always, that this is always, it should always be this way.
McCaul Baggett (24:22)
Yes. Yes.
Brian (24:36)
Because I don't know, I frequently will say things like, my experience has been, what I have seen is this, but that's just my experience. And that's a limited set of experiences. You have to line that up against what you've experienced and what your organization is going through and say, hey, does this sound similar? Are we seeing those same things? Are we not seeing those same things? There are best practices. There are some things that we could say, yes, this... And a lot of situations will work best in this way, but not all. And that's where it takes experience. That's where it takes somebody who's been there before to know.
McCaul Baggett (25:16)
Well, yeah, and a lot of this grew up in a very particular environment, right? So Agile practices, many of the ones that we've adopted, grew up through software, and through software in North America. So one of the things that I've been passionate about, and one of the reasons that I've pursued the career that I have is because a lot of the Agile community looks like you and me, right? So if you take into account not only are these the, quote,
Brian (25:29)
Ha ha.
McCaul Baggett (25:43)
but it's for teams that tend to look like you and me, tend to live in North America, and tend to be working on software. And that's such a narrow area that we're foolish to assume that such a thing as best practices have been codified yet.
Brian (25:58)
Yeah, no, and please, for the listeners, don't get me wrong because if you listen to the show, you know I'm a geek for the data. And I love being able to have really hard scientific data that you can look at and say, hey, studies show that this is how you do this, but you gotta be cautious about asking, was that a rigorous scientific actual study or was this just an internet sampling?
McCaul Baggett (26:13)
Yes.
Brian (26:26)
That's not a scientific study. That's just kind of gathering people together and saying, hey, if this group of people who choose to respond to this, what do they think about something versus something else? But you're absolutely right. You have to understand the basis of where this comes from. And the basis of where we get a lot of our stuff is people who look like you and me, who have been working in the software industry for kind of the time we've been working in the software industry. So things have changed.
McCaul Baggett (26:50)
Yeah.
Brian (26:53)
cultures change, cultures bring different dynamics into things. And what works for my team of five, six developers based here in Dallas, Texas, is going to be very different from my team that I have five people in India and three people here, or even all the team is in India, or all the team is in Malaysia, or all the team is in Saudi Arabia or Ireland. I've worked with teams all over Israel.
McCaul Baggett (27:09)
Yes.
Brian (27:23)
You work with teams in different cultures and you have to understand what the playbook I used for that last team ain't gonna work for this next one because they're different people.
McCaul Baggett (27:32)
I heard the term coined radical pragmatism. It was, JJ Sutherland said it. And it was, it is precisely what we should be shooting for. Radical pragmatism informed by the best data, informed by the best science, and then immediately thrown away when it's not applicable to the situation we're in. Yes, these are the ladder, the rungs, the steps to head in the direction we need to be headed, probably, but let's evaluate them for ourselves and reevaluate.
Brian (28:02)
Yeah, if you're gonna go buy a car, you're gonna do your research, you're gonna figure out what gets the best gas mileage, blah, right, all this stuff. But then you're gonna get on the line, you're gonna test drive and go, I just like the way this feels. Ha, ha, ha.
McCaul Baggett (28:12)
That's right, test drive the car, yes, for sure.
Brian (28:16)
Awesome. Well, this has been a great conversation. I really have enjoyed having you on, McCaul. And yeah, thank you for kind of sharing kind of some of the wisdom in there from the talk. I know we, you know, the talk was not long and we have not long to kind of dissect stuff here in our podcast, but I appreciate you making time to share with us.
McCaul Baggett (28:36)
Absolutely, Brian, this is a pleasure. And if you ever need somebody to shoot the breeze with again, give me a call.
Brian (28:42)
I will take you up on that.
McCaul Baggett (28:43)
Thanks.