Podcast EP 212. Are You Fluent in Agile? with James Shore

Description:

This week, Dan Neumann is delighted to be joined by a new guest, James Shore, the author of The Art of Agile Development and co-creator of the Agile Fluency Project with Diana Larsen, his contribution is invaluable to the Agile field.

In this episode, James talks about the second edition of The Art of Agile Development, which was published in 2021. This edition is a fully rewritten version that shows the influence of the Agile Fluency Model, including the different zones Agile Teams can occupy, such as Focusing, Delivering, Optimizing, and Strengthening, and best practices for Teams to become fluent in each area.

Key Takeaways

James rewrote The Art of Agile Development for its second edition.

He rewrote the book around the ideas of the Agile Fluency Model.
It includes more updated practices.
In the book, you can find out how to convince people to make a change, to try Agile ideas, and even advice when you are in a situation where you are not very Agile.

What is the Agile Fluency Model?

There are four different zones that Teams can occupy: Focusing, Delivering, Optimizing, and Strengthening. A Team can exhibit fluency in any of these zones.
A behavior is fluent when you can perform it unconsciously, naturally, as a default behavior.
A Team can demonstrate fluency but only the Organization can make it possible.
It is not a maturity model, you can be fluent in one of the zones and not the others.

The Agile Dream:

For most organizations, it looks like focusing plus delivering together.

James talks about the structure of the book.

The first part of the book is about how to introduce Agile ideas.
Most of the book is about the practices for the focus and the delivery zone.
Alternatives and experiences can be found at the end of every practice.

Learn the rules, break the rules, and then, ignore the rules.

After learning the rules you have to experiment because every Agile Team goes through a unique situation and process.

How long does it take to achieve a level of fluency?

It takes time to really become fluid.
In general, it takes two to six months to reach focusing fluency. Have under consideration that there is a one-to-four-month period of decrease in performance while people learn.
During two to six months, performance will be affected while trying to reach fluency in delivering in an expected period from three to 20 months.
When Optimizing fluency it takes one to two months of performance affectedness and three to nine months for reaching fluency in this area.
It takes one or two years to deliver reliably.
All these time frames overlap.

Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Narrator [00:03]:Welcome to Agile Coaches’ Corner by Agile thought. The podcast for practitioners and leaders seeking advice to refine the way they work, ban pave the path to better outcomes. Now, here’s your host, coach band, agile expert, Dan Neumann.

Dan Neumann [00:17]:Welcome to this episode of the Agile Coach’s Corner podcast. I’m your host, Dan Neumann, and I am excited to have you join as we are now in the second episode of our fifth, our fifth year. We have four years under our belt. This is actually starting the fifth year. I had Sam Falco come back who is a co-founder, and I’m super excited to have a new guest here, James Shore. I, you may recognize that name. James is the author of a classic work on Agile, the Art of Agile Development. It’s one of those trusty books I have on my shelves that was super valuable for me when I first got it and continues to be. James is also the co-creator of the Agile Fluency Model with Diana Larson, and James has been recognized for his contributions to the Agile community with agile alliances, Gordon Pasch Award for contributions to agile practice. James, thank you for accepting the invite and coming to the Agile Coaches’ Goner podcast.

James Shore [01:16]:I’m happy to be here. Thanks for having me.

Dan Neumann [01:18]:One of the exciting things that has happened and a reason to have you here and share other than all the things you’ve done in the past is a very recent contribution. You have a second edition to the Art of Agile Development that is available and published in 2021.

James Shore [01:35]:Yeah, that’s right. It came out about a year ago now, and it’s basically a complete rewrite of the first edition. There’s some material that has carried over, but mostly it’s a rewrite. I’ve rebuilt it around the ideas and the agile fluency model that I created with Diana Larson put in a lot of new practices or updated practices for what the community has learned. Devops is in there, for example. MOB programming is in there. I’ve got a lot of new material about how to convince people to make a change to try agile ideas. And also what do you do when you’re in a situation where things aren’t very agile and how can you, how can you invest in that change?

Dan Neumann [02:14]:I love it. There’s a lot of, well, first of all, there’s a lot of people doing complimentary practices in Scrum or doing XP practices that that date to, you know, when I first started getting into Agile development, 2006 to 2009 was when I first got introduced. And I’m excited that you have included a lot of those new ideas, new notions, mob programming being one of those. And you also mentioned that it was inclusive of the Agile fluency model as part of your rewrite. Could you maybe share a little bit about what the Agile Fluency model is and then how it has informed the second edition of the Art of Agile Development?

James Shore [02:58]:Yeah, the actual fluency model is something that Diana Larson and I put together. After the first edition of the book came out she and I started doing courses around the material in the book. And one of the things, and we started doing a lot of work together, and one of the things that we noticed was that there was a, as you look at all the different organizations using Agile, even back then, the first edition came out in 2007 and we were working together heavily in basically 2008, 2009, beyond that. And when we, when we looked at the organizations that were saying they were doing Agile, they really fell into a bunch of different, what we call zones so different ways of practicing agile. And some are, were focused on, you know, how is, how do teams work together and how do we focus on business value?

James Shore [03:50]:And those were sort of the scrum camp. And then there were some that were focused on how do we deliver really effectively. And that was some aspects of the XP camp, although the XP folks also do a lot of work on how do we focus on value as well. And there were some folks who were thinking sort of lean startup type of things, how and, and lean software development, how do we incorporate product management and design ideas into the Agile team? And there were some of course looking like, what is the future of agile? What, what are the new exciting ideas? And so we looked at all these different ways that teams worked, and we sort of coalesced into the agile fluency model, which is a description of the different types of agile teams have. And I think it’s, it’s was true then, and it continues to be true today.

James Shore [04:44]:There’s really these four different zones and teams can occupy one or more of those zones. And they’re focusing, you know, focusing zone is about you know, how do we work as a team and how do we focus on business value delivering is about how do we do it technically. Optimizing is about how do we incorporate product management and really think about producing market leading products. And strengthening is sort of the cutting edge folks. And, and any of those zones a team can exhibit fluency or not. And fluency is when you can do the things that are in that zone, sort of with sex in by second nature kind of automatically without thinking about it.

Dan Neumann [05:26]:That that fluency concept was interesting. Much like language, then it’s, I’m a native English speaker, I don’t have to think about my English. Maybe I should sometimes, but I generally don’t have to. I did a little trip to Germany and my high school German got me dangerous in Germany, but I was definitely not fluent. I kind of stumbled through it. I had to be really intentional. It was effortful. I got a lot of stuff wrong. And I think that’s what you’re describing here is moving from not just kind of getting by with some of the agile practices, but really having mastery of them so that even when the going gets tough, you do the agile thing, you don’t resort or revert to some other prior less than agile behaviors. Is that how you would characterize fluency?

James Shore [06:13]:Absolutely. In fact, the inspiration for, you know, what sort of got us thinking in terms of fluency when we created the fluency model was that at the time Diana Larson’s son, Willam Larson was very heavily involved in an effort to help preserve Native American languages. And so he was doing a lot of work about language fluency, and of course, Diane and I were talking about that. And that’s what inspired us to sort of use that model. And, and one thing that I like about that is that you see these various maturity models in the world. You know, there’s the famous cmmi, the capability and maturity model integrated, I think is what it stands for. But there’s other maturity models. But what I like about the fluency model is that it is not a maturity model. It’s not saying you do this, then this, then this, and this. It’s saying there’s four types of fluency, four zones of fluency that teams can’t have or not have. And you might see few maturity in any one of those zones. Like you were saying when you went to Germany, you either don’t know, you know how to do anything in a zone. You might be working on it, you might be getting there to the point where if you’ve got somebody coaching you, you could do it. But it’s not until you really can do it unconsciously all the time. It’s your default behavior. That’s when you’re fluent.

Dan Neumann [07:31]:I like that you distinguished it from a maturity model. You’re not doing focusing first and then delivering and then optimizing. If I understand that that concept correctly, it’s still hard to kind of step back and go, what does that actually look like in practice? So could you maybe give an example of a company who’s trying, whose business goals align with either delivering or optimizing and, and how the fluency model might inform their journey. And then I think after that, it would be interesting to hear about how some of the, the agile practices that you elaborate in the book kind of support those. So kind of a long Yeah, question, I suppose.

James Shore [08:12]:Yeah. No, no, it’s a great question. I particularly appreciate that you said how a business can support it. So what you’ll see in the focusing zone, for example, is that a team that’s fluent in focusing will be able to plan the work in terms of business value rather than technical tasks. They’ll be able to demonstrate progress in perhaps with a demo of some sort or other in other way. The neat, one of the neat things, one of the things I really like about the fluency model is that it’s not prescriptive. It doesn’t say which practices you do. It’s more sort of a middle ground between the agile manifesto and and the practices. So it says these are the outcomes you’re gonna see, but not necessarily how you do it. So they’ll, a team that’s fluent in the focusing room will demonstrate progress.

