Easy Agile Podcast Ep.25 The Agile Manifesto with Jon Kern

"I really enjoyed speaking with Melissa Reeve, VP of Marketing at Scaled Agile about how non-software teams are adopting a new way of working."

It's more important than ever to be customer-focused.

We talk about the danger of 'walk-up-work' and how to avoid this through proper sprint planning.

Melissa also gives an update on how agile is spreading to non-technical teams.

‍

‍

‍

Transcript

Sean Blake:

Hello everyone. And welcome to the Easy Agile Podcast. We have a really interesting guest with us today. It's Melissa Reeve, the Vice President of Marketing at Scaled Agile. We're really excited to have her on today. Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework. In other words, SAFe and its mission. She also serves as the practice lead for integrating SAFe practices into marketing environments. Melissa received her Bachelor of Arts degree from Washington University in St. Louis, and she currently resides in Boulder, Colorado with her husband, chickens, and dogs. Melissa, thanks so much for joining us on the podcast today.

Melissa Reeve:

It's such a pleasure to be here. I really appreciate it.

Sean Blake:

Great. That's great. I really like your enthusiasm straight off the bat. So what I'm really interested in hearing about, Melissa is a little bit about how you got to where you are today. What have been the highlights of your career so far and how as a marketer, did you find yourself in the Agile space?

Melissa Reeve:

Well, thanks for asking. And I have to tell you, but just before the podcast my husband knocked on the door and he was all proud because we just got a new set of chickens and one of the chickens had laid its first egg. So that's been the highlight of my day so far, not necessarily the highlight of my career.

Sean Blake:

So you'll be having scrambled eggs and eggs on toast probably for the next few weeks now.

Melissa Reeve:

I think so. So back to the career, I really fell into marketing. My background was in Japanese literature and language. And I had anticipated this great career and international business in Asia. And then I moved out to the Navajo Indian Reservation and just pivoted. Found my way into marketing and found my way into Agile right around 2013 when I discovered that there was an Agile marketing manifesto. And that really was a changing point in terms of how I thought about marketing. Because up until that point, it really considered marketing in what's termed waterfall. Of course, marketers generally don't use the term waterfall.

Melissa Reeve:

But then I started to think about marketing in a different way. And when I came across Scaled Agile, it brought together so many elements of my career. The lean thinking that I'd studied when I studied in Japan and the lean manufacturing, it was Agile marketing that I'd discovered in 2013 and just education and technology have always been part of my career. So I really consider myself fortunate to have found Scaled Agile and found myself in the midst of scaling Agile into both enterprises, as well as marketing parts of the enterprise.

Sean Blake:

Oh wow, okay. And I noticed from your LinkedIn profile, you worked at some universities and colleges in the past. And I assume some of the teams, the marketing teams you've worked in, in the past have been quite large. What were some of those structures that you used to work in, in those marketing teams? And what were some of the challenges you faced?

Melissa Reeve:

Yes, well, the largest company was Motorola. And that was pretty early on in my career. So I don't think I can recall exactly what that team structure is. But I think in terms of the impediments with marketing, approvals has always been an issue. No matter if you're talking about a smaller organization or a larger organization, it seems like things have to go up the chain, get signed off, and then they come back down for execution. And inherent in that are delays and wait states and basically waste in the system.

Sean Blake:

Right. So, what is Agile marketing then and how does it seek to try and solve some of those problems?

Melissa Reeve:

Well, I'm glad you asked because there's a lot of confusion in the market around Agile marketing. And I can't tell you how many news articles I've read that say marketing should be Agile. And they're really talking about lowercase Agile, meaning marketing should be more nimble or be more responsive. But they're not really talking about capital-A Agile marketing, which is a way of working that has principles and practices behind it. And so that's one aspect where there's confusion around Agile marketing.

Melissa Reeve:

And then another aspect is really how big of a circle you're talking about. In the software side when someone mentions Agile, they're really talking about a smaller team and depending on who you talk to, it could be anywhere from five to 11 people in that Agile team. And you're talking about a series of teams of that size. So when you're talking about Agile marketing, you could be talking about an individual team.

Melissa Reeve:

But some people, when they're talking about Agile marketing, they're talking about a transformation and transforming that entire marketing organization into an Agile way of working. And of course, in the SAFe world, we're really talking about those marketing teams that might be adjacent to a SAFe implementation. So, I think it's a good question to ask and a good question to ask up front when you're having a conversation about Agile marketing.

Sean Blake:

Okay. Okay. And for those people that don't know much about SAFe, can you just explain, what's the difference between just having a marketing team now working in a capital-A Agile way, and what's the difference between an organization that is starting to adopt Scaled Agile? What's the difference-

Melissa Reeve:

Sure.

Sean Blake:

...between those?

Melissa Reeve:

Yeah. So what software organizations found is that Agile teams, so those groups of five to 11 people, that way of working works really well when you have a limited number of software developers when you started to get into the world's largest organizations. So I think of anybody on the Global 2000, they might have tens of thousands of software developers in their organization. And in order to leverage the benefits of Agile, you needed to have cadence and synchronization, not only within a team, but across multiple teams up into the program level and even the portfolio level.

Melissa Reeve:

And the same holds true with large marketing organizations. Imagine you're a CMO and you have 6,000 marketers underneath you. How are you supposed to get alignment to your vision, to your strategies that you're setting if you don't have a way of connecting strategy to execution. And so the Scaled Agile Framework is a way of taking those Agile practices across multiple teams and up into the highest levels of the organization so that we're all moving in a similar direction.

Sean Blake:

Okay. Okay, I think that makes sense. And from a software team's point of view, one of the benefits of Agile is that it helps teams become more customer focused. And many would argue, well, marketing has always been customer focused. But have you found in your experience that maybe that's not so true? And when marketing teams start to adopt Agile, they realize what it really means to become customer focused.

Melissa Reeve:

Yeah. I mean, you raised another great point because I think most marketers think that they're customer focused. Like many things in the world, the world is a relative place. So you can, in your mind, in theory, be thinking about the customer or you can be actually talking to the customer. So I just finished what I call the listening session. And it was during our hackathon, which is our version of an innovation, couple of days worth of innovation. So it was eight hours on a Zoom call with somebody South Africa. Just listening to her experience and listening to her go through one of our courses, slide by slide, by slide, explaining what her experience was at each step of the way.

Melissa Reeve:

So if you think about somebody who is sitting in a large enterprise, maybe has never met the customer, only knows the customer in theory, on one end of the spectrum. And you think about this listening session on the other end of the spectrum, you start to get an understanding of what we're talking about. Now, your question really pointed to the fact that in Agile practices, you're thinking about the customer every time. In theory, every time you write a story. So when you write a story, you write the story from the perspective of the customer. And I would just encourage all the marketers out there to know the customer personally. And I know that's not easy in these large organizations. It's sometimes hard to get face time with the customer, but if you aren't speaking directly to a customer, chances are you don't actually know the customer.

Melissa Reeve:

So find a way, talk to the sales folks, get on the phone with some of your customer service representatives. Go to a trade show, find a way to talk directly to the customer because you're going to uncover some nuances that'll pay dividends in your ability to satisfy the customer. And when you go to write that story again, it will be even more rich.

Sean Blake:

Oh, that's really good advice, Melissa. I remember from personal experience, some of these large companies that I've worked in, we would say, "Oh, this is what the customer wants." But we actually didn't know any customers by name. Some of us personally were customers, but it's not really the same thing as going out and listening to people and what did they find challenging about using that app or what do they actually want out of this product? So there's a huge difference, isn't there, between guessing what a customer might want or should want? And then what their day to day actually looks like, and what are the things that they struggle with? That's hugely important.

Sean Blake:

For someone who's in one of these big companies, they're in a marketing team, perhaps they don't have the power or the influence to say, "Okay, now we're going to do Agile marketing." What would your advice be for someone like that, who can see the upside of moving their teams in that direction, but they don't necessarily know where to start?

