Transcript
Pasco Duarte (0:01)
Hi there. Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when like processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my he said, I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of Agile all succeeding that inspire you to action. We're talking real experiences, practical solutions, and of course, amazing insights from leaders like Gojkoacic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The early birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is, and get your early birth ticket. Now, it will only be available until early March, so grab it now. And now onto the episode.
Vasco (2:06)
Hello everybody. Welcome to our Wednesday, the Leading Change episode this week with Mateusz Kommander. Hey, Mateusz, welcome back.
Mateusz Kommander (2:14)
Hello, Vasco. Happy Wednesday or meet of the Week. Happy seeing you again.
Vasco (2:21)
It's only Wednesday, Captain. It's only Wednesday, which means we got three excellent episodes with Mateus coming up. So stay tuned. And today we're going to talk about change, of course. So, Matthias, share with us that process of change that you were involved with and you know, how it went from beginning to end. And then highlight for us the tools, the tips, the tricks, the techniques you learned back then that you still apply today.
Mateusz Kommander (2:47)
Hey. Yes. So today my history about change I think will be actually very, very funny one. Maybe not funny one, but very, hopefully very inspiring. So for me, the change I was for us, we need to remember as Scrum masters that for us to be able to provide or to implement any change with any organization, we need to have the support and quite often not only the support from the team or the product ownership, but quite often from the manager perspective, if we do not have that, it's hard to provide that change. I was fortunate enough to be in an organization who are quite open into experimentation and into experimenting with any change and any approaches. And my story actually began when the organization decided to provide improvement into one of their already existing app. So they aimed to further develop an application that will be supporting employees throughout the say their engagement with the company since the onboarding process, throughout their work till the offboarding process, including all of the aspects how the employees are supporting the the company. So we've started with a plan with a goal and with some small POC around that. And I was actually asked to, because I was already leading one of the teams in that organization, I was asked to support that second team as well. And at the beginning we've started very small, but the team grew quite fast, quite a lot with multiple skills that were needed for our development. And I've met or I was placed in a very quickly in a position when the team was too big to be a typical scrum team. So the organization didn't implement any scaling approach per se within any of their products, within any of their developments so far most of their teams were small enough to be able to work within rather one product team, product oriented team. So this was quite new for them. Fortunately for me in my past I was working in a quite big company and within scaled program approach from the biotech industry and I was able to bring that experience into my new project, my new product. And together with the program manager who was very supportive, her main goal was Mati. I just want to have the products to be delivered. How you do it is really up to you. And so we started introducing a little bit split based on very small and agile teams that can work on separate aspects of the application. We called those small, let's say individual groups of about flights. We're aiming to not have more than four people in one of the flight. So we are aiming to have the one qa, one backend developer potentially that can also leave that part of the team and Android and iOS developer. So the aim was that because we have so many different areas of the application to be developed, we didn't want it to have one team to be focused on that or for example to be the whole team of almost 20 people joining one call and listening about different aspects of the organization of the of the application. The intention was that each of the flights could Focus on one aspect of the product, develop, finish it as soon as possible and jump to something else if needed. We were aiming to maybe join, fully join the two of the small flights to work on one of the bigger products for some period of time, but then as soon as possible split them again. So the experiments started, the experiment started quite promising. We were able to to very fast develop first improvements within this team. Unfortunately at some point we were a little bit lost into silosing with that split. So the teams started naturally to somehow aim into splitting the work. Not really vertically, but rather horizontally. So I've started.
