 So a warm welcome, please, for Raul Fernandez and Gary Coach Garcia. Welcome. Welcome, gentlemen. Thank you. How are you? All right. So, yeah. Hi, everyone. Apologies for these initial issues. Yeah. My name is Gary Coach Garcia. I will give you a brief introduction of the IG Group and IGGBS, which is the company Raul and myself belong to. IGGBS is part of the IG Group. I will tell you a bit more about it in the next slide. All right. So, IG has a vision of becoming the leading group of airlines across the world. To do so is preparing a platform for different operating companies to work on it. So the idea is to maximizing the sustainable value to our stakeholders and customers. It started in 2011. There were joining leading airlines from Ireland, from the UK, from Spain, and it commemorates different type of airlines across the same group. So there are two full service carriers, which are Iberia and British Airways. There are also two value service carriers, like Erlingus and Iberia Express, and finally there are also low cost carriers, such as Boeing and Lebel. Lebel actually was created by IG in 2017, while the other companies were either creating the group or being a quality run, and the difference with Lebel is that it's a low cost company that offers transatlantic flights to many destinations, starting from Barcelona and Paris. Then as you have probably seen in the press, we are now in the process to publicly buy another airline, which is Europa, and that will give us also more presence in the Madrid hub. So what we are building in IG is a platform for these different operating companies to coexist and find the synergies between them. So the platform is formed by other operating companies supporting those businesses, which include IG Cargo for good transportation, then IG GPS, which is the one that provides group IT services, procurement, and financial services, and finally we have Avios, which is the loyalty aspect of the group. In terms of the vision, like becoming the world leading airline and creating this sustainable value, we believe that we are well positioned to offer this value because even if we are working on a very competitive and fast-paced environment, we do have the right basis for creating that. We believe that one doesn't fit all, so that's why we are quite diverse in terms of the different businesses that are part of the group. But we also believe that because they are different, we can also offer a rival customer proposition across the different segments of the travel industry. So here you can see the IG integrated platform, which is composed of Cargo, Avios, GPS, and so on that provide these services to the different companies. The idea is to allow this integrated platform to provide simplicity and to become more efficient and then let the different operating companies to be different, to have their own targets and in the end to provide different type of value to different type of customers. Now going a bit more into group IT. Group IT is part of IG GPS, so together with the financial services and group procurement, we form this global business services group. We do have a number of challenges in group IT that we need to address because of the nature of the group. For instance, there is a very heterogeneous legacy landscape that we need to address. Together with that, there are security issues, there are network challenges due to connectivity of different locations associated to the logistics. Obviously, there are different business alignments. The different businesses do have different visions and therefore different cultures that we will need to address from a common perspective in IT. The idea of IT is to offer a plug and play capability and this serves as a potential platform, let's say, even for future acquisitions so that we can integrate and find the right synergies underneath. So what we are doing in IT with this plug and play model is to really understand our access, our to be where we want to be, how can we standardize and to which level we can get those synergies and then define the associated roadmap and the strategy of course on how to go from it to be. Then in terms of what are the enablers to be able to do this, one of the enablers is the agitransformation that we are presenting. One of the samples is the Iberia com examples that will go a bit more in depth. Another very good example of enablers is actually the open group as a platform and the commercial aviation workgroup where we are aiming to develop much farther the commercial aviation reference framework which will serve as a base for our IT and architecture functions. Then in terms of agile working, well, you know, pretty much the idea of becoming agile so the organizations need to be more responsive, more effective, they need to be more efficient as well. There are a number of challenges that typically the different organizations face. They include specifically the culture and mindset change and that is something that we also struggled especially at the beginning and we have been evolving on that. So the use case will probably go a bit more deeper into that point. In the end what we found out is that we need to embrace the agenda and keep still some part of the more traditional way of doing IT and architecture but we will have to evolve in some areas and we have already started doing so. In order to do this, the role of the architecture that we know traditionally needs to evolve. There are some aspects where this is more necessary than others. Primarily we as architects need to be closer to the business owners. We have to be co-creating and be co-located with them, do a lot of whiteboarding with them, understand the issues and evolve with the business requirements. Then there is a necessity also for simplifying the documentation that we have and one very good thing to do so is to choose the right tools in order to not having to put extra effort on the more bureaucratic side of things. So just produce what is absolutely relevant for the business and actually within IT. The concepts that we are now a bit more familiar with and the aspects of architecture that need to change more, let's say, is rather than to boil the ocean and create a completely perfect architecture from the beginning, we should start more from a minimum viable architecture. This means that starting from the strategy and from a very high level vision of what we need to achieve, then we have to smartly partition the architecture to find the right level of depth and breadth of the different initiatives and then focus on the minimum viable architecture for each of those initiatives rather than trying to create the whole thing from the beginning. Then the concept of continuous architecture refactoring is also, as we were hearing before, making the architecture more agile. So we don't need to adhere to very strict and difficult to change these architectures or solutions, but starting from principles, starting from strategy, we can evolve that architecture as the requirements evolve or the technology underpinning those solutions or requirements are evolving as well. In terms of digital transformation, we want the teams to be working with new technologies. We are exploring the new technologies. We are applying them and see how they work. Proof concepts and small projects initially starting small and then growing on them. Things like technologies that a couple of years ago were radically new, now they are getting more, let's say, adopted by all the teams, but there are still a lot of opportunities that can be explored in areas like artificial intelligence, block change, you name it, all these new technologies that we work with. Finally, but not less important, is the architectural governance. In the traditional, let's say, the architectural governance is a bit too rigid and it needs to be a bit more fluid when we speak about agile. So to me, the key figure is the solution architect in this case that can flex the day-to-day work that is being done in the squads within the teams that are working in the agile delivery and the, let's say, enterprise architecture level where we have the strategy, the principles, the technology guidelines. So the solution architect can work with each of the squads, understand what are the needs for solutions and architectures to evolve and communicate that back to the enterprise architecture. We will see how these principles are becoming a reality with now the use case that Raúl is going to present for ABRIA.com. Thank you. Hello everybody. I am Raúl Fernández, the performance manager of ABRIA.com, and I'm going to, the case study that I'm going to introduce or present today is about the roadmap of the agile adoption of ABRIA.com. When I entered in the company three years ago, the process, the methodology they were using was very traditional, and one of the missions they gave me is to start doing the transformation with all the teams that are building the ABRIA.com platform. What is ABRIA.com? There are two different angles to see what is ABRIA.com. One is a platform, it's a technological platform, a collection of microservices, a front application, the front of the mobile apps, but also other legacy applications that are the core of the company like a ticketing system or the account, revenue accounting that this platform is using as well, and they are belonging to other teams, other areas of ABRIA.com, and sometimes we have to implement things and we have dependencies about features that they have to implement in their system, and this platform also is using third party services like ADEUS or other services. So this is ABRIA.com is a technological platform, but also ABRIA.com is a product. From the business point of view, it's a product, and as a product there are different businesses in ABRIA that want to spend money to do chains in the application because those chains are going to bring with revenue. So we have several businesses and one technological platform. Three years ago, the situation was very different to nowadays, and we have different businesses trying to touch the same platform. The businesses were not aligned each other, so whenever you start implementing things, you start seeing conflict in the implementation. So there were a misalignment between businesses. At that time also, we see we have another big problem with business is the priorities. These were three types of priorities, high-media level, high-media low. What happened? 80% of the projects were high-priority and 20-medium. If USIT has a lot of projects with a high-priority, the one that is deciding which project is going to be the first to implement ISIT, and that's the bad direction because we are losing the time to market to start working with a project that has the most impact in business. So at some point, we have to move that responsibility to business and say, we cannot work with only three levels of priority. The backlog has to be from 1 to N, and we can pick up the projects from the top of the backlog. Another problem that we had at that time is the visibility. So all the engineers in Iberia.com were working in tasks to implement features, but they didn't know the business strategy. If they didn't know the business strategy, you cannot pretend that the team is proactive and the team can take decisions in the right direction because they don't know the business strategy and we are working, we are not a technological company, we are selling tickets and our target is the user. And another problem that the business didn't know or didn't understand how IT was working because we were like at two different things, business asking things and IT implementing them, but we were not working as a team. Another problem was the dependencies. You have dependencies with another systems that are working, are still working in traditional technologies, traditional methodologies, and the speed of implementation is not as fast as an agile team. So if you have dependencies, you have to wait. And what's happening at that time is that because business was putting a lot of pressure in some of the projects because they were very urgent, if that project has a dependency in a third party, you cannot start implementing on that project until the third party finish the dependency because if you do that, then you have implementation that these are already done, but it's not ready to put in production. If it is not ready to put in production, why you don't work in other things that you can put in production and get the time to market. Another problem is the knowledge. There were like a few people with a lot of knowledge. Iberia is a very old company. Few people with a lot of knowledge and many people depending on them. So we have to distribute that knowledge in all the people. Otherwise, the dependency to do something is very big and also the quality. At that time, we had a very monolithic application. You change something here and then you break something in other part. Of course, we have done a transformation project and now we convert all that monolithic application in a microservice platform. So what we did at the beginning, agile goes about working with team, working with people. So at the beginning, we didn't say to anybody that we went to transform to agile. We just started to work with the people, with the team. And I remember the environment was a very difficult one because there were like a different providers working, delivering projects and when they put the project in the production, they generate a lot of bugs. And all the providers were blaming each other. So one of the things is you have to create a good environment. And a good environment that is focused in solutions. And everybody is working in a solution, not complaining, not blaming each other. So we started to do like a round of retrospective meetings in which we talk about the impediments that the people had doing their job. What are the impediments that you have? What we can do? And then we came with a series of actions. In those meetings, nobody can complain. Nobody can blame each other. Everybody, the laptops, please close the laptop. And if you have a mobile call go outside, we are going to work together in a solution. And it's amazing. In two months doing that every week, the attitudes of the people change because you put all the people to work in a solution together. And then you gave them like a possible solution to the problems. And then you try to influence them to give them the good values to create like a base in which you can work in agile. Especially be focused on the customer and the organization. You have to delegate in teams. You are going to, at that time, we were about to remove the project manager role. So team has to be able to out organize. And team has to be able to assume the responsibility as a team. And that is difficult, I will tell you. So we have a good success environment after two months in the people. And then we started to work together, to keep working together every week to define what will be the model that we would like to work. We are going to try to do the model scalable for all of us that we would like to work. And we did that with the development team, with the engineers, but also with the business people. Because the challenge was stop having two different teams, business and IT. The challenge was you are the product, we are IT. Herarchically you are in the same position, but you are doing different roles. But for doing different roles and with the common target that is the user, we have to be able to work together. How is the best model to work together? Then I put everybody in long sessions on Fridays, I remember, and to define that model. It was a difficult process. But then people start contributing with ideas. And they are the people that are going to implement the things. And they are the people that knows much better what is the best model for Iberia. Much better than if an external consultant comes to Iberia and says, this is the model, try to follow. No, we are going to create it. Because if they created the model, if they created the model, because they did it, they are going to follow. They are not going to leave that like an imposition. They are going to leave that like a democratic act that everybody agrees. And they have to do what the team is agreeing. Okay, so we created the model. We spent several months trying to define the model. Can you hear me? Thank you, the family model. And in January this year, when that the model was defined and agreed in all the teams, then I dissolved all the teams in Iberia.com, 130 people. I dissolved all the teams. And in the act of one day, in an auto-organized meeting, everybody choose when he wants to work. They already know the model. So with the model, you have a collection of rules. You can have, for example, for this model, we are going to have the development teams that has to be full stack. So every development team has to have all the profiles that you need to deliver such an improduction. Service backend developers, front-end developers, quality assurance, another different technology like experts in the content management system. So you have a team that can implement something and put in production. They already know that there were cells, I will explain later on, that every cell is formed by one product owner, one business analyst, one UX, one UI. So we draw the template and everybody select when they wanted to work. And after that, we started around to find the team agreements to start the new way of working. And we implemented this. We have been working this year with that model. And now we are in a position in that we found several things that we need to improve because, okay, this slide is not complete. Okay. Because we realize that the culture is very difficult to change. It's the most difficult thing when you are playing a transformation on a file. You can set the ceremonies, you can set the framework. But the culture, the mindset is still old. So now we have to do a second round of transformation. So what is the model that we defined? We defined it a model, a three-level model. The top level, well, it's not the top because it's not hierarchical. The center of the model is the core. In the core are all the stakeholders that have interest in Iberia.com, that have money, and they need to change in Iberia.com. And at this level, what we do is try to talk about the things that are cross. If you have a project that are touching two different businesses, you have to make sure that the priority for that business is the same that this one, otherwise, you will not be able to deliver because you have dependencies. So we try to figure out what are the dependencies and resolve conflicts. At that level, we have the solution architect of Iberia involved because the solution architect at this level has to try to identify what are the dependencies with other systems. Because as soon as you identify dependencies, you can start working on those dependencies. You start talking with other parties to then planify the work and have that work ready when you start implementing. Then we have a second level. You will see the squads, and every squad has two different levels. In the left-hand side, you have the cells and the development team. The cell is formed by the product owner, business analyst, US, and UI. What they are doing is trying to pick up the requirement at a very high level that are created in the core and do a fine game, and the input is an initiative, business initiative, and their output is used backlog with different user stories. A user story is a requirement that is very well defined from the functional point of view, but with enough information for a developer to be able to start to implement. In our case, we include the UI and UI as part of the requirements, and every cell can fit one or several development teams. The cell is like in the traditional scrum, the product owner, and the team, the development team is the development team. The development team is a full stack team with different technologies from apps, mobile apps, Angular, backend developers, it was inter-site, and every team also has a member that belongs to the chapter architecture. So the chapter architecture is like if I am a developer that I like architecture, I am working here in the development team, I like architecture, that is my focus, my passion. So what they do is they create a community, so every development team has a member of the chapter architecture, they create a community about architecture. So they can share things about that practice, they can be in contact with the solution architect and the enterprise architect, they can understand what are the principles of the architecture in AIG, and they can try to to conscientiate to the other people in the team how things have to be done, and they can identify also inside of the team that if we have to develop this functionality that has an implication in architecture, then I have to raise a flag and say to the solution architect. Okay, so this is the model, and then this is some photographers about the act when we created that model in an auto organization fashion. And other thing that we incorporated to the model is a ceremony that is the town hall meeting. We have a town hall every quarter at the beginning of the quarter, and the target of the town hall is to understand the business strategy for this quarter, what is business wanting to do in the application. So every business manager goes there and tell to all the people, when I say all the people, they say 160 people all together, and business managers comes and they tell us the business strategy, the sales, the product owners tell also the plan, align it with the business strategy, and then all the people together with a plan that they have about the implementation for the this quarter start talking to each other about the penances. So after those sessions of explaining the strategy, so in a big room we have different positions for different squads, and all the people goes through the different squads, and the product owner tell them in detail what is our plan for this quarter. And if you are, for example, someone for the ticketing systems and goes there, and then they tell you things, maybe you say, okay, if you want to do that, I have to do some change, because you will find that if you try to do this, this parameter is not in our process. So then we have to do things. So then you keep a positive, and then you have something to integrate as a ticketing system in your plan. So the target of this town hall meeting is try to manage all the dependencies we have with the people in front of you, talking about the things we are going to do, and talking, interacting with people is much more powerful that if we do this plan, this three months plan, based in emails or other kind of remote communication, it's much more powerful. And also we found that this kind of meetings, because all the people is together, and then you can know other people that is working in other areas that maybe you never see in the day-to-day, create a lot of synergies and a lot of motivation. And it's amazing that the last, for the last, sorry, we are finishing the time. It's amazing the result that meeting has. So basically I'm finishing the conversation, the rest of the points are key learning that we had in this phase that you can read in the PPTs, and then we are starting to work in the next level of change that we need to improve in the agenda formation. Please have a seat, Raul. We'll go through a few questions. Thank you very much for that. I think in your, you skipped over some of the key learnings in the interest of time. I think one of them might answer the first question, which was we heard earlier about a bimodal architecture approach. Is that how you would describe the situation in IAG? Bimodal architecture? Bimodal or two-speed or multi-speed? Two different spaces. Actually we have like three different levels. It's much more three levels than two. We have an architecture at the top level that we discussed when we have the core meeting, when all the stakeholders are together, and then we see the impact that the new functionality will have in the architecture, and then you miss the impact and the requirement that then we will have to change those pieces of software according with the principles of the architecture, the general principles. And another level is in the cells. When you are landing, when you are refining the requirements, then you find that there are some things also that are impacting that you cannot see at the high level. So architectures have also meetings every two months with all the cells, and they are explaining what is going to be the backlog for the two or three springs, coming springs, and so you can identify also other changes that you have to do. And also my happen is not the regular that when you are implementing in the SCRAM, you find some other implications. Okay, thank you. You mentioned user stories. Who creates those in your organization? User stories. User stories are created between the product owner and the business analyst. The differences in the product owner and business analyst is not so much. In our case, it's just legacy, because at the beginning, when we started to work, product owner work were in the business area, and the business analyst were in the business areas, and the requirements for IT were just one sentence. So we needed to hire a business analyst to try to translate that one sentence in something meaningful for the developers. But nowadays that we have been working with product owner and business analyst long time, and they know each other, and they know how the other guy is working as well. So there is a good synchronization, and so far, both of them are business product owners. But the product owner, PSL, is the responsible to create user stories. Okay, thank you. I'll combine two questions into one. When you got the teams together in the early stages, you mentioned the first two months, was that face-to-face, is the first part of the question? And secondly, you then talk about quarterly meetings, are they good enough, or should they be more frequent, do you think? Second part, you talked about quarterly meetings getting people together. Do you think that is regular enough, or should it be more regular than quarterly? Okay, let me explain. So the first phase, the phase zero in which we have this retrospective meeting, is very important to have that retrospective meeting face-to-face, because interaction is much more powerful than email, even much more powerful than when you are in remote. So you can do, essentially, it's much better. So there is a difference between the town hall meetings and the core. The core meeting in which all the stakeholders are together happen every Friday. So every Friday, we are discussing the things that are cross, things that are high level, and the stakeholder has a very good knowledge about how other things are going. The town hall meetings happen every quarter. It's enough. It's a lot of, so imagine 130 people in a meeting during a whole day. It's a very expensive meeting. It's not because it's expensive. It's enough because at that time you can plan the three coming months very well, and if you have any issues during the plan, because you see the other guy that is implicated in your project, you can go to his place and ask the questions. And so far it's enough, and it's a very powerful meeting. Okay. One for you maybe, Gary. What do you think of the term minimum viable architecture? It seems unarchitectural. The least amount of architecture possible doesn't sound like a good idea. What do you think? I think that makes sense. Actually, it is within the concept of photography itself. So when we do the ADM, we can choose what the scope of the ADM is, and that allows us to focus on really the partition of the architecture that we want to resolve at a very specific point in time and for a very specific initiative. So as I mentioned before, rather than trying to create the architecture for everything, it is better to just do a preliminary phase to identify things like the principles, the strategies, and so on. And from that perspective, and with an architecture vision probably for the whole lot, then focus on developing the architecture for specific necessities, primarily because those architectures and solutions are going to evolve with the time in an agile world. So sometimes it's also a waste of time if you want to resolve everything at the beginning, knowing that parts of it are not going to be used or are going to change. And we are at a time, but one more question because I'm interested in hearing you answer. What does IAG particularly hope to gain out of participation in the commercial aviation work group? So the principal focus, I believe, is the reference architecture. I think that will be one of the enablers for Group IT in the end that will provide us with the basement, let's say, for the different domain viewpoints, data architecture, applications, business architecture. So that will streamline quite a lot the ADM cycle in the end. So how to produce the architectures and the solutions to make it much more efficient to use the resources and to be able to deliver in less time and finally to become more agile. And it's the latest example of what we're doing in the open group in other industries as well is going to that reference architecture level and what it means for your particular industry. So we'll leave it there, gentlemen. Thank you both very much, Raul and Gary Klitz. Thank you. Thank you.