Guest host Nick Polce, Business Agility Practice Lead at Accenture, speaks with Diana Larsen, Leadership Agility Advisor at Eos House Consulting. Nick and Diana sat down at the Agile Australia Conference to talk about how, even though retros are often a device that gets set aside when things are busy, changing your teams’ way of thinking about retros can improve efficiency in both short sprints and over the long term. Diana also digs into the co-intelligence of teams, and how having a clear sense of purpose is a key to success.
Guest host Nick Polce, Business Agility Practice Lead at Accenture, speaks with Diana Larsen, Leadership Agility Advisor at Eos House Consulting. Nick and Diana sat down at the Agile Australia Conference to talk about how, even though retros are often a device that gets set aside when things are busy, changing your teams’ way of thinking about retros can improve efficiency in both short sprints and over the long term. Diana also digs into the co-intelligence of teams, and how having a clear sense of purpose is a key to success. You can find out more about how Atlassian and Accenture are helping businesses succeed at scaling enterprise agility by surfing to our home page http://accenture.com/atlassian
Nick Polce: Hello and welcome to Scaling Enterprise Agility, a podcast brought to you by Accenture and Atlassian. It's all about how businesses can be more adaptive and responsive to the ever increasing rate of change around us. I'm Nick Polce, your host and Business Agility Practice Lead at Accenture.
And we're recording here from Agile Australia in Sydney. And today I'm very excited to be joined by Diana Larsen to talk all things business agility, and particularly around leadership agility retrospectives. Ah…so Diana, thank you for being so gracious with your time this afternoon.
Diana Larsen: It’s my pleasure to be here.
Nick Polce: Do you mind introducing yourself to the audience, from a professional and personal perspective?
Diana Larsen: Well, from a professional perspective for the past 25 years or so, I've been involved in the Agile community and making contributions there as an author and, as a consultant and coach, along the way. And I'm, active in the Agile Alliance community and, and in the board of directors and things. So I've been around the barn a few times in the Agile world. And, uh, personally, I live in Portland, Oregon and write in Portland, Oregon in my home office there. I work all over the world, and I'm particularly interested over the next year or so to spend more time in Europe and Scandinavia than I've been able to do recently.
Nick Polce: So those are some, some great things about your work. You can travel places like Australia. Right,
Diana Larsen: Exactly.
Nick Polce: Is this your first time in Australia?
Diana Larsen: It's my second time in Australia, but the first time I spent also just a couple of days here. So yeah…
Nick Polce: A fleeting visit.
Diana Larsen: And I guess the third thing is, I'm delighted to have contributed a couple of books and most recently, I'm proud to have written and published Lead Without Blame, Building Resilient Learning Teams with Trisha Broderick as a co author and then also my two co authors Esther Derby and David Horowitz and I are very pleased to have published, sort of, the Agile Retrospectives Second Edition book and it's out now in beta at the Pragmatic Programmer site, and we'll be out in the final, final version of the book in January.
Nick Polce: Two topics I definitely want to unpack. So let's start with, your first one, Building Resilient Leadership Teams.
Diana Larsen: Yes.
Nick Polce: Can you tell the audience a little bit about the book and what are some of the key messages you're trying to get across?
Diana Larsen: Well, in the book, Lead Without Blame is, the book really comes in two pieces. And the first part is about the changing world of leadership and organizations and particularly agile organizations, but it is actually that the organization's moving into this new century. And so we talk there about sort of changing some of our old habits around leadership, like thinking that we need to be judging and blaming people and holding their feet to the fire.
And, you know, all those kinds of things and how, Stepping away from that way of leading and into a more blame free way of leading actually gets us better results. Then that segues into the second half of the book, which is about more and more of us in leadership roles are leading people in teams or are part of leadership teams ourselves.
And what some additional new ways of thinking about that and what we need to be paying attention to. Particularly as our world, the pace of change gets faster and faster and really the only way to get through that is to develop more and more resilience and resilience in our teams. And that is based on creating environments for much more depth and learning.
Nick Polce: What do you think is getting in our way from stopping leaders? We know that, large change programs and modern organizations require different leadership skills and behaviors.
Diana Larsen: Right.
Nick Polce: And we can teach leaders these things, but they've got to own it themselves. What, in your opinion, is getting in the way of us not leaning into this space as much as we would like.
Diana Larsen: Well a lot of it is habit. You know, when particularly when we're under a lot of pressure. Taking time to change a habit can be difficult, you know, can be challenging. And so we try to offer some ideas about how to make that a little easier for folks and, give them more sense of why it would be worth the investment to change some of those habits. Most of us learn our leadership skills from the leaders that we have seen leadership we've seen modeled around us and actually the traditional leadership of, annual performance reviews and are you doing exactly what's expected of you and all that kind of thing. we've been taught that, but it actually isn't effective, particularly not in today's workplaces.
Nick Polce: How do you think the circumstances that we've lived in, in the pandemic, has affected our leaders have shown up?
Diana Larsen: I mean, one way is around remote work, right? And then a lot of leaders that I've talked to and that I've read about are very confused about how do I lead in a remote world where I'm not sitting in the same. I can't look over people's shoulders. I can't micromanage their work because they're far away, and if I try to micromanage their work, it just becomes frustrating for everybody involved. So, what are the ways you can look at some of the outcomes of the work? And are the outcomes of the work what you want? Is it really that you want them to perform a certain task in a certain way, or is it that you want the result of that? And, looking more at results than at process, for instance, is one thing. and also getting to the place where leaders can have the courage to say I don't have all the answers, let's go find out. If a question comes up, we know how to learn our way through it and leaders can model that behavior. And then become confident that they're, the teams of people that they are working with have the ability to learn their way through the challenges that face them.
Nick Polce: That's a big leap of faith. You need to be very confident in yourself.
Diana Larsen: Yeah, well, it's a, it's a leap of faith in the beginning.
Nick Polce: Yeah.
Diana Larsen: If you want to build trust in your teams, we say trust first, right? And then you get to see how that works. And then over time, as you see that becoming more and more effective, you're more and more confident in it. It's much less of a leap of faith and much more a ‘I can rely on my experience that these people will get the job done.’
Nick Polce: It's amazing.
Diana Larsen: Yeah.
Nick Polce: Do you have an instance in your mind of some of your past work, taking a leader or leadership team through this experience. Can you share your experiences and talk about the journey that they went through?
Diana Larsen: One really interesting time is, an organization that I worked with that, had an impending project that, was on the brink of not delivering on time. And it was a big initiative in the organization.
Nick Polce: I think we can all relate to that.
Diana Larsen: Yes. And, they were a waterfall organization, and they decided that they were gonna take a pilot team, and do an experiment and see if this pilot team, working in a more agile way, could save them. Because, otherwise, they were doomed to failure. So they were... incented to do the experiment. And so, a team of us worked together with them to help them create this pilot group. It turned out great.
They delivered early. They delivered earlier than any of the other parts of the initiative. They had less than what had been budgeted. I mean, on all measures, it was a success. And so then they decided, well then, let's not just have this pilot group, but let's take all of these folks and have them work this way.
We'll use the approach that we created in our organization. And then we ran into troubles with the managers because the managers were in functional silos. There was a QA manager and a business analysis manager and an engineering manager and so on. And they were freaked out because they no longer had direct line of sight when people were put together in these cross functional, self organizing teams, they no longer had line of sight on what their people were doing.
And the tricky part, they were paid according to the number of direct reports they had. So it was a little bit of a threat to their own income, or could be at some point in the future, so they were hesitant about that. And so one of the things, that we offered them was, some facilitation support for their management team meetings, because they did start having management team meetings, but they didn't really think of themselves as a team.
And we had done chartering with all of the 17 teams that were in this whole big IT and software department. And so we offered to do chartering with them as a leadership team. They're like ‘Oh, no, no, no, no, no, no. We'll meet once in a while and we'll get, you know, we'll look at the impediments and see what we can do about them and so on.’
So they went along that way for a little while, but we had planted the seed that if you are working as a team in sprints in similar ways to the way the rest of the teams are working, you will have a better understanding of the challenges that they meet and so on. And about six months later, I got a phone call saying, ‘You know, we've been thinking about it, and we think maybe if we were to charter ourselves as a team, that would be effective for us.’ I said, Oh, that's a great idea. So now they conveniently forgotten that anybody else, but you know, probably the ownership of it is not important. And so, so we did do that. We spent a couple of days together. The whole group in a really lovely little location and got them to really think through, what was their purpose as a whole team, as a leadership team, and how were they going to manage? Spending some of their time as a leadership team for the teams and some of their time on some of the other tasks that they needed to perform that weren't directly related to the Agile team.
And so they figured all of that out and we put them through the whole chartering process and they examined their place in the organization. We look at context. Where do you fit in the larger organization. and in the end, they were very happy with that and they became better leaders because they did get an understanding. They decided that the impediment list that all the teams, all these 17 teams were sending to them would become their backlog.
Nick Polce: And that's how they moved from chartering to action. To action, yeah, to remove impediment to the teams.
Diana Larsen: And then after a while, they were doing not only impediment removal, but they were looking ahead to what are some of the policies and procedures in our organization that we see are getting in the way of the teams, even though the teams haven't seen that yet. It was a great experience certainly for me and for everybody else.
Nick Polce: Before I move away from the topic of leadership, because there's a lot I want to cover in the show at a time, if there are leaders or executives listening to this podcast, What are the couple of tips that you'd leave them with to something they can start doing tomorrow just to start making those subtle shifts?
Diana Larsen: If they are somebody who likes to learn through books, I'd recommend that they get our book and take a look at it and then also, one of the things I think about is the focus of understanding how leading a team is different than leading individuals.
And one of the things that always becomes a leadership task is this idea of you need to motivate your people. Well, what that means is you need to understand how to tap into the motivation that is naturally there. And so with teams, we now think about, it's got, every team needs its own purpose. As a team, not individuals, but as a team, why are they together?
Clarity around how what they're doing fits into the larger picture of what the organization is trying to accomplish and so on. And then autonomy, clarity around what decisions and, budget or whatever the team has to do their work to be able to manage their own work and self organize their own work.
And then finally, and those are kind of familiar to most people, but the third one that isn't as familiar is the idea of co-intelligence that a team needs to have an intelligence of its own that is made up of all the skills and abilities of everybody on the team. And then an understanding of where that needs to be stretched and grown and how to help a team do that.
And so, purpose, autonomy, co-intelligence for teams is a great lens to look through if you want teams to feel motivated to accomplish the things that they're charged with.
Nick Polce: Thank you so much for sharing that. I'm going to shift into retrospectives now. So another big era of passion of yours. Can you tell us about the second edition of the book and what we can expect from that?
Diana Larsen: Well, the second edition of the book is organized much like the first in that there's kind of three chunks, but each of those chunks has been greatly expanded. So there is the beginning part that is about how do we facilitate retrospectives?
How do we design and do the upfront work to make a retrospective work well? And in that part, we've begun to also touch on, well, what does it mean when teams aren't co located? Because in the first book. That was the assumption is that most teams would be co located. Well, that's changed a lot in the last number of years, aso that's a big piece. And then we've got the three chapters of activities for the different parts of the retrospective framework: set the stage, gather data, generate insights, decide what to do, and close the retrospective. Which, incidentally, is the way humans think. And if you want a group of humans to think and come to the same conclusion, you need to go through those same steps. Not enough to just generate insights, or just jump to deciding what you're going to do without thinking about it anymore.
Nick Polce: We say that all the time.
Diana Larsen: Yeah, right. so there's that. and then we've got the final part, which before was kind of peremptory, and now is in much more depth that we included some retrospective scenarios, like typical kinds of things that people run into that they want to run a retrospective about, and give them some ideas about how do you put together the retrospective design to do that. And then we have a whole chapter just devoted to when the teams are not co-located.
Nick Polce: Okay.
Diana Larsen: One of the things that we heard a lot over the years was we hold our retrospectives, but then nothing happens, how do we get to follow through? So there's a whole chapter on making sure that you can get to follow through. There's lots of information about how do you take retrospectives beyond just the software team and start, having them for the rest of the organization so that the organization becomes a more learning organization, not just and even beyond the teams and, some kind of how do we catalyze the things that we want to have happen?
Nick Polce: There's a lot to unpack there
Diana Larsen: And a lot of it is in response to the questions and comments that we've heard over the years about my retrospective isn't doing what I want it to do, and then the nature of those, and then, um, there's about twice as many pages. I mean, it's really a lot more material and different appendixes than we had before.
Nick Polce: You've kind of touched on one of my questions, but I'll ask it anyway, so, retrospectives is obviously, you know, fundamental for the learning culture, continuous improvement of teams and organizations. It's the most regular ceremony that gets dropped from the agenda.
Diana Larsen: Right.
Nick Polce: If an organization is struggling to make retrospectives stick, what are the things they can do to ensure it doesn't fall off the agenda?
Diana Larsen: Yeah, well, one thing initially is to create retrospectives that actually create an agenda for retrospectives that actually goes through those parts of the framework. That gets missed more than anything. And, you know, if you don't stop to gather data, then people are making decisions based on wildly different opinions because they haven't coalesced around what is it that happened that we want to really look at, right?
So you're just getting random kind of things. Many retrospectives end up being just list making and this is where I was talking about where I have seen many people use a confluence page, and that just hasn’t worked well. What do we want to do differently? Those people sit and they make those two lists and then do nothing with it, right?
So there does need to be that step of deciding what to do. What action, what do we need to learn next? What do we want to experiment with? What, action do we think is going to help us and have the whole buy in of the whole team for that? So that's an important part that often gets lost.
Nick Polce: Absolutely lost.
Diana Larsen: And I can understand why people couldn't move into action by just creating a couple of lists. Somehow, a lot of folks have in mind, if we just write it all down, it'll take care of itself. But that's not. actually how things happen.
Nick Polce: We see quite often the resistance is from that management layer that don't, perhaps understand the value of it.
Diana Larsen: Right.
Nick Polce: So is there, a strategy there of potentially, going to the leaders and getting them to run some retrospectives so they understand the value first?
Diana Larsen: Well, that's a great thing. And actually in the Lead Without Blame book, we have some templates for retrospectives that leaders can use. But more importantly, and tomorrow, my keynote here is going to be “Learn Small, Learn Frequently, Continuously Improve,” and one of our frustrations has been that, unlike planning for the next sprint or whatever, or doing the print review or whatever, retrospectives have been sort of, like you said, the thing that seems like it can be lost as a part instead of it's a part of the flow of work.
So one of the ways to make it more a part of the flow of work is to make them smaller and more frequent. So, one of the examples I will give tomorrow is some of the, ensemble or whole team, mob–whatever you want to call it, uh, teams that I've, that I have been working with and know about have started, they work, everybody all working on the same story at the same time. And, they work in Pomodoro's because it's very intense. And so they need those frequent breaks. So they'll do 25-minute Pomodoro, everybody focused on the same work. And then, traditionally with Pomodoro's, then you have a break, but instead of going right into the break, you can stop and say, okay, what's our retrospective on this last 25 minutes of work?
Did we notice anything slowing us down? Were we having any trouble with tools? Whatever it might be. Oh, yeah. One example I've heard is so and so has a Bluetooth keyboard and it's not connecting into the build system, and so can we fix that? Right? So it's a small thing, but we'll help to speed up the team, right?
And they say, okay, let's do that. Okay. Retrospective is done. We made our decision what we're going to look at. Everybody take their break. Five minutes. Come back. Start the next pomodoro. And if doing that in the flow of work it's like you remember Superman three and the fractions of a center office space had the same kind of thing in it that those tiny increments of improvement accumulate over time and the team gets better at noticing them, which
Nick Polce: is what we're doing in a two week cycle. We're just making that smaller.
Diana Larsen: Yeah, we're just making it much smaller, smaller and sharper and more frequent. And then it can't just make them smaller and keep the same two weeks. That doesn't work. And you can't make them more frequent and keep them just as long as the other. So it has to be smaller and more frequent. And then you get that compounding interest kind of benefit.
Nick Polce: It's like a tsunami if you do that every time across an organization.
Diana Larsen: I mean, think if, every 25 minutes or say you don't work in that way, but you've got a break, and a lunch, and a break, and at the end of the day, what if you did a small retrospective, maybe that one would be a five or seven minute retrospective, on that kind of cadence? And every time you made a 1% improvement in how the team is working, well, that 1% is going to accumulate into something really remarkable in a very short period of time.
And then on a longer cadence, you can have the retrospectives that are like, okay, let's take an overview of the last quarter, or let's take an overview of the last month or something like that, what kinds of things came up when we were having our short frequent retrospectives? But the important part is the retrospectives have to be embedded in and considered as part of the work–design refactoring or those kinds of things. It's not something special that you're doing. It is the thing. It is the work. And that's what really needs to have happen because software development is learning work. It is. It's not knowledge work, even, it's learning work. And so we need more and more learning mechanisms and retrospectives are kind of the classic and most obvious one.
Nick Polce: That's right. Last, lastly, I want to touch on the Agile Fluency Model. can you maybe just, give the audience a bit of an overview of what it is.
Diana Larsen: Okay.
Nick Polce: And I'd love to hear, you developed it some time ago. Would you change it, or has it changed?
Diana Larsen: It has, it has. Yeah, we first published the Agile Fluency Model in 2012 on Martin Fowler's blog. He generously offered to publish it for us. And, the idea behind it was... We kept hearing this you're either Agile or you're not kind of thing and you're doing it wrong and we were noticing in our work, James Shore is the other creator, that success with Agile looked very different in different places.
And so we kind of set out to describe that, get a sense of that, so that. leaders in organizations could know better how to support their teams in their learning and in their expectations and so on. So the model that we came up with had four layers, I would say they're not really levels. They're kind of layers. Um, and, we started the model with what we call pre agile, which is just, you haven't made that decision yet. And there are products that can be perfectly well made without going agile. Not the thing that we were most interested in, so we don't spend a lot of time describing that.
But then, the first layer is what we call focusing zone teams. And those are teams that have actually just groups of people who have actually just made the change into working as a team, and they need to, the fluency that they need to gain is in, um, how to work collaboratively how to have the right kind of relationship with their, the person who is telling them what to build their product owner or whoever that is in their organization and really get that devotion to building what the customer needs instead of building according to what's pre agile, often we find groups, work groups that are building according to what's. Most technically cool in an engineering way, which doesn't necessarily translate into customer satisfaction.
So in the focusing zone we're learning how to do that, and that interestingly, that is enough of a shift for a lot of organizations to begin getting quite a lot of value.
Just the fact that they're not necessarily predictable in their delivery, but they're reliable, they will always be working on the next most important thing but then in other organizations, they need something more than that.
And then we moved into what we call the delivering zone, which is all the things, all the collaborative skills. But now we are also focused on kind of boosting even our engineering practices so that we can do continuous integration, so that we can do continuous deployment and so on. And that takes higher level engineering skills than we might have been expecting before.
And so that needs to be, the extreme programming practices and the DevOps practices and the UX practices. I may all need to…I may have a technical writer on the team now, if that's necessary to deliver more frequently to the customer, according to whatever the cadence is that they want to get, you know, we've seen examples of that, which are the customer once updates multiple times a day to the customer once updates once every 18 months, because they have to go through some kind of governmental regulation review or something. So you have to figure out what that is and then deliver according to that.
And the vast majority of teams, that's what people are expecting when they ask for agile. Either focusing zone or delivering zone fluency. When we get into like R and D and we need folks really focused on a bigger project, then we have what we call optimizing. And that is what's classically been described as the Agile, right? The fully cross functional, fully self organizing, and by fully cross functional I mean maybe there's sales people on the team, maybe there's the business analyst is always on the team, or the product manager is always on the team, right? And they don't just come in and out, because it's everything that is needed to innovate or to disrupt.
But not everybody needs that. And it's a huge investment. And it also often means structural changes in the organization and things that the business either doesn't want to or really can't invest in but if you can, it's great. Right. And then the final layer we called the strengthening zone.
And that 1 has to do with, actually going small. It's the kind of thing we see when the team is, the organization is small enough and the team, the number of teams are small enough that they can actually be fully engaged in the work of the organization and not thinking in terms of their own product now, but now thinking in terms of what is the best for the whole organization?
Yeah, and of course they need all that other, all the things, all the focusing zone and delivering zone and optimizing zone skills, plus some ideas around new governance models, maybe, and, you know, other kinds of things. And so what we say is the strengthening zone is really inappropriate from, it's not like the pinnacle, it's just where you need all the skills, and that doesn't mean it's right for everybody. Okay. All right. So, so that's the model in a nutshell, which I know is always takes a long time to describe. And, there was one version of it in 2012. We updated it in 2018, and that new version is now on Martin Fowler's website and is also on agile fluency.org as a downloadable ebook.
But then since then, James Shore wrote the second edition of his book, the Art of Agile Development. And in there we collaboratively came up with, And what do, what else have we learned about the Agile Fluency Model? So that really is where the ultimate definitions of the model are.
Nick Polce: Okay. Is that a recent publication, that one?
Diana Larsen: It came out in, October of 2021, I think.
Nick Polce: We could talk for another hour. It'd be wonderful. So thank you for being so gracious with your time.
Diana Larsen: Oh, I'm happy to do it.
Nick Polce: We've covered a lot of things today. Uh, if there are any kind of key messages you want to leave with, the audience of this podcast that they can go away and start to practically, you know, look at taking action.
Diana Larsen: Well, as I've looked back, it took me a while, you know, I've written all these books and had all these ideas over time and had some wonderful experiences as a result, and it took me a while to realize that the nexus of where what I think is important is in the leaders creating an environment for teams to learn and leaders developing their own learning, because I believe that we are moving out of the era of thinking in terms of IT and software as knowledge work.
Knowledge work was defined, you know, people who go out and manipulate information, right? Go find information and manipulate it. We're now in an era of learning work. We can't rely on old knowledge anymore. it's handy and it's a good start sometimes for our learning, but it's only a good start for our learning.
And the world is throwing things at us so fast that if we don't get the skills to learn our way through each new challenge, we're not going to last very long. And, that ability to learn our way through every challenge is what gives us resilience. In the face of whatever crisis comes along, we're able to go with it.
So that is my biggest message, I think, is this idea of don't think of what we do as knowledge work anymore, think of it as learning work, and then find the way to create the environments that are going to support as much learning as possible, because that's what we're going to need.
Nick Polce: Amazing messages for the audience. Diana, we're at time, as I said, we could speak for a lot longer on this topic, but thank you for being so gracious and good luck with your talk tomorrow and hopefully you enjoy the rest of your time in Australia, but yeah, thank you for jumping on.
Diana Larsen: Yeah, my pleasure.
Outro: You've been listening to Scaling Enterprise Agility, a podcast from Atlassian and Accenture. You can learn more about Agile Australia, where this conversation was recorded, as well as the work Atlassian and Accenture are doing together by using the links in our show notes. We'll be back with more conversations soon. Follow us now in your podcast app, and you won't miss an episode.