 Agile development is awesome. I'm a huge fan. It has completely transformed the way that we work and the amount of customer value and customer satisfaction we can deliver and the frequency with which we can deliver it. It's a wonderful, wonderful thing, but it's also really hard to adopt if your company and your tool sets and your culture are firmly rooted in waterfall. Now, waterfall can be really inefficient, absolutely, but it's predictable and we're used to it. And that is something of value. Migrating to Agile requires rethinking the way that you do everything from specking out what you want to deliver to building software that meets those needs to ultimately delivering that software and that value to your end users. And no company is going to go through that level of disruption and change unless they have confidence in the end result. In our next talk, Alberto Dominguez will talk about getting there. He'll talk about how you can leverage the GitLab DevOps platform to provide that level of awareness and visibility and confidence so that you and everyone can fully embrace everything that Agile has to offer. Let's take a look. Hello, everyone and welcome to this presentation. I'm Alberto Dominguez and happy to be here with you today. And this presentation is a journey and some experiences and lessons learned about moving teams and some organizations from a waterfall thinking to an Agile thinking to really DevOps sort of mindset. Hope you find it useful. I will share some experiences and tips. And obviously, I will be waiting for your feedback and comments at the end of this presentation. And after this GitLab Summit 2021 event, feel free to contact me and discuss about these ideas. So welcome. I'm Alberto Dominguez. I'm an engineer, teacher, I'm a coder from the very deep of my heart. I'm in love of coding and support development. However, I work as a consultant and probably my main activity is managed team. The other day, I was dining with a friend of mine and he said, you are some sort of CTO who actually codes and probably is a good way to describe myself. I always work on the management side and I try to lead teams instead of coding and doing technical stuff. But I'm really in love of those kinds of activities. Sometimes I code, sometimes I support infrastructure, cloud management and everything. I work for big companies as a consultant and sometimes for startups as a scholar or lead engineer or team manager. So basically, that's why I do. And that's my point of view and I hope you find it useful for your process and your transitions and transformations through Agile and DevOps. So welcome again. This is the agenda of this presentation. It's about DevOps, how we get there on DevOps, why we talk now about DevOps and why DevOps is taking over Agile on our context. What is the role of Agile on this discussion? Why I put that name on the title? The challenges of this cultural transformation or adoption, I call it the evolution of the organizational culture and some tips to close and obviously talk about how GitLab can enhance and empower your teams to really go through this process. So welcome again. You all see this picture on GitLab's side or in other presentations or probably a different version of this picture and it's what people believe is DevOps. It's kind of a double endless cycle, like an infinite loop that at some point has to start. So DevOps is not something that is there and it's always running. It's something that you need to start or enhance on your teams if they are doing some sort of practices. And I started with this because I do believe that you have to start, set a starting point. You need to set where to start and probably that's where plan, the first plan appears. And if you are doing some transformations, you know that you struggle understanding a little bit how much planning you have to do or even if you are going to Agile, some people believe that you don't do any planning at all. You have to start just coding or writing or deploying or whatever. But there is not like a really clear path on how to build this kind of first plan and where do we get the requirements and if you're building apps, probably the first iterations or sprints will suffer some kind of lack of vision. And in some books and articles, you will find the idea of some sort of spring zero, which somebody probably loves or maybe other people will hate it. But the idea is that you cannot start working on something you have not planned at all. If you don't know where you're going, probably you will end at any point and it will be the same for the organization and for your team. So the biggest challenge with this picture is to understand that it is not an endless cycle. It will behave as a really, really, really long process at some point. But you will have probably to start at some point and end or decommission those products that you will be replacing with new ones. So the idea of DevOps is quite infinite in terms of the idea, but obviously the product has a different life cycle and probably that's where this needs to be adjusted. And the reason for that is that for me and my experience DevOps is more about synergy and how business and IT teams work together. DevOps is deeply connected to synergy and obviously means collaboration between those who identify or idea the products those who create or design the initial ideas and those who produce or create the product, the actual product, maintaining it and even use it. Sometimes in DevOps you have to include the ones who use it as part of the feedback loop. So the very important thing is that the DevOps implies people as a new organizational process and how they work together, which is quite important because DevOps is how we collaborate and work together to deliver those solutions. It's not about products or IT or solutions or tools, it's about delivering continuously delivering solutions and obviously that means that you will have some processes and you will need some tools to really make it simpler on complex organizations. Obviously if you work with a couple friends of you and you are a startup of 10 people probably you don't suffer from this kind of discussion that I'm trying to point here is when you have complex organizations and multiple teams and multiple locations and even different time zones or even cultural backgrounds and cultural backgrounds you will have some different challenges that if you are just a small team. So my presentation is more focused on those that are trying to move big elephants from a waterfall to DevOps. So this is what I call the model evolution. We all started at some point with something similar or based on the waterfall model, which in my humble opinion is perfectly fine for the context it was designed and to be honest waterfall was not designed for any purpose or all the purpose but for a particular purpose which is resolving a particular problem which is can be contained into a boundary. So if you have a problem that really doesn't change through the time or that you can subscribe to a border line then you can provide a solution and actually test that solution and see if that solves the problem or the need and I think it's quite clever it's quite straightforward idea and the challenges came later when you were unable to actually subscribe the problem to a boundary right you were unable to close the problem the problem was growing with you problem was changing with you the problem was getting obsolete while you were solving it and then you have a new problem or a new need or a new opportunity so obviously this kind of long process when you lock down was we were trying to apply to big big big big problems and it takes too much time to define and lock the problem and when you actually define the border of the problem the problem was obsolete or we were discussing about obsolete technology or we were discussing about new products so we were discussing about new requirements on the business side and to be honest the problem was not the waterfall itself but the idea of being able to apply it to a big big big problem and if you read the original paper you will notice that it stated clearly that you should not use that model on every problem you have or any challenge you have every challenge you have sorry so that's when agile jumps into the scene agile is some sort of a solution based on feedback loops to improve the solution or define a better solution while the problem or the challenge is changing through the time so it's more accurate to the problems we try to solve today and if you read the original documentation the feedback loops were longer the time boxes when you subscribe this kind of processes this small and production processes or iterations or sprints as you call it in the scrum you will notice that they have been trying to reduce the time from the last 20 years reducing the time because the technology now allows most of the team to deliver in in in in a matter of hours or minutes instead of days or weeks so we are trying to we are have been working on reducing those time boxes to speed up their development process and and reducing the time to market but if if you keep on agile probably you will have a lack of delivery and that's where for IT specific projects you have this kind of concept of the both when you just merge the definition of the product and the delivery and operation of the product in one in one in one kind of box so let's start with agile and why agile is important is because it gives the team the team that consume the product the empowerment to become a better team and to build a better product so agile is some sort of upgrade to your engine so you get this kind of better engine but you need to start thinking when you actually are successful on agile if you are you probably are discussing on the way you get the requirement the way the business connects to this new engine right the the the way we fuel it right because if you have a really good agile team but you still are providing requirements or product visions as a whole instead of an incremental product probably you are still failing to deliver and we are not saying having bad agile teams is probably you are doing a good job but probably you are facing some challenges on actually delivering so you create a lot of versions product that never see the light on the market and and and then what's the whole point of doing agile if you cannot deliver and you will see that you will have probably some bottlenecks outside your agile teams so the first important state here is that agile increases your ability of a small team to build valuable solutions when you think agile you think on small scale because otherwise you will have to think on hyper agility which is some sort of of a bossy word that it's it's hard to get in some some importance or probably you are thinking about agile at scale or are thinking on organizational agility but when you think on agile you think on small things and by definition and the idea behind a lot of agile is to build valuable solutions with those small things which is quite nice for most of us you have small teams delivering and performing very well being efficient and effective on delivering solutions to the next step of the process of actually putting that in the hands of our customers of our or our clients most of the implementation of agile are some sort of as part of the whole process on delivering most of them just speed up the development process but not the delivery process and that's where DevOps jumps into the scene so let's see this kind of journey of the most of organization I have worked for and how they perceive their processes and then discuss on the details first of all most of the organizations will decide to go win a pile which is good this is kind of a special team that we will give a lot of concessions it will be a special thing everybody in the organization will be really paying attention to what this team does and probably they will be more willing to help and do more concessions on how they interact with this team right which is not scalable at all right because you cannot be a special guy with all the teams of non-organizations so most of the organizations will fail thinking the pilot that's just a proof of concept instead of a really the seed of a bigger effort and obviously that comes with the capacity of the ability of put the teams dedicated to a to an initiative or product or a balance team if you understand the concept you will notice that in these organizations the pilots were with teams that fully dedicated but when you try to go scale and and big probably they will bring as a will jump and say hey I cannot give you all those team members fully assigned because I will just can be able to keep operating my area and that's why they saw this pilot as a proof of concept instead of a big transformation and that's why if you already see saw this oh I invite you to take a look to the state of Agile report which was launched a few weeks ago the close to the half of the respondents which is a lot of people close of the half of the organizations that say they are running agile or trying to implement agile they see two things that are the big biggest challenges first processes and practices fields have worked on the idea of agile and devils they simply don't match and that's because you are thinking on your engine as an as an isolate component why your engine is connected to your car to the driver it's part of the whole system that which is the car and running right and the and the second is the the resistance to the change and that's basically why most of the agile transformations really don't do any transformation at all is because you perceive the agile as something you change you tweak and every everybody else is keeps the same right or they really don't feel like part of the change and you see most of the organization has this kind of digital innovation fancy lab where only the cool people work on and they address differently different deficits different places to work different rules and the rest of the organization keeps the same and you say you see okay if you want the organization to change we are all the same organizations you cannot be that this built a kind of duplicated organization with different values and cultures and that's why I still believe that this kind of pilots this kind of specific areas created for agile and innovation lack of this this kind of invite to the rest of the organization to join the transformation however what we see now and probably the the what the the movement the clever movement that we are running is that most organizations are thinking on new way of organizing the teams into balistreams which is more oriented to the products we have to the applications we have in and the business they represent than the projects or the initiatives we work on and this will obviously give us a better usage of the resources the team members and the people that work with us so they don't have to switch between projects and meetings and different requirements people and business people they work on their teams they focus on their teams and the technology and the applications so they can be more specialized and probably more productive so the basic payload modes are agile silos multiple sources for requirements and pilots that do not consider scale even if you are going small you should consider how to scale that model and what needs to be a waiver what needs to be a change of the processes what needs to be thinking again in terms of the scale and most of these pilots also do not include any quality or compliance processes at all because they feel those processes are stoppers for agility and to be honest as a consultant I have to say that even even government or really heavy regulated companies should be able to take advantage of agile so the idea and the invitation is to think big right is to go big even if you are going to deliver a small proof of concept of agile you have to think big on your roadmap and the first concept I want to bring is the delivery pipeline probably you have heard it and the idea is that you build a pipeline from the ideation to the delivery of the solutions and the usage of the solutions because some of us work on platform as a service or or software as a service or as a service models and this means that the product itself is a service that keeps going on and probably DevOps includes the usage of the of the product right at the end pipelines connect at least two points and in this case in the organization is the ideation the finding of new features or the definition of new features and the creation and the delivery and the maintenance of that operation of that feature so first step design thinking on scale thinking on scale even if you go small on your pilot jump it right think bigger what happens we want to try to do this with all our products or all our IT department what means to be bigger right yeah and it means that IT departments should think on the governance of everything even if they are not the innovation area or the product management area if they rule the tools that will govern these processes that it happens most of the time with get left get left is a tool that probably is managed and governed by IT departments then you should invite other areas to participate and somehow IT is governed is doing the like the big picture for the whole organization which is forming a strategic and clever because if you are thinking on DevOps for your organization that requires a lot of IT solutions to operate so why you delegate that to other areas if you can help the organization to build this value stream solution and this pipeline to end from the ideation to the construction of the solution one tool to rule them all I hate those kind of solution where you have to click 100 times to get the other tool to get the other description and the requirement on its early stages in another phase and then in another when you have a powerful tool like GitLab that provides you a really good tool set to get early requirements to do some sort of portfolio management to even have like a like a like a funeral for those ideas to become requirements and then to prioritize and approve those you can build those processes within the same solution so you can have the big picture GitLab team is working all the time on new features and portfolio management and ethics and multi-level ethics and they are improving and improving and the more users jump into these kind of features obviously for them will become a focus I already talked sometimes with the team working on that they have great ideas but obviously they are focusing on the features people use the most while this is I think the secret ingredient that could just really put GitLab as a single source of truth and beyond the development of course we are not thinking about IT even if IT department is focused on the development and maintenance of those products and that's what basically DevOps means development and operations development for me and the organization also includes the definition ideation of the features of the product so stop thinking just on your development or code coding part involve a bigger picture not not to do that work but invite them to the process so you control how you fuel your new engine or the engine you are building or upgrading because otherwise you will still get crappy requirements or not so functional requirements not so good functional requirements that you will lack of delivery because the requirement is not prepared for an incremental release for example so the way we think our product it's something that we should be concerned of and if you don't get attention on that probably that you're all the four will still block by the way you fuel your engine some things are tricks Git can help you get there GitLab is a really powerful tool to solve this but be careful don't try to overuse scope and scope labels labels and scope label sorry be clever on how you set up your flows and how you set up how the requirements flow through your processes and be clever on how you organize the groups and the projects on your on your on your GitLab setup because it will make easier for the non-technical people to understand easy to visualize the flow or it can become really complicated so even the process of the creation could be incremental and you can see processes like link portfolio management and safe and the sandwich technique to complete these processes is about if this is your delivery pipeline and you so only focus on agile and your development teams probably you are in the middle of the pipe and you still have bottlenecks on the ends so work on the requirements gathering and work on the delivery even if your agile teams are still on early stages and and and not able to deliver yet in incremental at the end this is from ideation to delivery and not from approval of the business to the prioritization to the delivery you need to start thinking on how the requirements are conceived from the beginning and how they get to you right thank you so much my name is Alberto Dominguez again I'm happy to answer your questions and feel free to contact me for deep discussions