00:00:08

Hi, everyone. Welcome to the cell app, enabling DevOps in mobile ecosystem presentation. This presentation goes around devastated formation that we are currently running for shell, uh, for the most, uh, famous applications they have in the market. At the moment. Uh, the logos that you can see here in the left is of course shell logo, who is the client that we had working with liquid studio, which is a department that is specialized in DevOps enablement, the devil's delivery and full stack engineering and Accenture interactive the creators of the application from the design point of view and implementation here in this presentation, we have some drafts as DevOps, enterprise architect from shell hello, boss and myself, both of us by myself are, uh, from liquid studio. We are DevOps architects within that. So one let's start into the context, what we got from the beginning. Well, basically sell at a certain point when they were already quite mature in terms of agility, when all the teams were working in a grand manner, and they were really seen the application, uh, every couple of months, they were looking for a way to increase the business agility.

00:01:33

Uh, they wanted to increase, of course, they, with the quality and satisfy the customers in a faster manner by reducing the time to market. So basically increasing the value. So within these three points, we thought, okay, is there anything we can do to achieve them? And we can see there obviously DevOps because at the end, DevOps is made for that. This is the spirit of DevOps, these three boxes. Um, but well, as you can imagine, uh, there is a lot of doubts about what is DevOps and what it's not. So any Sally, one of the things that, uh, we were asked was to do the CICB the famous pipelines that we are always doing here and there, continuous integration, continuous delivery. However, I don't think that with CACD, we can achieve the three goals we define at the beginning. And therefore the first thing to understand is dev ops.

00:02:34

When do you want CACD do the one DevOps? Do you just want him to mention when you want DevOps, you want out of all the things like the organization of the teams, the way of working the processes and building the business, the development and the operations all together, the architecture, this is when you are going to be able to really break these three points, being able to react to the market in a faster money out and give the customers what they are looking for. Um, if you only do, TICD hardly ever you're going to reach everything. And of course, uh, CACD is the most important bracket disease, or one of the most important practices within DevOps. So it's going to be, um, embedded there, but in order to take advantage of them, you have to change a lot of all the things. This is how it is. And well, it's something that we like to do that. And that's when things catch the challenges because of politics and other things, it's not only technology. Um, but it's, it's how it is. However, there are a couple of difficulties and something to align with the client at that point.

00:03:38

Uh, yeah. So thanks. Giermo um, now that we have established that we actually don't want to focus on CSET alone. Uh, we want to benefit from dev ops, um, as a different way of working. Um, we're going to phase a little, uh, a few different challenges, um, than we originally, uh, were thinking about. Uh, and we'd like to think, uh, of these challenges in three areas, and then we have the people we have to processes and we have to technology. Um, and we focus on people first. Um, people are most important thing we have, it's the most valuable asset, um, without the people who are nothing, basically, especially in today's world, in, in, in the digital, uh, world. Um, and then we're going to think about who they are and what they do. Um, so we're talking about things about, uh, as, as common goals, uh, team composition, um, coaching of course.

00:04:37

And, uh, one of the most important thing here is trust. Um, and then process is all about changing. Um, how do people do the things, uh, right. Uh, things like self-organizing teams, uh, outdated or incompatible policies mainly for delivery, uh, think about manual stuff, uh, that, that there's, is there a, because full of shit and not because of, um, uh, limitation, uh, things about security, uh, outdated or incompatible, uh, security policies, uh, the way people communicate, their stuff, uh, report or stuff. Um, that's all a, this is all processes. And only then we're going to think about technology because we feel technology is only there to support the people and supports the processes to work in a devil's way. Um, in other words, the technologies we are using, uh, or building, uh, for dev ops are dictated by the requirements. Uh, that's the transition, uh, on the people on the process site are requiring.

00:05:39

