Panelists

	Roger Burlton	President & Managing Partner, Process Renewal Group Founder, BPTrends Associates
	Ronald G. Ross	Co-Founder & Principal, Business Rule Solutions, LLC Executive Editor, BRCommunity.com
	John A. Zachman	Chief Executive Officer, Zachman International

Moderator

Roger Tregear

Consulting Director, Leonardo Consulting

Welcome & Introductions

Welcome to you all. Thanks for joining us for this last session of what's been another fabulous BBC conference.

The Opinion of Gurus session has been running, first in Australia and now in BBC, for some fifteen years. During that time the intent has always been to get those people on the stage who make a difference, who shape the way in which business capability and business excellence is forming around the world. And we've got them here on stage today.

This is the chance to ask lots of questions — I'll ask questions; you'll have the opportunity to do so as well, through the app. Find it; remember the password; start getting your questions in as soon as you can. We have just sixty minutes together today, and a couple of times we'll go to the app and pull out some of the questions that you have. I also have some questions that have already been collected from delegates in various ways.

In today's conversation, of course, what we're talking about is the Business Agility Manifesto that our panelists have spent a good deal of time and effort — a lifetime perhaps — in pulling together. Our panelists need no introduction, of course, so please join me, in welcoming onto the stage, John Zachman, Ron Ross, and Roger Burlton. <applause>

All right. Let's all get comfortable. Get the app going and start thinking of questions so that when we get to that point they'll flash up on the screen for us.

What is the problem the Business Agility Manifesto is trying to solve?

I'm always interested in the answer to the question, "What's the problem we're trying to solve?" I think that's the question we all spend our lives answering, don't we? So, I'd like to pose this question to each of you in turn, just to kick us off:  If an organization developed the business agility that you think it should have, why would they be better off, especially in your practice areas?  In other words, if they're as agile as you'd like them to be, why would they be better off?

John, kick us off.

  Well, I committed to just 'yes' and 'no' answers to the panel discussion this morning, so I'll try to be economical in my comments.

The Industrial Age was probably, arguably, three- to four-hundred years long. We're moving into the Information Age, the Digital Age, the Knowledge Age — people have different names for it, but the game has changed. We're probably a couple of decades into this now, so a lot of different things are happening to us — notably, in the foreseeable future, we could see a dramatic escalation of complexity and of the rate of change. It's changing a lot of the ways we think. We have to become capable of dynamically changing the enterprise on demand. That presumes some things that have to happen. The enterprises of today have never been engineered, actually, so they have to be designed — because flexibility or agility is an engineering design issue. This doesn't happen by accident — there's physics involved.

My observation is that this whole idea of agility has to do with flexibility — dynamically changing the enterprise to accommodate the demands of either the regulatory environment, the government, or the marketplace. If you cannot accommodate that, the high probability is you're not going to be in business; you're not going to be viable.

That's the issue that we're trying to deal with here.

  Thanks, John.

Ron, the same question: If an organization had as much business agility as you think it should have, why would it be better off and is there a particular spin from the 'rules' world?

  The fundamental insight of the Business Agility Manifesto is recognizing that knowledge is an asset — a corporate asset — not just lip-service but the fact that it is a tangible, viable, valuable, inescapable, necessary business asset.

Entering the Knowledge Age, we have to be aware of what knowledge is and we have to work at engineering it, as John says — it's not going to happen by accident.

So, specifically, at the most basic level: concept models. Concept models are word models. They are structured vocabularies. They are a way to speak precisely about requirements, about business rules, about all aspects of communication. So, communication would be dramatically improved, which in turn accelerates development and thought.

Secondly, business rules.  Statistically, some of our clients have told us they can accelerate projects by 75% by having business rules ready before a project begins. And so, if you retain and engineer (manage) that knowledge, you have a huge advantage in launching projects.

Finally, compliance — today, unfortunately, compliance is often an after-thought, thought of as drudgery, as something to be avoided as long as possible. Compliance needs to be built in; it needs to be part of our solutions to problems. Knowledge is key to how you do that.

  Ok, thanks. So, deliberately capturing and understanding the knowledge so that we can be as flexible and dynamic about change as possible.

Roger, what is the answer from your perspective?

  I want to start out by saying that when we got together to start talking about something, we didn't know what it was going to be.

