Jan Schilt

This is a little bit bad news to start with, because, just to start with the conclusion of my presentation: DevOps will fail.

But there is a solution, and it's not just tooling and training, but it's also simulation. Because a DevOps journey is one big simulation. It starts somewhere. It's trial and error. It's making mistakes. It's laugh about it, try something else, which is the same as the simulations. It's experiential learning.

And in this short presentation, I just want to share with you the Phoenix Project business simulation and some of the outcomes and experiences we had.

We are just a small company. You can't find it on any map, just six people. But we have a huge international network, very loyal partners all over the globe. And we can stay very small because we build our materials and we share it with our partners, so the partner can use the materials in their own offerings, customize it if needed, and more than 400 trainers are ready to deliver trainings to their own customers in their own language, in their own country, own culture.

We also built Apollo 13, which is a great experience about the 1970 flight. And the big challenge is to use ITIL principles to save the crew. And not everybody saved the crew, but at the end, they learned how to use DevOps or not, and some other nice simulations. And they all have the same characteristics.

We try to put students in a very challenging environment that's very far away from their own reality, and that means they are excited to participate in this exercise, and before you know, they will behave like normal.

Well, they will blame the game, of course, after a few rounds and say, "No, no, normally I would do different." But we know better. They are so excited that what they show is what they really do.

And simulations are quite popular, because even with our small company, we run at least 500 workshops a year all over the globe. So while we're talking here, on two or three places in the world, they use one of our simulations to teach people behavior and culture and frameworks and whatever.

So the question is, why would DevOps fail?

Well, first of all, I think a lot of companies, they don't have the right culture. And I have a little bit of experience, because I built the simulation in a kind of agile way. So I tested a few versions of the simulation on people without knowing, because I just told them it was ready.

And then you see that a lot of companies fail to have the right culture. And right culture means a culture where they can experiment and learn and become better teams.

Also, lack of the right competencies. And competence is not just knowledge. A competence is also a skill and a behavior and an attitude. It's all part of a set of competencies.

Another, I think, reason is that a lot of people see this as the new framework. I was in Germany on a conference, and I didn't see any presentations about Lean or Agile or DevOps, and I went to the director of this conference. I said, "A little bit old-fashioned conference. I don't see any Lean and Agile, DevOps."

He said, "No, this is Germany. First, we have to finish ITIL."

So it's a little bit strange. So it's like, well, we first implement this, and then we implement that. So still, a lot of companies see it as the next framework. They see it as an attack on their current way of working and say, "Not ready."

Tools are the solution. Yeah, maybe. But maybe first start with people, and maybe first start to get some clear processes and behaviors before we buy those expensive stuff and then see that nothing changed.

Certificates. Nice discussion.

I don't know. I don't know. I think certificate is nice if you get more money, or you can put it on the wall and say, "Look, I'm an expert." But I'm not sure. But it influenced the world a little bit.

You saw what happened with ITIL: three million certificates, and still a lot of IT companies fail to deliver the services. So maybe we should not make the same mistake in DevOps and just say, "Let's go with the flow." And of course, you can do good training, and you can do some certification, but it's not the solution.

Fast implementation of DevOps. I did these few workshops in England with Auto Trader, and it took them seven years to reach a kind of level where they dared to change the building, where they got rid of all the walls and had these big screens on the wall and stand-up meetings and coffee corners.

That's only the last two years when they really removed the walls. And the same as ING in Holland. They also spent at least five years to reach a certain status where you can say, "Well, yeah, we work like DevOps." So it's quite a long journey. It's not something you implement overnight.

Gartner said it: cultural resistance will create significant failure. And I think that this is important.

And the other thing is organizational change issues are far more challenging than all other issues. And enterprises are not ready for DevOps, but will not survive without it. So just a few things from the news. It's warning us.

And this is also a very nice one. DevOps cannot be obtained overnight with a simple check and a little training. It's a transformational approach to core processes, and it takes time, dedication, and especially a team that can implement DevOps practice.

