Continuous Delivery And Continuous Design

**Guillermo Martinez: **Hello, everyone. Welcome to the conference about Continuous Delivery and Continuous Design with Miriam Soesan and myself, Guillermo Martinez. I'm leading DevOps in Accenture and in Accenture Liquid Studio, we always work in a DevOps manner and we always find quite a lot of similarities between DevOps and UX. And the talk of today is how these two words relate with each other and how the collaboration between DevOps and UX can really make things work.
First of all, would like to explain a little bit what's DevOps and what's UX and how they are combined. Probably you heard about DevOps, you heard about Agile, you heard about customer centric. You heard about all these companies in Silicon Valley, where they are always focus on the customer value. The similarities between DevOps and UX is that we want to bring value to the customers. That's the most important thing we want to bring customers what they want. However, when we work in DevOps manner, it means we have to do it as soon as possible. There are three principles in the world of DevOps, which is speed, response to change, and innovation. If we think about them, they are quite in line with the customer experience. Speed because of course, we have to be the first ones or one of the first ones delivering the new value to the customers. Response to change because we need to understand and we need to bring the new functionalities to the customers; therefore, we should be open to change and to deliver different functionalities features or any other improvement and innovation, that's also a clear point. We like to see things. We like to see things moving. It's important to innovate, it's important to be creative and being able to deliver new value to customers in that manner. Therefore, these three principles, they are quite aligned between DevOps and UX. And we can use a couple of references from famous companies like Netflix, Fidelity, Google, or Amazon, that they are the top practitioners in the world of DevOps and customer experience. They work in a focus of customer experience because of course the customers had a first for them, it’s very important to bring the needs to them but they want to do it in a manner that is quite cost effective therefore is kind of cheap, they can do it fast and they can innovate without big issues. They can continuously bring a new value. And now that I mentioned value, okay, what's customer value? Customer value is basically experiences. That's what we want to bring to the customers. They can be functional like features or the voice of customer, or they can be technical. If we think about an experience in front of the customer, we can think about the role, what functionality that they are looking for and improvement or something experimental that we want to see if it makes sense. And if it's good for the customer and then using the voice of customer through analytics or research, we can see if these changes are good enough and they go in line with our expectations or they can be technical. I think about as well, when you have a solution which contains all the functionalities a customer might expect but it's too slow. That's also an experience. The technical experience is also part of the customer value. What we do basically in a DevOps and UX situation is trying to bring this experience to the customer as soon as possible. But I think to go, depending that we should understand, first of all, how we work, how we make things happen. What's the flow on designing the experiences?
**Miriam Soesan: **Yes. So, our interaction design model is actually based on the well-known Double Diamond Model, which I am sure most of you are already familiar with and probably are practicing in your own work as well. So, I'm not going to walk you through the Double Diamond Model. I'm just going to explain how we are practicing it in Liquid Studio and the way that we actually are practicing it together with the designers and developers. So, the discovery phase is actually where we start to understand what the problem is? What is the challenge that we're facing? What is our scope and who is our audience? Now, this is something that not only designers should answer. This is also something that is very important for the developers to understand because that might affect the backend development. It might affect the language that they decide to code in. It might affect the different technical aspects of the product. So, this is why we start from the beginning to work designers and - developers together. Next off, of course, we have the define or the definition of what it is that we're going to do from all the information that we've gathered in the discovery phase and this is when we are actually defining our requirements and what do we expect. Of course, these two models, as you probably know these two parts can be reiterate within themselves. So, that would be the first diamond and moving on to the second diamond, we start with the design or for the developers, that would be the development part. Where we actually encourage our colleagues to think out of the box, give different answers and try and find creative solutions before we start the delivery phase, which also includes testing. And of course, we also do iterations on the entire process. So, we can iterate within each diamond but more importantly, we keep iterating the entire process. After the delivery, we actually continue to make testing and in an ever-continuing design and delivery world, we actually believe that there is no product that is ever really finished let's say. We are constantly gathering feedback and we are continuously researching and testing how our products and services are working to basically iteratively improve them. This kind of explains the structure of how the same process of that designers are usually more familiar with but also how developers can use the same process and how we are actually working together.
**Guillermo Martinez: ** Sometimes we can find issues in that domain when we are delivered in this building, says to the customer. What do you see right now on the screen is a regular waterfall sometimes not that waterfall sometimes a little bit more agile, but those are the steps of delivery that goes from identification of functionality, followed by design, implementation, testing, release and so on to the research, would we find new functionalities by performing the expedient sections. What in traditional delivery, we have an issue doesn't go directly in line with the customer experience and with DevOps, we of course perform all the actions. We actually can perform the actions of research and experience design but the way everything is organized. It's based on for my management. We like to categorize the teams and we tend to put different teams or different accountability but each of the steps, that way we are reducing the collaboration between each of the blocks that you can see and the screen, and therefore it makes the delivery process or the implementation process a little bit hard. During the last years, scrum practices has been really popping up and we are kind of combining design implementation even testing altogether but it's still most of the times are different departments running activities and they have close collaboration but they are still not really working together. Therefore, this process end to end contains with a couple of doors here and there from one block to the other, that makes things a little bit slower. So, let's say, imagine the case of a design is done then implementation that goes to test and then when there is an issue on the testing, testers will go back to the development team and it may be a problem that should be solved by design. However, when we work in this situation but this where you're working, this is not applicable. Then also something that happens from here is we might implement one functionality and then we will leave it there hanging until a large set functionality are available to bring what we call release. That's a situation where we sometimes consider it's an Agile way of working but to be honest, it's not very Agile. We work in experience. We work continuously in bringing functionalities. However, these functionalities don't reach the customer until one to six months. I'm talking about some research the puppet research, where they establish the frequency in between one and six months in general. So, therefore the situation where we think we are working in an Agile manner is not very agile we just bring functionalities, but they are not reaching the customer until X amount of time. And we tend to deliver a lot of functionalities altogether as a release. It makes it it's hard to test it, to validate the whole theme because they just had a lot of things to validate. It makes hard to release because there is a lot of things to be released. And if we go in today, the customer centric approach into the UX domain, it makes it hard to research the added value on what would be next because the researchers will have to find What's making sense from a large set of functionalities delivered, lots of experiences delivered and there is a lot of tenures at the same time. So, therefore the research cannot be a performing in inefficient manner. After they release one, we'll have another release which is 1.1 between both of them, what the time spent on research it's not enough, let's say. And also, the new changes that they are approached by UX domain most of the times they won't see the light in the next release but it will be postponed to a couple of release. Therefore, the customer won't see changes as soon as possible, they will see in a long term.
So, what's DevOps informs here is how we can make these deliveries a little bit more efficient. I'm going to talk now about what I just mentioned in here, USDS Delivery. It's in general DevOps delivery but since we want to focus a little bit more in the customer experience, I just put the brand of UXDX. The area for cycle is the same. We go from research to research but in that case, we are not going to deliver long releases with a lot of functionalities. We set up and structure and of course, it's quite supported by technology that's another point and we start listening to structure and organization where the team, it's accountable for doing everything. Probably you heard about the product teams. That's a product team. The product team is where they have ownership. They have a motivation and they have responsibility of defining, researching, designing your functionalities but also implementing them, validating them and releasing them. That's a change. That's a big change because changed a little bit the process about mailing, the organization and the capacities. I'm not talking about everyone in anything has to do everything. That's not the case. I'm talking about a team that has all the skills. Maybe people that are specialized in one area might be people that are specialized in that area. So, that's basically a product team. The way we work again, it's quite different. It's not focused on releases. It's focused on continuous feature delivery therefore what we can do here is ideate a feature, research, implement a solution and delivery. From the delivery of that, we'll go into again, research mode and we might identify new functionalities, new features to deliver. It might be an improvement on the feature like feature 1.1 or we can have a feature 2.0 or feature 3.0. For instance, we can have multiple of them. That way we can see how research goes ahead and brings new ones. If you can go to the next animation part, we can see here how the research can lead to feature 1.1 or into another type of feature. Also, another principle from DevOps could be the Multi-version, A/B testing. We can have multiple versions at the same time and then we can perform a continuous or revolutionary research just to identify what makes sense, what does it make sense? The data of this feature releases is that we don’t take one month to six months to deliver any functionality. We can do it in one day. We can deliver any functionality at any moment because the team is accountable responsible for that research is smaller. So, we can make a fast decision and fast research, deliver a functionality. And then in the same day or the day after we can even improve this functionality or bring a new one. We'll have multiple teams, smaller teams in that case that they are accountable for some set of features. So, that differs a lot from the front additional delivery because for instance, we consider the research team process, the research we'll have to a validate something that has been delivered recently and only one single functionality or a couple of them and not hundreds of times and when you have to research or make an analysis of efficiency and value over time. A lot of different functionalities. It can take a lot of time and you will see that a lot of them didn't make sense but it's still there. The activity is going to be performing efficient manner. However, in this scenario, everything that's a little bit smaller and more continuous. Therefore, there is no end and the stop is everything is just continuously with the flow of delivery. And that approach, that the structure of the team and the structure of delivery which is a continuous way of working, we applied into our liquid studio portal because that's our way of working. And we were developing now where our portal with some students, with some interns. Miriam, I think you can bring some information about it.
**Miriam Soesan: **Yes. So, as we had just mentioned, we actually took this practice and applied it to our own portal, our own website. What we actually did, you can see on the screen that we had from July, 2019 until December, 2019, we actually did 417 small changes or 417 push to production which is quite a lot even per week, if you divide it so even though the two examples that you currently see on the screen seem like two very different products. They are actually the outcome of a lot of small changes that we implemented. Now, let me just walk you through this process step by step: the screen that you see on the left was actually based on the preliminary research that we did when we asked ourselves, what who is our audience? What is the purpose of the portal? What colors should we use? Et cetera, et cetera. So, the color we based it very vaguely on the green that you can see in the Liquid Studio logo up here but we also wanted to have some blue into it and some more relaxing colors as well as we took the theme of Liquid Studio and applied it to the design of the wave here. So, I'm just going to show you a sneak peek into this first design of the website and then step by step and after testing it we decided to move into a more darker color. You can also see that here, the logo changed the menu up here changed from the original version, and we also decided to change the wavelength to make it a bit more relaxed and we animated it as well to give a bit of more of a lively feeling to it, a bit more interactive feeling to the product. Now saying that it seems like everything we did or it might sound like everything we did on the way was correct but that is hardly the case. As we also tested a few designs that just did not work. And one really good example all is the design that I'm about to show you where we tried to further explore the theme of being liquid and the watery theme which after testing showed that most testers, most users actually felt that Liquid Studio had something to do with either sea or marine activities which is hardly the case as we are a part of Accenture technology. We are a tech company as we see ourselves. So I'm just going to show you this demo and explain why it didn't work. So, we also did this scrolling sideways instead of instead of the normal up and down, we tried to play a bit with the layout as well. And of course, show her work at the end. Now, as I said, one of the reasons this design did not work was that we took the Liquid Team a step too far. So, what we did, as you can and see here in the Double Diamond Model, we went back to the research phase and it's not that we decided to skip everything. We kept actually some of the design here. So, there's scrolling sideways, for example, we thought was really successful but we went back to different colors and different setting. So, now the design still involves more creative way of scrolling through the information and more in a different way of showing the information. But we went back from a visual design perspective back to our branding, back to our original colors and you can see it here that we decided to focus on a few areas. As well as keeping the design language and the visual design much similar to the original brand of Liquid Studio and of the Accenture.
Now, this is our current website which as you can see, the previous screen showed you the design. As we can see, that was more our vision and this screen actually shows how the website currently looks. So, we have this black theme, as you can see. Also, our slides are black and we just took it a bit further also with the wavelength, we changed it a bit. And this also was done after almost 110 small releases from the or not the original, but from the dark blue design. We added some more animations as well to make it a bit more lively, a bit more projects about ourselves and some of our partners. So, that is basically how we implemented the design step-by-step and continue to test it. Continue to not only ask ourselves what is next but also ask our customers, ask our audience which consists of potential employees as well as potential interns and also our colleagues across Accenture in the Netherlands and globally and this is how we did it step by step continuous research and continuing to work together, developers and designers, bringing ideas to the table. And I think now is time to also maybe show them the pipeline behind all this.
**Guillermo Martinez: **Yes. We're going to run a pipeline demo just to show the technical aspect on there in the delivery. We mentioned, first of all, that we want to deliver a value as soon as possible. This value we said that they are experiences and we want to do it right now. From the video that you just placed before we identified that the logos of the partners are quite big and unaligned. So, we are going to just change it right now at the moment. We don't have to go through the process of change management. We don't have to go through the process of approval, validate testing, and then we'll see the change in one month or even more. We're going to do it right now. Shown the previous video, we could find that the logos that we had at the end on the partner side were quite big. So, we want just to change them and we don't want to go through their regular process of making a request and an approval, then a change, then a whole validation and so on and so on and so on. At the end, the customer will see it in one month. What do, we do it is doing right now? We decided between Miriam and myself, that we wanted to change these logos. So, what we do is basically when you change the code in a moment and then we will push the change of the code. That way we will run the pipeline where all the delivery steps are handled automatically different there and we could see the change.
First of all, I saw that there was some issue there and then there is a couple of other things to change like the align items or similar things. So, let's align items to the center, I already have validated that the worst, the good values. So, I'm just doing it a bit faster than usual. It's important to put a margin out of there because I saw also that margin wasn't good enough. So, basically, we are going to make a change of the solution. Just lay that, we don't embed it as a release. We just make a fast change like any other change we can do and then we'll see here in a moment. What happens in the meantime? Well, basically when we push code, pipeline runs.
What's a pipeline? Well, in all the delivery process, never the delivery process. There are multiple steps to be covered from unit testing. So, that could be a functional testing, a code validation, or code check, security validation, building the solution. In our case as well, we delivered with containers to make the multicultural possible and to make everything a bit more of a more flexible and scalable. Well, it happens a lot of different steps that traditionally, each of them was executed manually by one team or multiple teams but they're set. And it usually was taking multiple days in this situation when we work in a DevOps situation, the designer might define together with developers what's the functionality to be executed, what we want to change, what type of experience we want to deliver and therefore we can implement it together in a moment we just push it and we go through the whole automated delivery and in that way, we don't have to wait a lot of time. We don't have to move from design to develop, to test, to deploy, to any other step. We just do it all together in once and the whole chain, it's just executed in automated manner. If you have interest in the technical domain what's happens in the pipeline is basically a set of comments. We programmed the delivery. Let's say we programmed the delivery and what happens is basically a lot of comments in the background and a lot of technicalities in the background that well, if will inform us if what we are doing is good or not, or if it makes sense or if it's failing. So, it's really informed us about what's the status, how everything is going on.
So, at the moment we just take the first validation which was fine. Here, this one is where are loaded, fail, successful information for us then we build. Then we put it in a container and so on until it gets posted directly to production. So, we don't have to make any type of request to push to production because we've been mentioning all the time or we just could like that it's not that I've released. It's just a feature. It's just a continuously delivering features. So, now the image of the container it and the solution has been pushed to production so that new experience has been delivered which will allow the team to add new things based on this change without having to wait one month for the next release. So, right now, if we go and we refresh the page of the studio, we can see like they've reduce the size. It looks a little bit better. Right now, every time we have the designers watching the solution, they might already start thinking about it in their brains come next improvement and again, this is now a visible change. But think about all the backend all the things that happen in the background that can be improved. Well, that's only the demo that we wanted to do through the pipeline, which is how to program the end to end delivery process. So, on top of working together in a collaborative manner, in a product team, in the DevOps delivery, UXDX delivery, everything is supported by technology because of the delivery, the experience can be delivered enough fast manner without big challenges.
Okay. I hope you like the demo of the pipeline, which is basically the delivery part on the technology domain. And as a conclusion, we were looking for the points of speed, the response to change and innovation. We actually for speed because the organization that diverse proposes is quite less political than a previous one. Every time we want to do it, we don't need to go through a big process of approvals, rejections testing and so on, we of course do that but we do it in a more efficient manner, keeping the team accountable for end-to-end delivery and end-to-end maintenance. We deliver the experiences not in one-month timeline but in our timeline, we can perform research over the functionalities on the same day. Therefore, we don't need to wait a long time for releases to perform our research over them. So, we gain speed, new ideas are flowing constantly. We don't have to wait that much. That's thanks to the continuous delivery where you're working and continuous research, continuous design. And the response to change, a fast reaction. That's obviously one of the big wins every time we deliver a functionality, thanks to technology as well. We are able to measure the value in terms of data and analytics, but we can also perform research all the time. Every time we deliver is more functionalities, more change one of these hundreds or even more small changes that we were delivering through our portal. We can perform continuous research and that research which will evolve in new functionalities or an improvement functionality. Again, we don't have to wait a long month just to perform a research over some experience. We can just do it at the moment and take a decision, a fast decision and when experienced can evolve into 3, 4 or 5 versions in the same week which in a traditional delivery, that's not really possible. And then of course, the practices like hearing the customer it's very important to do. And the last part is innovation initially is hard. It's something that we always want but because it's not supposedly that cheap or because we never know if it's going to bring value, we don't do it. Well, that this way of working allows you to innovate way more because any small changes, basically down in minutes, it can be delivered in hours, even less. Sometimes you have fast feedback, you can have multi-version for testing different versions or perform and research over multiple version at the same time and therefore the innovation cost is way reduced. You can try out new things, you can analyze these new things, and then you can take decisions based on that. You don't have to wait a lot of time and you don't have to really create large business cases and meetings. And so on in order to train innovation, I'm talking about not only what you see in the screen because we focused a little bit more on what you were seeing in the screen before, but also in the backend functionality. So, new functionality, like the chatbot we implemented.
So, therefore this way of working, we combine a customer centric which is the value with DevOps, which is the fast delivery and also has to really have an efficient way of working where the whole team are more satisfied, motivated, and are able to take more decisions and make things happen. With that, I will just like to close. If you have any questions, if you want to know more or place or mail or a question in the channels, we are always open to hear you. I hope you like it. I hope you are able to learn a couple of new things here and there. Thanks a lot for your time. I hope to see you soon. Thanks a lot Miriam as well.
**Miriam Soesan: **Thank you.