That was late spring / beginning of summer. We just all had some frustration knowing that things weren't going as well as we'd like in the marketplace. And we quickly discussed the issue that companies don't last as long as they used to. As a matter of fact, they're going out of business really, really quickly. And even the ones who do survive, they're facing the issue that time-in-market of products and services is drastically shrinking, but time-to-market is not getting any better. And so, we're missing the opportunity to be in-market with good products and services because everything was a 'start up' — everything was a transformation, and there was nothing to leverage, to save from what we had before.

So, we quickly got to the point where we realized we need to have organizations that can easily reuse things they've got already, without ripping everything apart every single time. And so we kicked around words like 'adaptability', 'resilience', 'versatility', 'nimbleness'. Then we said, "Hang on a second; this is all 'agility'!" So, that's really how we came up with the idea in the first place.

  Too many disposable organizations.

  Yes.

  Perhaps deliberately so. We don't expect to be in business for more than a year or two.

  The shareholders might, though.

  Yes, well, we'll burn brightly and die. Something a little longer term might be better.

What are two practical steps that an organization could do next week to improve business agility?

Again, I have another question for each of you. And let's see if we can make this really practical. You might tell me it's too early to make it so practical but what could the folks here take away? What are two things that their organizations could do next week — two practical steps they could do next week to improve business agility?

Let's start with Ron.

  I would say the first thing you want to do is to think about your approach to requirements and look for existing sources of business rules, which is something that today we overlook.

Business runs on the basis of contracts, obligations, laws, statutes, regulations, warranties, guarantees — and those things are not mysteries. They exist. They are part of meeting expectations of customers.

So, simply becoming more in touch with the current realm of obligations and commitments that are relevant to the area you're working in is a very important first step — instead of getting in the weeds of a solution.

  So, find the knowledge.

  Yes. Look for it; identify it; understand it. It's all there. Business rules don't just come out of nowhere. They are what runs the company. They are the basis for shaping behavior and decisions.

  OK, thanks, Ron.

Roger? What's a To Do list for Monday?

  What I would say is that it is really quite important that you start to understand and show where whatever you're working on fits in the overall scheme of things.

Ask yourself the question, "Who are we doing this for?" It's not the person in the next department; it's the person or the organization that sits outside. Ask the questions "Who cares?" and "What do they care about?" And make sure that whatever you're doing is contributing value to that in a way that, if this is something that other parts of the organization might value, it's designed once and used many times. Start to think about reusability of those particular assets, and in the context of delivering value in an end-to-end process.

  Ok, sure.

John? Two things?

  I'm not too sure I have two, but one thing that is clear: I never said … and somehow or other somebody always hears me say this … I never said, "Stop the music for fifteen or twenty years and build a bunch of models, and then you can go write a few lines of code again." I never said that!

In any case, we're dealing with the most complex object humanity has ever conceived of so far in the history of humanity, seven-thousand years or so. We're dealing with the enterprise. That enterprise doesn't have to be very big before it gets really complex. So, we're dealing with extreme complexity.

The enterprises of today are not engineered; they're not designed. So, my argument is that you're going to have to get into the formal decisions of designing an enterprise. Otherwise, you're not going to be viable in a complex, highly-dynamic environment. It's just not going to happen.

So, between now and 'some day' you're going to have to begin to engineer, to design the enterprise. You can't stop the music and design the whole enterprise; it's the most complex object we've ever seen. You're going to have to figure out how to do this little by little — iteratively and incrementally — over some long periods of time, probably infinity. But at the same time you have to keep the existing enterprise running while you're doing that. You need to continue to generate the revenue stream.

And it doesn't make any difference if you're an existing enterprise or a start-up. The start-up, hopefully, becomes an enterprise, a viable enterprise. But these issues don't go away; it doesn't make a difference who you are or how long you've been in business.

The way to do this — little by little, iteratively and incrementally — is to start out with the CEO's problem. Then, I'd parse out of that problem what I call the primitive components and focus on those. If you can solve that problem, the CEO will then have another problem, and another one.

In other words, I would take a problem-based approach to build this out — do the engineering design, iteratively and incrementally. That implies some other things. It implies you're going to have some explicit definitions of what those architectural constructs are, what your design constructs are. And also, you're going to have to maintain, to govern the implementations incrementally, over time. You're going to have to have order. Right now, there is no order.

This is incredibly important.

  Right — solve problems for people. Prove the value; don't require an act of faith on anyone's part.

The Manifesto is very wordy. What would be the catchy 7-sentence version?

