#46 - Business Agility - Evan Leybourn

Episode Introduction [00:01:06]

Henry Suryawirawan: [00:01:06] Hello again to all my listeners out there. It’s great to be back here again with another new episode of the Tech Lead Journal podcast. Thanks for spending your time with me today listening to this episode. If you haven’t, please subscribe to Tech Lead Journal on your favorite podcast apps and also follow our social media channels on LinkedIn, Twitter, and Instagram. And you can also make some contribution to the show and support the creation of this podcast by subscribing as a patron at techleadjournal.dev/patron, and help me towards producing great content every week.

For today’s episode, I am happy to share my conversation with Evan Leybourn. Evan is the founder and CEO of Business Agility Institute, an international membership body to both champion and support next generation of organizations that are agile, innovative and dynamic. In this episode, Evan shared about the current maturity of agile adoption and how agile has matured over the years by looking at 3 different agility categories: technical agility, process or operational agility, and business agility. Evan then explained further what business agility means, and his interesting story of why he eventually started the Business Agility Institute. He then explained in-depth the concept of business agility domains, which is a model comprising 12 different interacting domains across four different dimensions centered around the customer. We then discussed about his theory of agile constraints, borrowing from the original theory of constraints introduced by Dr. Eliyahu Goldratt. And in his theory of agile constraints, Evan shared his insights on why he thinks Agile and DevOps transformations are currently hitting diminishing returns, and how we should address this situation by continuously finding the constraint to solve within an organization in order to become truly agile. During our conversation, Evan also touched on and shared about the recent Business Agility Institute research finding on why many agile organizations unconsciously fail to embed and support Diversity, Equality and Inclusion, or DEI within the organizations, an interesting finding that look at the intersection between agile and DEI.

I really enjoyed this conversation with Evan. And I hope you will enjoy this episode as well. Consider helping the show by leaving it a rating, review, or comment on your podcast app and social media channels. Those reviews and comments are one of the best ways to help me get this podcast to reach more listeners. And hopefully they can also benefit from all the contents in this podcast. So let’s get this episode started right after our sponsor message.

Introduction [00:04:20]

Henry Suryawirawan: [00:04:20] Hey, everyone. Welcome back to another new episode of the Tech Lead Journal. Today I have with me Evan Leybourn. Evan is the founder and CEO of the Business Agility Institute, which is an international membership body to both champion and support the next generation of organizations, which are the companies that are agile, innovative, and dynamic. So today we are going to talk a lot about business agility and things related to that. So Evan, thanks for being on the show. Hoping to have a good conversation with you about business agility.

Evan Leybourn: [00:04:52] Thank you, Henry. I’m really looking forward to it. It’s going to be a good conversation.

Career Journey [00:04:56]

Henry Suryawirawan: [00:04:56] In the beginning, Evan, maybe could you introduce yourself for the audience who may not be familiar with you? Maybe highlighting a turning point, or major highlights in your career?

Evan Leybourn: [00:05:05] Of course. I’m currently living in Melbourne, Australia, but that’s a fairly new thing for me. I have spent the last 15, 17, 20 years working and traveling all over the world. Now as this is the Tech Lead Journal, it would be worthwhile to share where I started from a tech perspective. I was a programmer. Web applications primarily, back in the late 90s and early 2000s. PHP being my development system of choice. I know it’s not the most flashy programming languages, but it did the job. This is like packing like the PHP 4 days, and so let’s be honest, it did the job pretty badly. I think it’s a lot better now. But in around 2003, I got exposed to this thing called Agile. And I say that with a capital A. Scrum and XP primarily at the time, and started to use these techniques in the development of the software products that we were building. At this point, I transitioned into sort of Information Management systems, data warehouses and web-based data warehouses, which were well, they’re a dime a dozen these days, but they were very new back then. So really exciting. I don’t know if any of your listeners are really into data warehousing or Business Intelligence space, but I can tell you that back then, data warehouses and business intelligence systems failed a lot. Companies would spend millions and millions of dollars building the systems only to get zero return on them. And so, Agile was seen as a way of closing that feedback loop, making it tighter, getting more insights from the data quicker without necessarily building everything all at once, and we did a pretty damn good job.

If we fast forward a little bit to about 2008. At this point, I’ve joined the Australian public service. There’s a concept called the Peter principle, which is being promoted to your level of incompetence. That may be a little bit of a joke, but this is where I was. I became the director of Business Intelligence for a government agency. I was a good team lead. I was a good programmer. I was a good database administrator. But I wasn’t a good director. There were skills there that I’d never learnt, that you don’t learn in university. You don’t learn when you’re building software products. And so I had an epiphany, well actually to be fair, my boss pointed out that I wasn’t doing a good job. I can’t say I had the epiphany, my boss pulled me into a room and it’s like, “You’ve got to get better. Otherwise, this isn’t going to work out.” So I started thinking about the challenges I was facing as a director around getting teams, divisions and functions across multiple government agencies cause we were doing a whole of government program. Getting them to cooperate and collaborate with each other. Getting that coordination of work and budgets and all those kinds of things.