Melissa Reeve:

Well, there's a philosophy out there that says take what you can get. So if you are just one person who is advocating for Agile marketing, maybe that's what you can do is you can advocate. Maybe you can start building alliances within the organization, chatting casually to your coworkers, finding out if you have allies in other parts of the organization and start to build a groundswell type movement.

Melissa Reeve:

Maybe you can build your own personal Kanban board and start tracking your work through your own Kanban board. And through visualizing your work in that way, it's a little bit harder now that we're all remote, but should we get back into offices somebody could in theory, walk by your cubicle, see your Kanban board and ask about it. And now you might have two people using a Kanban board, three people. And really start to set the example through your mindset, through your behaviors, through your conversations in order to start getting some support.

Sean Blake:

Oh, that's really good. So be the change that you want to see in the organization.

Melissa Reeve:

Exactly.

Sean Blake:

Okay. Okay, that's really good. And when these companies are moving towards this way of working, and then they're looking to take the next level, let's say it starts in the software development teams and then say marketing is the next team to come on board. How does it then spread throughout the whole organization? Because I know from personal experience, if there's still that part of the organization that's working anti-Agile it actually still makes it really difficult for the Agile teams to get anything done. Because there's still the blockers and the processes and the approvals that you need to go through with those other teams. And I guess SAFe is the answer, right? But how do you start to scale up Agile throughout the whole organization?

Melissa Reeve:

Sure. And what you're talking about is really business agility, is taking the whole business and making the business Agile. And you pointed out something that's key to that, which is once you solve the bottleneck and the impediments in one area of the business, then it'll shift to another area of the business. So the advantage of business agility is that you're trying to keep those bottlenecks from forming or shifting. But what a bottleneck essentially does is it creates what we call a burning platform. So it creates a need for change. And that's actually what we're seeing in the marketing side is we've got these IT organizations, they're operating much more efficiently with the use of Agile and with the use of SAFe. And what's happening is the software teams are able to release things more quickly than the teams that are surrounding them, one of which could be marketing.

Melissa Reeve:

And so now marketing is incentivized to look at ways of changing. They're incentivized to take a look and say, "Well, maybe Agile is the answer for us." So let's just say that marketing jumps on board and all of a sudden they're cranking along, and except for that everything's getting stuck in legal. And so now legal has a case for change and the pressures on legal to adopt it. So there is a way to let it spread organically. Most transformation coaches will understand this phenomenon and probably encourage the organization to just go Agile all in, obviously not in a big bang kind of way, but gradually move in that direction so that we're not just constantly shifting bottlenecks.

Sean Blake:

Okay. Okay, that makes sense. And when these companies are trying to build business agility across the different functions, are there some mistakes that you see say pop up over and over again? And how can we avoid those when we are on this journey of business agility?

Melissa Reeve:

Yeah. So I feel like the most common mistake, at least the one that I see the most often in marketing, although I've seen it in software as well, is people thinking that the transformation is about processes or tools. So for example, in marketing, they might adopt a tool to "become more Agile." Maybe it's a Kanban visualization tool, or maybe they're being suggested to adopt another common ALM type tool. And so they adopt this tool and they learn how to use it, and they wonder why they're not seeing big improvements.

Melissa Reeve:

And it's because Agile at its heart is a human transformation. So we're really taking a look at in trying to change the way people think. One of the topics I speak on is the history of management theory. And while it sounds pretty dry, in reality, it's eye opening. Because you realize that a lot of the habits that we have today are rooted back in the 20th and 19th centuries. So they're rooted in assembly lines. They're rooted in French management theory, which advocated command and control.

Melissa Reeve:

They're rooted in classism. There was a management class and a laboring, and the management class knew the one best way of doing things. So more than a process, more than a tool, we're talking about transforming this legacy of management thinking into a way that's appropriate for today's workers. And I feel like that's the number one mistake that I see organizations making as they're moving into transforming to Agile, an Agile way of working.

Sean Blake:

Mm-hmm (affirmative). Okay. Yeah, that's really interesting. And it really is eye opening, is it? When you look at how the nine to five workday came about, because that's the time when the factories were open and all the history around how organizations are structured. And it's really important, I think, to challenge some of those things that we've done in the past that worked back in the industrial age. But now we're moving into the information age and into these times of digital transformation. It probably doesn't work for us anymore, does it, some of those things? Or do you think some of those things are still valuable now that we have distributed teams, a lot of people are working remotely? Are there any things that come to mind that you think actually we shouldn't get rid of that just yet?

Melissa Reeve:

Oh, I'm sure there are. John Kotter has presented in his book, Accelerate, this notion of a dual operating system. So that you have the network part of the organization, which moves fast and nimble like a startup and then you have the hierarchical part of the organization. And the hierarchy is very, very good at scaling things. It's a well oiled machine. You do need somebody to approve your expense report. You do need some policies and some guidelines, some guard rails. And so we're not actually saying abolish the hierarchy. And I do feel like that's part of this legacy system. But what we are saying is abolish some of the command and control, this notion that the management knows the one best way, because the knowledge worker oftentimes knows more than his or her manager.

Melissa Reeve:

It's just too hard for a manager to keep up with everything that is in the heads of the people who report to him or her. So that's a really big change and it was a change for me. And I think why I got so fascinated in this history of management theory is because I came across some notes from my college days. And I realized that I had been taught these historic management theories. I'd been taught Taylorism, which stems from 1911. And I realized, wow, there's a lot of undoing that I've had to do in order to adopt this Agile way of working.

Sean Blake:

Well, that's great. Yeah, that's really important, isn't it? I've heard you speak before about this concept of walk-up work, especially in the realm of marketing. But I suppose, well, firstly, I'd like to know what is walk-up work. Why is it so dangerous, not just for marketers, but for all teams? And how do we start to fight back against walk-up work?

Melissa Reeve:

Yeah. So, marketers in particular get bombarded with what I like to call walk-up work. And that's when an executive or even a peer literally walks up, so think again about the cubicle farm, and makes a request. So how that looks in the virtual world is the slack or the instant message, "Hey, would you mind?" One is that it results in a lot of context switching and there's time lost in that context switching. And then the other part is rarely do these requests come in well-defined or even with any sort of deadline detach. In marketing, it might look like, "Hey, can you create this graphic for this email I'm sending out?" So now you've left your poor graphic designer with this knowledge that here she has to make a graphic, but they don't really have any of the specs.

Melissa Reeve:

So it's very, very helpful to put these things into stories, to follow the Agile process, where you're taking that walk-up work to the product owner, where the product owner can work with you to define that story, keep the person who's doing the work on task, not making them context switch or do that. Get that story in that acceptance criteria very well defined and prioritized before that work then comes into the queue for the graphic designer. And this is an anti-pattern, whether you're talking about an organization of 50 or 5,000.

Melissa Reeve:

And what I've found is the hardest behavior to change is that of the executives. Because not only do they have walk-up work, but they have positional authority too. And it's implied that, that person will stop working on whatever they're working on and immediately jump to the walk-up work being defined by the executive. So I feel like it's really dangerous to the whole Agile ecosystem because it's context switching, it interrupts flow and introduces waste into the system. And your highest priority items might not being worked on.

Sean Blake:

Okay. So how many people do you have on your marketing team at Scaled Agile?

Melissa Reeve:

We're pretty small, still. We've got about somewhere in the 20s, 23, 25, give or take or few.

Sean Blake:

So how do you-

Melissa Reeve:

I think right now we're three Agile teams.

Sean Blake:

Three. Okay. So those 20 something is split into three Agile teams. And do they each have a product owner or how does the prioritization of marketing work in your teams?

Melissa Reeve:

Yeah, it's a good question. So we do have individual product owners for those three product teams. And what's fascinating is the product owners then also have to meet very regularly to make sure that the priorities stay aligned. Because like many marketing teams, we don't have specialized skill sets on each of those teams. So for the group of 23, we only have one copywriter. For the group of 23, we have two graphic designers. So it's not like each team has its own graphic designer or its own copywriter.

