Huub van der Woude

Thanks a lot for being here and joining us in our journey towards DevOps. We are from the Dutch Railways, and actually, we learned something from DevOps until this moment.

Let's start with the Netherlands, where we are from. Tulips, windmills, wooden shoes, sea. Half of the country is below sea level, and beautiful trains. We live in the Netherlands with 17 million people, and everybody has an opinion about the service that we provide with the trains.

Shall I introduce myself?

Please.

Lovely. My name is Huub, and I have a function in our agile transformation. It's unclear exactly what function. Here we call it program manager. It's not really a program, but I'm very actively involved.

I have a background in software engineering. I have a very gray beard, so it started about 30 years ago, but we did do DevOps. It was called rapid prototyping.

After about 10 years of software engineering, I went into project test management in a completely different area, in big baggage handling systems for airports. We did Heathrow Terminal 5, for one thing. And you would think that we do nothing agile there, but actually we did a lot. We did loads of automation. We did loads of incremental development, also in a project that took about four or five years to build.

So some DevOps in my history. I joined NS about 10 years ago as a manager of a software development project department, and now I sort of got my dream job to help NS become a more responsive organization.

Now you're here, right?

Now here is the transformation.

And then you're here at this one.

Absolutely.

Ard Westerik

Yeah. Well, my name is Ard Westerik.

Ten years ago, I helped startups with the IT stuff they were doing. Then I went to a school platform system, helping them out after they emerged from being a startup and created a horde of mess with their architecture. And then I joined NS.

I'm a manager of software development for NS, and I lead 14 teams in software development on the digital area, like online, omnichannel, and propositions, so customer contracts. And together with Huub, I've got a role in the agile transformation, and that's even more interesting than being the manager of this department.

So we are going to tell you something about our journey, and actually the last two, three years that we worked together at the Dutch Railways.

Just a small perspective about the Dutch Railways. 1.2 million train journeys every day. 26,000 employees. 3,400 of them are driving trains, and only 1,500 people are in the IT staff. That's a little bit different from other companies I've met these days.

We have the world's busiest network of trains in the world, but we have also a problem over there. In the upcoming 20 years, the number of people that are going to travel by train in the Netherlands will grow by approximately 27% to 40%, and there will be no extra rails. There will be extra trains, but no extra rails.

So that is a huge thing for us, and the only way we are able to compete with that is by using IT in a different way.

This is the customer journey of NS, and here you see how things are changing for us. At the beginning, in the middle, in the center, you see a train, and our services are located around trains. But the customer is having a journey from his home to its destination, and maybe doing things at the destination and going back.

So in our service proposition, we have to do something about this customer journey. So it's going far broader than just the train, and IT is helping us out in providing services to our customers related to this journey.

Being able to give much more speed to all these services that we have to provide to customers, knowing that there will be no more rails, knowing that we rely on IT, we knew three years ago that we had to do something different.

We think that we are a very special organization, but there's nothing special about our IT. So if it is true that in an IT area where McKinsey says that you increase productivity by 20% to 30%, it must be valid for us. If it's true that you can reduce defects by 60%, it must be valid for us. If it also means that the motivation of employees will grow by that, it must be valid for us. And finally, if you can reduce time to market with that, then it must also be valid for us.

So this is what we believe in, that must be our challenge for the next years.

And this is also what we said: we want metrics on this. So all teams are going to work with cheaper, better, happier, and faster metrics. How they do it, they can decide, but this is what we want to see.

Huub van der Woude

First, I'll start to talk now about our agile transformation and our journey.

First, I'd like a little bit to talk about our plan. What you see here is a nice timetable that we have in our stations, and if our travelers want to go somewhere, we help them by pointing out various things: where the trains are going, where they will stop, when they will stop. Basically, the full package of information that you need when you want to go somewhere.

So what was our plan? Well, Ard and I thought really hard and really long, and basically we came up with this. We had very little idea what actually it was that we wanted to do. We certainly had no idea about how we were getting there, but we did know where we were now and where we were coming from.

And I heard a lot of stories already in the last day and a half about the things that we struggled with.

For one, we are an extremely fragmented organization. We have many, many different departments. It's really a marriage of six different companies. There's a lot of variation in IT. We have many departments, and the departments are staffed by primarily I-shaped professionals who are very good in one thing. And we had a number of value chains that really require every department and every person in that department to work together.

And the result of that, I think it was Barclays this morning. Did you see that presentation? I loved that. It was fantastic. This whole chain of events, which basically meant waiting, waiting, waiting for each other. So we come from an organization where everything takes a really long time.

