The Agile Fluency Conversation with Diana Larsen

Listen To Podcast Episode

Keeping Agile Non-Denominational, Episode 20

Watch Video

Cherie Silas   Hi, everybody! This is Keeping Agile Coaching Non-Denominational podcast and I'm Cherie Silas and I'm going to be your host today. I have with me Diana Larson and our topic is the Agile Fluency Conversation. You might know Diana from being in the community. She's a huge contributor of the community, she's an author, and she has spent a career helping others become more Agile. So Diana, I'm going to hand this to you, why don't you introduce yourself?

Diana Larsen   Oh, thank you. Well, you're right. I've been in the community for a long time; I joined right in the very early 2000s. I got introduced to some folks in the late 1990s and joined the community very early on and it's because I really did find a home here. I found the people who were doing the kind of work that I was also drawn to. So it's really been my privilege to contribute some books that people have enjoyed and have said nice things about and then also to be able to contribute by taking leadership positions like with the Agile Alliance Board and various conferences, and those kinds of things, and speaking and starting businesses that help others do this work as well. So that's the contribution I'm proudest of and I've just felt so fortunate to have been surrounded by the community of people and community of other contributors that have moved all of our work forward together.

Cherie Silas   Yeah and your work carries on. I hear people all the time talking about the Retrospectives book. You and Esther actually laid the foundations of, "This is what it looks like; here's the model" and then your liftoff book a few years ago...really, really great work. So now, we're talking about this Agile Fluency conversation. Help us to understand a little bit about what does Agile Fluency actually mean?

Diana Larsen   Agile Fluency is actually a model. We call it the Agile Fluency Model and it's a way of thinking about the behaviors, the learned behaviors that teams of people need to accomplish in order to provide the kind of business benefits, and the job satisfaction, and other kinds of things like that that we're all looking to the work. So James Shore and I, a number of years ago first in 2012, and then again we updated in 2018, an article that Martin Fowler published on his website, called the Agile Fluency Model. We also have that article in the form of an e-book, because it's a little bit easier to read on mobile devices and smaller screens. That you can freely download on our website but the idea behind it is- and I love the theme of your podcast, because that's what I think. I think we all need to find -- every organization, every team, every group of people that are forming a team -- need to find the Agile that is best fit for the outcomes that they want, for the nature of the thing they're building, for all of those things together. There are lots of approaches to doing Agile out there, to getting those benefits from Agile, and the idea that there's only one way...just...there's too much diversity in business and in the kinds-- I mean software, somebody said, 'Software is eating the world', you're hard put to find any business, any practice, any profession, any industry that doesn't rely on a software component at this point.  So it's everywhere and we need to be doing it well. By doing it well, I mean we create the business or organizational benefits that are needed and we create the job satisfaction that is needed so that people can keep doing the work; I mean, it's kind of circular, right? So, Agile Fluency, was really based on the idea of language fluency. James Shore and I were having a conversation about a workshop that we'd been presenting that was like a lot of workshops; it got really good feedback at the end and people had observations that we wanted to take into account. So we were looking through the feedback and thinking about, is there anything we want to tweak in this workshop? Any way we want to improve it, make it better? We tried a couple of different ways and we weren't really satisfied with it. We both had been exposed to the idea of language fluency and that the American Council for the Teaching of Foreign Language, ACTFL, kind of put -- and I think there's a council like this pretty much in every language family -- there's not just one way to be fluent. It really is about what you're trying to accomplish.  You can be completely and totally fluent in the language that you need to be a tourist. You can be completely and totally fluent in the language that you need to just go live in a neighborhood and interact with your neighbors and tell stories about what happened over the weekend, that sort of thing. There's a language that you might need if you are going to be a public speaker, or teach at a university. So there isn't ever just one fluency in a language; there is a fluency level that is right for your usage. So we started taking that analogy and saying, "Well, what about Agile teams? Are there different situations that Agile teams find themselves in that might require different fluent use? In other words, different proficiencies and then the skills that they need. What can they do well, and what can they do, and then the definition of fluency is what you do naturally, without thinking about it. You know, those of us that are born into a language are pretty much fully fluent because we speak that language without thinking about it. We know what the right appropriate response is in any given situation. Well, what if we thought about Agile teams that way? How do we create Agile teams that can know what situation they're in, and then always know what the right response is, and just do that routinely without having to stop and think about it, or stretch into it, or any of those types of things. So we started doing some research. We talked to a lot of people, exposed our ideas a number of times -- I love Open Space conferences so we take our ideas to our regional Open Space conference here in the Pacific Northwest, Agile Open Northwest-- and we show it to folks and say, "Well, what do you think? Are we on the right track?" In general, we got the response that, 'You're on the right track but have you thought about this?' or '...have you thought about that?' So we'd go back, and we'd incorporate that into it. Until we got to a place where all the people we were talking to were saying, "This is ready to be exposed to the public." That's when we wrote and  published the first article. Then we thought we were done.