Um, and that's not so traditional way to approach digital transformations. Um, typically these things can't take years, um, you see a poll from, uh, Gartner, uh, where it occurred a lot of fortune 500 companies, uh, about the state of the digital. What about to state off the digital transformations they are, uh, doing or have done in the, in the last few years. Um, and you see that, uh, three out of four transformations are not even halfway done. Um, so dare not even delivering any value, um, but traditional fusion implementing digital transformations, uh, are, are, are for long-term projects, uh, especially traditional fuels, right? Uh, especially in the digital world, uh, that means that you are outdated and irrelevant, um, by the time it's complete. And then the mainly on, on, on, uh, outdated ideas, outdated, uh, tools, uh, or irrelevant ideas and tools. Um, and therefore you want to, uh, add like the transformation value as soon as possible. Uh, and this in small increments, uh, basically, uh, you want to apply the devil's way of thinking, not only to what you apply, but also how you apply it. Um, the few expressing this slides fairly traditional rises, it's, it's a real recent case that was applied at a big firm. Um, so, um, uh, it it's to show that in the current world, we're still approaching new things. You know, it's an optimal way.

00:07:17

I totally agree with you with this point of trying to avoid a protein, a transformation in a waterfall monitor, because otherwise you are not going to see any results in the short term. However, that is something that's what you need to define a starting point. Um, we are always running data information in following these, this domain of, uh, assess plan implement and improve that of course can sound a lot of waterfall is a way of implementing. However, we are not really doing like that. Initially what we did in shell is okay, let's focus on the assessment and planning. Um, within two months, we need to understand what we have in France, how the teams are working in the technical domain, in the business domain. So we stay with them, sitting up with them, working with them, just really understanding what they were doing, what type of practices that we're following, what type of practices they were not following, what type of tooling they had, or they didn't.

00:08:15

So really understanding the, the current situation basically, well, just know what we have there. And then of course coming with the plan, because it's specifically for the business, they want to know what what's going to happen. And it makes sense to have some planning in order to understand, well, those are the actions that we are going to take based on the inputs, based on the assessment that we would run in, those are the most critical points to cover. And basically this is how we approach everything. Um, some of the deliverables coming from Kira architecture designs, roadmaps devotion vision for the whole company, because of course you need to have an alignment or the governance, even a proof of concept just to show, okay, this is how everything could look like. And after that, this is when we will move into the implementation as a one that will go later into the presentation. But first of all, let's focus on this assessment and planning and let's see what we found from it.

00:09:16

Yeah. But let's take a few steps backs, right. Um, what's the context of this transformation? Uh, what apps are we talking about? And, and, and w w w the, what tender, who, um, so if you go on your smartphone right now, well, don't do it right now, um, after this talk. Um, but if you search for the shell app, you find one app and us, the app that we were talking about, um, and on the screen, you see, uh, see some, uh, context about, about this project, because there's not a little, little app it's, it's, it's a, it's a big app is used by more than a 1.5 million users each month, uh, in almost all markets that shell is active in. Um, so technically we're talking about six programming languages, um, while that means that it's, it's, it's, it's a really big, uh, technical, uh, thing, uh, especially in, in, in the, if you talk like the technology side of dev ops, that means that we have a lot of, uh, that we need to have a lot of technology, um, to, uh, to, to support that.

00:10:15

Um, there's, there's more than 15 components. So, uh, if you talk about micro architecture, uh, stuff like that, but there's also some, um, some, some legacy, uh, monolithic components. Um, so there's more than 100 people working in this project, uh, in more than four countries, uh, in the world. Uh, and they're working together, uh, in, in, uh, in old ways that you can think of, um, mainly, uh, like we do right now, all, uh, uh, old because of the, the COVID-19, uh, crisis, um, remotely. Um, but there's also a lot of, a lot of traveling happening, and that means a lot of, uh, communication and a lot of, uh, alignment.

00:11:03

Okay. Um, there's a lot of things that we want to measure, right. Um, lots of things that we want to see going well in, in, in the scope of the different position. Um, so there's a little data and you don't want to guess that data. Um, so from good Def practice, we want to have reliable and transparent data to base decisions on. Um, so early on in the attrition process, uh, we have the tendency to run with people's feelings about how things are, or like guesstimates. Um, but typically those numbers are clouded by false assumptions. Um, so measuring things is very important. Um, there are a lot of things we can measure. Um, so then it's really hard to decide on what you want to measure and what makes sense to do, um, because to re really understand the, uh, what the numbers are saying. Uh, you need to know what they mean. Um, so we're measuring things, uh, mainly for us, uh, the teams, um, not to report to higher management, there's a whole different story. Of course. Um, we, we want to have the numbers to base decisions on, uh, about what's delivering value and where is the failure, uh, to be found in this whole transition, uh, process. Uh, so once we have these KPIs in place, uh, and we have some workable numbers there, we can move on to the next phase.

