Investing in agility with James Shore
In just over a decade, we’ve witnessed how agile software development began as a grassroots movement to eventually progress and become a mainstream methodology. Agile’s approach aims to change the software development process by inviting organizations to invest in a philosophy that would ideally increase productivity & ROI, and meet business goals — all while creating better environments for IT teams and individuals.
Agile Fluency® Project Consultant & Co-Founder James Shore shares the concept of energized work, the evolution of team rooms, applying agile methodology by looking at complexity in large-scale enterprises, and advises on how organizations can invest in agility.
David Brown: I’ve been very well. Thanks, Kevin.
James Shore: I’m doing great. Thanks for having me.
KM: Let’s dive right in. You’re currently working on the second edition of your book, the Art of Agile Development. What changes in the industry or discoveries have you made in the past decade that spurred you on to start doing a second edition?
DB: Have you witnessed the agile process change or has it just been that cloud adoption and dev ops have introduced new implementations of the agile process?
DB: Why would that be?
JS: It’s hard and it’s a culture change and it’s so much easier 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 going to do it and they’re going to 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 the certification afterwards. And some of them are really good courses, but there’s only so much you can do in two days. You’re going to get stamped with the certification. Then you say, “Tada! 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. 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 it.
KM: 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?
JS: 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 histories of software development. 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 in the 20th century. A lot of that was based on this sort of assembly-line model of the industrial revolution and of the early 1900s. 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. But then, the manufacturing world actually passed the software world behind, left the software world behind, and came up with the idea of Lean Manufacturing, which was introduced by Toyota with the Toyota production system. You’ve probably heard of Just-in-Time manufacturing. When I was growing up, this is just betraying my age a little bit, but 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, you order something from a catalog, everything would say allow six to eight 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.
DB: The phrase agile is used in a much broader context these days, talking about becoming an agile organization. You don’t talk 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 being quick to respond to the demands of those people and the change that they’re undergoing as well, everyone’s undergoing a 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, software’s underlying, we talk a lot about that and facilitating it, but hasn’t the phrase also been used in a much broader context in terms of the way organizations are thinking of themselves?
JS: Yeah. I think it has. I’m not sure what to think about that. You talked about how these ideas are really more, something that’s easier for small businesses and medium businesses to accept. And that’s certainly, it’s 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!” That’s what I see with a lot of these bigger companies, it’s now the term is digital transformation, but it’s still the same old stuff. It’s: “Let’s take these agile ideas and actually use them to transform our business”. That’s really, really hard because it takes cultural change. And that is something those big companies are not optimized for except for a very, very few.
KM: Speaking of a change. Let’s dive into this a little bit 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 conceptualized it?
KM: All right, so let’s move on. Let’s talk about applying agile. Let’s talk about applying the agile framework in a large scale enterprise. So, in one of your previous articles, you described how complexity in software development is inevitable as we cannot eliminate it, but we can move it around. So, from the monolith and microservice approach to using nano services and a hybrid approach by a mono repository, how do you think large scale enterprises should look at and deal with complexity?
JS: That’s another great question because I think complexity, this is Coding Over Cocktails, right? So, we’ve got an audience 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 an assembly. We could write in C++, we could write in Java, we can write in Python. It doesn’t matter to the computer, 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, do you choose to use a functional language versus a procedural language — it’s because you think the functional languages, makes it easier to manage complexity.
So, this is even more true in a large-scale environment, because the problem is I ran into this when I was a kid when I was 15 or something. One of my first big programs, D&D character creator, because I’m a geek. And every geek’s got to write a D&D program. So, the D&D character creator wrote in Applesoft, basic, which was a lovely programming language that had two-character variable names. Well, technically you could write as many characters as you wanted the variable name, but only the first two characters counted. It used line numbers. So, it was gotos and gosubs, right? And so I’m programming along, slinging line numbers gosub 10,000 cl string, dollar assignment string, a cl dollar sign, AN, AN percent, all this stuff. And I guess I had gotten called for dinner or something like that because literally between one moment to the next, I went from all in my head ‘till 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 as 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 link it all together, combined with distributed programming, which is God-awful, to begin with. The one saving grace is it is a lot harder to use stuff like globals 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 going to 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 going to start seeing some 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.
DB: So, what is the process to manage the complexity? What do you recommend to manage that process?
JS: I don’t have a simple recommendation. It is fundamentally about design and 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 makes a change, and it affects all of these other teams — now you’ve got a problem, especially if they don’t know it.
DB: It always comes back to people, right? Whenever we talk about this stuff, it’s always coming back to the people.
JS: That’s right.
DB: Team organization, how you structure the stakeholders, whether you get them into the same room together, whether you make them as one team, whether you make the transparency communication between teams, that all comes back down to people.
DB: Kevin, our next guest, Ruth Malan.
KM: Yeah. We’re going to check her out. All right. Okay. 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 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?
KM: Yeah. We’ll give them the chance to read your book or even the excerpt that you’re publishing on your Twitter feed.
DB: Sure. Thanks so much for your time today. Our listeners can obviously follow you at jamesshore.com. And your Twitter handle is?
JS: It’s at jameshore, pretty easy.
DB: Awesome. Thanks so much. And good luck with the rest of your book. We’ll certainly be following the excerpts as you publish them.
JS: Yeah, my pleasure. Thanks for having me on and cheers.
Originally published at https://www.torocloud.com.