Cherie Silas   All that just to publish an article!

Diana Larsen   All that to publish an article but we wanted to get this idea of, 'What does it mean for a team to be fluently Agile?' and what are the sort of differences that you might-- you know, like, are you a tourist or are you living in a neighborhood? What are the differences? Then we started getting questions from folks. When we would tell them about that or they had read the article they'd say, "Well, so how do we apply this? Now what? Now what? Now that we have this model, this way of thinking about things, how do we apply it? What do we do with it?" Then we started thinking about that and that's the second iteration of the article, it replaced the first one, that's now up on Martin Fowler's website, and our ebook reflects all that learning that we did between 2012 and 2018 about what is the actual application? How do you implement fluency in your teams and in your organizations? It's really about-- we use sometimes the analogy of riding a bus. A dear colleague, Bonnie Allman, told us this little story about a yoga class that she was at, and we borrowed it, and the idea is that when you get on a bus, you only ride it to the place where you want to get off, right?

Cherie Silas   Yeah Yeah

Diana Larsen   You don't ride it all the way to the outer suburbs zones, where the big box stores are, if what you really wanted to do was go to your doctor's office. It's just in another neighborhood in town or whatever. So that's the idea behind the Agile Fluency Model  and in language fluency as well. You can stop at tourist level fluency but if you want to go live in a neighborhood, you're still going to need that tourist level fluency skills but then you're also going to need to be able to have a logical conversation with the utilities provider, or whatever it might be. So we were looking at, how did that work together? The idea is, the team rides the bus. The team figures out -- the team and the organization together -- figure out the destination they want the team to be; what zone, we call it you borrowing bus zones, what zone of fluency does this team need? So then the team's going to ride the bus to get there. The team's going to acquire all the skills and the routine implementation of those skills to get there but the organization has to buy the ticket. So it requires organizational investment in order to help the team get to where it needs to go to give the business then back what they need. So it's a kind of a "help us help you" situation and it's working together. What we discovered for us was that the team behaviors were the best indicator of what was going on in the larger organizational system. How much support was the organization giving its teams in order for them to produce what was needed? So that, in general, is the idea behind the  model and why we called it Agile Fluency. How do you become fluent in Agile? Well, first, you have to figure out what you know, what is it you're trying to accomplish? Then, when we know what you're trying to accomplish, we can identify the fluency you need to accomplish that. Then that tells us where you need to build more skill proficiency, more mastery, in your team. So it's not that every single person on the team needs to have all those masteries but the team as a whole needs to be able to draw on all that mastery.

Cherie Silas   You know, Diane, as I listen to you talk about this. Some things really stick out to me. This word of fluency, right? The teams need to have fluency. What I often hear is 'team maturity' and to me that has always kind of been like, "They're not children! Why are you talking about maturity?" Right? It doesn't make sense. So I really liked this use of fluency. The same thing with when coaches go into a company, and they're like, "We're gonna do Agile transformation!" and I don't even know that customers/clients know what that means but this concept of building fluency so you can do what you want, what you need, get where you want to be fluidly. Then the last thing that I think is really huge is, what I don't hear is, "Here's my framework, here's my box, now you get in it, and I'm going to cram you down in there, and I'm going to make sure that you've got everything the box holds." So I really, really appreciate that.

Diana Larsen   Right. I think that is one of the things that we end up talking about a lot with the folks who come to us to learn about the Agile Fluency model and what we call the Agile Fluency Suite, all the other materials that we built around it so that people can use it. It really is about moving from being able to say, "I'm a Scrum coach" or "I'm a SAFe coach" which is good. That's great. I love people learning and you can demonstrate your learning, and that's fabulous but there comes a point at which you need to sort of move beyond that and say, "I understand extreme programming, I understand Scrum, I understand SAFe, I understand DAD, I understand Less, I understand whatever the toolbox is that the bigger toolbox is that is most relevant to the person who wants to use those tools, and be able to say, "and I know, when I use a phillips screwdriver", I'm going to keep that toolbox thing going, "When I need to use a phillips screwdriver and when I need to use a flat screwdriver, and they're both good tools, but you use them in different places." So being able to pick and choose among the practices, and among the proficiencies, and among the -- dare I say it -- the mindsets that are kind of inherent in each of those frameworks and methodologies, being able to say, "I have a nuanced view and this is what's going to fit best for this team in this organization and let's work with them from there." So start from where they are. It makes me sad, when-- I guess the people are always wanting to know, "So if you're not, you know, associated with one of these methodologies, what is your competition?" My competition is anybody who comes in and says, 'One size fits all'. After having grown up my whole life as a woman who is a larger sized woman, I know one size does not fit all!

