OK, we'll start. Uh Hello everybody. Hello, dear friends from women in tech network. We are very happy to be giving a talk here among such amazing lineup of speakers.Uh Today, we will be uh speaking about shift left in the software development life cycle, an approach that we have recently implemented in our company. Uh First of all, we'd like to introduce ourselves. We are a group of engineers currently working at Hop. We have a crazy good, good front end engineer in the group, Laa Lopez, a rockstar data analyst, Agus Santos and two Andrea Q A engineers, Rebecca Pores and myself, Anna with uh in this index. I'm going to give you an overview of what we will discuss today. First of all, we will review the traditional model of the software development life cycle because to go forward, you need to know where you come from, then we will get to know the definition of the shift left model. After that, we will give you a a sneak peek of what wallop is about as context. Following that, we will see how we implement the chief left model in our current organization. And lastly, as a way to wrap this presentation. Uh We will see a number of which were the ups and downs we got from this approach. So let's get into it. And now August will tell us all about the traditional approach of the life cycle.

Hi, everyone. So when we talk about traditional life cycle, we talk about the software development life cycle. That is a methodology that provides a framework for software creation. We divide the software development process into a series of steps that can be assigned, completed and measured.

If we go through each of the steps, we first have the strategy phase that involves project planning where discoveries and analysis are done in order to define goals. Also the requirements need to achieve the plans are gathered and defined together with the estimation of cost timing and resources.

In step two, we have the design phase. This phase involves uh analyzing requirements and identifying the best solutions in order to develop the software from the U I and engineering point of view. Usually product and te refinements are done in this phase where teams look for the best ways of integrating features within the current infrastructure. In step three, we have the development phase where engineering teams go and develop all the requirements defined in previous phases through sprints.

Step four, we have the testing phase that this phase is also known as the regression phase where qas are involved in testing for quality analysis where they check the correct function functionality of the feature and if customer requirements are met, this is partly combined with the development phase where developers also test automatically their work.

In step five, we have the deployment phase that involves the launching in production of the feature and monitoring its correct functionality. And last but not least we have the maintenance phase, which is a continuous phase where monitoring takes place. But it's not only um for resolving customer issues or fixing bugs, but it's also it's an opportunity to find new ways to improve existing features. To conclude with this approach, we wanted to share some pros and cons of this methodology. So from the pros point of view, this methodology provides a framework where a problem or a goal is defined together with proper roles, definitions as well as inputs or outputs of each step in order to have a clear perspective of what is needed to reach the final launch of the feature.

But there are also some cons such as not being a cost effective or time efficient process where risks are not minimized through forward planning, which is, which usually ends up being reactive to bugs. So now that we have introduced the traditional approach, I will hand it over to rebe to tell us about the

shift left. Thanks. I was let's jump right into seeing what the shift left approach is. The shift left is an approach where quality and testing practices happen earlier. In the development life cycle. If we see the different phases, we will see that the shift left occurs in the planning and design stage and also in the develop and and build stages. Whereas the traditional approach that I was watching mentioning has a testing stage and it's mainly focused on the deploy and release and monitor and analyze. It is important to mention that the traditional test approach has a testing phase. Whereas in the shift left, uh testing are a series of interventions along the whole cycle. If we see the attention of detail that both different models have, we see that the shift left has a higher attention to quality because um quality is not owned by a single role anymore, is owned by the whole team. So the whole team is accountable for quality. Therefore, it enhances um the the attention.

Then if we see um the cost factor of error correction, we see that in the shift left, it's way less costly to fix errors in advance rather than in the traditional test approach where um issues are spotted at the end of the cycle and the cost of fixing them, it's much higher.

Now, um this uh being said, let's see which are the attributes of the shift left approach. If um we see um the focus on continuous quality and whole team ownership, this is because now quality is owned by the whole team, then um it happens earlier. Um shifting left reduces risks and many issues are addressed um before they are committed to production, it enhances the continuous collaboration um of the team. It encourages everybody in the team to be communicative and to be collaborative. We understand the product and understand the behavior of the feature that is about uh to develop much deeper and also much earlier. Um We continuously test uh from the start with this approach. And uh this approach invests in issue prevention over issue resolution. There are different dynamics put into um and assessing risks and also mediating this risks earlier in the in the life cycle. If we go to compare um the different models, it is important now to sit and give an overview on uh what's the shift right approach. And the or the traditional approach, as I was mentioning, um this approach focuses quality at the end and also every phase is very staged. But it can be a really good compliment for the shift left approach that we are giving because shift right allows us to uh be involved in monitoring uh user behavior.