But if you think about it, cooperation, collaboration, coordination, these are things that Agile with a capital A did really well, obviously in building software products. But I had this sort of like “A-ha” moment where it was like, if these principles, the agile manifesto, the principles, the values, and the practices work well to solve these patterns of problems, maybe they’ll solve these patterns of problems in another context, in which case in a business setting. Long story short, they did. That’s sort of what got me into this space that we now call business agility. Back then, to be honest, it was more like agile business. But in the intervening 12-13 years, I’ve been both honing my own skills and experiences around business agility, and helping organizations on that same path. So the most recent thing, three years ago, I left the consulting world, and co-founded the Business Agility Institute. Which Henry, as you very nicely mentioned, we’re a professional association. We have members in 60+ countries. We don’t do training, we don’t do consulting, but we do research. We actually have 14 research teams exploring different facets of business and I suppose what that looks like. That was perhaps a long answer to your question. But that’s Evan in a nutshell.

Current Maturity of Agile Adoption [00:09:24]

Henry Suryawirawan: [00:09:25] So thanks again for sharing your story. I think one thing that I noted is when you mentioned about Agile with capital A. So maybe you can share a little bit, what do you mean by Agile with capital A? And is it common to say agile with lowercase A now?

Evan Leybourn: [00:09:40] When we say Agile with a capital A, we use that to refer to the Agile Manifesto and the agile practices and frameworks. It is the thing called Agile, the noun. Whereas agile with a little A, it’s the verb. It’s the thing that you are. You have agility. You are agile. You do Agile with that capital A. Now, yes, there’s a whole Agile Manifesto, which is values and principles. It’s not as clean cut as that. But if we say Agile with a capital A, we’re really just referring to that broader context, the practices and so forth.

Henry Suryawirawan: [00:10:17] So you mentioned about all this experience that you have and you also now have Business Agility. Maybe in a nutshell, what do you think is the current maturity of Agile adoption? I mean, it’s been around for, I dunno, more than a decade, I would say probably? And what do you think is the current adoption? Are companies familiar with it? They are able to introduce that and be more Agile, so to speak.

Evan Leybourn: [00:10:41] Let me separate this into 3 categories of Agile. This is just Evan, how I see it, this isn’t some official how Agile is defined. But just for the sake of answering the question, let’s look at it in terms of technical agility, process or operational agility, and business agility. So technical agility is things like XP back in the day. It’s not the project management wrappers, but it’s rather how you write code. It’s DevOps. I remember back when I was a techie, we didn’t have Continuous Deployment back then, but we definitely had Continuous Integration. So this was a fundamental part of the Agile work that we were doing. We had to have this technical agility. This ability to create products that were modular. So it touched architecture, it touched design, it touched the delivery, the actual writing of code. Now I would say that over the years, we have gotten very good at this. In part, because it’s something that can be repeated, DevOps as a concept. I know some of your listeners may object to me linking DevOps and Agile, because I know some people think that they’re completely different things. Hence why I’m using agility, not Agile per se. But DevOps and the professionalism around that operational aspect of the business, actually I think took this technical agility into a high level of maturity across most organizations. We all know organizations that are struggling.

If we look at the process agility, the operational agility, this is the frameworks around project management, around product development, around portfolio management. I think this is Scrum. This is SAFe. This is disciplined agile, though some of those do go down in that technical agility space as well. Organizations are doing okay. We’ve been doing it for a long time. But there are elements of it that are particularly culturally hard for many established organizations. It’s why young organizations generally with a younger management base without that inertia, without that 1960s management model or that 1980s management model, they do quite well with this. But the larger more established organizations, there’s almost a generational change that is occurring.

So if I pick, say two examples. An example like Microsoft. Now I’m an open source person. I still have Ubuntu on my laptop. I haven’t logged into it for a while, but I still have Ubuntu on my laptop. I ran the open-source developers conference in Australia back in 2008. So I’ve always been embedded in that open source space. So I can remember back in 2008, 2007, 2006, Microsoft was the enemy. Microsoft was the big monolithic, in many cases, evil organization. But I look at Microsoft today with nothing but a sense of, I’ll say almost pride and respect. They have managed to turn their organization around. Now, it’s not perfect everywhere. But they’re doing some pretty amazing things, and a large part, it comes from that agility, that generational change. The old guard moved out, a new generation moved in into those leadership roles, into those program and project roles, and they brought with them an almost native agility. Microsoft has gone incredibly well because of it. If I look at another organization like IBM, it’s older, more established, but it hasn’t had… and it’s trying. In all respect to IBM, they are truly trying to be an agile organization. But they haven’t really had that fundamental shift of culture and generational leadership across all the different elements. In all openness, I actually used to work for IBM. So there are pockets of great agility. Some of the greatest thinkers are in IBM, but the organization as a whole doesn’t have that. They have pockets of agility, whereas Microsoft has pockets of unagility. So, it’s possible, but that’s that difficult.