Cherie Silas   It does NOT!

Diana Larsen   It really doesn't. So how do we develop the discernment that it takes to figure out what is the right size here? What is the right selection and combination that fits here? That takes some additional ways of looking at things.

Cherie Silas   Yeah and just because you can squeeze into it doesn't mean it fits.

Diana Larsen   That is right!

Cherie Silas   Just because you can does not mean you should. So we're talking a lot about this--

Diana Larsen   Well, and actually -- I am sorry -- the opposite of that is also sometimes people put on clothes that are way too big for them and they really need a smaller size and that's what we're really after at the Agile Fluency Project. What's the right configuration for you?

Cherie Silas   So we're talking a lot about fluency and I heard you say that it's the Agile Fluency Model, which tells me there's some kind of method or thinking that goes in there. So can you talk a little bit about that model piece?

Diana Larsen   Sure and the quickest way to learn about it, I'll just tell everybody, is to go to the homepage of our website, www.agilefluency.org. There's like a 10 minute video that is the quick overview of the Agile Fluency Model, because it does have a lot of pieces and parts. The idea is that we identified, again, what we call zones of fluency, four zones --  actually, maybe it's like five and a half zones -- because we also say there are folks who are what we call pre-Agile. They haven't made a choice to want to go Agile yet. It may be that where they are is just fine. If they're working on some kind of software that is a repeatable process, and that they've built before, and they know how to do it -- some kind of phased development approach where there's only a couple of individual contributors and the managers telling them what to do -- that might fit. That might fit. We don't spend a lot of time describing that in any of the things that we do because that's not interesting to James and I. So when we get interested is where people say, "That no longer is sufficient for us. We actually need to try some of this team stuff, some of this cross functional stuff, some of this Agile.  So where we start really describing is in the zones. The first zone that we get to we call Focusing Zone. That is where a group of people really learn how to work collaboratively as a team, how to produce together, how to shift their mindset from thinking in terms of components or what's technically cool to what can we build that's going to return value to our customers and our business, which is a really different way of thinking about things. That's a big kind of work culture shift to make from individual contributors building components to a group of people building according to value and according to valuable stories. So, that's a shift that happens there. So we gain fluency in building together in that way. That usually means we also need to gain some fluency in working with an internal person, like some kind of business liaison, an onsite customer, a product owner, somebody who can help us as a team understand what's valuable and what's the next most valuable thing. Then we also start building in fairly small chunks so that we can, if we learn after we've delivered a few things, if we learn what we thought we were supposed to build isn't exactly what's going to fit the situation and we need to redirect or refocus our energies, we can do that without having created a lot of waste. So building small, producing, and then moving forward in that way. We need some really good basic software skills, software, programming skills in that in that zone but we don't have to get too fancy just yet. That actually ends up working pretty well in a lot of situations. The methodologies that people often use, is they go back to the Agile Manifesto and they'll say, "Let's create something that fits all these values." Or they'll pick up basic Scrum, or basic Kanban, depending on the nature of the work, and kind of the fundamental pieces. We often call the focusing zone Agile Fundamentals. It's like the basic idea of how you need to shift your thinking so that you can work in this new way. That's not sufficient for everybody. So it doesn't work for everybody. Sometimes people need to ride the bus a little further.

Cherie Silas   I feel another zone coming

