Jan Schilt

We spent hours introducing each other, what we're doing, and now I have to do the next slide.

Right. Well, nice that you all came over to listen to my story, because this story is not about technology. I can repeat a few of the slides of this morning: it's all about people. But in fact, this is all about people. So you will not find any slide about technology, nothing. It's all about people, because that's what we try to focus on with our business simulations that Paul and I developed.

We like to build serious business simulations related to a nice context, a challenging one. So it's always nice to save the crew of Apollo 13. And when they die, then you go home and say, "Yeah, we just killed the crew, but we learned a lot about ITIL and what went wrong, and why we should implement more and learn more about ITIL."

And the same for Challenge of Egypt. Even playing a game like building pyramids out of Lego and learning how to apply PRINCE2 or PMI or Agile Project Management, it's always fun.

So that's what we're doing. A very pragmatic company. We have lovely partners. A few are here in the room, so they hear my story for the twentieth time, and still they're here to learn.

What we are doing means small, relational, fun, professional. We have over 300 partners all over the world, and we run more than 500 workshops in the world. So while we're standing here, people are playing our game. And yesterday I was in Stockholm playing the DevOps game, which was really fun. I should have made pictures of it. But that's what we do.

So we train our partners, then we leave them with the box. We wish them all the best, and they will support their own customers.

So yeah, I think DevOps will fail. So nice you were here, nice you spent your money on all this training and stuff. But if you really listen to the essence of DevOps, then I think it will fail. And one reason is that there is no good culture.

Culture is something that's within the people. It's the attitude of people. The culture is not what you can touch. It's like an iceberg. The thing you can touch is the behavior. That's what I see. I see you now, and you show behavior.

Oh, shit. Oh, the starting time of the presentation. That was my reminder to be here. Perfect.

So this culture is something you cannot touch. It's in the people. And that's why I hate culture-change programs, because you cannot change the culture. You will try to change the attitude of people and try to motivate people so they will start showing new behavior.

So I think we have to do a lot of things to change this culture. And a lack of the right competencies. I will show you later, but we run this workshop now for years, and the competencies of people are terrible. They think they communicate, but they don't. They think they can make decisions, but they don't. So we really need to focus on developing the right culture and the right competencies.

When we started building this business simulation of DevOps, the first thing was a lot of people said, "No, no. No new framework, please, because we are now finishing ITIL, and that's enough for today, okay? Because we will not spoil the people on new frameworks."

And I said, "Wait a minute. Did you read anything about DevOps? Do you really understand what it's all about?"

But as long as people see this as the next framework, then it will go wrong, because they think you can implement DevOps like they thought you can implement ITIL. Okay? So I think it's another reason why it will go wrong.

We focus on tools. So let's buy a tool, let's install it. I saw these pictures this morning. I don't know anything about any of those tools, but if I were an employee in this type of company, I would get crazy. All these tools and pushing buttons and not knowing what's happening. So I think if we still focus on the tool first, then there is a possible risk of failure.

Certificates. If we go the same way as ITIL, where everybody wants certificates on the wall, so building up knowledge and not the skills how to use it, I think DevOps will fail. Because then we end up the same as ITIL. Everybody knows ITIL. We pass the exam: "Look, I got a certificate." But look what's happening. We're still not delivering the right services.

And we think that you can implement DevOps fast. I had the luck to visit Auto Trader in the UK to play our game, and they took seven years to start a journey. And now they are somewhere, and they think they have to go further and further. But it's a real journey. It's something you start.

They even had to change their offices to make the next step, because people were still working in departments and in big rooms and small rooms. So it's not something like, "Okay, let's choose DevOps. Let's hire a consultant, do some training, and tomorrow, yes, we are a DevOps company or team."

And I'm not the only one, because Gartner is saying the same: "Culture resistance will create significant failure rates when starting with DevOps." It's Gartner. It's not me.

CIO: "Organizational change issues are far more challenging than whatever DevOps is."

And The Wall Street Journal: "Enterprises are not ready for DevOps, will not survive without it." It's quite interesting. So it's not me. Well, we know it is because we play around with a lot of departments in the world, and we know what they suffer about.

