Evan Leybourn pioneered the field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. He keeps busy as a senior IT executive, business management consultant, non-executive director, conference speaker, internationally published author and father. You can find our more about Evan on his website, The Agile Director.
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Related Podcast: Should Projects Ever End?
Transcription of the Podcast
Joe: Welcome everyone. This is Joe Dager, the host of the Business901 Podcast. With me today is Evan Leybourn. Even is an experienced leader, coach, and author in the developing field of Agile Business Management. He applies the successful concepts and practices from the Lean and Agile movement to corporate management. Evan, I would like to welcome you and could you introduce the audience to your book, ‘Directing the Agile Organization?’
Evan: Good evening to you Joe. Thank you very much for taking the time to interview me. I’ve enjoyed reading your work over the last few years. I started in this field primarily after the IT space. Starting with very traditional agile technologies and Agile practices around IT, and IT development, and IT project management. It came to a point where I was promoted outside of IT which everyone likes being promoted but we always get to this point where we start coming across the political issues, the communication issues, the budgetary constraints that get hidden from you when you’re a lowly developer.
I started to realize that the values and the principles and the methods of working in an adaptable or Agile way which we sort of exemplify through our IT over the last 10 years would work in a corporate context, the business management context. In about 2008, I started working with organizations and clients around Southeast Asia and Australia to take these concepts and to build a concept of Agile Business Management or Business Agility in a much broader, wider context and it’s been absolutely great. I’ve loved it so far.
Joe: It sounds pretty exciting. From the IT area, were you kind of a Scrum guy, a Kanban guy, or XP guy? What was your experience?
Evan: This is before Kanban. I’d have to say that I probably would have been a Kanban guy if it had been around. Well, to be fair, Kanban has been around for almost like 60 or 70 years, but Kanban and IT has only been around for about 5 or 6. But no, I was a Scrum guy. A little bit of XP, a bit of Pair Programming, but with the organizations I work with, it was primarily Scrum. That’s one of the things about Agile is there’re so many different frameworks but there’s only two or three which have the mindset, or the market penetration and Scrum is probably the biggest of them. If you ask anyone, they’re probably all Scrum, guys.
Joe: They probably are. I think people that have been in Lean a while. Most of them were all Six Sigma black belts, but Lean’s the popular term and they gravitate towards that now.
Evan: It’s a market brand. Six Sigma was very popular especially with their certifications through the belt system over the last 15 odd years. But more recently, the Lean practices especially with aspects such as Lean Startup, even going earlier into TPS which is the Toyota Production System, these are brand concepts which are gaining some market traction within business management. If I walked into an organization 10 years ago and I said, “We’re going to build a Lean organization…” They would have thought that I would have been making redundancies. Whereas now, if I walk into an organization as a consultant and say we’re going to be building a Lean organization, there’s a certain understanding as to what that means. They want efficiency, but they also want adaptability. They want these concepts of Lean Startup, these concepts of reducing wastes. So the concepts are now starting to build their way into the way businesses think.
Joe: When we talk about businesses, they’re all Agile, right? I mean every business is Agile, but your experience when you go into them, are they really practicing Agile at all?
Evan: Many organizations say they’re Agile, but they’re not. Organizations are built upon years and years and years of process, and process is very easy to create but very hard to get rid of. The older an organization gets, the larger an organization gets, no matter what they say, no matter what their branding and their marketing says, it’s very hard for organizations of that size to actually be Agile. Forget about practicing Agile. I’m not just talking big A Agile, Scrum. I’m just talking adaptability or agility in the very raw sense.
For an organization of any reasonable size to actually change their market positioning in a matter of weeks or months is impossible for many organizations. Certainly there are organizations that don’t have adaptability built into their core. So a lot of what I do is actually; it’s not about teaching them how to use sprints, or iterations, or retrospectives. It’s not about various stand-ups. It’s about how do you at your very organizational core, your organizational structure, how do you embed a concept of agility so that when something changes in the market and the market is changing very quickly right now, you’re in the position to adapt and be competitive, rather than — well, I like to call that ‘Kodak Moment’ where you invent something that’s groundbreaking and then ignore when someone else takes it and kind of puts you out of business.
Joe: I think that’s a good way to put that. You’re talking about adaptability and those Agile principles, do you use the same project management principles of Agile as you move out of software?
Evan: That’s a surprisingly hard question to answer. In the first instance, the majority organizations do. Project management has been around; the same project management practice has been around since the 80’s. If I was to build a risk flow or a project management plan or a schedule, it wouldn’t really change whether I was looking at a project from 1985 or 2015. However, what we’re starting to see especially in an Agile context, larger organizations that adopt Agile tend to do so some within the context of a traditional project management approach. Now this has certain issues, implications where you lose some ability of adapting to change, but you gain some perceived reduction in risk of failure, or a simplification of selling the idea of Agile to the organization.
We move now to say the high maturity organizations; the organizations that actually understand the adaptability in agility. And for them, there is entirely new ways of running projects which are actually not using projects at all. The problem with projects themselves is that they are highly risky and prone to failure. In fact there are studies by every single consultancy, every single organization like McKinsey and so forth, which looks at the failure rates of projects, the overspend of projects and I’m not just talking IT here; I’m talking across the board.
There was one study I saw recently which you may or you may not agree with the mass behind it, I know there’s been some controversy but which states were that the total cost of project failure in the United States per year is in the order of like 1.7 trillion. Something’s going wrong if there are numbers with the word trillion attached to it, attached to a concept of project management. The idea in more mature organizations gets to the point to answer your question, is to actually move away from rigorous project controls and move towards a really adaptive approach where we have these concepts of continuous change and continuous delivery, where change or institutional organization change in what we know and be developed within the concept of a project can be developed incrementally or iteratively in a continuous fashion day after day, month after month, year after year.
Joe: Well that kind of throws me; because the first thing I think about is a project has a beginning and an end, okay? That’s the very first thing I think of, and you’re saying no, that really shouldn’t be happening in business. Because some businesses, all they do is projects.
Evan: I work with many organizations like that, and I will tell you that I’ve never seen a project that has gone to plan. I wouldn’t necessarily say that they would have failed, but they’ve never actually gone to plan; just that sheer concept. The point of a project is having a start, a middle, and an end, that’s actually one of the biggest problems that we find in organizations today. They run a project; they develop ‘X’ – it doesn’t matter what it is; be it an upgrade to internet explorer on the desktop. It could be a rollout of a new software product or a module for whatever. It doesn’t actually matter. But then they stop; the project team disburses because it’s probably not necessary to be a team who’s doing the projects. So they disperse, they go back to wherever they came from and then six months comes, or a year comes, or 18 months come past and they have to do another 10 to 15 million dollar project to upgrade the system because you’ve lost the expertise, you’ve lost the skills, you’ve lost the people. You have to stand everything up from scratch, and the organization is not being able to actually keep up with the continuous or on-going change.
The idea is that apart from the very few, apart from an experiment, apart from something that you’re literally saying I’m going to give this a try, and if it doesn’t work, we’re going to stop and throw it away and do something else. Apart from that case, anything that you build in a project doesn’t end. You may scale down slightly, but there’s a continuous evolution, a continuous expansion or enhancement of whatever it is you’re creating.
Joe: You’re not going to really have a project close out per se, but you’re going to put the necessary controls in place maybe for this to continue on?
Evan: Controls are absolutely necessary. There needs to be — what we talk about is we talk about outcome-focused. Whatever it is that you’re creating needs to meet or work towards a predefined and agreed outcome; not an output. I personally couldn’t care less how you create something; as long as you comply with a certain set of principles that the organization defines, now your principles may be compliant with SOX – Sarbanes-Oxley. So any outcome, any output you create in order to meet an outcome must meet this list of principles. So this acts as your governance, your constraints, so you can’t just do whatever you want. There is still always some constraints. But when we talk about an outcome, the outcome may be increase revenue by 5%. The outcome may be increase customer satisfaction or staff satisfaction by 17%, or increase staff size by 300 people. It doesn’t actually matter what the outcome is. Once you know what the outcome is, if we have teams that are built around developing capability or change continuously towards meeting that outcome within the constraints of the principles, then we have a very robust and governed way of delivery change continuously into an organization without a project structure.
Joe: This outcome is really not at the end of the target. It’s not out there. It’s some place like in the middle because this could sustain until the end of its life cycle.
Evan: You’re absolutely correct. The idea of an outcome is we should be able to incrementally achieve value towards that outcome. It doesn’t mean that we’re going to do one thing and achieve a 5% revenue increase, no. We’re going to do one thing after another, after another and this team or teams which are accountable for this outcome, they’re going to be constantly developing new capability, new tools, new features – whatever it happens to be, in order to deliver tools and outcome throughout the process. In a program perspective, we might call this benefits or benefits realization. But even within the context of a project, benefits realization occurs at the end of a project. It may start midway but when the project ends, the benefits are meant to be realized. Outcomes realization is really very continuous. So we may hit our 5% target, but then we go for 6% and 7%. There’s an ongoing change. There’s an ongoing improvement to the organization.
Joe: I like the sound of it. I understand it because I’m kind of that service dominant logic type guy; value is in the use of the product. When you start looking at it from that viewpoint, it moves the customer to the center because there’s always something out there at the edges that you can build towards. Whether it’s a product or service, it takes a very disciplined company to think this way?
Evan: Yes. We’re talking about high maturity organizations. If you’re a command and control organization, you want to know what everyone’s doing without giving them any level of autonomy that this approach is not going to work. What tends to happen in organizations that aren’t Agile, you’re a 5-person company, you know what everyone’s doing. You’re the CEO of a 50-person company; you know pretty much what everyone is doing. You get to 150, you get to 1500 people, all of a sudden, you don’t know what everyone’s doing. You can’t physically know what everyone’s doing. So what do you do? You create a process. You create an abstraction of reality that simplifies what people should be doing and you sort of expect them to roughly follow that process.
Now, that’s great because it gives you as CEO or CFO a very clear idea of what everyone is doing or should be doing, even if you don’t know specifically. But what happens in organizations that aren’t agile is that the process becomes the reality, rather than just an obstruction. Any real activity is going to have spikes and troughs in whatever that process. There are exceptions. There are workarounds. A process is only ever as good as the way of looking at that process if opportunities expose themselves. An organization that isn’t agile can’t move beyond the process.
Joe: We limit ourselves a great deal because we’re not what I call maybe the edges and looking at the edges of projects or services because that’s where we find opportunity.
Evan: That’s it. That’s exactly it. When you have a process, you’ve got the middle. The middle is well controlled, but that’s not where opportunities lie. And what also happens is that the middle in reality moves. You have a process that you created a year ago, it’s worked fine, but the market has moved on. Suddenly it’s now mobile-centric rather than web pages. If you’ve got processes around a particular way of working and the market evolves, then what you would consider as being edge is actually the norm, is actually the middle ground and you actually start to lose market share because you cannot compete.
The rise of the mobile platforms has taken a lot of organizations completely unexpected. They spend millions of dollars on building websites to do e-commerce and whatever else and all their processes, all their mechanisms for sales, for marketing, for branding is built around this web-based approach. Sometimes you might think of it as like Web 2.0. But in the last two or three years, we’re seeing a major shift of usage of these services, shall we call them, away from the traditional web into more mobile type browsing. Organizations who don’t have the processes in place do very quickly take advantage of that are the ones who are being left behind. We’re seeing these in the numbers of public organizations right now.
Joe: Is it difficult to make money by living on the edge? I’ve always looked at the fact that you have Standard Work; that’s the core competencies where what puts groceries on the table. You’re continuously improving them, that Lean mentality. And then you have a certain percentage of it where you’re on the edges, and you’re looking for new work. So what you’re talking about is only part of the company looking at it this way and moving and there is a standard core that’s making your money?
Evan: I’m really talking about projects at the moment and project management or an alternative to projects. So projects aren’t your core by nature. Any organization is going to have a BAU or an operations team which will maintain and develop the core as you call it. Let’s actually pull back and say this isn’t actually completely independent of what you just said. If you have an outcome, and you have 10 or 15 outcomes on the organizational level, another 50 or 60 outcomes like across each of the divisions, but if you have an operation division, a team that is responsible for keeping the lights on for your core services, then they still have outcomes that they are trying to achieve. It may not be evolutionary or revolutionary, but they still have certain outcomes that they’re trying to achieve.
The same approach of continuously improving these core outcomes apply just as easily whether we’re talking about something at the fringe, at the edge of the market, or something right in your centers, right in your sweet spot as an organization.
Joe: How do people feel about this approach? I mean are they comfortable with it or are they uneasy as it’s non-traditional to them?
Evan: It depends on the organization, and I suppose I could use that answer for every question you’ve asked. Some organizations do find it very difficult and it comes down to a strong leadership, a strong C-level executive who are actually trying to push an agility or adaptability agenda. When you have organizations where you have a very rigid hierarchy, it tends to be very difficult to introduce these concepts into the organization where you don’t have that level of trust, and that’s actually a keyword.
It all comes down to the level of trust that an organization has, both with his partners in other organizations but also within its staff. How much do you trust someone to take accountability for an outcome in that organization and to actually work in the best interest of that organization? If I own the company and I have that level of trust in my staff with the appropriate governance and controls because trust isn’t blind, then I can adopt these ideas, these concepts and principles very easily. If I’m in an organization that I don’t have that level of trust, then it’s going to be very hard to start doing anything like this.
Let me also just say on this point, these approaches aren’t for every organization. There are some organizations where a tried, and true project approach works perfectly fine. If I’m building a skyscraper, I don’t want to have a level of adaptability beyond what color am I painting the walls. Even that, I need to design that logo and buy the paint. So this is very much an approach for organizations that exist in a very dynamic marketplace, and IT is one of those, but there are others as well.
Joe: Is it difficult to create measurements to the outcomes and maybe evaluate people within that construct? How do I do that? It seems fuzzy. I got a lot of fuzzy logic here.
Evan: No, you’re absolutely right. Let me ask you a question. Let’s turn this around for a minute. How do you define a smart objective for a value that is qualitative, for something that produces a qualitative improvement in an organization, how do you create a smart objective?
Joe: Put a timeline to it. You make it very specific, and you have to pick a measurement of some type. And a qualitative judgment still may be two or three perceptions and even if it’s just a thumbs-up, that’s a measurement, right? In a rating scale, as I go up, I can push that up, and that’s my answer real quick.
Evan: And that’s very reasonable.
Joe: It’s analog, right?
Evan: It is; it is. So it comes down to how do you define your outcome? Your outcome is either going to be qualitative or quantitative. I’m being simplistic here. Where it’s quantitative, it’s fairly easy to define a measurement against that. So if my outcome is to increase conversion of users to subscribers by 7% year on year, then I can measure that. I can have statistics. I can have put in place mechanisms to actually track and evaluate that.
Interestingly, slightly on topic, there’s a concept from Lean Startup that we use quite often called AB Testing, where you do have a quantitative measure and you can actually run experiments and say I’m going to try A, and I’m going to try B. I’m going to run them both in parallel for half of my user base. I’m going to measure them in real time which ones are actually more effective than the other, and whichever one wins, it will win that competition. Then we’ll pick another capability, another idea, experiment, and we’ll run that. They may both fail in which case, oh we actually lost users from both of these, but we’re not going to do either of them. By having lots and lots of these very small AB tests, we can actually incrementally evaluate and improve that we’re reaching our targets, whatever our targets are.
In the second instance where we have a qualitative measure, it’s exactly as you said. We need to find a way of defining some value against that and then try and measure against that value. Whether it be surveys, whether it be a thumbs-up.
Joe: What’s upcoming for Evan? Are you writing some articles now? Are you writing another book?
Evan: Yes. So at the moment, I’m writing a series of articles on exactly the topic that we’re talking about, that will hopefully be ready in a couple of weeks. But as you know, writing always takes longer than you think it will. I’m trying to get these ideas very crisp. I’m trying to sell these ideas to more than just my clients, and I personally have a great passion for these kinds of approaches. I think organizations that are able to be adaptive and adaptable to the market are the ones that will succeed in the next 10 to 15 years.
Beyond that, I’m working on another book on Business Ethics, on a completely unrelated topic, but very fascinating and interesting, and I’ve been working with clients in the Southeast Asia market doing these little transformations. I keep incredibly busy, and that’s exactly how I like it.
Joe: I forgot to mention even where you’re at. So you’re located in Singapore, correct?
Evan: Correct, yes. I moved to Singapore a little over a year ago from Australia. I find from a personal perspective, Southeast Asia has a much greater density of organizations who want to be adaptable, rather than Australia, which is a little bit more conservative in the way that their business operates.
Joe: Where are you originally from?
Evan: Australia. Canberra and Melbourne.
Joe: What’s the best way to contact you, Evan?
Evan: The best way to get in contact with me is probably through my blog: TheAgileDirector.com. Otherwise, I’m found all over the internet. Twitter @Eleybourn or just hook me up on LinkedIn or somewhere like that. I’m always happy to answer any questions about these topics. As I said, I have an absolute passion for it and sometimes, it’s hard to get me to stop talking.
Joe: Well I’d like to thank you very much, Evan. Is there anything that you’d like to add that maybe I didn’t ask?
Evan: No. I just want to thank you very much, Joe. I’ve loved your work for the last couple of years. It’s been an absolute pleasure speaking with you.
Joe: Well I would like to thank you again. This podcast would be available on the Business901 iTunes store and the Business901 Website. Thanks, everyone.
Lean Sales and Marketing: Learn about using CAP-Do