Diana Larsen   Yeah, I feel another zone coming-- to what we call the Delivering Zone. Here, we're actually shifting into a broader view, where we're not only thinking about what we're building and making sure that it's valuable, but that we're also thinking about how does it fit in our larger organizations? So now the team may have DevOps in mind or UX in mind, the cross functionality of the team starts getting a little more diverse and we need really good engineering skills because now we're looking at release at will. Now we're looking at continuous integration, continuous delivery, continuous deployment on an as needed basis. Now we're working with what we call our business representative. whether that's product management, product ownership, an on site customer, whoever that might be -- business analysts sometimes now -- we're working with them to know what kind of cadence does our market need in terms of how often they can take in new versions, new releases, what is their, their expectations about that. Some people want a  much longer cycle, other people want something really fast. The classic old time example of that was Flickr who was delivering into production like 14 times a day or something like that. Now, lots of folks are doing more of that. So that's the Delivering Zone and it requires that the team, together, has very collective coding standards, has agreed on continuous integration and how they're going to manage that. So they have to rely on those team collaboration skills that came out of the focusing zone, those are all still needed but now they're adding more sophisticated engineering approaches. So would you say the zones build on one another or are they side by side?  Yes they build on one another or at least they work in tandem. What we tend to say is, "Figure out what zone of fluency you need from your team and then do everything you need to get there. So if you said to me, in the beginning, "I really need my team to be a delivering zone team", then we'd say, "Okay, well, there's all these skills that we would have in the Focusing Zone, and there's all these skills that we would have in the Delivering Zone, and let's just start." It takes longer if you say, "Okay, now let's get fully fluent in the Focusing Zone. Okay, now we're there. Okay, now, let's start on Delivering Zone." That just takes longer in our experience. So we say go for the place you want to be but you're going to need to include a whole greater body of skills. So the other thing that happens is, the further along in the zones you decide is what you need, the longer it's going to take you to get there just because of learning curves and all that.

Cherie Silas   So it sounds like you're saying that, if I say I want to be in the delivery zone, I don't have to do everything that's possible in that zone in order to be successful. I can go as far into the zone as I wanted.

Diana Larsen   Exactly, exactly.

Cherie Silas   What's the third zone?

Diana Larsen   So then the next zone-- so I just want to say most teams that we run into, the most common is people want either Focusing Zone or Delivering Zone teams and Delivering Zones are even more common than Focusing Zone teams in terms of what people want. What we actually see is a flip of that.

Cherie Silas   Yeah, it's like, they may not know that you need the Focus Zone but they knew that They need the Delivery Zone.  That makes sense.

Diana Larsen   So then -- but if people say, "Well, wait, this still isn't quite enough. I mean, we're delivering on a market cadence, we're releasing at will but we need to be out there innovating. We need to be out there potentially disrupting a marketplace. Now what do we need?" Well, then we say, "Well you need Optimizing Zone teams." These are kind of like the skunkworks teams; the teams that really focus down on a whole product and learn it within the team. The fluency is around not only the engineering parts of that product or the software parts of that product but everything they need to know about what their customers want and need or their users want and need. So that often, the shift that we talk about that happens here is there's sort of some changes in organizational structure. One of the things that we see a lot is that those teams don't have enough business representation in the team to make fast decisions. So what we want from those people is their ability to make decisions to sort of own that product, know what they're going after, and maybe even have a budget that they're managing, So there's business representation in the team, there might be Sales and Marketing representation -- the group of subject matter experts grows according to what we're putting in here. This happens in both software as a service and embedded software and hardware. I mean, these things all go together.

Cherie Silas   Would you say that this space is what maybe people would say, 'Product Management' 'Business Agility', is that what is in this space?

Diana Larsen   Yeah, this is the interesting one. We call this, the Optimizing Zone and it is the zone, what we call 'Agile's Promise.'

Cherie Silas   Oh I like that!

Diana Larsen   It's that zone that a lot of people describe when they're saying, "This is how you be Agile!" but not everybody needs this much effort and they certainly don't need this much organizational disruption. Now you've got to hire a whole lot more people who can feed that business information into the teams and make sure every team has a full time representative so there's no waiting. We can move really fast and there's no handoffs; everything is right there. The managers who probably needed to change a little bit how they managed in focusing and delivering because they need to manage teams and not individuals now, now they need to probably be looking at managing groups of teams, and they're probably working more laterally than vertically. So managers need to be communicating with each other about what policies and procedures in the organization are getting in the way of the teams being effective. They've got to work out the impediments at that level and that's hard. That's hard work. It often requires somebody with a real belief that this is the only way we're going to be successful and someone in leadership that is willing to spend their internal social capital to make it happen.

Cherie Silas   Yeah, you know what I hear you talk about this. One of the ways that I've kind of described this in the past is, there's Scrum or Kanban adoption, right? That's what some people want. Then there's Agile adoption. So they want to bring it more into the whole culture. Then there's Agile transformation, which is a whole different beast, and now it sounds like you're starting to really get into what his transformation work.