And then the third space is business agility. This is where we’re looking at everything from finance and HR and sales and marketing and all those kinds of things. The industry in general is fairly low. From our research, and your listeners will be very happy about this, the number one industry in terms of business agility adoption is the technology industries. Financial services firms are in the top. They were in the top three, they’ve dropped. I think they’re now number four. Interestingly, manufacturing, factories, production firms are actually now in the top three. So, it’s been quite interesting to see how they have gone from this lean perspective to this lean Agile perspective. And so, they’re growing, but it’s still a very young industry. It’s still got a while to go before, before companies make that shift effectively.

Henry Suryawirawan: [00:15:49] So thanks for sharing this statistic. I mean, it’s very interesting for me personally. I’ve worked in the financial services long way back. I thought that they would be more mature in terms of agile adoption, but you mentioned that technology space and manufacturing are in the top three. So what is the other one?

Evan Leybourn: [00:16:05] Oh, consulting firms. That’s an interesting space because consulting firms they often experiment on themselves. I’ll be blunt. I don’t mean the big ones. The really big four consulting firms aren’t agile in the slightest, and you all know who they are, so I won’t say them out loud. They have very limited agility. They’ll do it to others, but they struggle to do it to themselves. But there are tens of thousands of small to midsize consulting firms. I’m talking 10 people up to about 150- 250 people. These firms are exemplars in business agility in many cases because they do it to themselves. They become consultants to try and help other organizations because they believe in it. Because they believe in it, they’re doing it themselves. The big four consulting firms, obviously… that plays with that Microsoft, IBM game of generational change is going to be required.

Business Agility [00:16:57]

Henry Suryawirawan: [00:16:58] So I think it’s also a good time now to move into the topic of business agility, which is the main theme for today. So maybe if you can explain again, what is business agility, in short? And why did you come up with the institution? It’s pretty interesting to me.

Evan Leybourn: [00:17:13] What is business agility? Let me give you the definition, as we define that. Business agility is a set of organizational capabilities, behaviors, and ways of working that afford your business the freedom, flexibility, and resilience to achieve its purpose, no matter what the future brings. So let me touch into a couple of things, capabilities, behaviors, and ways of working. In reverse order, the ways of working is what you do. The behaviors is what you’re expressing. And the capability is what you’ve achieved. If you’ve got those three, then you’ve got a good foundation for business agility. Many organizations will adopt the ways of working, but they don’t change the behaviors, and they don’t create new capabilities in the organization. And so, I would say that they’re doing Agile, not being agile, and that’s unfortunately quite limiting. So you need all three to be effective.

The second point I want to highlight is to achieve its purpose or to achieve your purpose. Organizations exist for a reason, and that reason is sometimes very obvious. We exist to serve our customer. We build a product, we serve our customer in a particular way. In some cases it might be a little bit more hidden, a government organization, or a not-for-profit. But there’s a great quote by Frederick Laloux, “profit is like the air”. We do not live to breathe, but we do need to breathe in order to live. So what does that mean? As an organization, your purpose isn’t to make money. Your purpose is to serve your customers. Making money is how you know you’ve served your customers. And so we see a lot of organizations get that round the wrong way. The customer is secondary to making money, and those companies tend not to last more than 5 to 10 years. Those companies who get that customer centricity are the ones who, especially right now in a very dynamic, very unpredictable market, are the ones who are doing quite well.

There’s another concept called job to be done. The concept of job to be done is when you go and buy a drill, you’re not buying a drill because you want a drill. You’re buying a drill because you want to hole, and you want a hole because you want to put up a set of shelves. So that drill company isn’t in the market of selling drills, they’re in the market of selling holes, and helping you build things. So, if there is some issue with the sale of drills, for example, there are supplier problems or regulatory issues, or the EU says you can’t sell to them anymore, you can’t import drills for whatever reason. I know that’s a silly example, but just bear with me. Those organizations who see themselves as we sell drills have a problem. Those organizations who they see themselves as we serve our customers to create holes, they’re the ones who can then look at that problem from a different perspective and go, “How else can we serve this customer? How else can we sell? Or what else can we do? What else can we sell that enables the customer to do what they want to do without selling this drill that we can no longer sell for whatever reason.” That’s a silly example, but there are real fundamental cases where that’s true.

