Easy Agile Podcast Ep.2 John Turley, Digital Transformation Consultant, Adaptavist

Transcript:

Sean Blake:

Hello, everybody. I'm Sean Blake, the host of this episode of the Easy Agile podcast. I'm also Head of Marketing at Easy Agile, where our mission is to help teams around the world work better together. We have a fascinating guest with us today. It's John Turley from Adaptavist. John is a pragmatic Agile leader with 25 years experience working in companies at all levels, from teams to C suite, always bringing real value, adding change to the way organizations work. Dissatisfied with the standard discourse around transformation and agility, he is passionate about applying cutting edge knowledge from fields as diverse as sociology and psychology. We're really excited to have John on the podcast today. So John, thanks so much for being on the Easy Agile podcast.

John Turley:

You're welcome, Sean. Pleasure to be here.

Sean Blake:

Thank you so much. So John, you've got a lot of experience in the Agile space, in the tech space. And I'm not trying to call you old. But I'd love to get a sense of what's changed over 25 years. It must just be night and day from where you started to what you see now.

John Turley:

There's a lot of change. And I'm pretty comfortable with old. I'm 48 now, and it's closest to 30 years now. That tells you when I first wrote that bit in the bio. So the technology has changed. That's mind blowing. I started off in ops, and then infrastructure and project management and stuff and 1999, 2000, it would take us three months and 50,000 quid to build a couple of web servers with a pair of load balancers and firewalls and a database at the back. And now we spin them up in seconds.

John Turley:

This is profound. Platform technology is profound slack or I mean platform technologies, that makes a massive difference to the way we interact. Scale is a massive issue. I would say that the world is sort of dichotomized into very large and quite small organizations. There seem to be less in the middle. It's just a gut feeling. We see, I think trust is collapsed. We see that in Edelman Trust Barometer. We see the complexity has increased. That's deeply problematic for us. [inaudible 00:02:23] has been measuring that one.

John Turley:

And we see that workforce engagement is at all time lows through the Gallup World Poll. Those things are big, big changes. What's the same though is the people, the way the people think, the way we construct our reality, our mindset, if you like, the way we make sense of the world around us is very, very similar. So although we now talk a lot more about Agile, the waterfall and waterfall for many is a bit of a dirty word, not for me and same with command and control. People are taking the same mindsets. This is measurable and provable. People are taking the same mindset that they had around waterfall and command and control using different language of Agile and behaving in the same way. That hasn't changed.

Sean Blake:

Very interesting. So you touched on trust, and how basically we've seen this breakdown of trust across the board. And I've just watched a documentary that's come out on Netflix around the Social Dilemma, and how the trust that we have in these big social media platforms is eroding. And we're getting a little bit skeptical around what these big companies are doing to us as the customer. Do you find that that's a hard balance with the people that you work with around being customer focused, but still building a profitable and growing business?

John Turley:

Yeah, I do. Yes, and the way I think it manifests itself, which again maybe we'll get into the sort of the psychology and the sociology as well as the complexity science, I'm into it later. But there's a very clear way that that lack of trust manifests itself. I'm not sure it's the lack of trust that manifests itself. But there's a very clear thing that's happening is people, there's repeated patterns of behavior I see all over the place in a lot of the work I do, which is one on one and with groups, that people hold on to this idea that their view is right and anything that doesn't comply with that is wrong.

John Turley:

This is a view that comes from the predominant mindset from what [inaudible 00:04:33] call the sort of expert or the achiever mindset, and it becomes a barrier to us collaborating and learning together and innovating. If somebody with a different point of view is dismissed as wrong, then there's no common ground to start to build trust. Trust is eroded from the outset, and that means that we can't collaborate, and in a complex world where we need to collaborate ever more closely and learn together and innovate, that's a deep, deep problem.

John Turley:

And the response seems to be that people actually withdraw, they withdraw into groups, we might call them cliques or echo chambers. The sociologists call this process homophily. This is a function like many say of platforms like Twitter, we retreat into groups that echo the opinions that we already hold that then reinforce those opinions, and separate us from the opinions of others and reinforce the opinions we have. So the gaps between the cliques grow wider, and particularly in times of COVID and the lockdown that we've had here, and that we seem to be maybe heading back into the isolation perhaps adds to that, and we see it more and more. So at a time where we need to be getting our act cliques and talking with understanding with others with different views, we're actually psychologically in a difficult position to be able to do that. And so that's what we might generically call the lack of trust manifests itself in the work that I'm doing. And that's how I see it with almost everybody that I work with, including myself, by the way. It's not an easy thing to conquer.

Sean Blake:

So what does your day to day look like, John? I think your official job title is Digital Transformation Consultant. You work for Adaptivist as one of the most well known Agile consulting practices in the world, I would say. What does that mean for you day to day? What does your nine to five look like?

John Turley:

So we're really involved in three things. I'm really involved in three things. And it's all about learning, collective learning, organization learning. So we're involved in a lot of original research. We do that original research with a number of academic partners in a program that we're putting together. We've been doing a lot of the research on our own. But as it gets bigger and more credible, other partners are coming to join us and they're very credible partners.

John Turley:

And the research is uncovering new learning. And that new learning points us to new consulting practices where we can take that learning and embed it into a workshop, say or how we might use the research instruments that we've borrowed from academia in the real world to measure social networks or psychological complexity or the amount of autonomy in the environment. So we can then use that to work with teams to help them shift from a sort of functionally oriented way of working to a cross functional way of working, which whether we're talking about safe and Agile release chains, or whether we're talking about Lean software management and value streams, whether we're talking at a team level or an organizational level, the challenge is essentially the same. We need to orientate ourselves around the creation of customer value in cross functional teams that are focused on delivering that value, not just delivering on their function. And that switch brings with it some deep, complex, deep psychological challenges that we're just not really equipped to meet. So we bring sort of the people and culture element, the tools and the Agile methodology simultaneously to bear in teams to help them make that shift. So that's really what my day to day work looks like, so the research and the practice.

Sean Blake:

Okay, research and practice. And when it comes to the practice side and encouraging that cross functional collaboration, how hard is it for people to get on board with that recommendation or get on board with what the company is trying to do?

John Turley:

For most people, it's really hard. So my experience before doing the research that I guess we started a couple of years ago I was just referring to, was something like this recently. We'd often get, so I've worked in the Agile space for a long time, I don't quite know when I started working in that space, in other words, full space, but a decade or two, let's say, and now bumped into a repeated problem, we get our, let's say, thinking of a specific example with a specific client about three years ago, very functionally orientated, trying to make that shift into cross functional teams. So we got a group of five people together from different functions, so designers, testers, developers, a couple of ops people, and between them, they should be able to obviously, launch some working code within 10 days or whatever. We were probably trying to spring into the real world.

