Kevin Montalbo

In just over a decade, we witnessed how agile software development began as a grassroots movement and eventually progressed to become a mainstream methodology. Agile approach aims to change the software development process by inviting organizations to invest in a philosophy that would ideally increase productivity and ROI and meet business goals all while creating better environments for IT Teams and individuals. 

Greetings listeners. My name is Kevin Montalbo, content editor at Toro Cloud. In this episode of cocktails, we talked to one of the foremost thought leaders in the agile software development space as he shares with us the concept of energized work, the evolution of team rooms, applying agile methodology by looking at complexity in large scale enterprises and his advice on how organizations can invest in agility. Joining us today for a round of cocktails as always is Toro Cloud CEO and founder David Brown. How’ve you been, David?

David Brown

I've been very well. Thanks Kevin. 

Kevin Montalbo

I love the cocktails in the background. All right. And our guest for today is one of the 1st 10 people to sign the Agile Manifesto when it was released to the public in 2001 in 2005. He was an inaugural recipient of the Agile Alliances Gordon Pask Award for contributions to Agile Practice. The first edition of his book, The Art Of Agile Development was released in 2007 and became a much loved classic. He went on to create other influential works such as the agile fluency model with Diana Larson and is a popular speaker at events around the world, James Shore. Welcome to the podcast. How are things?

James Shore

I'm doing great. Thanks for having me.

Kevin Montalbo

All right. Let's dive right in. You're currently working on the second edition of your book, The Art of agile development. So, what changes in the industry or discoveries have you made in the past decade that spurred you on to start doing a second edition?

James Shore

Well, the first edition came out in 2007. So that's what 13 years now, boy, that seems like a lot. And well, you know, a lot has changed since then. The, the book was originally written to be sort of evergreen and I think it succeeded in that way. But nonetheless, I've, I've learned a lot since then. And the biggest thing that's happened since 2007 is you know, cloud based software has really just exploded and the DEV ops movement came along. Um And also as a consequence of doing that first edition of the book, I actually got together with Diana Larson and we taught a number of courses based on that book. And one of the outgrowth of that collaboration was the actual fluency model. So, it just seemed like after 13 years, I also, my, my publisher came to me and said, we're getting requests for, for it to be updated. It seemed like it was time. So the, the new edition's got a lot more about cloud and DEV ops in it. It brings in the agile fluency model talks a lot more about adoption and how that works and it's not gonna come out for another six months or more fingers crossed. We'll see how that comes. So I've got a lot of writing still to do, but so far I'm really happy with it. I'm going through and I'm just touching everything. I'm revising absolutely everything.

David Brown

Have you witnessed the agile process change or has it just been that cloud adoption? And Dev OPS has introduced new implementations of the agile process

James Shore

Agile. So first agile is not really a process, it's more of a philosophy or a way of thinking about software development. Um Martin Fowler has has his description of agile, which he calls the essence of agile development, which I think is really dead on. He says it's adaptive rather than predictive and people oriented rather than process oriented. And I don't think that's really changed. I Martin actually came up with that characterization before the term agile was even coined and I think it's still true today. And I think even today, 20 nearly 20 years after the Agile Manifesto was written, there are a lot of companies who just don't get it like they don't get that core idea of adaptability rather than predictability and people orientation over process orientation. So I would say the core ideas of agile. No, they haven't really changed, but Agile is a big tent. Like what we do in agile today is not what we did in Agile in 2000. Um We're constantly bringing in new ideas. So lean start up by Eric Rees has come in. There's been a lot more work in the area of how do you do large scale development with agile? So these ideas are always coming in dev ops movement of course, is taking XPS ideas of continuous integration, which is another thing that's sort of been misinterpreted over the years and bringing it to cloud development and doing continuous deployment and delivery. So I would say Agile is evolving as because it's always taking in new ideas, but the core ideas haven't changed. And I would say the vast majority of companies that say they're doing agile have yet to adopt those core ideas. And why would that be? It's hard and it's a culture change and it's, it's so much easier. It's so much easier as some as somebody in a large company who's been tasked to bring in agile, it's so much easier to hire somebody who says they're gonna do it and they're gonna make it easy. So, there are so many courses that you can buy and pay for that are two day courses where you'll get stamped with a certification afterwards. And some of them are really good courses, but there's only so much you can do in two days., you're gonna get stamped with the certification. Then you say today we're agile, but actually becoming agile as an organization requires changing habits, culture, and ways of thinking about your work that doesn't happen in two days. And it takes a, it takes an in depth thoughtful approach. That's at odds with people who have been tasked to do something they don't necessarily understand and want to just pay money for.

