 We made it. Thank you so much to be patient. So here today, it's me. It's Hylenia. I'm a senior agile practitioner for the Coral Agile System Engineering. I've been working at Red Hat for three years, more than three years. And I worked within OpenShift, and now I'm working within Proud. That's why today with me, I have Irene. She is one of the engineers in the RALAGE team that I work with. Yeah, good afternoon, and nice to meet you all. I'm Irene Diaz. I'm a software engineer in the RELFORCE team, and we are responsible for RELFORCE, as well as for the IOT. Nice to meet you all. So in this talk, we are going to try to explain how we managed to create a successful environment so that the team can get better. How our specific team transformation went, and at the end, we'll finish with a couple of key points that we should take away from this talk. All right, I think we all know that change is hard, right? And to make an environment to be successful, we really need to try to face the, to handle the pace of change. People deal with change in different ways, and we need to take that into consideration. People go through different phases, and I want to show you here an example. I will be using the Kabler-Ross model and explaining this with a real-life example. I think each of us here probably had the experience, this situation. We basically had a key team member leaving the team while back. It was a high-performing individual, and we had, it was a great loss for us, basically. So I want to show you this with this example. The first thing that happened for us was that we were all in shock, so we were all surprised about what was happening. And the second phase is the denial phase. So here it's when we are actually trying to look for evidence that that didn't happen. So I remember personally talking to someone in the team and saying, no, I cannot believe this is happening. It's really true. Then people usually move to their frustration phase, and this is even the phase where people are angry. So they usually try to blame themselves or they try to blame someone else. Then the next phase is the one of the depression, where there is a lot of mood, low energy, lacking productivity. And from this point on, we move on to actually more positive phases. So we start with the experiment. Here it's where people try, start to deal with this new situation. And they start to be more positive about that. And then we go through the decision phase. Here people, they start really accepting that things changed and they feel more comfortable and positive about the whole situation. And the last phase is the phase of integration. Here is basically the changes now status quo. And people go back to the normal life basically. So I was saying that we really need to handle the phase of change because as I said, people go through those phases and some of them, they just go through few of those phases. Other people maybe go through all of them one by one and people move backwards and forward between those phases. So people really need time to actually deal with the change that is going on. So I wanted to share with you what I believe is the foundation of a culture that is needed to create a successful environment for a team transformation. The first thing is creating conditions where the team can actually start new behaviors. And they do that through new habits. When we talk about new habits, new habits are basically reinforced patterns and they need to be consistent. Consistent in bad days and good days. So really consistency here is the key to enforce new habits so they can change behavior. Second is creating a goal. A goal that is inspiring and scary at the same time and that it goes beyond comfort zone for people. A goal that is gonna sparkle imagination that is gonna engage heart and mind for people. So it's gonna bring all together so that you can actually go through the silos, break the silos that you have within the team or even within an organization. Third, fourth thing is to actually start practicing transparency and open communication. So basically people really need to understand the why behind the decision or at least they need to understand how the decision was made. People, I think we can all say that we use a list to say that the, sorry. We use to say that the change is needs to be, it's difficult for people and that's why we need to open communication within the team. The next thing is about creating idea of meritocracy. So great ideas comes to people attention, to the leaders attention on different ways. It can be because they come directly from the leaders or because those idea comes from the people within the team or an organization. So they can come from different levels but to do that you really need to make an environment and a culture where people are not afraid to speak up, to share feedback and to be open. There is always someone that is gonna merge within a team so you need to try to create as well an environment where people where a leader can emerge in that. So that's really important as well. Last but not least, I think I didn't mention this word yet so maybe you were expecting it. It's agile principles and values. And so the agile has a lot to offer in terms of transformation. If we think about limiting the work in progress or if we think about creating self-organizing teams. So if we think about prioritizing the work so that people can actually focus on delivering value for their customer or stakeholders. And we have as well the values that are really relevant like commitment, courage, openness, respect and so on, right? Okay, so I think I'm gonna end over now to Irene to talk about the team. Yeah, so our team is six people which are the developers. We come from different experience levels. At backgrounds, there are people who have been in red hat for more than 10 years and so on. Others like me are more new to the team and so on. Our team is fully remote. That is something that causes some issues because we are not used to dealing with people. We don't know each other and sometimes there is some kind of context that is lost. You cannot yet simply go to someone's desk and strike a conversation with them in order to, I don't know, find a common ground in an issue or something like that. So that is something that is lost. Being fully remote, so do you have to make the most of the meetings that you have scheduled and so on in order to be productive and so on? Another thing is that the team had different familiarity with agile. There are people who have been working for agile. Others like me, we studied it at the university but this is our first job with the framework so we had to learn it again. And of course, the team is still growing because we are building products in an emerging market. So the industry is growing as we try to identify which are the areas that need most of the focus. Regarding to our Scrum team, we have all the roles that you would expect. We have our fantastic Scrum master which is Eleni Aguilera here, the product owner and the rest of the team are the developers and yeah. So let me talk to you based on the documents stages of team development, what happened with our team. So Takman says that there are like four different stages, the forming, storming, norming and performance stages and there are a couple of behaviors that are more common in those stages. For instance, in the performance stage, everybody in the team is feeling really very excited because I mean, there are new things that we want to work for, I mean, we want to work on but that excitement is common but also there might be some anxiety going on because we don't know what the future might hold. And overall we can say that there is a low task accomplishment because we are getting used to the processes, the team and everything. Then we would get to the storming phase where we start to understand the goals or velocity. Yeah, some disagreements may arise because of the processes and because we are trying to understand velocity and some IELCO sets and so on. Yeah, then we get to the one thing. In the storming phase, we also have to take into account that people have different personalities so we need to try to identify which personalities work best with each other. So that is something that we also need to take into account. Finally, we reach the norming stage where we can see that the goals of the team are very understood and we know what are the things and the processes that we need to do in order to deliver. So overall we can say that there is an emphasis on team goals and we try to help each other because the goal is to perform as a team and then the final stage is the performance stage. Well, each member in the team understands what are the strengths and weaknesses of each team member and then we can plan and we can try to make the most of our team. So this team formed in 2021 and since then, I mean, these processes that you see here is not linear. So in our case, we had new team members, some team members that left and so on. So on one stage we were in the performance stage but due to these changes, I would say that right now we are between the norming and the performance stages. Okay, so now I want to share with you the challenges that we faced during our team transformation. So I remember being in some of the meetings that the team was having and they were discussing about can we actually move this user story to them. So that's where, is this happening with anyone in here? Is here and who, perfect? Yes, that's normal. So I actually helped them and guided them through the facilitating the discussion about the definition of done. So that they were all aligned on what done means for the team. Then we had some other meetings when they were actually trying to estimate user stories and something else that happened was I was hearing them saying, should we go for a three or a five? Let's go for a five because it's safer. Is this happening to anyone in here? Okay, cool. And another thing was, sorry, so I actually did some training with them about using story points and help them to understand how to estimate. So we aligned them as well on this topic. This is not happening anymore, right? Wow. Maybe we need to do another session then. Then we had, they had a lot of things to work with and it was a problem that like they had too many things to handle. So we really needed to understand which one were the priorities. So I helped the managers, yeah, the managers, the leaders and so on to talk about the priorities and then we actually talked to the team about this. And then we have the capacity planning. That's another challenge but I'm gonna tell you more in a second about this. So I'm gonna show you now a velocity chart. So here we are at sprint 31 to start with. Basically they are already having a change here because this was a team that was basically a bigger team. So it was, they were two teams together. At that point they were one. But sprint 31 was the sprint where the last sprint before they actually went, they split it. So the teams were going in different directions so they decided actually to split between them. And so that's why we see those high bars in here because it was even way more people working together. So if we look at sprint 32, that's where they start working together as a team. Here we were just before Christmas holidays. People were like, yeah, but don't worry, we can do everything, right? We're gonna be able to do a lot of things. And so we see that they actually committed to 32 story points and they were able to deliver only eight, it was Christmas, so it's all right. So we go back in January and we still had people doing the onboarding as well because we had new people joining. But still the team was like, yeah, we're all back from holidays now, we're all here, we can do a lot of things together. So they actually committed to do even more, 48, and they delivered only eight points again. All right. So sprint 34, it's when the team started to feel a bit more confident, the onboarding was going better for everyone. And yeah, they were like, yeah, we are a team now, cool. We can still do a lot of things, right? So they committed to 43 and they deliver 10, bit better. Okay, so here we start seeing some challenges. First, it's about the capacity. We couldn't really understand the capacity of the team at this point because they were carrying over stories sprint by sprint. Is it happening to anyone? Yes, yeah, a lot of fans, okay. So we did try a thing. So we decided to actually go back to our definition of done and review it. And it was specifically a point that was saying we are gonna move, a user story is gonna be moved to done when the PR is gonna be approved and merged, right? Cool, yeah, that's what we were doing until now. But we had to review that because of this carrying over the stories sprint by sprint. So we changed that to, we are gonna split our story into two different story and the task, basically. The story was the implementation work for the team. And they were like, yeah, I did my part, right? It's all done from my side, but then they needed to wait for approval from upstream or from external teams and so on. So they were like, yeah, I done my part, I can move it to done. So we did this. We split the two cards. We added an implementation one and they could move that to done with the story points. They estimated at the beginning and we opened a new task, basically. There was a tracker just for the PR. With zero story points, we were having heat there just to remind ourselves there is still going on. So let's see what happened. Things are going better now, right? 43 committed, 30 delivered. That's a big change, I would say. Now for them, happy times, but still there is still a problem here that actually we are over committing. How many of you come on and expect a lot of hints here about other committing all the time? Okay, okay, good. So we said, you know what? Let's try something else. Let's try to actually take a step back and commit to only one card each. So we tried this and we were like 29 that we committed. So less than usual. And they were actually to finish everything plus that they committed plus something else. So they deliver 34 at this point. So, you know, we tried different things and so on. So we experimented and we saw that this was helping the situation. Some of those things were helping others that we tried. Maybe they were not helping. So we actually adapted and changed and tried new things. Okay, so from my point of view, while there was this transformation going on, I was actually transitioning from Scrum Master role to an agile practitioner role. So I was there at the beginning with the team actually giving them solutions, suggesting things. And I had to move to actually guide them to come to find solutions themselves without actually imposing my ideas. The other important point here for me was that I wanted them to get into a mindset of continuous improvement. So they were trying to experiment all the time. All the time. I mean, every four weeks we were trying an experiment but at least to get them into this mindset of continuous improvement. And last thing is about finding a sustainable pace for the team, right? Because this way we knew what we could commit to and we wouldn't get to burn out. That's what we don't want from team members. Yeah, and from my engineering point of view, I mean, you have to understand that some emergencies may arise which are, for instance, back that affect our clients. So no matter how perfect the planning was, according to the three points and so on, there are times where you must drop everything and take the feedback, which is a task that doesn't have a lot of story points but you must do it and finish it as soon as possible. The other thing that you have to take into account is that we are an operating system team so that we don't work in silos and there are a lot of processes that we don't control. So even though we said from our point of view that the work was finished, there's still the docs testing and other things that have to give approvals to our task and that is why speaking the cards worked for us because it also helped us get to that mindset where we were accomplishing something because we saw story points moving to them. And finally, yeah, I mean, from our point of view, the story might be finished but we cannot ship something that is not tested and that hasn't been thoroughly documented. So we need to, I mean, focusing on one task allowed us to help those other teams in order to get the information that they needed as soon as possible so that everything was finished as soon as possible and yeah, and that story points could be moved to them. So does Agile really help engineers perform better? So personally, I come from an academic background and we work with the Waterfile Development Environment and I find that Agile, of course, is more flexible and it does not only allow developers to define their processes better but there are specific meetings where you can look back and try to think what is working, what is not working because with the Waterfile Development Environment, you have that psychological bad situation where you think that, okay, I haven't finished this deliverable in time or I'm running out of time to do my testing. So yeah, Agile allows us to identify what is working, what is not and what we can do about it. So we wanted to share with you some of the lessons learned from us for this transformation. It is still going on, I didn't finish, I mean. So first thing is deconstruct big change into smaller steps. Change fatigue, I really believe is now a thing and we need to try to, as I said at the beginning, people go through the different stages that we saw so we need to take into consideration that they need the time to adapt to the changes. So don't do changes, just fire changes one by one, right? They need to have the time and that's why don't come with like, oh, we're gonna change everything from today to tomorrow. No, we need to do that, actually deconstructing a big change in smaller steps. Next thing is about changing the behaviors of the team through their habits and especially very important, I said this before, is try to get the team driving actually the continuous improvement themselves within the team. Third thing is to try to build a team with enjoyment of practice. Enjoyments should be part of our daily life but when we talk about our professional life we usually forget about this and that's very important. So try to schedule some team building activities or even give the space to people to actually talk about their passions together and last but not least, to focusing on building the right things. So we are here to satisfy the needs of our customer or stakeholders so we don't just have to build things but we need to actually build the right things. Yeah, so we're at the end, what did we learn today here? First, we created an environment that encouraged and enabled the teams to develop and mature and that's how you build high-performing team. Second, this is our journey. So we shared our journey that is not a life other teams but that's definitely unique to us so you may or may not be sharing the same challenges. And third, we were successful building the team and high-performing team but as Irene said earlier, we were in that stage of high-performing and now we went back because things happened and now we're trying to get back to be an high-performing team. So yeah, change is hard, right? Okay, so we are gonna leave you with this sentence to reflect about the transformation takes a long time and value realization typically takes even longer. Thank you, thank you. Any questions? Yeah? Okay. The first one is very quick. Who is Tram or what do you mean? Is there any other... No, yeah, no, we started with Tram and we continue with that. Yeah, yeah, in this case, for this team. And the second one is for this team here. I don't know, probably to answer, I don't know. But if you talk about the change you mentioned at the top, the change in evidence, which is great. I think you did a great job at finding the way to get around the problem here. How did you reconcile with the changes? How did you get that kind of experience? How did you get that kind of experience? Yeah. Did you make any changes at the time or did you not really think of it? Yeah, so as I said... You don't have to repeat the question. Oh, yeah, sorry. So he was basically asking how we deal with change fatigue nowadays, right? So as I said, this is a thing going on and what you really need to try is not to have too many changes all at once. As I said before, you need to really understand that people needs to go through all the phases that I explained at the beginning. So you need to give people the time to go through this process, right? So there is a change going on. Cool, let's try this, we're gonna do that. But give them actually the time and the space to be comfortable with that change. And then you move on to the next steps. So this way you are gonna try, you are gonna avoid the change fatigue because if you're gonna have all the changes, all one by one, one after the other one, then it's not gonna work. That's when we arrive at the change fatigue phase, right? Yeah. From an engineering point of view, your team needs to communicate as soon as possible and if you haven't set up the environment for pre-communication, then you have to pay as an agile person, right? Yeah, so I'm very glad that what she said because it connects to what I am going to say. So I work mostly in upstream projects, so my team is me, a couple of people from my dad, couple of people from Google, a couple of people from Amazon, whatever. And again, communication is basically the main tool that we have. We don't have sprints, but we try to have some kind of periodic call to do this. But I cannot tell people what to do. I cannot organize work across companies because my release period is not theirs and my manager is not theirs especially. So what are some kind of agile concept that I can learn about and apply in this completely different situation? I think that's collaboration in here. Yeah, yeah, sorry. So here he was asking about cross-collaboration basically between co-operated teams and different teams working together. So I think it would be all about collaboration together and try to communicate. So try to find at least sometimes few times, for example with them, we couldn't really find the time that would suit everyone. But we settled in the end of finding two hours in the week on a Tuesday and a Thursday to actually meet all together just for the one hour to start with and try to do all the things and discuss all the things that we needed to. Yeah, in our case we have one hour every two weeks, hopefully with some people doing it at six AM and some people doing it at 10 PM. Yeah, yeah. Because it goes from Pacific Coast to China. Yeah, yeah, I see. Yeah, it's a piece of cake. As well we use Slack for example and some of the communication are over there as well for the teams. It's not the same thing, I know, but yeah, try to find some time at least even at 30 minutes maybe three times per week to gather all together. Okay. And one of your suggestions of splitting the cards? Yeah. I think is something that's one thing that happens with upstream. So I think doing that with upstream helps you get over that point because they won't fit into your sprint schedule if you try, if you, it just will never work. Yeah, exactly. I think it is good to split the cards and let that happen, because otherwise you can't. It's a different schedule. It's just a meeting. Yes, yes. You're lucky. Everybody has seen that. Yeah, so there was... One last quick question. How do you handle the handling after the split when you are lack of senior developers and you get in like a lot of hard topics and you cannot split them into senior developers? Do you have maybe similar issues and then you have a lot of hard topics, a lot of similar developers and you cannot be given that because there isn't a single test on that. Because senior developers are not working. Yeah, so basically he's asking how do you deal with the fact that senior people, developers and engineers don't really want to split cards or lose time doing that, right? All these actually came from them. So they saw the challenges from them. They are here. They actually saw the challenges and they started the discussion and just helped them facilitate the discussions. And they were like, we really want to try to actually improve the situation, what we can do about it. Let's talk about that. So it's not something I did in pause to them. It's something that came from themselves. And that's, I think, it's a very important thing because if you go there and saying, okay, we're gonna do this and now you're gonna do it like this, you're not gonna have people happy about doing that, right? But if you give them the time and the space as well to try to understand what are the challenges and let them see as well what are the challenges, then it's gonna be different. And they can start having those discussions together. And they were really worried about the velocity by why it's like this. It didn't come from me, it came from them. We found that in a lot of cases with the senior developers getting there and just without the cards and just smaller ones and helping them actually better to find the problem. Yeah. So that they could help the junior developers and actually help their own understanding of the problem that we're trying to solve. Yeah, exactly. Farron, cool. Anything else? Yeah. Yeah. You said that the change was made on the team, basically. How many people did not survive the change in terms of how many people actually did because of the change? We are all here. We didn't lose anyone. Just the guy that decided to move on just for personal reasons. It wasn't nothing really related to the team. So yeah, we have all of them here. They are over there. If you want to talk to them later, let's have them. Cheers. Yeah. Okay. Cool. All right. Thank you so much.