Diana Larsen   At least into the beginning of it because there's one more zone -- well, it's one and a half, one and a third more zones -- but if you're in a large organization, probably if this is what you're looking at, this is the kind of potential transformation that you're looking for, because most organizations don't start out with a structure, or a design, or an organization design that fits for these kinds of teams. So adjustments must be made, right? So there's one more there is one more zone after this but these first three zones, they're the ones that we see all the time. The next zone is one we don't see very often, and we certainly don't see it in large organizations. It's a small organization zone and we call it the Strengthening Zone because now the teams are not just focused on their own product, they are focused on the good of the whole organization. That organization communication flows and such are-- it's possible to do that. We don't have communication overload yet. We can still know what's going on in other parts of the organization. We can still know whose product we all want to see get to market first, even though we may be working on different products at the time. Also things like these are the organizations -- and this we call the organization culture shift -- that these are the organizations that are trying out new governance models, they may be inventing new practices, that they then contribute back into the Agile world. A lot of the new practices have come from experiments that people were doing in smaller organizations and and they've contributed that back. So we see those kinds of things. Their view is bigger than just their team or their product on these teams and we call that the Strengthening Zone, because their focus is in strengthening the whole. We don't see very many teams there so I don't put a lot of focus there. If you look at the graphic representation of our model, you see there's a little tail that comes out of the strengthening zone. That's there to represent what else might be coming. We don't know that these four zones are the only zones that Agile is capable of and we have seen some teams -- and we're talking about teams all the way through -- we have began to see some teams that are not only not limited to their product, or to their features, or their product, or their own organization but they're beginning to look at societal. "What is it that we're building that's good for the whole of society and how do we need to organize ourselves to do that?" or "How do we give back to our larger communities?" and those kinds of things. And so there are some teams that are beginning to adopt those ideas. So we think there's at least one more zone emerging but we don't have enough information about it to really describe it yet.

Cherie Silas   Well, this has been really fascinating to listen to you talk about this model and to really see what your experience over the years has taught. You didn't just jump in and build something to go sell it, this is actually years of experience. So, Diana, our listeners are going to want to know like, "Yeah, and what are you doing right now and how can I get some of this?"

Diana Larsen   Right

Cherie Silas   So what would you say to that?

Diana Larsen   Well, um, my focus right now is primarily on -- I've got a couple of writing projects going on, because I always do but -- most of my focus is on this Agile Fluency Project  and transferring/mentoring other folks into doing what we do. So the way we're doing that right now is we have a workshop series that we do, it comes out on about a quarterly basis. We've got a couple of other ones that were that are kind of in the planning but right now we call it the Agile Fluency Facilitators workshop and that is the workshop that helps people move from a more narrowly focused Agile coaching practice, which they could be quite an expert in to more of the idea of being a consultant or change agent, either outside consultant change agent or an internal change agent, that has the broader view about how to introduce their ideas into the organization, and so on. Then we give them all the Agile Fluency materials we call the Agile Fluency Suite, the Agile Fluency materials and other tools that we've developed over time that they can then get a license in. The best way to discover about that is to look at our website, we have a page called become a facilitator. We also have a page that lists our workshops and events that are coming up so people can read more about things there. One of the things that's a real pleasure to me in all of this is when people earn the license, and we've had well over 100 people gone through our program at this time but when someone earns a license, then part of that license to use the materials also comes with the opportunity to speak to their trainer, or to me, or to Jim sometimes when he's available, and just arrange for a half an hour of mentoring, kind of on call, as is mutually convenient. So I get to have all these amazing conversations with people who are out there using our materials and using other people's materials too. That's how I learned about things like Wardley Mapping and things that aren't a part of our world, our scheme but are also opening up the world. I find things like team topologies and the Agile Fluency Model just really blend well together. So there's a lot out there that I'm excited about and that I get to learn about from the people who've been through our program. Then I get to give them a little gentle nudge. I wouldn't say I'm a career coach or a professional coach in that way but I have served more of a mentoring role at this point in my career. So we just have wonderful conversations about what people want, and need, and where they want to go.

Cherie Silas   Well Diana, it's been really fascinating to talk to you about this and to hear your vision and your work with people and really just that your contributions continue and you're really equipping people in this Agile space to be to be successful so I thank you for that. This has been wonderful talking to you and this is Cherie Silas with your Keeping Agile Coaching Non-Denominational podcast. Goodbye.

About Episode Guest

Want to Learn More About Professional Coaching?

Explore Our Professional Coach Training Programs - parts of The Coaching Path®

Other Episodes