Video
Podcast | Cyber trends – what should we know?
Cyber security is a process that we need to approach comprehensively. On-the-spot action can give the illusion that ‘som...
Podcast | SDN behind the scenes – Plan the developers work, i.e. R&D projects through the eyes of the Scrum Product Owner – part. 1
Who is a Scrum Product Owner? What is their role in the company? Join us for the second part of our conversation with Michał Mąkosza, who will describe what it’s like to be a bridge between business and technology, how he manages to translate the language of technology into business and vice versa, what is the AnArch team, and what attracted him to EXATEL.
Telecommunications technology is changing right in front of us. What was once a dream is now becoming a reality. For example, the SDN – Software-Defined Networking, a philosophy shaped around 2010 that is currently conquering the world of telecommunications technologies and creating a new market, estimated to be worth as much as $43 billion in 2027. In this podcast, I talk to people who create solutions based on the SDN philosophy: developers, architects, analysts. They are experienced people who simply know a great deal about programmable network technologies.
Please enjoy the next episode of the podcast SDN without secrets. Piotr Mierzwiński.
Piotr Mierzwiński: Today, our guest is Michał Mąkosza, Scrum Product Owner in EXATEL’s SDN project. Hi Michał!
Michał Mąkosza: Hello.
Piotr: I wanted to ask you about the specifics of your work. Who is a Scrum Product Owner exactly? This is a rather unusual position, or at least it seems to be.
Michał: In a way, yes. On the one hand, perhaps for people who work in Scrum every day, it may seem strange to use the word Scrum in the job title. However, I insist on adding it, because for most people a Product Owner is someone a bit different than Scrum envisions. The peculiarity of this work is that in Scrum, the Product Owner is the bridge between the business side and the developers. So the specificity is to speak both languages at the same time.
Piotr: The languages of developers and technicians?
Michał: And business.
Piotr: Business as well?
Michał: Exactly. This is the biggest challenge. A Product Owner must understand the business value. Why something is being done and so on, where the money lies in it, what is the plan and the means of execution of that plan. On the other hand, in my opinion, the foundation of Scrum is that this Product Owner is close to the developers team. Close to people who know technology, one that is out there, as well as programming. Scrum seeks to expand beyond IT, beyond programming. Currently, in Cora, it is most popular for programming. So on the other side, we have this developers’ language.
Piotr: Before we get to the part of what Scrum generally looks like when developing an SDN product, you mentioned that… You translate business language, technical – telecommunications language. It is known that Software-Defined Networking technology primarily has its counterpart in the telecommunications world in the language of programmers. How do you manage to do that, when these are two different worlds? On the other hand, I know that you are a person who has some experience in both areas, right?
Michał: Yes, that’s right. The specifics of my employment history are that I come from the world of telecommunications. I studied this, and I may even still remember something from my studies. For the first half of my career, I worked for a telecommunications company, and then I moved more into the areas of IT, programming, analytics, system analytics. Coming to EXATEL, I was fascinated that a telecommunications company had built such an internal software house. A startup of sorts, by the way, but a very modern entity internally. And that suited me, because it combined the two worlds that I have encountered at some point of my employment history.
Piotr: You are the person who, on the one hand, created these telecommunications technologies, optical fibers, cabinets and all the things related to such an ecosystem of devices and technological solutions. On the other hand, you take care of business analysis, needs development and now you ended up with Software-Defined Networking, the SDN. How did you really manage to combine these three things, and is this diversity of experience, really reflected in how you create SDN technology?
Michał: I participate in this process. I can’t take full credit for creating it with these hands. Unfortunately. I take care of talking. This is what I specialize in – translating the approach methods from one side to the other. The philosophy of SDN is to combine these two worlds – telecommunications (what has long been mastered) and IT (Software-Defined Networking programming). These are the two somewhat related worlds, but they haven’t really interwoven that much until now. It’s only now that they begin to do so. The fact that EXATEL decided to do something like this, that the philosophy of Software-Defined Networking involves combining these two worlds, and me having had a glimpse of both at some point, made me very interested in the subject, the company, and the project.
Piotr: The year is 2022. SDN has been in development at EXATEL for some time. How does this translate into practice?
Michał: This is a book-size topic, I could talk about this for hours, so stop me if I drift off too much.
Piotr: That is why you are our guest today.
Michał: I’ll start with the fact that we are working in Scrum for this project. Not much of a surprise, since I’m a Scrum Product Owner. Developers work in two-week Sprints, when initially there is focus on planning and figuring out what needs to be done. At the end, we’re having a Sprint Review – a presentation of what they have done. Here I try to stick very much to scrum rules, that is, not to barge in there, no micromanagement or anything like that. At the same time, I try to keep the business side as far away from the developers as possible. That’s the beauty of Scrum.
Michał: Certainly, this part is an important part of my work, so that’s why I’m starting with it. So on the one hand, being a bridge between the two worlds, and on the other, making sure that these worlds do not clash with each other, because this is how it usually used to be. Business wants everything for ‘yesterday’, yet developers would like to have as much time as possible to quietly polish the code, etc. But back to what was an interesting challenge for me here at the beginning, it was to connect these worlds. The project is from the Research and Development category. It’s not like there was a template ready for us to just implement, type it in and we’re done, no. Here, it was necessary to conduct recognition much earlier. Business likes to have a plan and know exactly what will happen in the future. Business hates the unknown. In research and development (R&D), we have the exact opposite from the spot. We don’t know what’s going to happen tomorrow, because the research we’re doing today may change direction completely. So a process was created that combines all these directions for us. This was my first challenge – to create such a process, which we all would be able to understand. And it works effectively. We have this process written down and it works. It relies on Scrum for developers. They start with planning. What they have at the input are the elements. We work with a very popular tool, Jira, where we have Jira artifacts and there are user stories as well. They get these stories on input, and at some point they have to segment them into individual tasks for themselves. So we agree that there is something to be done in the Sprint and at the end they show what they’ve managed to do. There is an increment of business value. I have to put an asterisk here right away. There are really a ton of things to do in this project. We have already done quite a mass, but we have ambitions and appetite for much more. So these increments that occur are not that big for the business end user. This is another layer of difficulty to translate between the here and now and what the business would like to see. When I use the word business, I use it as a very broad term. So we have user stories at the beginning. These stories are produced by the AnArch team from our company.
Piotr: AnArch team? The anarchists?
Michał: This is the proper name we use. It is derived from a specific function: An+Arch = analysts and architects. The analogy to anarchy and chaos is appropriate insofar as it is their role to contain the chaos that is in the input and turn it into a more structured ‘what to do’ so that the developers don’t have to sit down and get a PhD in telecommunications. Because oftentimes, someone who does programming is an expert in programming and not necessarily in telecommunications, protocols and so on. It is more convenient and efficient for the developer to have some more digestible material at the input.
Piotr: What does such a process look like? Are we getting any business requirements? Does business come in and say: ‘I would like there to be a function that does a certain thing, e.g. control, check, verify, distribute the transfer or whatever’? How does it look like in practice? An information goes to the AnArch team, and then, how do they try to decompile it, break it down into parts, while at the same time trying to explain it to people who don’t really understand very much of how it works at such a high level, because they actually create the individual functionalities, the individual components.
Michał: I’ll try to paint this picture in some detail, but we would even have to go a step further. In the beginning there is an idea: let’s realize some functionality like Elan transmission (we want to provide such a service on our solutions). It really takes a lot of time and consideration, for a developer to sit down and write the first line of the code. First, we segment this into large elements – here I will immediately translate into the developers’ language – into epics. We have epics, individual stories storage in Jira, and each story is then divided into tasks. And that’s exactly what we’re doing – first we convert ideas into epics, paint ourselves preliminarily what there is to do in a given epic and what the scope of that is. That’s what the architects do. Then there is the analytical phase. Analysts write the stories to this. This then goes to developers, who, in collaboration with AnArch (analysts and architects), must understand the material provided and break it down into various tasks they have to do. And these tasks, of course, go to Sprint.
Piotr: It sounds a bit like such a rough friendship. Someone comes in, tries to say how many things there are to do (often things that are not always understood) and someone at the very end will be held accountable for writing it. That really sounds like quite a challenge!
Michał: That is a challenge, without a doubt. But a rough friendship? I wouldn’t add the roughness there. Nonetheless, we have the advantage of working in such a way and in such a specific project, which results in our AnArch team, those who commission what needs to be done, being actually very close to the production team. It wouldn’t have a chance to work if it was just a ‘here are the materials, read them, and then I’ll get it back from you’ relationship. Such things happen in the world, of course, but here, fortunately, it does not work that way. What they need to understand in the AnArch team, it that there is a lot more on the technical part here, therefore it is easier for them to talk to peole who also have a technical knack on the developers’ side. But you’re right, it’s kind of how it works: there’s a person at the beginning, an analyst who is supposed to prepare these stories, then they pick it up from the developers. However, this receipt does not look like this: here is my signature, you can invoice now. We all work inside, we’re the employees of the company. Rather, it’s looking at the end result and saying ‘okay, it’s working as we imagined’ or ‘no, something else needs to be done.’ This is exactly how it looks in sprints. The input is what the AnArch team has prepared, segmented the idea into epics, epics into stories, it was explained to the developers and they segmented it into tasks. They produce the tasks in Sprint and show the whole story at the end: ‘Here it is. Do you like it?’ a conversation ensues and it’s either a yes or no. If they don’t like it, something needs to be changed, and usually in Scrum, the new tasks are derived from that. And so it goes from there.
Piotr: The whole process seems to be very structured, a copybook. But what I’m especially interested in is your role as the Product Owner. As the person who is somewhere between this translation and implementation and is also under pressure from the business’ side. I wouldn’t say it’s shaping the product, but reinventing some things. Someone comes to you, saying ‘I want this functionality’ and you have to actually translate it into the SDN language. Are you responsible for that in the team? What does it even look like from a day-to-day perspective? And the second question, which immediately occurs to me, what does such daily work of a Scrum Product Owner look like in general? What do you do on a daily basis? Sprints happen once in a while, same for billing, and it is known that we do not live from Sprint to Sprint.
Michał: I will try to answer both questions, but you used a term ‘copybook’ to describe the process. This process is tailor-made for our needs. Besides, I have yet to come across a 1:1 implementation of Scrum. It is always a local implementation. It’s a very important thing that I keep repeating at every step, and it is possible that the team is a bit fed up with it. The process we have created and the rules on which we operate are supposed to be the framework on which we build our daily habits, actions, the things that go into our blood. It’s supposed to be a backbone, not a limiting armor dictating that we only have to act from here to here. It should be a form of systematization, so that we all know more or less what is going on and who is doing what. This is important. The process I’m talking about is not the letter of the law, it doesn’t force us to do things exactly that way, but it allows us to systematize things. Now I will answer your questions. Maybe I could start with the latter part if I could?
Piotr: Of course.
Michał: Everyday work looks like this: in the morning I make coffee. This is a very important point of the day.
Piotr: You have to start somewhere.
Michał: Exactly. In addition, I sit down to our holistic plan. In nutshell, this is a plan, from which I see what is happening from the developers’ side, what they see – the current sprint, the tasks that make up the epics. But on the other hand, from the way I see it, the same plan is an information from the business point of view – when will they have specific functionalities. From this side, this plan already looks like a roadmap. That means, we are on the right path to what we have assumed, and what I have promised to people in power – when can they reap the benefits of what we do here. It needs to be updated all the time. What I am personally proud of is that the holistic plan is such a self-winding machine. Meaning that if there is input from the developers that something has been prolonged in individual tasks (in a story, in an epic), it immediately translates into the roadmap. If, of course, it can be translated so explicitly. And on the other hand (from the business side) when there’s a new demand or requirement, whether it’s time or functional, I immediately know how it translates for me into those tasks, or I know which new task needs to be created now. So back to what I do every day. Looking at this holistic plan, as this sprint goes, I know how one thing relates to another. I immediately become alert, whenever something starts to go wrong. If there is an opportunity later on and I get a gap between the meetings, I am very eager to go to our scrum teams daily, where I strongly take to heart what Scrum says and what I was taught at the very beginning, and what the Scrum Product Owner usually has a problem with – to sit quietly. Don’t try to say that ‘it will be better if you do it.’ Daily is for the team. This is also something I need, to know what’s going on and implement what I see as my main task from the team side: to be able to separate answers on the spot and deliver what the team needs. Later in the day, I attend various meetings. Mostly its one-on-one meetings on variety of topics, but it all comes down to me constantly trying to monitor what’s going on and how it translates into the plan. And the other way: how the new requirements translate into what teams need to do. Of course, I could talk here about this other scrum artifacts – review and retro. I participate in all these elements. However, on a daily basis I just work with this holistic plan and the backlog to make it all tie together. A large part of my time is devoted to this plan, mechanism, process I’ve just talked about. Digesting what comes at the input level and what is coming in from the business. I don’t know if you’ve noticed what a smooth transition I’m making to the business part here.
Piotr: Perfect, I would say.
Michał: This takes a big part of my time. At all times, business has expectations and would like to have everything as soon as possible. My role is to react. Our circumstances are changing, especially in R&D. Say, it turns out that this research and development shows that something is not working in the path we have been following so far. This is the point where you have to pull out plans B, C, D from under the table. You won’t be able to accomplish something like this by going with just one plan. You have to run an alternative plan, that is, go back to the business and say: ‘this is our plan now.’ This is the circumstances, the monetary demand for resources, for people. It varies. The way I work with business is that I try to inform them, as soon as possible, about the changes and the other way – to understand what their current demand is. And this is what I was talking about at the very beginning. Where the money lies and what needs to be implemented as soon as possible to benefit from it.
Piotr: You said a lot about your daily work, planning, about a certain process that you follow every day. You work for a telecommunications company. In a company where the research and development process is not the business’ core. It is a very important element, but not the most important part of the operation of the entire organization. So how do planning and the reality compare? Because the projects you’re involved in, SDN projects, often last for about 36 months or more. Looking from the perspective of such long-term planning, even if we take it from life. The easiest thing to plan for is tomorrow. What’s a week from now is problematic, and what’s a month from now is all up in the air. Planning for 36 months is a challenge. What does planning versus reality actually look like?
Michał: You’re right in that what we do, in this internal software R&D house of ours, we’re a bit disconnected from the rest of the organization. We don’t connect to services on a daily basis, we don’t lay new optical fiber cables or anything like that. We are don’t speak with our external customers. You used that term, but from my perspective, it’s crucial for the organization, only the organization doesn’t know it yet, doesn’t feel it yet. What we are creating now will really be something fundamental to EXATEL in two years. But in order not to fall into self-delight over the project in which I participate…
Piotr: Which you are leading…
Michał: Yes, on the scrum side I am. I can’t take all the credit in this regard. To avoid getting into this part, I’ll try to answer the question of how planning relates to reality. Always, and I mean always, the plans are great and they do not work when faced with the enemy.
Piotr: Some say that plans are made to be changed.
Michał: Yes, this is also very interesting and there is something in it. Plans always, must be subject to revision the moment we implement them, because somehow the future stubbornly refuses to behave the way we imagined it will. And in R&D you have to multiply this times one hundred. As I said earlier, it is very often necessary to pause on the chosen path. However painful it could be, you have to decide that you will go down a different path. In a couple of places I tried to incorporate elements that build this possibility. The process I mentioned that we have segmentation. The analogy I made is that we have this process as a framework on which we superstructure our practices. It’s the same here. This is also the framework that allows me to react to what is happening. The fact that in Jira we have the transposition of an idea into smaller and smaller elements, until we’re left with what needs to be executed. If there is any change in the team, something takes longer, new tasks need to be added, then automatically these tasks go to my epic. I have an epic planned for a certain amount of Sprints. It lengthens this epic for me, and as a result, I can see it cascading down to the roadmap. I am able to respond to that. We exceeded a deadline that was non-extendible to me? We have to get back the other way. What to cut from this epic? What is absolutely essential? Maybe I should go to the business side and talk it out? Or maybe speak with the developers, ask how we can carry it out differently, so as not to exceed this deadline. It’s very fluid and the process I mentioned doesn’t limit me in what’s happening, but it’s a very big help.
Piotr: There is one question I ask all my visitors who are involved in R&D projects, who work with people, programs, business, architecture, Scrum, technologies, philosophy. Call it what you will. I’d like to direct this question to you as well, due to the fact that, besides being a Scrum Product Owner, you also manage a certain part of the team. I’m thinking about the team we talked about earlier – AnArch. It is quite a specific team. It combines the telecommunications knowledge with how to explain it to a developer who actually speaks a completely different language. What kind of personality will work best here? It is quite a specific role to combine these two, slightly different worlds – the strictly communication one, with the developers’ world of creation.
Michał: I could probably defend the thesis of these not being such distant worlds, but I will try to focus on what you said. It’s hard for me to define it so clearly. What certainly makes me work well with the people I have on my team, is their openness to challenges and their willingness to make the subject interesting. From my perspective, the topic is very interesting. Telecommunications is the future, but it’s more in the category of those things that are coming in, rather than something that is already mastered. Such a person must therefore like to learn. They must like to recognize topics, break them down, bite into it. At the same time, without doing art for art’s sake, they must also be able to present it in a technical way. That means we need a scientific mind. We have some templates for what we’re hammering this knowledge away into. The AnArch team does this, and when they understand it, they make records. These templates are there to make our work easier, not to limit us. I would say these are the most important aspects for people in the AnArch team. Curiosity about the world and a technical mind.
Piotr: Before the interview, you’ve also mentioned self-reliance. Your approach to implementing these projects is not so binary. Team Manager – Team. It works on a slightly different principle: we are all carrying this project and everyone is equally responsible for it. Right?
Michał: You’re right. That’s exactly it. I’m sorry, I forgot mention it, but it’s such a natural thing for me, something I work on every day, that it slipped my mind. Although, I did think of it for a split second. As you mentioned I manage the AnArch team. I’m the one who manages the schedule/plan. People adapt very quickly. Scrum approach, Agil approach, it’s not that we manage people. Everyone should know what they want to do and we provide the tools to do it. It’s the same in the AnArch team. It’s not like I’m dictating tasks. We talk about what is worth doing for the project. Just as I mentioned, people get curious, they get excited by such topics. It’s a lot easier to talk with someone excited by the topic, who comes to you saying: ‘now I’ll get on with this.’ I add business value to it, what I’m able to understand, and at the very end I try to help balance it in order to decide ‘yes, we’re going this way, this is a cool idea, this is what you’re going to do now.’ But it is not that raw, old-fashioned management: ‘as the manager I command’ You are right, this is a very important aspect. I would be hard to work with us for people who expect to be told ‘you start here and dig till twelve o’clock.’ These people must be driven to achieve a certain goal. This is something we can talk about, nevertheless, this person must have the will to decide for themselves, what they will have to do, in order to achieve this goal.
Piotr: Great. I think we still have some topics to discuss but we are also running out of time. Michał – thank you so much for today’s conversation and for giving us a glimpse of what the world looks like through the eyes of a Scrum Product Owner on R&D projects. I hope we will have another chance to talk, because there are still a few topics I would like to discuss with you. For today, thank you very much for your time. Our guest was Michał Mąkosza, Scrum Product Owner in EXATEL’s SDN project. Thank you Michał.
Michał: Thanks.
