Christoph Schär

Swisscom is the largest telco company on the national market. However, even as a national provider, we can no longer only look to the market from a national perspective.

Increasingly, our products face competition from global digital products with fast, frequent, and disruptive access to our customers. As examples, WhatsApp elbowed out our short text messages within months a few years ago.

Now, we set out for our transformation journey, mainly prompted by this change. I would like to share our experience together with you and to tell about our learnings we did so far, and probably some of these learnings might be helpful for your transformation journey as well.

Therefore, we will ask four questions within the next 20 minutes. Why did we take Agile and continuous on board of our transformation journey? What are the key levers? How did we proceed? And where do we stand today?

Now, does this perception of IT seem familiar to you? IT projects that last for nine months often go over budget, do not really satisfy all of the customer's needs, and this results often in expensive changes at the end.

If we, as internal IT development unit, would not have started our change actually two years ago, I think today we would have some serious issues to cope with the market demand.

So let's look at the expectations a bit closer. As I said, so far, we are having a very demanding market environment. And on the other hand, the perception of our IT internally was, in the past, so-so. And we have to acknowledge as well there is much room for improvement regarding our engineering capabilities when we started two years ago.

To be fair, all these expectations, they are not new today. We know that. They have been around as well in the past. However, they become much more crucial in the wake of digitization. And even in the past, we tried actually to satisfy these expectations better by optimizing our waterfall approach we had. But there we have to admit that we really came to an end with only implementing incremental optimizations to this process.

For us, it was clear that we have to enter really new avenues, and they have to be disruptive if we want to be successful as well in the near future.

Let's look at that. Is this the disruptive way we should go? No, it isn't. Sorry, I'm still back on the outsourcing slide. No, that's not the approach. This could have been one from 2007.

Today, as digital business, we know that software engineering is one of the core competencies of our company, and therefore, we aim to raise...

Oh, I don't know. Somehow the wrong one. Next slide, please. Great. Thanks.

Therefore, we aim to raise our competence level and the professionalism that we become one of the top-ranking software engineering companies in Switzerland. On the one hand side, this will be an attractive prospect for our present employees. And on the other hand, we need to recruit new talents to improve our DevOps and continuous capabilities as quickly as possible.

And we know we didn't do enough there in the past. And of course, all the outsourcing discussions and decisions did not really help us to improve these capabilities. We were mainly focusing on steering capabilities rather than engineering capabilities.

On top of that, we set our level to add value to the whole enterprise. We want to improve our cost efficiency by 30%. On top of that, we need a 40% improvement on our ability to react on the market, and all that with constantly high quality and stability by 2020.

Now, why these values? You're justified in asking why the 30% cost efficiency, and you wouldn't be the first one actually asking this.

We didn't do a proper bottom-up analysis to come to the 30%. We didn't do that. If we would have done, I guess we would have ended up with roughly 3% as target. In this case, we would only have had to tackle this mountain, or rather call it hill. This is one of England's highest mountains. It's called Kidder.

But as we are from Switzerland, we set our ambitions higher. I don't know if you know this one. That's the Matterhorn. It's one of the most famous and highest mountains of the Alps. Therefore, our 30%, it was an upfront commitment we did, and this one was based off experience from others.

And the key insight there is actually that this upfront commitment of the 30% made our transformation journey very interesting to the executive management board. I don't think that's astonishing, but that's crucial for us because we need this support of our executive management for this actual journey, our transformation embracing the whole company.

And with these goals in our backpack, we set out for our transformation roughly two years ago.

Jens Wilhelms

Right. So does this work? How did we really start our ascent to these mountains that Christoph shared here, the Agile and DevOps mountains?

Actually, our journey did not start in Switzerland. One could say it started in Spain. It was 2014 when our current boss, who back then didn't know he would be heading up the development division at Swisscom, picked up the concept of bi-modal IT back then.

And you might say bi-modal IT is not too much of an inspiration if you really want to go DevOps, and that's right. But still, taking these ideas to Switzerland, we derived a strategy that really helped us setting out on our Agile journey.

Agile didn't exist too much in Swisscom. It existed, but certainly it wasn't the norm. It was the exception applied in a few areas, but it was always with Scrum at the end. And DevOps as a term was not familiar at all in Swisscom.

So this is the strategy we derived back then in 2014. And we also adapted our organizational structures according to that.

What were the reasons for going bi-modal back then? Number one, what we acknowledged is that we needed to create some kind of incubator to start with because we really didn't have the practical experience back then.

And the second one, we needed to manage risk. We could limit the risky part to some 10% or so of the organization. And that really helped us building up trust in the organization.

Another advantage of this approach was that we can now flexibly choose our pace to scale the transformation. We can take pieces and topics from the core mode to the digital mode and make them Agile or DevOps. And it is really helpful to build up trust in a really controllable area before scaling out to everywhere.