Sean Blake:

Yes.

Melissa Reeve:

So that means the three POs have to get together and decide the priorities, the joint priorities for the copywriter, the joint priorities for those graphic designers. And I think it's working. I mean, it's not without its hiccups, but I think it's the role of the PO and it's an important role.

Sean Blake:

So how do you avoid the temptation to come to these teams and say, "Drop what you're doing, there's something new that we all need to work on?" Do you find that challenging as an executive yourself to really let the teams be autonomous and self-organizing?

Melissa Reeve:

Yeah, I think the biggest favor we've done to the teams is really, I don't want to say banned walk-up work, but the first thing we did is we defined it. And we said, "Walk-up work is anything that's going to take you more than two hours and that was not part of iteration planning." And iteration is only two weeks. And so, in theory, you've done it within the past 10 days. So if it wasn't part of that and you can't push it off to the next iteration planning, and there's a sense of urgency, then it's walk-up work.

Melissa Reeve:

And we've got the teams to a point where they are in the habit of then calling in the PO and saying, "Hey, would you mind going talking to so and so, and getting this defined and helping me understand where this fits in the priority order." And really that was the biggest hurdle because as marketers, I think a lot of us want to say yes if somebody approaches us with work. But what's happened is people have, myself included, stopped approaching the copywriters, stopped approaching the graphic designer with work. I just know, go to the PO.

Sean Blake:

That's good. So it's an extra line of defense for the team so they can continue to focus on their priorities and what they were already working on without being distracted by these new ideas and new priorities.

Melissa Reeve:

Yes. And in fact, I think we, in this last PI reduced walk-up work from 23% down to 11%. So we're not a 100%. And I don't know if we'll ever get to be a 100%, but we're certainly seeing progress in that direction.

Sean Blake:

Oh, that's really good. Really good. And so your marketing teams are working in an Agile way. Do you feel that across the board, not only within your organization, but also just more generally, are you seeing that Agile is being adopted by non-technical teams, so marketing, legal, finance? Are these sort of non-technical teams adopting Agile at a faster rate, or do you feel like it's still going to take some years to get the message out there?

Melissa Reeve:

Yeah. And I guess my question to you would be, a faster rate than what?

Sean Blake:

Good question. I suppose what I'm asking is, do you feel like this is a trend that non-technical teams are adopting Agile or is it something that really is in its infancy and hasn't really caught on yet, especially amongst Scaled Agile customers or people that you're connected to in the Agile industry?

Melissa Reeve:

I would say yes. Yes, it's a trend. And yes, people are doing it. And yes, it's in its infancy.

Sean Blake:

So, yes?

Melissa Reeve:

Yeah. So all of those combined, and I'm not going to kid you, I mean, this is new stuff. In fact, as part of that listening session I mentioned and we were talking about all these different parts of the business. And there was mentioned that the Scaled Agile Framework is the guidance to these teams, to HR, to legal, to marketing could be more robust. And the answer is absolutely. And the reason is because we're still learning ourselves. This is brand new territory that we're cutting our teeth on. My guess is that it'll take us several years, I don't know how many several is, to start learning, figuring out how this looks and really implementing it.

Melissa Reeve:

Now, my hope is that we'll get to a point where Agile is across the organization, that it's been adapted to the different environments. When I've seen it and when I've thought through things like Agile HR, Agile Legal, Agile procurement, the underpinnings seem to be solid. We can even things like the continuous delivery pipeline of DevOps. When I think about marketing and I think about automation. And I think about artificial intelligence, yeah, I can see that in marketing and I can see the need for this to unfold, but will it take us a while to figure out that nuance? Absolutely.

Sean Blake:

Okay. And can you see any other trends more broadly happening in the Agile space? You know, if we're to look forward, say 10 years, a decade into the future, what does the way of working look like? Are we all still remote or how are team's going to approach digital transformations in 10 years time? What's your perspective on the future?

Melissa Reeve:

Yeah, I mean, sometimes to look to the future I like to look to the past. And in this case I might look 10 or 12 years to the past. And 12 years ago, I was getting my very first iPhone. I remember that it was 2007, 2008. And you think about what a seismic shift that was in terms of our behavior and social media and connecting and having this computer in our hand. So I ask myself, what seismic shift lies ahead? And certainly COVID has been an accelerant to some of these shifts. I ask myself, will I be on airplanes as frequently as I was in the past? Or have we all become so accustomed to Zoom meetings that we realized there's power there. And we don't necessarily need to get on an airplane to get the value.

Melissa Reeve:

Now, as it pertains to Agile, I feel like in 10 years we won't be calling it Agile. I feel like it will look something more like a continuous learning organization or responsive organization. Agile refers to a very specific set of practices. And as that new mindset, well, the practices and the principles and the mindset, and as that new mindset takes hold and becomes the norm, then will we be calling it Agile? Or will it just be the way that people are working? My guess is it'll start to be moving toward the latter.

Sean Blake:

Well, let's hope that it becomes the normal, right? I mean that it would be great to have more transparency, more cross functional work, less walk-up work and more business agility across the board, wouldn't it? I think it would be great if that becomes the new normal.

Melissa Reeve:

Yeah, me too. Yeah. And I think, we don't call the way we manage people. We don't say, "Oh, that's Taylorism. Are you going to be practicing Taylorism? It's just the way we've either learned through school or learned from our bosses how to manage people. And that's my hope for Agile, is that we won't be calling it this thing. It's just the way we do things around here.

Sean Blake:

Great. Well, Melissa, I think we'll leave it there. I really enjoyed our conversation, especially as a marketer myself. It's great to hear your insight into the industry. And everything we've discussed today has been really, really eyeopening for me. So thank you so much for sharing that with me and with our audience. And we hope to have you on the podcast again, in the future.

Melissa Reeve:

Sean, it's been such a pleasure and I'd be happy to come back anytime.

Sean Blake:

Great. Thanks so much.

Melissa Reeve:

Thank you.

In this insightful episode, we dive deep into one of the most common frustrations in engineering and dev teams: retrospectives that fail to drive meaningful change. Join Jaclyn Smith, Senior Product Manager at Easy Agile, and Shane Raubenheimer, Agile Technical Consultant at Adaptavist, as they unpack why retrospectives often become checkbox exercises and share practical strategies for transforming them into powerful engines of continuous improvement.

Want to put these insights into practice? We hosted a live, hands-on retro action workshop to show you exactly how to transform your retrospectives with practical tools and techniques you can implement immediately.

Key topics covered:

• Common retrospective anti-patterns and why teams become disengaged
• The critical importance of treating action items as "first-class citizens"
• How to surface recurring themes and environmental issues beyond team control
• Practical strategies for breaking down overwhelming improvement initiatives
• The need for leadership buy-in and organizational support for retrospective outcomes
• Moving from "doing agile" to "being agile" through effective reflection and action

This conversation is packed with insights for making your retrospectives more impactful and driving real organizational change.

About our guests

Jaclyn Smith is a Senior Product Manager at Easy Agile, where she leads the Easy Agile TeamRhythm product that helps teams realize the full benefits of their practices. With over five years of experience as both an in-house and consulting agile coach, Jaclyn has worked across diverse industries helping teams improve their ways of working. At Easy Agile, she focuses on empowering teams to break down work effectively, estimate accurately, and most importantly, take meaningful action to continuously improve their delivery and collaboration.

Shane Raubenheimer is an Agile Technical Consultant at Adaptavist, a global family of companies that combines teamwork, technology, and processes to help businesses excel. Adaptavist specializes in agile consulting, helping organizations deliver customer value through agile health checks, coaching, assessments, and implementing agile at scale. Shane brings extensive experience working across multiple industries—from petrochemical to IT, digital television, and food industries—applying agile philosophy to solve complex organizational challenges. His expertise spans both the technical and cultural aspects of agile transformation.