Look at Kodak. Kodak believed they were in the market of selling chemicals and machines to print shops, to allow print shops to print your photos. And so the customer to Kodak was the print shops. Not the person who’s taking the photographs. They forgot that they were in the market of allowing people to capture memories. And it was in their marketing that Kodak Moments kind of thing. But their marketing wasn’t replicated in their business. They invented the digital camera. But, well, they were so tightly bound to their existing markets, their existing customers, that they forgot who they were in business for, and they paid the price for it.

Business Agility Institute [00:21:15]

Henry Suryawirawan: [00:21:15] When you set up this Business Agility Institute, what is the purpose behind it? Why do you think an institute would make a sense for people to join and maybe learn from each other?

Evan Leybourn: [00:21:26] Of course. So I actually never set out to create the Institute. In 2016, I was in India. I was speaking at Agile India Conference, and I was talking about business agility as it’s what I talk about. It’s what I’ve always spoken about. I was with IBM at the time. But afterwards, I was sitting down with a friend of mine, and we were talking about the problems that we had with existing Agile conferences. And don’t get me wrong, I love Agile India, other than 2020 for obvious reasons, I’ve been to that conference every year for almost 10 years. But when you talk business agility, half the time, everyone in the room nods and goes, “Yes, we need this.” But they go back to their offices and nothing changes. And so I was lamenting, I was very frustrated about this to my friend, and she said, “Well, why don’t you create a Business Agility conference?” I was like, “All right, I will.” So in 2017, we launched the first Business Agility conference. This was in New York. I was living in Singapore at the time. I have to admit, running a global conference, literally the opposite side, it was a 12 hour time zone difference. It was not pleasant. But I walked into that room, I had a fairly arrogant assumption. I assumed, cause I’d been talking about business agility for at that point, eight or nine years, I thought that I would know most people in the room, 80%. I was wrong. I knew maybe 20%, maybe less, maybe 10% of the companies and the people in that room.

We sold out, by the way. It was a huge success. What this exposed to me was that there was this untapped pain. People wanted to talk about business agility. They wanted a space to call their own that wasn’t in the Agile world, that wasn’t in the technology world. But where a CFO and a CHRO and a transformation consultant, and people who were wanting to see businesses change, to create a space whereby they could have that conversation. So the conference was a success. And after the conference, we started planning the next event, which was obviously a year away. Completely coincidentally, I had to move from Singapore back to Australia for family reasons. I do miss Singapore. I’d moved back there in a heartbeat if I could. I love Singapore. But so I had to move back for family reasons, and so I had to resign from IBM because I was employed by IBM Singapore. I’m there going, what do I do? I’ve got to get back to Australia. I could join IBM Australia. IBM Singapore was pretty good. I enjoyed IBM Singapore. I didn’t think I’d enjoy IBM Australia anywhere near as much as I enjoyed the work I was doing at IBM Singapore. Do I join another consultancy or do I join a firm like a bank and help them with their transformation? There was nothing in my heart that so went, “yes, that’s what I want to do”. I kind of felt that part of my career was over. Paid well, and I certainly was making an impact. But I then thought about what I enjoyed, and I thought about the conference. I thought about the impact we’d had. I was talking to a gentleman called Ahmed Sidky. I was saying it’s like, “I don’t want to run events. I’m not an event planner. The event is a means to an end. It’s a way of bringing people together. Is it possible to create a business that brings people together?” And that’s where the Institute formed from. It’s to create that space for those conversations.

Now I’m going to jump forward six months because when we started, we had a particular vision. We were going to do events around the world. We were going to have a library of content and material to inform people about business agility. About six months later, I was actually, ironically, at the same conference in India where this whole thing started. I was listening to a talk by a lady called Linda Rising. She’s amazing. If you’ve never heard her speak, I suggest you check out some of her YouTube videos. She got her PhD in Information Technology I think when she was 60 or something. Absolutely brilliant. And she said, ironically, the plural of anecdote is not data. Now, that’s actually an incorrect quote and there’s a whole bunch of reasons why. But her point, which was very valid, in the Agile, and in my case, business agility environment, so much of what we do is based on anecdote. It worked for me here, therefore it’ll work for me there, or it’ll work for you there. And the assumption that, because I’ve got it, I’ve done it once, it must be true. She was lamenting the lack of good evidence and research. I realized at that moment in that talk that we were one of the few organizations who could. Because we weren’t selling services, we weren’t selling consulting. So if we were to do research, it could be trusted. Because we would never sell services based on that research. With all respect to a lot of the other organizations in this space, they’re either selling consulting, they’re selling certification. And so if they say Agile is great, and then in the next email they’re saying, buy our services or become a certified X, the credibility isn’t there. I’m not saying they’re wrong, but the credibility isn’t there.