Also, we tend to do things by starting large projects, and that has a history in the fact that we do a lot of tendering. We use a lot of suppliers to do the work for us. When I joined NS, my department had 3% of NS employees in their projects working. 3% means basically every single part of the work is done by outside suppliers.

That means that we have to tender because we're government, so we have many European rules, and to tender, you need really stacks and stacks of paper with specifications. And then we ended up in these large projects, and everything went wrong and went slow and, well, The Phoenix Project in full living color.

Also, very smart, we had a strict separation between change and run. We still sort of have that. Not all of these problems have been solved. It means that there was a group of people who made things, and there were a group of people who put things into production and kept it there, and they had vastly different views on life, as Jane Groll also told us a couple of talks earlier.

There was some good news. There were definitely pockets of change. There were many agile initiatives on the workflow. We tried to experiment a little bit a couple of years ago with Lean and trying to optimize processes and make things go faster. One project had experimented with continuous delivery. They worked together with XebiaLabs for that, and there were also people interested in scaled agile and a different way of working really together with the business.

Now, it's not really true that we didn't know where we were going, because some people were a bit savvy about the things that were happening around us, and they looked on the internet, and they heard Henrik Kniberg talk and these fantastic videos, and they learned about Netflix and about Jeff Bezos with his mandate that required the entire company to use microservices. So there was stuff going on.

Now, what happened in the years that we will cover today in our talk, about two years, a lot of things. And if we had gotten the two hours that we requested from Gene Kim, I would actually take you through all these events step by step, but we have to finish real quick.

So when Ard and I prepared this presentation, we said, "Okay, how can we take the events as they actually happened and sort of reverse engineer them into a plan, and what would it look like then?"

Well, it basically looks like this. There were really three big themes that came out of the way that we approached things. One was awareness. The second one was experiments. And number three was engagement, getting people involved.

So in the presentation, we'll take you through these three stages or aspects.

Okay, I'll start with awareness.

We are a train company and not an IT company, and I think in Ard's slide in the beginning, we have about 30,000 people working for us, and out of these 30,000, we have 1,000 IT people. And we are not, IT-wise, the most high-tech company.

So I also told you that a lot of work was done by outside suppliers. So our own IT staff was not exactly cutting edge, and that means that a lot of people needed some help or would benefit from a broader perspective.

So one of the things that we did, and we put a lot of effort in, is creating awareness. Giving people a broader view on the world.

Now, this is a photo album. I think it's very important that you take photos and make your own storybook. There's a lot of things going around, but for a collective memory, you need to create your stories and gather them and put them together. So we will use some photo albums in our presentation.

Now, on top left, there was one of our early efforts, an extremely silly workshop that we did on DevOps. And the big guy on the left is an ops guy, and the slightly smaller guy on the right is a development guy, a test manager. And tiny me in the middle with a T-shirt saying, "Break down the wall between dev and ops."

And it was a 20-minute workshop that basically talked about the culture clash and ops favoring stability and dev favoring change, and how those cultures would clash, and kind of a couples therapy, but then a couple of years ago.

We spent a lot of time looking outside the window. So we had several visits to companies who were already doing things. We did agile safaris, so we looked around the Utrecht area, Amsterdam, for companies that were doing things that we really wanted to do. And we went to talk to them, and we visited them, and we exchanged knowledge, which was really nice.

We had a series of pizza sessions every month. Fifty or so people would get together, and we would invite people over from Bol.com. They were there with an architect. Coolblue had some architects. There were people that were working in the transformation, but there were also people working in finance. We had developers talking, and it was very nice to use it as a basis. I think our Swedish friends before us, they did something similar, which is nice.

We started book clubs, people reading the interesting titles together. So this is one of the photos that we used to get into this conference, the book club about The Phoenix Project. Very nice. It was really reading about our own company. And the next book will be David Marquet's book that we're going to read together. Very inspiring, very nice, and also something that we need to work with.

The picture on the bottom right, that's Madonna. And you're probably wondering what Madonna is doing here.

One of our team leads is a music fan, and his department, I think about 15 teams large, they just started with continuous delivery, and he used the concept of the CD of the month to take a concept within continuous delivery to get people to talk.

And he first asked the people, he would name the theme, and the people could come up with a song, and they would sing and dance and discuss the aspects.

So this month, he told me, the song was "Get Into the Groove." That's why it's Madonna. And it's about establishing a cadence in the team to be able to deliver real working software every couple of weeks.