James Shore [08:59]:They, the business stakeholders will be able to rely on the team to work in the order that they of priority that they think is important and, and other things that I describe and that we describe in the model and I’ve got in the book. But in order to achieve these results, yeah, you need the team to do the practices, but it’s really the organization that makes that possible. And the investment that the organization makes into the team to make these things possible is what creates fluency. The team demonstrates fluency, but the organization makes it possible. And I think that’s a really important thing that a lot of organizations don’t understand or miss.

Dan Neumann [09:39]:It’s interesting, I’ve, I’ve seen that as well where the organizations, well, we want the teams to be agile. We want them to be a good scrum team. We want our increments every sprint. Oh, but we’re not going to let them focus for two, three or four weeks at a time, or we don’t have a very clear vision they can align to, or we will second guess the choices that the teams are making or the product owners is bringing in. So there, there can be many systemic challenges that happen there. Yeah,

James Shore [10:08]:Yeah, a lot of, I mean, a lot of companies, a lot of organizations who are thinking about agile really only think of agile in terms of the focusing zone. And there is nothing wrong with the focusing zone. There’s, you know, serious benefits from achieving fluency in the focusing zone. But but there’s more to achieving that fluency than sending everybody to a two day scrum master training course. For, for example if you, if you want to have a successful focusing team, you need to have people on the team who have some understanding of what business value means or who are at least available to the team, you need to make that investment. They need, the team needs to have access to stakeholders. They the team needs a, a coach that they can work with. And this is sort of the easiest, lowest level of investments. If you want fluency in the delivering zone where you get really reliable deliveries, you need even more investments in more technical practices.

Dan Neumann [11:09]:James, one of the things that might help me wrap my head around some of the zones, you’d mentioned companies having business goals, and somewhere along the, the continuum, it’s probably not a continuum, so you can correct my word there, but somewhere along the zones of focusing, delivering, optimizing or strengthening, it might be appropriate to just focus and deliver or focus, deliver and optimize. Could you give maybe an example of how a company’s business goals would be appropriate to get to the delivering zone or to the optimizing but not farther?

James Shore [11:45]:Yeah, yeah, absolutely. And again, it’s, it’s not a maturity model, so it’s not really a progression between, from focusing to delivering to optimizing. It’s really four different dimensions any of which you can be fluent in or not. So you could be fluent in delivering only and none of the others you could be fluent in optimizing only and none of the others, or delivering and optimizing together, but not focusing really any of them is something that you could be fo fluent in.

Dan Neumann [12:11]:So they, you can be in optimizing and delivering, but not focusing it, it doesn’t build upon itself is,

James Shore [12:20]:I mean, you’ll have the most success. It, it is true that the various agile practices you know, reinforce each other. So there is a sort of a typical progression that companies follow just because that’s easy, but it’s not required. So it’s very, it’s what I see out there in the world is pretty common for companies to start with. Strm realize that that’s not enough, that they’re having trouble with technical, you know, the technical deliverable deliverability, and then they’ll introduce, you know, practices that help them get to delivering fluency. And then that will create trust in the organization and the team’s ability, and some of those teams will move on to the optimizing zone. So, so that’s sort of the typical progression. Teams that start with XP will do focusing and delivering together because ex extreme programming has the practices needed to reach fluency in both those zones.

James Shore [13:15]:Startups often start out with fluency in the optimizing zone and nothing else because in a small startup, you’ve got a lot of interest by everybody in the organization in how do we, you know, what is our market? How do we get product market fit, what are we gonna do? But they’re, the rest of their development practices are kind of ad hoc. And something that’s interesting that happened is as a startup tends to grow up, they say, oh, we need to get serious about software development. We need to stop messing around and, you know, get some adults in the room and they actually destroy their optimizing fluency because they stop having people, having the team have real access to stakeholders and making decisions that affect customers. So those are some examples of ways that people can progress through the zones, but it’s definitely not a, you do this than this, than this. There’s different choices that you can take, and each of those choice is a decision to invest to get benefits and making that decision is a business decision.

Dan Neumann [14:21]:That example was helpful, and I’ve seen the instances where you have that, the optimizing lean startup kind of company, and the scenarios I’ve seen, usually they’re acquired by somebody who says, oh, that’s interesting, I want that. Or even if it’s a defensive acquisition and it just squashes whatever good stuff was happening at the optimizing,

James Shore [14:44]:You also see it’s less common. But you can see companies or teams start with just delivering fluency particularly with the state of DevOps report, the Dora report and Accelerate book. There’s some companies that are really excited about getting continuous deployment and they want that level of fluency. Well, that’s the kind of thing that you see with delivering fluency. So you might have a team that focuses on delivering fluency before they’re really good at working as a team or focusing on value. They’re prob, you know, they might still be sort of doing technically focusing on technical priorities rather than business priorities. So yeah, these can go in, in any order.

Dan Neumann [15:23]:And simultaneously then, I’m assuming, based on some of the things you’re describing, is that also true?

James Shore [15:30]:It’s, it’s if you have, if you know you want, let’s say, so it’s a really, I would say kind of the, the ideal agile, the agile dream looks like focusing plus delivering, plus optimizing together. I think what is, for most organizations, the best bang for the buck to start with is focusing, plus delivering together. And it’s definitely true if you, so the, the way you use the model is you say, which of these zones is appropriate for us? Where, where do we want to be in a year or two? And then go all in on the practices needed to get you there because the practices are self-reinforcing. If you want to reach delivering delivering fluency, for example and have that continuous deployment and the low defects and the ability to release at the drop of a hat, that that gets you well, that is gonna be easier to do if you’re also doing the teamwork and planning work that comes along with the focusing zone.

Dan Neumann [16:31]:That’s wonderful. One of the things I loved about and, and will love in the second edition, I’d love you to talk about how it’s changed in the second edition is the, the self not self-reinforcing, the reinforcing between different practices. And now tying it to the agile fluency model for people not familiar with the second edition, could you maybe talk a little bit about how the book ties fluency in these business objectives for the zones to activities practices that they might look to adopt as part of their agile journey?

James Shore [17:03]:Yeah, absolutely. So the first part of the book is just, is about how do you introduce agile ideas whether or not you already have something that’s called Agile. How do you either evolve or expand that, or how do you introduce it from scratch? And that’s where the model is introduced and it says, well, here’s, here’s the benefits you get from each zone, and here’s the investments you need to make as an organization to get those benefits. And here’s how you influence change in the organization, and here’s how you deal with scaling. That’s part one. That’s actually a fairly small part of the book. I worked really hard to get the PA book to less than 400 pages, and I failed , the book is 500 pages long and

James Shore [17:44]:The, and, and we had to do the thing you know how when you’re in college and you’re like writing a paper and it’s supposed to be 10 pages long and you’re like adjusting the margins in and making the font bigger, , we did it the other direction. The margins are a little, a little tight because I just, I didn’t want the book to be too thick. So yeah, there’s, there’s a lot in there about how do you get going with with Agile, but that’s, that’s a, that’s a fraction of the book. Most of the book is the practices and it’s divided into practices for the focusing zone and practicing for the delivery zone. And then a little bit about the optimizing zone, which is in a lot of ways an extension of doing, focusing and delivering really well in terms of getting to fluency.

James Shore [18:29]:And, but it’s true that some, as you know, delivering is easier when you have got focusing practices and focusing is easier when you’ve got delivering practices. So throughout the book there’s these little sidebars and in the in the e-book version, we made them links. I’m really proud that we’ve got the same source code for both of them, but shows up as links in the ebook and as, as little sidebar in the print edition. And and they, they’re, they’re, they’re called allies and it’s, and throughout the book constantly it will say something like, you know, well, I’m just opening to a random page and I’m looking at the adaptive, the visual planning practice, which is about things like Jeff Patton’s story mapping and GOCO ad six impact mapping. And it says, you know, in an impact map you’re gonna start with the goal. And then over in the corner it says, well, your ally for this is the purpose practice, which is how you decide your goal. And that kind of thing is just completely a continuously throughout the book. Pretty much every page has got an ally.

Dan Neumann [19:32]:That was one of my favorite things in the first edition. And my new task is to become more familiar with the second edition. Cuz it sounds like some tremendous additions for people like me that read at a tortoise pace. How might you it’s, it’s true. I don’t, A 500 pager for me is a big effort. How might you suggest consuming the, the information in there? I mean, is it front to back? Is it pick, you know, find your spot in the zone and, and hop to the practices? What, what’s your,what’s your tips for slow readers like me?