So we decided that we would become a research institute. So we actually shifted gear after about six months. This is what business agility is. It’s about changing what you do to better serve your customers. So we became a research organization. So now we have that professional association, we still have the events in New York and we have a couple of others around the world, but we’ve actually scaled back events. Actually, we started scaling back events before COVID, which seems prescient now. We now have 14 research teams. We just launched our research on agility, on the relationship between agility and diversity, equity and inclusion. The problem with being a research organization is if we have negative findings, we still have to publish them. Let’s put it this way, Agile organizations do not score well in general in terms of DEI, in many cases, it’s not because they’re doing Agile badly, it’s because of Agile. So there are things that need to be done to improve some of the Agile practices and frameworks to embed D, E and I better into them. Sometimes we have to publish things that actually say, “Hey, maybe we’re not so crash hot after all”.

Agile & DEI [00:27:45]

Henry Suryawirawan: [00:27:45] So I’m pretty interested in why some of these Agile organizations not actually making good scores on DEI? Some of the hindrance in your research, probably if you can share with the audience?

Evan Leybourn: [00:27:55] Yeah, absolutely. So, well, there’s a couple of things. First of all, D, E and I is implied within Agile, but it is not explicit. So what does that mean? That means that we say individuals and interactions over processes and tools. But you know what? We assume that it must be there, but it’s not, and therein lies the problem. The second thing that we do as the focus on transparency, the focus on rapid communication, even practices like the daily standup, it’s designed for people who are neuro-typical. They’re able to think fast, they’re able to talk fast. They’re able to engage in a public social setting without hesitation. Whereas neuro-diverse people who may be introverts, people who may have that kind of social challenges really struggle.

Another issue is around even just the technology and the tooling. One of the researchers had a visual impairment. Actually, one of the things that we discovered from this, his organization went through a big Agile transformation, and he ended up leaving the organization because they went from MS Project to whatever else, which don’t get me wrong, MS project is the worst. My project management days, I really hate that product. But at least it supports a screen reader. So he could know what was going on, because it would speak it out. He could zoom in. He could see what little vision he had, he could read, and he could hear. Whereas when everything transitioned to post-it notes on the wall, he can’t read it, he can’t see it. So he can’t actually do his job anymore. And worse, the organization, because D, E and I wasn’t embedded in that as a principal, it wasn’t even considered. We say individuals and interactions, but we don’t.

There are also cultural issues. Let’s be blunt. Where did the Agile Manifesto come from? 17 middle-aged white men. Back in February 2020, I was in Nigeria launching the Business Agility Conference in Africa. There was a speaker there talking about what African agility looks like. Because it’s really interesting, and it’s really challenging. There’s this huge culture of respecting our elders. What happens if you are a young Scrum Master, trying to be a servant leader with developers or team members who are older than you? There is this cultural conflict that emerges that was never considered in the design of any Agile practice, because that’s really not a thing in America. This is just some examples. There is a lot more, and any of your listeners can go to our library and download the research report because all of our research is public. So you can find out more there.

Henry Suryawirawan: [00:30:36] I’ll make sure to put it in the show notes later on. So thanks for sharing the findings from your research. Actually, it’s pretty interesting because now that I heard it, completely makes sense to me, because I see some of the introverts may not be able to fully be embedded inside of some of the practices of Agile. Just like daily stand up or maybe retrospective. So I think, yeah, it’s pretty interesting research. I’ll also probably read up to know more about this as well.

Business Agility Domains [00:30:59]

Henry Suryawirawan: [00:30:59] The other thing about business agility I saw from your website is that you come up with these domains. So many different domains as a principle or the guiding framework behind business agility. Maybe, can you share a bit about those domains?

Evan Leybourn: [00:31:12] Yes. So the domains of business agility were actually one of the very first things that we published as a piece of research. In fact, it actually wasn’t meant to be research. It wasn’t meant to be something that we publish. It started out as a blog post. I was just writing about what I thought were the characteristics, the domains of business agility. I finished the article, and I just happened to be going to surgery that day. It was a day surgery. But I put it up on LinkedIn to my followers and I was like, “Hey I’ve written this post. Here’s a Google docs link. This is what I think the domains of business agility are. Love your feedback. Can you follow the link, add some comments?” That kind of thing. So I come out of surgery and obviously the first thing that you do when you come out of surgery is check your email. I open my email, and I look at this document, and there’s about 60 people having a comment war about what business agility meant. So what started as a blog post effectively then turned into this big community consultation, which then turned into a grounded research study on what are the characteristics of an Agile organization.

