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. 2
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. SDN, i.e. Software-Defined Networking, is the Holy Grail of 21st century telecommunications. The SDN philosophy that took shape around the year 2010, today is conquering the telecommunications technology worldwide and creating a new market estimated to be worth as much as $43 billion in 2027. In practice SDN means a telecommunications revolution. Thanks to the SDN philosophy, companies like EXATEL that write their own software and develop their own technologies, can create flexible solutions at the highest global level. 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. Sylwia Buźniak, EXATEL HR Business Partner.
Sylwia: Hello. Our guest today is Michał Mąkosza, Scrum Product Owner in the Software-Defined Networking development team. Hi Michał!
Michał: Hello.
Sylwia: I’m glad that you agreed to come here. Today I’d like to continue the conversation from the previous podcast, but this time go down to a greater level of detail and get to know your work from behind the scenes. Not just focus on the theory, but talk about what your role looks like in practice.
Michał: Thanks for the invitation. I had a good time previously, so I was happy to come back. This is an interesting experience for me. I’m happy to tell the story. I even prepared some material on what this means in practice.
Sylwia: Who is a Scrum Product Owner?
Michał: Scrum Product Owner – as a reminder – acts as a bridge between the developers and the business. That is, on the one hand, I need to know what the business value is and what the company wants us to accomplish. Then I’m the voice of the production team for the rest of the organisation. On the other hand, for the production team, I am supposed to be the voice of the organization, convey information and talk to both sides in such a way that they understand me. Which is quite peculiar, because the language is different for business and the developers.
Sylwia: Exactly. You are a link between business and technology, to put it simply. That is, you translate business language into one that developers will understand. In that case, please tell us how it looks from the top, strategically. What are the arrangements at the business level that you then have to convert and translate into the language of the production team?
Michał: In the previous podcast, I talked about how it’s more on the side of talking to the developers. Now I will try to talk about how this cooperation looks like from the business side, i.e. where the materials I present to developers come from. And as I was thinking about what to say here, this idea came to me: to talk about the operator’s portal. It’s one of the components of our SDN ecosystem, and we’ve come quite far with it. I have a story that, in my opinion, shows the project quite nicely from the moment of coming up with an idea to its implementation. Where in particular does the business will come from? Maybe I’ll start this story with a small digression.
Sylwia: Go on.
Michał: When I came to EXATEL, the first very positive surprise was that EXATEL decided to create such an internal software house. A great move. I liked it a lot.
Sylwia: So did I, that’s why I’m here.
Michał: However, in addition to that, I had experience as a Scrum Product Owner, so automatically in the back of my mind I knew that it would look the same – Scrum here, Scrum there. The second surprise, more ambivalent, was something I had to adapt to. It was that the project of production of the entire ecosystem, the device, the operating system, the controller and the SDN-operator portal – which I’ll talk more about soon – is a different time scale than I was used to, though. I just happened to have some experience developing Android and iOS apps, and there Scrum rotated really very quickly. Every two weeks we delivered some increment that the business could understand and see. Here, for me, that first shock – what I had to adjust to and find out how to work with businesses and the developers – was that the time scale is totally different. It’s a bit like building a model car. It’s like you could build a whole model car in two weeks, you present it and hear ‘great, only we want this car to be green now, not red.’ So in the next two weeks you repaint it. Here, it’s as if we were building a whole 1:1 car. We can build one handle in two weeks, show it to the business, and the business says: ‘great, I want to see the whole thing before I evaluate anything.’ So that was that first shock – the time scale. This story begins in 2020. The project was already quite advanced, and I mean the whole ecosystem at the research level. As I mentioned – we are doing Research and Development here. Looking holistically, strategically, from the Scrum Product Owner’s point of view, we were more at the stage where we were looking for how to do something, rather than actually doing it. So we had advanced work in various components, in varying degrees. I came to the conclusion that it’s high time we produce something. Even if it wasn’t going to be a product in the commercial sense which we wouldn’t put on the shelf to sell outside the company, but something solid, not some PoC that would be put in some lab to prove a concept. It was supposed to be something solid, already working. We were then able to execute the so-called MVP-0. In scrum development, the MVP-0 talks about the scale of the amount of sprints, so here we said MVP-0 would take us a year or something. To do so, we also had to prepare for it. Prepare preliminary materials, analyze, hold discussions with the rest of the organization, so we got a time window for the developers. When we said ‘attention, now we’re going to go for MVP-0’, it wasn’t ‘come on, now, start!’, it was ‘we still have to prepare something for you, so you have a while’. An opportunity came up: maybe this bit of time could be spent on such a component that we had planned for the vague future which would be very useful in this MVP-0, not absolutely necessary, but very useful. And that was the operator’s portal.
Sylwia: How to understand the operator’s portal? What was it supposed to be and for whom?
Michał: We’re creating our device and the entire ecosystem of telecommunications devices in the SDN philosophy, that is, under software control of the controller. We’re building it on ONOS, but we’ve decided that we want the network operator to have one graphic interface (GUI) one for the entire SDN. This graphical interface, that’s the operator’s portal. So we could say that in this Stack we have, the lowest level there is obviously some silicon contained in the device, the device has its firmware, above the firmware is the operating system of that device (that seals the device), but above that operating system is the central SDN controller (on the central server), and on the way to the user (the man who operates that network), there is also just this operator’s portal.
Sylwia: So it’s not user level yet, but an in-between, right?
Michał: It’s the closest to the user. The user operates on the operator’s portal.
Sylwia: And what do they see there?
Michał: First of all, a network. Secondly, they can read the parameters of what is happening on the network and what is happening on the devices. They can set up services there and, of course, check what the parameters of those services are. Also such mundane things as being able to log in, check the log of the previous operations, or set up accounts for other users.
Sylwia: Sounds great. You mentioned that this was the smallest module you could develop, because a slot in the product life cycle appeared and the production team just happened to have the capacity. How long did it take? How long was it spread out over? How many tasks were written?
Michał: This is exactly what I’d like to present – what it means to work on this component, which is not necessarily the smallest. On the other hand, what did I mean that a time slot appeared? We knew what we wanted to do on the SDN ecosystem side, we needed functionality – it’s the meat that’s supposed to work there – the most important thing is to flip traffic, control these devices, etc. However, before the developers would implement these elements, we needed a chunk of time to prepare AnArch’s operations (i.e., analysts and architects), this main part of the functionality. Then the question arose: what to do with developers’ over time? And it’s not that we pasted the entire operator’s portal at that time – that’s the beautiful story I want to tell – it’s just that at this point we realised: we have two Sprints. So far, dear developers, we have not talked about the operator’s portal. We don’t have any AnArch roster ready to go, but this is a great time for you to conduct a PoC (*Proof of Concept). Two Sprints in four weeks and your goal is to ‘achieve the wow effect’. Whatever is the closest you can get to it. So that was quite a specific first epic – of the series of epics needed to produce this component which is the operator’s portal – the goal was not a specific functionality, but we had a Timebox, meaning: in four weeks do what you can. In addition, we also ‘borrowed’ from another R&D (Research and Development) project at EXATEL a person who already had experience with Front-end, because most of our developers deal with this ‘meat’, flipping traffic, telecommunications, networking, etc. So it’s not the same specialization as for someone who knows how to create a graphical user interface.
Sylwia: And also to make the UX work, right?
Michał: This is also an interesting issue. Of course, yes, so that the UX also worked. What we needed here – forget about polishing on the UX and UI side – was someone who would have been able to write it. Colloquially speaking, we borrowed a colleague from another team to work with us for these four weeks. What my colleagues created over those weeks with such input parameters given was truly astounding. And it showed that we are very much capable to put this operator’s portal in MVP-0.
Sylwia: I think you approached it a bit from the other side, since there was no analysis done in the analytical-architectural team. So the architect didn’t do the whole architecture of the solution, but you started from the bottom and the team had to check what they were able to do at a given time?
Michał: Even more. They weren’t supposed to tell what they would be able to do, but to actually do it. It is unusual with this classical approach, but we take advantage of the fact that we work in Scrum and it is ideally suited for exactly the kind of issue we encountered here.
Sylwia: Well, out of curiosity, tell me how the team reacted. Because it was uncommon. Usually they get tasks decomposed by architects into smaller ones, undertake and assess them themselves, and here they were given the task of ‘come up with something and propose a solution’.
Michał: In all, as I mentioned it was 2020, early 2021, when we actually took on this PoC of the operator’s portal. From what I remember of that time, the response from the team was very positive. Of course, some people prefer to have a free rein, while others prefer to be clearly told, from A to Z, what is to be done. So it’s not that everyone has shown tremendous enthusiasm. But in general, the team liked it a lot for two reasons. First of all, this is Scrum in its pure form, which is generally a more pleasant way to work. Secondly, the criterion for success was to be able to learn something new. With most people, especially as you know yourself, when we recruit someone, one of the things we pay attention to, is whether the person has an open mind and is willing to learn something new. If that person is driven by that. Because, in R&D it is impossible to avoid learning new things.
Sylwia: Here flexibility is extremely important.
Michał: Exactly. It’s not just producing the same thing over and over again, doing what we already know how to do, it’s just learning new things. So the response has been very positive in this regard, at least that’s what I remember. From the business side, it was a great success, because first of all, we showed that this is something we can even put in MVP-0 already. Something that was not, at the absolute minimum, at the such a stage of product maturity, but was a solution to few elements that we would have had to do otherwise. Secondly, it showed us that we know how to work this way. The end result of this two-sprint epic was that some of the stuff was on strings, some of the functionality worked on the basis of ‘here’s a button’ that will do it someday, but it showed that we were able to do it, and in the process, colleagues gained that knowledge, skill, and experience in doing this graphical interface. So from there, we started to implement it into the standard workflow, which means it was given to the AnArch. Look, here we have this Proof of Concept and now that we know we want it to be a part of MVP-0, turn it into requirements, epics, and stories that we will then produce normally. And another epic was created , the so-called Portal_v1, which was analyzed in AnArch, prepared into what we need on MVP-0, and ten user stories were created. A lot and not much, depending on what scale you operate on. In our case, these are quite large stories and this time scale on which we work is really quite large. Very often one sprint equals to single user story. I don’t remember exactly how long this epic was once it went into development, but it was about six sprints. The developers team decomposed it into 135 tasks. Now, I’m supporting myself with the statistics I wrote down earlier. It’s not like I can list how many tasks all the epics had during that year.
Sylwia: Refer at least to whether it is a lot or a little?
Michał: Ok, so one task is something (statistically speaking, because they obviously vary) that one developer has to work on for a couple of days.
Sylwia: I understand.
Michał: So we’re talking about between 100 and 300 person-days here, and this is roughly judged to show the scale.
Sylwia: But it gives a reference point.
Michał: So based on that PoC, where we did the tunneling of that ONOS (controller), we kind of pulled it out to the visual layer, we wrapped it into our application that the user would use, and based on that PoC we said: ‘okay, now we know how to do it – let’s realize the requirements of the business and the end users at this absolute minimum.’ It was done by the team in this v1, these 135 tasks. Then, we reached some stage with this particular component and the team took on another one, another epic was prepared by AnArch and we started testing what was there. It turned out that a few things worked nicely, but a few things still needed to be added. On the other side, while watching the business said: ‘we forgot, or it has only now occurred to us that something like this is needed’. Or the best one: ‘you inspired us to do this, it would be cool if you made it for us’. That’s the best thing, hearing something like this from the business. It’s not like they’re telling us this, and in two weeks they’re looking at it. This means that we now have to prepare it, analyse how it affects the architecture and how it connects to other components.
Sylwia: So, from how I understand it, that goes into the backlog managed by…
Michał: The backlog is managed by me.
Sylwia: Exactly. So it went into the backlog, and I understand that you are already engaged in dissecting the schedule and calculating the requirements from the business, or prepared by analysts, yes?
Michał: Yes. In case of my daily work, yes. But in this particular story, the sequence of events I’m talking about, we were at the stage of closing the epic. That is, the team has produced something and we are now taking a look at the product. So it’s again the AnArch’s task to look at what has been produced. We already knew, based at least on what I said, that some additional information had started to flow from the business, that we would have to do one more epic, a polishing one, before delivering the MVP-0. We had the first epic, a timebox – ‘let’s do what we can and learn’ – based on that we had this main one – ‘then let’s do it decently now’ – and based on what we did decently we ended up with – ‘we need to polish it’. And so the third epic was created, called Portal_EPL. We squeezed into the MVP-0 schedule, where we had a fixed release date, we committed to the rest of the organization as to when it would be available. So a next epic was created, and again the AnArch prepared a breakdown, this time into 8 user stories, the team broke it into 78 tasks so this epic was much more solid. When it comes to using it, polishing. It turned out that we had 75 more bugs, but the end result was that when we delivered MVP-0 – for this first launch to see if the whole concept worked – the portal was already an integral part of the solution.
Sylwia: Sounds really nice. What was the business’ final reaction? Did they have any other comments? What does the final acceptance usually look like on the business side?
Michał: I’m going to get away from the term ‘final acceptance’ because as I said, building this whole ecosystem is a very broad topic. Really broad.
Sylwia: A never-ending one?
Michał: Maybe not never, but I would definitely not call it a final acceptance, because I want to be consistent with what I said earlier, in 2021, when we presented MVP-0 to the business, and then I repeatedly told them – this is not the final product. This is our first approach to something final, tangible, and not just an element of something that will be sometime in the future. It already does something, but don’t expect it to do everything you need it to.
Sylwia: So, I understand that the approach is a bit like for project or task work – in order not to procrastinate, make up an end date, see how much can be done in that finite time, and that way we get away from such a perfectionism, because otherwise projects would be hard to finish, right?
Michał: Yes, especially in research and development (R&D) where there will always be something interesting to research and do. On the business side, I badly needed us to crystalize our plan, that is, to do something rather than focusing on the process of doing. Even if it won’t be perfect.
Sylwia: Then how do you explain this, as the first contact person for the business and for the developers, especially to this business, which has these perfectionist qualities, highly exalted. Satisfying them is difficult, so you have to explain it somehow, yes?
Michał: Well, yes. In certain areas, perfectionism is very welcome, and in network maintenance it is firmly viewed positively. After all, we want the network to be perfectly operational. So you’re right, talking to my colleagues from that part of the company is not the easiest task from my perspective.
Sylwia: So did I get it right?
Michał: Yes. And as I said – this is natural, because this is their role. Mine is to deliver something and gather answers as quickly as possible. This is the thing I emphasized the most: ‘Listen, this is not the final product. I understand that something’s wrong here, something doesn’t work there, but that’s why I’m showing this product, to hear all of this from you.’ And it worked out great, because we learned a lot. Today I’m focusing on the operator’s portal, but we already have two more epics based on what we’ve seen and that we know what to do with it in the future. We also heard opinions based on this first use. Not based on some demonstration, but these people have already made contact this component, this tool.
Sylwia: Now I know what you meant when you said that the final acceptance did not take place. Because it’s still being updated, polished and perfected, right?
Michał: Yes.
Sylwia: Now let’s move on to your role in the discussions with the production team. I know that this topic has already been partially discussed in a previous conversation with Piotr. However, I’d like to ask, how do you translate the language of the business to the production team, especially if they have high expectations and the team knows it’s not possible. Your role is to play a therapist, a psychologist, a person who translates the language of business so that the production team perceives it correctly.
Michał: Yes, absolutely. I call myself a bridge between these two worlds. That is, the one who can translate from one language to another. I enjoy the conversations quite a lot. I really enjoy talking to the developers. Here, the main issue I mentioned earlier was to explain to the business: ‘this is not the final product. But tell me what more to do, which way to go, so that I have the material for where those lowest-hanging fruits we want to harvest from this tree of SDN promises lie.’ Yes from the point of view of talking to the team, the main focus is on what is realistic to deliver. I present them with a whole, very long list with selected things that we have agreed are to be done for now business-wise. And what I need to get from them is, first of all, the understanding. That is, they confirm ‘yes, we technically understand what is going on’. Second: ‘it will take us eight sprints.’ This is the main thing that I do in my conversation with them. As a Scrum Product Owner, I still have that second part, asking them about how the work is, what tools I can provide to make their work easier. But that’s a separate topic.
Sylwia: Definitely. And one more question in this case, because we kind of separate the production (developers) team from the AnArch team, i.e. the analytical and architectural team. Who do you talk to first? Is it somehow fixed? What do these conversations look like with the production team and the analytical and architectural team?
Michał: It’s not so binary. I talk to everyone, of course, just at different stages of what we do. And what’s most important to me is that I don’t go so deep that I’m able to dictate that in these two weeks you’re going to write lines of code that work in such and such a way. That’s why the AnArch team is there to tell it from the technical side. For me, the most important thing is for both AnArch and the production team to talk to each other, and for me to be able to provide them with information: ‘this is the business focus now, this is where we’re going.’ Of course, they ask why are we going for this and not that. Then we try talk it out as well. But the most important thing is getting AnArch and developers to be on the same page.
Sylwia: Do you pass the AnArch team’s information to the production team, or does AnArch talk to the production team directly?
Michał: It’s direct. It would be greately inefficient if I stood there in the middle. In fact, what I’m aiming for – an ideal state – is that I’m practically redundant in this conversation. I would just come in and say: ‘it’s now going to be about the operator’s portal’. That’s it. Of course, it’s unrealistic for this to happen, but this is the state I’m trying to achieve. I try to be helpful as much as possible, not someone rushing in with the whip and saying ‘do this or do that’.
Sylwia: Michał please tell us, what were the biggest challenges you’ve faced as a Scrum Product Owner? That is, at the intersection of business and technology. Challenges with both the business side and the technical side.
Michał: I have to think about this a bit. With the business side, the biggest challenge I have is to balance all these beautiful promises of what we can deliver in the future with what we deliver now. That it is a product that is not quite finished, incomplete. At the same time, I want this product to be already used. That’s one thing. The second thing is, among all these promises of the future, what the whole ecosystem will be able to deliver to us is really a lot. This is revolutionary from EXATEL’s point of view. Speaking of that perfection – you can keep doing, doing, doing, and I would like to have a piece of something already. So I have to choose which piece it will be, which on the one hand can be delivered fairly quickly, and on the other hand will have value. Aside from the fact that there is a challenge with pricing it, deciding which apple we want to pick from the tree first, the other challenge is in presenting this apple so that my customer (business) would not be discouraged: ‘But wait a minute! I was expecting a whole stack of apples and you give me one?’
Sylwia: And preferably even an apple pie.
Michał: Right? I understand that, and that’s why I say it’s a fine line I’m walking. On one hand, showing an incomplete product, and on the other, trying not to cause any discouragement, making this communication happen after all. And from the development team’s side, I think my biggest challenge is that it’s a big team and there are different people. For one person, it’s really cool, how they can take care of something that hasn’t been dictated to them, they have the option to go in different directions and that AnArch provides very precise documentation of what to do. Some may not want to have such documentation provided – they would like to prepare such a documentation themself. They want to join the process a step earlier. Another person, however, prefers to work with clear criteria for where to work from. And reconciling that, for the people have comfort at work – because this project has no chance to work out if people are demotivated, if they don’t have fun – I must admit this is a very big challenge for me.
Sylwia: So what you do is actually listening to the team and their needs, even individually. Because we’re not even talking about listening to the team as a group, but listening to individuals and their needs.
Michał: Yes, this is the biggest challenge that everyone is different. Everyone has different needs, and somewhere in the end you have to decide whether you go right or left. From the business side, it’s important for them to say where those PLNs lie, which way – left or right? At the same time, I have to throw in the information about how much time it will cost us, how much potential motivation. Maybe there is something very cool for the business, but hard for the team for some reason. Of course, the reasons may vary. I would say that this is the most difficult part of my job.
Sylwia: The issue of commitment, team stability in this day and age, and research and development, is a very broad topic, so maybe let’s leave it for another time. I’m familiar with this topic, working in the HR field, but maybe I’ll just invite you again to discuss that.
Michał: I would love to. Although it could look more like you talking to yourself, because you’re the one who knows best what the issues are.
Sylwia: You participate in these recruitments with me, so you know very well what it looks like. So, we will save this topic for a separate meeting. I would like to ask as well, so that our listeners also know, how to understand business? Who are the stakeholders in the project? You have already mentioned that they are network teams, but perhaps not only? How would you group or introduce this area? What SDN aspects are these?
Michał: Here, as an anecdote, let me tell you that every time we have such a meeting outside of our Software-Defined Networking team, we take a look at what I did by then. I’m comparing this handle that we built in two weeks and we’re trying to present how it fits into this door of ours. As I say, we have a production team here and the business here. I can imagine most of the people out there grinding their teeth and thinking: ‘how am I, a network engineer, a business? I’m technology!’ so you’re right. This word ‘business’, which I am using here, is very broad. Because on the one hand, we have our end users who will actually use it, the engineers. So they have a different perspective than the PLN. As I was talking about business, once I was talking about those engineers, our users, and the other time, when mentioning money, about the people who make decisions, watch the budget and set the strategies for the whole company. So business is really broadly covered here. I simply make such a demarcation line: the team that produces in SDN (our R&D) and the rest of the organization. And all the rest of the organization I call business.
Sylwia: Is the business supportive?
Michał: Yes, of course. In the sense that they are helping us with this project. Although, of course, in the beginning as you know we only have these first elements. Components of this handle. Then why are you bothering us here? The closer we get to the final product, the more interesting it is for them. But they are supportive, of course. The heavy sigh on my part is that, as I mentioned earlier – I also understand their position. They have a significantly different job than we do. Therefore, making this language, approach, consistent is a challenge itself. That is, yes: they show support as much as possible, but by support I also mean such things as critical remarks: ‘listen, here you went the wrong way, do it differently’. Listening to such a remark, it’s hard to call it support. But actually this is it. Without it, you can get lost.
Sylwia: Definitely. I agree that if the feedback is constructive, it is an added value.
Michał: Yes, absolutely. For me, it really is a great value.
Sylwia: Michał, we could talk and talk like this, because the topic for me is also very interesting. Despite being an HR person, I like technical issues. Nonetheless, I think that for today the topic we talked about, that is, the operator’s portal and some of your work from behind the scenes. As you said yourself: part of it, because it’s quite a wide range and we’ll save some for the next podcast. I would be happy to talk to you again. But as for today, thank you very much. I’m glad that you were here today.
Michał:
Thanks! My pleasure. I like to talk very much, so I hope to meet again in the future.