Transcript

This transcript has been lightly edited for clarity and readability while maintaining the authentic conversation flow.

Opening and introductions

Jaclyn Smith: Hi everyone, and welcome back to the Easy Agile Podcast. Today I'm talking to Shane Raubenheimer, who's with us from Adaptavist. Today we're talking about why your retrospectives keep failing and how to finally fix them. Shane, you and I have spent a fair amount of time together exploring the topic of retros, haven't we? Do you want to tell us a little bit about yourself first?

Shane Raubenheimer: Yeah, hello everyone. I'm Shane Raubenheimer from Adaptavist. I am an agile coach and technical consultant, and along with Jaclyn, we've had loads of conversations around why retros don't work and how they just become tick-box exercises. Hopefully we're going to demystify some of that today.

Jaclyn Smith: Excellent. What's your background, Shane? What kind of companies have you worked with?

Shane Raubenheimer: I've been privileged enough to work across multiple industries—everything from petrochemical to IT, to digital television, food industry. All different types of applied work, but with the agile philosophy.

Jaclyn Smith: Excellent, a big broad range. I should introduce myself as well. My name is Jaclyn. I am a Senior Product Manager here at Easy Agile, and I look after our Team Rhythm product, which helps teams realize the benefits of being agile. I stumbled there because our whole purpose at Easy Agile is to enable our customers to realize the benefits of being agile.

My product focuses on team and teamwork, and teamwork happens at every level as we know. So helping our customers break down work and estimate work, reflect—which is what we're talking about today—and most importantly, take action to improve their ways of working. I am an agile coach by trade as well as a product manager, and spent about five years in a heap of different industries, both as a consultant like you Shane, and as an in-house coach as well.

The core problem: When retrospectives become checkbox exercises

Jaclyn Smith: All right, let's jump in. My first question for you Shane—I hear a lot that teams get a bit bored with retros, or they face recurring issues in their retrospectives. Is that your experience? Tell me about what you've seen.

Shane Raubenheimer: Absolutely. I think often what should be a positive rollup and action of a sequence of work turns out to normally become a checkbox exercise. There's a lot of latency in the things that get uncovered and discussed, and they just tend to perpetually roll over. It almost becomes a checkbox exercise from what I've seen, rather than the mechanism to actively change what is happening within the team—but more importantly, from influences outside the team.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

Jaclyn Smith: Yeah, I would agree. Something that I see regularly too is because they become that checkbox, teams get really bored of them. They do them because they're part of their sprint, part of their work, but they're not engaged in them anymore. It's just this thing that they have to do.

It also can promote a tendency to just look at what's recently happened and within their sphere of influence to solve. Whereas I think a lot of the issues that sometimes pop up are things that leadership need to help teams resolve, or they need help to solve. It can end up with them really focusing on "Oh well, there's this one bit in how we do our code reviews, we've got control over that, we'll try to fix that." Or as you say, the same recurring issues come up and they don't seem to get fixed—they're just the same complaints every time.

Shane Raubenheimer: Absolutely. You find ways that you put a band-aid on them just so you can get through to the next phase. I think the problem with that is the impact that broader issues have on teams is never completely solvable within that space, and it's no one else's mandate necessarily to do it. When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

The pressure problem and overwhelming solutions

Jaclyn Smith: Yeah, I think so too. The other thing you just sparked for me—the recurring issue—I think that also happens when the team are under pressure and they don't feel like they have the time to solve the problems. They just need to get into the next sprint, they need to get the next bit of work done. Or maybe that thing that they need to solve is actually a larger thing—it's not something small that they can just change.

They need to rethink things like testing strategies. If that's not working for you, and it's not just about fixing a few flaky tests, but you need to re-look at how you're approaching testing—it seems overwhelming and a bit too big.

Shane Raubenheimer: Absolutely. Often environmental issues are ignored in favor of what you've been mandated to do. You almost retrofit the thing as best you can because it's an environmental issue. But finding ways to expose that as a broader-based issue—I think that should be the only output, especially if it's environmental and not team-based.

The problem of forgotten action items

Jaclyn Smith: Something I've also seen recently is that teams will come up with great ideas of things that they could do. As I said before, sometimes they're under pressure and they don't feel they have the capacity to make those changes. Sometimes those actions get talked about, everyone thinks it's a wonderful idea, and then they just get forgotten about. Teams end up with this big long backlog of wonderful experiments and things that they could have tried that have just been out of sight, out of mind. Have you seen much of that yourself?

Shane Raubenheimer: Plenty. Yes, and often teams err on the side of what's expected of them rather than innovate or optimize. I think that's really where explaining the retrospective concept to people outside fully-stacked or insular teams is the point here. You need, very much like in change management, somebody outside the constructs of teams to almost champion that directive—the same way as you would do lobbying for money or transformation. It needs to be taken more seriously and incorporated into not just teams being mini-factories supporting a whole.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way. Naturally you get team-level ones, and that's normally where retrospectives do go well because it's the art of the possible and what you're mandated to do. I think bridging the gap between what we can fix ourselves and who can help us expose it is a big thing.

I see so much great work going to waste because it simply isn't part of the day job, or should be but isn't.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way.

Making action items first-class citizens

Jaclyn Smith: Yeah, absolutely. I know particularly in the pre-Covid times when we were doing a lot of retros in person, or mostly in person with stickies on walls, I also found even if we took a snapshot of the action column, it would still end up on a Confluence board or something somewhere and get forgotten about. Then the next retro comes around and you sort of feel like you're starting fresh and just looking at the last sprint again. You're like, "Oh yeah, someone raised that last retro, but we still didn't do anything about that."

Shane Raubenheimer: I think Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself. Because it doesn't matter how good you are if the impediments that are outside of your control are not managed or treated with the same kind of importance as the actual work you're doing. That'll never change, it'll just perpetuate. Sooner or later you hit critical mass. There's no scenario where your predictability or velocity gets better if these things are inherent to an environment you can't control.

Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself.

Jaclyn Smith: Yeah, that's true. We've talked about action items being first-class citizens and how we help teams do that for that exact reason. Because a retro is helpful to build relationships and empathy amongst the team for what's happening for each of them and feel a sense of community within their team. But the real change comes from these incremental changes that are made—the conversations that spark the important things to do to make those changes to improve how the team works.

That action component is really the critical part, or maybe one of two critical parts of a retro. I feel like sometimes it's the forgotten child of the retro. Everyone focuses a lot on engaging people in getting their ideas out, and there's not as much time spent on the action items and what's going to be done or changed as a result.

Beyond team-level retrospectives

Shane Raubenheimer: Absolutely, consistently. I think it's symptomatic potentially of how retros are perceived. They're perceived as an inward-facing, insular reevaluation of what a team is doing. But I've always thought, in the same way you have the concept of team of teams, or if you're in a scaled environment like PI planning, I feel retrospectives need the same treatment or need to be invited to the VIP section to become part of that.

Because retrospectives—yes, they're insular or introspective—but they need to be exposed at the same kind of level as things like managing your releases or training or QA, and they're not.

Jaclyn Smith: Yeah, I think like a lot of things, they've fallen foul of the sometimes contentious "agile" word. People tend to think, "Oh retros, it's just one of those agile ceremonies or agile things that you do." The purpose of them can get really lost in that, and how useful they can be in creating change. At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

Shane Raubenheimer: Absolutely. Outcome being the operative word, not successfully deploying code or...

Jaclyn Smith: Or ticking the retro box, successfully having a retro.

Shane Raubenheimer: Yeah, exactly. Being doing agile instead of being agile, right?

Expanding the scope of retrospectives

Jaclyn Smith: One hundred percent. It also strikes me that there is still a tendency for retros to be only at a team level and only a reflection of the most recent period of time. So particularly if a team are doing Scrum or some version of Scrum with sprints, to look back over just the most recent period. I think sometimes the two things—the intent of a retro but also the prime directive of the retro—gets lost.