John Turley:

And they were all great people. I knew them all personally. I spent time working with them all. They were very sort of Agile in the way they approached the development of the software that they did, and we put them in a room virtually to begin with and we asked them to produce a piece of code that works across functions, produce a piece of code and release it at the end of the week. And they didn't. And we thought what on earth happened there? We didn't really understand this, so we tried it again. But we assumed that the problem is because we'd done it virtually.

John Turley:

So this time, we got everybody together in Poland, as it happened in a room, we set it all up, we talked to them at the beginning, then people like me sort of left the room and let them get on with it, got to the end of the week, same outcome, nothing has happened. And if you talk to them, while they say, "Yeah, my phone pinged and there was a support incident, and you just couldn't.", and they had lots of very plausible reasons why they couldn't come together as a cross functional team. But the fact remains twice in a row, the most capable people haven't done it.

John Turley:

So we had a really long think about it, one of the senior leader in the business and myself. And we realized that the only thing that could be happening, the only thing that could be going wrong here is that there must be some sort of breakdown in the dialogue between the group in the room. So we ran it, we ran the workshop, let's call it for a third time. And this time, we had somebody else in the room just watching what was going on.

John Turley:

And they spotted something happened really early on. One of the people from the UK said to one of the Polish developers, they said, "Look, think of us like consultants. We're here to help you, to transfer knowledge to you so that you develop a capability so that you can do this on your own." And at that moment, the person who was in the room said that the dynamic in the room seemed to change. People glazed over. And I think what it was is that that word consultant that the English person had used had a different meaning for a colleague in Krakow. I think that meaning, the meaning of consultant meant, we're just here to tell you what to do and not actually do anything and put ourselves on the hook for any work, just kind of watch you do it.

John Turley:

And I think at that point, they kind of went, "Okay, well, all right, I get it, same old, same old. We'll do the work you English guys talk about it, because it's an English company.", and that breakdown started to occur. So the question we started is, I've seen that all over the place. So the question we started to wrestle with in our research is what's happening in those moments when that dialogue breaks down what's happening?

John Turley:

And what we've discovered is that there is a number of research studies, the biggest is about 10,000 people, that shows that around about 50% of people are at a level, and this is 50% of leaders in a study of 10,000, so for middle management, senior management, so it's a skewed number. So in reality, in software teams, it's probably more than 50% of people have reached a level of psychological complexity that suits the environment as it was, but has some limitations in cross functional working.

John Turley:

So they have a mindset, a way of making their reality that works well in a functional environment, but it's challenged in a cross functional environment. And that mindset, this way of thinking, which is very prevalent, is a way of thinking where individuals draw their self esteem from their expertise, just to put it very short, simple as an oversimplification. And the thing is, if you're drawing your self esteem from your expertise, when your expertise is challenged, it feels personal.

John Turley:

If it feels personal, people are likely to get defensive. And it's not because they're stupid, or they're not interested or they don't want to, the psychologists can show it's a level of psychological complexity, where that's just how our minds work. That's just how our meaning making works. Now, if that's the stage you're at, if we imagine me as a developer sitting down with a tester, and the tester's saying to me, "Look, the way you've written the code isn't the best way to do it for me, because I can't test it."

John Turley:

If I'm drawing my self esteem from my expertise as a developer, I'm likely to reject that, and might even start to think thoughts like, "Well, I think what really needs to happen here is that you need to be a better tester." I think that's the problem. And then we get this separation. Now at the next stage is psychological complexity. And these stages are in a framework that we do move through these stages. Again, it's an oversimplification, but it's observable and measurable. At slightly later stage of psychological complexity, things start to change. People start to recognize that the world is much more complex, that it's not black and white. And actually, there are multiple ways of doing things.

John Turley:

So to go back to my example as a developer, the tester might say to me, "This isn't the best way to write the code as far as I'm concerned." And what I'll hear is the, "Oh, as far as I'm concerned." It might be as far as I'm concerned, it's not fair enough. How can we change the way I'm writing the code to make it easier to test? But I can't do that if I respond like it's a personal criticism, you know what I mean? So what we started to uncover in the research is a correlation between how successful cross functional teams can be, and the level of psychological complexity in the leaders and the individuals in that team.

Sean Blake:

Interesting. So there's a book that we've been reading at Easy Agile recently called Radical Candor. And really, it comes down to giving constructive feedback to each other, not in a way where you're attacking them personally but you're trying to be honest around how we can work more collaboratively. And like you said with that example, how can a developer write code in a way that the QA tester can actually perform the tests on it? For someone who's new to cross functional ways of working, what advice does the research have around preparing that mindset to receive some of that radical candor, to receive that feedback in a way that you don't take it personally?

John Turley:

Well, so it's a great question, you put it really well, because radical candor is fine. We have, I work in a team that is very candid. We have some difficult conversations, and we don't even really dress our words up. And nobody gets offended. We just know that it's a shortcut. We might get our words wrong, but it's a shortcut to unlocking value to finding out how to work together. But it's not about the words that each of us picks to express. It's about how the other chooses to react to the words landing, as much as now that's a dialogue, it's a two way thing, it takes two to tango.

John Turley:

And the way we can develop a mindset that's more suitable to cross functional work is interesting. First of all, we've got to get out of comfort zone. We've got to be prepared to get out of our comfort zone, not far necessarily, and not for very long necessarily, and not without support and understanding from the colleagues around us. But we do need to get out our comfort zone. Otherwise, psychological growth can't occur. This is what I'm talking to about now is the work really of Robert Kegan and Lisa Lahey, who do a lot of work in dialogue on radical candor.

John Turley:

So we've got to get out of our comfort zone. But we've also got to be addressing a complex problem with a group of people when we're outside of our comfort zone. And that complex problem has to be meaningful, and it has to be salient, it has to be something that we care about, it has to be something relevant to our day to day work. And if we've got those characteristics in the environment that we working in, then there is an opportunity for individuals to choose to develop their own psychological complexity.

John Turley:

So that environment that has those characteristics, we would call in Kegan's word a deliberately developmental environment, because we can't separate the development of individual mindsets from the environment that that mindset functions in. The reason most of us have got the mindset that draws self esteem from expertise is because that's actually what most environments that we work in or not. That works in a functional environment. It's where you get promoted, it's where you get hired. It's where you get your Scrum Master badge and all that other stuff that gives you status and makes you feel good.

John Turley:

The world that we work in for many of us honors that expert way of making meaning. It doesn't honor learning and admission that yours might not be the best way to do things in the same way. So we have to shift the environment to support the individual to choose to take that developmental step because it can't be something that's done to them. You can't make people develop a more complex psychology. You can't train them to do it. You can only give them an environment that supports that step if they want to take it and if they don't, fair enough, that's okay. But maybe cross functional teams for them, if they don't want to because the hard place is to work.

Sean Blake:

Is it a problem that people find their expertise or find their self esteem from expertise? Is part of it encouraging men to find their confidence in things outside of their work or is expertise an honorable pursuit?

John Turley:

I wouldn't say it's a problem at all. Expertise, and the development of expertise is an honorable pursuit. Drawing your self esteem from your expertise is a very necessary part of our psychological development is a stage that can't be skipped really. I said to you before that I don't like to say things like that without the research base, but the psychology certainly imply that it's a stage that can't be skipped. So we've got to do it. We've got to go through this stage. The stage before we're drawing our self esteem from our expertise is where we draw our self esteem from our membership of the group.

John Turley:

And that's very important too, if you think of us as children or being part of a group is essential for our survival, so ingratiating yourself into that group, not rocking the boat, so we don't jeopardize our group membership is critical. But at some point, people start to realize, well, actually, I have to rock the boat a little bit if we want some direction. So separating your meaning making from drawing your self esteem from the group to drawing your self esteem from your expertise is a development in that sense. Drawing your self esteem from your expertise means the best way to write this code is let me train somebody to do it.

John Turley:

It's critical. But like all developmental stages, it has its limitations. So it's not problematic in any way, unless the individual is in a complex environment in which that expert way of making meaning isn't well suited. And then you got a mismatch between psychological complexity and environmental complexity. And when you've got a mismatch like that, the individual's anxiety will go up probably, employee engagement goes down, certainly wellbeing goes down, people revert to an earlier way of making their meaning that's more embedded in their expertise or the group, just to the point, they need to get more sophisticated.

John Turley:

So the problem is the mismatch between psychological complexity and environmental complexity. That's why we need to support, as the world gets more complex, that's why we need to get all get better at supporting the development of individuals into a level of psychological complexity that suits the more complex environment. That's kind of the nub of the problem. Nothing wrong with being an expert in drawing your self esteem from your expertise. People have done it forever, and will continue to do so. Every time you get in a flash car and you feel good, because you're in a car, you're drawing your self esteem from the status symbol, which is very similar to your expertise. As a young man, I put on my sharp suit and I feel a million dollars. Nothing wrong with that at all, but it's limited. That's the problem.

Sean Blake:

Understood, understood. So you've spoken about research and measurement and having an evidence based way of making decisions. When it comes to this cross functional way of working or digital transformation or teams moving from the old way of working to an Agile way of working, do we have evidence to say one way of working is superior to another way of working? And when you're talking to these clients or these customers, can you guarantee that if they work in this way, it's going to lead to better outcomes for the business? How do you approach that conversation?

John Turley:

No, I can't do either of those things. So I would never go anywhere near nor would I research saying that one way of working is better than another way of working or we can say like the mindset and the environment that there are ways of working that will work better depending on the problem that you're trying to solve. But it's very unlikely that one could be considered right and the other wrong in all sorts of circumstances, but more than that, I would say that doesn't matter what your way of working is or a team's way of working is. If the mindset is the way of making sense, if the reality doesn't also shift, then you're just following a new process, a new way of working with the old way of thinking, and you're going to get the same results just with different words.

John Turley:

So for me, that isn't entirely true, I'm quite biased. I guess in the work I do, I've got quite a perspective. If you shift mindset, then everything else will drop into place. If you change everything else, but don't shift mindset, nothing else will drop into place. What we can say however, is that there are three things, let's call them the three elements of a cross functional team that are hidden to people in organizations at the moment.

John Turley:

So generally, we think if we've got people with the right experience and skills working suitably hard, then they're going to work as a successful cross functional team. And if they're not, they're either not working hard, they're not the right type of person, or they haven't got the right set of skills, so fire them and hire somebody else or give them or put them on a training course, and that solves the problem, which of course it doesn't.

John Turley:

We would say that there are three other elements that remain hidden parts of the cross functional team that are more critical than that, and we're beginning to be able to demonstrate that there is a correlation between these three things that I'm going to tell you about on both employee engagement and team performance.

John Turley:

And these three hidden elements are the structure of the social networks that underpin the way people work. So if we think about how we as groups of human beings organize ourselves, we might think about hierarchies and hierarchy diagrams and old charts and bosses and stuff. That's not really very important for a cross functional team. What's much more important is the social network that develops across that team, who works with whom and when and how, right? Do the developers and the testers and the testers and the ops guys and the designers and the technical architects, do they all work together in a cross functional team?

John Turley:

Now that's a social network. That's a network that's formed through individual autonomy because they want to get the job done not because the boss says you've got to go and do it. In fact, it can't be done because the boss says go and do it. So we have worked with some friends in academia with actually an Australian company called Polinode to measure their various ways we can get the data, what those social networks look like. And the structure of those social networks is key.

John Turley:

As we look at the structure of social networks, we can see whether those teams look like their function, sorry, organized hierarchically, or were they organized for cross functional working because of the network structure. So network structure is one element. The other is psychological complexity. So we've worked with a gentleman called David Rook, who did the original research and developed a psychometric instrument that can measure an individual's stage of psychological complexity, both the structure and the substructure. And that mindset complexity is also linked along with network structure to where the teams can function cross functionally.

John Turley:

The third thing that was the hardest bit, the last bit of the jigsaw that we sort of put into our hypothesis is we need to have adequate degrees of autonomy. We needed to develop a much better understanding of what it means for teams to be autonomous than we had, and how that autonomy relates to control and how control undermines autonomy and how we all tend to be orientated, to taking the cues in the environment either as instructions, which we must comply with or invitations to be autonomous. And we now have another psychometric instrument. So the third instrument that we use, we call the motivation orientation scale, excuse me, that can measure an individual's likelihood to interpret inbound information as an instruction or an invitation to be autonomous.

John Turley:

And once we know that, we can start to challenge this common perception within product teams, software teams that the team is autonomous, because everybody thinks they are autonomous. And in fact, everybody is, research shows mostly autonomous, but we might be almost entirely autonomous, or we might be 60% autonomous. We can measure this. And then we can say to teams, "Look, you are autonomous as a bunch of individuals. But you also have this control thing going on where you're responding to inbound requests."

John Turley:

And we need to be more autonomous. So once we can start to measure it, we can start to challenge their ideas of how autonomous they are. And we can start to examine where the teams are choosing to respond from that control orientation or their autonomy. So they're the three things, autonomy and control, complexity of mindset and network structure, equal employee engagement and team performance. That's what our research says. So what we can say is, to your question in the beginning, there is a network structure, a level of psychological complexity and the amount of autonomy that correlates to successfully working as a cross functional team. And in that sense, we might think that those levels are right, in some sense.