And this is another one. Adam Bertram said, "DevOps cannot be obtained overnight with a simple check and a little training. It's a transformational approach to core process and takes time, dedication, especially a team that can implement DevOps practice."

And I think this is exactly what it's about. So the self-steering team starts with creating a self-steering team, and not telling them to work as a DevOps team. Say, okay, let's start with a self-steering team.

How do we know? Well, as I said, we run so many simulations, got so much feedback from partners and ourselves. On the other hand, if we look at our experience with Apollo, for example, or other games, the number one is when people are not successful in the game, they say, "Yeah, because unclear roles and responsibilities."

We started at 9:00 in the morning. We thought we knew what a flight director should do, but then halfway through the day, we lost the crew because suddenly we realized that it was not clear.

I said, "Well, congratulations. So you spent half a day doing things, not knowing why and how. So when did you discover?"

"Yeah, 9:00."

"So did you raise a finger and say, 'Hey, I don't understand you?'"

"No."

"Well, good luck with your new culture."

If we don't ask questions, not raise our fingers, then we will not create a culture where it's normal to ask questions. In many companies and countries, it's wrong to ask questions because then you're stupid. So better is not to ask questions and then just try something. And trying is a potential waste.

Lack of management buy-in. We all know these CEOs, and maybe there are a few in the room, that come into a meeting and say, "Yeah, this is all very important. That's why I'm here, and I want to encourage you to listen to our trainer and consultant. And by the way, I wish you all the best, and I go back to a meeting."

And he says, "Yeah, I showed commitment. I was here."

No. Commitment is being part of the team.

Last Monday, we had one customer in Holland, and the CEO invited three people from the business, an architect, a developer, and some other guys. And he said, "Yeah, I hear this rumor and noise that we should do something with DevOps. I saw your workshop coming by and said, now, why don't we play it?"

So he took off his jacket and said, "Where am I?"

And he started with a little anecdote. He said to his team, "We had a seven-year strategy, and we are now where we are. But I believe that the next seven years will not be the same. I don't know what and how and when, but I would like to discover in this workshop how DevOps can help us to develop a new strategy."

So he was just playing a role, and he was writing down all the lessons learned. And if you're interested, I have them on my computer, the lessons learned of this multifunctional team, and I think they cover most of this. But he was in the room. He was the one who was also putting Post-its on the wall and realizing that he should act as a product owner as well in some situations. So he showed real involvement. But that was maybe the first one this year I saw so much involved.

Lack of business focus. I'm not sure what the guy from ING told you, but ING in Holland has another word. They say BizDevOps, because they believe that DevOps should not be the party of IT, but should be a party for all of us.

So more and more, you see that what we learn from other simulations and other companies is that the business should be equally responsible for making projects successful. You can't always blame the project manager. But sometimes it's the customer who should have the blame, or the business. So they should be equally responsible.

And if there is no focus on the business, then things can go wrong, and then we go back in our own little department and cage and try to think on behalf of the customer, which will lead to dramas.

It's still them and us. Because in our simulation, we have a moment where you have to transfer knowledge. Well, Brent is in the game, and Brent needs to share knowledge with IT support. Now in the game, it's a matter of choosing a card. In reflection, I said, "Would you do the same in the real world?"

He said, "No."

"Why not?"

"I will not transfer knowledge to IT support."

"Why?"

"Yeah, they can even make it worse."

So that means that we think that we are a team. But when it comes up to sharing knowledge, then suddenly it's them and us, and then they made a mistake of IT.

Yesterday in Stockholm, we ran two parallel workshops, and there was even a them and us between the two teams. So squad number one supporting one customer, squad number two another customer from the same company. And I brought them together and said, "Now share your knowledge, because this is a terrible solution here, and this is a great solution here. Now try to find out why is this terrible and this better."

And they didn't want to share knowledge. They said, "No, we are competitors now. We want to compete."

So sometimes it's very hard to get rid of this them-and-us thinking, and that's something we need to fix.

No time for doing it right. Okay, so you are under pressure. We need to do it fast.

And no link to people, process, product, and partner, which is from ITIL. So we need to combine the people, the process, the product, and the partner. Everything should be together. More and more partners will deliver services on behalf of us. So I think this morning it came on the slides: how do we integrate a partner or a vendor in this way of thinking?