James Shore [20:06]:Well, I, I feel you and I hear you and I, I don’t want people to be scared off by the idea of a 500 page book. One of the things I thought we did really well my co-author for the first edition was, was Shane Warden, although he wasn’t available to work with me on the second edition. One of the things that I thought we did really well in the first edition was we made it as something that you could read cover to cover or pick up and read as a reference. So each individual practice in the book is typically two to 10 pages. It’s quite, quite brief, you know, definitely something you could sit down and read. I think the average, I I haven’t actually gone through and calculated it, but the average is probably like three or four, maybe five pages.

Dan Neumann [20:43]:I can do that.

James Shore [20:45]:And yeah, so the idea is if you’re, if you’re just interested in like learning how to fine tune a practice or maybe how can you experiment with a practice? Because one of the things I love about the second edition is at the end of every practice I have this section called Alternatives and Experiments, and it sort of summarizes, this is what this is all about and here’s how you can experiment with getting that result in a different way. And here’s some other things that people have tried, and some of them this is what works and this is what doesn’t work, and here’s some other ways you can experiment with it. So perhaps you’ve, let me just flip over and again, at random impediment removal is one of the practices, so maybe you wanna read up on that. Well, that is, you know, 1, 2, 3, 4, 5 pages. So you can just read that. And by the way, that one Diana Larson wrote for, for us, which and I think she did a great job,

Narrator [21:40]:Have a topic you want us to tackle, send an email to podcast@agilethought.com or tweet it with a hashtag agile thought podcast.

Dan Neumann [21:51]:I am, I’m looking forward to that. So, and, and I wanted to appreciate that you put in, here’s a way to experiment with it. One of the challenges I see with organizations is the change seems really big and intimidating, and we have to plan it to the nth degree and we have to get it right and oh gosh, what, what if it doesn’t work? And I think it was Chip and Dan Heath in their book Switch where they talk about shrinking the change to make it more achievable. And I think what you’re describing fits into that well, where it’s now where we’re shrinking the change, we’re making it safe to run an experiment.

James Shore [22:27]:Well, of course, and agile, and I think this, you know, agile has sort of shrunk in people’s minds to standups and stories and for a lot of people excessive micromanage bureaucracy. And that makes me really sad when I hear, when I hear that, because, you know, that’s not what agile is all about. One of the things that Agile is about is continuous learning and experimentation and adapting and improving your process. So so the book is very much geared towards that mindset. Of course, we’ve got the retrospectives practice in there. We’ve got a whole chapter on improvement. Retrospectives is one of the practices in that chapter. Impediment removal is another one, the one I just mentioned. And but the, the core idea, if you, you know, the very second chapter of the book after, you know, what is Agile and how is it different than Caru Cold, agile?

James Shore [23:23]:The, the second chapter of the book says, you know, how do you master the Art of Agile development? And the answer is, is first you take something that somebody has, you know, you take something that’s written down like, like my book, and you do it by the book and you learn from that and see how it works. And then once you feel like you know how to do it by the book, you look at what isn’t working very well and you start making changes, you make a change, you observe what happens. You go back to the book and study, you know what it says, and you try, you keep, keep trying new things and you break the rules. Now this comes from Alistair Co Coburn’s Shoe Hari. First you, you learn the rules, then you break the rules, then you ignore the rules. So after you’ve learned the rules, you’ve gotta experiment and you’ve gotta find out what’s unique about your situation and how you can change the ideas of agile to better fit your situation. Because every agile team has a process that is unique to their team if they’re doing it well.

Dan Neumann [24:26]:Now a agreed, and I feel one of the, like you mentioned, the cargo cult agile, that’s definitely okay. We, we have a, we stand up 15 minutes every day, by the way. We actually just do a kind of status report. We actually don’t collaborate whatever there, there’s that cargo cult and the other related dysfunction that I think is in that is the binary agile. It’s agile or it’s not agile. We end up with these contests, if you will. We’ll keep it pg friendly here, but you have the contest about well, that’s not agile. That’s not agile and it’s not a helpful conversation.

James Shore [25:01]:No, it’s not. But it is the kind of behavior you see from, well, to be honest, beginners, because beginners learn best by being, by beginners. Look for a cookbook, a a set of rules that we can follow. And, and it is a great way to learn to, to follow the book. But that can lead to people who, who, who are speaking to beginners. So maybe some of these trainers, I think the scrum guide tends to be a little bit dogmatic about this is Scrum and this is not, well, it’s targeting people who are trying to learn what it is. And that’s a good way to learn. And that’s what my recommendation is too, you know, follow the book exactly as written when you’re starting out. Because if you start tweaking it from the beginning, you’re gonna take out the stuff that’s really unique and different because it’s gonna feel uncomfortable.

James Shore [25:47]:So go ahead and do those things that are unique and uncomfortable, but then, and this is why the alternative to experiment sections are just littered throughout the book. Every single practice has it. Then after you’ve had that experience, now it’s time to experiment. Now it’s time to change. And I think after people have had more experience, they start letting go of that this is the, the one right way. But it can take a while. And I think there is some messaging in the community, maybe by people who tend to work mostly with beginners that sort of are downplaying the value of that customization. But I think customization is absolutely at the heart of what successful agile looks like.

Dan Neumann [26:26]:That That’s very cool. I don’t wanna throw you a curve ball, but at, with the risk of roughly how many practices would you say are in the second edition?

James Shore [26:35]:That is a great question and I should know the answer to that off the top of my head, but I don’t, we could, so let me just, let me just run through it real quick, quick. Yeah. so in the focusing section we got seven teamwork practices, six planning practices, seven ownership practices, five accountability practices, and three improvement practices. And in the delivering zone we’ve got four collaboration practices, six development practices, three design practices, four DevOps practices, and three quality practices. And then there’s two or three chapters in the optimizing section, but that’s organized a bit differently. So it’s hard to compare.

Dan Neumann [27:15]:That’s tremendous. And it makes me just kind of consciously reflect on how often and how much focuses on a handful of different things and I hesitate to enumerate them. But so much of like the agile talk is, I dunno, I’ll pick on user stories or scrum or, you know, there’s a couple more. And I think what your second edition will do for folks is really open their eyes to, oh, that one. Yeah, either I’ve heard about it and forgot about it, or I didn’t know anything about it and my, now I might like to try it.

James Shore [27:48]:Yeah, I would love for people to take the book and just sort of flip through it and, and stop and say, oh, that’s looks interesting. And at the print edition at least, we’ve got these little call outs, sort of like magazine pull quotes that sort of highlight interesting things. So you can just flip it open, randomly find one and look for those quotes. And if one of them looks interesting, you can sort of stop and read that practice. And it’s only a couple of pages, right. So I love

Dan Neumann [28:12]:It.

James Shore [28:13]:Yeah.

Dan Neumann [28:13]:And do you have a, a resource we wanted to make sure to mention four folks interested in the content, but maybe the, the print book hasn’t shown up yet or they’re, they’re trying to become a little more familiar with it before they, before they buy it and it on james shore.com and we’ll put a link to the, the full location. But you’ve got a version two book a lot of details in there. The chapter intros, you have conversations with thought leaders. I know you mentioned several of them. Diana Larson was in there. And I’m blanking, but I mean, yeah, can you, could you talk a little bit about the resources on the site for

James Shore [28:52]:Folks? Yeah, yeah. I, I would love for people to go to the site and, and join the conversation and see all the material I’ve put out. We we’re pretty close to the one year anniversary of the book coming out. So if you go to james shore.com/s/ao a D two, that’s Art of Agile Development two, that’s sort of the short link that we’ll take you to, to the page. If you go there, you’ll see sort of a description. You’ll see down at the bottom of the page, the table of contents. Every single section of the book has got an excerpt from it in it which is the opening section of a practice. But also I got O’Reilly O’Reilly’s, the publisher O’Reilly gave me permission to excerpt a huge amount of the book, 25% of the book. And so just yesterday for that for that one year anniversary, I went out, I went through and I put the most, what I felt were like some of the most important practices. I put the full text out there and they’re just available for you to read. And that’s things like adaptive planning and incremental design, which is part of evolutionary design and test driven development and stakeholder trust and task planning and capacity, which some people call velocity. Some of my favorite practices are, are out there and I encourage people to check ’em out,

Dan Neumann [30:08]:That, that is beautiful. And then there are some audio conversations about different practices there as well.

James Shore [30:15]:Yeah, yeah. So for nearly a year after the book came out, I did a weekly book club where it was a call in talk show. So I had, you know, people just, you know, sharing their thoughts, but I also had a lot of a lot of luminaries in the agile world.

Dan Neumann [30:33]:You mentioned Linda Rising, that was the name I was desperately trying to come up with. I’m a huge fan of hers too.

James Shore [30:39]:Kent Beck Jeff Patton, Martin Fowler yeah, Linda Rising at Woody Zo on there. Talking about mob program, gi click guard, who did the psychological safety Mike Hill and Joe Berg are talking about test driven development. It was just DevOps. I had Jessica Care talking about DevOps and Kelsey High Tower talking about continuous deployment. Such a, a great set. And those folks are all linked from that page. James shore.com/s/ao a D

