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 capabilities, behaviors and ways of working 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 would say that they're
doing agile, not being agile. And that's unfortunately quite limiting. So you need all three to be effective. Hey everyone. My name is Henry Surya with Robin. And you're listening to the tekhelet Juno, the show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an
impact in your personal work. So let's dive into our Journal. Hello again, to all my listeners out there. It's great to be back here again with another new episode of the tackling Journal podcast. Thanks for spending your time with me today, listening to this episode. If you haven't, please subscribe to technology, you know, 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 pack leader. No dot f, / Patron, and help me too. Producing great content every week for today's episode. I am happy to share my conversation with Evan laybourne.
Evan is the founder and CEO of business agility Institute and international membership, body to both champion and support next generation of organizations that are agile Innovative and dynamic in this episode, haven't shared about the current maturity of a jar. Adoption and how agile has matured over the years by looking at three different agility. The categories technical agility process or operational, agility, and business agility.
Evan then explain 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 discuss about his theory of age are constraints borrowing from the original theory of constraints introduced by dr.
Eliyahu. Rat and in his theory of age are constraints, even shared his insights on. Why he thinks a jar 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 touch on and shared about the recent business agility Institute, research, finding on why many HR organizations.
Leslie fail to embed and support, diversity, equality and inclusion, or DUI within the organization's an interesting. Finding that look at the intersection between a gel and d. I, I really enjoyed this conversation with Evan and I hope you will enjoy this episode as well. Consider helping the show by living 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 podcasts 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. Are you looking for a new cool swag tekhelet Journal. Now offers you some swags that you can purchase online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool swag is available by visiting
technology. No, dot f / shop and don't forget to brag. Self. Once you receive any of those tracks everyone, welcome back to another new episode of the package. You know, today I have with me, everyone Laybourn 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 Asia Innovative and dynamic.
So today we are going to talk a lot about business agility and things related to that. So Evan. Thank thanks for being on the show. Hoping to have a good conversation with you about business agility. Thank you Henry. I'm really looking forward to it. It's gonna be a good conversation in the beginning event. Maybe could you introduce yourself for the audience who may not be familiar with? You may be highlighting or turning points or major
highlights in your career. 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, obviously, this is the tech lead Journal, it would be worthwhile to share, where I started from a technical 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. 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 their dime, a dozen these days, but they were very new back then those really Citing, I don't know if any of your listeners are really in the 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 these systems only to get 0 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. 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 maybe 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. Data, but I wasn't a good director.
There were skills there that I 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 Seeing as a director around, getting teams divisions and functions across multiple government agencies, because 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 kind of things. But if you think about it, cooperation, collaboration coordination, these are things
that agile. The capital A did really well, obviously, in building software products, but I had this sort of like a half moment. 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 holding my own I 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-plus countries. We don't do training. We don't do Consulting but we do research to actually have 14 research teams, exploring different. Assets of business. And I suppose what that looks like. That was perhaps a long answer to your question, but there's Evan in a nutshell. So, thanks again for sharing your story. I think one thing that I noticed is when you mention about a gel with capital A, so maybe we can share a little bit.
What do you mean by Asia with capital A? And is it common to say, Asia with lowercase a now when we say a job with a capital, A we use that to refer to the agile Manifesto and And the agile practices and Frameworks. It is the thing called agile, the noun, whereas a draw with a little a it's the verb. It's a 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 is 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. So you mentioned about all these experience that you have and you also now have business agility. Maybe a nutshell. What do you think is the current maturity of Asia adoption. I mean, it's been around for, I don't know. More than a decade. I would say probably.
Yeah, and what do you think is the current adoption of companies familiar with it? They are able to introduce that and be more jails. Let me separate this into three categories of agile. This is just Evan how I see it. This isn't some Vishal? 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 rappers, 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 delivery, the actual writing of code. Now, I would say that over the years. We have got very good at this in part because it's something that can be repeated, devops as a concept. I know some of y'all As 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 organization. We all know organizations that are struggling. If we look at the process agility, the operational agility. And 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 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 a bun to on my laptop. I haven't logged into it for a while, but I still have a bunch of 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 Say almost pride and respect they have managed to turn their organization around.
Now. It's not perfect everywhere, but they are 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 and almost native agility. Microsoft has gone in Incredibly well, because of it. If I look at another organization like IBM, its older more established, but it hasn't had and its 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. Irene IBM. But the organization as a whole doesn't have that they have pockets of agility whereas Microsoft has pockets of an agility, 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 kind 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 Is the technology Industries Financial Services firms are in the top. They were in the top three. They dropped.
I think the number 4. 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 still, very young industry. It's sort of a while to go before before companies. That shift effectively. 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 adoption. But you mentioned that technology space and Manufacturing are in the top three. So what is the other 10 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 for consulting. Firms aren't agile. 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 mid-size 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 is that Microsoft IBM game of generational change is going to be required. 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. What is business agility? Let me give you the definition. And as we Define a 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 things capabilities behaviors and ways of working in reverse order, the ways of working is what you do.
That have behaviors, is what you're expressing. And the capabilities is what you've achieved. If you've W 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 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 a customer. We build a product. We serve a customer in a particular way and 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 lelou 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 in those companies tend not to last more than five to ten years.
Those companies who get that customer centricity are the ones who especially right now in a very Dynamic, very unpredictable Market other 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 duel because you want to drill, you're buying a drill because you want to hole, and you want to hold because you want to put up a set of shelves.
So that drill company isn't in the market of selling drills there 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 Three issues or the EU says, you can't sell to them anymore. You can't import drills for whatever reason. I know that's for silly example, but just bear with me those organizations who see themselves as we sell drills have a
problem. Those organizations who the 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 in a Tables 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, the 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 that 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 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. When you set up this bizarre. At The 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? Of course. So I can never set out to create the institute in 2016. I was in India.
I was speaking agile, India conference, and I was talking about business agility, as it's what I talked about, 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 About the problems that we had with existing agile, conferences, and do 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 ever in the room nods and goes. Yes, we need this, but they go back to their offices and nothing changes. And so I was the menteng I was very frustrated about this to my friend and she said, well, why don't Don't you create a business agility conference? That's 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 site is a 12 hour time zone difference. It was not pleasant, but I walked into that room. I had a fairly arrogant assumption. I assumed because I've been talking about business agility for at that point. Eight or nine years. I 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. Old but we're a CFO and a chir row and a transformation consultant, and people who were wanting to see businesses change to create a space where by they can have that conversation to the conference was a success.
And up 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 move back there in a heartbeat if I could. Love sample, but so I had to move back to 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.
I am. Singapore was pretty good. I enjoyed our AVM, Singapore. I didn't think I'd enjoy IBM, Australia, or 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 had I was talking to a gentleman called Achmed Siddiki. 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 is 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 events around the world. We were going to have a library of content and material to inform people that 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 an Don't 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 they say agile is great. And then in the next email, they're saying by 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, 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.
Start scaling back events before covid, 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 us put this way. Agile organization, do not score. Well, in general, in terms of d&i in many cases, it's not because they're doing agile
badly. It's because of our job. So there are things that need to be done to improve some of the agile practices and Frameworks to embed DNA better into them. Sometimes we have to publish things that actually say. Hey, yeah, maybe we're not so crash right after all. So, I'm pretty interested in why some of these agile organization, not actually making good scores on the, what are some of the hindrance in your research? Probably if you can share with the audience.
Yeah, absolutely. So well, there's a couple of things. First of all, de9 I is implied with in 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 stand-up.
It's designed for people who are neurotypical, 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 introverted. First people who may have that kind of Social Challenges really struggle. And now the issue is around the even, just a technology in the tooling. One of the researchers have 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 or 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's what a screen reader. 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 transition 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, and I wasn't embedded in that as a principle. It wasn't even considered. We say individuals and interactions, but we don't, there are also cultural issues. Let's be blunt. Where do the agile Manifesto? So, come from 17 middle-aged white men back in February, 20, 20.
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 your elders. But 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 in any of your listeners. Can go to our library and download the research report because all of our researchers public. So you can find out more that. 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 a child 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. The other thing about business
agility. I saw from your website is that you come up with these domains so many different domains except principal or The Guiding framework behind business agility, and we can you share a little bit about those domains. Yes. So the domains of business agility, we're 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. That the mains the business agility. I finished the article. I just happen to be going to surgery that day. It was just a surgery but I put it up on LinkedIn to my followers and was like, Hey, I've written this post. Here's a Google Docs link. This is what I think the demands of business agility, our 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 have 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 turns 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 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 Arguments for each shareholders, owning 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 Y 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 contracted. It doesn't matter what your legal employment type is. You still need to be. That 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 third this 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 of 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 statistic, they can release a change into production, every 11 seconds, something like that. So gay 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, terrains, three, individual domains and three operations. Domains the leadership domains of people management one team and strategic agility. These refer to To the capabilities of leaders and the behaviors of leaders people Management's.
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 are 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 the 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 Old in their development teams, and they think that 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 at.
Like, how did you get that job? You're not doing what you need to be doing the issue isn't Jilla T. 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 don'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. Life cycle, oh, 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
feed in, you've got recruitment. You got budgeting, you've got deployment, you've got security. You've got pmo hundreds of processes weaving in and out of various points in the 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.
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 June developer reports to a senior developer who reports to a deadly to reports to a head of
development. That is nothing more than A modern implementation of a thousand-year-old Apprentice system where a 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 or what happens here is that at a certain point I don't need a cross-functional team of multiple disciplines to shoe 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 can figure this out because I haven't seen an organization with a separate. Devon testing 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 Lower 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 that chapters and gills to try and counteract that sub optimizing for skills. The problem is that many Transformations. They forget, they start adopting scored some 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 been created, so it can help. But two blunts 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 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 Things not to forget. Thanks for sharing all these. There are a 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. One thing that probably we can go deeper because you mentioned a couple of times. It's about your theory of age are 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 for support? And why do you come up with this theory of Of age are constraints.
The theory of constraints comes from a book called, the goal by Eli Gold rap. It's 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 Seemed 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 team. So 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 takes three minutes to put the engine in the car is not rolling off in three minutes, the cars running off in for because the new constraints of the wheel team. Is what's limiting in it? So there's always a constraint to the system. Now with apologies, that your leg old Route, I talked about Evans 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 60s. I think it was 1969. The first conference 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. Faith. We're 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 a glorified version of engineering and applied it to software to Evelyn what they took wasn't even reality for engineers. It was this hyper formalized, the pendulum swung too far for 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 three, four, five years to bring a product to Market first, 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. Was that was the constraint to agility software, teams could move faster. That's what agile was meant to do, create those feedback loops
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 signed to use agile. So I started using scrum fantastic, I could have Ave potentially shippable product increment, every two weeks. Fantastic.
Where did it go? Because didn't go to the customer because we had a release window and that release window is a minor release every three months and a major release every six months. And for those of you old enough to remember what released 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 increment, every two weeks. We couldn't actually deploy them until six months later.
Our agility, it was known as measured by years, but it wasn't measured by weeks. It was now measured by months because operations became the constraint. Devops really became a thing after Tech. Stop being my day-to-day job. The devops was the way of the industry, addressing the constraint to agility in the system. So now we have Amazon statistic, every eleven point, three seconds or whatever it is, so we
can deploy change. Now in seconds, but remember the corollary there is always a Restraint, 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, either. Budget change approved. It takes you six or seven months to get a vendor engage. 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 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 stopping your teams from going faster. This is why business agility is so important. Even for Tech teams right now. Agile transformations in devops.
Transformations are hitting diminishing returns. All 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 at. 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 wheels. When the engine team is the constraint, so that's pretty much sum up. All the latest that we have in this world.
Probably also in the software development, or the devops will 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 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. 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? 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 want, 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 yourself 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 and 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. And 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. Well, 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. Yes, you can. 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. No, but your boss's 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 just because you're not expressing it. Pretty insightful. Reminder, for actually all of us, especially the pakis.
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 what happened said, many more people will be able to put their trust on you. So thanks everyone for spending. Your time is really great. So where can people find you online or about the work about the research that you've done? So check out the business agility Institute website is business agility dot Institute.
I'm still amazed at how many top-level domains there are. In fact that dot Institute is a top-level domain. Look me up on LinkedIn. My 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. I know how they've found me. So tell me that you heard me on this podcast and I'll connect with you. Thanks for sharing those tips.
So, thanks again, everyone. 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 Into more a gel thank you. It's been a great conversation, and I hope I can impart some good ideas. So thank you very much. Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts
better. You can also find the full show notes of this conversation on the episode page at tackle, the journal, the death website including The full transcript, interesting quotes and links to the resources and mentions from the conversation. And lastly make sure to subscribe to the show's mailing list on technology. No, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.