And communication. It's a nice word, but so difficult.

One thing I would add here is the ability to learn. It's not just the ability to learn, but also the time you get for learning. How many times I've seen, when I was coaching people, that we were in a room laughing at a whiteboard, that the manager came in and said, "Now, back to work."

I said, "This is work. We are learning."

"Yeah, and laughing. Okay, could not be serious."

So we should find time for learning.

Well, I like this definition. Not that I promote DevOps Institute, but I think it's great. It says, "A cultural professional movement." Okay? And it says, "It stresses communication, collaboration, integration between software developers and IT operations professionals."

That's it. Bringing the world together. So that's me. We need to do something with culture, communication, collaboration, integration. That, I think, is a key focus.

So how can we avoid failure? Because you want solutions, okay? So everybody has pens and will write down and make pictures of all the solutions.

Well, first of all, it starts with business awareness. Business awareness is crucial because if the business doesn't know that we are doing DevOps, they will not follow the "procedures," quote, quote.

So in the game, sometimes I am, or the teacher is, playing the customer. And then I know that a team has implemented some kind of DevOps, and I will simply bypass everything because I want a quick solution. And then it's interesting to see how they treat you if you act like the director who is not playing the product owner, who's not posting his Post-it on the wall, but goes straight to IT support or the technoid.

It's interesting to see how people act on this, how they give feedback to the business, or how they train the business that the world is changing when we have a different way of working. So business awareness is one of the key success factors, and playing a game and a simulation is one of the success factors.

Senior IT management experience. Sorry, awareness. Because the IT management should change their way of thinking as well.

In one of the workshops, a guy said, "What about me? Because I'm a team lead."

Yeah, good question. What about the ITIL process manager who's responsible for incident management? Yes, good question. So what's the answer? Discover.

So maybe you have to get rid of all these managers and create teams and have some other types of management skills around. But you have to get the IT management on board. Otherwise, you touch their jobs, and they will still do the old things. While the rest is doing the new way of working, they will simply fall back to the old way of working, try to create silos again, and get people in a room and try to make decisions, and so on.

Focus on people and the attitude, behavior, skills, and communication. So that means we need to work with people. We need to give people feedback. Maybe we have to implement HR systems where we reward people differently.

Everything has an effect. Are any people from Auto Trader here? No? So then I can tell the story.

It's a positive story. But in Vegas, February, they told an excellent story about how they support this part with just a very simple action. What they do every, let's say, month or so, they have a squad together on Skype. Everybody's face was on the screen, and I saw it. And then they give everybody, let's say, £50. And they say, "Now, you can give away the £50 to anyone in the team, but you have to explain why."

So when this 20-minute session takes place, then I can say, "I give you £20 because you helped me yesterday. I give you £30 because yesterday I had a problem with my role, and you helped me to understand it. And I give you £40, and you £60," whatever.

And at the end of this exercise, everybody has shared his money. And then Jonathan, who was the manager there, takes a dice and throws. And if it's a six, then you get the money. If it's not a six, then we had fun.

And of course, it's a crazy way of doing it. But he said it fosters a kind of culture where we not only give feedback during work, but this is a funny moment at the end of the month just to enforce people to think about each other. Okay?

And I think we should find many other ways and ingredients to make people proud, give them the rewards they need to get.

We need to focus on teamwork, and "we" means management as well. So the manager should get lost himself, keep it going, and say, "Okay, I put it back in the team," even if he knows that the answer is very quick maybe, because he can make a decision or he can do something.

But I think managers should say, "Okay, I have a team, so I leave it to the team. Maybe it goes slow in the first few years or months, but I will protect my team towards the people that put pressure on us. I want to give them a fair chance to develop this new way of working, and that needs time."

And those managers who are able to do this, they will be successful, because then the team is allowed to make mistakes. They can learn from this, and step by step, they can do more work.

Well, first process is in behavior and then the tool. A fool with a tool is still a fool. So you should say, "First, let's figure out how do we work?"

Auto Trader told me that they started with Post-its, and now seven years later, they use Trello. They have more than 400 Trello boards. Perfect. It's almost free. It's a great tool. But it starts with understanding how do we work, how do we visualize, and then they search for a tool that fits.