We can analyze business metrics, we can also use it as a stage for um running some tests such as performance and security metric or we can actually test some deliberate uh failures. So it can be very good complementary to the shift left approach. Now, let's see the shift left approach um which in here, as we have stated, um testing is an activity is not a phase anymore. It's a series of interventions and this allow the team to be uh testing early and often um we need a really open minded team. Since the communication go beyond the role, the objective is to detect problems earlier and we avoid problems before they happen. Um We, we can say then that the pros and of this model are the communication is improved. There is constant feedback, we have risks mitigation. Uh We boost the software efficiency, we produce faster. Um And we catch back much earlier on the comes and there might be some blurry limits of the, of the roles. Since uh we keep encouraging everybody to go beyond their scope. At the beginning, some lines might be blurred and we might need to put some efforts on this. There is a drastic culture in, in the team um narrative and it might not be easy. Teams are comfortable working in the, in the way they have been working traditionally. So it might require some time to accommodate to this new shift. And um in the uh another point to, to state is that the test documentation needs to be a bit more exhaustive since it won't be performed by single roles anymore.

It will be a documentation performed by the whole team. So it needs to be much clearer. And this being said now la is gonna give us an overview on what Guap is.

OK. Thank you, Abe. Hello, everyone. So now uh that we uh saw what the shift left is, we are going to talk about uh what is well about and how we are organized uh inside the company here. We have an example and to explain a bit uh what is well above uh we are a platform founded here in Spain for buying and selling uni goods uh to give them a second life and you will be able to do so from our apps for I Os and Android. But uh we also have a website uh where you can uh use the shipping method with our purpose. We want to encourage a mote and promote uh sustainable consumption and encourage also a more dynamic and circular economy as a summary, uh our reserves uh earn money and we take care of the planet and now uh that we associate it, let's see um what the organizational model and how we are organized, organized uh inside the teams basically.

Um we are organized by topic teams and maybe you are wondering right now what uh is a topic team. So it is a multidisciplinary team that has uh ownership of uh a part of the company or the product. And you can see on the drawing that we have on the left that um inside every topic, uh we have engineers, analysts, marketing people, and so many other roles involved. But it will, depending on the necessities that we have uh in everything. Uh it's really important. Also to note that the teams do not work alone or is related because we collaborate with each others uh on our current basis. And now uh Anna will introduce us uh how we applicate uh receive left inside the company.

Thanks Leah. So before applying ch left in wallop, we had several issues that we wanted to mitigate. We had weights, bottlenecks and dependencies. Developers had a safety net, an insurance plan because they knew that the tester would review the implemented product afterwards.

And because of this, they wouldn't focus that much in testing and impossible cases. Since testing was a phase that came after development, there was a bottleneck effect as developers had to wait for Q A to review the feature in order to merge to master and also feedback came late, was slow because of the weight and therefore fixing errors was more expensive.

Another another issue to mitigate was the workload on manual testing after development. Uh Q A engineer was mainly focused on validating regression testing so they wouldn't focus on other important aspects that happened in the the finding stage since testing came later on. After development, automation was not so much in the picture. So automated testing coverage was low. Another aspect that made us go for the shift left model is that we wanted to release faster and experiment more, releasing faster means that we would be able to do more experiments since we wanted to do more innovation. We needed to get more user insights and select or discard product variants based on that with the old approach, experimentation would take more time and therefore, uh user insights would arrive later and last but not least we wanted to improve quality. Since testing was a phase, the team had the belief that the testers or the Q A team were the only ones responsible for quality. Discuss that we were finding much more errors in production or during the regression done before the releasing, which are the two stages where more bags where bags are more expensive to fix.

Since risk analysis was not so important in the software development life cycle, we realize of the presence of some risk by the end of the cycle which made it impossible or very difficult to react over them. So now we've reviewed all the problems that we had before we wanted to improve. Uh Now, um uh here is where the shift left model comes in. I want to make a disclaimer here by, by saying that as LAA mentioned, we have several topics in uh topic, teams in the company. And while this model is being implemented by most of them, teams have different levels and different velocities, some teams have adapted really quickly and while some others are having more trouble, this being said, now we will take a look um to the solutions from each tax point of view, we will start with product and then we will see Q A and then development hours will start.

So from the point of view, the shift application includes early colla collaboration between team members, especially between product and tech in the first stages of the cycle such as strategy and design, as mentioned before. This means having idea workshops involving the engineering teams from scratch to share their deeper knowledge from the tech site, having experiments and tracking sessions when they apply and defining the requirements through three amigos approach and their proper review by the whole team.