Kevin Montalbo

Speaking of cultural, you recently published an excerpt of your book, which is on energized work. Now, it's quite refreshing to see a book about software development agile that dives deep into energizing and motivating the workforce. Can you tell us more about your thought process behind the section of this book?

James Shore

Yeah, that's a great question. I think that actually really ties back to what David was saying a moment ago because this idea of energized work, it goes way way back to the very beginnings of agile and it's not my invention at all. I remember I said that Martin Fowler described the essence of agile as being people oriented rather than process oriented. That's really shows in this idea of energized work. The idea that so prior to agile, the, the big approach of the day was these process, these big heavyweight processes that the, the sort of the underlying theory was that if we have a well defined process, it doesn't really matter who we put through that process. The process is a real asset and we can exchange people as needed who are notoriously unreliable and tend to do things like want money and quit and stuff like that. So we're gonna rely on our process to be our real asset and we will just pump people through this process and we'll get really nice, consistent results. They did get consistent results, but I wouldn't call them nice because it turns out that people are really important for software development, right? We all know that um there was 0567 years ago. I don't know, there is, I don't know if I should say this on, on the podcast. Maybe you can bleep it out. But there was this movement called programming Motherfucker, right. So, it's basically that core idea, the, how we do programming matters and the skill that we have as people matters. And agile made that really central. And one of those ideas from the first edition of Extreme Programming, which was the first really big popular agile method was the idea of 40 hour week, which says basically you do your best work when you're not worn out. And then Kent Beck, who wrote that, who created extreme programming,, did some work in Switzerland and came to understand that not everybody thinks of work in terms of 40 hour weeks. So in the second edition of Extreme Programming, he called it Energized work. And for the first edition of our book, we just took that name. Exactly because, we're all about building on what came before. And it's funny you should mention this specific practice because of all the things that all the stuff we've written for the second edition that practice, that one had nearly zero changes. Everything else has had lots of updates, but that one had nearly zero changes.

David Brown

You talk about that process oriented, of course, yeah, organizations from the industrial revolution, that's what they became really, really good at, right? Is they became sausage machines and they were good at producing that sausage, whatever that product was that organization. But varying away from that sausage was something small business could do, not necessarily enterprise. And so when we talk about the agile manifesto and being an agile organization implies change, being able to adapt to the market and change and be quick at changing and being quick to respond to the change. And so it's a total mindset change a away from being process orientated, which I think is an industrial revolution. Um you know, concept which worked super well. For the last 150 years. Um And so now we're asking organizations to be fundamentally different. They were really good at making sausages and now you want them to make pies and, you know, sausage rolls and everything else as well, right. The market fancies at the time is that, is that, is that a reasonable analogy?

James Shore

It's, it is a reasonable analogy. I think a lot of early software development was based on this idea. I don't know how true it was. But I'm actually just been working on a section of the book today talking about some of the history of of software development. And you know, there's this idea of waterfall that people say is sort of a straw man, but is how people actually thought how software should be developed, you know, in the 20th century. And um a lot of that was based on the sort of assembly line model of, of of the industrial revolution and of the early 19 hundreds. there's Frederick Taylor who had his scientific management, which was all about seeing workers as kind of lazy, undisciplined people who had to be controlled in order to get good results out of. But then the the manufacturing world actually left the software world behind and has came up with the idea of lean manufacturing, which was introduced by a Toyota with the Toyota production system. And you've probably heard of just in time manufacturing when I was growing up, this is just betraying my age a little bit. But,, if you were to order something on, well, there was no online. If you were to order something from a catalog, this was like the internet, except it came on a paper and in the mail,, if you order something from a catalog, everything would say allow 6 to 8 weeks for delivery. And now of course, you order something online and you get it within a couple of days or you're pissed off. That's because of these short supply chains and the innovation that's been happening as a result of lean manufacturing agile is actually taking a lot of the same underlying theory and adapting it to design rather than manufacturing to software development rather than manufacturing.