Sean Blake:

Okay. So what does a 100% autonomous team look like? And do they still have interaction with, say the executive team on a day to day basis? Or are they at odds, those two concepts?

John Turley:

No, they're not at odds. They do have, they might have day to day, I suppose they would, they will have either directly or indirectly interactions with the executive team. So the first thing we need to bear in mind here is that the research that we're leaning on is something called self determination theory, which is a theory of motivation. And it has quite a specific definition of autonomy, which is not what we might normally think. Often autonomy is taken to mean as sort of the general use of independence. So if we buy a company, we might leave it to run autonomously, which would mean we just left it alone for a while. And autonomy in this context doesn't mean that. It means individuals acting of their own volition, individuals deciding how to act towards a common purpose. So the team has to have the vision which they can self organize around. You can't self organize without autonomy. If you don't got autonomy, you have to wait to be told what to do. And then it's not self organization.

John Turley:

So autonomy leads to self organization, and self organization can be around a common vision or a set of goals or an OKR is quite a sophisticated way to do instead of management by objective, then we can self organize in a way that sort of honors the need to be part of an organization, doing some coordinated work, but that doesn't rely on a manager telling the individual what to do.

John Turley:

That's what an autonomous team looks like. An autonomous team, you need the autonomy is really a self organizing team. And the self organizing team is deciding what the team ought to do in order to achieve a wider objective, which could be integrating with other self organizing teams. And obviously, the direction is set often by the executive. So all these things sort of come into play. It's not a question of control on the one hand or autonomy on the other or Agile on one hand or waterfall on the other.

John Turley:

So we're going to blend the two. We're going to balance them. And that balance needs to shift not only across teams, but also depending on the level that the organization is, that the team is working in the organization. And what I mean by that is the need for control and measurement increases in many ways as you go higher up the organization. So we want high degrees of autonomy at a team level where we're creating customer value. But we need to recognize that that self organizing team has a legitimate requirement to integrate with some elements of controlling the organization, because if we have some elements of control, then we can't do the accounting and be accountable for where we spend investors' or shareholders' money, you know what I mean? So it's much more complex in the sort of the dichotomized world that people tend to look at, which is very black and white. Is it Agile or is it waterfall? Are we autonomous or are we control orientated where you're both and the blend of which needs to shift depending on the environment here.

Sean Blake:

Okay, okay. So there's always a need for a bit of control on top of the autonomy.

John Turley:

It's a balance, right? We're all comfortable with control, aren't we? We all comply with speed limits, for example. We're perfectly okay with that. Control is not a dirty word. Some will do things that we're told to do sometimes, and we're happy to do it. Sometimes we do it begrudgingly. We're not happy to do it. Sometimes we reject it. There's nothing wrong with control in itself. It's the overuse of control to coerce people to do things that they don't want to do. That's when it becomes problematic because it undermines an individual's autonomy, which is a basic, universal psychological need. We all need to have a sufficient degree of autonomy to feel well.

Sean Blake:

Okay. Okay. So we know that Agile's had a good run, it's been decades now. So do you still find that you come across the same objections when you're speaking to these executive teams or these companies perhaps from more traditional industries? Do they still have the same objections to change as they did in the past? And how do you try and overcome them?

John Turley:

Yes, they do. So one of my strange experiences as a young project or program manager, whatever I was, is that when I would end up in a room full of software developers who were Agile, probably the language they would have used at the time and a bunch of infrastructure engineers who followed waterfall, and the distaste for one group for the other, it was almost visceral, and you could see it in them. There would be a bunch in, I don't know, Linux t-shirts and jeans, and then the infrastructure waterfall people would probably be wearing suits.

John Turley:

I mean, it was really obvious, and it was hard to bring these groups together. That was my experience in let's say, around about 2000, I sat with a client yesterday, who said exactly the same thing. They said that in their organization, which is going through a very large, Agile transformation at the moment, they said, "These are their ways. We kind of got people at the two extremes. We can sort of bookend it. We've got the waterfall people who think their way is best and we got the Agile people who are totally on board with Agile transformation."

John Turley:

And what I heard when the individual said that is quite senior leaders, the Agile people are on board with the Agile transformation brackets because they think their way of working is best. And what I tried to point out to that senior manager was that that was one group, there were perceptions anyway, that one group was into Agile and got cross functional working, all that got cross functional working and the other group didn't, actually the two groups were operating in the same way.

John Turley:

They both thought their way of working was right, and one was espousing the virtues of waterfall and the other Agile, but the fact was they both thought that they were right, and the other was wrong. And they were both wrong in that. Waterfall works really, really well in a lot of scenarios. And full on Agile works really, really well in some environments. In some environments, it's quite limited by the way, in my opinion.

John Turley:

My friend and colleague, John Kern, who was a co author of the Agile Manifesto in 2001 or 2004, whatever it was, I can't remember. He says, "I love waterfall. I do loads of waterfall, I just do it in very small chunks." And because the fact is we've got to do work sequentially in some manner. I can't work on an infinite number of things in parallel. There has to be a sequence.

John Turley:

And that really, when I heard him say that, it sort of filled my heart with joy in a way because for somebody with a waterfall background, I used to say, "Look, I don't get this. In waterfall project management, we're talking about stages. And in Agile, we're talking about sprints." And they've both got an end. One's got a definition of done. And one's got some acceptance criteria, and they both got a beginning. The only difference is the language and the duration.

John Turley:

So what if we make sprints, sorry, stages 10 days long? What's the difference now? And yet people would say, "Well, we're Agile, and we do sprints, and that would still be a stage." Come on, we've got to find some common ground right to build a common meaning making between large groups of people. Otherwise, only the Agile listeners amongst us can work for Agile organizations, and everybody else is doomed. And that's not true, is it? That's nonsense, right? So we've got to come together and find these ways of working as my friend John Kern points out so eloquently.

Sean Blake:

Okay, that's good advice. So for these, some people that you meet, there's still this resistance that has been around for many years. How do you go about encouraging people to get out of their comfort zone to try this cross functional way of working and be more transparent, I guess with contributing to the team and not necessarily pushing towards being just an individual contributor?

John Turley:

Another great question, Sean. So there are a couple of ways we can do it. The psychometric instrument that I mentioned earlier, that can sort of measure I kind of always put that in inverted commas, because it doesn't really measure anything, it assesses, I suppose, is a really, really powerful tool. Off the back of that measurement, the psychologists that we work with can create a report that explains lots of this sort of meaning making stuff, adult developmental psychology to the individual. And it tends to be mind blowing. It really shifts people's perspective about what they are and how they're operating in the world.