Now, next month, the theme is how you move away from a very monolithic system towards a more microservices-based architecture. And any music fans in the room, could you guess what the song is? They took an old Neil Sedaka song from the '60s called "Breaking Up Is Hard to Do." I thought he did a good job there.

Back to you.

Ard Westerik

Right. After awareness, there comes experiments.

We recently made a count, and we have at this moment 125 teams working agile at NS. Two years ago, we were asked, "Will you do an investigation on how these teams work?" And you can say, I said, "No, we're not going to do that, because when we do that, we need to be able to follow that up, and we are not able to follow up something like 100 teams."

So we said we have to start with experimenting, just doing it. And all these teams were already working Scrum from 2011. And what occurred to us is that all these techie people are willing to do something new with cool tools.

So we said, we are going to do an experiment, and we're going to experiment with two teams, and we do it over the line of continuous delivery. Because if we do that, we provide tools to these teams that they want to embrace and where they can make the difference themselves.

So we asked them to start out with at least three things. Besides the fact that we wanted to measure them, they had to measure faster, better, cheaper, and happier. But we asked them to do three things in the project.

Value stream mapping, because if you do value stream mapping, you sit together with different kind of teams over the same product and find out where your problems really are.

We asked them to work with a maturity model, because we didn't know where they were, but they themselves didn't also know. So how can we help a team in growing when we don't know where they are? That's why the maturity model was.

And feedback loops, because feedback loops create learning, and without feedback loops, no learning. And we didn't have visible feedback loops over these value streams, so that was an important thing to start out with.

And the results. We started with two different teams in different areas. The results after 12 weeks were quite impressive, I could say.

Team happiness grew. Duration of testing was minimized, for example, by the Rhino team, from 45 minutes to 15 minutes.

And these are all small results that we made to start with, but the result of all these small results was, for example, that the Rhino team was now able to bring stuff in production, instead of after three months, after six weeks.

So that was already quite some proof that we were on the right track, and that we had to continue with this approach we had there.

And our CIO said, "Well, I think you're on the right move too, so go ahead. Go another year." This was 2016. "Go ahead in 2017. What do you need?"

And we said, "Okay. We want to do six extra teams."

And he said, "No, no, no, at least 20."

"No, no, no. We can't do that because we are not at scale yet. We have to learn a lot, and please give us the possibility to do it with six extra teams. We have to learn, right?"

And one other thing we did is that the learnings from this year, we expressed broadly. We created a conference at NS where every developer could get together and find out what the learnings of these two teams were.

So the experiments in 2017, we learned more. We put all the results in, of course, we have them all digital, but if you want to spread out something, it's cool to have a wafer, like the continuous delivery wafer, with all the results that all the teams made in the second year.

And it did also something about measuring and being open towards the things you achieve as a team. I talked to you about feedback loops. All teams got big screens, and on these big screens, they could do whatever they wanted, but we asked them, "Can you tell me something about the productivity of the team? Can you tell me something about the quality of the pipeline? And can you tell me something about the quality of your product in production?"

And the first one was quite easy because you have Jira, so that's on top of the left. But the second one was already a little bit harder because if you're working in silos, you need to get access to information, data, that is not directly given to you. So it took us about half a year to get build status.

And finally, this one, that was only at the end of 2017. And you can't read what it states, but I will tell you. It's about the revenue that the product of this team makes online. So they had no clue what the revenue of their product was online. And they were astonished because this says that almost 50% -- that's the yellow against the blue -- that only about 50% of the revenue that we make with their product is via their product online. They thought it was 10%.

So it's all about misconceptions and learning what you have to take responsibility for.

Of course, you need good tooling. And there is, of course, everybody has a story about good tooling. We have a story about how you get good tooling at teams.

This product is called Topaz, and actually, it's not a product. It's a suite of all kind of standard tools that you can use. And the Topaz team at the Dutch Railways did integrate that and provide it to teams. But they did it in a very special way, and they did it in a way that they said, "Well, there's one tool for one function, and by the way, we define the function, and we define the tools."

So what happened? This environment is already five years available. What happened is that in 2016, they ended up with two teams, and these two teams were very annoyed about the tooling environment that they got.

We believed that this Topaz thing could be a game changer for NS. With this thing, we might be able to scale up, but then there should be changed something, and that's the attitude of the team working with Topaz towards their end users.

So we asked them, "Are you willing to come on board of our transformation program?"

And they said, "Yes, of course, we want to do that."