Ok, let's take some questions from the audience. Can we have the slide of questions up?

"The Manifesto is very wordy." Did you write that question, John?

  No, I wrote the Manifesto.

  So, it used to be seven sentences and then John explained it. <laughter>

I guess we're not going to come up with a seven-sentence version now. But it's a valid point, isn't it? These are big ideas, complex ideas, and you can't simplify everything to a bullet point. But there is an issue, isn't there, in taking this home and explaining to the CEO about why this is important?

  I can talk a little bit about the philosophy, fairly succinctly.

We looked at the problem from the perspective of the management of the organization. And management isn't going away, by the way — you may flatten hierarchies and change your organizational dynamics, but management isn't going away.

What are the imperatives that management must satisfy on a continuous basis? We worked back from those imperatives, which are on the website, to what are the key points that people below them in the organization (and practitioners) need to pay attention to. Among those, knowledge is probably the most important.

And therefore, you need a knowledgebase — a business knowledgebase — and you need to ensure that that asset of business knowledge is protected, retained, and reused carefully.

That, in a nutshell, is a big part of the message.

What did I miss, guys?

  Roger, do you have something to add?

  Yes, I'm going to answer the second question.

  That's not fair!

  Nobody said this has to be fair.

  Can you imagine these three? That's why they took twelve months to write it. <laughter> You and I could have knocked it out in a week.

  See, there's your answer to the first question.

  For the record, the original version was about four times longer than the final version. I couldn't get these guys to be succinct; I tried and, you know, it was hard. <laughter>

What do you believe are the top 3 most important concepts of the Business Agility Manifesto that you'd like to see us leave with?

I'll go to the second question now. What do I think are three of the most important concepts in all this?

One is to take a wider perspective than you're taking today. As BAs we are asked all the time to go in and find out what's needed in this small little area, with no clue as to how it connects to value creation. So, you need to start looking at a whole value chain, start looking end-to-end — start looking at how we actually create that value, and know where you fit. Know where your client fits. Quite often your internal customer has no idea what difference it makes. They think they are the customer. But they are not the customer; they are just a means to an end. So, that's one thing: broaden your horizon; make sure you know how your customer's customer's customer is going to benefit from what's taking place. That's one.

The second thing is: organize your thinking. Don't just think about random texts and information. People might ask, "What do you want in the solution you're building?" Think about the fact that processes are different than rules; rules are different than data. Data is different than organizational structure. Get the categories of things and get stuff in them, and keep the independent variables separate so that you can then associate them together. The rule is: Don't integrate; separate, but associate. If you can do that you'll have things that Ron can put into the knowledgebase — those are the knowledge areas. Put that into the knowledgebase to be available next time.

The third one is: Don't just draw things from the knowledgebase for your project. Make sure you take what you use and document it. Put it back into the knowledgebase. Repopulate that knowledgebase so the next team knows what you did.

  I would just add the observation that I think there is a high level of risk that we're dealing with here. So, I think you have to have a survey of things you need to consider. You may not be able to consider everything all at one time, but you'd better have a way to consider what is significant — understand what the risks are that you're assuming.

That would be the key thing you want to take away. The Manifesto is a comprehensive survey of what the imperative things are that you have to take into consideration. If you're not going to consider them all then you'd better understand which ones you are going to consider and what the alternatives are.

How do we convince management that these ideas are important?

So, the common question, if I can just pull a couple together, is "How do we convince management?"

We all come to these conferences and hear about all sorts of good things, and the common question is always "How do we actually convince management?" Indeed, how do I even get to meet with management sometimes? But given that I could get there, or meet them at the water cooler, how do I convince them? And there is a different challenge for public sector organizations. In a commercial organization you might say, "We can find the pain — the stock price is going down, and everyone's very publicly upset. We're bleeding money." But in a public sector organization, what's the problem we're trying to fix?

Roger?

  I don't think it is a problem.

We've seen so many organizations in the public sector that have done a really, really good job of knowing we've got to stop driving into other cars on the side of the road and keep the population living, as opposed to having lots of accidents. That's a public sector organization. We've seen those organizations really get their head around performance.