In terms of intent, you can run a retro about anything. Think about a post-mortem when you have an incident and everyone gets together to discuss what happened and how we prevent that in the future. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

You can run a retro about anything. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

Understanding anti-patterns

Shane Raubenheimer: Absolutely. You just default to "what looks good, what can we change, what did we do, what should we stop or start doing?" That's great and all, but without some kind of trended analysis over a period of time, you might just be resurfacing issues that have been there all along. I think that's where the concept or the lack of understanding of anti-patterns comes in, because you're measuring something that's happened again rather than measuring or quantifying why is it happening at all.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

Jaclyn Smith: Yeah. Tell me a little bit more about some of the anti-patterns that you have seen or how they come into play.

Shane Raubenheimer: One of them we've just touched on—I think the buzzword for it is the cargo cult culture for agile. That's just cookie-cutting agile, doing agile because you have to instead of being agile. Literally making things like your stand-up or your review or even planning just becomes "okay, well we've got to do this, so we've ticked the box and we're following through."

Not understanding the boundaries of what your method is—whether you like playing "wagile" or whether you're waterfall sometimes, agile at other times, and you mistake that variability as your agility. But instead, you don't actually have an identity. You're course-correcting blindly based on what's proportionate to what kind of fire you've got in your way.

Another big anti-pattern is not understanding the concept of what a team culture means and why it's important to have a team goal or a working agreement for your team. Almost your internal contracting. We do it as employees, right?

I think a lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally. That's simply not a thing.

A lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally.

Jaclyn Smith: Yeah, I think that's a good call-out for anyone watching or listening. If you're not familiar with anti-patterns, they're common but ineffective responses to recurring problems. They may seem helpful initially to solve an immediate problem, but they ultimately lead to negative outcomes.

Shane, what you just spoke about there with retrospectives—an example of that is that the team feel disengaged with retrospectives and they're not getting anything useful out of it, or change isn't resulting from the retrospectives. So the solution is to not hold them as frequently, or to stop doing them, or not do them at different levels or at different times. That's a really good example of an anti-pattern. It does appear to fix the problem, but longer term it causes more problems than it solves.

Another one that I see is with breaking down work. The idea that spending time together to understand and gain a shared understanding of the work and the outcome that you need takes a lot of time, and breaking down that work and getting aligned on how that work is going to break down on paper can look like quite an investment. But it's also saving time at the other end, reducing risk, reducing duplication and rework to get a better outcome quicker. You shift the time spent—development contracts because you've spent a little bit more time discovering and understanding what you're doing.

A common anti-pattern that I see there is "we spent way too long looking at this, so we're going to not do discovery in the same way anymore," or "one person's going to look at that and break it down."

The budget analogy

Shane Raubenheimer: I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

Jaclyn Smith: It's the contractor.

Shane Raubenheimer: Yeah. It's almost like exposing stuff that everybody allegedly knows to each other is almost seen as counterintuitive because "we're just talking about stuff we all know." It often gets conflated into "okay, we'll just do that in planning." But the reality is the concept of planning and how you amend what you've done in the retrospective—that's a huge anti-pattern because flattening those structures from a ceremonies perspective is what teams tend to do because of your point of "well, we're running out of daylight for doing actual development."

But it's hitting your head against the wall repeatedly and hoping for a different outcome without actually implying a different outcome. Use a different wall even. I think it's because people are so disillusioned with retrospectives. I firmly believe it's not an internal issue. I believe if the voices are being heard at a budgeting level or at a management level, it will change the whole concept of the retrospective.

Solution 1: Getting leadership buy-in

Jaclyn Smith: I like it, and that's a good thread to move on to. So what do we do about it? How do we help change this? What are some of the practical tips that people can deploy?

Shane Raubenheimer: A big practical tip—and this is going to sound like an obvious one—is actual and sincere buy-in. What I mean by that is, as a shareholder, if I am basing your performance and your effectiveness on the quality and output of the work that you're promising me, then I should be taking the issues that you're having that are repeating more seriously.

Because if you're course-correcting for five, six, or seven sprints and you're still not getting this increasing, predictable velocity, and if it's not your team size or your attitude, it's got to be something else. I often relate that to it being environmental.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table, and I think that's a big one.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table.

Solution 2: Making patterns visible

Jaclyn Smith: I think so too. Something that occurs to me, and it goes back to what we were talking about right at the beginning, is sometimes identifying that there's a pattern there and that the same thing keeps coming up isn't actually visible, and that's part of the problem, right?

I know some things we've been doing in Easy Agile TeamRhythm around that recently, attempting to help teams with this. We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've added a few features to sort and that kind of thing. Coming in the future—and we've been asked about this a lot—is "what about themes? What about things that are bubbling up?" So that's definitely on our radar that will be helpful.

I think that understanding that something has been raised—a problem getting support from another team, or with a broken tool or an outdated tool that needs to be replaced in the dev tooling or something like that—if that's been popping up time and time again and you don't know about it, then even as the leader of that team, you don't have the ammunition to then say "Look, this is how much it's slowed us down."

I think we live in such a data world now. If those actions are also where the evidence is that this is what needs to change and this is where the barriers are...

Solution 3: The power of trend analysis

Shane Raubenheimer: Certainly. I agree. Touching on the trend analytics approach—we do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application. We don't actually trend or theme, to your point.

We do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application.

We theme everything when we plan, yet somehow we don't categorize performance issues as an example. If everybody's having a performance issue, that's the theme. We almost need to categorize or expose themes that are outward-facing, not just inward-facing. Because it's well and good saying "well, our automated testing system doesn't work"—what does that mean? Why doesn't it work?

I think it should inspire external investigation. When you do a master data cleanup, you don't just say "well, most of it looks good, let's just put it all in the new space." You literally interrogate it at its most definitive and lowest level. So why not do the same with theming and trending environmental issues that you could actually investigate, and that could become a new initiative that would be driven by a new team that didn't even know it was a thing?

Jaclyn Smith: Yeah, and you're also gathering data at that point to evidence the problem rather than "oh, it's a pain point that keeps coming up." It is, but it gives you the opportunity to quantify that pain point a little bit as well. I think that is sometimes really hard to do when you're talking about developer experience or team member experience. Even outside of product engineering teams, there are things in the employee experience that affect the ability for that delivery—whatever you're delivering—to run smoothly. You want to make that as slick as possible, and that's how you get the faster outcomes.

Solution 4: The human factor

Shane Raubenheimer: Absolutely. You can never underestimate the human factor as well. If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated. Because if you're hitting your head against the same issue regardless of how often you're pivoting, that can be very disillusioning, especially if it's not been taken as seriously as your work output.

If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated.

We run a week late for a customer delivery or a customer project, and we start complaining about things like money, budget overspend, over-utilization. But identifying systematic or environmental issues that you can actually quantify should be treated in exactly the same way. I feel very strongly about this.

Solution 5: Breaking down overwhelming action items

Jaclyn Smith: We tend to nerd out about this stuff, Shane, and you're in good company. You've also reminded me—we've put together a bit of a workshop to help teams and people understand how to get the most out of their retrospectives, not just in terms of making them engaging, but fundamentally how to leverage actions to make them meaningful and impactful.

We've spoken a lot about the incremental change that is the critical factor when it is something that's within the team's control or closely to the team's control. That's how you get that expansion of impact—the slow incremental change. We've talked about sometimes those action items seem overwhelming and too big. What's your advice if that's the scenario for a team? What do you see happen and what can they do?

Shane Raubenheimer: I would suggest following the mantra of "if a story is too big, you don't understand enough about it yet, or it's not broken down far enough." Incremental change should be treated in exactly the same way. The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth.

If we're iterating work delivery, problem-solving should be done in rapid iteration as well. That's my view.

Jaclyn Smith: I like it.

The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth. If we're iterating work delivery, problem-solving should be done in rapid iteration as well.

Wrapping up: What's next?