Dan Neumann [31:09]:Two. That’s wonderful. And what a, what a great contribution to the community, both authoring the first edition and now a, a complete rewrite second edition. So I am going to add that to the print bookshelf and it’ll be on the Kindle. Cause when I travel, you can’t drag a bookshelf with you. And then the audio version, so I can listen to it when I’m driving because I, you know, actually I say, is there an audio version?

James Shore [31:32]:You know, I’ve been asked that, and O’Reilly, the publisher would have to come to me. But when I did the book club at the beginning of each book club, I would read like a little excerpt. And a lot of people say, well, are you gonna do an audio version? So I guess my voice is, you know, of acceptable enough quality . I would love to do an audio version, audiobook version. I should reach out to O’Reilly and see see what they think about.

Dan Neumann [31:57]:I think, I think it would be helpful. Like I said, sometimes a, I like it for when I’m mobile and, and b, sometimes it’s easier to hear and follow along and it, it helps my brain track on that content. So I don’t know, for what it’s worth, you get my phone.

James Shore [32:12]:I think it, I think it would would be possible. There’s a couple of chap capital practices have a lot of code in them and I don’t know how well that would work, , but so, so for everybody listening, if you want an audio version, tell O’Reilly that you want an audio version because that’s just what’s gonna make it

Dan Neumann [32:29]:Happen. Absolutely. You mean they’ll wait for a demand signal before they’ll produce? That’s crazy. That’ll never work.

James Shore [32:34]:.

Dan Neumann [32:37]:I would take way more of your time if we didn’t have a little bit of a time box here. I was hoping you could touch on one thing and then maybe give some closing thoughts. Mm-Hmm. <Affirmative>, one of the facets that I liked about the white paper on Agile fluency was you put in some timeframes how long it might take to achieve a level of fluency. And I thought that was important. I know early on in my agile career, I got frustrated with the speed of change. I still can tend to be that way. Could you maybe talk to the time to fluency or how long organizations might expect to have this nirvana of agility?

James Shore [33:19]:Yeah, absolutely. I think one of the things that a lot of organizations don’t do when they’re trying to invest in fluency, or rather they’re declaring, okay, we wanna be agile, but they’re not actually investing in fluency, is they’re, they are com dramatically underestimating how long it takes to really become fluent. And I’ve got my own experience in this, and of course other people are gonna have different experiences. So I can’t say that what I’m about to say is absolutely a hundred percent correct for everyone. But in general, I would say to reach focusing fluency, which is where you’ve got the team able to focus on business priorities, give visibility into teams work, and have the ability to change direction whenever the business needs. You’re gonna look at one to four months of decreased performances as people learn and two to six months to reach fluency.

James Shore [34:12]:So, you know, and that depends on how much support they have and how much the organization’s investing and how much they want to do it too. And a lot of, I talk about this a lot more in the book when I’m talking about how do you create change in an organization, excuse me. And then in the delivering zone, the main benefit of that is low defects and high productivity and technical longevity. You know, not having to rewrite your software after a number of years because it’s because it’s too crafty. And that’s about a two to six perform month performance dip. And three to 24 months until fluency, depending on how much existing code you have that needs to be sort of fixed up and optimizing fluency. The benefit there is you’re gonna see higher value releases and better product decisions. You’re looking about a one to three month performance dip and three to nine months until fluency. Although it often takes a year or two of delivering reliably with delivering fluency before you can even get permission to, to make that investment. And one of the interesting things here though, is that those timeframes overlap. So investing in focusing and delivering together is not one to four months plus two to six months of a performance dip. It’s just two to six months together. And that’s one of the reasons why, if you think you’re gonna want focusing and delivering fluency, do ’em both at the same time

Dan Neumann [35:33]:So you don’t have those repeated dips. I think of the the change curve set tiers, change curve gets used for that sometimes, right? There’s dips. So interesting. Take take the dip at once if you know you’re doing both those things.

James Shore [35:45]:Yeah. And not only that, and we do have a, the change model or the Seti change model picture in the book because, you know, it’s, it’s so true. But the other thing that happens with teams that I think a lot of organizations don’t realize is they think, oh, we need to be agile about adopting agile, but agile is a software development philosophy. Is it a way of thinking about how do you do software development? People are not computers. People get sick of change. And so if you’re just dripping out a little change, a little change, a little change, a little change, people are gonna get burned out partly because the first little change is not gonna be sufficient on its own. It’s gonna run into all this friction with other things that you’re not doing yet. And second, you’re just gonna get changed to fatigue. So it’s actually better to take a big bite, swallow it, and then be done with it than to say, okay, we’re doing a little bit, and now, oh, great, that’s done. Now your reward is you get to do more uncomfortable stuff. Congratulations. Yay,

Dan Neumann [36:43]:. I, I love it. James, I want to appreciate that you’ve been so generous with your time and to share with me and the listeners, what closing thoughts might you have about Agile, the second edition, the Art Agile development, fluency, dealer’s choice, anything you’d like to share?

James Shore [37:00]:Yeah, I would say, you know, my takeaway for, for people who are listening is that there is no one size fits all agile. There are different ways you can think about agile. There’s different ways you can exhibit your agility. We’ve divided them up into four zones of focusing, delivering, optimizing, and strengthening. And I think that’s a pretty good model to be really successful with Agile, to be really successful with agile. Start out by deciding which of those zones your organization needs, which benefits do you need, and then truly, truly make the investments to reach fluency in those zones. And my book, you know, blatant plug, it’s one way to help you get there, but it’s not the only way.

Dan Neumann [37:49]:There has to be one only way. I mean, well, I, I have no doubt the second edition will help a tremendous number of folks get there. It’s,it’s an important topic and the way this is constructed is super valuable. So thank you again for that.

James Shore [38:07]:Yeah, my pleasure. Thanks for having me.

Dan Neumann [38:10]:We ask folks at the end of our episodes what’s on their continuous learning journey, and I’m curious if you have something you’d like to share as part of James Shore’s continuous learning journey.

James Shore [38:20]:I, I do, you know, now that the book is done the nice thing about writing a book is it sort of takes all the stuff that you’re constantly thinking about, gets it out of your head, right? And so now I’m o I’m freed up to work on what my other passionate passion is, which is well business related passion. I have been working with teams and organizations that have lots of teams for, for many years now, and people call this the scaling, scaling problem. And I’ve been helping them with that for a long time. And I’ve tried a bunch of different things and the majority of the way I used to work on it was very similar to what what was published in the book Team Topologies, which I call a horizontal scaling approach. And it has some, it has some real flaws, it tends to be fairly rigid and for larger organizations you know, I did it with an organization, I did it in New Relic and they had 42 teams when I was done working with them.

James Shore [39:21]:There are some real limits to what you can get from that horizontal scaling team topology style approach. So I’ve been looking for a better approach. And what I’ve found is something called fast fluid scaling technology, which is a way of having a bunch of teams work together as a single virtual team. And it’s extremely innovative. I’ve done it, I’ve done it in a remote environment and it has been the most successful approach to scaling I’ve ever seen. And so I’m looking at doing it some more, and then after I’ve had some more experience with it, maybe that’ll be my next book.

Dan Neumann [39:51]:That sounds outstanding because scaling is def there, there’s a need for it, there’s a place for it. There’s also a place not for it. Like not everybody has to scale, which I think is a misconception, and there needs to be a little bit of diversity of, of thought on how we can scale agile teams. So I am excited to hear and wait for more on that contribution.

James Shore [40:14]:Yeah, absolutely. You can learn about Fast by going to fast agile.io and I have a number of presentations on it. I don’t have a short link, so I’ll just give that to you to put in the, in

Dan Neumann [40:24]:The show notes. We’ll put it in the show notes. The show notes are at agile.com/podcast and we’ll put a link to Fast agile.io in there as well. Thank you again, James. I really do appreciate you taking some time to share and all the contributions to the community for, you know, decade plus. So thank you very much. I’m well beyond a decade at this point, isn’t it?

James Shore [40:48]:It’s more like 22 years. I’m sad to say.

Dan Neumann [40:51]:That is, that is tremendous .

James Shore [40:54]:It’s been a pleasure. Thank you so much for having me on. I’ve had a great time.

Narrator [40:58]:This has been the Agile Coaches Corner podcast, brought to you by Agile thought. The views, opinions, and information expressed in this podcast are solely those of the host and the guests, and do not necessarily represent those of Agile thought. Get the show notes and other helpful tips from this episode and other episodes@agilethought.com slash podcast.

Mentioned in this Episode:

Follow James Shore.

Check the second edition of The Art of Agile Development.

Agile Fluency Project

FAST Agile

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

Share These Tweets!