The trick is to find what is that pain that John talked about. Now it's going to be the minister or the elected official — what's their pain? We've seen really good examples both in public and private sectors.

  I would add to that that if there is anything true about public sector organizations, they are policy rich and knowledge oriented. So, techniques aimed at those, especially when explained in the context of problems that the CEO or the top leaders see, are going to go a long way.

  And possibly under lots of pressure, maybe even more pressure than some commercial organizations, through budget cuts, demands to do more, et cetera.

  Absolutely. Absolutely.

  And people wanting to get re-elected. There's your driver.

  I don't know that you're going to see business agility high on the list of Election Manifesto items. I think that's a hard sell.

How do we know if an organization is 'agile'?

John, how do we know if an organization is agile? How would we know if we'd succeeded?

  I think that if you can change dynamically then you know it's agile.

If you want to do something with minimum time, disruption, or cost — if you're trying to just implement something — the way to do it is to hard-bind things together; you encapsulate things, so that makes it easier to implement.

But if you're trying to engineer for change — for agility — you separate the independent variables. In my seminars I say to write this down because this is such a key idea. If you want flexibility, agility, you separate the independent variables.

For example, if you know you'll want to change this room after you have it built, don't hard bind the wall to the floor. We can see this room is not designed to change. If you want to change these walls out, you're going to have to scrap and rework — tear the wall down and rebuild the wall and the floor.

For agility, what you have to do is engineer things so that they are separate — you separate the independent variables, loosely-couple them, associate them. You can define where the dependencies are, but you don't want to hard-bind them together if you want to be agile.

  I'd add this one thing. You would know that an organization is agile when you can make a change to a business policy in no more than the length of time it takes to think through the risk and the consequences from the business perspective. In other words, all the change management aspect is in the plumbing, and once you understand the right policy that you want, you 'flip a switch'. That's when you know you're really agile.

  I like what Ron says about the knowledgebase. Nobody is going to change this building until they get in there and look at what the descriptive representations for the building are. You start changing things and you could lose the whole thing in a heartbeat. So, you'd better have that knowledgebase. They will have it for this building.

For airplanes and buildings and things where citizens are getting hurt, they will be regulated; they won't be allowed to build a building unless you can guarantee to the people who have jurisdictional control that you are describing the building. And they will look to see that you actually built the building the way you described it. Then, if you want to change it, you have to go back and change the descriptive representations before you can change the building.

This is a really critical point. Ron has made an issue of this for decades: If you don't know how your enterprise works and you start wanting to change it, it's high risk. You can change it and see what happens — that's like knocking these walls out to see if the building will still stand up.

What is the business knowledgebase?

So, Ron, the business knowledgebase is obviously a core concept. Bring that to life for us. What does that look like? Is it a database of something?

  Let's not think about it quite that way.

I think the best way to think about a business knowledgebase is through the eyes of anybody sitting here in the audience. Think, in your own work from day to day, what questions would I like to have answers to? What questions would I like to not have to spend time doing detective work on in order to understand how something works?

You would like that knowledge right at your fingertips.

So, think about it in terms of questions that you would want answered — like "What is a Gold Customer?" And who decided who Gold Customers are? Who can change that policy? Where did it come from in the first place? What are the exceptions to those rules?

If you could answer those questions, imagine how accelerated your day-to-day work would be.

Yes, you could describe a knowledgebase in terms of 'platforming': Okay, it's a database; it's a repository. But that's really not the point. The point is having the knowledge at your fingertips in a knowledge companion that enables you to do your work more effectively.

What is the difference between 'agile' and 'agility'?

Let's take another question — this one at the top because I think it's an interesting one.

Obviously, 'agile' has all sorts of meanings, and you kind of get the idea that if something isn't agile anymore it's hardly worth doing. But it does have some very particular meanings, and you must have thought about this when you decided to use the word 'agility'. Because you're not talking about agile software development. You're talking about something quite different. Just tease that out for us — what is the difference between 'agile' and 'agility'?

  I think that they are different forms of the word. If you look at agile software development, that's a methodology. Or, somebody said to me this week and I thought it was a really good answer, "It's a project management methodology" as much as it is anything else. So, that's a way of doing things.

But 'agility' is a characteristic of an organization.

Just because you do agile development, it's your development that's agile, not the product or the service you deliver; it's not necessarily 'agile'.

A large part of this is because IT organizations have been under such pressure to get things done faster that this is a very appealing thing. Project management — what do we measure project managers on? We measure them on time and budget; we don't necessarily measure them on flexibility. That's not part of their goal.