Learning-by-doing culture. Foster learning cycles. A meeting is not just an action list. A meeting is also to get the experiences and have a standard meeting and learn from each other.

Plan time for learning. I wrote a little blog on LinkedIn about continuous learning, and it should be part of a normal culture where we go back to a room and spend, let's say, 20% of our time on reflecting and improving. And that's something we need to implement as well, because it's the key success factor of your DevOps journey.

We need to transfer theory into practice. Oh, yes, if you read a book, perfect. If you go to a conference like this, perfect. If you go to a foundation class, do it. But that's not the problem. The problem is how to get the knowledge from your brains into the live operation. How do we transfer the knowledge?

I've seen a lot of people when I was a teacher in my class who did ITIL Foundation, and I asked them later when I visited them when I did consultancy, I said, "How many of your managers were very excited that you came back after this training and gave you new exercises or asked questions because you had new knowledge?"

Well, zero. Because it's just kind of normal. So what did we do with all the money we spent on training? We need to find a way to transfer knowledge from books, conferences, training, back to the practice. It should solve problems.

And we can't stop the old way of working. The shop needs to stay open. So that means we have to find a way to integrate this new way of working in your company.

And I had this question last Monday, and people said, "Yeah, this looks nice, but..."

And I said, "Okay, now if you know and now understand what it is all about, how can you start?"

And one girl said, "Maybe start with just a small service, with one small team that's not so risky. Let's practice. Let's assign the roles. Let's take some people away from different departments, put them in a room, call them a squad or a team or whatever you give them the name, and try to practice and learn from this. And maybe step by step, we can add more teams and so on and so on."

Yeah, but we can't say, "Let's close the office for a week and let's do it."

And it's a transformation approach. So a transformation means that we expect a warm organization where people can deal with change, where change is a challenge, and that we know where we want to go to. If you have those ingredients, a warm organization and a warm change, then you can use a transformation to move there.

Then you can say, we're going to make steps. We're going to build metrics. We're going to try to reach our objectives and goals, and we will celebrate. But you will do it because you have the skills and the culture in you to do this.

If you don't have a company that's warm, that's cold, then we are using the word implementation. Because then we open something, put something in, close it, and we think it will work. But better is to use a transformational approach.

So we need to do this because we need to train people those skills. And that's a serious game, because a serious game is an interactive workshop that takes a day or two days or whatever, which is based on the learning cycle. We do, reflect, think, and decide. And that's the rhythm of the day, which is the same rhythm as your DevOps teams and your DevOps lifecycle or your DevOps journey.

It's the continuous learning cycle that will go on Monday morning, Tuesday afternoon. And step by step, the whole team becomes a better team. Well, perfect. In a business simulation, you can make mistakes, you have fun, and you can learn how this cycle works.

Not just how it works, but who should facilitate this? Is it a team, or is it a coach, or is it a manager, or whatever kind of role?

It's a group of learners face to face in our situation, okay? So we believe in interactive workshops with people in a room arguing, seeing each other in the eyes, and trying to fix issues.

The actors are all challenged in a realistic context. Now, we are very lucky that we have the rights of The Phoenix Project. So Gene and I, we agreed on the book, that we use it in the game. And so people are acting like Steve and Bill and all the other players. And really, we see the Brents in the team, even how they organize the cards on the table with coffee cups between it and stuff.

So actors are challenged in a realistic environment. So what they do is realistic. They say, "Yeah, it looks like work." If you hear this sound, then it's good.

And we need to focus on specific learning objectives. So we will not train people in things they don't need. That's why we always do intakes and capture their objectives and focus on the objectives. If it's not on the list, we will skip it.

We want to solve day-to-day problems. Because if we know there is a problem in communication, well, we will adjust the game a bit and focus a little bit more on communication. Or maybe the game leader who is playing Steve becomes a tough Steve because nobody communicates to him. And you can teach the people by creating some pain and sometimes reward them. But you are in the lead to help them to discover the right things.

So this is just an impression of the game. This here is the Auto Trader session, and you can see they were quite used to the way of working, because the first thing they did during the day was a standup meeting. And they asked the business to share business objectives and strategies. So it's quite natural.

