Today, we’re asking the question: What is the best Agile? To help us answer that question, we have invited Diana Larsen to join us for today’s episode. Diana is the co-founder of FutureWorks Consulting in Portland, Oregon, and she partners with leaders around the world to design work systems, improve team performance, and transition to Agile methods. She is also the author of a number of books about Agile and, in this episode, we start with the best ways to approach Agile depending on what it it you’re trying to accomplish. Diana takes us through the limits and constraints a team might encounter, how to avoid a backlog of work, and how Agile has focused our attention on necessary software, meeting budgets, and keeping deadlines. We also discuss the different zones needed for a successful product, from optimizing to strengthening, and Diana shares a bit about what the Agile Fluency Project does and the tools that they use. For all this and more, tune in today!
Key Points From This Episode:
- Diana tells listeners a bit about herself and the books she has written or co-authored.
- What is the best way to approach Agile? It depends on what you’re trying to accomplish.
- Some of the limits and constraints on teams, given the online formats without voice or video.
- It so so important to be discerning about these limitations in order to work with them.
- Boundaries to bump up against foster creativity and innovation – limits can be a strength!
- Helpful limits include allocated space, allocated channels, and team working agreements.
- WIP limits and story size in Agile are fundamental limitations that give us wiggle room.
- Diana explains how limits indicate the choices we need to make and the risks involved.
- How limits tie into Agile fluency and why the focusing zone is well-suited for things that are rapidly deployed and don’t have a long lifespan.
- Avoiding a backlog and how the pandemic has demonstrated how fast things can change.
- Agile has focused attention on necessary software, meeting budgets, and keeping deadlines.
- Successfully developing software to spec, understanding customer’s issues well enough that we can anticipate their needs.
- How expansive teams are now, including not just technologists but business people too.
- The different zones needed for a successful product, from optimizing to strengthening.
- The Agile Fluency Projects works predominantly with Agile coaches looking to improve.
- The key to driving success for your organization is being fit for purpose.
Transcript for Episode 165. What's the Best Agile? with Diana Larsen
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie-down Bronx. I’m your host, Michael Nunez. Our co-host to day.
[0:00:09.3] DA: Dave Anderson.
[0:00:10.2] MN: Today, we’re asking, what is the best way to Agile?
[0:00:14.5] DA: There’s got to be a way. The on true Agile, it’s not just a capital A, the whole word is capital. It’s scream case.
[0:00:22.6] MN: The best and it’s the best way to do it. We have this question and we have a guest today. We have Diana Larsen, how’s it going Diana?
[0:00:32.2] DL: It’s going as well as it could be expected in these days and times, yes.
[0:00:38.5] MN: Yes, I mean, we’re all –
[0:00:39.6] DL: I figure that’s a win.
[0:00:41.9] MN: Yeah, that is definitely a win, we’re all still at home, at – safe and sound to the best of our abilities. Diana, tell us a little bit about yourself?
[0:00:51.4] DL: I’m somebody who has been hanging around with the Agile world for a while. A lot of people are familiar with some with either conference talks I had given, or – written a few books, the Agile Retrospectives book, another book called Lift Off that includes information about chartering teams and helping them get started. A book called Five Rules of Accelerated Learning, that actually is one of my real, prime interests, is in how people learn and improve their skills, their teamwork, their products, all those kinds of things. Then I’m also the co-author of the Agile Fluency Model white paper.
[0:01:33.7] DA: It sounds like we’re in luck. We may be able to answer this question today. You may be able to tell us finally how we were supposed to Agile – end all, be all.
[0:01:44.6] MN: End all, be all. Yeah, final episode right now of this.
[0:01:47.6] DA: No pressure, we’re going to end the podcast after this.
[0:01:53.7] DL: Yes. Well, maybe.
[0:01:56.8] MN: Do you have an answer to start, what is the best way to Agile? If we approach you with that question right now, what is the response you would have?
[0:02:04.9] DL: Well, I have been a coach and consultant for decades now, so my answer is very well honed. It depends –
[0:02:18.2] MN: It depends, yes.
[0:02:20.3] DL: – on what it is you’re trying to accomplish. Things like you know, what industry are you in? What kind of software are you building? I mean, my interest is primarily software teams and so lots of people are extending Agile further beyond into other parts of the organization, but I came into the Agile movement because I had and have a real affinity for people who work in software and IT. That’s who I’m most interested in.
It depends on what you’re trying to accomplish, what kind of benefits you want to get from your teams, you want to win a – what are your expectations for their performance? How often do you need them to deliver? You know, all those kinds of things –
[0:03:08.7] DA: Right. It’s also like –
[0:03:11.2] DL: – are determinants in, what’s the best Agile.
[0:03:13.1] DA: I think that’s also like, what kind of limits you’re facing right now. Say, if there’s like a global pandemic and, you know?
[0:03:22.7] DL: Yes, well, there’s been lots of conversation about organizations that have continued to have the same expectation for productivity from teams that were formerly collocated, and now are scattered to the winds, and only able to work in an online format. Like we are now, and are not given the tools that they need to do that, or the rest of the environment, or – the thing that breaks my heart the most, is when I discover that teams that you – formerly were collocated, now have had member swap out, because some have been furloughed and new people have been added and they don’t get video.
They only have an online production environment that they can see, and they have no video with other team members. You know, those are a number of limits and constraints that those folks are dealing with that really have to be looked at.
[0:04:25.6] DA: Yeah, that's definitely challenging. I definitely had some colleagues, early in my career, who were like, in India and I never knew what their faces look like. It was so hard to build a team when you could not imagine the face. Someone finally provide me a photo of them but it was like a cellphone photo from 2005 so it’s one megapixel or something.
[0:04:53.1] DL: What’s so sad about this is, we have had this information about how to work in a distributed way. We know what is recommended and what the inhibitors are and this is all well-known. I mean, your example, Dave, of working with people in India. It’s way easier for people on the east coast to do that than for me like people on the west coast.
We are exactly 12 and a half hours off from folks in that part of the world.
[0:05:25.4] MN: Half hour just rubs it in.
[0:05:26.8] DL: Yeah. But you know, when you’re a little closer, like I have a lot of colleagues in Germany, and they work with people in India and that’s only a five hour difference, so it’s manageable. If you’ve got a manageable set of time differences like that, there are a lot of things you can do that have been known for a long time, like just even knowing what the weather is.
You know, giving out a weather report of what’s it like where you are, and where our team mates are, or what their faces look like, or what time it is where they are or, you know, sharing some simple things like that. It’s always been known that even those things will help bring the team closer and then, of course, the primary thing of needing to be able to see each other.
At least have a face to put to a sound, a voice, to know who sounds like what. Those things are really super important.
[0:06:25.4] DA: That’s mainly from a perspective of building team empathy or –
[0:06:30.8] DL: Well, team empathy, yes, and non-empathetic teams are not very productive teams. It’s got – there’s a business case behind it. It’s not just touchy feely. Early, when I first came in to the Agile world, I remember running in to somebody who said, “You know, the last time I talked to you, I thought everything you talked about was all touchy feely,” because we were talking about retrospectives and things like that, and he said, “Now I’ve been promoted into management and I realized it’s all touchy feely. It’s all flowing in,” you know?
It’s like, those are the drivers, and those are the essential skills, and not the soft skills, right? Yeah, I mean, the reason that we – I mean, we talk about these things, of being the connectors. We’re humans, we like to connect with each other. Particularly, if you want us to work together, we need to be connected to each other. Recognizing what are those constraints, what are those limits, is a really important thing because only then can you begin to work with them.
Only then can you begin to say, “This is a limitation we have. Actually, you know, figuring out how to work within this limitation makes us more creative. Here’s another limitation we have, this one is so constraining that it is causing us to not be able to perform to our full potential.”
Being able to be discerning and discriminating about those things.
[0:08:10.0] DA: The first stop is realizing that there are limits, or that there are maybe new constraints that are there, and trying to identify them and name them.
[0:08:20.7] DL: Particularly now. I mean, because we’re faced with so many new ones that we hadn’t really thought about before. Yeah, I mean, there have always been limits in every situation, but some of them are more familiar than others, and now so much is new to us. One of the things that I’m going to talk about in my session tomorrow.
My mom was an art teacher and an artist herself and so, from very early on, I heard a lot about, you can’t make art if there are no constraints. If you have no boundaries at all, no anything, it paralyzes the artist. Right? There needs to be some limits, some boundaries to bump up against, and that fosters creativity. That fosters innovation. Like everything else, limits are – you know, have our yin and yang, they are – they give you strengths and they can impose weaknesses on you and you have to look at them and figure out what that is. If you’re going to get the most benefit.
[0:09:29.3] DA: Yeah, I definitely felt that, like, starting a new project where you don’t have the very most important thing identified yet, and you have to figure out what that is. The feeling of not having those limits and not having that pull, that direction, the momentum forward to a thing, it just feels like it could be anywhere.
[0:09:53.3] DL: You know, a word that a lot of people will use for that is untethered. It’s like, free floating. My god, you know? A tether is a kind of limit, you can go this far but no further. It’s comforting limit, an enabling limit and it keeps us from just flying off into crazy world, right? Yeah.
[0:10:18.4] DA: What are some limits that you’ve found can be helpful like when you recognize them.
[0:10:26.2] DL: Well, things like, just a really fundamental thing is a limit of space. For teams, it’s important for them to know what is their space. Whether it’s a collocated team that has a room or a defined set of cubicles, or whatever that they all sit in, they all work together. Kind of defining that enables the conversations, it enables the overhearing, it enables a lot of those things. Online, it’s the limits of, you know, within the workspace this is our channel, that’s your channel, right? Those are boundaries, those are limits and it helps us organize our work if we have those.
That’s one example of some pretty helpful limits. Other ones are things like team working agreements. We don’t accept just any old kind of behavior here, right? We are looking for the behavior that is going to help us work well together. We create some agreements that sort of bound what’s permitted behavior here.
[0:11:38.8] MN: Right.
[0:11:39.0] DL: And have those conversations about, you know, mundane things, like what are our core hours, or how late can somebody show up to a meeting before the rest of us are upset with you, or those kinds of things. The rest of us feel like you’re wasting our time, right? If you're not showing up for a meeting or letting us know within a certain amount of time.
Those are all kinds of limits that sometimes we welcome, and we put on ourselves. Some of the most fundamental ones are, well, common one in the Agile world is WIP limits, you know? Not having so many different things in flight that we can’t keep track of them. Narrowing that to what are the next critical few? So that we know how much we can keep in flight and how we feel about that. Those are all examples of really basic limits. Story size. How many – we want to make our stories all of a size that we can fit X number of them in our sprint, or in our work, and process limit, or whatever that might be, so that, odds are, we’re going to get at least most of them done if not all of them, right?
It gives us some wiggle room, lets the team feel successful because they are probably going to complete some of those, but also then gives some wiggle room, in case if we miss one piece of work, we’re not missing something huge, because we’ve sized our stories in such a way that they each deliver value but maybe a very small increment of value.
So those kinds of things, those are the kinds of, kind of basic fundamental limits that we look for.
[0:13:33.6] DA: Yeah, some of those things are like pretty nuanced that might take a team a long time to figure out. Like the story size is always a challenging one I think, especially when you’re just starting out on something but –
[0:13:46.3] DL: How many people can be on a team?
[0:13:48.5] MN: Yeah.
[0:13:49.6] DL: And have it still be well functioning productive team and not falling into factions and other kinds of things. You know, lots of different ways the limits can help us. Clarity about the limits that we want to define it’s, you know, the limits we get to define for ourselves, clarity about those, keeps us out of sort of doing wishful thinking, and helps us understand what the balance, the tradeoffs are between this idea and that idea.
Helps us understand what’s expected of us and yeah.
[0:14:31.3] DA: Right, I guess like, there are some that we accept willingly and that we design into our system, like the end of a sprint, but there are other maybe real constraints that we did not accept, but we have to realize exist, like a deadline or you know, something like that.
[0:14:54.8] DL: Or how often do our customers want to get the a version of our product, right? Kind of that idea of cadence, delivery cadence. James and I actually, both at different times, worked with a same company that was building mass spectrometers and we worked with the team that was building the software to go in those mass spectrometers.
In that instance, there were actively discouraged from releasing anything, you know, any more often than every six months or every year or so on, because once a new product was released, it had to go through FDA approval. That was like an 18 months, you know? They didn’t want you throwing something new out every other week, or certainly not 14 times a day, like it used to be talked about at Flickr or whatever.
You know, the limitations of the regulations on their product had to be well understood so that they could do the right thing within those constraints as well.
[0:16:06.6] DA: Right, And there’s constraints of the legal requirements are derived from other constraints of what could very rarely go wrong with that software. Like if Flickr goes down then you know, I don’t see my vacation photos but, you know – the volume of the mass or whatever, if that goes wrong, the volume of the mass. I’m obviously not the person who should be designing those things but –
[0:16:36.1] MN: Pacemakers.
[0:16:38.0] DL: Yeah, I mean, there are lots of folks who are working on software that has the power of life and death.
[0:16:45.0] MN: Right.
[0:16:45.8] DL: If it’s not right, if the bug is such, is a certain way, it actually could have very dire consequences for people.
[0:16:54.4] MN: Yeah, we had a recent episode, Dave and I, about pacemakers and rockets. We actually had no idea how they work but I imagine, as you mentioned, software for pacemakers may require rigorous testing timeline that is faster than the two weeks that the engineers want to deliver this software. It’s like, you have to kind of wait it out and then put it in to the FDA process in general.
[0:17:19.2] DL: Right, if you got a constraint like that, right? You probably want to make sure you have some kind of internal production environment where you can still be doing your continuous integration, right? Even though you may not choose to release it into the wild yet, or deploy it broadly, yeah.
Those limits all tell us something about the choices that we need to make, and the risks that go along with our product, and all of those kinds of things. Depending on the answers to those kinds of questions, you probably need to think about your Agile approach to doing the work differently, because we don’t do Agile for the sake of Agile.
[0:18:08.3] DA: I guess that’s bringing it back to my best way about doing Agile right now. Is that like, I had limits kind of tie into the Agile fluency?
[0:18:20.5] DL: Well, for one thing, the different zones and the Agile Fluency Model are likely to encounter different limits, and differences and constraints and boundaries, and things like that. Just by the nature of the kind of work that gets done in that zone. That’s one thing. I mean, one of the examples I like to use for, say, the focusing zone is – focusing zone is really well-suited for things that are rapidly deployed and have a not very long lifespan.
A marketing initiative website that is going to be up for some period of time and then is going to go away and then there’s the next one. The expectations and the elites burden on that kind of software. You know, probably technical debt is not going to be that because it’s not that long lived, it’s not small things are not going to come back. And, the world is not going to evolve in such aw ay and the technology is not going to involve in such a way during the life of this thing that we’re building. That you know, new ways of thinking about why this isn’t working are going to come online.
Focusing zone is really the proficiencies and fluencies that goes in the focusing zone, it’s very well suited for that kind of work, or for some internal infrastructure or IT configuration work. Where you know, it’s not going to impact our customers are all internal, we’re not going to be impacting what we’re delivering to the outside world. You know, there’s some other considerations there. If we are actually delivering things to customers and the outside world, some of which may be life and death, we were just talking about, right?
Then, we would start looking at some of the limitations that come along with being in the delivering zone. You know, those would be things like do we have a really good set on our team of coding standards? I mean, we’re going to move beyond just team working agreements and really think about collective code ownership and one of our coding standards on our team and how does that fit or not fit with other teams that may also be working on other aspects of the same product.
How do we negotiate those things? Then there’s a new set of limitations for folks who are working in that zone.
[0:20:59.6] DA: Let’s say that whatever decisions you’re making with the application like, you’ll have to live with them for the foreseeable future so you should invest a little bit more in it?
[0:21:11.5] DL: Right. I recently was talking with someone about this topic of product person in Germany and she said that when the COVID hit, they looked around and they realized that they had 25 different product initiatives in flight.
[0:21:32.0] DA: Wow.
[0:21:34.0] DL: She said, the first thing they did was look at that situation and say, we can’t do that. We have to work in much shorter increments, we have to you know, we have to get more focus and they reduced that group of 25 down to three and they said, we can work at on three initiatives at the same time, no more.
[0:21:53.2] DA: Wow.
[0:21:53.3] DL: As we rolled those out, we may pull from that list of 25 that we had before but we’re never – I mean, similar to a working process limit, right? Only on a grander scale, we are never going to have initiatives in process limit, right? They realize they needed in their organization if they were going to make it through. That was in April or May when they made that decision and now I’m sure still living with that.
I’m probably benefiting by putting that constraint, that limit on themselves.
[0:22:26.5] DA: That makes sense. Does that like correspond to like a shift in the zone that they were sitting in the fluency model?
[0:22:36.0] DL: The teams that she was working with, they are primarily teams that are working on fluency and the delivering zone, their product is a delivering zone kind of product. Requires kind of a regular cadence of putting out new features, new kind of keeping their – kind of main products that are in flight updated, and being responsive to what new things they have their customers want, and that sort of thing.
They’re in the travel business. Yeah.
[0:23:10.7] DA: Did those additional constraints like kind of move them from the delivery zone to the focusing zone or –
[0:23:19.0] DL: No, because they’re still doing the work in the delivering zone. They still need the very high-level engineering skills, they still need to work with their DevOps people. Those kinds of things are hallmarks of being in the delivering zone.
[0:23:32.0] DA: Okay, it didn’t change those other constraints that require them to have –
[0:23:38.4] DL: No. Right. But you know, not as impacted by those things. You know, some other things that I think of in delivering zone because they tend to be working on longer term products where they’re going to keep upgrading and upgrading, we all love to get upgrades on our – on everything.
[0:24:00.8] DA: Just the other day, just installed those updates on my phone.
[0:24:03.8] DL: Yep, they didn’t give us upgrades. We would be unhappy but we hate the way interrupt our work but anyway. So because those products have a long life and have more thinking into them, it’s like, how much of that imagining that you have about future work are you going to expose to the team, right? Because everything the team knows about adds to their cognitive load as a whole team and so I love what Mary Poppendieck said about, you know, “No team should ever be exposed to a team backlog of work.”
That is more than about three months’ worth of work. I mean that maybe kind of a role in three months but the product management folks, product development folks, product owners, whatever terminology people use, can have a whole set of things that they imagine they may want in the future or that customers have asked for but don’t rise to the level of being worked on right now or really soon because we know I mean what is it? Every cloud has a silver lining.
One of the things I love about the pandemic is how clearly it has demonstrated how fast things can change. The assumptions we had about the products we were building, and the things that were absolutely going to be necessary in February, and March, and early April, are not the assumptions necessarily that we are making now, right?
[0:25:41.1] DA: My idea for the Uber of XYZ is like, wait – I mean I don’t want to be Uber now.
[0:25:48.5] DL: Yeah, right, because everybody who is in that business is looking at some really big issues, right?
[0:25:56.0] MN: Yeah.
[0:25:57.3] DA: Right so I guess keeping that constraint on yourself of not planning too far away, and accepting some uncertainty, makes it easier for you to change the direction of the ship.
[0:26:10.3] DL: Yeah and you know the product people can have somewhere if it doesn’t bother them somewhere they can have a list of all of the bright ideas, right? Here’s all of the possible things we might do, but don’t expose that to your delivering teams, because they need to be head down working on the next most valuable future, the next most valuable thing that your customers have asked for. It just is distracting to know too much more beyond that, yeah.
[0:26:43.5] MN: I think as an engineer, a part of me appreciates the idea that we don’t have more than three months because if I knew that we had this feature that is going to role out like six months from now and I am implementing something, then I may try to make it and extend that particular part of the code, when we don’t need it for another six months. It is like, a part of me is like, “Oh that’s YAGNI, right? You ain’t going to need it,” but like but we will soon, maybe, you know?
But it is there and it is in this backlog that we’re going to get to in six months, and who’s to say in four months we may not get to that part anymore, because it is no longer needed but I built this feature to support the thing that we no longer are going to need.
[0:27:30.0] DL: And it is a rolling three months. I mean it is not, you know you don’t get right up against the three month boundary and then say, “Oh let us see the next three months,” no. It’s a rolling three months, so that you have some sense of the context of this system but you don’t need to know it. All of the ideas that are out there, because odds are a number of those ideas are never going to need to be built. I mean that is part of the rationale of Agile is to get away from that data point or the information in the Standish report, the chaos report way back, that said, you know well over 40% of features in any given software application aren’t used by anyone, right?
Why are we building those things, right? Well it is because we are looking at, we are imagining somebody might want them before we really know or before it really becomes pertinent to have them. Part of the whole intention of Agile is to move away from that and really put our attention on the things that we absolutely are certain that people are going to want and use, because they have told us, they have given us some information about that, and it helps us prioritize our work.
[0:28:49.5] DA: For some reason I have never heard of that report, although the name like it really sticks out, the chaos report. I feel like I just need to go out and read this right now.
[0:29:01.4] DL: Well the one that came out in the late 90s, you know, this is back in the dark ages of Agile. The one that came out in the late 90s was a big stimulus for the folks who were working on what was then called light weight methods right? Because it was just so horrific how many software projects were considered failures. A huge number. Never met their budgets, always went way past their deadlines, all of those kinds of things and Agile is meant to be a solution to that problem.
Let’s make sure that we are building the things that need to be built, and that we can finish, and actually get into somebody’s hands in time for it still to be useful to them, right? So, I mean, I think a lot of folks just look at the manifesto and they don’t necessarily understand the historical context of it. It was a remarkable document for its time, and you know Extreme Programming and Scrum and Crystal and all of the other folks who were getting together at object oriented conferences in different places.
To talk about these things, we're really struggling with a very hard problem of how do we do this in a way that’s successful, because software is a fairly young industry.
[0:30:28.0] DA: Right it is not like the same thing as building a bridge or something. The Romans did not build Facebooks.
[0:30:39.2] DL: No, I mean well, the first we go back to is Ada Lovelace and she’s in the mid-1800s right? And so you know yeah, even if you consider her sort of the beginning of writing software, the beginnings of computing –
[0:30:58.1] DA: Oh my gosh that really stinks.
[0:31:00.7] DL: That is still less than 200 years, right?
[0:31:03.0] DA: And I am thinking about that report right now too, because she wrote the first piece of software and no one ever used it.
[0:31:09.4] DL: Right. Yeah, sad.
[0:31:16.2] DA: So braggable, but so sad.
[0:31:19.1] MN: Oh no.
[0:31:19.9] DL: Set a tone for the whole industry.
[0:31:24.3] DA: Yeah pouring one out for all of those buttons, websites that have never been clicked on.
[0:31:30.1] DL: Yeah.
[0:31:31.8] DA: Yeah, I feel like even if you successfully developed something to spec, it is still possible that it is never used by somebody. You never asked the person who is actually going to use it if they are going to use it.
[0:31:46.5] DL: It depends on how the spec got generated, right? Was it in response to a request and getting a lot of feedback from the person who is requesting it, about the context that they would be using it in, and all of those kinds of things, or is it just some idea we have about what somebody might want? Now we can’t discount those either, I think.
That’s actually, when we talk about optimizing zone in the Agile Fluency Project, what we’re counting on from those teams. In addition to the things in focusing and delivering, they need all of that, but then they also need the ability to be scanning the technology horizon and recognize when something pops up, that if we added that into our product, they would really solve a need for our customers that our customers haven’t asked us to solve yet, but we understand their domain. We understand the issues that they deal with well enough that we can anticipate this need, and so that’s where you get disruptive technologies.
That is where you get really market changing innovations. When we have the ability to do that, but it needs a deep understanding. I mean I think people talk about Steve Jobs and the iPhone and stuff as if he just pulled that out of the air, but he had a deep understanding of what people wanted to do. He had a unique genius and sort of seeing, you know people would, given the way things are going, people are going to want to do this, and I can test it in a number of different ways.
And I can put something out in a small way and see how that goes. I mean it is the lean startup stuff. The customer development and product development kind of moving along at the same time in parallel paths, right?
[0:33:48.6] DA: Yeah and I guess like living in that zone comes with its own risk because, even Apple for all of their successes now, had a pretty rocky road at times because they were doing things that were ahead of their time. So how do you validate that risk or do you – when you are trying to live in that zone where you’re scanning for new things, how do you balance like just the gut instinct with something that’s based in reality?
[0:34:23.3] DL: Right. Well that is when our ideas about cross functional teams become much broader. Now it is not just cross functional in that it’s got a UX person, and a DevOps person, and a tester, and some developers, and they’re not all technologists on the team. Now we’ve got people on the team that are marketers, that are information architects, from business people who understand sort of how things go out and to the economy.
You have – depending on the product, you’re going to have a whole set of folks there that, back when we were working on that mass spectrometer team, there were chemists as part of the team. There were – the domain expertise shifts when you get to those other kinds of folks who are really working on innovation and disruption. Then you have a whole different cast of characters that you bring together and a team that focuses only on that product.
Now they are focused on the whole product, they are not focused so much feature by feature, but they’re focused on the whole product and what is the long term trajectory of this product. How well can we understand our market and what their evolving needs may be? So you know it needs everything from the focusing zone, everything from the delivering zone, but then also this other whole set of things that make up a team’s ability being optimizing, to be fluent and optimizing.
[0:35:58.7] DA: Okay, interesting. So it goes into like a really deep expertise and knowledge that is very broad. I guess when I initially thought about optimizing, I was thinking about AB tests, and you know changing where a button is on a page, just by a guess or something but –
[0:36:24.6] DL: Right. Well, those kinds of things are probably happening in the delivering zone. There, you want your product people who are working most closely, you want them to be customer advocates, right? They need to understand, but they aren’t necessarily full-time team members in delivering, but they should be out asking those kinds of questions and getting that kind of feedback, and doing the demos to the real customers. So that they’d get that kind of fast feedback and then feed that back into the team.
[0:36:56.9] DA: Totally. So where do you go from optimizing? It sounds like there are no more limits left.
[0:37:05.7] DL: Well there are. There is another zone, but you know 98, 99% of the teams that we see in the wild out there, a lot of them haven’t even really moved into – they have decided they don’t want to be pre-Agile anymore but they haven’t really picked the zone. So there is a certain number of folks out there who just aren’t really focused on developing the kind of proficiencies they need. Even of those who have, well more than like 75% are either on focusing or delivering.
That is the bulk of the need that is out there. Then there are a few who have these contingent RND teams in almost any industry, those kinds of folks, need to have more of the optimizing zone fluencies. The additional zone that we have we call strengthening, and it is moving beyond being most concerned with the health of our product, to being most concerned with the health of our organization. Our whole product line, our whole everything, and so those tend to be small organizations.
You don’t see those in really big organizations. The biggest I have seen that have some of the hallmarks of strengthening zone teams, are in the couple hundred person size of the organization, down to maybe a dozen people or something like that. In that range. It really is very, very small company range, because it’s just really hard. Once you get above a certain number of people, I don’t know if it is Dunbar’s number or what, but once you get beyond a certain number of people, it’s just the communication overhead, keeps you from being able to do certain – I mean it is a limit right?
Scaling puts a limit on what you can do, right? We think of scaling as, “Oh! We’re going to be able to do all of these big things,” but there is a different kind of limit that gets imposed there, right? We can no longer all talk to each other. Now we need the limitation of figuring out which communication channels are we going to use, right? And we want to stick to those because we don’t want anybody to miss anything.
Different kinds of limits come in when we got bigger and bigger and bigger. So you know smaller companies are more nimble. We know that, but not necessarily more resilient. So that choice of do we want to be extraordinarily nimble and make a lot of changes and be able to pivot a lot or do we want to be resilient about the changes that come to us from the outside, you know, where are we going to – what is the balance there?
Where do we want to make sure that we are building this into our culture? That is a limiting choice, right? We are going to make some decisions about which way to go there.
[0:40:10.3] DA: Right, like valuing consistency over pursuing this broader vision of improving the portfolio or the organization. I don’t know I feel like I want to be strengthening but you know it sounds like a really tough place to get to.
[0:40:28.8] DL: Well it is interesting because at the Agile Fluency Project, we work a lot with Agile coaches. The tools that we have in the Agile Fluency Model, and we got a diagnostic, we got something we called the improvement cycle, and then we’ve got a bunch of supplemental things that support all of those tools, they are most helpful to either leaders, or organizations, or Agile coaches, you know who are trying to help be trusted advisers, and who want to bring their best and help the teams grow and thrive and become more proficient and develop more capabilities and capacities and those kinds of things.
So we work primarily with Agile coaches, and the kind of paradoxical or funny thing that we run into is that Agile coaches and visionary leaders, and the kind of people who are drawn to the Agile Fluency Model, all love the idea of the optimizing zone and then especially the strengthening zone, right?
These are like awesome, right? And we call it strengthening because their are focus is strengthening the whole organization, and optimizing is optimizing the product, right? So the funny thing is, is that it’s the focusing and delivering zone teams that actually need the most coaching. Once teams become pretty fluent in optimizing, or deviling and strengthening, they are able to do all of these stuff on their own, right? They don’t need coaches so bad.
[0:42:03.5] DA: Like, get out of here.
[0:42:04.9] DL: Yeah, you know they learn to think about complexity. They have learned all of these different things. Your comment reminded me of that about wanting to be in the strengthening zone.
[0:42:18.3] DA: One day I’ll get there. Just keep doing reps.
[0:42:21.9] MN: That’s the best Agile right there, is it? Right in the strengthening zone.
[0:42:26.8] DA: Yeah, although it sounds like there is benefits to picking the right place for you to be and seeing what limitations you’re feeling right now, and you know what would drive success for you and your organization.
[0:42:43.8] DL: Absolutely. That’s key. It is understanding, what are your business goals? What do you need right now? How do you need the teams to contribute to that? And then making sure that you are not over-investing some place, but you are investing appropriately in the things that will really enable that team, or those teams, to meet the business needs that you have.
That’s the key. I mean we’re talking about sometimes called fit for purpose. How do we ensure the teams have everything they need to be fit for purpose and all of the supports, all of the investments everything to enable that for them.
[0:43:21.5] MN: Awesome. Diana, are there any services that you’re currently offering in terms of the Agile Fluency Model and workshops or anything of that nature you have right now?
[0:43:31.8] DL: Absolutely. On our website, we have a free, downloadable eBook. It is the same content really that’s in the article that Martin Powler published for us on his book, but it is in a more sort of mobile device-friendly format, and some people just prefer to get their information this way. So we do have this downloadable eBook. We encourage anybody who wants to learn more about the model to get that and look at there is also a little 10 minute video on our website if they just want a little taster.
[0:44:01.8] MN: What’s the website?
[0:44:02.9] DL: agilefluency.org. Then in addition to that, I suggest that folks take a look at our workshops and events page. We currently have, live, a couple of different workshops. One called the Agile Fluency Facilitators workshop, which is the one that gives folks the opportunity to get a license to use all of our materials. Then we just give them everything that we’ve got, and as new things get developed they get that, but it is a substantial program.
It’s eight sessions over three months, a lot of learning by doing small cohorts. People seem to really love that aspect of it and, of course, all online. Then we’ve got – we always have a couple of those going at any given time so that people can look at the different schedules and figure out which ones work for them, and then we can also offer those are private workshops and we can customize those. So people can get in touch with us about that if they like.
And we have a number of places on our website where folks can contact us about any questions or anything that’s come up for them. If they have been reading the eBook, or just have heard things at sessions that they’ve gone to, or whatever, and wonder about them. We try to really stay in conversation with folks as much as we can. So we’ve got all of those things going and you know I’d love to hear from folks.
[0:45:26.3] MN: Awesome and that was over at agilefluency.org.
[0:45:29.7] DL: At agilefluency.org yes.
[0:45:31.5] MN: Awesome, any social media you’d like to promote?
[0:45:35.3] DL: Well, I have a Twitter account. @DianaOfPortland is my Twitter account. So does James Shore, his Twitter account is @jamesshore. Then the Agile Fluency Project also has its own Twitter, which is @AgileFluency. In addition to that, we have – there is a Facebook page but none of us are really big Facebook users. So we have a company page on LinkedIn and then of course we have our individual pages there. So those are all places you can find us.
If for some reason you can’t find us on there, hit the website, you can track us down. I love – Ron Jeffries has a wonderful little thing in his Twitter bio where we says, “If you really want to know who I am, I am confident you can figure it out.”
That’s kind of where we are, if you just put in whatever search engine you’re using, if you put in Diana Larsen or James Shore, we’re probably going to pop up there.
[0:46:33.4] DA: Got to get that SEO, nice. It was great having you on.
[0:46:38.8] MN: It was great, thank you so much for coming on down, down into the Rabbit Hole.
[END OF INTERVIEW]
[0:46:43.7] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
Agile Fluency Project: Workshops & Events
Agile Fluency Project on Twitter
Agile Fluency Project on LinkedIn
Liftoff: Launching Agile Projects & Teams
Liftoff: Start and Sustain Successful Agile Teams
The Five Rules of Accelerated Learning
Sponsor
StrideOur seasoned cross-functional agilists work with you to develop technology, ship product and deliver value. We leverage our diverse expertise across industries and throughout the organizational growth cycle to your benefit. We bring best practices, emergent practices and creative solutions to your problems.