So when we introduced this concept and presented it in the organization, this was well appreciated once they saw the advantages. And honestly, many were also a bit relieved because they saw, okay, over the years, I can stay a bit longer in core, and I really don't have to pick up this new stuff for a while. So that was quite convenient for them.

But some openly gave feedback to this because they saw this can't really be our pole star, being bi-modal. And they were right. Why? Because Agile is something that, if it works in some area, why not extend it to everywhere?

And also, it is a bit of an effort to manage and coordinate and align these two modes running in parallel. So it's causing a certain overhead, which we want to get rid of.

So we acknowledged that bi-modal is something we need to go beyond. And also what we saw is that limiting our transformation back then, that was development that we tackled with some 800 internal employees and a lot of partners back then, that was not the end of the story. We had a lot more potential if we extended it to Ops.

So we extended the whole thing, and DevOps became then our pole star for the whole transformation. And for us, that was not really a strategy change back then. It was something that we consider as an evolutionary step, like shown here.

And to express that, there's a quote from Charles Darwin. We heard it today in another session by chance. It's not the strongest species that survives. It's also not the most intelligent, but it's the one most responsive to change.

We are not the strongest, we are certainly not the most intelligent, but we are ready to change.

And this is how our adapted strategy, or a simplified version of it, would look like. What are the key changes that we did?

Number one, Agile picked up quite some speed. We are now at 25% of our organization, and that was faster than we anticipated. So we said we haven't screwed up. It works, so let's accelerate even stronger and make the whole organization Agile by 2020.

The second thing is we now want to dissolve the two modes, core and digital, because it's all DevOps at the end.

And number three, what we also did is merging the two dev and ops silos organizationally into one. That's something we did at the beginning of the year. So we now have really an organization with 1,400 people, DevOps together. And that's something that is the new version of our strategy.

That's still in German. That's still in German, I think. That was the version, the slides we didn't want to show.

Anyway, what was a core part of our transformation is involving employees and also managers on this transformation. So what belongs to that, for us, is complete transparency.

What we did is admitting also that all the way to this pole star, DevOps pole star, is something we don't know yet all the details about it. Plus also, we shared all the details about the cost savings agenda that Christoph mentioned before, these 30%, and all the details about it with the teams.

And that was the first time that the details of cost savings were shared with teams in our company. It was a bit of a shock at the beginning. But then people also appreciated a lot this openness, and it built trust.

So this is part of a stronger cultural change that we have to do.

But also, this cultural change is something that turned out to be the most difficult part of our transformation. For example, if you share the details of cost savings with the teams, this builds up a lot of trust. But on the other hand, of course, this is related to the fact that people also lose their jobs in some cases. And that obviously also causes some disquiet and some concerns in the organization that you have to handle.

So cultural change, building up trust, also communicating, cooperating, for example, at eye level in interdisciplinary teams, that is something that people have difficulties with. Because in the past years, or even decades, the focus was on achieving their own silo goals and not achieving shared goals together with the business, for example.

So this is why we also developed the DevOps Charter together with our people, in order to have a clear understanding and also joint understanding what this cultural change is about, what is the pole star of our culture at the end here.

And this also clearly requires a strong change in our leadership. Because our leadership today is more top-down driven. They are coordinating, they're supervising the teams. But what we need in the future is trainers, as entrepreneurs who empower their teams and really place trust in them.

And that is a challenge because many fail to accept this change, or at least they are not good role models for their teams because they haven't really got used to this change.

But we are convinced that we have all the people, most of the people that we need for this leadership. They need to change, they know that, and probably this requires more time, a bit more patience, and a lot of dialogue with the people to really embrace this change.

Thanks.

Christoph Schär

Now, what are some of our key levers we used actually to change the organization and to adopt this new culture Jens was talking about?

If I look at this picture, I don't know if this situation seems familiar to you. Same users want to use the same resources at the same time. If I translate this to traditional IT, it will mean that we have several major business initiatives or projects having the demand to do some major changes on the same systems, contacting the same key person at the same time, and all of them are pressing to the same major core releases.

I stop right here because this is not the future of software engineering.

If I look at this picture, our first major change is based on the fundamental recognition that Agile holds huge potential to achieve our corporate goals I mentioned before, meaning a higher ability to react on market demands with stable quality and stability.

So now, what's the key fundamental of the Agile way of working? It's not the method. It's actually the Agile Manifesto, or I would say it's the Agile thinking. It's an Agile DNA that you use, and that's the key success factor from my point of view to change the way of working from a long term.

And if there are organizations, managers, teams that still only equate Agile with Scrum, as it sometimes happens, I think they still have a long way to go. They did not really internalize the fundamental principles, nor did they change really their culture.

And on top of this key fundamental, I see four additional elements that are key for this new way of working.

First of all, it's really focusing on generating business value with each iteration, and this instead of having long-running projects only delivering business value at the very end.

Then second and third, it's the product orientation and additionally, the accountability of interdisciplinary or cross-functional teams for the whole lifecycle of a product or a service.