This is not natural for a team that doesn't know anything about DevOps. They simply go back into the silos. They argue. There is nothing on the Kanban board after one round, and they fail. Which is fun, because then they will learn.

This is not a result of round one, but after a few learning cycles, suddenly they discover that they need to visualize. Well, we simply use Post-its. This is enough, because it's so difficult to agree on the Post-its: where to put them, how to use it, what does it mean?

The test team will say, "Hey, this is great. Now I can test the release packages because they're all nice together." But this is not a result of round one or two. This is the result of round three, where everybody learned that everybody should benefit from visualization. So this is one of the outcomes.

We have dashboards like sales and share price, and KPIs to show the number of deployments and success rates, which are similar to the metrics as we encourage people to create in their own company.

And they all play with laminated cards. If you're interested, I brought the box with me so you can take it in your hands and feel how it is.

So a little bit of background. We have business and IT roles together in the game because they need to work together. And we encourage the customers to put the business and IT together in this exercise, and not just IT, not just the business.

So we will try to bring in what we call the top 10 failures in DevOps. And that was our research when we started the game. We invited a lot of people to share them, and they're all now translated into real issues in the game.

So that's why people feel that this is a realistic environment, because, yeah, it looks like my company. Hey, it looks like my boss. Yes, because we know what's happening currently in the world.

So we reflect, we experiment, and we learn. Sometimes we don't even help the team. We say, "Yeah, you have to do it yourself." Okay?

So become a better team step by step. They have to find their own solutions, and the facilitator or game leader will just help them a little bit because they have to learn how to deal with uncertainty, with the fact that they don't know the answers. They need to reflect on it and try to find solutions themselves.

And at the end of the day, and maybe the debriefing, we will help them to transfer the knowledge back to day-to-day work in terms of coaching and maybe creating their own action list.

Well, just an overview of all the words that I took from the slides and the Post-its when they reflected on the day. So what did you learn? Or what did you remember? Or what were the things we were discussing? And this is just a brief overview of all the words that will come by during the day. And you can imagine that people like to know more about this, and that's the role of the facilitator, to help them.

Well, the question is, why is it a must-have? Well, the first thing: it demonstrates the end-to-end working of a team. And you cannot test it in your own environment too early. If you don't know where to start, then maybe it's better to find a safe environment like an interactive workshop just to practice and experiment a little bit before you go live.

It can only be successful if the whole team works as a good team. And I think these are also the ingredients of a successful DevOps journey. So if you don't see people working together in the game, then I should be very careful when you go live with your DevOps ideas. Maybe you need coaching and some support.

And the evidence is in the room, because in the first round, everybody will blame the cards. But in the second round, they realize, "Wait a minute, it's not the card, it's me." And if you really discover this and you talk about this, then you have an early warning that it's maybe too early to start doing it in the real world. So better is to practice first.

Well, continual learning and improvement is an element and is very useful for your own journey.

And the other thing is a little bit more the knowledge behind this. If you look at how we train people, and look at yourself maybe, then the lowest level of knowledge is the knowledge itself. So you can remember. You know the difference between a standup meeting and a meeting, or an incident and a problem. So you can define it. You can say, "Okay, I know the difference." Well, great. Congratulations.

But maybe it's better to understand why there is a difference. Now, understanding is a little higher in the way you use the knowledge. You understand it, so maybe you can even use it in another context. Maybe you can explain to others how it works. So the knowledge is more valuable now because you can reuse the knowledge.

The third level is that you are able to apply this. So you know the knowledge, you understand it, and you say, "Wait a minute, I see a situation. I have the knowledge, and I will bring it in and we'll fix it." Which is great. So if we can bring knowledge to that level, then it becomes more valuable.

Well, the rest is to analyze. You can use the knowledge to analyze situations, evaluate, and create. Well, let's leave it on university level where you create new knowledge, and maybe you can design DevOps version two or so with all the knowledge you have.

So what we see in a simulation is that suddenly, sorry, we are not just focusing on the knowledge, which is done in a foundation class, but we will challenge people to go to the higher levels. So they need to understand the knowledge better. They need to apply it, and suddenly the knowledge becomes more powerful, and they learn more how to apply it in day-to-day work. And that's a great exercise, and one of the elements why simulations are so powerful.