I think it has everything in it, that DevOps is more than just go to a training, get your certificate, and then implement it in your own organization. It's not.

And I like this definition, because you can see a few words like cultural, professional, movement, communication, collaboration, integration, IT and software developers. So it's a great definition. It shows all the aspects we have to take care about.

So we have to find solutions to work on that culture, to really work with people as if they're professionals. You may expect from them that they act like professionals. And it brings the world together.

Only one thing I'm missing, and that's the word business. Because what we learned in our first simulations is that people say, "Yeah, the best thing I learned was the business should be an equal part of this whole transformation. It's not just the IT party. It's the whole setting."

So how can we avoid it?

Well, just to capture a few outcomes, one is this business awareness. It's not just awareness saying, "Yes, I understand DevOps, and yes, please go for it, and I will follow." But the real awareness is also commitment and buy-in. That means they should also take responsibility to minimize the flow themselves and make the right decisions on prioritization.

Senior IT management awareness. We did a workshop in London with 40 people, and one of the IT managers came to me and said, "It's very nice, this DevOps. I really like it. What about me?"

Yeah, it's a good question. Maybe the whole way of how we manage people will change. A good team doesn't need a real manager. The team can manage itself. But then we have about one third of this room will have to find another job. You can become agile coach, or you can become specialist, or you can become something else.

But we need to take care of this population, and it will change rapidly.

Be focused on people. Attitudes. So everything starts with an attitude, because attitude is something you can't see. If I say to you, "Oh, you're a great audience," then maybe my attitude is completely different.

So my behavior looks nice. Oh, polite guy from Holland, yeah. But maybe I think, "Okay, it's another 14 minutes and 50 seconds, and then I'm gone." If that's my attitude, then I will never change my behavior, because it's here.

So maybe first you have to work on the attitude before behavior will change.

Focus on teamwork and collaboration. It sounds easy, but teamwork is very difficult. Try to imagine a specialist who will share knowledge with an IT support engineer. He will not do this. He said, "Yeah, you can make things worse, so why should I share my knowledge?"

But it's part of teamwork, creating cross-functional and multifunctional teams. So how do you get those people to share their knowledge and work together?

First processes and behavior, then tool. Because you need to first work on the processes and behavior, otherwise this most expensive tool will not benefit from everything.

Learning-by-doing culture. When we run these workshops and demos, people say, "Yeah, it's very nice, this two-hour session, it's enough. But if I work and I take some time for reflection, my boss enters the room and says, 'Go back to work.'"

So how can we create this learning-by-doing culture if we don't spend time or organize time for learning and development? It should be part of the team exercise to spend your time on retrospective and learning cycles.

Transfer theory into practice. It's the same story with all the other frameworks. You got your certificate, you got your theory, and then you go back to the office, and what are you going to do? Who is taking you serious, and who will tell you to take the new theory and use it to solve problems?

So I think we can learn from this history to make plans how we're going to transfer the knowledge.

And integration in the current way of working. There is so much work done already. We have these ITIL processes, and people think that you have to throw them away. But you still need to solve incidents and find root causes and plan changes and plan your capacity. It's still something you need to do.

But maybe in this DevOps environment, it's a team who will take care of everything. And it's not only your role description. It's just the responsibility of a team to make sure that everything is done. So maybe we need to find a way to continue where we are. That's, I think, a good strategy.

Right. And transformation approach means we have to make transition steps. So we have to move from one stage to another. And maybe you can define them as a team. Say, "Okay, the next target is to achieve this." But you have to make a transformation.

Transformation requires what we call a warm organization and a warm change. Warm organization means an organization that likes to learn, and they want to learn. They have the capabilities to learn. That's a warm organization.

And a warm change is a change that has time, and I think we have time, so we can use the transformational approach. If we don't have time and we have a very cold organization, you have to implement something. Open it, put it in, close it. Don't talk, don't listen, don't train. And then it's an implementation.

Right. So what is a serious business simulation? Well, it's interactive learning. It means people in a room and go through the learning cycle of doing, reflecting, thinking, and deciding. That's the learning cycle, and that's crucial.