"Well, then you need to do two things. One thing is learn from your end users. So you ask the end users, and we have these six additional teams available. And so you're going to listen to these six teams, and you're going to provide services. That's the second thing. You're going to provide solutions for the things that they ask you to do."

Now, then that was a little bit like this. They said yes in the end. And in one year, this was the year 2017, 20 new teams were onboarded on this platform, and 20 happy end-user teams are now using this platform.

So it's all about what you do with the people you work for. Are you helping them out to deliver products to our customers, or are you putting yourself on a platform and saying, "Well, it's me and you should listen to me. I know everything that's going on here"?

So this was really a game changer for us. And actually, if it's about better, faster, cheaper, happier, then the happier thing is not only from the perspective of the teams using Topaz, but also from the perspective of the team that delivers Topaz has grown. It's amazing. They are rewarded for what they are doing now. It's seen what they are doing, and people are happy about these people, this team working on Topaz.

We also have actually some cool results.

This is from a team that was not part of the eight teams. So what happened around us is we were doing things with teams, and we motivated them, but there was a group of teams around these eight teams, maybe 13 teams, that were also interested, and they were just looking and learning from what we were doing.

And this is a team, it's working on an SAP environment, all very inflexible. And they had a very big problem, and the problem was that every four or every three months they were doing a release, and this release took us 20 hours to get into production.

So there was a lot of pizzas and a lot of horror stories over there, and a lot of firefighters that were doing cool stuff in the weekend. And at the end of the weekend, after every three months, this release went into production.

But the people from business, they were not happy with us because it took us about 20 hours. And they said, "Well, that's not good, because now there are customers that are unable to sell our products." And, well, maybe weekend, but they are always there.

So we started improving on that, and we were able to bring that, by the end of 2016, from 20 hours to 12 hours. And we were very happy. But the marketing people, the business people, they were annoyed.

And we didn't know what to do because we stretched the processes till the end. We did everything in the same way, but extremely much better. And we thought, "Well, if we can't make an improvement in this way, then the way we approach this is the problem."

So we asked the team, "What would you think that we should do?"

And they said, "Well, we have created a value stream, and we know where the problem is. The problem is in automation."

"Okay, what's your proposal to automation?"

And they said, "We need a product. It's called ChaRM, to automate our processes. And when we automate these processes, we will be able to make automated processes to production, but also the auditor will be happy because we will not see this guy anymore because he can look into the logs. So this will help us out."

And we were thinking, "Well, maybe, maybe not." But as we are agile and believing in the agile principles, we said, "Okay, if you as a team believe it, go do."

And then this happened. And I'm from IT, and I worked 20 years in IT, and I never believed in hockey sticks because they're always predictions in the future. But this is really what happened at our site.

Within a year, they were able to go from releasing every three months to releasing three times a week to releasing five times a week. And when we were at five times a week, they didn't use all the slots anymore they get provided. That's why the red and the blue line are differentiating over there.

And this is what happened with the downtime. And it's not that they didn't measure here. It's really zero. So they went from these 12 hours until zero downtime at this moment, and that is absolutely amazing.

Everybody was astonished that we could get these kind of results from different kinds of working together. And this is what agile, DevOps, continuous delivery brought to NS.

So what did we learn from that?

Small experiments, very important. Feedback loops, very important to see what you're learning. The IT perspective was, in our experience, very important to give the tools to the people who care about these tools. Do something that's close to the developers and operations people. Sharing knowledge, because that's how we got growing the idea.

And of course, we learned also some other things.

The factory paradigm. If you're working with managers, and I'm a manager myself, you hear a lot about, "Well, we are doing IT like a factory."

When you hear people saying, "You're doing IT like a factory," there is a paradigm in their head that doesn't understand what we are really doing. We are working with highly educated people that have a creative mind, and it's not about candy stores or whatever. It's not about a factory.

So as long as they talk about this paradigm of the factory, you're sure they're not understanding what the changes that have to be made. We are struggling with that at this moment, and if you have an answer how to kill that, we would really learn from that.

And another interesting, but also very difficult thing is external suppliers. And it's not actually the external suppliers, but it's the contracts that are coming with these external suppliers and actually, of course, the things that we ask these external suppliers.

As long as you have that, and we have some of these big contract things, they are actually in the way of making the move towards a more flexible way of working.

Huub van der Woude

Well, as we are about halfway through our presentation, I need to speed up a little bit in the last part.

By the time that we were expanding from two to eight teams, really a movement was started in the company. People were getting very enthusiastic and wanted to participate in the transformation.