Whereas, from an organization, I can talk business agility to a Chief Executive Officer. But I probably can't talk it to an agile development team, unless they're part of that messaging across the whole organization.

  Let me just add a point or two about that. One of the things we avoided in the Manifesto and its positioning is that we did not talk about organizational agility. We did not talk about team agility. We didn't talk about social agility.

Those are methodological agility — those are all forms of agility, and there is plenty of space for contributions in all areas of agility. But the one area that we focused on in this Manifesto is on the business agility, meaning the management imperatives of managing assets and protecting assets — especially knowledge — and ensuring that what we do, from day to day, aligns with strategic and business objectives.

  You know, we were very careful to isolate our own individual perspectives out of the Manifesto. Roger comes from a process domain; Ron comes from a rules and knowledgebase domain; I come from the architecture domain. There's nothing about those subjects in the Manifesto. We were careful to maintain a completely neutral kind of perspective.

For the question that was asked, I will show you my bias now, which has to do with enterprise architecture. (And those folks who were with me in my tutorial Monday will have heard this before.) If you cannot show me that set of single variable, ontologically-defined, primitive components, I know your enterprise is not agile. You could tell me anything you wanted to — but I would know that it's not agile; it's not integrated; it's not flexible; it's not interoperable; it's not reusable; it's not aligned; it's not engineered.

So, you can argue anything you want to, but I'll tell you, "Show me the model!" I'll tell you whether you're agile or not.

The word 'agile' is getting abused here. It's a marketing word. And this is really a serious issue. Using the word to describe something that it is not is just not reasonable. Forgive me for getting emotional.

  John says it's a marketing word almost in a disparaging way, but we're also using it as a marketing word ourselves.

I think a large issue for many of you in this room is, "How do you market this to the executives?" How do you communicate that this agility is an important thing, when they've heard the word over and over and over and over again? And they think you're coming to talk about software development.

 By the way, if we've got an agile business — we've got these models and the knowledge that Ron is talking about — if we've got that, then we can do agile software development in a much better way than we're doing it today, especially if we return the knowledge back to the knowledgebase when we're done. There's nothing wrong with software agility. But without attention to business agility you'll be doing a lot of stuff that you can't maintain.

What roles are needed for all of this?

Let's talk a little bit about roles and take it to the highest level first.

Just to follow up, Ron, when we were talking about the knowledgebase, I appreciate that it's a sort of 'ultimate wiki' with all the answers to all the questions you might ever want to ask, but that does have to be created and managed and owned. It is a real thing — it's beyond concepts. You're going to type something in to something and get an answer. Or you're going to talk to something and get an answer. Who's in charge? How do we do this? Do we set up a different structure?

  I don't think anybody completely knows the answer to that question, but I can tell you that the owners will not be, and should not be, IT. The way I would say it is to ask yourself who owns other business assets in the organization: Who owns the money? Who owns the facilities? Who owns the processes? (Although maybe I shouldn't go there.) Who owns these?

In a sense, everyone in the company are stewards and participants — there's not necessarily the sense of 'ownership'. So, there are various roles: there are protectors of the asset; there are facilitators of the asset; there are implementors of the asset; there are users of the asset; there are participants in the asset. And, so, what needs to happen is sort of a rich, multi-aspect (multi-dimensional) web of governance and usage. This needs to be woven, but I don't think that, today, there is any single answer for every organization.

  So, we might have a Chief Agility Officer? <laughter>

  Maybe a Chief Knowledge Officer.

  I would argue that there ought to be, if it's not the CEO, the Executive Vice President in charge of Change Management.

  And they've got to have some clout to make it happen.

  Yeah, I hate it when he has a better answer than I do. <laughter>

  And a really short one!

  Yes, unbelievable.

  What's interesting about this is, when it comes to physical things, we do have this clear role. There are people responsible for the buildings. It's very clear; someone's responsible for this building, and if it's a whole series of buildings it's going to be a senior person. We have people responsible for humans.

Where we don't have it is where it comes to these more conceptual things, these less tangible things. We are just now learning to do this.

John mentioned before about the Industrial Age: It took the Industrial Revolution two- to two-hundred-fifty years to really take hold and stick. And there were a lot of casualties along the way. People had to learn to do that, and we're just at the beginning. We have to have a few generations of management die off in order to perhaps get there. (I'm sure some of you would like to facilitate that. <laughter>)

  A few generations of consultants as well.

  So, the timetable is obviously very long. It's forever, I guess, to develop.