If you learn it in the simulation, you can do it in day-to-day work. And it's the same mechanism we want to see back in DevOps teams. We want to see a learning cycle.

Of course, you can use the plan-do-check-act, but that's project management. In DevOps, we talk about learning, continuous learning and experimenting. So that's why we should teach people the learning cycle.

It's a group of learners face-to-face. So no digital learning, no Skype. Just look each other in the face and talk to a person. Shake hands and say, "Hey, I need to talk to you because we need to talk about an improvement opportunity."

So more and more companies I spoke with, they say, "We bring the teams back to one place. We don't want these virtual teams. More and more, if possible, we bring the group back together in one room, and we let them support a service or a value stream."

It's actors in a challenging, realistic context. So actors means, like in our simulation, the DevOps simulation, there is a Steve, there is a Bill, there is a Brent, and people recognize those roles. And within a split second, they show the same behavior, and then they recognize their own managers and their own specialists and their own organization.

So yes, they are actors, but in fact, they really act.

It's a focus on specific learning objectives, so you can customize the simulation to focus on those things that make sense. Or try to do it in a DevOps foundation and say to a teacher, "I want bullet four of slide 26, and I want you to spend 20 minutes on slide 40." No, you have to sit the whole day and listen.

But in a simulation, you can say, "The only subject we talk about is how we communicate together, or how we use visualization or flow." And you can introduce day-to-day problems. You can ask people to bring in their own cases, and you can practice and experiment with it.

So these are just a few pictures of what people do, that they make little... Well, I have to be very careful with the word Kanban. A few agile specialists in Brussels almost killed me because I used the wrong explanation of Kanban. So from now on, I use visualization tool.

Okay. So visualization tool, and you can see a stand-up in the left corner. This is a very experienced team from Auto Trader in the UK, and it was very funny to see. They are about five years busy implementing DevOps, and as soon as I start the simulation, after my introduction, they call, "Stand up."

And they were standing in front of a whiteboard, and they organized the work. I said, "Wow, great." And then they create a few visualization tools on the wall, and then they start playing the game.

And this tool in the middle was changing every round. Every round, they make something else, which is great. Experiential learning, practicing, throw it away, build something new.

And this is just an overview of all the words that will come by when people play the game. This is what they talk about. And talk about means they not reproduce knowledge. They don't know the definitions, but they really understand what it means.

And that's, I will come back to that a little bit later about the taxonomy of Bloom, is the understanding and application of knowledge, which is much more important than just reproducing the theory.

So first of all, it's very powerful because you can put a whole team in the simulation, which is great. Business, IT support, technology operation, everybody. Put them in one room, close the door, and wish them all the best and see what happens.

Focus on behavior, interaction, teamwork, and this continuous learning cycle. Because there is four rounds, for example, so each round they will make mistakes, but you will not tell them what went wrong. You will facilitate them towards success, and that's what they learn.

So they learn the value of an agile coach or a Lean coach or any other coach to help them to move from one stage to another.

And this is about Bloom. Maybe you know the taxonomy of Bloom, but what he said is that we have different layers of understanding and knowledge building, and the lowest level is knowledge. It's reproduction of knowledge, the definition of an incident, the definition of a flow, so you can give the right answer and you pass the exam. That's great. That's the knowledge level.

The second level is about understanding. So you can reproduce the definition, but you also understand why an incident is something different than a problem, or you understand what a difference is between Kanban and a flow. I now understand.

So that's the second layer. It goes a little bit more deeper in building up your knowledge.

And application is the ability to use it in any kind of situation. I don't know how it is with you, but since I know more about DevOps and Lean, my shopping process is different. I look at an average shop. I see all those people waiting. I see the things I need. I don't see them, so I think somebody is not managing the inventory.

So it's a little bit crazy in the brains, but I try to apply the theory every day of my life, and that's because I understand it, so I can look differently into the world. And so that's the next level.

