Daniel Mezick
Transcript
Okay, so welcome. Thank you for being here today.
We're starting a little late. It's about 4.05, right? So the topic of my talk is inviting leadership. So the reason why I'm here is to help you and serve you and challenge your thinking. So that's what I hope to do in the next 45 minutes. I also hope to open it up for questions in the last 10 minutes. And if there's no questions, we'll just finish early. But if there's lots of questions, you'll get to ask them, okay? All right, so is that fair? All right, so a whole bunch of people that are going to come in later, they're going to miss the train. The train's leaving the station, okay? So here we go. Going once, going twice. Here we go. All right, so this is a mountain. Mountains look very nice. It takes very long, you know, they're very beautiful, very nice to look at, and very difficult to get to the top of, right? So agile transformations are a lot like that. They look really nice, they look very idealistic, however, it's very difficult to get to the top of the mountain. Is that fair? Yeah? All right, it's not as easy as it looks is what I mean, right? Okay, so here's who I am, right? So I've been coaching for 10 years. I've written a couple books. I know a couple things, but the ratio of what can be known to what is known is almost infinite in size, right? So I don't claim to know very much. I know a couple of things, okay? All right, so I wrote this book called The Open Space Agility Handbook. It's outside. We're going to give away a couple of copies at the end. And everyone who's here, if you want to get on my list, I will give you the Kindle edition of this book. I will send it to you by email. Okay, I'll send you the link. If you want it, you have to sign up for my list. So you're invited to sign up for my list. Please come to the front. Okay, so that's what this is.
I have been party to over 40 attempts at agile transformation in the United States of America.
It hasn't always been fun.
I don't think we really got any transformations. We got transformations. People in a zombie state. People, you know, sort of disengaged, okay? So this is what I'm talking about. This is what happens a lot of times. We literally paint a very rosy picture of something that is not pretty.
I put these lessons on the web, Agile Coaching Lessons. If you Google Agile Coaching Lessons, you'll see my lessons on the web. They're free to the world. Just go and enjoy them, okay? I'm not here to sell you anything.
So what does it take for a real good work environment? People need a sense of control, a sense of belonging, and a sense of progress. Without these things, you feel depressed. If you go to work and you have a low sense of control, a low sense of belonging, a low sense of progress, That's the same as being depressed.
That's what depression is, right? So I'm sure people, you've all been in jobs you didn't like, hopefully. How many people, let's find out, how many people here are lean agile coaches?
Okay, how many people here are executives who make decisions inside an organization? Okay, a couple of people. How many people? People here convene meetings at work. You can call a meeting at work. Okay, some people. Okay, all right, so let's go.
So this is also what it looks like, you know, more of everything we're looking for, things that are good, like revenue, morale, you know, your career advancement, all these things are supposed to be good, right? All right, so how do we actually get there? How do we get there?
What's actually in the way? Because there's always something in the way, isn't there? Yeah.
What has to be removed that's in the way for us to actually be able to say that we have a legitimate, agile transition, lean transformation happening? Those of you that are coming in, please come to the front. I'm inviting you to come to the front if you want. You don't have to, but it would be great if you come a little bit closer.
I'm not going to hurt you, but I am going to challenge you. So let's go and do that.
So in the Agile community, the so-called thought leaders talk in platitudes. Platitudes. So platitudes sound good. They look like that mountain, but there's no guidance on how to get there. Okay? A platitude is a remark or a statement that's been said so many times that it's actually not useful. You know what I mean?
Yeah? Okay, so here's a platitude. When platitudes are expressed in Agile, we express the platitude and then there's no guidance on what the obstacles are or how to get rid of them. Have you ever seen that at conferences? They talk about how beautiful everything is, but they offer no guidance. These are the thought leaders that we follow. These are our fearless leaders who talk in platitudes. Let's look at some actual platitudes. Here's one.
You would like to hear some platitudes? These are right out of the marketplace, things that agile thought leaders actually say. Ready?
Executives should empower employees so they can do great work. What's the problem with this? There's no guidance. See it? It sounds good. Doesn't it sound good when I say it? It makes me look good, but I'm not offering you anything. See? Here's another one. This is an actual quote. Teams should be able to do their own planning, make their own commitments, and organize your own work. This is a platitude. This is not actionable. Do you understand? It's useless. It's not helpful.
Platitudes aren't actionable, they sound good, they don't identify the obstacles or how to get rid of them. We will not be dealing in platitudes today.
Here's what's going to happen in this presentation. I want to establish with you what needs to happen and then give you the actual steps to make it happen. Okay? Is that fair? Okay, here we go. I'm going to speed up now, right? Let's speed up. All right. Here's a real thought leader, Peter Block. Anyone heard of Peter Block? Peter Block. The Structure of Belonging. It's a great book on community. Here's what he says. Transformation occurs through choice, not mandate. Choice, not mandate. How many people here are participating in a mandated, imposed... Forced agile adoption where everyone has to do it.
Yeah? Okay, how many people are in a completely invitational space where they don't have to do it if they don't want to? Is there anyone here who's involved in an agile transformation that they don't have to participate in? Show of hands. People who don't have to participate. Do not have to participate. There's one person here who doesn't have to participate. There's about 40 people in the room. So that's one out of 40. That's about 2.5%. That means that... 98.5% of the agile that's represented in this room is forced. Fair? Okay, please come to the front of the room if you want to be, you don't have to, but I'm asking you to come to the front, okay? All right. This is what he says. Transformation occurs through choice, not mandate.
Here's another. Here's what Martin Fowler says. Who knows who Martin Fowler is? Martin Fowler is the signatory of the Agile Manifesto, okay? Here's what he says. Imposing an Agile process from the outside strips the team of self-determination that is at the heart of Agile thinking. In other words, imposing is wrong. This is an Agile Manifesto signatory, not some guy. It's a real, real thought leader, okay? Here's another one. Imposing Agile methods introduces a conflict with the values and principles that underlie Agile. In other words, if you're imposing Agile, you are in conflict with Agile principles.
Here's another one. Transformations cannot be accomplished without others helping voluntarily. And people don't help unless you engage them first. You cannot engage people with imposition. That doesn't work.
So why bother with lean or Kanban? Why even do it?
Why bother?
Anyone want to give me one reason? Like, why bother with Kanban? In service to what?
Purpose, okay.
Anyone else? Like, why do we do it?
To deliver more effectively. Yeah, that sounds fair. Does everyone agree? Yeah? Who doesn't agree with what this gentleman said? To deliver more effectively. That's the reason we do Kanban. Is there any other reason to do it?
Probably not, because we want measurable improvement, measurable results. Is that fair? Is that the reason why we want to do it? How are we going to do this? The primary way to get the results, I think, well, there's one thing I need to say right before we go any further. I need you to pretend that everything I say is true.
I mean, just for now, I want you to act as if everything I say is true. I want you to suspend your disbelief, okay? Just for one hour or 40 minutes, okay? That's it. I think, is that fair? How many people are willing to pretend that everything I say is true?
How many people do not agree?
All right, what would it take to get you in?
What would have to change?
All right, we're not going to get everyone in, but we've got most of the people in. If you pretend that what I say is true, I can accelerate your learning, okay? But if you don't want to pretend, then we can have a debate at the end, because we'll open it up to questions, okay? So, how do we get measurable improvement? I believe that it comes through self-management. Self-management is how we get most of the improvement. In Kanban, who creates the board? The team. In Kanban, who moves the tickets across the thing? The team. The team is self-managing. They're managing their own work. They decide what columns, what rows, what tickets, right? That's self-management. So self-management is how we get results. How do we get self-management? Well, nobody who's self-managed is disengaged. So I think we need engaged people if we're going to have self-management. People have to be actively involved. Fair? Yeah? Okay, so how do we get more engagement? I think the way you get more engagement is by putting people on decisions, because decisions are very engaging. If I'm not making decisions, it's likely that I'm going to be disengaged, because if others make decisions for me, what do I have to be engaged for? Everyone else is making decisions. Why do I even care? I'll just do what they tell me. So I think when you put people on, give them an opportunity to decide that this is very engaging.
Does that sound good? Does that sound fair? It's a platitude, by the way. I haven't offered you any guidance at all yet.
And I think the primary way to get decisions is by inviting people to engage. Inviting people requires them to decide yes or no. So every decision, every invitation creates a decision point.
Does that sound fair? Okay, so the real question is, why aren't we inviting people if the reality is that it goes like this? Invitation generates decisions, decisions generate engagement, engagement generates self-management, and self-management generates results. Apparently, if we start with invitations, indirectly we're going to get great results, if you believe this is true. Now, some of you are willing to suspend your disbelief and pretend that everything I say is true. Others have been unwilling, and that's okay. Let's keep going.
Inviting over imposing, this idea of inviting leadership, we're going to invite.
Agile practices we're going to invite, agile mindset, we are not going to try to impose agile mindset. We know that imposing does not actually work. If you go around the industry, about one attempt in seven or eight are actually lasting and genuine. And you who do this work know exactly what I'm talking about. Who has been involved in Agile for more than nine years? Okay, five years. More than five. More than three years. Okay, so if you've been involved in Agile more than two years, raise your hand. Two years or more. All right, so there's a lot of new... people here. Okay, so you people who are new, I don't know if anybody told you yet, but most Agile adoptions do not work.
I'm sorry to be the messenger, so please don't hurt me. But this is the reality, okay? So the first step, this is where we get out of the platitude zone, okay? Now you're going to get actionable guidance. If you want a real agile adoption, you need to start with educating the leaders in how imposing doesn't work. Because it kills engagement. And engagement is the name of the game.
So we need to educate the leaders, and then the leaders need to invite everyone else into the process. This is how it actually works. I know this from direct experience. I've been at this for over 10 years, almost 11 years. Okay? I'm not making stuff up. Sorry to be the messenger, so please don't hurt me, but this is the reality, okay? So, the first step, and this is where we get out of the platitude zone, okay? Now you're going to get actionable guidance. If you want a real agile adoption, you need to start with educating the leaders in how imposing doesn't work. Because it kills engagement. And engagement is the name of the game.
So we need to educate the leaders, and then the leaders need to invite everyone else into the process. This is how it actually works. I know this from direct experience. I've been at this for over 10 years, almost 11 years. Okay? I'm not making stuff up.
So if you're going to really have a true agile change, here's what's going to change. The way authority is distributed and how decisions are made is going to change. How many people here have ever heard someone say, we did agile, we tried agile, but... Nothing really changed. How many people have ever heard that? Okay, so here's my translation.
We did Agile, but the way decisions are made didn't change.
That's what's really going on. The way decisions were made didn't change.
That's, if you're going to do real Agile, if the Agile is real, the way decisions are made changes. Different people make decisions in service to the work. Okay, that's what actually happens.
You need both top-down management, top-down authorization, and bottom-up engagement. You cannot just have one. You need both. If you have one or the other, it does not work. So you can pretend that we can get the leaders on board and that they will authorize Agile Lean Kanban. That's not good enough. You need the people to engage for this to actually work. So the real question is, how will you do this?
Invitation is what gets you there. Invitation gets in your head. When you're invited, you think, if I do not attend, what will I miss? If I do say yes, what will I learn? Should I say yes? Should I say no? Should I stay? Should I go? When I invite you, I get in your head and you think. Yes or no? It's called mind share. I get mind share. I get some of your mind. When I invite you. If you invite me, you get some of my mind. Because I have to think, oh, what if I miss? It's tomorrow. Should I go to the party, not go to the party? Should I go to the dinner, not go to the dinner? I don't know. I don't know.
What are you going to do? Are you going to go? You know, that's what happens. Okay? Invitation. Leaders must figure this out.
You must teach them. There's nobody else that's going to be able to do it. How many people here are coaches? You must teach them or they'll never learn it.
They are ignorant now. These very well-meaning executives have no idea. About invitation and the relationship with engagement and results and how imposing does not work. They don't understand. It's your job, it's our job to teach them. We're teachers. We're supposed to challenge the thinking of people in service to helping them. We must teach them.
Teaching them means you need to teach them that the way authority is distributed is going to change. That's a difficult message to deliver, but it's a message we must deliver.
Now I want to talk about these four things, right? Authority distribution I just discussed. Now let's talk about agreements, experiments, self-management, and inviting leadership. Inviting leadership, two ways. Inviting as an adjective. It's leadership that's inviting. That's one definition. And then there's also inviting as a verb. Right? So we are going to invite emergent leadership. So I'm a C-level person. I'm a person who's a CTO or a CEO. I'm going to invite others to come in and lead, emergent leaders. That's the other way to think of it, okay?
All right. What is agile software development? It's all about people, isn't it? Okay. All right. It's all about people.
People get worried. Here's a list of people who get worried. Managers, architects, executives, team members, they all get nervous when you bring a change.
Here's what they're nervous about. The way decisions are made is going to change. Some people are going to win and others are going to feel like they are losing. They will be afraid and they will block you. If you do not engage them, they will block.
Managers and directors who have direct reports are happy with the way things are. Yeah? Yeah, they're happy. And if you report to them, you better be happy too. Because they have your performance review, don't they? And if they send you the signal that they don't like this Agile, you better not like it either. You see how the whole thing can just be completely destroyed by people who block.
DevOps. Developers can now push to production. Hey, I have a question for you. What do we need all that authority and quality assurance for now? If in DevOps we have such great rigorous testing that developers can push to production every single day,
What do we need a QA department for anymore? Testers are on the teams. The teams push the production. QA is outdated. The way authorities distributed has to change. Developers never pushed the production before DevOps. Now they do it 10 times a day.
If you're blocking that, you will never get the benefits of DevOps because you never change the way decisions were made about push to production. See it?
So DevOps requires you to change the way decisions are made. Specifically, to authorize developers to push code to production. That is a dramatic change in authority, authorization, and decision making.
Executives need to understand this is not a threat. This is in service to the organization being better off, not worse off. We're going to teach them how to make a trade, how to trade one unit of authority for a hundred units of engagement and great results in a controlled way. DevOps being an obvious example of what I'm talking about. Okay? All right. You need to teach this. If you're a coach, you need to teach this. You will not get a transformation if the leaders do not understand what's about to happen.
Changing around authority is very difficult.
If you don't change it, you will not get any change. Agile change is change in who gets to make decisions. That's what it is. Okay?
Empiricism is learning by experience. We got to do a little, learn a little, we go again, right? Do a little, learn a little, go again. That's agile, right? Okay. Learning by experience is great, isn't it? Isn't learning by experience great? Because agile is great, empiricism is great, isn't it? Yeah.
Then how come
We do not do the transformation in stages as an experiment to be inspected. How come it's always assess, train, coach? That's ABC. That's waterfall.
That's Waterfall. We're using Waterfall to install Agile.
Isn't that funny?
I mean, it's a cruel kind of joke, isn't it? Yeah, it is.
Now, we're not going to do this exercise because we don't have time, but ask yourself, is the implementation of Agile at my company an experiment to be inspected, or is it a forced march to Agile until further notice? Which is it? Just take a moment and think about it. Go ahead. Let's do the exercise. Take a minute. Turn to the person next to you and answer the question. Is it a prescriptive directive or is it an experiment? Go ahead. Take a minute. Talk to somebody about it.
All right, one more minute.
All right, you have to kind of wrap it up now.
All right, so let's wrap it up now.
Now let's talk about self-management. Self-management. What is self-management? We hear about self-organization, self-organizations in the Agile Manifesto. We know from the Agile Manifesto that everything good comes from self-organizing teams, right? All right, what is this? So flocks of birds self-organize.
Right? Schools of fish self-organize. Mobs of human beings self-organize. Crowds of human beings self-organize. That's not what I'm talking about.
I think when we say self-organizing in the agile world, what we really, really mean is when we assemble as a team in the pursuit of a goal, we are self-managed. We manage ourselves. That's what we mean when we say self-organization. So when I hear self-organization, I think self-management of the team.
I want you to start to think that. And remember I just told you, I want you to pretend that everything I say is true. I want you to believe self-organization in the Agile world equals self-management. Okay? So what is self-management? What are they managing?
I have a hypothesis. Here's what I think they're managing. I think they're managing decisions that affect the whole team. That's managing. Self-management is the management of decisions that affect the group. So here, let's do an experiment. Who here speaks English? All right, this fellow speaks English. Hi. Hi, I'm Daniel.
I'm Matthew.
Hi, Matthew. Yes, Matthew. You work on a team? Yeah. Okay, how does your team make decisions?
We actually, I don't know, we talk about it together and try to figure out the best solution.
We talk about it together. We try to figure out the best solution.
And sometimes we vote.
Are there other people here on your team?
I don't think so, no.
Okay, so is there someone else who speaks English over here?
Who wants to answer the question? All of a sudden, nobody speaks English. That's very funny. I like that. Oh, that's an English-speaking man. Hi, I'm Daniel.
Hi. Hi, Daniel. I'm Dragos.
Hey, Dragos. How do you make, how does you, do you work on a team, Dragos?
I'm working with teams, yeah.
How does the team that does the Kanban conference, you're on a team, you're running the conference, right? Yeah. How does the team make decisions?
We're using something like a device process. We take a job to be done, we propose a solution, we consult with the others, and if there's no veto, we go for it.
All right, so what Drago's just defined to me, you couldn't hear it because of the microphone, is a very clear process for decision making. So if I want to find out whether the team that does the Lean Kanban Conference is self-managing, I could go outside and ask the same question to someone who's on Drago's team, and if I get the same answer, I know they're self-managing. If I get a different answer, I know they are not. So as homework, I want you to go to your teams, ask your teams, hey, how does a team make decisions? Ask one person at lunch, ask another person. in the hallway, ask another person at coffee, and if you get the same answer, they are truly self-managing. If you get a different answer from each person, they are not, because self-management is the management of decisions that affect the whole team. Decisions trigger a lot of engagement, so self-managed teams are deeply engaged in the process of working because they're all involved in decision-making. About the work itself.
That is triggered through invitation. So invitation triggers decisions, decisions trigger self-management of decisions, and so forth and so on. Okay, so an invitation requires a decision, it's a yes or a no. It's a very powerful technique for getting good results. Also a very good way to be in the world. How many people here never force anyone to do anything?
Ever.
Okay, so for homework, I want you to go and invite people to coffee. Invite people to a beer. Invite people to do some work. Don't be so quick to tell them. Ask them instead. So, invitation triggers decisions, decisions trigger self-management of decisions, and so forth and so on. Okay, so an invitation requires a decision, it's a yes or a no, it's a very powerful technique for getting good results. Also a very good way to be in the world. How many people here never force anyone to do anything? Ever.
Okay, so for homework, I want you to go and invite people to coffee. Invite people to a beer. Invite people to do some work. Don't be so quick to tell them. Ask them instead.
Engagement is a very big deal. We are not going to do this exercise, but for homework, I want you to go back to your place where you work and ask the folks if they are willing to make even one meeting optional to attend. One meeting, just one meeting optional to attend. Go to the executive, ask them, would you make a meeting optional to attend? So people don't have to go to it unless they feel it's valuable.
The first thing they're going to ask you is, what if nobody comes to my meeting?
And the answer is, maybe they were never there.
Fair? Okay. All right.
Inviting leaders can manifest epic levels of engagement the other kind don't. Now here's exactly what you can do starting tomorrow.
The first thing to do is go first. Whatever they're asking the teams to do, you're going to ask them to do. So if the group is going to a lean Kanban stance, and the executives are mandating that, I want you to ask the leaders to use a Kanban board for their leadership work.
And you might be very surprised at how unwilling they are. Oh, that's just for IT. No, it's not actually. It's for everyone.
Second thing, I want you to teach the leaders to phrase everything as experimental and to be inspected. They won't like this.
Executives like a story that goes A, B, C, the end. Chapter 1, chapter 2, chapter 3, the end. This is what they like.
Experiments have three dots at the end.
It's chapter 1, chapter 2, chapter 3, dot, dot, dot. Executives don't like that. However, Agile is about this.
Third thing I want you to do is I want you to go to the executive leaders and ask them if they might be willing to work with just the willing people. Let's talk about pilots for a minute. How many people here have experienced an agile pilot, been part of it as a coach or as a participant? You know, like the beginning. Okay. So in those pilots, usually you work with the willing teams. Why? Because you want to take the risk out of it. That's why. You want to take out the risk of failure. Failure is a risk. So we're going to work with the teams who really want to do this in the pilot. Make sense? All right. Now, what happens is those pilots usually really work out really, really great. I think it has something to do with the willing people, the willing teams, the ones that say yes. Then the pilot is great and the executives say, This is so great. Let's scale it. And then we get organizational amnesia. We forget that it was willing teams. What we need to do is scale willing teams. The unwilling teams will block. The unwilling managers will be obstacles. Unwilling executives, unwilling teams are impediments. We need to identify why. We need to identify. Identify that they're blocking and then ask them what it takes to get them in. Here, let's do another show of hands. How many people are willing to pretend that everything I say is true for the next 20 minutes?
Okay, how many people are not willing to agree that everything I say is true? They're not willing to pretend. Who here is not willing to pretend that everything I say is true? A lot of you didn't raise your hand.
So all the people that didn't raise their hand are the resistors.
I say to you, what does it take to get you in? This is what we have to do in the Agile adoption as well. People resist. What does it take to get you in? Do you want to know a way to identify the resistant people? The resistant teams, the resistant managers, the resistant executives, the people who do not want Agile? I have a really good way of identifying who they are. Do you want me to tell you?
Ask him to agree on a word definition, like the definition of agile.
Try to get him to agree that agile means the 12 principles of the agile manifesto and the four values. All the people who are resistant will go, I don't really want all that. I don't think that definition is very good.
I have trouble with that definition. That can't apply to everybody.
We need a better definition than that. That's someone who's resisting.
So in the Agile community today, if there's, how many people in the room, about 60? There's probably 60 different definitions of Agile in this room.
Everybody has their own. That's a tower of Babel. That means our effort gets lost in translation. If you want to identify who the resistant people are, ask them to agree to something. They will say no.
Those are the resistors.
Fourth thing, executive leaders ask them to start and end the enterprise transition with an all-hands meeting. And now I'm going to really speed up.
All hands meetings generate what's called common knowledge. Common knowledge means you know that I know that you know. When we have one big meeting and everyone gets in one room, we get to hear from everyone, we tap the collective intelligence, we build consensus and agreement. Okay, that's how you do it. Get everyone in one room. How many people here have started an Agile Enterprise adoption by getting everyone who is going to be affected, all the teams, all the stakeholders, all the BAs, all the executives, all the managers, all in one room for at least one day? How many people have experienced that? All right, take a good look around. There's only about five hands up. Keep those hands up. How many people have experienced that? Okay, there's only five people in this room who got everyone in the room for one day before it kicked off. That's really bad.
All hands meetings are great. Use open space. Open space is a meeting people do not have to attend. You invite them.
Everyone sits in a circle. How many people have attended open space of any kind at a conference or anything like that? Wow, not a lot of people. Whoa, less than half. Okay, so open space starts in a circle. You're invited. You don't have to attend the meeting if you don't want to.
There's a theme, some issue, like Agile, how will we ever do it at this company? And then people who care about that issue come to this meeting. The executive invited you. They welcome you to the meeting. They sit down. The facilitator stands up, and they take the people through the process. The process of what? The process of building out an agenda that's going to happen dynamically in the here and now during that meeting, in that time, in that place. It goes up on the wall, A, B, C, D. Those are locations or spaces. And then the columns are spaces and the rows are times. So where there's a time... space, there's a meeting. And that's what those colored papers are in between the blue squares. Okay?
They go into the small sessions, and this is what it looks like. How it works.
Here's another small session with the facilitators. And then there's a newsroom. Meetings are generated from the small sessions. They go into a book, and the book is distributed to everyone as a PDF the next day. It has the actual outcome of the sessions. Who was there? What was said? What was done? What the recommendations are? It becomes the story of the future. The open space meeting is about discussions. The proceedings are about action. The sponsor tells everyone at the beginning of the meeting, we want those proceedings because we intend to act on what's put in the proceedings. This is the people creating the proceedings. And then there's a closing circle. So after all the small sessions are created, we have a closing circle. And people share their reflections. We have a formal closing.
Okay, so how many people in this room have experienced an open space meeting inside an organization with everybody, like the whole enterprise? Show of hands. All right, that's pretty good. Maybe 10 people. That's pretty strong. I like that.
How many people have only experienced open space inside a conference? All right, so the people who have only experienced it at a conference, I'm here to tell you, inside an organization, it's a very different story. An organization is more like a family. And a conference is more like a vacation.
Right? So we have low cohesion. We are not. We're just a group of people for a couple days. But inside an organization, if I go into a session with you, tomorrow I still have to face you. You know, after this conference is over, we part ways, right? Totally different.
All right.
All right, so I have developed something called open space agility. It begins and ends in open space. 45 to 90 days. Start in open space, do experiments for 45 to 90 days, end in open space. The whole enterprise. Inspect and adapt. Experiment and learn.
Okay?
If we define Agile process with, you know, if we use waterfall to install Agile, that would be stupid.
I mean, really, it really is dumb.
However, we can just say no to platitudes. We can just say no to imposition. We can just say no to bad thought leadership. And we can just say no to stupid frameworks. Because we really don't need them. We have everything we need. We just have to say yes. And I think that would be really smart. And that's what I'm asking you to consider doing. So, here's how it looks. You start in open space. Everyone's invited. There's planning. You start in open space. All the people are invited. The people who really want to be there show up. Proceedings are generated, and then we go through 45 to 90 days of experimentation as the whole group. The leader stands up in the first open space, this one right here, and they say, we are going to do experiments right through here for 45 to 90 days, and then we're going to inspect that in a retrospective way as a whole company. And if we're using some techniques, we're going to check, inspect those. We're going to discuss them here, and then we're going to go again. 45 to 90 day iterations where you're going to plan, experiment, and learn. That's an agile approach to agile transformation. Here's how that looks a little more formally.
This is on the web at the website openspaceagility.com. You can go there and click this. This is like the safe big picture. You click it, and then there's a page behind it. There's 43 links there. Okay?
So, summing up, leaders go first, frame everything as an experiment, work with the willing people, teach leadership about invitation.
And then I'll go back here because some people wanted to take that picture, right?
Okay? And then I want you to investigate these links. There's a group on Facebook where you can learn, where other people that are doing open space agility, this is the old name, but this is a full link, slash, you know, facebook.com slash groups. The group's name is Open Space, Open Natural Adoption. We do an online open space every month, osacon.com. Go and investigate that. And then my web, danielmezic.com, you can reach me there and all the other links are there. And then Open Space Agility is the place where that picture was, this one here. Okay? That's where you can get the full thing. We're only here for an hour together. That's all we got. So, you know, we're kind of stuck that way. Now, I'm telling you right here, right now, if you sign up for my list, if you go to danielmezic.com, I will give you a Kindle edition of the OSA handbook, okay? And you can reach me at danielmezic.net, or dan at newtechusa.net. And now I want to open it up for some questions. But before I open it up for some questions, I want to raffle off a couple copies of this book. So who was born on October 22nd?
October 22nd. Anybody here born on October 22nd?
All right, how about April 22nd? Who's born on April 22nd? Okay, who's born between June 10 and June 12?
Nobody? What, are you people hatched from eggs? Or how did this work? A test tube, test tube babies. Okay, okay, who was born in July? Okay, okay, okay. Who was born between July 1st and July 4th? All right, come on up here, both of you, please. Come on up here. They're the winners. Let's have polite applause for them.
Congratulations. There you go.