Now when we look at this, there are certain characteristics. Now, obviously this is a podcast, so I can’t show you the domain. So I’ll just highlight a few key points. The first is at the very heart of the model is the customer. Now there’s a big argument as to who’s at the heart? Some people said it should be the customer. Some people said it should be employees. Some people said it should be shareholders. And there’s argument for each. Shareholders own the business. You look after your employees, they will look after your customers. That’s a pretty good train of thought. But the reason we put customer at the center was, and I think I mentioned this earlier before, your customer is why you are in business. Simon Sinek says, “Start with why.” Because they represent the purpose, the reason you exist, we put them at the heart.

Surrounding the customer are the three domains that we call relationships, workforce, board and partners. Workforce is an interesting one. In an early version we had employees, but the problem is there’s contractor. It doesn’t matter what your legal employment type is, you still need to be part of that. So workforce is a generic term that encapsulates everyone who creates value. The board of directors because the shareholders are important, and they do represent agility. They’re also ironically the furthest people from the customer. So if they’re making strategic decisions around the organization, around the direction, around the hiring of the CEO, all that kind of thing. If they don’t have some customer centricity themselves, they’re going to be making poor misaligned decisions. And then partners, because the agility that you can express as an organization may be limited by things outside your organization, your suppliers or distributors. Let’s say you have distributors or agents or vendors and so forth. If they’re the ones who are talking to the end users and you get your feedback from them. What’s Amazon’s statistic? They can release a change into production every 11 seconds, something like that. So yay for DevOps. But if you can release change every 11 seconds, but you can’t get feedback, or your distributors can’t take that change, give it to their customers and give you feedback, if they can’t do that quickly, let’s say it takes them six months, your agility is not measured in seconds. Your agility is measured in months. That’s why partners is one of the key domains. Three leadership domains, three individual domains and three operations domains.

The leadership domains of people management, one team, and strategic agility. These refer to the capabilities of leaders and the behaviors of leaders. People management is one that I take to heart. In part because of my own personal experience of being a bad manager. But we know that management accounts for something like 70 to 80% of employee engagement scores. We know that people leave organizations because of bad managers, more than anything else. So management is such a vitally important capability inside Agile organizations. But if we think about managers, what do we think about the managers from office space or the office? We think about the pointy head boss from Dilbert. Managers are at best, incompetent or at worst, evil. Everyone wants to be a leader. No one wants to be a manager. And unfortunately, management is a skill, and it is such a vital skill. So we’re on a quest to reclaim management. Because management is good and it is important. And there are bad managers, yes. But to all the listeners, think back in your career, think back to the best manager you’ve ever had, and the job satisfaction that you had there, and the opportunities that arose from that. I think you’ll find that for most of you, that good manager is what makes such a huge difference.

The individual domains: growth mindset, ownership, and accountability and craft excellence. For this audience, craft excellence is going to be, I think, a hot topic. Because I’ve seen a lot of organizations kick off an Agile transformation because they have a lack of skill in their development teams. And they think that, “Oh, it’s very expensive to go and train everyone in the latest version of Java or whatever else.” Hiring, they hire cheaply. And I’m sure you’ve all worked with people where you look and it’s like, “How did you get that job?” You’re not doing what you need to be doing. The issue isn’t agility, the issue isn’t Scrum. The issue is the fact that they don’t have the skill to do the job. So that craft excellence, and it doesn’t have to be development. This is accounting or marketing, whatever the craft is, has to be done with an embedded sense of quality and purpose.

And then the three operational domains: process agility, enterprise agility, and structural agility. Now, process agility is where most transformations begin, that’s transforming a process. An organization is not just a process. The software development process, great. Adopt Scrum, and that gives you an Agile process around the software development life cycle. Or Agile marketing around the marketing process, or beyond budgeting for the budgeting process. This is where something like theory of constraints comes in. You’ve got other processes that fit in. You’ve got recruitment. You’ve got budgeting. You’ve got deployment. You’ve got security. You’ve got PMO. Hundreds of processes weaving in and out at various points in this software development life cycle. And so enterprise agility is creating agility, not just in that process, but in the network of processes and the relationships between them. And then structural agility is around how an organization creates agility in the way teams are formed. To those of you who have had the misfortune to be part of an organizational restructure around squads and tribes, it’s not a bad thing. It is actually an element of business agility.

A key element of structural agility is this concept of no handoffs. A functional hierarchy where a junior developer reports to a senior developer, who reports to a dev lead, who reports to a head of development. That is nothing more than a modern implementation of a thousand year old apprentice system, where an apprentice blacksmith apprentices to a master blacksmith to learn the skill. Because the apprentice system is designed, is optimized for skills transfer. So the functional hierarchy is optimized for skills transfer. But what happens here is that at a certain point, I don’t need a cross-functional team of multiple disciplines to show a horse. I need one blacksmith who knows what they’re doing. That’s it. But there is not a single modern product that I can think of that can be done with one person with one skill. It requires a team and a team with different skills. Now in software, we figured this out cause I haven’t seen an organization with a separate dev and test team for 10 years, and that definitely was the case. But outside of software, we still have these functional hierarchies. So the value of structural agility is to reduce those handoffs in the system to optimize for the flow of value through the system, which then actually ironically sub-optimizes for skills transfer because there’s always a trade-off. So that’s why Spotify has their chapters and guilds to try and counteract that sub-optimizing for skills.