Another reason why it's so powerful is that there is a kind of, I would not say a new way of looking at learning, but they discover that 70% of the things we know as professionals comes from experiential learning, by doing things, tough projects, challenging exercises. 70% of your skills, your knowledge, your attitude come from this.

20% of what you do and know comes from talking to people, like on a conference. Ask questions. What do you want to know? Or I don't know how to do this.

And only 10% comes from a class, a training, e-learning, or another type of class.

So if we know that a professional learns in this way, and we treat our employees as professionals, then we should also offer them training programs according to the 70-20-10 rule. That's a human resource development principle.

So if you put professionals in a foundation class, well, it will not work because that is not the way they learn. They grab only 10% of the knowledge, but they will go out and practice it. They will use LinkedIn to get new knowledge.

So if you look at the game like a simulation, then this is a little bit how the day is organized. 70% is learning by doing, is dealing with difficult issues during the day. 20% is maybe a colleague who says, "I think I know how to do this. I made a Kanban before. Give me the Post-its. I will do it," and other people will learn. And 10% comes from the teacher, who will give them some knowledge after reflection and say, "Maybe you can use this."

So if you're able to design your training intervention using those three elements, then it will be much more powerful and also fun for the students.

And the other advantage is we will focus on relevant issues. If you look at an ITIL Foundation, PRINCE2 Foundation, or DevOps Foundation, there are so many slides, you say, "I know, I know, I know." But you can't tell the teacher, "Can I see slides 35 and 26 at 9:00? Then I can leave." So you have to sit there all day, listen to everything.

But in a game, it's not, because we only focus on the subject that matters. And then the rest comes because we need it, but we focus on one element.

So when to use? Well, after a foundation, then you can say it's a great way to tell people, "Congratulations. We issue you a certificate. Now, tomorrow we're going to run a workshop, and you can show your skills," and see how many will fail during the day. Not to laugh about it, but to make people aware. Don't think you can go back to the office and say, "Now listen to me. I know everything. I know how to do DevOps."

To create business awareness. What I discovered till now in the six, seven countries I've been now with the game, is not many organizations understand the real consequence of starting with DevOps. They think they know, but they still think that it is the magic stick, or they're a little bit scared about this, so they don't know.

Well, if you want to create this awareness first before you start training and coaching, whatever, maybe they should first experience this exercise to understand it.

It's not necessary yet because I don't see many organizations that are ready for an assessment. When we started Apollo in 2004, there were lots of companies who had ITIL implemented. And then we played a game, and they said, "Yeah, we know everything about ITIL. Let's play the game." And suddenly they realized that they were not successful.

So it was a kind of very nice self-assessment tool, where we didn't hold interviews, but just let people play and discover a long list of improvement opportunities.

I think for DevOps, it's a little bit too early because there's not too much experience yet to do the self-assessment. But it could, in the future, be a great instrument to put those companies in a game and say, "Now, let's see what you can."

Develop awareness in the dev and the ops environment. Some of the feedback I got was that people say, "Oh, it's the first time that we are working together, dev and ops." And they realize there were two types of persons and people. So maybe you can say not creating awareness in business, but maybe first create awareness in our own teams for this new way of working.

Just to practice to work together, because it's a funny way to work together. The first experience of having a common dashboard with all the Post-its.

There's a Dutch company who started this exercise, and he said, "Yeah, I have a big problem because the IT support manager, he has an SLA, and I want to deliver on time, and the two KPIs bite each other. Because I want everything quick, and he wants everything accurate, and that's not something that we have in common. So how can we align the two metrics and still be happy as one big team?"

So we played a game, and they discovered that still you can do your own work, but you don't need to fix or integrate the ITIL processes too much in your DevOps stream. You could better use your normal ITIL processes and fix the issues normally as you agreed, and maybe find some areas where we can work together. For him, it was a discovery because he thought the whole world needs to change.

And to explore solutions, because nobody has the right answer. No company is the same. And I think this is a great moment to say, "Let's sit together as a team. Let's practice and see what we can take out of this. Maybe we come to great ideas."