David Brown

But the, the con the, the phrase agile is used in a much broader context these days, isn't it? When you can talk about becoming an agile organization? You're not talking about just software development and an approach to software development. You're talking about a mindset for the organization itself and the ability to be listening to the customer and the market and your employees and business partners and, and being quick to respond to the demands of, you know, of, of those people and the change that they're undergoing as well is, you know, everyone's undergoing this digital transformation yourself included. But you have to take into account the transformation that your customers, employees and business partners are also going through. Right. So, it's, it's software is, you know, fun underlying. We talk a lot about that and facilitating it, but hasn't the phrase also being used in a much broader context in terms of,, the way organizations are thinking of themselves.

James Shore

Yeah, I think it has. And that's, and I'm not sure what to think about that. Um, you talked about how these ideas are really more something that's easier for small businesses and medium businesses to, to accept and that's certainly something that we saw in the early days of agile. It started out and it was all the early adopters and innovators,, generally the smaller companies that really embraced agile, but they had so much success. It attracted a lot of attention. You asked me earlier., why aren't more people doing agile as for real, as opposed to just using the name? Because it's easy to call yourself agile, right. There's no trademark. You can just smack it on the door. You're done. We're agile. Congratulations. Um, that's what I see with a lot of these bigger companies is they are now, it's now the term is digital transformation, but it's still the same old stuff. It's, let's take, let's take these agile ideas and actually use them to transform our business and that's really, really hard because it takes cultural change and that is something that big companies are not optimized for., except for a very, very few,

Kevin Montalbo

Speaking of change, let's dive into this a little bit more deeper. There's another excerpt that you published recently and it's about this concept of the team room. Now, I understand that the team room can either be physical or virtual. But with a global pandemic, forcing people to work remotely from home. Has the approach towards collaboration within this team room. Has it changed from when you initially conceptualize it?

James Shore

Yeah, no kidding. The pandemic of course, has been um a real, a real change to the system for everybody. And it's actually impressive how, how much I think we're all able to weather it. I think in software development, we've got that capability much more easily than, you know, more physical occupy occupations. The first edition of the book, um It was really clear, it said this is something that we know how to do when you're in person and we don't know how to do when you're remote, but that was 13 years ago. And actually, before that first edition was published, I actually created a start up with a friend of mine called Card Meeting with the intention of let's make team room work when you're remote and that, that start up failed as, as they tend to do. But, but now the same ideas you can see and I'm not going to claim to be the, you know, the instigator of these ideas because it's pretty obvious. But the same ideas of having a collaborative workspace where you can move cards and stickies around as if you were in person is now found in tools like mural and in mirror. And they, unlike us have actually succeeded. We had a product that basically did that but it, it was never more than an alpha or beta. They've actually made it work as a real proper production project product. So we have the tools now, I think to make it possible to interact in the same kinds of ways that we had when we were physically together. This rich communication where you can have multiple, multiple people collaborating on the same discussion board, the same white board at the same time, which is really, I think essential for an agile style of collaboration. So that's something that if the pandemic hadn't come along. I don't know if I would have leaned into that as hard in the book in the second edition of the book as I am. Now, it's front and center. The first edition said, you really don't know how to do remote. We don't know how to do remote well in an agile environment. The second edition, I was gonna say, well, we do know how to do it. And here's some tools and I was going to put that off in the side of one chapter somewhere. But now every single thing I write when I say here's how you do collaboration with agile. I, they're, they're both side by side. Here's how you do it in person and here's how you do it remote. And it's actually not that different because we do have the tools now to make that remote collaboration possible. That's

Kevin Montalbo