“A Team can exhibit fluency in these four zones: Focusing, Delivering, Optimizing, and Strengthening.” — James Shore

“You are fluent when you can perform a task unconsciously all the time, it is your default behavior.” — James Shore

“A Team can demonstrate fluency but only the Organization can make it possible.” — James Shore

“Agile is a software development philosophy, but people are not computers; they get sick of change.” — James Shore

Speakers

Dan Neumann

Principal Enterprise Coach

Dan Neuman is the Director of the US Transformation and Coaching practice in the Agility guild. He coaches organizations to transform the way they work to achieve their desired business outcomes.

With more than 25 years of experience, Dan Neumann is an experienced Agile Coach with a deep knowledge of Agility at the team and organizational levels. He focuses on achieving business outcomes by shifting both mindset and practices, resulting in a disciplined, yet practical approach to solving problems.

10 Things a Java Developer Should Learn These Days

We are halfway into the year and, looking back at what the last 2 years of the COVID-19 pandemic left us, we can say that the advancements on technology and all the different languages, frameworks and development tools have not disappointed us and even in many cases have overtaken us. It doesn’t seem that long since Java 8 was released more than 8 years ago and, although it is true that today the latest version is Java 18, we must remember that there are still many companies stuck with Java 8 and even a few with Java 1.4 a 1.6 and a few other legacy frameworks.Because of this great advance in programming languages and frameworks in recent years, many programmers could feel overwhelmed due to the large number of updates that we are exposed to in our industry. However, we have begun to see very marked patterns in different industries, and we believe it is important to mention what are the 10 things that every Java programmer should learn.

6 min read

August 25, 2022

Succeeding at Cost Takeout – Improving Cost Management Strategy

The cost takeout is a strategic initiative that can help your company become more efficient. The goal of the initiative is to determine ways to reduce expenses without sacrificing quality, speed or customer satisfaction. A successful cost takeout requires an accurate understanding of where costs arise in your business process and how those costs can be reduced through new technologies. In this guide, we’ll look at some of the most common drivers of costs in IT departments and explain how you can identify them within your own organization’s processes.Cost drivers are the factors that cause your costs to increase. They’re different for every business, but you can identify them by asking yourself: “What makes my costs go up?”

10 min read

February 7, 2023

Podcast EP 212. Are You Fluent in Agile? with James Shore

Narrator [00:03]

Welcome to Agile Coaches’ Corner by Agile thought. The podcast for practitioners and leaders seeking advice to refine the way they work, ban pave the path to better outcomes. Now, here’s your host, coach band, agile expert, Dan Neumann.

Dan Neumann [00:17]

Welcome to this episode of the Agile Coach’s Corner podcast. I’m your host, Dan Neumann, and I am excited to have you join as we are now in the second episode of our fifth, our fifth year. We have four years under our belt. This is actually starting the fifth year. I had Sam Falco come back who is a co-founder, and I’m super excited to have a new guest here, James Shore. I, you may recognize that name. James is the author of a classic work on Agile, the Art of Agile Development. It’s one of those trusty books I have on my shelves that was super valuable for me when I first got it and continues to be. James is also the co-creator of the Agile Fluency Model with Diana Larson, and James has been recognized for his contributions to the Agile community with agile alliances, Gordon Pasch Award for contributions to agile practice. James, thank you for accepting the invite and coming to the Agile Coaches’ Goner podcast.

James Shore [01:16]

I’m happy to be here. Thanks for having me.

Dan Neumann [01:18]

One of the exciting things that has happened and a reason to have you here and share other than all the things you’ve done in the past is a very recent contribution. You have a second edition to the Art of Agile Development that is available and published in 2021.

James Shore [01:35]

Yeah, that’s right. It came out about a year ago now, and it’s basically a complete rewrite of the first edition. There’s some material that has carried over, but mostly it’s a rewrite. I’ve rebuilt it around the ideas and the agile fluency model that I created with Diana Larson put in a lot of new practices or updated practices for what the community has learned. Devops is in there, for example. MOB programming is in there. I’ve got a lot of new material about how to convince people to make a change to try agile ideas. And also what do you do when you’re in a situation where things aren’t very agile and how can you, how can you invest in that change?

Dan Neumann [02:14]

I love it. There’s a lot of, well, first of all, there’s a lot of people doing complimentary practices in Scrum or doing XP practices that that date to, you know, when I first started getting into Agile development, 2006 to 2009 was when I first got introduced. And I’m excited that you have included a lot of those new ideas, new notions, mob programming being one of those. And you also mentioned that it was inclusive of the Agile fluency model as part of your rewrite. Could you maybe share a little bit about what the Agile Fluency model is and then how it has informed the second edition of the Art of Agile Development?

James Shore [02:58]

Yeah, the actual fluency model is something that Diana Larson and I put together. After the first edition of the book came out she and I started doing courses around the material in the book. And one of the things, and we started doing a lot of work together, and one of the things that we noticed was that there was a, as you look at all the different organizations using Agile, even back then, the first edition came out in 2007 and we were working together heavily in basically 2008, 2009, beyond that. And when we, when we looked at the organizations that were saying they were doing Agile, they really fell into a bunch of different, what we call zones so different ways of practicing agile. And some are, were focused on, you know, how is, how do teams work together and how do we focus on business value?

James Shore [03:50]

And those were sort of the scrum camp. And then there were some that were focused on how do we deliver really effectively. And that was some aspects of the XP camp, although the XP folks also do a lot of work on how do we focus on value as well. And there were some folks who were thinking sort of lean startup type of things, how and, and lean software development, how do we incorporate product management and design ideas into the Agile team? And there were some of course looking like, what is the future of agile? What, what are the new exciting ideas? And so we looked at all these different ways that teams worked, and we sort of coalesced into the agile fluency model, which is a description of the different types of agile teams have. And I think it’s, it’s was true then, and it continues to be true today.

James Shore [04:44]

There’s really these four different zones and teams can occupy one or more of those zones. And they’re focusing, you know, focusing zone is about you know, how do we work as a team and how do we focus on business value delivering is about how do we do it technically. Optimizing is about how do we incorporate product management and really think about producing market leading products. And strengthening is sort of the cutting edge folks. And, and any of those zones a team can exhibit fluency or not. And fluency is when you can do the things that are in that zone, sort of with sex in by second nature kind of automatically without thinking about it.

Dan Neumann [05:26]

That that fluency concept was interesting. Much like language, then it’s, I’m a native English speaker, I don’t have to think about my English. Maybe I should sometimes, but I generally don’t have to. I did a little trip to Germany and my high school German got me dangerous in Germany, but I was definitely not fluent. I kind of stumbled through it. I had to be really intentional. It was effortful. I got a lot of stuff wrong. And I think that’s what you’re describing here is moving from not just kind of getting by with some of the agile practices, but really having mastery of them so that even when the going gets tough, you do the agile thing, you don’t resort or revert to some other prior less than agile behaviors. Is that how you would characterize fluency?

James Shore [06:13]

Absolutely. In fact, the inspiration for, you know, what sort of got us thinking in terms of fluency when we created the fluency model was that at the time Diana Larson’s son, Willam Larson was very heavily involved in an effort to help preserve Native American languages. And so he was doing a lot of work about language fluency, and of course, Diane and I were talking about that. And that’s what inspired us to sort of use that model. And, and one thing that I like about that is that you see these various maturity models in the world. You know, there’s the famous cmmi, the capability and maturity model integrated, I think is what it stands for. But there’s other maturity models. But what I like about the fluency model is that it is not a maturity model. It’s not saying you do this, then this, then this, and this. It’s saying there’s four types of fluency, four zones of fluency that teams can’t have or not have. And you might see few maturity in any one of those zones. Like you were saying when you went to Germany, you either don’t know, you know how to do anything in a zone. You might be working on it, you might be getting there to the point where if you’ve got somebody coaching you, you could do it. But it’s not until you really can do it unconsciously all the time. It’s your default behavior. That’s when you’re fluent.

Dan Neumann [07:31]

I like that you distinguished it from a maturity model. You’re not doing focusing first and then delivering and then optimizing. If I understand that that concept correctly, it’s still hard to kind of step back and go, what does that actually look like in practice? So could you maybe give an example of a company who’s trying, whose business goals align with either delivering or optimizing and, and how the fluency model might inform their journey. And then I think after that, it would be interesting to hear about how some of the, the agile practices that you elaborate in the book kind of support those. So kind of a long Yeah, question, I suppose.

James Shore [08:12]

Yeah. No, no, it’s a great question. I particularly appreciate that you said how a business can support it. So what you’ll see in the focusing zone, for example, is that a team that’s fluent in focusing will be able to plan the work in terms of business value rather than technical tasks. They’ll be able to demonstrate progress in perhaps with a demo of some sort or other in other way. The neat, one of the neat things, one of the things I really like about the fluency model is that it’s not prescriptive. It doesn’t say which practices you do. It’s more sort of a middle ground between the agile manifesto and and the practices. So it says these are the outcomes you’re gonna see, but not necessarily how you do it. So they’ll, a team that’s fluent in the focusing room will demonstrate progress.