And the third one here is the continuous delivery of product increments to get very fast to the market, to the customers, to take feedback and responses very often, and to be able to adapt to new demands from market side.

And this was actually our launchpad for the transformation.

On top of that, we knew that this new form of working together is also calling for a new form of organization. The classical way of organizations having functional units or functional silos, having a top-down steering and controlling, that does not really embrace this new Agile way of working. Nor does it foster the innovation power of all our employees we are having.

So for us, it was clear that we need a new form of organization that focuses on generating business value on the one hand side, and that needs to be interdisciplinary on the other hand.

And therefore, we were inspired by the Spotify engineering model and their squads and tribe approach. Looking at that in more detail, what distinguished this approach for us is the central product orientation in role and structure. You can see it here, with the central position of the product owner and the product manager.

Then second, it comes along with a lean setup, mainly regarding the number of roles, and there in particular, regarding the leadership roles. So hierarchies are of minor importance. For instance, we don't have any more team leaders or department leads in the new organizational form.

And the third one here is actually that we have a cooperation at eye level of all the different roles.

Now, we have seen this picture already yesterday. We talked a lot about Agile so far. Now, what's DevOps? As you can see here on the picture, there are a lot of different interpretations of DevOps. And so was it as well within our organization when we started about two years ago. We had different interpretations of DevOps.

So what's our interpretation? It's still Agile with interdisciplinary teams in the center. That's the first. On top, we have the six continuous capabilities, which cover the whole lifecycle and cover the whole value chain. And there it's actually vital that we implement those continuous capabilities standardized and automated. If we don't do, we will simply increase the manual effort within our organization.

And this combination of Agile teams and the continuous capability is our interpretation of DevOps.

To support this transformation, we established a holistic maturity model. This model takes into account that our teams, all of them, have a different continuous improvement journey. They have a different starting point, they have different priorities driven by their market needs, and they have a different context. However, they all have the ambition to reach the digital mastery.

We applied this model in March this year and made all the results transparent, so that the teams can learn from each other. And the teams used the results to define their own goals for the transformation of this year.

Now we talked a lot about Agile and DevOps. What's our next big challenge? It's to scale all that along the whole enterprise. And therefore, we use the SAFe framework as orientation.

What we learned so far, that there is a pitfall to slip into anti-Agile patterns in defining too many roles, too much structure, too many decision boards. And what we are doing there is that we are using the model very consciously, mainly focusing on benefits like establishing a lean portfolio management, which is actually fitting the Agile way of working, and using the elements like PI plannings to synchronize dependencies along teams and on program level.

So far, we have two big learning fields here in the case of the scaling. The one is the cloud development, and the other one is the product development for the whole small and medium enterprise customers. It's a $1 billion business. And there we are really doing business, development, and operations all together. So we call it as well BizDevOps.

Jens Wilhelms

So coming to the last part, and I think I need to speed up a bit. Where do we stand today? What have we learned?

One thing is, if you compare that to the picture at the beginning of the presentation, the business who is applying Agile and DevOps with us is a lot happier with our results.

If you look at it from a more measurable point of view, for us, it was important to really deliver the goals in our first year in all of these four dimensions. Delivering the required output with high quality for the business, even during the transformation. Learning how Agile really works, scaling Agile and DevOps to more and more areas, and also into the business, from IT into the business, and then harvesting the promised cost saving, let's say also for the management.

So that was important and that was encouraging for the first year, but we also faced a number of challenges.

One of the key challenges is certainly the attractiveness of Agile and DevOps. A lot of people wanted to follow, and they did, but they did not necessarily do it correctly in a way because that requires a lot of change in the organization and the teams and the way of working.

So some people, for example, or teams started to call themselves squads, saying, "Okay, we are now Agile," but in fact they were not cross-functional at all. So we have a variety of things where people call themselves Agile or DevOps, but they're not really.

So what we have here is a conflict between the autonomy of the teams on the one side and the alignment that the organization also needs to really scale. What helped us here is certainly the DevOps maturity model, what Christoph showed before, but also having Agile and DevOps coaches working with the teams and taking care of this minimum alignment.

Another one is it takes a long time for teams and people to embrace the whole transformation. And that is something you see not so much at the beginning when you have the motivated people who have the right attitude. But if you scale to the whole organization, that is something that really gets difficult, to convince people who are really skeptical towards these new ways of working.

So what have we achieved? Certainly, we have climbed up the hill that we saw at the beginning, but we are somewhere in the middle if it's about climbing up this Swiss mountain here. And we know it's a long journey still to go.

So this part of the journey is what we showed you at the beginning. Why did we do that? How did we do that from bi-modal to DevOps? But it's still a long way to go, and there are good learnings that we have picked up during this journey that we would like to share with you, if you want to also after this presentation.

But we are aware if we come back, for example, next year, there's a lot more that we can share and that we have learned by then.

So thank you very much.