 and come in. Let me run a little quiz. A little exam. See how well you know agile. What is the earliest reference to agile? Now by the way, I don't know how it goes in my book so, how long it gets to closest, we'll get a couple. 1986, go earlier. 17s go earlier. 87 go earlier. 50s, keep going. 18th century. 18th century, keep going. A British man might be a little bit too far. I'm sure that he would trade the wheel but there was no record of that. 18th century is the last, keep going. 15th century, keep going. It's about agility, it's about agility not agile. Alright, can you hear me now? Alright, I'm just going to use my loud voice while I sort this out. Alright, 15th century, keep going down. 10th century, keep going. Evolution itself, I suppose we do have records technically of that, but not quite what I'm looking for. How about 600 BC? Allow me to read you a story. By the way, this is from West and I know there are probably other histories which I don't know about. I will not talk about that, thank you. Allow me to read you a story from 600 BC. A very large oak was up rooted by the wind and thrown across a stream. It fell on some reeds which were thus addressed. I wonder how you, who are so light and the wind, are not entirely crushed by these strong winds. They replied, you fight and contend with the wind and consequently you are destroyed while we, on the contrary, bend before the least breath there and therefore remain unbroken and escape. Aesop's fables, 600 BC. Now, I honestly, in the two and a half thousand years since then, I can't find the best description of what agility is. This is the imperative that we have to survive. And so this is why we're going to talk about physical agility in the next 25 minutes or so. Let me give you another imperative, a call to action. These are the top, well, 50,000 companies of the Fortune 100 companies from 1983 through to 1993, through to 2003, through to 2013. This is, as you can see, a very large number. Of the hundred, 57 of those companies no longer exist. Six bankruptcies, 34 acquisitions, 7 mergers, 10 divestments. 57 gone. Have a guess how many Fortune 100 companies from 2013 didn't exist in 1993. Sixty percent. You have much. That's a bit too high. Twenty percent. Twenty percent of the world's largest companies did not exist one generation ago. Then you. The younger than probably half the people in this room. Now, think about that. These are trillion-dollar companies. These are the biggest of the big. Yes, they fail. They are the program, not the read. So business agility. I want you for the next 25 minutes to put aside all thoughts of scrum, all thoughts of karma, safe, less, DA. It doesn't matter. It's not about agile to a capital A. This is about agility. This is about the imperative to survive as an organization. So, with apologies to Elliot Goldrat, I need two volunteers from the audience. I'm not going to make you do anything about it. Stand up. Can you stand here? No, you need both hands. So, let's talk about the theory of constraints. So, we have an organization. An organization represented by a flow, a process. Now, this represents, in one case, a jealousy. Now, if we have an organization with equal flow, it never happens. So, what are we going to do? There are some constraints in here. So, first thing, we want to make our IT more agile. Move this down here. Big gap here. Now, IT is agile. Isn't that a great thing? Except what's down here? Business and employment. It is sales. It is a limiting factor to our agility. But it's not as simple as that. It actually occurs throughout the organization. Lots of little parts constrain. This, and in fact, it may not even be at the start. There we go. So, we can make this bit agile. Great. What's that down there? Finance. Our budgeting process. We have an 18-month budgeting process. And even if we do open up the deployment and make that fast, and our IT is agile, we as an organization have a constraint. Thank you. Thank you. The point is, with that sticky, sticky, sticky tape, is that there is always a constraint in your organizational agility. There is always a limitation to how agile you can be. And in your organizations, is it IT? Is it software? You may not be doing capital A agile perfectly, but is that your constraining factor to agility? Sales. It's not IT anymore. It hasn't been IT for 10, 20 years. For some organizations, much further down the maturity curve, maybe. But what we are trying to say is, look beyond IT. We have techniques and technologies, practices, frameworks, and a mindset that tells us how an organization can be agile. It dates back 2,500 years. This is a very quick summary of what I call the domains of agility. I'm just showing you this to give you a sense of where business agility fits against Scrum or Kanban. Now, this is my personal opinion, not truth. This is what I believe. I see that there are three forms of agility. Business agility, process agility, and technical agility. Now, for 20 years, we've been focused very heavily on these first two sides. Why? Because in that theory of constraints, IT was the constraining factor. But it's not anymore, which is why we now start to open up. Technical agility. This is where we started. This is coming out of the software crisis out of the 60s. This is where we start looking at test-driven development and pair programming, XP, all of the technical practices. But let's be clear. Even though it's agile originated in software, technical agility is not bound to the software domain. Beyond budgeting. If I'm an accountant, there are practices within beyond budgeting and the agile accounting practices that gives me the ability to be agile as an accountant. The same is true with your HR or marketing or so forth. Process agility. This is where it's no longer about the individual and the work that they do, but it is now about the domain and the process within the organization that they operate within. Project management. Product management. Program management. Portfolio management. Put management at the end of anything and you're probably describing process. And we can make a process more agile. In fact, Lean Six Sigma is all about optimizing a process. But also, by the way, my problem with Lean is it assumes that the process is right in the first place. But let's put that to the side. These are all different areas within which process agility has evolved. Scrum, Kanban, DA, SAFE, they all operate at this level. But also, in some cases, at the business agility. So business agility is at an organizational level. Now this is not a pyramid. This is not a hierarchy. This is not above the other. These are interrelated elements of an organization that need to work in conjunction. Business agility, leadership, structure, design, the very heart or DNA of the organization. Now there are practices that sit within business agility. DA has elements of business agility. SAFE has elements of business agility, whatever you think of SAFE. Beyond budgeting, whilst noting it's down here in technical agility, it's also up in business agility because there are practices and methods within beyond budgeting that sit in both domains, that sit in both technical and business agility. Now, does this all make sense? Yes, hands up. Fist of five. Beautiful. You will notice I've made one controversial change. One problem I have with Agile, capital A Agile on the manifesto, is it originated in software, but it's no longer about software. So my personal opinion is that working stuff is much better than working software because it's not just about software anymore. Does this make sense? Beautiful. All right. Let's talk about four domains. The structure of an Agile organization, leadership, customer interaction because the customer is the heart of an organization, which is surprising because, as I heard Steve Denning say the other day, you don't see the customer in the org chart. And that's actually quite an insightful observation I found. And then of course we end with some of the work practices. So, good old quote from Einstein. Who here has heard of TEAL organizations? TEAL organizations. Seriously, only two of you? Two people have heard of TEAL. Okay, let me start at the beginning. So, I could spend 45 minutes talking about TEAL. There is controversy around the model. It's not perfect. It's a metaphor. But as a metaphor, I find it quite seductive and quite appealing to understand. Now, can everyone see this board? Yep. All right. Putting aside the pre-organizational levels, organizations at the dawn of time, when organizations and tribal organizations started to emerge, we would class them as red organizations. These are not hierarchical in the sense of an organization that you might think of. But these are organizations with a very, very clear leader. There is no second level. Everybody reports to the leader. In today's world, we see this in gangs. We see this in cults. And I include some startups in that definition of cult because there are some cults in the startup world. But this is a very, by definition, flat, but not empowered organization. All right? Highly rigorous, ruled in many cases by fear, but not necessarily by a shared sense of purpose. Over time, organizations grew. And we enter into the world of AMBA. Now, an AMBA organization is what you might consider to be a hierarchy from three centuries ago. A very good example is the Catholic Church. Its predominant metaphor is the pyramid. A leader and layers below that leader. Okay? Does that make sense? All right? The Catholic Church, all right? You've got, or in fact, old organizations. You've got a leader at top. They have subordinates who have subordinates who have subordinates. All right? There is no, the chain of command is sacrosanct. There is no going across. You go up, across, and back down. All right? I'm sure some of you have experienced these organizations as well. After AMBA comes Orange. An orange organization is the predominant metaphor for organization design today. It is still a pyramid. It is still a hierarchy. A leader, a leader with subordinates, subordinates with subordinates. But the difference here is we introduce the matrix. Horizontal functions, capabilities, projects that emerge. How many of you have more than one boss? Yes. All right? Welcome to the world of the orange organization. All right? No. I work for IBM. I'm as orange as it gets. I hope that is not recording. So an orange, and I should actually note at this point that there's no moral judgment assigned to these levels. This is not saying that orange is better than AMBA, that AMBA is better than red. It's also not saying that your entire organization is of one classification. All right? There may be pockets of red, pockets of AMBA, pockets of teal in an otherwise predominantly orange organization. All right? So this is not a hierarchy. This is not a one is better than the other. This is the traditional, this is the model we have today. All right? But in the last few decades, two additional models have started to emerge. Green and teal. Now these are what we would class as agile organization structures. A green organization is one where the pyramid still exists. The hierarchy still exists, but it's upside down. All right? This is about empowerment. This is about servant leadership. This is about the CEO is not at the top of the hierarchy, but at the bottom. They're the chief enabling officer. And in La Lou's book, when he talks about this in reinventing organizations, he goes into a lot of detail about where green organizations are emerging in the world today and the kinds of behaviors that force them to emerge. And they emerge coming out of markets, markets that are very dynamic, markets where individual from a recruitment standpoint, we want a higher, really great talent. And these are emerging trends. All right? Now, anyone here think they work in a green organization with a servant leader? Oh, I'm so sorry. Okay, well, your job after this is to start working on your organization to become one of these. Okay? Now, teal. Teal is interesting. Oh, who here has heard of the Spotify model? Yeah, Spotify would be a green-ish kind of organization structure for those of you familiar with the structure. Teal. Teal is, it breaks the model. It breaks the metaphor. Teal is no longer about the pyramid. It's no longer about a hierarchy. A teal organization is often described as a network or a nodal organization where individual teams or individual individuals sit together, work together, but they have contracts between one another. So I will, I have a contract with you, a social contract, not because you're my boss, but because you are, you need something that I do or I need something that you do. And so we, as mature adults, agree to that relationship. That emerges. And this is an organization structure that is never printed on paper because those relationships will change over time and, in many cases, quite dramatically. Now, you might think this is a whole bunch of consultants talking about some great ideas that they're trying to sell, because let's face it, consultants like selling restructures. It's kind of what we do. But that's not the point here. The point is that these teal organizations tend to be self, they tend to be emergent organizations rather than structured organizations. You can't do a restructure and create a teal organization, or at least not effectively. Now, teal has also been around for decades. There's a company in the US called Morningstar, and in the recent conference in America that we were at, we had Doug Kirkpatrick coming to talk about his experiences with Morningstar over the last 20 years. This is a tomato processing factory. It is as blue-collar as it gets. Raw tomatoes go in at one end and tin tomatoes come out at the other end. There are no managers. There's an owner, all right? But there are no managers. 4,000 employees deciding what plant equipment to upgrade, what they're going to do that day based on fairly strict relationships and agreements upstream and downstream. Another example of a teal model would be Helocracy, which you may have heard from Zappos, who have now since gone away from Helocracy, but that's another model of a teal organization. So how many of you think your organization can't become green or teal? Mix? All right, all right. Why not? How large? I work for IBM, so 400,000. We're talking the same language. Okay, you just mentioned a number of different words, which I'm going to pull apart, all right? Process, organization, all right? Size, all right? Let me come back to this at the back there. Why not? I will come to that because that's actually critical. In fact, that's actually an entire section of this talk. Clarity of purpose. Okay, so let me address some of these concerns because those are common and in a few cases, missing the point. Alignment? That's clarity, purpose, vision, alignment. Hang on. I'll come back to some more questions in a second. Let me just, what's on the board already? So, personal question to the audience. Who here has children? Almost all of you. Excellent. Did you have a process for that? No. Did anyone other than your parents tell you what to do? No? Okay, did you listen to them? Did you listen to them? They may have told you what to do, but did you listen to them? Okay. No. Now, tell me, you're raising a child. You're buying a house, all right? Is what you do at work more important, riskier, or in any way more meaningful than raising a child? With a greater impact to the rest of the world. So, if we can let you raise a child without telling you what to do, there we go. Nobody tells you what to do. Sorry, nobody lets you. You just do it. Thank you very much. So, there's a common vision. Come back to that one. Actually, I've seen some families. No common vision there. Well, you do what needs to be done. All right? And that's the point. We are mature. You have a child. You have obligations to that child. You do what needs to be done. No one tells you what to do. You might read a few books, and you might try and do a better job. You might look to other parents and go, hey, that's a good idea. I might try that. All right? The whole balance bike idea. All right? But no one tells you. So, why do you need to be told in the office? I hire you for a job. I give you an outcome. Now, I'm talking green, not teal here, specifically, because I'm still a boss. I give you an outcome. I say, your job is to achieve 7% sales growth, is to develop these features, is to whatever. It doesn't really matter. Now, a good leader is one who will not tell you what to do. No, they will not tell you what to do or how to do it. They will delegate the outcome. I need this business result. It is up to you, because I trust you as a good parent, to figure out the best way of doing it. I also expect you to come to me if you need help or to go to your peers. Teal takes that a little bit further. One second. Teal takes that a little bit further. And it's not about me as a manager telling you what to do. That's not my job anymore, because, well, you don't have a manager. You are hired by the organization as an entity. The organization has a mission. The organization has a purpose. That never goes away. In fact, that is stronger in a teal organization than in any other form, because I can be an amber organization and I don't have to give a damn why I'm there. I get a paycheck. I get to go home who cares why I'm doing what I'm doing. I'm not fulfilled. I'm not necessarily happy at my job, but I don't need to care. A teal organization, I'm not hired by a manager. I'm hired by a group. A network, a subset of the network identify that they need a new person, someone to achieve a particular set of goals. So they choose to put the job ad out. They choose to go, we're going to spend some of the funds that we as an organization have, hire this new person, and as they come in, we're going to agree as part of the recruitment process certain relationships up front. You are hired not for a job, but to align to a mission. And if three days after you join, you decide that there's a better way of achieving your mission, that this relationship is actually not right and in fact you've got to work with this person over here, then that's your job, whether you're a parent or an employee, to make that decision. Process. Okay. Why does process get created in most organizations? Yes. Communicate the vision is also, you're thinking about it, orange. I come up with the vision and I communicate the vision. I tell you what the vision is and you buy into it. Teal is emergent. The vision, as the organization grows, the vision and the mission of the organization is going to evolve and emerge over time. And as new people come in, as a new child is born into your organization, as a new child is born into your family, the family dynamics change. As a new person is hired into your organization, into a subset of the organization, the dynamics of that will change. And the purpose, whilst the meta-purpose will probably remain more or less the same, a tomato processing factory is not suddenly going to start producing aeroplanes. That's no one who's been hired is aligned to that mission. But maybe they start buying plums and creating some other plum source because the machinery's there and they see an opportunity. I don't need a manager to tell me to do that. I identify an opportunity and I keep moving, so I'll come back to you in a sec. So, process. Process emerges in most organizations because somebody makes a mistake. Right? Notting. Somebody stuffs up. Now, what does this mean? It means that a server was brought down. It means a bug went out to the client. Somebody got yelled at by somebody else. And so, in order to make sure that never happens again, who's heard those words again? Who's heard those words? Make sure that never happens again. Yeah? In order to make sure that never happens again, we create process. And process begets. Process begets. Process. And so on until you have a bureaucracy. Until you have an organization where it is possible to succeed and not actually succeed. Right? How many people have failed, but it's okay because I did my job or I followed the process? Just me? I have. It is organizations that make the process the reason for existing. Now, there's another reason for process as well. It's not just about risk and failure. It's also about control. It's also about understanding. So, done bars number. 150. I hope I'm saying that right. This is the size of a community that you can hold in your head. Your organization. You've got an organization of 35. Congratulations. I'm assuming you know everyone's name. I hope so. Do you know their wives and their children's names? Most of them. Excellent. All right. Perfect. Now, your organization. 100,000 people. One of your. Do you know everyone's name? No. Do you even know what they do? But if someone says they're a project manager, do you know what they do? Yes. Because I don't need to know who you are. I don't in fact care who you are. But you tell me you're a project manager and I know that you follow process Z475 project management. And great. I know how you plug in to the organization. But where's the agility? Where's the ability to adapt when the market changes? The process gives us control. The process gives us confidence and reduces risk. But it reduces any possibility of agility. The more process and the more control you have over that process, the less you can do. The less you can be agile. I actually don't recommend the network organization. The majority of organizations in the world today cannot and should not go teal. They do not have the maturity and they do not have the cultural mindsets, the heart to go that way. And I recommend you reinventing organizations by Frederick Delu because he says it much better than I can. But it really comes down to the leadership of that organization. You bring in a different leader and it all goes away. It's not bottom up. As much as we from the agile community think developers can change the world, it takes one senior leader change to break everything. And I think we've all seen this in our own agile transformations as well. Where agile has come in, I'm so sorry, you look in pain. That's a personal experience I can see. A new leader comes in and all the hard work and they have a different opinion, a different approach and thousands of people suddenly change the way they work because of the way they're all the leader. So in a teal organization the leadership is critical and at this point in time 99% of companies cannot and should not go teal. Green, I would like to see a large percentage of the world go green. But to be honest, other companies won't. There's also going to be pockets. IBM is a very large organization, 400,000 people-ish, give or take, 50,000. It's a predominantly orange organization. There are pockets of green. There are probably pockets of teal in there as well. Relationships that merge and divisions that have very enlightened leaders. And there's also going to be pockets of red where a division is ruled by fear. And that's going to exist. So a lot of what we have here is a set of classifications of how we think about organizations, not what should be. It's not a you go from red to amber to orange to green to teal. It's not a flow, it's not a hierarchy, it's not a roadmap. It's not a five-step plan to a more profitable organization. So, yes. So, okay, so you're saying it's about goals and how do we achieve those goals? Hold that thought, so we'll address it. Okay? So, I have, there it is. Oh, size, 100,000 people might be hard to go teal, to be honest. The biggest reference case I've seen is about 5,000 people. My own personal experience around agile and agility and have I just run out of time? Sorry, there's some clapping. Not long, though. And the whole point of agility is to inspect and adapt at an organizational level. So it doesn't really matter what this is going to end up within your organization. As long as there's the ability to change, as long as the organization has an agile mindset, then you can thrive, then you can survive. Any other questions on this? You don't have to. So because, so I just want to leave you with this slide. Leadership is critical, not management. Leadership. Now what does that mean? It means inspiring purpose. It means setting them up for success. It means removing impediments. It means getting everyone aligned to a common goal. Now whether the leader is from the owner of the teleorganization or from the servant leader in a green or for that matter the CEO of an orange, it doesn't matter. The key and the very key point is that as a leader, you are trying to build an agile organization. If a new leader comes in and says, I don't want an agile organization, you have two choices. What are they? If you're their boss, you can do that. So there's a quote that I like. Change your organization or change your organization. It really comes down to that. If you have a leader that you cannot work with, find an organization and a leader that you can. It's not always as simple as that because there are markets and you have families and decisions to make, but the point of empowerment is the choice to be able to leave. So I will leave you with two final points. How much time do I have left? Five minutes? So I will leave you with two final points. Point number one. There's a quote which I love also by Frederick Lalu who if you haven't guessed is actually one of my favorite authors. He writes, profit is like air. You need to breathe to live, but you don't live to breathe. Now the reason I like that is because of this. The goals. And I have a talk tomorrow on designing outcomes, designing goals for organizations. So come along to that if you actually want to figure out how to do them properly. If we create an organizational outcome, then if my organizational outcome is profit, then I've completely lost sight of why we're in business. It's pointless. I'm not in business to make money. I'm in business to make widgets. I'm in business to heal the sick. I'm in business to provide educational services. That's why I'm in business. I need money to survive. I need money to grow. I need to be profitable, otherwise I'm going to die. But that's not why we're in business. The purpose of life is not to live. Otherwise we spend every minute in a doctor's surgery. It's not about living as long as possible. It's about living as well as possible. And so we make choices. We take risks. So the goal is not that. The goal, who is your customer? Go to Joshua's earlier talk. Who is the customer? Where is the customer? Where is the customer on your org chart? Where's the customer here? Is there a customer here? No? Here? No? Orange? No? Green? Even though in the green org structure, do we really define the role of a customer in the structure? They're out here. They're separate, too, apart from the organization. A teal organization does build in the customer. They have relationships and responsibilities according to the agreements that emerge. But 99% of you will never work in a teal organization. Green at best. But if you're going to define your organizational outcomes and align the goals, it's not profit. It's the value. Profit is air. You need it to breathe, not to live. Okay, final point. Sorry. I get very excited about that topic. So the final point is also about the customer. They have to be on board this journey. If you do not have a customer who wants to work in an agile way at an organizational level, and your customers can be internal, not necessarily external, this is true whether think about the constraints. I open up the middle. Software, great. We're agile. Finance, sorry, we're not agile. Deployment, sorry, we're not agile. IT can be as agile as the hell it wants, but it's going to be constrained. So you need to help these downstream, upstream customers of yours, external or internal, to be agile, to have that concept of business agility. Otherwise, nothing that we talk about over the next four days is going to help your organization beyond getting to a baseline of agility. If you're already as agile as your finance department, then yes, you can iterate to your heart's content, but you're not agile. You need to help them. You need to help finance, HR, sales, marketing, your customers, your users. You have to help them to think in an agile way as well. Not so much your users and customers, because they're already agile. They'll go somewhere else in a heartbeat. All right. Thank you very much. My time is up. I'll hang around here for a bit longer. So if you have questions, feel free to come up and talk. I will put the slides up, but please note, the talk is very different to the intended talk. I basically went into a very introductory concept of agile design, org design. So the slides cover a lot more detail, which I'm happy to talk about to your heart's content over the next two days. I'll leave tomorrow. All right, thank you very much.