James Shore [08:59]

They, the business stakeholders will be able to rely on the team to work in the order that they of priority that they think is important and, and other things that I describe and that we describe in the model and I’ve got in the book. But in order to achieve these results, yeah, you need the team to do the practices, but it’s really the organization that makes that possible. And the investment that the organization makes into the team to make these things possible is what creates fluency. The team demonstrates fluency, but the organization makes it possible. And I think that’s a really important thing that a lot of organizations don’t understand or miss.

Dan Neumann [09:39]

It’s interesting, I’ve, I’ve seen that as well where the organizations, well, we want the teams to be agile. We want them to be a good scrum team. We want our increments every sprint. Oh, but we’re not going to let them focus for two, three or four weeks at a time, or we don’t have a very clear vision they can align to, or we will second guess the choices that the teams are making or the product owners is bringing in. So there, there can be many systemic challenges that happen there. Yeah,

James Shore [10:08]

Yeah, a lot of, I mean, a lot of companies, a lot of organizations who are thinking about agile really only think of agile in terms of the focusing zone. And there is nothing wrong with the focusing zone. There’s, you know, serious benefits from achieving fluency in the focusing zone. But but there’s more to achieving that fluency than sending everybody to a two day scrum master training course. For, for example if you, if you want to have a successful focusing team, you need to have people on the team who have some understanding of what business value means or who are at least available to the team, you need to make that investment. They need, the team needs to have access to stakeholders. They the team needs a, a coach that they can work with. And this is sort of the easiest, lowest level of investments. If you want fluency in the delivering zone where you get really reliable deliveries, you need even more investments in more technical practices.

Dan Neumann [11:09]

James, one of the things that might help me wrap my head around some of the zones, you’d mentioned companies having business goals, and somewhere along the, the continuum, it’s probably not a continuum, so you can correct my word there, but somewhere along the zones of focusing, delivering, optimizing or strengthening, it might be appropriate to just focus and deliver or focus, deliver and optimize. Could you give maybe an example of how a company’s business goals would be appropriate to get to the delivering zone or to the optimizing but not farther?

James Shore [11:45]

Yeah, yeah, absolutely. And again, it’s, it’s not a maturity model, so it’s not really a progression between, from focusing to delivering to optimizing. It’s really four different dimensions any of which you can be fluent in or not. So you could be fluent in delivering only and none of the others you could be fluent in optimizing only and none of the others, or delivering and optimizing together, but not focusing really any of them is something that you could be fo fluent in.

Dan Neumann [12:11]

So they, you can be in optimizing and delivering, but not focusing it, it doesn’t build upon itself is,

James Shore [12:20]

I mean, you’ll have the most success. It, it is true that the various agile practices you know, reinforce each other. So there is a sort of a typical progression that companies follow just because that’s easy, but it’s not required. So it’s very, it’s what I see out there in the world is pretty common for companies to start with. Strm realize that that’s not enough, that they’re having trouble with technical, you know, the technical deliverable deliverability, and then they’ll introduce, you know, practices that help them get to delivering fluency. And then that will create trust in the organization and the team’s ability, and some of those teams will move on to the optimizing zone. So, so that’s sort of the typical progression. Teams that start with XP will do focusing and delivering together because ex extreme programming has the practices needed to reach fluency in both those zones.

James Shore [13:15]

Startups often start out with fluency in the optimizing zone and nothing else because in a small startup, you’ve got a lot of interest by everybody in the organization in how do we, you know, what is our market? How do we get product market fit, what are we gonna do? But they’re, the rest of their development practices are kind of ad hoc. And something that’s interesting that happened is as a startup tends to grow up, they say, oh, we need to get serious about software development. We need to stop messing around and, you know, get some adults in the room and they actually destroy their optimizing fluency because they stop having people, having the team have real access to stakeholders and making decisions that affect customers. So those are some examples of ways that people can progress through the zones, but it’s definitely not a, you do this than this, than this. There’s different choices that you can take, and each of those choice is a decision to invest to get benefits and making that decision is a business decision.

Dan Neumann [14:21]

That example was helpful, and I’ve seen the instances where you have that, the optimizing lean startup kind of company, and the scenarios I’ve seen, usually they’re acquired by somebody who says, oh, that’s interesting, I want that. Or even if it’s a defensive acquisition and it just squashes whatever good stuff was happening at the optimizing,

James Shore [14:44]

You also see it’s less common. But you can see companies or teams start with just delivering fluency particularly with the state of DevOps report, the Dora report and Accelerate book. There’s some companies that are really excited about getting continuous deployment and they want that level of fluency. Well, that’s the kind of thing that you see with delivering fluency. So you might have a team that focuses on delivering fluency before they’re really good at working as a team or focusing on value. They’re prob, you know, they might still be sort of doing technically focusing on technical priorities rather than business priorities. So yeah, these can go in, in any order.

Dan Neumann [15:23]

And simultaneously then, I’m assuming, based on some of the things you’re describing, is that also true?

James Shore [15:30]

It’s, it’s if you have, if you know you want, let’s say, so it’s a really, I would say kind of the, the ideal agile, the agile dream looks like focusing plus delivering, plus optimizing together. I think what is, for most organizations, the best bang for the buck to start with is focusing, plus delivering together. And it’s definitely true if you, so the, the way you use the model is you say, which of these zones is appropriate for us? Where, where do we want to be in a year or two? And then go all in on the practices needed to get you there because the practices are self-reinforcing. If you want to reach delivering delivering fluency, for example and have that continuous deployment and the low defects and the ability to release at the drop of a hat, that that gets you well, that is gonna be easier to do if you’re also doing the teamwork and planning work that comes along with the focusing zone.

Dan Neumann [16:31]

That’s wonderful. One of the things I loved about and, and will love in the second edition, I’d love you to talk about how it’s changed in the second edition is the, the self not self-reinforcing, the reinforcing between different practices. And now tying it to the agile fluency model for people not familiar with the second edition, could you maybe talk a little bit about how the book ties fluency in these business objectives for the zones to activities practices that they might look to adopt as part of their agile journey?

James Shore [17:03]

Yeah, absolutely. So the first part of the book is just, is about how do you introduce agile ideas whether or not you already have something that’s called Agile. How do you either evolve or expand that, or how do you introduce it from scratch? And that’s where the model is introduced and it says, well, here’s, here’s the benefits you get from each zone, and here’s the investments you need to make as an organization to get those benefits. And here’s how you influence change in the organization, and here’s how you deal with scaling. That’s part one. That’s actually a fairly small part of the book. I worked really hard to get the PA book to less than 400 pages, and I failed , the book is 500 pages long and

James Shore [17:44]

The, and, and we had to do the thing you know how when you’re in college and you’re like writing a paper and it’s supposed to be 10 pages long and you’re like adjusting the margins in and making the font bigger, , we did it the other direction. The margins are a little, a little tight because I just, I didn’t want the book to be too thick. So yeah, there’s, there’s a lot in there about how do you get going with with Agile, but that’s, that’s a, that’s a fraction of the book. Most of the book is the practices and it’s divided into practices for the focusing zone and practicing for the delivery zone. And then a little bit about the optimizing zone, which is in a lot of ways an extension of doing, focusing and delivering really well in terms of getting to fluency.

James Shore [18:29]

And, but it’s true that some, as you know, delivering is easier when you have got focusing practices and focusing is easier when you’ve got delivering practices. So throughout the book there’s these little sidebars and in the in the e-book version, we made them links. I’m really proud that we’ve got the same source code for both of them, but shows up as links in the ebook and as, as little sidebar in the print edition. And and they, they’re, they’re, they’re called allies and it’s, and throughout the book constantly it will say something like, you know, well, I’m just opening to a random page and I’m looking at the adaptive, the visual planning practice, which is about things like Jeff Patton’s story mapping and GOCO ad six impact mapping. And it says, you know, in an impact map you’re gonna start with the goal. And then over in the corner it says, well, your ally for this is the purpose practice, which is how you decide your goal. And that kind of thing is just completely a continuously throughout the book. Pretty much every page has got an ally.

Dan Neumann [19:32]

That was one of my favorite things in the first edition. And my new task is to become more familiar with the second edition. Cuz it sounds like some tremendous additions for people like me that read at a tortoise pace. How might you it’s, it’s true. I don’t, A 500 pager for me is a big effort. How might you suggest consuming the, the information in there? I mean, is it front to back? Is it pick, you know, find your spot in the zone and, and hop to the practices? What, what’s your,what’s your tips for slow readers like me?

James Shore [20:06]

