First, we're going to start with the most important question: why, if we look at, for example, the Fortune 100 companies from 1983 to 1993 to 2003 to 2013, will we see that 57% of these organizations no longer exist in their current form and some have gone bankrupt? I think there's about seven bankruptcies in there; some came out of the bankruptcies but some did not. Some have been acquired, some have gone through mergers, some through divestments, but in all these cases 57% of the largest companies in America no longer exist. This is why we care about business agility. We want organizations to thrive in ambiguity; we want them to survive in it. Who here wants to lose their job? No? Yeah, there we go. This is why we want organizations to thrive and survive—because business agility is nothing less than the survival of organizations and the ability for them to thrive in an unpredictable and ambiguous market.
I'm part of—I run the Business Agility Institute. We are an independent advocacy organization to promote agile organizations. Everything we're about to talk about comes from a series of surveys we ran over the last 12 months, looking at 166 companies and 400 odd people to understand what business agility was for them, how it worked, what benefits it brought, and what challenges they were facing. The results, probably unsurprisingly, were pretty terrible. Organizations around the world are very weak in business agility. Some are good—some are market leaders—but the vast majority are just pretty ordinary. Four point nine was the average maturity; seven and above is a good score, and anything less than seven is a poor score, just like in PS.
When we looked at what organizations did well—in terms of customers, understanding, pride in their work, and building agile teams—these were areas where they thought they did well (traditional Agile, Scrum, Kanban, and so forth). Areas where they did badly were funding models, finance, HR, market experimentation (the realm of lean startup, the ability to bring products to market quickly and experiment in that market), and supporting functions like HR and marketing. These are the areas in which companies were failing. So we're going to turn this around. I want you to tell me what you think about your organization. Pull out your phone, go to the URL pollev.com/bizagility, and tell me what you think about your organization or your client organization if you're a single individual. Tell me, how mature are they at autonomy and delegation?
What does this mean? I add a—in what we call pre-crawl, which is a very low maturity organization—this is delegation: I'm going to push work to you; I'm going to tell you what to do and how to do it. In the middle, my team can make local operational decisions. I can make decisions around my team, what my team is doing, and how it works in the market—like with our customers. This is where I have accountability for an outcome; my boss doesn't tell me what to do, what product to build, or how to build a product, but simply says, "I want you to achieve this business goal." We want to increase staff satisfaction by 20%; we want to have 50,000 more downloads of our app (that's a bad outcome, but anyway). I'm not going to tell you how to do it because your job is to do it—your job is to figure out what needs to be done to make it happen. There are a few teams that are more agile than I was expecting, but we're looking at the majority of teams sitting at one to six. Does that make sense? That's what business agility looks like; we'll come back to that in a bit.
Let's give you some examples. This is something called an enterprise visibility room. It is an example of how organizations build transparency and autonomy in some of their teams. This is a Kanban board—it’s nothing more than a Kanban room, to be honest. It’s an information radiator showing different things, but it’s not for a team, a project, or even a product—it’s for the entire company. The people who walk into these rooms are the board, the CEO, the CIO, the CMO, the CHR—their job is to go through and look at the primary initiatives that we, as an organization, are undertaking.
What’s a strategic goal? How are we going towards our strategic goal? What does that look like? Are we able to achieve those goals? There’s a great example coming from a bank in Singapore where they have, not a room, but portable boards. They have a sheet about a big initiative that is gradated from green to red, and they call these the confidence meters. It’s fantastic. There are different columns: question number one, how confident are you that we're going to meet our strategic objective; question number two, how confident are you that we're going to hit the next milestone; question number three, how confident are you that we have the right skills to achieve what we want; question number four, how confident are you at not asking questions around the strategic makeup of the organization. There’s no data behind it, no science, no system—it’s just a yellow post-it note on this green-to-red scale. So if I'm the CIO and I've got these boards around me—this is initiative one, initiative two, initiative three, initiative four—then what do I do? It's like, "Initiative—alright, Havel, why are you not confident about this initiative? What is it that we can do to increase your confidence around the skill of your team, or those of the leaders who report up to you?" I don't need to know what you're all doing; I just need to know that you have the ability to do what you need to do. I don't care what you're doing—if you need me, I'm here to help you—and those confidence meters tell me what's necessary. Another interesting thing about this is, of course, if you're very confident for three months and then you fail, that tells me something as well—not a good thing, but it does tell me something.
Let me introduce you to an idea: the domains of business agility. A couple of you, fantastic. About a year ago—actually, a bit over a year ago, last May—we ran the first Business Agility Conference in New York. This was meant to be a conference to answer the question, "What is business agility?" As we got closer to that conference, we realized that it was a stupid question—that trying to define business agility at this point would actually undermine it. Business agility is the ability for an organization to adapt to a changing marketplace. Okay, great. How helpful is that? Not really. So we had the conference—the conference was a huge success—but we didn’t try to answer that question; we just explored the entire breadth of business agility, what people were doing in this domain. Then, after the conference, I wrote a blog post—about 500 words long—that said, "Here's what I think business agility is made up of. Here are the different parts that make up all the different domains of business agility." I was going into hospital for day surgery and I put it up on Google Drive, I put it out on LinkedIn, saying, "Hey, I've got this little article about what business agility is. If you've got some opinions, let me know. I'm going to publish it tomorrow." I come out of surgery eight hours later, they give me my computer, and the first thing I do is check my email. There are about 60 people who have started a comment war in this Google document about business agility. What started as a 500-word blog post turned into a community consultation around what we now call the domains of business agility, and this is the result: it is three dimensions, nine domains, centered around the customer.
Why is the customer at the center? This was one of the areas where we had the biggest debates. Shouldn't employees be at the center, as they are a most valuable asset? Shouldn't shareholders be at the center, since they own the company? We ended up with the customer for one very important reason: the customer is why you're in business. They're the reason you do what you do. You're not in business to make money—a mistake that many of us have made in the past. Companies that forget that they're in business to serve a customer tend not to be in business for very long. There's a great quote by Frederick Lalu: "Profit is like air—you do not live to breathe, but you do need to breathe in order to live." And that's quite true. We need to make money; profit is important, but that's not why we exist. We exist to serve the customer, and never forget that.
The work dimension looks at literal ways of working. We're going from technical agility—this is the domain of DevOps, this is the domain of XP, the main way of actually creating something in an agile way—to process agility. This is the value stream, from ideation through to delivery. This domain includes Scrum, Kanban, Lean Six Sigma, and Enterprise Agility, where we're looking at not just a single value stream but the system, the systems thinking that the value stream exists within an organizational system. HR, finance, and marketing—these three areas are some of the biggest constraints in agile today. There's an idea—who here has read The Goal by Eli Goldratt? A couple of you; it's a fantastic book, and I do recommend you read it. With apologies to Eli Goldratt, Evan's theory of agile constraints is that an organization can only be as agile as its least agile part. If I have a production line building a car and the slowest part is attaching doors, then I can only produce cars as quickly as I can attach doors. No matter how agile my IT function is, the slowest or least agile part in that ecosystem determines the overall agility.
Let's take a history lesson. Thirty years ago, in 1986, the first talk about Scrum took place. Why did we invent Scrum 30 years ago? Because IT was the constraining factor to agility—it would take three years to bring a product to market. We would build these products, create massive architectural documents, design them, build them, and it would take forever. Agile was a pushback against that heavy engineering approach. Fast forward to about ten years ago: we had Scrum, and we could deliver change every two weeks. Where's the constraining factor now? I still had to wait three months for a release window. So, I could make change every two weeks, but it would take three months before it got deployed. What did we do? We invented DevOps. Fast forward to today: Amazon’s statistic is that we can deploy change every eleven point seven seconds, or something like that. I have an IT engine that can make change every two weeks and deploy change every 11 seconds, yet I have an 18-month budgeting process, a three-month recruitment process, and HR policies and procedures designed to slow me down—they’re designed to reduce agility in the system.
So today, the constraining factor—or the fragility in the enterprise—is, in my experience, finance, HR, the PMO or compliance or legal (mostly for regulated industries like banks), connections, leadership agility (the domain of servant leadership, the domain of delegation—delegating outcomes, not outputs), and structural agility. There have been multiple talks around things like Teal and network-based organizations. An interesting personal observation: if you ask a coach what the hardest part of a transformation is, they often say it's mindset or culture. Yes, it's hard, but culture follows structure—culture follows the processes and structures that you have. If you can change the structure, it doesn't mean you're going to change the culture immediately, but it means you have a chance. If you're trying to change a culture within the existing structure, you've got almost no chance whatsoever. Structural agility means an agile structure is one where the value stream is self-contained within a single team with no handoffs, where the customer is embedded very closely in the market.
Agility in contracts and procurements is also crucial—not just the customer, but the users, your suppliers, and your distributors. If they're your constraining factor to agility—if you can make changes every two weeks but your distributors don't want to sell a change every two weeks or are slow to inform their customers—then you can't be agile; you can only be as agile as they are. The mindset—a learning mindset, a growth mindset, a collaboration mindset, an ownership mindset—are the cultural behaviors you need to embed in an agile organization. I call this the "Don't Forget" model because if you're going to run a transformation, don't forget to do these things.
Who’s doing SAFe? Who’s doing Scrum? Most of you—fantastic. Scrum is here and a little bit there: 1, 2, 3. Some frameworks don’t tell you anything about technical agility at all, very deliberately; you have to go to XP or DevOps for that. They don't tell you how to structure your teams; they just say you need a couple of new roles. They say our leaders should be collaborative, but they don't actually give you any guidance around leadership agility, nor do they touch on enterprise agility. SAFe gives you a little bit more on enterprise agility, as do DA and other scaling frameworks. There is no framework out there that will do everything. So if you're running an agile transformation and you're basically trying to say we're going to be agile, don't forget there is more to building an agile organization than any single framework you might adopt.
Next set of questions: bring out your phone. We talk about agile organizations as being outcome aligned—that is, I don't care what output you're going to create if the outcome is being realized. In a low maturity organization, we have projects where we track time, cost, and scope, and we only track the benefits of that project when it's complete. We could be using Scrum inside that project to our hearts' content—that's not outcome aligned. In the middle, we're aligning teams and KPIs against product goals, not project goals. So I'm no longer being measured against time, cost, and scope, but rather on the benefit to the customer. In the end, we're changing funding models: I'm going to fund a team to achieve an outcome—not to build a product or deliver a project. The work will come to that team, but their accountability—that KPI—is about an outcome. And that's about what I would expect: pretty terrible, right? Organizations around the world—and this is true no matter what country I'm in—show this trend. The Nordic, Scandinavian countries actually do pretty well; most of the rest of the European countries, the American organizations, and organizations in Asia all sort of run around this sort of ratio.
A couple of other findings from the Business Agility survey: if you're going to transform your organization, finance and HR have the biggest impact on your organizational agility, yet they are the divisions that the fewest companies are actually transforming. There is such great insight and work that can be done if you're willing to go well outside IT into those supporting functions and help transform them. If you can't go that far—if you're just transforming technology or doing a standard IT transformation—then you're just sitting at the bottom like everybody else. What about who's leading it? If your transformation is being led by the head of X, then their span of control—the span of influence—is quite weak. If your organizational transformation is being led by the board, then you can change everything. It is a sad state of affairs that in many agile organizations, when we talk about delegation and autonomy, the most effective transformations are led by the board, yet organizations remain highly hierarchical.
Last question for you: tell me what challenges you're facing. You can write in English, Czech, or your national language—whatever is fine. I want to know the top challenge(s) that you're facing. There we go: mindsets, business transformation, agility mindsets, culture, communication. Oh, communication—I'm doing a talk this afternoon on communication in the other room, so come to that talk as well. Mindset—yes, interesting. This is different from the global responses. The global responses showed that the biggest challenge most organizations face was not up here; some from the small ones said management and leadership was the number one issue. Money—money is always an issue. So these were the top challenges from the survey: leadership buy-in, organization design, skills, and capability. I'll send out the slides—no need to take photos; I'll send them all out to you.
On that note, as you walk out the door, I have some copies of the report to give away. There are only a couple of copies, but I've got some printed copies of the report and a copy of the radar that you can use to run a quick assessment of your own organization—it's just on the outside. This is the kind of feedback we received about where business agility was struggling. But what about the success? This was a bigger surprise for me: market success, revenue. Not because I don't believe an agile organization has greater profits than a non-agile organization, but because I didn't think we as a community were there yet. I thought we had another five years to go before real financial benefits were realized, but globally, that was the number one benefit that organizations found—which I thought was just absolutely fantastic. Some of the comments we received from both clients and staff were, "Much improved. Our culture is strong, vibrant, and resilient." And that's what you get when you build an agile organization.
I've got time for probably one question because we're timeboxed—we're agile, we stop on time. I even got a question: "Why customer and not user?" That's a good question. To be honest, user didn't actually come up there. From a business perspective, a user can be a customer or a user can be behind the customer. From a business perspective, we are looking at revenue; we do need to earn money. So yes, keeping users happy is critically important, but the customer is the one who is actually funding our work—they're the ones who make the decision about what we're going to create. They probably have more authority over us than a user. Users have authority over us collectively. So if you have an iPhone, you're a user or a customer of Apple, meaning you have no influence over the next version of iOS except as a group. I'm hypothesizing here because it wasn't something we really explored. I should mention we are working on version three of that model now, so I will take that into account.
We were talking—one more question. No? Fantastic. Well, thank you very much. If you want to know more about the Business Agility Institute or the work we're doing, feel free to come up to me—I'm wearing a three-piece suit, so I'm probably the easiest one to find around here. As I said, there are some giveaways just on the table outside; feel free to grab one as you walk out—once they're gone, they're gone. If you want digital copies of this report, you can download them from the Institute website or just email me and I will share them with you. Thank you very much.