All about applying the agile framework in a large scale enterprise. So in one of your previous articles, you describe how complexity in software development is inevitable as you cannot eliminate it, but we can move it around. So from the monolith and microservice approach to using nano services and a hybrid approach via a mono repository, how do you think large scale enterprises should look at and deal with complexity?

James Shore

Yeah. That's, that's another great question because I think complexity, you know, this is Coding over cocktails, right? So we've got an audience of, of programmers and I think the essence of programming is managing complexity. That is really what programming is all about and that's what software design is all about because the computer of course doesn't care. We could write in assembly, we could write in C, we could write in Java, we can write in Python. Doesn't matter to the computer under the under the covers. It's all just byte code binary, right? The programming is for us humans and what we're doing when we program is we're managing complexity. Every time you write a function you're managing complexity every time you write a class or a module, you're managing complexity. If you choose to use a functional language versus a procedural language, it's because you think the functional languages, it makes it easier to manage complexity. So this is even more true in a large scale environment because the problem is I, I ran into this when I was, when I was a kid when I was 15 or something. One of my first big programs, D and D character creator because I'm a, I'm a geek and every geeks gotta write ad and D program. So D and D character creator written in Apples Soft Basic, which was a lovely programming language that had two character, variable names. Well, technically, you could write as many characters, you want the variable name, but only the first two characters counted. So, and it used line numbers. So it's go tos and go subs, right? And so I'm programming along sling in line numbers, go sub 10,000 cl string, dollar sign meant string, cl dollar sign, a nan percent, all this stuff. And I must have gotten called for dinner or something like that because literally between one moment of the next I, it went from all in my head to I had no idea how this thing worked and that was because it had outgrown the level of complexity. My brain can handle all software outgrows the level of complexity your brain can handle if it gets big enough and large scale software development by definition is too complex for one brain to handle. So how are you going to manage that? And that is where these ideas like microservices come in. But I think they're fundamentally flawed microservices aren't fundamentally flawed, they're fine. But as a tool for managing complexity that people are using it like a silver bullet, right? Because if you can't build a monolith with good management of complexity, there is no way you can build a microservice mesh with a good degree of complexity. All you're doing is you're kicking the can down the road. But if you thought dealing with a monolith that was poorly designed was bad, just wait until you get a microservice mesh that's poorly designed. Now, you've got all the problems with the monolith of not knowing how things are supposed to fit together and being able to, you know, link it all together combined with distributed programming, which is God awful to begin with. Um The, the one saving grace is it is a lot harder to use stuff like global's in a microservice environment. And that is the source of a lot of mistaken coupling. But I think that over the next couple of years, we're gonna start to see microservices have been around long enough that they've hit that magic level where they're no longer new code, they're now legacy code and that's what sucks. It's not the language it's not the design. It's the fact that it's old and you didn't write it. We're getting to the point now that we're gonna start seeing some major, major reports of major problems with microservices just because the people who couldn't design monoliths also didn't change their design skills when they went to microservices. 

David Brown

So what is the process to manage the complexity? What would you, what, what do you recommend to manage that process?

James Shore

I don't have a simple recommendation. It is fundamentally about design. And um in a large scale system, when you're thinking about which teams you have, what you're really thinking about is what is the design of our software? Because of course, there's Conway's law that says the design of the software reflects the design of the organization and vice versa. So when you're thinking about how you want to set up your teams, you need to also think about how you want to set up your software. And that means minimizing coupling between teams having clear interfaces between teams being really crisp about how teams depend on each other. So that when this team makes a change that affects this team, this team can be aware of it. And if you've got a poorly designed microservice mesh where you don't know that stuff and this team make a change and it affects all of these other teams, now you've got a problem, especially if they don't know, it

David Brown

It always comes back to people, right? Whenever we talk about this stuff, it's always coming back to the people. That's right. Team organization, how you structure these stakeholders, whether you get them into the same room together, whether you make them as one team or whether you make the transparency, communication between teams, it all comes back down to people.

James Shore

