Europe 2022
Enabling IT Operations - Transforming to DevOps
A new experience story about a Programme set out to enable and transform IT Operations for DevOps.
DevOps has largely been driven by ‘Dev’ and there has been a general feeling in Operations that DevOps has been ‘done to us’. This is an opportunity to share that Operations are here at the DevOps table and we’d like to demonstrate how this different approach to transformation can work.
We’ve got the same ambition. and we’d like to encourage others to closely collaborate with their Operations counterparts to achieve true DevOps harmony.
MC
Moira Cheng
IT Operations - DevSecOps Transformation Programme Manager, Vodafone
Transcript
The first talk for today is from Moira Chang, who is dev SecOps transformation program manager at Vodafone, a global connectivity and digital services provider that operates in 21 countries. She is part of the one tech team initiative, which is a plan to add nearly 7,000 software engineering roles to its expanding European technical workforce by 2025 through a combination of recruitment, reskilling, existing employees, and insourcing. What is so interesting about this initiative is that a specific constituency that they are targeting are the existing 2,500 it operations staff across the enterprise in an era that is increasingly reliant upon cloud services and platforms as a service. This group is often at risk of being left behind whether perceived or actual. There was something about this initiative that appealed to Moira, and she had just attended this conference last year, just as she was starting in her new role. I think this is such an amazing story for so many reasons, because it goes beyond just training and education, but creates a community of ops practitioners across Vodafone that are helping each other on so many different fronts to make sure that people are relevant both now and in the future. Here's Moira.
Hello everyone. My name is Moira Chang. This is my first presentation at the DevOps enterprise summit. And I'm honored to have been given this opportunity to speak to you today. I'm here to tell you about an approach to transformation and how we're enabling Vodafone's it operations function towards transforming to DevOps. But first let's start with a little bit of an overview of Vodafone. Vodafone is a global connectivity and digital services provider, which has operating companies in 21 countries. Vodafone technology alone has around 34,000 employees across digital and it network and other supporting functions included in this are shared services centers operating under Vodafone intelligence solutions or voice for short across India, Portugal, Egypt, Hungary, and Romania. We'll dive in deeper into digital and it shortly Vodafone serves both consumers and business customers. Most of you may know, Vodafone is only a mobile connectivity provider. However, beyond mobile, we offer consumer IOT, wifi TV, device lifecycle, and other services for the home.
Vodafone is a world leader in internet of things otherwise known as IOT. Our business division serves public and private customers of all sizes, small office or home office customers, small medium enterprises, larger enterprise customers, which include national corporate public sector or multinational companies across ver and business. We provide a variety of fixed and mobile connectivity as well as unified communications, cloud security and IOT products supported by our global network. We provide services to many industries and sectors, including manufacturing, financial services, government and education, retail, and wholesale health, and many others supporting their day to day business operations within Vodafone digital. And it is our operations infrastructure and technology voice function we develop, deliver and provide operations support for the it systems and applications, which underpin those products and services for our consumer and business customers, as well as for our employees, if we narrow a focus just to European it operations, it runs in 12 European countries.
If you include Turkey and we have voice shared service technology centers in India, Egypt, and Romania, this makes up circa 2,500 employees. We also have a central supporting function, which I am part of as for a bit of background about myself. I've been with Vodafone for about 15 years coming through with the cable and wireless worldwide acquisition for a da decade or so. I've spent designing services and managing a team who design, how we sell, build and run our new enterprise or business products. I've collaborated cross functionally across many teams in Vodafone to bring together our technology, both network. And it solutions with people and process ensuring we can deliver end to end solutions through our internal teams and provide great customer experiences. It's through working on new product developments that I started to see a shift to DevOps about five years ago, it was one particular product platform team that started taking that leap in my role.
Then I thought what you want to build it and run it. It was an odd thing. Then we had teams that built and the other teams that supported it. But what about our ops teams over there? I initially thought you want to do changes without going through the change process and the change approval board. Okay, let's go and talk to our change management team over here and see what we can do in another part of our it delivery organization who developed new capabilities and applications for our employees to use. I was also exposed to another team who were bringing it delivery and it ops teams together. And I was impressed by how they began cross skilling across dev op teams and matured to be one fully fledged DevOps team. Over time. I've had some amazing colleagues, the earlier adopters who were willing to enlighten me on the DevOps ways of working the culture and its practices organizationally in April last year, Vodafone had just pulled together all of the digital and it teams with every European market coming under one roof.
And we effectively became one large it delivery in operations organization. One tech team in a press release in October, 2021, Vodafone unveiled its plan to add nearly 7,000 software engineers to its expanding European wide technical workforce by 2025 through nation of recruitment, reskilling, existing employees and insourcing. It was this time last year that I was offered further accelerate the insourcing and skill strategy by changing the way our teams work across dev second ops. And the program is created for two reasons to ensure that we, as it operations looked at how we work and our skills needed for the future. And two for it, operations play a key role with our other colleagues in other functions to shape how we evolve together, how well our aim is to educate, share best practices, collaborate with others and improve our overall understanding of DevOps with everyone on the same page, we could then work to harmonize and transform to DevOps ways of working across all our European markets and voice teams.
We had already lent a lot from the DevOps success in the digital space, but not so much so well in the, um, traditional monolithic or legacy it space. It was all very timely. I managed to attend this very summit last year. It was my first and what an immersion into the world of DevOps. It was, I came away in inspired and with a clear mission and a purpose, but I questioned myself, how should I do this? And I delve into three weeks of extensive research books, videos, websites, and blogs on DevOps, but there was really no magic bullet answer for what I wanted to do or achieve, right. I'm up for a challenge. I thought as I resolved to either find the way or pave the way. So research and discovery was a starting point for me know the problem before you dive into the solution.
As all my previous business analysis and service design training told me, the first thing we did was interviews with the markets and the ops teams to understand what their barriers were to adopting DevOps, ways of working. It became apparent that DevOps was perceived to be something that could only be done with cloud native solutions, more prominent with digital front end developments. We struggled to understand how to apply DevOps to hybrid cloud environments and other traditional monolithic or legacy. It solutions stacks. Our very rough analysis showed that our consumer segment was clearly leading the way in digital front end developments with majority deployed on cloud native solutions closely followed by hybrid it solution stacks enterprise front end still had about 50% deployed on traditional it stacks. And if we looked at both consumer and enterprise backend systems, the vast majority were still operating on traditional it stacks.
Now, why is this important? You might ask, well, with this data, the assertion is, is that our it operations teams are in their majority still running systems based on traditional it solutions. We have not yet gotten over the curve of modernization into the cloud as a whole. And from a broader perspective, we do not have the ideal conditions in which technically to enable DevOps and by which I mean the ability to use APIs C I C D pipelines or the optimal conditions to deploy small contain, low risk releases, fast into production. However, why couldn't we start applying a DevOps culture and encourage collaboration between our DevOps teams and try some DevOps practices. I questioned. The other challenge was a lack of involvement in agile projects. If operations teams are in the majority busy supporting optimizing patching and maintaining legacy or traditional it stacks, and in these cases still use waterfall delivery methods.
There are less opportunities for operations teams to be involved in and collaborate closely with development teams in agile projects, late engagement, lack of being involved in PI planning and agile scrums were common themes. The engagement with operations often still happen just before going into production or only when there was a need to change something on a live system or application. So how do we build a culture of Devon op collaboration when we're not presented with the opportunities for closer collaboration? Do our operations teams really know what working in agile is or means. I wondered looking across the organization. However, there were glimmers of potential. Those working with the digital teams had more opportunities to evolve to DevOps, ways of working. Some markets were more mature than others and regardless of technology stack and the lack of optimal technical conditions, some teams and projects did manage to display the right DevOps culture and were beginning to collaborate better together, but were not sharing their knowledge and experience widely enough. So how do we leverage the learnings and experience of those practicing DevOps today to markets and teams, which have yet to explore DevOps and its potential fully I pondered.
So we began to scope and shape our program in July, 2021. We understood that it would be best if we brought our teams on this journey together with us and even better if they didn't know about DevOps and learnt through this program, we asked for volunteers from across the it operations function from all markets and voice teams and through interest and word of mouth. We even found some more people experiencing DevOps who wanted to share their knowledge too. All we asked of those individuals, but that they had an interest in DevOps, no matter their experience levels, and to commit to some time per week to be part of our program. We were a zero budget program, which was spurred on by the buzz and curiosity of DevOps with a joint goal of wanting to build, gain knowledge and evolve, to be future ready for digital and DevOps. We identified that we wanted to break down our program into seven work streams, people, culture, and change team to apologies organizational models and role evolution, standards, and guard rails, measuring success, operations processes, and ways of working evolution, tooling, and process automation and security and operations. We defined OKRs for each of these streams and understood what outcomes we wanted to achieve. And with our first set of about 25 keen volunteers from across various markets and teams, we did some design thinking workshops.
We brainstormed and we prioritized a list of suggested deliverables. And from the market discovery sessions, we sorted through 63 challenges, map them into our work streams and prioritize our top 17 challenges based on importance and feasibility. We brainstormed ideas to see if the team could come up with any new ideas or deliverables that we hadn't already thought of. And we mapped all ideas and deliverables back to those challenges to ensure we would address the pain points to conclude our design, to thinking workshops. We did a Moscow prioritization. Now design thinking was quite new to the team. The volunteers learned something new and enjoyed the workshops for many. It was their introduction to the mural collaboration tool. It was a new way to approach ideation, brainstorming and prioritization. It's not something operations teams come across in their usual daily jobs. And the team appreciated being involved in shaping and contributing to ideas for what we would deliver as a diverse virtual team.
They began to become invested in the purpose and objective of the program and could see the potential of the outcomes it could deliver onto the program structure and delivery method. And from the start I intended for this program to deliver using the safe agile methodology, it would be a leap of faith. Many of our volunteers from operations had never worked in agile project before. I thought, if I'm bringing everyone on this journey of learning on DevOps, why not run this program in agile? And everyone will benefit from the practical experience of working in agile too. My inner voice started assessing the situation. The less optimistic side of me said, well, you've got no fixed team. You're not creating a product or doing a software or technical development. This is more of a cultural and way a working transformation program. Has anyone tried agile with this sort of thing before?
And the optimistic and competitive side of my brain said, it's okay. You can fix your capacity. If you know, the hours each person is committing, it doesn't have to be technical features. You can think of all of them as enable enabler features. And if you can size it, you can do it. You just match the volunteers to where their interests and the skills sit best let's experiment and try. I thought what's the worst that could happen. Hashtag fail fast and learn. So based on the years of working in agile projects and a couple of calls, I had made to a couple of trusted agile coaches for advice, they offered their reassuring support and I was confident it could be done first. We needed customers as stakeholders. We decided it best that we have one customer each representing a, an experienced market in DevOps B an inexperienced market in DevOps and C our voice shared services team who support multiple markets and had a real interest in ensuring harmonization of ways of working.
They would be our feature prioritization decision makers for every PI. I decided we need a core solution team people who helped to initially define and then refine our feature backlog created the solution context, but who'd also help with launching publishing and supporting queries for whatever we produced on top of that, we created, of course, our agile release train with three scrum teams. And we asked our volunteers where they thought they'd fit in best based on a set of characteristics and scope for each scrum. We defined our features about 10 of us dig diligently, spent two hours a day, about four days, uh, creating the initial set of features with descriptions, business benefits, acceptance criteria. At the start we had about 140 features, but by the end of it, we had about 86 validated features, but like any bad log, it keeps getting added to and refined.
And with our key stakeholders, we then agreed our MVP for the program. Now we won't go into any more agile program set up details. As I think this talk is more about enabling DevOps, but suffice to say we successfully prepared for and held our first PI planning event on 30th September last year. We're now in may and have just started our third program increment of delivery. So what have we delivered for so far? Well, one of the first things our team did was develop a survey. We wanted to find out what people on the ground thought about DevOps and dev ops. We also wanted to get a feel of whether the individuals were actively applying or practicing DevOps, ways of working and what the perceived barriers were to our amazement, roughly 1,300 people responded to our survey in November, 2021. That's just over half of our it operations global team.
And the re results analyzed gave us some great insight and one that would help shape our program, but also give us some measure for success for our program. Moving forward at a high level, the results showed that only 36% of those surveyed in the operations teams were practicing DevOps today. When asked about applying the DevOps culture in ways of working to their daily work, 52% responded that they knew the theory, but they weren't sure how to apply it in their day to day work. We asked what their barriers were to working in or adopting DevOps. 51% selected the combination of lack of training, lack of opportunity, and lack of knowledge or understanding. And 21% highlighted the lack of opportunities alone. We also asked how people manage their learning and innovation time. Only 31% manage the plan in their diary and stick to it. But 49% also said they're self-motivated to learn outside working hours.
And lastly, we wanted to see what everyone felt about change and their behavior towards change in general, over 90% viewed DevOps as an opportunity. And over 65% felt psychologically safe and empowered to seek, help and learn new things. The survey results really provided with, with some really great feedback to know that one, the individuals needed to learn more about DevOps and dev ops, but they don't really have enough time in their working day to learn about it. And two, they haven't really had enough opportunities to get involved in DevOps, and therefore haven't probably had the chance to apply the culture or adopt the way of working. And finally, three, they have a positive mindset and they view DevOps as an opportunity and our eager to learn.
So from the outset of our program, the intent was to create a knowledge base for DevOps, for internal reference, to try and gather as much useful detail on DevOps, which we could share globally. We started with the foundation, a playbook where anyone could come and view and provide feedback on DevOps and dev set ops related content we produce. So what's in this playbook by January, 2022, we had documented some guardrails, a holistic view on DevOps principles and standards. We took a look at our own operations principles and standards. We tied together some information from our architecture teams on DevOps tooling strategy, our software engineering teams on engineering principles, as well as our security team on security by design principles. Now on DevOps tooling, as you can imagine, in a global environment, many markets and individual DevOps teams were already having the autonomy to use DevOps tools.
They wanted, some were already heavily adopting and rolling out various C I C D pipeline tools with the guidance of our group architecture team who had a target architecture stack. We documented the recommended tools to be used for the entire DevOps lifecycle. This was to give everyone a clear vision of where we were headed with the aim to become a bit more harmonized and convergent on tooling globally in the longer term. Secondly, we needed to build on and explain team to apologies and how it's applied in Vodafone. We also needed to articulate our existing it landscape within Vodafone and explain the conditions and enablers for favorable and not so favorable DevOps ways are working. We looked not only at how our teams are set up, but the technical conditions, the training, the tool, the skills at a high level, and the intent was to help give others an understanding of what challenges they may have to overcome in adopting DevOps ways are working and how to recognize if the conditions weren't completely ideal.
But on the flip side, they would also understand how to identify when conditions were more favorable for successful DevOps adoption onto processes. We started off with a big hitter change management. We wanted to understand globally first, who, if any, had robust change management processes already fit for digital and DevOps ways of working through our analysis. We found that actually there were many workarounds being done to bypass the traditional change management processes. The workarounds range from logging bulk digital changes in advance or retrospectively in our it service management system to not logging any changes at all. We were still working. We're still working on the endstate solution for this one, but the intent is to have complete automation of release and deployments from C I CD pipeline tools into our its and tool such that we have a system or record for changes, but we shall have no more CAS and no need for approvals of non-service impacting DevOps changes.
Now, besides change management, we're also focusing on how we evolve our existing service enablement and service introduction procedures to better cater for agile and DevOps ways of working the old ways of issuing and tracking compliance of operational requirements in the waterfall approach with operational readiness checks and handover to go live procedures, they still need to evolve on measuring DevOps, evolution, maturity, and success as an organization. And we took a of a pragmatic approach to find a maturity model and assessment that works for us as a large organization. These tools are currently used to evaluate and benchmark our evolution towards DevOps adoption. By working collaboratively with our software engineering teams, we discovered we had different maturity models, which teams could use to assess ourselves. First software engineering had the delivery and engineering view. So the C CD to CI CI and CD and testing part OFS, DevOps lifecycle, but in operations, we two had our operations maturity matrix and our automation assessments.
Now, of course, if you look at organizational silos, both would be used completely in isolation. We thought what a great idea, why don't we merge the two and have them in one place for all DevOps teams to use in any market, let's have a single DevOps maturity framework and assessment. And the intent is if the DevOps teams have one holistic DevOps assessment, which focuses on the entirety of the DevOps life cycle, then it should enable better joint visibility, ownership, accountability for all the elements and foster the right dev one DevOps team mindset and collaborative behavior. We're also looking at doing something similar with KPIs. We want to enable visibility of all the dev and ops KPIs together as a unified DevOps KPI set. Yes, there'll be different levels of granularity required for different levels of reporting. However, with the right culture and having a full set of combined DevOps KPIs, transparent and visible to all, if it's viewed as a big picture objectively and not in isolation, and importantly, without blame, these will provide insight to identify opportunities for continuous improvement on people in culture.
Sometimes it's really the simple things. Where do people start when they want training on DevOps and dev ops? We have so many learning platforms nowadays with so much content. And in my three weeks of intense research, I manage to get hold of and list. So very many websites, articles, blogs, books, YouTube videos, official learning programs, sponsor technology, learning programs on specific tools, et cetera, and different markets and different DevOps projects also had collated some learning training material. We even have our official company learning platform and links to others too. So the first thing was let's create a DevOps learning library and a dynamic learning path for everyone to be able to reference globally the objective, to avoid wasting time finding out what to learn so that everyone can find it immediately and learn. And for those who have not been exposed to DevOps and DevOps ways of working, how can we spread the knowledge on approaches and things?
Others have tried successfully Q success stories. We would go on to publish our first set of success stories in March, 2022. We have quite a variety of approaches and different ones to start with. The first is a story about a digital app development, which really had a divide and a team topology of anti patent, a dev and ops teams in silos. The success stories about how both teams came, came together to foster a true DevOps team collaborative model. The second is a story about a legacy middleware application where you really wouldn't expect is an obvious choice to try DevOps with, but with modernization to the cloud and by applying SRE practices, the team successfully applied DevOps ways of working. And the third is a story about a team which went from a traditional waterfall development and deployment methodology to the adoption of agile and DevOps with C I CD pipeline integration.
So as you can see, these are variety of success stories, which will start spraying on the interest of others who do not know much about DevOps, one final challenge to share with you. Well, we felt we needed to provide some guidance to the it operations team managers, to understand how to transition and transform their teams, to be able to operate in this bimodal hybrid manner. And to explain bimodal hybrid a little bit more. I mean, that really, we were asking the operations to first continue working with their procedures like they did today for the traditional legacy. It systems. So manager instance, operations, user existing processes, and flows, et cetera, but also start thinking about agile and DevOps and start becoming involved in a new way of working. And it's a big shift, not just from a capacity and resource planning perspective to be involved in agile PI plannings plan and influence operations in the design and development phase, but also from a BAU incident management perspective, we needed to shift the focus from not just responding and resolving incidents, but to assessing and understanding how it could have been prevented in the first place, as well as importantly, feeding that back into the designers and developers to architect design code and implement.
We also needed to recognize that our new skills that we'd be looking to harness in order to mature and evolve our operations practices, the focus would shift to proactively reducing manual toil, automating as much as we can analyzing trends from monitoring, feeding, and providing those new requirements to automate events from early on in design or as continuous improvement activities. Now, by working with some of the more experienced markets, which I've tried and tested working in DevOps, we developed some guidance for operations team managers. It covers understanding the it landscape from within which they operate the different types of demands that might come into their teams, understanding the skills and trainings and tools that are required. Understanding the agile delivery structure and set up as a whole, which they're asked to be operate within understanding the DevOps team to apologies. They also ask to emulate and lastly, understanding what transition stage you're in and where they are on this journey to hybrid or bimodal ways of working.
We then created a transition journey framework to help the operations team managers identify exactly where they are on this journey to DevOps and how to identify opportunities for their team to start piloting or trialing DevOps experiments or projects. For example, if we're insourcing some development or we've been asked to take on more operations managers, uh, management, also insourcing more ops, then this is a clear opportunity to start with a DevOps first mindset and culture. And if we're upgrading some of our older technology stacks to the cloud, we can begin to transform how we're doing dev and ops. And this too is an opportunity. Alternatively, if both dev and ops teams have been working together, but in isolation for a while, how can we foster a better DevOps collaboration culture between them? So it's small steps to start, but they do count a one DevOps team mindset is really key to building relationships and harnessing collaboration.
So the barriers just come down naturally. So now here, I need to state a bit of disclaimer. We've not yet thoroughly tested our transition journey, framework and approach mentioned, but we're merely at the starting line. And I'd really welcome ideas from any of you around this particular topic. But by giving the operations team some guidance to start applying the theory and a structured transition and transformation approach, we're hoping our teams will feel better informed and more confident to try and adopt and experiment with DevOps, ways of working alongside their development and delivery colleagues. But the key to all this though, is people collaborating across all development and operations teams to work to how we'd like to shape and work together in future. And if some are already a step ahead and have some numbers, some answers, sorry for everyone to openly share and leverage the knowledge we already have.
So we've done some foundation work we've got so things down paper, we have an approach to transition and transformation, but now for implementation or as the product teams would say, it's time to go to market and launch some of this stuff. Now, thinking ahead, we've already introduced a method and process for feedback and continuous improvements on the content that we've produced in our foundation playbook, we're working on our next set of 15 features for delivery right now. One area we're really keen to focus on for some further experiments is a topic of site, reliability engineering and its practices for a large organization with a mature operations function, the discipline and practice of SRE very much aligned to objective of operations. As a whole SRE practices are methods are much easier to relate to by operations team members and therefore they help make the DevOps leap a little bit more palatable, understanding error, budgets reduction in manual toil, increasing automation and having properly defined and measured SLIs SLOs SLAs are common best practices and operations teams can easily leverage and apply SRE practices, taking its findings and suggesting improvements to drive better DevOps collaboration with our software engineers in delivery community, identifying where we could apply SRE practices to better existing legacy and traditional it solutions will help us accelerate and bring us a little step closer towards a more complete adoption of DevOps down the line.
Also important for scaling our program and its learnings will be our DevOps ambassadors. We've put a call out in every single one of our markets and locations for individuals who are keen on the topic of DevOps and have an interest in networking within their geographies who want to see this transformation succeed. Our DevOps ambassadors will not just share and promote our work that our program is delivering, but they will also be key to identifying and providing some guidance and support for DevOps pilots or experiments and opportunities within their markets. Crucially, the ambassadors will be providing our program with continuous improvement, feedback lessons learned and contribute to new challenges or ideas that they need our support to address. So we're continuing on this philosophy of the more, the merrier on this journey with us and slowly but surely, we aim to create a continuous learning experimentation and sharing culture across all our markets and teams.
And in line with that saying the more the merrier, you'll probably now understand why I'm sharing this early view of our transformation journey with you. Firstly, I Hope's provided you with a bit of a different perspective from the upside of the fence, and now you can probably relate to some of the challenges we face. Secondly, if you are in or part of a delivery or development function, I really hope this talk inspires you to reach out to your respective ops colleagues, as I'm sure they equally want a more collaborative DevOps relationship, but they just probably don't know where to start discussions. But if you could start with a mutual objective, something like, well, how could we help each other reduce MTTR? I'm sure this will open up many opportunities to work better together. And third, if you agile project managers or scrum masters, please do try and engage your operations teams early on as they would really benefit from being involved in agile ceremonies and closer engagement with the delivery teams.
And if you're a product owner, you may just well start to see some feature requests to be built in around design of non-functional requirements, features around performance, capacity, monitoring and automation. They all do need to be prioritized proportionately of course, against product development features. And lastly, if this is all completely new to you and like me last year, this is your first DevOps enterprise summit. Well then I hope this session has been useful and informative. You now have a couple of insights on what we're doing to enable better learning and sharing of DevOps practices from an it operations perspective, I've shared some practical things we're working on to enable better DevOps collaboration and to remove some barriers between dev and ops teams. There's no magic wand or spell to transform an organization or a particular function towards DevOps. There's no one way or right way, but what I've presented is a way, so don't be afraid to try something new or different and experiment.
And finally, to close the methods I've shared here on how we're enabling it operations to transform to DevOps in Vodafone AR well, um, how should I put it quite creative and experimental with the use of design thinking and agile with a zero budget program and volunteers. And I would love to hear from any of you who want to share your feedback on your own transformation experiences to DevOps in particular, if you've had any operations journeys to DevOps transformations, where you battle with traditional it stacks and set ways of working and brought the old into the new. But also if you've got any insight on how you've brought in external vendors on this journey, I'd be grateful for the guidance. If you've been down any of these roads, I'd genuinely love to hear and learn from you. Now, I hope to be back here next year to tell you how it's all going. But in the meantime, if you want to connect, please contact me via LinkedIn. My contact details are on the screen and final. Finally, I'd like to leave you with a short video from wan and collaborators. I thank you sincerely for the time you spent listening to me today and I hope you've taken something valuable away from this session. Enjoy the rest of the summit, everyone. Thank you and goodbye for now.
Hi everybody. I'm Ben Connolly, head of digital engineering in the UK and head of what we call cloud engineering globally here at Vodafone. Uh, we've been on a journey already for a, a few years now from a classic telco to primarily a technology business that that happens to be in the communications industry, uh, for a few years now. Uh, we've been making some really great progress, uh, in lots of areas of the company, uh, and we're already seeing some amazing results, um, in terms of release frequency from once to month, to all day, every day, uh, and from MTTR from hours to minutes. Uh, and, and even the fact that we're talking about these concepts and the fact that they're so well understood across the company is, uh, is really a great sign now. Uh, but with Mora's leadership, uh, this initiative in particular, uh, we can connect all of these pockets of the company and truly drive, uh, a cultural change, which will form the basis of a, of a really sustainable and meaningful transformation for us now. Uh, so I'm really looking forward to taking this to the next step. We've been working with Moira and the team for a little while already. And, and the head of steam we've created together with ways of working automations collaborations. It's really now helped us blast through, uh, a lot of the inertia that can appear in a, in a transformation like this. And it really feels like the whole company's behind us now. So can't wait for us to come back and, and to show you the results.
There are three reasons why I'm proud of this program. Number one, it's driven by our people for our people. They are empowered and engaged to shape their own future around common goals that they have set. Number two, we've reached out to teams across the business, working on their own DevOps programs, looking for ways to help them succeed rather than simply claiming that our approach is the best one. And number three, we've given a stronger voice to the operational part of DevOps, which in my experience is not always the case. People enjoy working on this program. They're not being forced. They all volunteer. This is largely down to the energy and inclusivity that Moira has brought from day one. Well done, Moira.