John Turley:

Once people start to understand that there are these developmental stages, and we all move through them potentially to the last days of our life, we can start to see the disagreements. They just start to fall away. Disagreements start to fall away, because they cease to be seen as opposing views that can't be reconciled, because I'm this type of person and they're that type of person.

John Turley:

And they start to be seen as incompatibilities in meaning making. So people start to go, "Okay, well, I think this and you think that. How are we both making our meaning around this, that means we can see other's perspective?" And immediately, then you've started to find a mechanism to find some common ground.

John Turley:

So the leadership development profile report, which is the report that comes from the psychometric instrument really sheds a lot of light on for the individual, both on how they're working and what development looks like, what psychological development looks like for them. So that's a powerful tool. We have another service that we call dialogue partnering, which we're piloting, which is sort of what over an eight or 10 week program, it's a one on one collaborative inquiry into how an individual is making their meaning, and what the strengths of their meaning making and the limitations of their meaning making are.

John Turley:

And once people start to realize that the way, the reason they feel defensive because the way they code has just been criticized is because they're drawing their meaning from being the best coder on the planet. But there is a development path that leaves that behind, which is where many, many people get to. It's kind of like an a-ha moment, people just realize that reality is different to what they thought and it can be adjusted.

John Turley:

So the LDP, the Leadership Development Profile reports, dialogue partnering, and working with senior management to create a deliberately developmental environment, which does those things I mentioned before, they're the critical tools that we use to help individuals unlock their own psychological development. And the question is, of course, why would they be motivated to do this? Why would they care? And they care, because 80% of people have got a very low level of engagement in their work. Most people are treading water, killing time. It's not a joyous place to be. Once people start to work in cross functional teams and get involved in joyous work with their colleagues to create things they couldn't, which is a basic human instinct, that's a buzz, then you come into work and enjoying yourself.

John Turley:

That's what I said to you at the beginning of that call, right? I'm having a great time, I'm working with some brilliant people unlocking new knowledge that we believe humankind doesn't have. That's a buzz. I'm not treading water in my role, you know what I mean? And this isn't unique to me. In my view, the whole world could be like that. We could all work in roles like that, maybe that's got a bit far. But certainly, many more of this could then currently do to get on board with the psychological development and enjoy your role more, enjoy your work. There's a lot of time.

Sean Blake:

Yeah, I really resonate with what you said about the buzz. And I've seen that happen when the light bulb comes on in people, and it's no longer this factory line of work getting passed down to you. But you realize you're now part of a team, everyone's there to support you, you're working towards a common goal. And it's transparent, you can see what other people are working on, and you're helping each other build something together. It's actually fun. For the first time in a lot of people's careers, it's a fun and enjoyable experience to come to work. So that must make you feel really good about doing what you do.

John Turley:

Yeah, it does. It's why I get out of bed, and it's what I've been about for 20 years trying to unlock this, really help other people unlock this. I got a phone call from a colleague the other day who said they were doing some exercise, and they were thinking about their new role. And they thought to themselves, this is what it feels like to do joyous work.

John Turley:

I mean, that [inaudible 00:42:51] job done, because this is a very capable individual. Once they're feeling like that, you know that they're going to do great things. When they're feeling like they're other people feeling, that people are clot watching, or there's this culture of busyness, where we can't admit that we don't know things. And then we've got to be in a meeting doing something, in the transparent world that you're just talking about, if I've got any work to do, I can just sit and say, "I'm going to work today, I'm waiting for more stuff to write." And it's not a bad thing. It's like, great, you're working at a sustainable pace. That's a good thing. I worked for a Swiss bank for years and years, working at a sustainable pace but nobody was interested, you need to work at a full on flat out unsustainable pace. And when you're burned out, you can go and we'll get somebody else to come in and do it. That's how it works. That's miserable.

Sean Blake:

It's not what we want, Sean, is it? It's not what we want. And unfortunately, a lot of people have been there before and they've experienced it. And once they see the light, they never want to go back to it, which I guess is a good thing once you recognize that there's a better way.

John Turley:

Yeah, agreed.

Sean Blake:

Yeah. Okay, well, I think we're going to wrap up shortly. I do have two more questions for you before we call an end.

John Turley:

I'll try and keep the answers brief.

Sean Blake:

No, that's fine. I'm really enjoying it. I could probably go for another hour but I know we've got other things to do. So in the research, I've read some of your blog posts, and I watched some of the talks that you've done and events in the past, and you speak about this concept of hidden commitments. And I just like to learn a bit more, what is a hidden commitment? And what's the implication?

John Turley:

Great question. So Robert Kegan and Lisa Lahey, developmental psychologists, wrote a book called Immunity to Change. This is a book that I read here a few years ago. And in there, Bob and Lisa talk about hidden commitments. And so they start by pointing out that we all make New Year's resolutions and they all fail. We really mean them when we make them. And when I was in my late teens, maybe I really did mean them when I made them. But I could never keep them.

John Turley:

In another book, Kegan points out, I think it's in the book called The Evolving Self. He points out that a large majority of men, after they've had heart attacks, I think it's a study in America. But it's been a while since I read it, I think it's six out of seven, don't change either their diet or their exercise regime after they've had a heart attack. And the reason he uses that as a case study in the book, because he's pointing out that it's not that these people don't know what to do, you need less calories in, more out. And it's not that they're not motivated to do it. They've had a near death experience. They'd like to stay alive, we presume.

John Turley:

Yet still, they don't make any meaningful change to their diet, their exercise regime, why not? And what Bob and Lisa say in the book from their research is that it's down to hidden commitments. We all have our way of making meaning. We have our values and our assumptions that we absorb from society as if by osmosis. And we don't question them. We can't question all of the assumptions that we absorb as we grow up. It's just not possible. So we have these hidden assumptions that we're committed to hidden commitments. And sometimes, these hidden commitments conflict with our stated objectives. And when the hidden commitment conflicts with our stated objective, the result is that we get very confused about the fact that the stated objective sort of falls by the wayside, and we don't really understand why. We might think, I would think a common out, because I just need to try harder, I just need more willpower. I just need to stay the course. And it's not true very often. There is something else in your meaning making this conflicted with our stated objective. And once you can surface it, then you can start to examine that hidden commitment, and you can play around with it.

John Turley:

And when you can play around with it, then you're adjusting your meaning making. And the technique that we use in dialogue partnering comes from Bob and Lisa's book, where we're essentially uncovering those hidden commitments and seeing how they conflict with commitment. So that's sort of, and then once you can see it, and you can experiment with it, you can start to unlock change in yourself. Peter Senge, I think he's director of innovation. He's very famous, director of innovation for MIT. And he has a beautiful little quote, something like, "What folly it is to think of transforming our organizations without transforming ourselves?"