The problem is that many transformations, they forget. They start adopting squads and tribes and they restructure, but they don’t really look at why they’re restructuring. They’re doing it because they think they should. They’re doing it because everyone else is. And they actually end up designing a system that is no better. You may have all pivoted 90 degrees, but still got the same number of handoffs between you and the customer, and so no agility is actually being created. So it can help, but to be blunt, more often than not, it doesn’t. That’s pretty much the domains, and there’s a lot more to it, obviously. We think of this as it’s not a framework. You can’t actually create a framework for business agility. This is a characteristic model. I think of it as the “Don’t forget model”. If you’re going to change an organization, these are the things not to forget.

Henry Suryawirawan: [00:40:17] Thanks for sharing all these. There are lots of the concepts inside all the domains, definitely. For people who are interested, I think you can refer to the website, and find out more. I’ll also put it in the show notes.

Theory of Agile Constraints [00:40:28]

Henry Suryawirawan: [00:40:28] One thing that probably we can go deeper because you mentioned it a couple of times, is about your theory of Agile constraints. Actually, you wrote about it a few years back if I’m not wrong. So maybe you can explain to the people here, what is theory of constraints, first of all, and why do you come up with this theory of Agile constraints?

Evan Leybourn: [00:40:46] The theory of constraints comes from a book called “The Goal” by Eli Goldratt. It’s a very simple pattern. It says that in any process, there’s a constraint to the process. Let’s say that you’re a production line building cars, and it takes you five minutes to install the engine, and that’s the slowest part in the system. That’s the constraint. So it means that cars can roll off that production line every five minutes. You can’t roll them off any faster. It means that if you try and optimize or transform any other team, like the wheel team, you’re actually not going to get those cars rolling off the production line any faster. So you transform the engine teams. Now it takes three minutes to install an engine. But the thing is the theory of constraints, the corollary is that there is always a constraint. And so the constraint is, let’s say it takes four minutes to put the wheels on. Now that it takes three minutes to put the engine in. The car is not rolling off in three minutes. The car is rolling off in four because of the new constraints of the wheel team is what’s limiting it. So there’s always a constraint to the system.

Now with apologies to Eli Goldratt, I talk about Evan’s theory of Agile constraints. That is that in any organization, there’s a constraint to agility, and that’s probably not IT anymore. I’m going to take you all back to the sixties. I think it was 1969, the first conference. It was a conference on software engineering. At the time there was a thing called software crisis, and this was a crisis of identity, a crisis of faith, where all of these developers and programmers didn’t feel like they were being taken seriously. They looked at the professions, engineering and law, and they looked at how professional those industries were, and said, “We want some of this”. So as part of this, they created this software engineering concept, which takes, let’s be honest, a glorified version of engineering and applied it to software. To be blunt, what they took wasn’t even reality for engineers. It was this hyper-formalized. The pendulum swung too far, let’s put it that way. So what happened was that, fast forward to about the 80s, and the constraint to agility was the software teams. Because it would take 3, 4, 5 years to bring a product to market. So let’s then fast forward to about the 80s, the 90s, and 2001, it’s very logical for capital A Agile to emerge in the software world. Because that was the constraint to agility. Software teams could move faster. That’s what Agile was meant to do. It’s to create those feedback loops, to create better products, get the first version to market in a matter of months, not in a matter of years.

But remember, there’s always a corollary to theory of constraints. Late 90s, early 2000s, you have Agile. And this is where I come into the world. As I remember, I was a techie back in 2003, starting to use Agile. So I started using Scrum. Fantastic. I could have a potentially shippable product increment every two weeks. Fantastic. Where did it go? Cause it didn’t go to the customer. Because we had a release window, and that release window was a minor release every three months and a major release every six months. And for those of you old enough to remember what release windows were like, oh, that was fun. I say that. No, it wasn’t. It was not fun at all. So even though we were able to create this potentially shippable product increments every two weeks, we couldn’t actually deploy them until six months later. So our agility, it was not only measured by years, but it wasn’t measured by weeks, it was now measured by months. Cause operations became the constraint. DevOps really became a thing after Tech stopped being my day-to-day job. But DevOps was the way of the industry addressing the constraint to agility in the system.