Well, I, I feel you and I hear you and I, I don’t want people to be scared off by the idea of a 500 page book. One of the things I thought we did really well my co-author for the first edition was, was Shane Warden, although he wasn’t available to work with me on the second edition. One of the things that I thought we did really well in the first edition was we made it as something that you could read cover to cover or pick up and read as a reference. So each individual practice in the book is typically two to 10 pages. It’s quite, quite brief, you know, definitely something you could sit down and read. I think the average, I I haven’t actually gone through and calculated it, but the average is probably like three or four, maybe five pages.

Dan Neumann [20:43]

I can do that.

James Shore [20:45]

And yeah, so the idea is if you’re, if you’re just interested in like learning how to fine tune a practice or maybe how can you experiment with a practice? Because one of the things I love about the second edition is at the end of every practice I have this section called Alternatives and Experiments, and it sort of summarizes, this is what this is all about and here’s how you can experiment with getting that result in a different way. And here’s some other things that people have tried, and some of them this is what works and this is what doesn’t work, and here’s some other ways you can experiment with it. So perhaps you’ve, let me just flip over and again, at random impediment removal is one of the practices, so maybe you wanna read up on that. Well, that is, you know, 1, 2, 3, 4, 5 pages. So you can just read that. And by the way, that one Diana Larson wrote for, for us, which and I think she did a great job,

Narrator [21:40]

Have a topic you want us to tackle, send an email to podcast@agilethought.com or tweet it with a hashtag agile thought podcast.

Dan Neumann [21:51]

I am, I’m looking forward to that. So, and, and I wanted to appreciate that you put in, here’s a way to experiment with it. One of the challenges I see with organizations is the change seems really big and intimidating, and we have to plan it to the nth degree and we have to get it right and oh gosh, what, what if it doesn’t work? And I think it was Chip and Dan Heath in their book Switch where they talk about shrinking the change to make it more achievable. And I think what you’re describing fits into that well, where it’s now where we’re shrinking the change, we’re making it safe to run an experiment.

James Shore [22:27]

Well, of course, and agile, and I think this, you know, agile has sort of shrunk in people’s minds to standups and stories and for a lot of people excessive micromanage bureaucracy. And that makes me really sad when I hear, when I hear that, because, you know, that’s not what agile is all about. One of the things that Agile is about is continuous learning and experimentation and adapting and improving your process. So so the book is very much geared towards that mindset. Of course, we’ve got the retrospectives practice in there. We’ve got a whole chapter on improvement. Retrospectives is one of the practices in that chapter. Impediment removal is another one, the one I just mentioned. And but the, the core idea, if you, you know, the very second chapter of the book after, you know, what is Agile and how is it different than Caru Cold, agile?

James Shore [23:23]

The, the second chapter of the book says, you know, how do you master the Art of Agile development? And the answer is, is first you take something that somebody has, you know, you take something that’s written down like, like my book, and you do it by the book and you learn from that and see how it works. And then once you feel like you know how to do it by the book, you look at what isn’t working very well and you start making changes, you make a change, you observe what happens. You go back to the book and study, you know what it says, and you try, you keep, keep trying new things and you break the rules. Now this comes from Alistair Co Coburn’s Shoe Hari. First you, you learn the rules, then you break the rules, then you ignore the rules. So after you’ve learned the rules, you’ve gotta experiment and you’ve gotta find out what’s unique about your situation and how you can change the ideas of agile to better fit your situation. Because every agile team has a process that is unique to their team if they’re doing it well.

Dan Neumann [24:26]

Now a agreed, and I feel one of the, like you mentioned, the cargo cult agile, that’s definitely okay. We, we have a, we stand up 15 minutes every day, by the way. We actually just do a kind of status report. We actually don’t collaborate whatever there, there’s that cargo cult and the other related dysfunction that I think is in that is the binary agile. It’s agile or it’s not agile. We end up with these contests, if you will. We’ll keep it pg friendly here, but you have the contest about well, that’s not agile. That’s not agile and it’s not a helpful conversation.

James Shore [25:01]

No, it’s not. But it is the kind of behavior you see from, well, to be honest, beginners, because beginners learn best by being, by beginners. Look for a cookbook, a a set of rules that we can follow. And, and it is a great way to learn to, to follow the book. But that can lead to people who, who, who are speaking to beginners. So maybe some of these trainers, I think the scrum guide tends to be a little bit dogmatic about this is Scrum and this is not, well, it’s targeting people who are trying to learn what it is. And that’s a good way to learn. And that’s what my recommendation is too, you know, follow the book exactly as written when you’re starting out. Because if you start tweaking it from the beginning, you’re gonna take out the stuff that’s really unique and different because it’s gonna feel uncomfortable.

James Shore [25:47]

So go ahead and do those things that are unique and uncomfortable, but then, and this is why the alternative to experiment sections are just littered throughout the book. Every single practice has it. Then after you’ve had that experience, now it’s time to experiment. Now it’s time to change. And I think after people have had more experience, they start letting go of that this is the, the one right way. But it can take a while. And I think there is some messaging in the community, maybe by people who tend to work mostly with beginners that sort of are downplaying the value of that customization. But I think customization is absolutely at the heart of what successful agile looks like.

Dan Neumann [26:26]

That That’s very cool. I don’t wanna throw you a curve ball, but at, with the risk of roughly how many practices would you say are in the second edition?

James Shore [26:35]

That is a great question and I should know the answer to that off the top of my head, but I don’t, we could, so let me just, let me just run through it real quick, quick. Yeah. so in the focusing section we got seven teamwork practices, six planning practices, seven ownership practices, five accountability practices, and three improvement practices. And in the delivering zone we’ve got four collaboration practices, six development practices, three design practices, four DevOps practices, and three quality practices. And then there’s two or three chapters in the optimizing section, but that’s organized a bit differently. So it’s hard to compare.

Dan Neumann [27:15]

That’s tremendous. And it makes me just kind of consciously reflect on how often and how much focuses on a handful of different things and I hesitate to enumerate them. But so much of like the agile talk is, I dunno, I’ll pick on user stories or scrum or, you know, there’s a couple more. And I think what your second edition will do for folks is really open their eyes to, oh, that one. Yeah, either I’ve heard about it and forgot about it, or I didn’t know anything about it and my, now I might like to try it.

James Shore [27:48]

Yeah, I would love for people to take the book and just sort of flip through it and, and stop and say, oh, that’s looks interesting. And at the print edition at least, we’ve got these little call outs, sort of like magazine pull quotes that sort of highlight interesting things. So you can just flip it open, randomly find one and look for those quotes. And if one of them looks interesting, you can sort of stop and read that practice. And it’s only a couple of pages, right. So I love

Dan Neumann [28:12]

It.

James Shore [28:13]

Yeah.

Dan Neumann [28:13]

And do you have a, a resource we wanted to make sure to mention four folks interested in the content, but maybe the, the print book hasn’t shown up yet or they’re, they’re trying to become a little more familiar with it before they, before they buy it and it on james shore.com and we’ll put a link to the, the full location. But you’ve got a version two book a lot of details in there. The chapter intros, you have conversations with thought leaders. I know you mentioned several of them. Diana Larson was in there. And I’m blanking, but I mean, yeah, can you, could you talk a little bit about the resources on the site for

James Shore [28:52]

Folks? Yeah, yeah. I, I would love for people to go to the site and, and join the conversation and see all the material I’ve put out. We we’re pretty close to the one year anniversary of the book coming out. So if you go to james shore.com/s/ao a D two, that’s Art of Agile Development two, that’s sort of the short link that we’ll take you to, to the page. If you go there, you’ll see sort of a description. You’ll see down at the bottom of the page, the table of contents. Every single section of the book has got an excerpt from it in it which is the opening section of a practice. But also I got O’Reilly O’Reilly’s, the publisher O’Reilly gave me permission to excerpt a huge amount of the book, 25% of the book. And so just yesterday for that for that one year anniversary, I went out, I went through and I put the most, what I felt were like some of the most important practices. I put the full text out there and they’re just available for you to read. And that’s things like adaptive planning and incremental design, which is part of evolutionary design and test driven development and stakeholder trust and task planning and capacity, which some people call velocity. Some of my favorite practices are, are out there and I encourage people to check ’em out,

Dan Neumann [30:08]

That, that is beautiful. And then there are some audio conversations about different practices there as well.

James Shore [30:15]

Yeah, yeah. So for nearly a year after the book came out, I did a weekly book club where it was a call in talk show. So I had, you know, people just, you know, sharing their thoughts, but I also had a lot of a lot of luminaries in the agile world.

Dan Neumann [30:33]

You mentioned Linda Rising, that was the name I was desperately trying to come up with. I’m a huge fan of hers too.

James Shore [30:39]