Jaclyn Smith: I think we're almost wrapping up in terms of time. What can people expect from us if they join our webinar on July 10th, I believe it is, where we dive and nerd out even more about this topic, Shane?

Shane Raubenheimer: I think the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

With our approach that we took to our workshop, I think people will very quickly get the feeling of "this is dealing with cause and effect in a cause and effect way." So practical—to put that in one sentence, an active showing or demonstration of how to quantify and actually do what we've been waxing lyrical about.

the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

‍Jaclyn Smith: Excellent. That was a lovely summation, Shane. If anyone is interested in joining, we urge you to do so. You can hear us talking more about that but get some practical help as well. There is a link to the registration page in the description below.

I think that's about all we have time for today. But Shane, as always, it's been amazing and lovely to chat to you and hear your thoughts on a pocket of the agile world and helping teams.

Shane Raubenheimer: Yeah, it's always great engaging with you. I always enjoy our times together, and it's been my pleasure. I live for this kind of thing.

Jaclyn Smith: It's wonderful! Excellent. Well, I will see you on the 10th, and hopefully we'll see everyone else as well.

Shane Raubenheimer: Perfect. Yeah, looking forward to it.

Jaclyn Smith: Thanks.

Ready to end the frustration of ineffective retrospectives?

Jaclyn Smith and Shane Raubenheimer also hosted a live, hands-on webinar designed to turn retrospectives into powerful engines for continuous improvement.

In this highly interactive session, they talked about how teams can:

• Uncover why retrospectives get stuck in repetitive cycles
• Clearly capture and assign actionable insights
• Identify and avoid common retrospective pitfalls and anti-patterns
• Get hands-on experience with Easy Agile TeamRhythm to streamline retrospective actions
• Practical tools, techniques, and clear next steps to immediately enhance retrospectives and drive meaningful team improvements.

👉 Watch the recording here.

"It was great to chat with Alana and learn from her experience" - Sean Blake

In this episode, I was joined by Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day.

She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.

We covered a lot of ground in today's episode. We talked about:

• The importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities.
• Building trust with your team and disclosing some vulnerabilities about yourself.
• Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community.
• Servant leadership and being a generous leader.
• The importance of authenticity and direct communication.

I hope you enjoyed today's episode as much as I did.

Transcript

Sean Blake:

Hello, welcome to the Easy Agile Podcast. My name's Sean Blake and I'll be your host today. Today, we have a really interesting guest and a fantastic episode ahead for you. Our guest today is Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day. She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.

Sean Blake:

We covered a lot of ground in today's episode. We talked about communication styles. We talked about the importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities. We talked about the importance of building trust with your team and disclosing some vulnerabilities about yourself. We covered Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community. We talked about going first in servant leadership and being a generous leader. The importance of authenticity and direct communication. I hope you enjoyed today's episode as much as I did. Let's get started. Alana, thanks so much for joining us on the Easy Agile Podcast today. It's great to have you here.

Alana Mai Mitchell:

Thanks so much, Sean.

Sean Blake:

Before we jump into our conversation, Alana, I'm just going to do an acknowledgement to country. We'd like to acknowledge the traditional custodians of the land from which we're recording today, the Watiwati people of the Tharawal speaking nation, and pay our respects to elders past, present and emerging. We extend that same respect to all Aboriginal and Torres Strait Island peoples who are tuning in today.

Sean Blake:

Well, Alana, there's so much to talk about today. The background is, we used to be colleagues in the financial services industry. We bumped into each other again out of the blue at Agile Australia '21 Conference, just at the end of last year, which was a great conference. We thought we'd have you on the podcast because you've got so many different stories to tell, but I thought maybe we could start this episode by talking about your career journey and how working with Agile Teams has weaved into your career trajectory.

Alana Mai Mitchell:

Yeah, sure. Agile really came into the forefront right back in 2013. I always remember my first Agile training. We had a team day, where I was working at the time. We had an external facilitator come in because the Agile framework was something totally new to financial services at that time. We played Lego. We had each of our wider team was divided into smaller teams, like scrum teams, all this new terminology. Then we were building island and we had an island each and the product owner was feeding user stories in from the customer. Partway through we were building, I think, a rocket launcher and then no, we didn't want to rocket launcher anymore.

Alana Mai Mitchell:

We wanted to tweak it. We had to adapt to things on the fly. I always remember that experience because it was so transformative, just having such a direct and collaborative way of working with people on a project. To this day, of all the Agile trainings and experiences that I've gone through, it's always the ones that are really interactive that I've remembered the most and gained the most and taught them, like learnt them myself as a participant and then taught them to other people as well.

Sean Blake:

Along the way, do you think, you've been through all these training sessions and you've been working with teams on the ground. What have you found from Agile, which is a big topic, but what have you found to be the most transformative and the most helpful from the way that these teams used to do things to the way that they do them now?

Alana Mai Mitchell:

I would say communication. What I found was, because I had the contrast with both, I've worked in Water Force style projects and Agile projects as well. I think the biggest part is the amount of effort and rigor that we would go through reviewing requirements and have those be delivered into technology. Then it go quiet and you not hear from technology until they come back with something and they're like, "I've got a baby." You're like, "What kind?" The difference with Agile is that you are able to co-create them.

Alana Mai Mitchell:

You're creating with your customer or your end user, if you're working with an internal user, and then you are also working with technology and finding out what kind of constraints technology has or what kind of ideas they have as well. You have that ability to communicate with the dev. Sometimes your devs are on-shore, often cases they're offshore. We're all remote now, so it doesn't make as much difference as it did when we were in the office. You can really just pull away a lot of the process that gets in between people and have conversations. That's what I really think is the most transformative part.

Sean Blake:

Great. Yeah, so that communication. Do you feel like the communication throughout COVID and working remotely has been more challenging? Are you one of those people that find those face-to-face communication skills, you really prefer the face-to-face or has remote been okay for you? Because I know some people have struggled. Some people have found it easier to be on Zoom all the time.

Alana Mai Mitchell:

Well, I mean, when I go in the office and we have that brief time where we were back in the office, I had a smile on my face the whole time. Because I just love seeing people and I'd go around and walk over to my team and say, "Hey, how are you going?" Just catch up with them. I think the one piece that's missing for me in the remote working whilst there's greater flexibility, you can do multiple things at the same time. You focus a lot of your work. You can get a lot more done quicker. I do find that informal relationship building, you need to actually schedule in time or pick up the phone out of the blue and connect with someone.

Alana Mai Mitchell:

Whereas in the office, I would just find that because people were there and I don't know, you might be having lunch at the same time or going downstairs for something at the same time or even the corridor conversations that happen after the meeting where you can just chase someone or ask someone a question or they chase you and you just get things done. It's just different. I'd say it's more, the catch ups are more scheduled and formal, I find in a remote work setting.

Sean Blake:

I feel the same way. I feel the small talk and the talk about the weekend on Zoom is much harder for me and much more tiring to try and sustain that than in person. It becomes more naturally. I really have to make a big effort, especially on one-to-ones with people in the team when I'm trying to check in on their health and wellbeing and how they're going at work. I just find that much more exhausting than what I do in person. I think it's just those nonverbal communication skills and you can see people's body language easier when you're in the office.

Sean Blake:

Someone's slumped at their chair for six hours out of a seven-hour work day. Then you're like, "Oh, something's wrong." If you know that you've got to get on Zoom and try and pretend to be happy and that everything's okay, then you can fake it a little bit easier. Of course, there's loads of benefits to remote work, as you say. That human element personally, I find it's much more challenging to replicate using digital tools. Maybe there'll be more innovation that comes, but the time will tell on that.

Alana Mai Mitchell:

Yeah. On that, I wanted to add some of my friends in the technology space. Talking about the metaverse and how at the moment you and I are having this conversation through screens. I'm in my space, in my house, and you can see my painting in the background and I can see that you've got a podcast set up. One of my friends was talking about how, he's an architect, and so he was thinking about how we create digital spaces. When we meet digitally, if we were meeting as our avatar, what kind of space would facilitate better conversation? That blew my mind when he was talking about that. I was like, "Oh, I hadn't even thought of that." Absolutely, you could meet in a virtual space because we're doing what we've got with the tools that we have today, but the tools can change.

Sean Blake:

I guess it's almost certain they will change. I can't see that Zoom will be the market leader forever. I'm sure there'll be things that come along very soon that will try and replicate some of those physical experiences that we miss so much of being in the office and having those social experiences together. Alana, I'm wondering about the teams that you work with now or in the past, those Agile teams, do you have any tips for people who are new to Agile teams or maybe they're coming in?

Sean Blake:

They want to improve their communication, whether they're remote or in office, and improve their organization's Agile maturity, but they're just finding it a bit of a struggle. Do you have any tips for people who are just, they're butting their heads up against the wall and they can't seem to make progress with some of those patterns and habits that you talked about, like taking requirements away and not knowing what's happening for so many months or years before you hear something back from technology? How do you actually start to influence that culture and behavior, if you're new to Agile?

Alana Mai Mitchell:

I'm going to take a slightly different approach on that to answer your question. Because the thing that came to mind for me was when I in Outward Bound, which is a remote wilderness organization in 2012 in the US. I was instructing there. One of the frameworks that they use is William Glass' Choice Theory. Choice Theory talks about that we have five needs, and I'll put myself on the spot. Well, I'll mention some of them, because I can't remember all of them. There's like need for fun. Some people have a high fun need. Then there's like need for power, like feeling powerful. There's like, love and belonging, is another important need. There's two others, which I can't recall right now. I think when you are coming out of a situation, from a perspective, you've tried a couple of times when you're approaching it, and not getting anywhere, I would have a look at what needs am I, myself looking to get met out of this communication.

Alana Mai Mitchell:

Then on the flip-side, what needs is my communication partner or the team that I'm working with? What is the most important need for them? As we were talking about remote working, like the fun need. People love to have fun and you can actually have fun at work. It doesn't need to be separate. Thinking about like, if you have a high fun need, and you also notice your team has that as well. How can you address that in your communication style or bring out some kind of activities that can bring that to life? I would always go back to what are my needs and what are the needs of other people that I'm working with? Because when you're working with different teams, they have different agendas, they have different goals. If you can figure out what you have in common, it's a lot easier to bring another team or people in those team on the journey, once you figured out what the common ground is.

Sean Blake:

That's great advice. Think about it from their point of view, rather than just what you need and your own agenda and try and adapt to your approach to them. That's really good. I saw this quote recently, Alana, which reminded me a little bit about your mental health journey, which we'll talk about more in a moment. The quote was about, when you're looking for a new role or a new job, you shouldn't just look for a great company to work for. You should look for a great manager to work for, because the influence and your experience as an employee, working for a manager, is often so much more important than and influential than just picking a great or a well-known company to work for. Have you found that to be true in your own career?

Alana Mai Mitchell:

Oh, yeah. I have found that some really phenomenal leaders. In a previous organization that I was working in, I like to keep learning and growing all the time. In previous roles, sometimes I get bored. It happens. That's really valuable to organizations because I'm constantly looking at where to improve things. I had a time where my manager was focused on other things and learning and development wasn't as important. Then I had a lady named Christina come in and Christina was like fire. She was just, "This is what we got to do." Open to change, really clear communicator, she's from the US. She's really direct in a compassionate way and she's really progressive as well. I found because of her influence in the organization.

Alana Mai Mitchell:

Also, through my willingness to put my hand up and say, "I'm willing to participate." Which is, for the people who are tuning in, it's not just about the leader creating the opportunities for you and saying, "Hey, present to this general manager forum or executive general manager forum." Or whatever it is. It's also about you saying, "Hey, I'm willing and I'd love to." And communicating what you are after. We met on that path and I had some of the most, stronger success working with Christina. I was fortunate at that the culture was also really great. The immediate team culture needed to shift as well, which is part of why Christina came on board, and the company culture is really good.

Alana Mai Mitchell:

I would say on the point on like manager over culture is that when you are someone who is progressive and you're wanting to shape the culture for the better, you're going to find cultures that need a little attention or need a little work or things that aren't quite as performing as well as they are. With the sales perspective, opportunity plus. If you go to a culture and everything's amazing, you're sure you can make it a little bit more amazing. Really, when you have the support of your manager, who's, you see these initiatives and they're going to say, "Okay, go for it. I've got this GM forum coming up that you can present at, or let's find your sponsor. Let's find your mentor." That the two of you working as a team can be at the forefront of the new culture, which impacts the rest of the culture.

Sean Blake:

Interesting. I don't know if I've ever been in a culture that's perfect and overachieving and too good, but absolutely you can get too comfortable and complacent in roles and you can almost just be a little bit shy from putting your hand up for those opportunities. Do you think there's many cultures out there that are too good? How do you assess the quality of a culture before you accept the role and start working in that team?

Alana Mai Mitchell:

Oh, good question. I always asked, what's the vision and how does it relate to this role? I want to hear it from the hiring manager before I join a company. What I'm looking for is I'm asking that question to multiple people. I'm looking for a congruence, about the hiring manager sees a similar story as to what their peer, who's maybe interviewing in the second interview or their leader in the third interview. I'm looking for those things to match up, because that's telling me there's consistency. It's just, I'm getting the same story. That they're also communicating well. That would be a sign to me. Yeah, that's about what I do.

Sean Blake:

That's good. Good tip. Alana, you have a quote on your website, which talks about your mental health journey. It says, "I have totally recovered from five mental health breakdowns across six years, where doctors once talk would me, I would be homeless." That sounds like a lot of hardship and a lot of sweat and tears and pain over many years. Do you want to walk us through a little bit of that journey and what you've learned about yourself through those experiences?

Alana Mai Mitchell:

Oh, yeah. Thanks for pulling that out from the site, Sean. In 2013, I started to notice that things weren't right. I wasn't feeling myself. I sought help from a counselor, career counselor. Because I thought, "Is it my career?" I said, "Am I not in the right job?" I spoke to a psychiatrist and a psychologist and they did a little bit of an investigation, but no one really got to what was going on. Then I made some quick decisions in my career, which I look back on and I think, "Wow, I really was in the throes of it and not thinking clearly at all when I made those choices." I found myself, about November 2014, in between roles. As someone who was previously really ambitious, like high-achiever, chronic high-achiever without having a role and a career prospect at the moment back then was a big deal.

Alana Mai Mitchell:

I had what was called a psychotic episode. Essentially, that was like me, believing deluded thoughts and not having a really strong grip on reality, having some story going on in my head that wasn't true at all. It ended up because I was taken by ambulance to hospital. Then still at that point, people didn't really know what was going on. I was a in mental health ward and came out from that, started on medication, which improved things. I thought, and this is part of why I had the multiple psychotic episodes, is that I thought that the stress of being in between jobs or stressful situations at work, I thought they were the triggers for the psychotic episodes.

Alana Mai Mitchell:

I would take the medication for a while, get better temporarily, think everything was normal, stop the medication. Then six months later I would have another breakdown. Then that happened over six years and I realized towards the fifth and final, so that was when I was running a coaching business that had a few clients at the start and then we didn't have any clients at all. I essentially ran out of money and got into debt. Then when the doctor learned about my financial situation, he said, "You're going to be homeless." I was so offended. I was like, "How dare you." I was like, "No, I will not. I will not." I look back now and I'm so thankful for him sharing that with me, because he provided me with a choice. Something to push against and choose another way. He activated my will, from me going from being offended to being thankful, where I'm at today.

Alana Mai Mitchell:

I charted my way out of that. Now, I have well-managed schizophrenia and I take medication. I'll be taking medication for the rest of my life. It's part of who I am. I don't experience like, some people have a lot of appreciation for, because I know that they're in their mental health journey. It's not all smooth sailing, even after they have an answer of a diagnosis. It still can be challenging in there's up days and down days. For me, I'm consistent. It's been now coming up to four years since the doctor and I had that conversation in the hospital. Life is just incredible since then.

Sean Blake:

That's great. I'm so happy to hear that. Thank you for sharing your story with our audience. I think it's really important, isn't it? To be vulnerable and to share the truth about things that have happened in the past. Do you think that there's something that we can learn? With the people that you work with now, do you have a clearer understanding or are you looking for signs of people in your life who might be struggling with some of the similar issues and what can we do as people in our own communities and working with teams to look out for each other and to better support each other with some of these mental health issues front of mind so that we can be more supportive?

Alana Mai Mitchell:

I always listen for and check in with how the team is doing and it's not just, you ask how are you, and you're listening for more than what they say. If they say they're good, how are they saying it? We had that conversation before about the remote working and it's different. To come to the, are you okay, and we have the, are you okay days. Someone asked me in the office where we were actually working together. They're like, "Are you okay, Alana?" I couldn't answer her. It's not always as simple as getting a no, sometimes it's, you don't get a response. Then the alarm does go off. I really think taking in all the points of interaction that you have with someone and aligning to, is that consistent with how do they were, is there something different, check in with them, how is it going? If you're having a conversation, great. If they're sharing with you, even better.

Alana Mai Mitchell:

If they're not, you can always just check in with yourself and being like, "Is it something you need?" As to, why are they not sharing or is that something that's going on with them as well? The other piece I wanted to tie it, bring it back to the Agile leadership piece and from the conference that Agile Australia that we were at. I really see that building trust with teams is so key. We're in this remote working environment or hybrid working environment, depending on what office you're in. It really is important to build trust with your team. One of the quickest ways you can do that is by sharing vulnerably with what you have to share. I don't mean going for exposure and putting yourself in vulnerable situations where you are uncomfortable with what you share.

Alana Mai Mitchell:

It's disclosure, so it's something that you're 100% comfortable within yourself, and you've accepted it within yourself and you share that with your team in openness. When you do that, you see that your team also, they hear it and they mirror it as well. You go first and they share. The mental health example, I shared that on LinkedIn. I've shared it in situations with my team. Then I've been invited to talks and I've had people approach me. It really builds without having to go through a lot of, I ask this thing of this person, do they deliver it above and beyond expectations when I ask for it? How many times do you need to go through that process before you trust someone versus you, coming out and creating an environment of trust through of vulnerability? I do caveat that it's like not oversharing, it's sharing what you're comfortable with at that point in time, and that might change as you go on.

Sean Blake:

Interesting. Does this apply to leaders as well? I know that you've spoken about being a generous leader in the past, and that reminds me of servant leadership, which is another kind of Agile phrase that you hear come up quite a lot. This idea of going first, disclosing what you're comfortable with to your team, even as a leader, showing vulnerability is really important. I know in my experience, if you can share some of the honest and harsh realities of what it's like to be in your position, then your team are more empathetic with the challenges that you have.

Sean Blake:

Because a lot of people assume that when you are in a position of leadership and responsibility, then things are easier because you can just delegate or you've got budget to solve some of these problems, but it's not actually the reality of it. The reality of it is you struggle with things just like anyone else. By sharing and disclosing things with people at all levels of the organization, then that helps to build empathy and a bit more care and support no matter what level you're at. Are there other things or habits or qualities of a generous leader or a servant leader that you've seen or that you try and model or encourage?

Alana Mai Mitchell:

The big one that stands out for me is authenticity. Really knowing yourself, knowing what your leadership style is, knowing what your challenges are, what your strengths are, what you're working on and being authentic about that. When you feel something, sharing what you feel, not having to feel like you need to say it a different way or sugarcoat it, being able to speak your mind in a way that's direct and compassionate. We're not going for like arrogance, and we're not going for wishy washy. We're going for direct and compassionate, then share what's in your heart, so authenticity. Those are the leaders that you, I'm so glad you brought up empathy because when you're vulnerable, empathetic, and authentic, those are the leaders that really stand out for you and me.

Sean Blake:

That's great advice. Authenticity, direct communication, build empathy. All right, thanks for sharing that.

Alana Mai Mitchell:

You're welcome.

Sean Blake:

Alana, how did you decide that you wanted to write a book about some of your experiences and can you tell us about how your book, Being Brave, has changed your life and how you think about sharing your story?

Alana Mai Mitchell:

I naturally have a lot of things going on. I love projects. I love it, that's why I'm in projects. Because I love setting a goal and reaching it. The company I was working at had done a number of workshops and I got to a point where I didn't have as many activities going on. I was like, "Oh, that's really interesting. I don't have as much stuff going on." This was just at the start of the pandemic in 2020. A friend, a really dear friend of mine said, "Try meditation. Try meditation daily." I meditated each day and I had been surrounded, my network is very much of a coaching network. I know a lot of coaches and they had written their own books as well. I was on the radar and I was meditating and I got the idea to write a personal memoir about my story.

Alana Mai Mitchell:

It's really interesting that even in through that process of doing a lot of personal development work and going through the process of writing the story, there were still some things in that, that I wasn't quite comfortable owning yet. It's been, since I wrote the book that I've accepted that. In a book, if people read it, I talk about psychotic episodes. I don't talk about schizophrenia because it was all later when I was asked to do a media thing about schizophrenia, that I was like, "Okay, yep. Time to own that." I feel like the book at a point in time had me accept all that had happened with unconditional love and then to still, modeling that piece of going for disclosure and not exposure. Still, I had my fragility on what I wasn't ready to disclose yet. Since then, that had progressed further.

Sean Blake:

That's awesome. That therapy you're sitting down to write the story actually helped flesh out the story itself and you came to terms with some of those things that happened. What has been the reception to the book?

Alana Mai Mitchell:

Most people, when they pick up the book, it's a short book, so some people even call it a booklet, because it's 11,000 words. It's short. They say, "Wow, I read that in an hour and a half, in one sitting. I couldn't put it down." someone had said, "It's the story of the famous rising from the ashes." They can take a lot of inspiration from it. The point of the book and a lot of what we're talking about vulnerability is going first as the leader. You set an example that others can follow in, so that will flow into their lives as well. The book is set out with a story and a few questions at the end that people can go through for their own insight.

Sean Blake:

Great, awesome. Alana, is there anything else you'd like to share with our audience before we start wrapping up the episode today?

Alana Mai Mitchell:

I did, because I know this is about Agile more so, and that's a really important topic to your audience. I did write and have a think about after that conference we went to, Agile Australia, about what is beyond the Spotify model? Because the Spotify model is very, word is spoken about it at the moment with the crews and the tribes and squads of course, and the chapter lead models and all that they have, which I'm sure everyone tuned in would be really familiar with. I started to think about, what are the things that are relevant beyond the Spotify model? What's next? If your organization is at a point where you've already at your job at some of that, and you're looking for what's next. I did write an article about that. It's on LinkedIn, and I'll give it to you. If you want to, you can put it in the show notes.

Sean Blake:

That's awesome. We will definitely do that. Where can people go to find out more about you? Where can they buy your book or visit your website?

Alana Mai Mitchell:

My site is www.alanamaimitchell.com. On there is more about my story. There's a few things about coaching, which may be relevant. I'm not coaching at the moment, I'm more focused on my career in financial services. Then the book is on Amazon and it's in English and also in Spanish. There's the audio book and also the print book and the eBook.

Sean Blake:

Awesome. Well, Alana, thanks for disclosing what you've disclosed today and sharing your story with us. I've learned a lot about your experiences, and I've got a lot to think about, to reflect on, how to be a more generous leader. Thanks for spending time with us and being part of the Easy Agile Podcast.

Alana Mai Mitchell:

You're so welcome. Thanks for having me on the show, Sean.

Sean Blake:

Thanks, Alana.