This helps translate it into robust communication between all Latin members through the whole process. Giving a feeling of joint ownership of the feature to be developed, being able to follow up metrics related and understanding the impact of their work. That being said, I hand it over to Anna to talk about shift L allocation in the Q A team.

Thank you always. Um So the Q A point of view, we have seen three important points where our ways of working have improved first in the testing area, uh then in the collaboration and in the communication between team members. And then in the scope in terms of where the Q A engineers put uh their efforts in the testing site, we have seen how manual testing workload has been reduced. We have stopped validating each feature after development and have put more effort in defining the acceptance criteria, test plans and, and all of these before anybody gets to coding. This has led us to explore more as most of our manual testing is now basically exploratory.

From a cultural perspective. We've seen how the team has evolved their thinking. We have stopped seeing testing as a stage and we are now seeing it as a series of interventions that can and should be applied during the whole software development life cycle. As for the collaborate, collaboration and communication, we've seen an uplift in conversations between Q A and development regarding testing practices. We've also seen a deeper knowledge on business impact of our deliverables. And also we've seen how the shift left approach has improved leadership and communication skills for all team members. As one of of the basis of this approach is that communication between all of the team members needs to be higher and sooner. And in the last point, we've seen a change on ours. Cope Q A engineer view is less about checking and verifying and it is more about strategic thinking, requirement, definition and risk assessment. As the approach name suggest shift left is about bringing quality practices to the left.

So it just makes sense that the Q engineer is more focused on these activities which happened to be on the left of the software development life cycle. Since the figure figure is less about manual testing, we can also spend more time on analyzing quality metrics and providing further insights to keep the life cycle active and keep iterating it and improving it. For example, we've seen a 55% reduction in definition bugs. What does this mean?

So inter internally we classify bugs by root cause and bugs that were caused by a lack of definition have decreased by so far by 55% this year compared to the data that we have from last year and this is it from the Q A side. Now, Leia will explain to us the development point of view.

OK. So I would like to start this part by commenting that for me, uh the most important thing about the shift left implementation is that the developers are not only limited to go um because we participate uh throughout the entire process of creating a feature, like we can see on the explanation.

Um If we take uh the left drawings, we are part of the product meetings, providing our ideas and investigating and also raising our hand in case that we see any technical limitation in the future development. Um This is very important uh for preventing uh future mistakes. So once the development has started, we test our own code with unit test and sometimes uh also we do an integration test. On other hand, uh we do a manual de direct in the beta environment to check that everything works as we want or we plan it. Um this delivery methodology, we think that it's really a G because uh we make uh many small deliveries instead of one really large um to try to give value to the users as fast as we can. So the sooner than uh we launch at list, the sooner that we can start monitoring user metrics and see if they like the new implementation or if we need to change any part of the product that we just created um to close this whole cycle. Um It's essential to create technical documentation if it's necessary to give visibility to other topics, or maybe we just uh want to create it for our own topic team. And now uh as the talk is almost over, let's take a look. Uh a brief summary of the benefits of the ce presented by this work model as we have seen, um all the roles are involved through the entire uh future creation process.

So we are forced to say that way to understand what is being done at all the times working this way. Uh We provide high value from start to finish from all the team members. It's sequential. As you can see, all the benefits are directly related because if we pay more attention on design plan and investigation and stages, um we are moving uh from reaction on bugs to predict them. So we are going to introduce less bugs and we are going to deliver uh features faster. A really important side note is that small deliveries and problems identified in advance are cheaper, but also uh faster to solve. And uh now we are going to see the things that maybe are a bit complex when implementing shift left in the companies. Um At least when we are starting sometimes uh it's a bit difficult um for teams that maybe are not really cohesive or that they are really used to do a very specific role and not getting uh out of it. But we think that if it's aggressive team that collaborates well, um or maybe a new one and there should not be conflict even if at the beginning uh is out of the comfort zone and the team members need time to adapt to the chip left on other side that we have on the right.

Um Like we mentioned before, uh if the roles are not well defined, it can confuse uh the people uh involved with. So it's really important that the scope is closed and everyone uh have clear about what they should and what they should not do. And yeah, this is basically it on our side. Uh Thank you very much. Uh We left here our website. Um Now, uh you can also buy from web. Uh We have available Spain, Italy and Portugal. Um So feel free also um to contact us if you need something or you have any question, we are going to be available for you and that's it. Thank you.