So we created a program, an emerging program, but we liked the word movement better, to allow people to participate in this. How do we become a DevOps organization?

And we used a lot of symbols that talked about movement. This is a nice mobile by an American artist. Fixed structure, but always responding to its environment.

And we created one simple motto. We wanted to make our work and its results better, faster, cheaper, and more fun to do, happier, by applying Lean, agile, and DevOps principles.

Now, this was basically the objective, and people were asked to participate in whatever way they could think of. We provided a little bit of structure, and it seems to be a little far-fetched now, but I was very proud of it when I thought of it about a year ago.

We had various perspectives on the transformation, and people could choose one of them and get active. So there was inspiration, meaning organizing inspiring sessions. We had learning teams that experimented with continuous delivery and DevOps. We had support, ondersteunen in Dutch, who supported it with tooling and with coaching. There was a team that targeted measuring, and there was a team that thought about what the agile transformation would mean for their chapter and how to secure best practices.

Now, this was one gigantic experiment for the sole purpose of getting people moving. Call to action.

So we also decided to experiment with the way to do this. So we took a kind of a SAFe-like approach, where we would have a quarterly, three-month cadence about what we try to achieve there. Well, we had what we call the PI planning session, the program increment session, where people would talk about what they would try to achieve within their perspective.

We did a lot of organizing big events, I think our Swedish friends also talked about that, to really get people moving and to spread the ideas.

That was a success in some ways and not a success in others, which was interesting. There was definitely a lot of energy. People were really energized and enthusiastic to participate. There was a lot of cooperation because people were in those virtual teams together with people from different departments, so breaking down those walls was successful.

But it was very difficult to get to concrete results here. People found it difficult to work agile, to break big things up into small parts, and then deliver the small parts. So we had to try to eat our own dog food.

It was very difficult to align quarterly results. So from all of these different perspectives, to come up with something that was a meaningful result.

And we also found measuring very difficult. Not to come up with the KPIs because there are a ton of them, and not to come up with ways to measure them, that's also fine. But we found it difficult for the teams to get measuring.

People knew it was important to get feedback about their own performance, but it somehow got lost. There's always a lot to do, and to implement the measuring program and get the discipline of gathering data and do something with it was something that we struggled with. So that's something that we'll have to do better in the future.

Now, Gene insisted that we make a slide that shows our next steps. Well, the next steps are, I heard many pointers in the presentations that I followed so far. They're basically all related to scaling up.

We put a lot of effort in culture and mindset and in way of working, but these are really things that need to be addressed when you want to do something structural within your organization with DevOps.

So it has to do with, how do we organize ourselves? Are we willing to reorganize? Very difficult subject within NS. How do we do agile governance? How do we fund activities, strategic objectives? How do we move away from projects and move away to products?

What do we do with our middle management? They need to display a different type of behavior, but their job might be on the line, so are they willing to do that?

Our working environment. We have very old-fashioned buildings with very old-fashioned floors and very old-fashioned offices. There is no money, obviously, to fund the wishes of an IT department while we're trying to get new trains. So these are all things that need to change, but it's difficult.

The good news is that we got our management team on board, and they pronounce that agility, as opposed to stability, is now the prime objective in our next three months.

Now, my final words here, reflecting on what we did and what we would advise you or give to you based on our experiences.

Number one is just start traveling. And this guy has one small backpack and two enormous suitcases. You really don't need those two enormous suitcases, and they can be tons of funding or 100 agile coaches or management support on the board level. You can really do an awful lot of things with a small backpack. Awareness sessions, getting people to participate, starting small experiments within teams. Very possible. Do that.

Inspiration. There are fantastic books on railway journeys of the world. There are very successful companies, and when I sit here, I feel really very small. I think everyone is doing fantastic things, and why are we struggling? Get inspired, but do it your own way. What works for your own company is very situational. So you got to look at the culture. You got to look at management support. Do your own thing, but be inspired.

Third one, I mentioned it before: create your own collective history. Make your photo books, make your photo albums. Things like McKinsey or the DevOps report, they can state fantastic numbers, but if you cannot show them with your own stories and your own achievements, it will never stick. So it's very important to get people moving and gather those stories yourself.

And finally, what I think, I think these are very exciting times in our industry. I really thought that maybe 15 years ago, things were sort of standing still, at least that was my feeling. Things are moving again, and it's a fantastic journey, and I really enjoy being part of that journey.

So I would give that advice. Look out of the window and be happy that we're doing the things that we're trying to do. Thank you very much.