But there needs to be something that happens in a short time, doesn't there, just to maintain interest and attention? Organizations have gotten shorter and shorter attention spans.

  I think it's critical we not see this as a 'project'. Don't see this as a transformation. It's like you want to go on a crash diet and then, after a bit of weight loss, go back to where you were? No, you need to change your lifestyle.

This is a lifestyle change for organizations.

  Good answer.

  By the way, Ron has never said that to me, ever, in my entire life.

  Oh, I must not be thinking clearly.

  So, ok. We have a high-level view of it, with still some work to be done to make it real. But what's going to happen to lower-level roles? For example, take 'business analyst' — we've probably got a room full of people who are business analysts of one sort or another. Do you think that increasing agility in an organization changes that role?

  Just the opposite. I think the business analysts are the catalysts that make agility happen, in whatever way that you want to define 'agility'.

You know, there's been a lot of discussion at this conference about "What's the future of 'business analyst'?" Will people still be called 'business analyst' in the future?

I can't foresee a time when there isn't a need for people who are a catalyst within organizations — people who do what business analysts do, which is that essential change aspect of bringing business thinking and technological innovation together. They are fundamental and central to the whole area.

  I have a friend, Dan Appleton, who's been around in the industry for a long time. He's made major contributions, and I learned so many things from him.

Years ago, he was arguing that the person who is the market for these kinds of ideas turns out to be the person the CEO turns to and says, "Go find out if that's a good idea for us to work on." Do we want to do Six-Sigma? Do we want to do Balanced Scorecard? Do we want to do XYZ?