00:12:25

Yeah. And next phase is basically getting things done. Does the one, when the beauty starts, when really they action happens, we as engineers, we of course like to, to make things happen, uh, and solve the problems. But yeah, so things that we came out from the assessment and planning are just basically what boss mentioned, we've been able to understand what was the landscape of the application, something that at the beginning, we had no idea or defining how we want to measure success, how we want to measure that as inflammation goes well or not. And yeah, from that point, it's the moment of really taking action. Am I taking action? We mean implementing and coaching everyone into the present technology that we defined previously during the assessment and planning something very important to consider and something that sometimes what I've seen, places where it's not considered different technologies might deserve different tooling and different way of delivering.

00:13:29

Same as different teams, different ways of delivering. There is no one size fits all in, in, in this scenario in dev ops. Most of the times he's once he's faced one or couple of them, but not everything. So that's how we did it. Here we create is, first of all, I'm an architecture reference and reference that shows not only the delivery and doing delivery steps, but also the technologies and how they are going to be approached. And then box by box Daria was to go and implement all of them based on the customer needs of usually and customers. In our case, out of the actually, uh, developers, testers are British and our guys business, those are our customers and how we approach it this way, how we execute it, this, uh, action. Well, just think about that friend that you have that, well, you didn't see him in six months or one year when you see him, you really think like, oh, that person has a lot to do.

00:14:34

They have a beard? Do you even have heritage in your head? And you don't have it anymore? Well, uh, we don't want to have that feeling. We want to work in a manner of a continuous way of working. You don't see the change from one day to the day after you feel like nothing changing, but a lot of things are changing, but we don't want to disrupt you in that manner. And then when you look back six months or one year back, it's the moment when you see like that person it's bald or, uh, is actually, uh, have been a big change for him. This is the day how we want to do it, and this is how we are doing it basically. Um, one of the things that we, we covered always is the, uh, the, you said the needs of the people. That's the first thing to start with.

00:15:23

First of all, we need to understand what people want to do and how they want to do something. And then we use technology to achieve that goal. We don't want to go, uh, and fall into the waterfall way of transformation that we defined at the beginning, because that will be a big mistake. Um, you want to approach it in a, that there was some information in that dev ops monitor, which means not continuous. Wait, why we do that? Because imagine that you are going to change everything and suddenly the moment you change is after one year after one year, you have kind of a big bang of a change where do enable all the automation and all these type of things. That will be a big challenge for everyone to understand and, and, uh, take a part of that. So that's why we work in a different manner.

00:16:11

As mentioned, we understand the user needs, uh, we support their needs with technology. And we do that with every week. We have the global vision of covering the three points we mentioned at the beginning, which is the business ideality, the quality and the customer satisfaction. We define what their goals to have some targets, but then every week we are changing the priorities, understanding what there've been new needs and implementing these situations. So basically what we do every week is, uh, go though with the people, understand what they need, implement a solution that fits and can solve their needs, handed over to them, uh, handed over to each of the teams. So they really can, uh, give us the feedback in terms of if it's what they want or not. We have to change it. And then we hand it over to them. And this is the moment when these teams are becoming DevOps.

00:17:03

We are not here to do all the delivery reactions for them. We are here to let's say, uh, build the car that will build their, this first structure, and then let the teams drive this car and do the things it's making them become in DevOps is enabling DevOps for them. Uh, as an example, let's go to a hotfix development and delivery. Um, I'm gonna compare what was the situation in, in non dev ops versus the current situation on dev ops. And I'm going into a hot fix because it's something that is crucial for customer when something doesn't work fine, and it could be a bug, but it could be also performance. Uh, this customers needs to have a solution as soon as possible. So let's go into this scenario where we are willing to implement a hot fix, uh, that will take three hours of development.

00:17:53