Analysis and evaluation and create are much higher. That means if you are on that level, you will create a DevOps version two. That's the highest level of understanding and application.

But a simulation is very powerful because it puts you on the level two and three. It will challenge you to use the theory in a totally different context. In fact, that's one of the definitions of learning: applying theory and knowledge in a different context. So if you learn something today, you will use it tomorrow in your office. That's learning.

And the other thing is that we all learn differently. The 70-20-10 rules are very popular right now, and that means that 70% of everything that we know in this room, we learn by tough projects, making mistakes, doing things, reflect on this when we go home. That's how we learn.

70% of all the things we know, they come from doing. And 20% comes from talking to your peers during this conference, having a coffee together, say, "Hey, how do you fix this?"

Only 10% you learn by listening to me or to any other speaker. That's why all these presentations are quite short, so you can concentrate for a long time.

So 70-20-10 is perfect because an average simulation has the same structure. 70% of the time is doing, 20% is talking to each other, and 10% or even less is the time for the teacher or the facilitator, because that's a good simulation.

I also have simulations where the teacher is talking all the time, but this is the aim. 70-20-10, a perfect match in time.

Now, how to use it and when to use it?

Well, it's perfect after a DevOps foundation, for example, because then we get all these people with certificates and a head full of theory. But don't put them back in the office and say, "Now you know everything. Tell us, how are we going to do DevOps?"

Maybe another step is to let them practice a theory and see how well they do.

It's also to create business awareness. The simulation we built is based on the book, so it's very easy to understand. So it's perfect for business. So we can put them in this situation and let them experience, let them play this IT team. Let them play this Steve or Bill. Let them feel frustrated about themselves, because suddenly they play the other end of the medal.

To create a kind of assessment or gap analysis. Not many companies are already that far in their journey that it's time for a kind of assessment. But maybe it's good to say, "Yeah, we are working now for a few years. Let's play a game and see if we can find other solutions."

Or to develop IT awareness. Still, many companies are at the start of their journey. They just want to see what is that DevOps, what can it bring us? And this is a great way of saying, "Well, I will not tell you what it is, because I can't." I like the picture of the elephant this morning. So many impressions.

Better is to say, "Well, I don't know, but I just put you in the context."

To practice working together just for fun, see if we can become a team, and many other types of, well, let's say, applications of the simulation.

And maybe to start, or before we start anything else, maybe we should avoid all those mistakes and say, "Let's first explore what it is and make our own plan."

Well, Auto Trader, I mentioned it earlier. This group is very far ahead. They did an excellent presentation on one of the conferences in Vegas, and I spoke to Jonathan and I said, "Look, it looks like you are a perfect pilot team for me because you can really test my simulation."

And so we played a game, and they scored very, very high. And he said, "Yeah, but if I had this simulation five years earlier, we would've made bigger steps, because we had to find our own way now."

So for those companies who are at the start of the journey, maybe it's a good start to explore first before you make terrible mistakes.

Well, this is something you can read, while I see that my time is 21 seconds. But these are just some takeaways from the simulations. Most of the simulations are played at this moment on conferences all over the world, and step by step, more and more companies are starting using it for their own start-up and their own DevOps projects.

I know it's really a silly presentation to tell you something about something you need to do, but I brought a box with me. So if you have time during the break, you don't want to drink coffee, but look in the box, then I'm happy to show it. Maybe we can take a table somewhere in the back and show you something.

Any questions? I'm here until tomorrow, 12 o'clock, because then I fly back to Amsterdam, so you can use me until that time.

Any questions? Is there time for questions?

Q&A

Jan Schilt: I think...

Audience: Because you're the manager.

Facilitator: Everyone's in trouble now.

We are officially at break, but if you have any questions, we can pass out the microphone and do a couple quickly, if anyone has any.

Q: How do you get it?

Jan Schilt: Sorry?

Q: How do you get it?

Jan Schilt: How do you mean, how do you get it?

Q: The simulation. How do you...

Jan Schilt: Oh, maybe after the session. If you come to me, I will tell you.