Kent Beck Jeff Patton, Martin Fowler yeah, Linda Rising at Woody Zo on there. Talking about mob program, gi click guard, who did the psychological safety Mike Hill and Joe Berg are talking about test driven development. It was just DevOps. I had Jessica Care talking about DevOps and Kelsey High Tower talking about continuous deployment. Such a, a great set. And those folks are all linked from that page. James shore.com/s/ao a D

Dan Neumann [31:09]

Two. That’s wonderful. And what a, what a great contribution to the community, both authoring the first edition and now a, a complete rewrite second edition. So I am going to add that to the print bookshelf and it’ll be on the Kindle. Cause when I travel, you can’t drag a bookshelf with you. And then the audio version, so I can listen to it when I’m driving because I, you know, actually I say, is there an audio version?

James Shore [31:32]

You know, I’ve been asked that, and O’Reilly, the publisher would have to come to me. But when I did the book club at the beginning of each book club, I would read like a little excerpt. And a lot of people say, well, are you gonna do an audio version? So I guess my voice is, you know, of acceptable enough quality . I would love to do an audio version, audiobook version. I should reach out to O’Reilly and see see what they think about.

Dan Neumann [31:57]

I think, I think it would be helpful. Like I said, sometimes a, I like it for when I’m mobile and, and b, sometimes it’s easier to hear and follow along and it, it helps my brain track on that content. So I don’t know, for what it’s worth, you get my phone.

James Shore [32:12]

I think it, I think it would would be possible. There’s a couple of chap capital practices have a lot of code in them and I don’t know how well that would work, , but so, so for everybody listening, if you want an audio version, tell O’Reilly that you want an audio version because that’s just what’s gonna make it

Dan Neumann [32:29]

Happen. Absolutely. You mean they’ll wait for a demand signal before they’ll produce? That’s crazy. That’ll never work.

James Shore [32:34]

Dan Neumann [32:37]

I would take way more of your time if we didn’t have a little bit of a time box here. I was hoping you could touch on one thing and then maybe give some closing thoughts. Mm-Hmm. <Affirmative>, one of the facets that I liked about the white paper on Agile fluency was you put in some timeframes how long it might take to achieve a level of fluency. And I thought that was important. I know early on in my agile career, I got frustrated with the speed of change. I still can tend to be that way. Could you maybe talk to the time to fluency or how long organizations might expect to have this nirvana of agility?

James Shore [33:19]

Yeah, absolutely. I think one of the things that a lot of organizations don’t do when they’re trying to invest in fluency, or rather they’re declaring, okay, we wanna be agile, but they’re not actually investing in fluency, is they’re, they are com dramatically underestimating how long it takes to really become fluent. And I’ve got my own experience in this, and of course other people are gonna have different experiences. So I can’t say that what I’m about to say is absolutely a hundred percent correct for everyone. But in general, I would say to reach focusing fluency, which is where you’ve got the team able to focus on business priorities, give visibility into teams work, and have the ability to change direction whenever the business needs. You’re gonna look at one to four months of decreased performances as people learn and two to six months to reach fluency.

James Shore [34:12]

So, you know, and that depends on how much support they have and how much the organization’s investing and how much they want to do it too. And a lot of, I talk about this a lot more in the book when I’m talking about how do you create change in an organization, excuse me. And then in the delivering zone, the main benefit of that is low defects and high productivity and technical longevity. You know, not having to rewrite your software after a number of years because it’s because it’s too crafty. And that’s about a two to six perform month performance dip. And three to 24 months until fluency, depending on how much existing code you have that needs to be sort of fixed up and optimizing fluency. The benefit there is you’re gonna see higher value releases and better product decisions. You’re looking about a one to three month performance dip and three to nine months until fluency. Although it often takes a year or two of delivering reliably with delivering fluency before you can even get permission to, to make that investment. And one of the interesting things here though, is that those timeframes overlap. So investing in focusing and delivering together is not one to four months plus two to six months of a performance dip. It’s just two to six months together. And that’s one of the reasons why, if you think you’re gonna want focusing and delivering fluency, do ’em both at the same time

Dan Neumann [35:33]

So you don’t have those repeated dips. I think of the the change curve set tiers, change curve gets used for that sometimes, right? There’s dips. So interesting. Take take the dip at once if you know you’re doing both those things.

James Shore [35:45]

Yeah. And not only that, and we do have a, the change model or the Seti change model picture in the book because, you know, it’s, it’s so true. But the other thing that happens with teams that I think a lot of organizations don’t realize is they think, oh, we need to be agile about adopting agile, but agile is a software development philosophy. Is it a way of thinking about how do you do software development? People are not computers. People get sick of change. And so if you’re just dripping out a little change, a little change, a little change, a little change, people are gonna get burned out partly because the first little change is not gonna be sufficient on its own. It’s gonna run into all this friction with other things that you’re not doing yet. And second, you’re just gonna get changed to fatigue. So it’s actually better to take a big bite, swallow it, and then be done with it than to say, okay, we’re doing a little bit, and now, oh, great, that’s done. Now your reward is you get to do more uncomfortable stuff. Congratulations. Yay,

Dan Neumann [36:43]

. I, I love it. James, I want to appreciate that you’ve been so generous with your time and to share with me and the listeners, what closing thoughts might you have about Agile, the second edition, the Art Agile development, fluency, dealer’s choice, anything you’d like to share?

James Shore [37:00]

Yeah, I would say, you know, my takeaway for, for people who are listening is that there is no one size fits all agile. There are different ways you can think about agile. There’s different ways you can exhibit your agility. We’ve divided them up into four zones of focusing, delivering, optimizing, and strengthening. And I think that’s a pretty good model to be really successful with Agile, to be really successful with agile. Start out by deciding which of those zones your organization needs, which benefits do you need, and then truly, truly make the investments to reach fluency in those zones. And my book, you know, blatant plug, it’s one way to help you get there, but it’s not the only way.

Dan Neumann [37:49]

There has to be one only way. I mean, well, I, I have no doubt the second edition will help a tremendous number of folks get there. It’s,it’s an important topic and the way this is constructed is super valuable. So thank you again for that.

James Shore [38:07]

Yeah, my pleasure. Thanks for having me.

Dan Neumann [38:10]

We ask folks at the end of our episodes what’s on their continuous learning journey, and I’m curious if you have something you’d like to share as part of James Shore’s continuous learning journey.

James Shore [38:20]

I, I do, you know, now that the book is done the nice thing about writing a book is it sort of takes all the stuff that you’re constantly thinking about, gets it out of your head, right? And so now I’m o I’m freed up to work on what my other passionate passion is, which is well business related passion. I have been working with teams and organizations that have lots of teams for, for many years now, and people call this the scaling, scaling problem. And I’ve been helping them with that for a long time. And I’ve tried a bunch of different things and the majority of the way I used to work on it was very similar to what what was published in the book Team Topologies, which I call a horizontal scaling approach. And it has some, it has some real flaws, it tends to be fairly rigid and for larger organizations you know, I did it with an organization, I did it in New Relic and they had 42 teams when I was done working with them.

James Shore [39:21]

There are some real limits to what you can get from that horizontal scaling team topology style approach. So I’ve been looking for a better approach. And what I’ve found is something called fast fluid scaling technology, which is a way of having a bunch of teams work together as a single virtual team. And it’s extremely innovative. I’ve done it, I’ve done it in a remote environment and it has been the most successful approach to scaling I’ve ever seen. And so I’m looking at doing it some more, and then after I’ve had some more experience with it, maybe that’ll be my next book.

Dan Neumann [39:51]

That sounds outstanding because scaling is def there, there’s a need for it, there’s a place for it. There’s also a place not for it. Like not everybody has to scale, which I think is a misconception, and there needs to be a little bit of diversity of, of thought on how we can scale agile teams. So I am excited to hear and wait for more on that contribution.

James Shore [40:14]

Yeah, absolutely. You can learn about Fast by going to fast agile.io and I have a number of presentations on it. I don’t have a short link, so I’ll just give that to you to put in the, in

Dan Neumann [40:24]

The show notes. We’ll put it in the show notes. The show notes are at agile.com/podcast and we’ll put a link to Fast agile.io in there as well. Thank you again, James. I really do appreciate you taking some time to share and all the contributions to the community for, you know, decade plus. So thank you very much. I’m well beyond a decade at this point, isn’t it?

James Shore [40:48]

It’s more like 22 years. I’m sad to say.

Dan Neumann [40:51]

That is, that is tremendous .

James Shore [40:54]

It’s been a pleasure. Thank you so much for having me on. I’ve had a great time.

Narrator [40:58]

This has been the Agile Coaches Corner podcast, brought to you by Agile thought. The views, opinions, and information expressed in this podcast are solely those of the host and the guests, and do not necessarily represent those of Agile thought. Get the show notes and other helpful tips from this episode and other episodes@agilethought.com slash podcast.

Agile Podcast: Agile Coaches' Corner