John Turley:

We need to change our relationship with power in order to change the way power is distributed across our organizations. And that's an example of a hidden commitment that we don't normally think about. We just think we can empower people magically, whilst retaining all the power for the senior manager. And that just doesn't work. There's a hidden commitment, conflicting with the idea that we want to empower our teams, which is a quite flawed idea.

Sean Blake:

Wow. Okay. Well, I really like the approach to work and looking at the social structure, the social networks, and the psychology behind it all. It's really fascinating and it's not something I've really come across before, especially in the Agile space. So that's really unique. Thanks for sharing that, John. Last question for you. 2020 has been interesting to say the least. We've talked about some things that have stayed the same over your career, some things that have change. What do you think is going to come next, looking forward to the next five, 10 years? What are some of those trends that you think are really going to stand out and maybe change the way that your work, it changes the way that that your nine to five looks or changes the way that you interact with your clients?

John Turley:

I think that this won't just change the way my nine to five looks. It will change like everybody's nine to five looks. I think that the world is in a difficult place. A lot of us are upset, and it looks like a bit of a mess, and we're all anxious, I think. A lot of us are anxious. But as a friend said to me, he was quoting somebody else, never let a good crisis go to waste. The amount of changes, a lot of energy in the system, the amount of changes in the system is palpably changing things.

John Turley:

Many of us recognize there must be a better way of doing things because our ways of organizing ourselves as society, including our organizations is collapsing. It doesn't work anymore. People are realizing through work that people like the names I've mentioned, and through our original research, I hope will sort of contribute in an original way to this, that there is a better way of organizing ourselves that humankind does have the knowledge and the experience to do what we need to do.

John Turley:

It just isn't in IT. We need to look outside of it to what the psychologists say about mindset, not what the Agile people say about mindset. That's a radical idea. And as we import this learning and this knowledge, we have a framework that helps us understand to a much greater degree what's really going on, and how we can unlock real change. So everything that I talked about today, very little of it is original. We have some original work I can't really talk about. Does it matter? The knowledge is out there. If we do the people and culture bit and the tools and the methodology together, then it scales, then we change the way organizations work, which is going to change everybody's nine to five.

Sean Blake:

That's great. It's bringing it back to basics, isn't it? What we know about human beings, and now let's apply that to what we know about work. So that's really eye opening. And I've learned a lot from our conversation, John. I've got a few books and a few research papers to go and look at after this. So thank you so much for appearing on the Easy Agile podcast, and we really appreciate your time.

John Turley:

Sure, my pleasure. I mean, I love and we love at Adaptavist to sharing what we're doing. So we can all engage in more joyous work, man. So thanks for helping us get the message out there.

‍

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.

"I absolutely loved my conversation with Sarah, she shared some amazing advice that I can't wait to put into practice!"

We spoke about the agile mindset beyond IT & development teams, how teams such as marketing and finance are starting to adopt the methodology and the benefits of doing so.

In celebration of international women's day, we discussed the future of women in agile, and steps we should be taking to support one another towards an inclusive and enabling environment.

Be sure to subscribe, enjoy the episode 🎧

‍

‍

‍

Transcript

Caitlin Mackie:

Hello everyone and welcome back to the Easy Agile Podcast for 2021. Each episode, we talk with some of the most interesting people in tech, in agile, and in leading businesses around the world to share fresh perspectives and learn from the wealth of knowledge each guest has to share. I'm Caitlin and I'm the Graduate Marketing Coordinator at Easy Agile and your host for this episode. We are thrilled to be back and have some amazing guests lined up this season. So to kick us off, I'm really excited to be talking with Sarah Hajipour.

Caitlin Mackie:

Sarah has so much rich and diverse experience in the agile space. She's an agile coach, a business transformation leader, a project and program manager, and more recently a podcast host and author. She's the jack of all trades and has been in the business agility space for over 10 years. In this episode, Sarah and I chat about the significance of goal setting and in particular goal setting in unpredictable times. We chat about her most recent projects, the Agility Podcast with Sarah Hajipour and her book on Agile Case Studies.

Caitlin Mackie:

And of course with International Women's Day coming up, Sarah shared some amazing advice and her thoughts on the way forward for women in agile. She highlighted the importance of raising your hand and asking for help when you need it, as well as embracing qualities that aren't always traditionally thought of in leaders. It was such a thoughtful and insightful discussion. I got a lot of value out of our conversation and received some great advice, and I'm really looking forward to putting into practice. I know those listening will feel the same. Let's jump in.

Caitlin Mackie:

Sarah, thank you so much for joining us and spending some time with me today.

Sarah Hajipour:

Sure. Thanks for having me.

Caitlin Mackie:

So being our first guest for the year, I wanted to ask you about any new year's resolutions. Are you on track? Are you a believer in them or do you have a different type of goal setting process?

Sarah Hajipour:

That's a great question because we discussed this with a couple of friends and we realized new year's resolution is always going to be some kind of like a huge goal that we don't know if we're going to meet it or not. And thinking agile business agility and as an agile coach, I believe in the fact that let's have smaller goals and review them every three months, every six months and see where we at. Instead of looking into huge goals that we don't know what's going to happen because there's always a lot of uncertainties, even in our personal lives regarding the goals that we set up for ourselves. So yeah, that's how I look at it. Quarterly, quarterly personal goals. Let's say that.

Caitlin Mackie:

Yeah. Yeah. I love that. Yeah, I think if the last year has taught us anything, I think we can all agree how unpredictable things can become. So those original goals.

Sarah Hajipour:

That's true.

Caitlin Mackie:

Yeah. The original goals might have to take a couple of detours. So what would be your advice for setting career goals in uncertain times?

Sarah Hajipour:

That's a great question. For career goals I believe it really matters that you do something that you're interested in at least. If you still haven't found your passion, that's fine especially people like young professionals. It's okay if you haven't found your passion yet, but you can still follow a basically career path starting with things that you like to do, kind of you enjoy and you learn through the way.

Sarah Hajipour:

I was listening to one of the fashion icons on YouTube a couple of days ago and the interviewer was asking her, "What was your career path? How did you get to this place you are now?" And I loved what she told everybody, the students, and that was go and find a career, find a job and learn. You first need to learn a lot of skills before you decide what you're actually good at. You decide, you understand what's your weaknesses and your strengths, right? Because not all of us have these amazing ideas all the time and that's fine.

Sarah Hajipour:

I'm not very much pro-everybody has to be a visionary and everybody has to have like big, shiny goals and ideas. I think that's perfectly fine to just find the kind of job that or the kind of career path that you're comfortable with and then sometimes get out of your comfort zone and then discover as you go. Life is to explore, not to just push yourself on the corner all the time and just compare yourself with everybody else.

Caitlin Mackie:

Yeah. I love that. That's great advice. So you've recently added podcast host and author to your resume. Were they always career goals of yours?

Sarah Hajipour:

No, absolutely not. Well, I'm a little bit of an introverted person. So kind of sit in front of a camera even talking and having people hear me was always like, "Oh my God, I know I need to talk about this even with my teams and stuff," but I will do it only if it's necessary. What got me into podcasting was that I figured there's a lot of questions that I'm finding answers when I'm having conversations and meetups and in different groups, professional groups that I'm in. And I wanted other people to hear those as well. I talked to people who have great insights and have been way longer than me in the career. So I'm learning at the same time. And I wanted to share that learning with everybody else. That's the reason I'm doing the podcast.

Caitlin Mackie:

Yeah, that's great. Yeah, I love that. And I think you kind of touched on this earlier, but I think being in the agile space, sometimes it can be a nice reminder for you to have a bit of a focus, but then reflect and understand sort of where to be more effective and adjust accordingly. I know you mentioned that with your career goals, do you think that those agile principles can be applied beyond the usual use case?

Sarah Hajipour:

I do. I believe that it's a very intuitive like agile is a very intuitive way of working and a way of thinking. That's why now it's expanded to other industries. They didn't stay with DevOps and IT and development. It is now a lot of different industries adopting this because it's a mindset change. And just not just using scrum. It's not just using Kanban. It is about understanding how to be able to reflect on and adapt to the faster changes that are happening in the world. And that also applies to our personal lives as well.

Sarah Hajipour:

I mean, I used to have set goals when I was 18-years-old, I'm going to be this at 30, but did they happen? No. In some aspects I achieved much, much more. And in some aspects I just changed my goal. I think the changes that are happening in the world that are more rapid, it demands us to change as well. Yeah.

Caitlin Mackie:

Yeah. Awesome. So just to circle back a little bit there for your podcast just for our audience listening, what platforms can they access your podcast on?

Sarah Hajipour:

I'm on all of the main platforms. I'm in Apple podcasts. I'm in Spotify, I'm in Amazon. Most of the prominent podcast platforms.

Caitlin Mackie:

Awesome. And then just again, for our audience, your podcast is called the Agility Podcast with Sarah Hajipour.

Sarah Hajipour:

That's correct. Yes.

Caitlin Mackie:

Awesome. That's great. What do you think has been the most valuable lesson you've learned from your podcast so far? Is it something a guest has shared or something you've learned along the way?

Sarah Hajipour:

What I have learned, I have learned a lot from the people that I interview because I make sure that I talk to people who know more than me and have been in this field more than me, and in different industries. The main thing I would say is that agile business agility is about mindset rather than the tools and processes. And the fact that the world overall is moving towards a more human-centric way of working.So basically that's why I say agile is more intuitive rather than just following ABCD. Yeah. This is the core, the main thing that that I have learned from my interviewees.

Caitlin Mackie:

Yeah, amazing. You've also started writing a book at the moment. Can you tell us a little bit more about that? How did that project begin?

Sarah Hajipour:

I actually love this project. In this book, the way I actually started writing the book was the book came first and then the podcast happened. I attend a lot of meetups. So for young professionals and even for professionals who are very much skilled in what they do, meetups are great place to meet and expand your network and learn from your peers. So I was attending all of these and I was learning from people. And then I decided I really want to have one-on-one conversations with them. And eventually I figured that a lot of the agile coaches, a lot of executive levels and a lot of consultants, they have a lot to share, but I didn't see any platform that kind of unifies that.

Sarah Hajipour:

I said, "Okay what are the learnings that we can share?" A lot of the mistakes because of the meetups groups, people feel safe to share and be vulnerable. And I was in multiple meetups so I heard very similar stories from people, the mistakes that have been repeated by a coach somewhere else. So I thought that'd be a great idea to put these in agile cases. So it's going to be Agile Case Studies and share it with everyone so. Especially the young coaches or stepping into the business, there's a lot of unknowns. I don't want them to be afraid. I don't want them to think, "Okay, this is a huge task." There's always going to be a lot of unknowns.

Sarah Hajipour:

Yes, I just see that. I kind of want to give that visibility that everybody else is experiencing the same, even if they have 25 years of experience, which is amazing, right?

Caitlin Mackie:

Yeah.

Sarah Hajipour:

And that's the reason I started writing the book. So I interview with agile coaches and agile consultants that have been around at least five to 10 years and led agile transformation projects. And then from there, one of my interviewers once said, "You should do a podcast. I like to talk about this too." I'm like, "This is great" and that was like the week after I was like running around looking for tools to start my podcast.

Caitlin Mackie:

Oh, amazing. Sounds so good. What's the process been like? How have you found from ideation to where you are now, and then eventually when you're publishing it?

Sarah Hajipour:

For the podcast?

Caitlin Mackie:

For the book.

Sarah Hajipour:

For the book, so I go to these meetups and I listen to what's the coaches and the executives are sharing. The ones that are exciting for me are kind of a new for me, I will ask them, I connect with them over in LinkedIn and people are so open to sharing their experience with you. I've never had even one person said to tell me, "No, I don't want to talk about this or anything." People want to share. So I approach and I say, "Hey, I have a book outline or guideline. It's a two pager." I send it to them and I asked them if they are interested to talk to me about this and they let me know and then I'll select a time.

Sarah Hajipour:

And first session, it's like a half an hour. It's a kind of a brainstorming session. What are the key cases that they feel they want to share? Then we pick one and the session after that, they'll actually go through the case with me. I record it, draft it and then share it on Google Drive back and forth until we're happy with the outcome.

Caitlin Mackie:

Yeah. Awesome. Do you have a timeline at the moment? When can we expect to be able to read it?

Sarah Hajipour:

I'm looking forward to around the end of 2021, because it's 100 cases and I think that I'll have that.

Caitlin Mackie:

Yeah. Awesome. It's so exciting. Lots to look forward too.

Sarah Hajipour:

Thank you.

Caitlin Mackie:

Now, I also wanted to touch on International Women's Day is coming up and you've been in the agile space for a few years now. I assume you've probably witnessed a bit of change in this space. Have there been any pivotal moments that have sort of led to where you are today?

Sarah Hajipour:

Well, I think that a lot of women are being attracted to the agile practice, the different agile roles. And I have seen a lot more women as scrum masters, as product owners and as agile managers or agile project managers. A lot of different roles are being kind of flourishing in this area. And I've seen a lot of women contribute. One my goals actually in my book and on my podcast is to be able to find these women and talk to them regardless of where they are in the world. Yeah, I just feel that women can grow really in this area in the agile mindset, because women are more the collaboration piece.

Sarah Hajipour:

I can't tell we're less competitive. I haven't done research on that, but I have discussed it with people. Do you think that women are more collaborative rather than competitive? Because competition is great, but you need a lot of collaboration in agile and a lot of nurturing. You need to have that nurturing feeling, the nurturing mindset, that's what a scrum master does. One of the key characteristics of a scrum master has to be they have to have this nurturing perspective to bring it to the team.

Caitlin Mackie:

It's funny you mentioned because I actually have read some stuff myself about women typically possessing more of that open leadership style and that open leadership seems to complement the agile space really nicely so.

Sarah Hajipour:

That's exactly, yeah.

Caitlin Mackie:

Yeah. Yeah. That's great and I think there's lots that we can take from that, open leadership and the direct leadership. So men and women coming forward and finding that middle ground and yeah, I feel like agile is a great space to do that in?

Sarah Hajipour:

Yeah, I totally agree. Yeah.

Caitlin Mackie:

Yeah, yeah. So what drove your passion? I guess what made you want to pursue a career in this space?

Sarah Hajipour:

I love the collaboration piece and I love the vulnerability because like people are allowed to be vulnerable and in the teams that they work in. And it is a culture that is more human rather than super strict. We're not allowed to make mistakes. We're not allowed to be wrong. Leaders are supposed to know everything right off the bat. But in reality, that's not the case. Leaders have to feel comfortable not knowing a lot of things that are not even known. But a lot of times I always say we're in the unknown unknown zone. And in that zone, even leaders are not supposed to know everything.

Sarah Hajipour:

So a lot of it starts with what are the other things that I learned from my interviewees is that it all starts with the leadership. So the agile transformations, the leaders have to first create that atmosphere of collaboration and of trust and psychological safety among themselves. And then only then they can help with teams to be able to thrive in those kinds of atmospheres as well.

Sarah Hajipour:

Women in agile and women in leadership. I like to say and what I see is a lot of men and women both that are changing their perspective from process of tool-centric to people-centric because it works better for everyone. And I see change really happening in all industries. I see it in retail. I see it in construction, obviously in IT, in finance system. And there's men and women like hand-in-hand trying to kind of embrace this way of thinking and this way of working.

Sarah Hajipour:

And women are being more comfortable to grow and kind of raise their hand and say, "Hey, I can make each page. I can take this role" because they understand because they bring that psychological safety that women for ages, it has been a workplace has been something that was mostly men and we're gradually getting into the workforce or the business world as females. So that psychological safety has allowed women to raise their hand and grow in different roles and leadership roles obviously.

Caitlin Mackie:

Yeah, yeah. I couldn't agree more. Has there been any resources or networks, things like that that have helped you along your journey?

Sarah Hajipour:

Learning from everybody else like creating a network, expanding my network to kind of coming in and saying, "Hey, I don't know. I want to know." There is all of these amazing things that are happening. I like to understand how this works and I remember it was one of these founders. Who's the founder of Apple? Oh my God. Don't tell me.

Caitlin Mackie:

Steve Jobs.

Sarah Hajipour:

I love this quote from Steve Jobs that says, "There has never been a time where I asked for help and people didn't help me." So just raise your hand and say, "I need help." And what does that help that I need? I need to know about this. What does it mean? What does scrum mean to you? How does it work in your industry? How does it work? And really I think that was the key for me up until now to connect with people and just be vulnerable and let them teach me.

Caitlin Mackie:

Yeah. I think my next question would be about how do we amplify that diverse and empowered community of women and our job in increasing the representation of women in agile? And yeah, what do you think is key to achieve a supportive and enabling environment?

Sarah Hajipour:

What I have seen and realized is that women really need to be and are being more supportive of each other. There was a study in HBR, Harvard Business Review in 2016 that said, "If there is only one woman in the pool of the interviewees, there's a zero chance for that woman to get the job, even if she's the best." So this calls for not which women are actually working great on that. Not being the queen bee, but also engaging and including other women. Because the more women in different roles, the more we are going to be receptive in those communities. That I think is a key that we understand that and support each other, help each other, build the communities around it.

Sarah Hajipour:

There is a community Women in Agile that is in different cities and different parts of the world that I'm a member of as well doing a great job. It's not just women actually in those groups. I see men participating as well, but it's predominantly women are trying to give each other insights from all aspects of the agile practices, the agile ways of working and stuff. Yeah.

Caitlin Mackie:

Yeah. So I think what's the way forward? I guess what's your prediction for women in agile? What do we need to do to continue that momentum?

Sarah Hajipour:

I think women will do great in anything and everything they put their minds in, regardless. We're human bottom line and we all have this potential to be able to grow in whatever we put our mind and heart on, regardless of our gender. So I would love for women to kind of be able to get that holistic perspective that regardless of their gender, they can do anything and they are, we are.

Sarah Hajipour:

We read about other women who have been successful in the fields of business that you felt that probably women can't do like women astronauts. There are women physicists. Women engineering leads and all of these that have been less common. The world is changing for the better and that's great.

Caitlin Mackie:

Yeah, yeah. I absolutely love that

Sarah Hajipour:

It's a great time to be alive.

Caitlin Mackie:

Yeah. That's exciting. Yeah, exactly.

Sarah Hajipour:

Yes.

Caitlin Mackie:

Yeah. I definitely think that we are beginning to see a huge increase and the visibility of female role models across so many industries. So it's great to have that. But Sarah, this has been such a great conversation. I wanted to finish with a final question for you and that was if you could give one piece of advice to women just starting their career in their industry, what would it be?

Sarah Hajipour:

I would say maybe the best advice that I can give is that we do have the power. And we need to look, number one, beyond gender and kind of have that belief that we can do anything that we want. And second is don't be shy to open up and build your community like build a community, join a community of agile practitioners of agile coaches, even people, specifically people who know more than you.

Sarah Hajipour:

And don't be afraid to ask help. Don't be afraid to say, "Hey, I'm new to this and I love to learn from you guys." Don't be afraid to put yourself out there and you're going to learn a lot that you wouldn't even expect. Just like you're going to get the result so you're going to hear things beyond what you've expected. There's a lot to human potential that could be unleashed when you just put yourself out there and let others contribute to your growth.

Caitlin Mackie:

That's amazing. That's great advice, Sarah. Loved every minute of our conversation. So thank you so much for joining me today. I really appreciate it.

Sarah Hajipour:

My pleasure. Thank you so much for having me.