Okay, you can hire a consultant. Please do it. But maybe it's better to discover it yourself, because then you become the owner of the solution. And that's what we like to see. We like to see ownership in teams.

So if you are a manager who leaves it to the team, let them find solutions, and say, "Well, great solution. Tomorrow, we're going to use it." And that's true leadership. So take the lessons learned and focus on the implementation.

And this is how we do it. I saw this book in America a few weeks ago, and I didn't read it yet, but I like the title because that is a culture-change book. And it said that is the most common word we hear: "Now, testing went wrong." "Yeah, we know. That's the way we do it." And that means don't talk about this because we do it for years, and everybody likes this or is happy with this.

But it should not be the culture that we accept. If something goes wrong, if you have to wait for something, or if you have to do rework, we should create a culture where it's not normal.

One of the games, they had a Post-it wall and said, "Everything that you are frustrated about, you put it on the wall."

We did workshops in the UK with Open Limits, and I like the way they reflected. They say, "Let's make a little round. I want one emotional word. How do you feel?" And it's very nice to see round one, two, three, four, how the emotions were changing. At the end of the day: proud, happy. The first day, first round: frustrated, angry. Okay?

So it's nice to see how people change. And so we could be not happy with the way it works now. And maybe you should use it to start before you do anything else. You can make a lot of damage, and maybe it's better when you work with people, not to spoil the party, but give them a fair chance to be prepared.

And this is one of the quotes from Jonathan. He said, "If we had the simulation five years earlier, we would have made bigger steps in our journey." Because he said, "Now we had to reinvent everything. We had to discover everything, which was useful, but we could do faster if we had a kind of experimental exercise."

And the funny thing is that people who play the game, and when we look at the results, and we capture them on flip charts, and normally this is done by the students themselves, because then it's really the truth. Otherwise, they will just be kind to the teacher.

And the questions they have after the sessions, they say, "Yeah, but still, I don't know who should lead a Kanban session. We need to figure out who should be the one that stands in front of the board and leads this."

Well, they discover this, and the answer could be easy. It doesn't matter. Somebody who likes to do it. Because there is no boss in a squad, and maybe somebody likes to change Post-its or lead the process.

How to use a Kanban? They said, "Yeah, we don't know how to use it."

"Yeah, but you learned today."

"Yeah, but in our company, we have 400 projects."

So still questions.

The improvement processes. How to improve processes. Who should take the lead in taking a team into a room and trying to find the root cause of failure and trying to fix it? Who should take the initiative? I believe it's a team. It should not be somebody who said, "It's time for you to learn," because then you will not learn.

Making the right decisions. What is the product owner doing? What decision can we make in our team?

A nice example is a group that discovered that if you plan your work in progress with all the projects and an incident comes in that requires capacity from development, that everybody is stressed and we need to make decisions.

Well, who is going to tell the company that we cannot deliver his application because we need to fix an issue?

So they said, "What we can do, we can take 20% of our work in progress, and we give it to IT support. And that's their capacity to fix incidents without any discussion with any other team. And the other 80% is for development."

And then people start to argue. They said, "20% is too low. It should be 40."

"Okay, do 40. Why do you think 40?"

"Yeah, look at the first round. We didn't fix all the incidents. Look at the unplanned work."

"Okay, do 40."

So the first round or second round was 40. And then the next round they said, "We can lower it."

"Why?"

"Yeah, because we did everything correct, so we don't have much rework and issues."

So in the game, they brought it down from 40 to 20. They said, "What does it mean?"

"Yeah, we can deploy faster. We have less downtime, less incidents."

So they very practically discovered something very simple in the game, but they could transfer it to the day-to-day work, where they say, "We have to manage our people a little different."

Right.

So this is just an impression of how the simulation can help the DevOps journeys. We have many partners in the world. We work very close with the group of Gene. And if you're interested, you can go to our website. You can visit our partners. You can go to HPE on the conference, who is our partner as well.

So if there are any questions, then I think there is still half an hour left for questions? Yeah. You're the timekeeper?

Actually, yeah.

Okay, are there any questions from the audience? Go ahead.

2:15 is the next session.

Yeah. If not, then if you want to see it, you can come over. If not, you can go to the next session. And if you want to know more, find your way in the world. You will find us.