And it's going to have two unit tests, one book at level code, and also we are going to put their deployment issue. Um, actually there was a every scenario that happened. Um, if you see the guff there in the access, you see the time diamond, meaning it's how much time it took to run everything. Uh, and in the Y axis, you see the different delivery steps from implementation to, uh, the testing to the fixie, to reimplementation to, uh, check in validation as a one while in a non dev op situation. It was taking a lot of time, uh, more than two weeks to be able to deliver the outfits because we were waiting a lot for, uh, having the actions done. So despite the, the, uh, implementation could be fast and then testing event, we had sort of automation here and there. We were waiting a lot between, uh, the different delivery steps between step and step between let's say, implementation and testing and revalidation and retesting.

00:19:05

Uh, we will wait in a lot of time and this is why it was taking, um, huge stems to, to, to deliver a result while if we do it in a DevOps manner, uh, everything is in a continuous manner. You implement the three hour Scott fix. Um, then, uh, everything is starting to run continuously, and then you are going to spend some time on fixing lunch one, but it's a fixed that you are going to apply, apply over something that you develop then 20 minutes earlier, not something that you develop three, four days earlier. Um, some of the big things, uh, that we gained from this way of working in DevOps is obviously the speed, um, even more than 23 times faster. Uh, but one of the things that I would like to mention is, uh, the broken develop branch, uh, in a nonverbal situations, we were putting code that was not, uh, properly working, uh, in a development for 50 hours.

00:20:06

It means for a one week, um, DevOps, as we said, it's not about technologies. It's about changing the way we work. It's about adopting new practices, um, practices that makes everyone be more efficient. And this was one of them. Um, the branching strategy, something that would change, there is no that much technology around it is just a way of working. And in the non DevOps situation, we were just placing code there that was faulty. And then we had to fix it. Uh, and the thing is we were putting a faulty code there in not only from one level, but from multiple developers. And then at the moment you have to fix something, you have to deal with a lot of code from other people. And that could be tricky that could really result in, uh, in, in efficiency. So that's why we gain a lot of speed and also a lot of quality.

00:20:58

Uh, some of the other benefits we, we got is, uh, what traceability on releases, understand what we are going to deliver it and where, and what type of version we are, would in place business, uh, involvement into the delivery, uh, by one-click approvals, for instance, or automated communications. Also real-time alerts something quite useful to understand the situation so that for we, uh, we implement a lot of, uh, solutions, not only in technology, but also in the way of working in the processes. And of course, in our cultural aspects, in, in the, the mentality of the people, as it's very important to adopt this new way of working, because it's something new. Um, and it still, we have a lot of things to do. Obviously, uh, dev ops is in our case, our continuous improvement, uh, activity would, that is not interstate, but a better one.

00:21:50

It's just, you always have to do things. There will be always something to improve. Um, currently we, uh, have implemented CACD for all the teams. We, eh, involved business into the, into the delivery pipelines. We increased, uh, like six, seven times the amount of testing and executions we are, we are running, uh, but it's still, uh, we want to do more things. And the next steps that we are going to cover is the implementation of device farm for further testing, testing in the cloud with physical mobile devices, uh, something quite cool, uh, something that, uh, we are looking for, what to implement advanced really surface duration, uh, next steps on monitoring and alerting to really ensure that the application is always working and, uh, not only from functional point of view, but from performance point of view and a very wood way. And we will put as well, uh, some teams acting as a Surrey because now that all the teams are DevOps, now that all the teams are able to implement and deliver themselves, it's time to go to the next level.

00:22:57

Um, one of the things to mention is, of course, you might think like a, why you even start from monitoring, not from an operational point of view, and you focus initially on the delivery automation. Well, basically these, because that was the, uh, the big net of the teams, uh, we already had in place. And we already have it at the moment, a good support. Uh, the application is almost having no issues, but of course there is always things to fix, but we were looking for the spinning of the teams and converting them into dev ops. And as we said, we focus on the, on the needs on the, uh, people needs in our case, uh, our development and operations, our testers, our business guys needs. And then we implement that way. Um, what, uh, that's basically all, uh, if you would like to know more, feel free to contact us by, uh, reaching out by email or connect with us in LinkedIn, or you use any of the conference centers years, uh, has been a pleasure to present this scenario to you. I hope to see you again in the future. Maybe not in that, they it that way, but now presents our way who knows. And I will be glad to give you the, the next level next inputs. What happened afterwards in, in shell, in the shell app, what's the next steps and show you the evolution that we are doing. Thank you very much. Thank you, Sandra. Thank you, BAS uh, and thanks audience to be here.