Whoever that is — the title might be 'business analyst' or 'business architect' (I'm not too sure) — but whoever it is, it's the person the CEO turns to. And if that person has a knowledgebase of how the enterprise works, they will be able to construct a specified argument about what needs to be dealt with. For any issue that has to be dealt with, there's probably a set of things that can be done — how much money to spend, how fast do you want to do it, …. That's probably the person who would be charged with the actual work of creating the knowledgebase and keeping the knowledgebase to do the assessment, the diagnosis of the problem.

In fact, the young man who works with me to do my workshops — he works for Battelle (the large research company) — he was doing enterprise architecture and they didn't know what he was doing. He was using my Framework to go solve problems. He would retain the knowledge that he identified as he was solving a problem, putting it into a repository that was structured, that had separated out the independent variables. Over a period of years now he has become known as "the guy who can solve the problem." He's the go-to guy. And, by the way, he doesn't work for IT; he works for the CFO.

He would argue that the general manager who really cares about this is the CFO — the Finance Officer — because they deal with (a) risk and (b) resource allocation. He would argue that that's the place it needs to reside.

  So, don't look around for the person who's going to make it happen because the person is me!

  I think that, as business analysts and business architects, you are professionals in your own field, with your own methodologies and practices. The people you're dealing with don't know your business. So, you have to bring those methods to those people. The thought that people in business are going to solve all these problems all by themselves I think is just nonsense.

  I was reminded, in the hallway just before this session, that we should be careful about calling everyone at this conference 'business analyst' (or 'business architect') because the person I was talking to has the title 'Director'.

So, there are people among us here who can actually carry this off and take this message directly to management. They are the people.

It's something to keep in mind.

Are there examples of organizations that have demonstrated a high level of business agility?

So, as we come to the end of our time, the question that's been sitting near the top and everyone's been keen to have answered, "Are there examples of organizations out there with high levels of business agility?"     The poster children of the modern age who didn't exist five or ten years ago — are they agile, or are they just a new form of non-agile?

  There's an organization that we've been close to for a long time, Morning Star. They are a tomato paste and tomato packing company. When you buy Heinz or Campbell's — anything tomato — it all comes out of Morning Star. They are in California.

They are completely agile. They've got all this stuff going on. But no one talks about it. They don't know that they are agile. They never set out to be agile. It's just the way they set up to run the company, where everybody is focused on the end results and everybody knows they have to be very nimble in the marketplace. It's in the culture of the organization.

So, maybe if we're really at the top of the maturity of this, we don't even know about 'agile'.

  When Eli Whitney invented the cotton gin, that was identified as the beginning of the Industrial Age. Then, how many people were inventing cotton gins, or automobiles, or airplanes? Not very many.

We're only into this for a couple of decades, for goodness sake. So, nobody's going to be perfect in this regard. But we can start to see where it's going to go. In fact, in the American Civil War we were starting to see the formalization of standard interchangeable parts in weapons, the standard production environments. It takes a while before it permeates everywhere.

But if you don't start, you're never going to end up any place. You've got to begin to see where it's going and then you begin to invest some intellectual energy into creating the descriptive representations. You find that you can't 'wing it'; you can't do it by just remembering everything. Think about it; you couldn't remember everything about this building. They had to write it down in order to create it.

So, you need to start doing these kinds of things, iteratively and incrementally — you don't need to do everything, but you do need to begin working on it.

  I think a lot of the people who think about business agility are thinking about start-up companies and companies that are fundamentally disrupting marketplaces. And you can look awfully agile — you can appear to have business agility — when you are so successfully because you have hit a sweet spot in disrupting an industry.

But if you really want to test business agility, go to an old company, go to an older industry. I'll go back to the example I cited earlier, a major, large insurance company — they have improved their time-to-completion on projects by over 70% by having business rules up front. And they have also improved by an order of magnitude the success rate in their projects. I would say that that is a signal of business agility.

  As long as we're talking examples, in our experience there's a huge issue of executive motivation. I had a client one time who said to me, "Roger, I'm planning to get a promotion within the next eighteen months so whatever you do has to be working and be measurable within the next twelve months." That's not a good argument for being agile.

So, one of the things we noticed is that long-running, family-owned businesses are much more likely to think about the health and value of the family asset than somebody who's going to be there for two years and then get fired with a big payout.

What is the main impediment to an organization achieving agility?

OK. Let's draw this to a conclusion. A question for each of you — you've got sixty seconds, and I'd like you to share with us what you think is the main impediment to organizations achieving agility. Show us how it's done in sixty seconds.

  I would argue that the main impediment is deciding to do it. If you don't believe it's going to be helpful — if you don't believe it — then you're not going to do it.

  Silver bullets.

I'm going to turn and ask John a question, if I may. John is a walking treasure in our industry because he's been here since the dawn of the computer age, literally. <applause> (Yeah, he paid me to say that.)

  He is the knowledgebase. We found it!

  So, John, in your forty, sixty (how many?) years in the industry, has there ever been a time when the next silver bullet was not going to solve all our problems?

  Geez, I love this.

You know, Cobol was going to solve all the problems — you remember that, right? All you have to do is Cobol; you'll never have to work or think again in your entire life. Everybody will live happily ever after. And you can get rid of all the programmers.

All you have to do is Virtual Memory, and you'll never have to work or think, and you get rid of all ….

All you have to do is The Cloud, and you'll never have to ….

All you have to do is XYZ ….

The silver bullet phenomenon is so dominant, people believe you don't have to do actual work. But there is no silver bullet. In fact, Fred Brooks wrote that article, "No Silver Bullet." That is a great article; everybody ought to read that article.

  I knew I could depend on John for my answer.

  And I've got a few more ideas about this….

  Machine learning, blockchain, cloud, …. You can add those to your list. They're all great. It's all wonderful stuff.

  There's something good about everything. But there is no silver bullet — no magic that is going to make all the pain go away. Every one of those ideas is a good idea. The question is, "What do they do?" and "What don't they do?" That's the question.

  And the accretion of the little bits of good, over the years, from all of these silver bullets should be doing more for organizations than we're seeing. Is that a summary?

  No. In many ways they've made the problem orders of magnitude worse than it was, decades ago.

  Sticking it on; not designing, not diagnosing.

  I'm going to take a different perspective on all this.

I think the fundamental issue is that the executives of the organization have a conflict of interest compared to the outcomes the organization is trying to deliver, including longevity and sustainability and so on. They're not measured on this: they're measured on how many sales did my group do this week; they're measured on how much cost reduction did we have; they're measured on how much cash do we have in treasury. They are not focused on these issues — there's a conflict of interest there.

Until we get all those executives having at least part of their incentive on sustainability of the organization, we're not going to get the behavior we're looking for. I think this is critical. <applause>

  And do you see that actually happening?

  We see some organizations, now, where people have some of their incentive at least toward customer-centric outcomes, as opposed to just "my department." That's the process answer.

  But we're a long way from seeing some market analyst rating them highly because of their increasing business agility, in any meaningful way.

  Absolutely.

  They would think agility means the ability to shed people — we're good at sacking people.

Wrap-up

All right. That's it for this session. Let's give our thanks to the gurus. <applause> And, Gurus, as is our tradition, we need to thank these folks because we couldn't do it without them. <applause>

# # #