So now we have Amazon statistic, every 11.3 seconds or whatever it is. So we can deploy change now in seconds. But remember the corollary, there is always a constraint. If you can create a shippable increment every two weeks, if you can deploy in seconds, but it takes you three or four months to hire the right person, it takes you nine months to get a budget change approved. It takes you six or seven months to get a vendor engaged. You have to wait for the next project control board to approve the next phase gate or whatever process project that you’re running. Despite the DevOps, despite the Agile, your agility is constrained by HR or Finance or the PMO or compliance or wherever happens to be inside your organization.

So a large part of business agility is actually just finding the constraint. Figuring out where to apply or create agility within the system because it’s what’s stopping your teams from going faster. This is why business agility is so important, even for tech teams. Right now, Agile transformations and DevOps transformations are hitting diminishing returns, because the investment in the transformation is no longer at the point of the constraint. So for you and your teams, for all the listeners out there, for you to actually run at the speed that you know you can run it. We have to address the constraint to agility in the system, not necessarily in your team. More DevOps, more capital A Agile is in many organizations not going to help because that’s not where the constraint is. It’s like optimizing the wheel team, when the engine team is the constraint.

Henry Suryawirawan: [00:46:17] So that’s pretty much sum up all the latest that we have in this world, probably. So in the software development or the DevOps world, things are pretty great because we have new techniques, new tools, new practices, whatever that is. But I hear what you say is that from other parts of the business, like the hiring, the budgeting, the procurement, the approval probably also need some kind of new practices, theories or tools and all that. So that wraps up our discussion about business agility due to time.

3 Tech Lead Wisdom [00:46:45]

Henry Suryawirawan: [00:46:45] But before I let you go, Evan, so I have one question for all the guests, which is about three technical leadership wisdom. So can you share what are your three technical leadership wisdom for us?

Evan Leybourn: [00:46:55] So first is, I define success in business and in technology with three things: competence, empathy, and confidence. I’m assuming most of you as listeners are competent. You’re good at your jobs. You wouldn’t be listening to this kind of podcast, if you aren’t. You’re there, you’re trying to learn. Empathy is just as important. Because competence without empathy is arrogance. So you need to listen to others, listen to your customers, put yourselves in their shoes. Think about others from their perspective. And the last is confidence, which is the ability to stand up and stand your ground. The ability to say, “I’ve got an idea.” And as about in the empathy lets you say, “Oh, my idea was wrong.” But the confidence is what puts you forward. And if you have those three things —competence, confidence, and empathy— then that is how you’re going to be successful in any role that you take on. Those are the three things. Those are three skills that you all need to develop.

Henry Suryawirawan: [00:48:01] Wow. It’s short, concise, and pretty insightful, actually. So I agree with the confidence part as well. Because sometimes you may be competent and you probably have good empathy, but if you never speak up or give it a try at least, you probably won’t go forward as far as you can.

Evan Leybourn: [00:48:16] It’s actually worse than that. Competence and empathy without confidence, you may be trustworthy, but people may not trust you. Humans, we trust confidence. We shouldn’t, because often, confidence and empathy without competence is fraud. Let’s say we see that in a lot of politicians. But if you have competence, empathy, and confidence, you will be trusted. You’ll be seen as trustworthy. But if you only have two of those, and missing the confidence, then the people around you, your bosses, their bosses. Maybe your boss knows, your peers know. But your boss’ boss and your boss’s boss’s boss, they either won’t see you or they won’t be able to build that personal sense of trust with you. Not because you’re not trustworthy, but just because you’re not expressing it.

Henry Suryawirawan: [00:49:07] Pretty insightful reminder for actually all of us, especially the techies. Some of us probably are not the most confident individuals in any company. So, when you get a chance, maybe you should step up and be more confident so that, like just Evan said, many more people will be able to put their trust on you. So thanks Evan, for spending your time. It’s really great. So where can people find you online or about the work or about the research that you’ve done?

Evan Leybourn: [00:49:32] So check out the Business Agility Institute. The website is businessagility.institute. I’m still amazed at how many top-level domains there are. In fact, that .institute is a top-level domain. Look me up on LinkedIn. My only request is if you’re going to connect with me on LinkedIn, tell me that you heard me on this podcast. I get hundreds of LinkedIn requests every week, and I don’t connect with people unless I know who they are, or know how they’ve found me. So tell me that you heard me on this podcast, and I’ll connect with you.

Henry Suryawirawan: [00:50:02] Thanks for sharing those tips. So thanks again, Evan. I wish you good luck with all your business agility, you know, research, and also you know, trying to revolutionize, so to speak, the other parts of the company that has not been transformed into more Agile.

Evan Leybourn: [00:50:17] Thank you. It’s been a great conversation and I hope I can impart some good ideas. So thank you very much.

– End –