Yeah, absolutely. And one thing I would add to that is that people think, you know, organizational leaders think about the decision of what teams to create as a management decision. But because of Conway's law and because of this management complexity, if you have interdependent teams, if you have teams that depend on each other to ship a product, you don't have a management problem, you have a software design problem and you've got to put people who are experienced in software design at the head of deciding how those teams are broken up. For example, it's really, really easy and common to say, well, we're going to have our user experience, our user interface, front end people here and our back end people here. But what have you just done everything that the software does now involves these two teams communicating. It would be so much better if we said, well, no, we're gonna take this one thing that we have and we're gonna split it into admin with front end and back end and log in with front end and back end and then and profile with front end and back end. If you do that, now, they're still depend on each other, but you don't have every single thing they do depending on every other team. So that's the same thing. You know, when you think about your front and back end coupling, don't create teams that are coupled in the same way that those are, put your, make your teams cross functional. And that's just, you know, that's just the beginning. There's a great book, team, apologies that I have not read all the way through but discusses this sort of stuff in detail that I have a really good feeling about and I it has come very highly recommended, Kevin,

David Brown

Our next guest, Ruth Milan,

Kevin Montalbo

We're going to take her out. All right. OK. So let's circle back to your book because we're talking of large scale enterprises here where you advocate the idea that organizations need to buy into the underlying agile philosophy by investing in agility. So as we're down to the last month of 2020 so we're recording this at December, our listeners might want to have an idea of what they can prioritize as they start the New Year. So what's the best advice apart from buying your book? Of course, that you can give them when it comes to investing in agility.

James Shore

Well, they should check out my book at least because until it is published I'm doing an open review. So you can actually see everything I'm working on for free and give your feedback on the mailing list because I'm an actual guy. I take feedback and I act on that and I iterate. Um So it's all available online right now if you go to Jamesshore.com/s/aoad2 for Art of actual development, second edition. so you can see this stuff right now and there is a chapter called Choose invest in agility that has, has these ideas in it. But if I were to and I think all those investments in that chapter are important, but if I had to narrow it down to just a few, I would start with buying a, a decision to become agile is a decision is, is not a decision to take lightly. It's a decision that requires people to change their behaviors and their habits and that's the team members, but it's also managers and its stakeholders and you need those people to go into it knowing what they're getting into. So start with the buy in and then from there. Remember Martin Fowler's essence, it's people oriented rather than process oriented and it's adaptive rather than predictive. So it's gonna take the people time to learn. So make sure to account for the fact that your productivity is gonna dip where you're gonna learn and it's gonna be, it's gonna cause some chaos and you should manage that chaos. Well, especially in a large organization, um put your people together on dedicated cross functional teams that don't have a lot of dependencies on other teams as we were talking about a moment ago. Um And when you're thinking about how you do governance in your organization, do you assume a predictive environment? Do you assume that you're gonna say that this is a project that's gonna take a year and it's gonna shift this thing at the end. It's gonna take this long. It cost this much. If you do, you don't want agile, you want a waterfall style process. The decision to use Agile is a decision to say, we think adapting is more important than predicting. If it's not, don't use agile, it's not gonna do you any good. It's not meant for that and there's more, but I'll, I'll stop there.

Kevin Montalbo

Yeah, we'll give them the chance to read on your book or even the excerpt that you're publishing on your Twitter feed.

David Brown

James Shore. Thanks so much for your time today. Our listeners can obviously follow you, as you say at james.com and your Twitter handle is

James Shore

It's at James Shore pretty easy.

David Brown

Awesome. Thanks so much and good luck with the rest of your book. We'll certainly be following that excerpts as you publish them.

James Shore

My pleasure. Thanks for having me on and Cheers. Cheers.

Kevin Montalbo

Thank you very much James Shore for being with us to our listeners. What did you think of this episode? Are you taking on any agile development methodologies for your organization? Let us know in the comments section from the podcast platform you're listening to. Also, please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter, and Instagram. You can talk to us there because we listen. Just look for Toro Cloud again. Thank you very much for listening to us today. This has been James Shore, David Brown and Kevin Montalbo at your service for Coding over cocktails.