Skip to main content

The Journey of a Product Owner at Shell - Self-Management, Stakeholder Management, Incremental Delivery in a Complex Enterprise Environment

December 14, 2023

In this episode of the Scrum.org Community podcast, host Dave West is joined by Olga Rownanyk, a Product Owner at Shell and John Coleman, a Professional Scrum Trainer. Olga shares insights into agility and culture at a large scale organization, talks about her Product Ownership journey at Shell involving internal systems, processes, and customer insights and shares some helpful tips for Product Owners based on her deep experience.

 

Transcript:

Dave West  0:20  
Hello, and welcome to the Scrum.org community podcast. I'm your host, Dave West CEO here@scrum.org. And today, I'm actually really excited about this podcast because we're, we're talking to a couple of people that have really been heavily involved in using Scrum and Agile in an interesting context where we're fortunate to have two people on today's podcast, we've got Olga Rownanyk, who's the customer operations, enterprise lead from Shell, everyone knows Shell, obviously, they probably go there frequently to put gasoline or petrol in your in the car. And we have John Coleman PST from the UK who worked with Olga on a really interesting engagement. Welcome to the to the podcast, Olga. And, John.

Olga Rownanyk  1:12  
Thanks very much for inviting invitation.

Dave West  1:16  
Now, before we dig into the content, which is we've got a lot to cover in 1520 minutes says, our listeners love to hear a little bit about you and where you're talking to us from Olga, maybe you can start where are you? Where you calling us from today?

Olga Rownanyk  1:33  
Well, actually, I'm calling you today from Krakow, which is based in Poland. And they've got the lovely and very sunny autumn afternoon here. So you're more than welcome to join me in Krakow anytime soon.

Dave West  1:44  
It's a it's a great city for our listeners that it is we have a number of trainers in that area. So I've been fortunate to be there. And it is, it is absolutely what you'd expect medieval but modern and really interesting. So thank you for taking the time on this autumn afternoon. And John, you're somewhere a lot less exciting than Krakow, right?

John Coleman  2:04  
Indeed, in the English countryside, about half an hour drive from Oxford. So that's not so bad about Northside, London. Thank you very much for having me today.

Dave West  2:12  
I know awesome where the where the Thames begins, right. And it's not even called the Thames. So great. Well, thank you. All right. So, Olga, let's start with you. Because I'd love to get some context for this story. You've had a pretty interesting and dare I say varied career at Shell shells, obviously a huge company. Tell us about your journey to your current position. And, you know, some of the some of the key moments over this over this journey.

Olga Rownanyk  2:44  
Sure, I'm happy to. So before shell just you know, I was studying different things and studying languages. And I also study to be a fashion designer, which doesn't work out. I joined Shell 15 years ago. And the majority of it was in various customer operations, roles supporting different businesses. And I started that show with picking up phones from Austrian customers, then I changed my role to being a team leader in various teams as well. Then I moved on to the operations manager when I managed the community of 70 plus people. And in the last years, I had a couple of project roles that were individual contributor, more type of roles, but I was focused kind of a more holistic, project type of activities.

Dave West  3:32  
sounds really interesting. And it's interesting, you say, your education wasn't software development and process and all this. It was very varied. And, and I actually think that, I mean, I think that makes it even more interesting the journey you've gone through, because you've got a very different perspective than people like me and me and John, so we'll definitely be pulling on that later. And John, you know, you know, where did you just quickly for our audience, where did you sort of get to this position? What was your journey?

Olga Rownanyk  4:08  
I was originally a project manager as well, like, actually spent a bit of time in shell as well had three engagements in Shell but I was originally a traditional project manager. And towards the end end of my project management days, I felt the plans were controlling me more than me kind of managing the plans and I became probably one of the worst project managers in the world. When changes came in, I'd say life changes, business changes, bring it in, it's fine, I'll figure out a way to swap something else out or another change request to get some more scope or whatever. But it was, it was when a general manager of a factory in Ireland came to me one day saying John, I need you to increase the capacity of the factory by 40 percentage of four months and no floor space. It was kind of like I knew I was in trouble them because really small changes, because it was a continuous improvement projects and so on. Small changes, were taking nine months, I had to change the whole factory in four months. So I kind of was in big trouble. So actually went across the London train by Ken and went back to Ireland and upset everybody with Scrum for a while. So I got started with Scrum.

Dave West  5:14  
I know that that story is something that can still mention occasionally that he met you. And you then went back and destroyed a factory. I mean, no made a factory incredibly successful. Alright, so let's talk about shell. And, and you know what, what you actually did. Olga, tell us a little bit about the problem space that you introduced Scrum and Agile into?

Olga Rownanyk  5:39  
Yes, well, we went through that everyone knows shell from its gas station, right? Yeah, just pull over you just like gas, pay for it and drive off happily? Well, it there is much more than this. This is a very complicated and highly complex environment. It has loads of moving pieces. And it also covers a lot of different lines of business. So there is also lubricants. There's also a variation, there was also Marines, there is chemicals, you name it. So basically, we get almost everything. So it's not only shell site. And if you have so many businesses, you can imagine that we are also very used to work in various styluses. And that is not the best environment. If you decide you would like to get the holistic kind of integrated look from the customer. If you add to this complex customer Keyaki, where you have data available for three and a half 1000 unique accounts, 400 plus corporate, and 240 plus strategic accounts across multiple product lines, and geographies. And all of this is scattered around 14 different systems. So if you try to pull this together, you can imagine it's not the easiest task.

Dave West  6:53  
No, it sounds incredibly complicated. So and that really is the the complexity that you you and John worked on and solved in key accounts, you know that that was that was the that was the challenge. Tell me a little bit more about sort of key accounts and what you were trying to fix with Agile and Scrum?

Olga Rownanyk  7:16  
Well, actually, I'll recall this part of the customers that we've been working with are the enterprise and the sectoral account. So to level up, it's a creme de la creme of the shell customers, you can call themselves. And at this level, we prefer to call them as the business partners than the customers because that's what they really are. And we are no longer offering them simply products. So we are not just selling them something we are rather cooperating with them on projects, and making some tailored solutions to the very specific needs. And sometimes when they were starting conversations with them, we don't really know what will be the answer for the problem statement. And we identify the John during our short time projects, while the expectations always is that we understand their business. And there's ways of working in a sense of a value chain, and not just a simple product need. And with this knowledge and also based on our experience as a company, we can propose options to improve the business and their customers experience because we are talking about the companies that have their own customers. And, of course, what they expect from us that we will do all of this, being able to accommodate to them and not the other way around. And I'm not saying this we always do at work like this that we do whatever the customers ask us to do, but at least we need to keep this in mind. And we need to kind of give them something that will keep them satisfied. My role is focused on customer operations, Spark making sure that we are all able to look kind of holistically across lines of business with different ERPs inside, and those ERPs do not talk to each other. That makes a little bit more difficult. And that our enterprise themes also have access to the insights, that we have our systems, which makes them much more equipped for the further conversations with the customer. So

Dave West  9:11  
let me see if I get this. I mean, it's really interesting use of of Scrum and Agile because ultimately, your customer has I'm going to use some Agile and Scrum terms, right? A clear product goal or goal, right. And then you then incrementally deliver value against that goal, both proving that you understand that goal, you know, assumptions. And when they said tomato, you said tomato, you know those things get very clearly ironed out. And then obviously, incrementally delivering value requires you to work with multiple different ERPs and different teams and different lines of business to deliver this value to this really probably very big and very bureaucratic and quite complex company that you're providing services for. Is that really the essence of the of the situation? Yes.

Olga Rownanyk  10:04  
I think it's a very nice summary.

Dave West  10:07  
Gosh, I did sort of pay attention. So John, talk to me a little bit about your perspective. You know, you've this isn't a classical use of Agile and Scrum, right? I mean, it's a great use of it. But it doesn't seem very classical.

John Coleman  10:21  
Indeed, it was one of my first challenges with companies like Shell where often we went to other companies and things can only get better. And we use Scrum and things are, you know, to get better. But companies like Shell that the project managers, there's a discipline, whole discipline around project management in general. And in companies like that, they tend to be very good already doing what they're doing. And so one of the things that you need to be to up your game on as a change agent is expectations management about what might happen once we start doing the change. How are we going to manage expectations about dates, and maybe event later about uncertainty, but a really important thing that would be concerning companies like Shell would be? How do we demonstrate compliance at pace? So how do we stop people being overly concerned about information security, real estate, privacy, data, protection, finance, all these regulatory legal concerns, these are all things that need to be kept safe, basically, we need to make sure there are control rooms and companies like Shell. And we need to demonstrate compliance on a regular basis on a month by month sprint by sprint basis. And so figuring out how to do that can be a real challenge in companies like Sha.

Dave West  11:36  
So what you're sort of highlighting is that there's a lot of stakeholders that are not just the customer has a probably every sprint actually a clear product a goal. And then but unfortunately, or fortunately to do this requires lots of stakeholders to be aligned to be transparent with and to work through that. That's really interesting. So obviously, you, Olga, you were working before Scrum and Agile in this way. So what were the some of the challenges that this super complex environment demonstrated, you know, what did Scrum and Agile help you to do or to solve?

Olga Rownanyk  12:19  
I look, I can give you a straightforward answer as a Scrum and Agile is used in shell for for a really long time already. And as part for this problem, for this particular problem, that was already a product that we already had the product that tried to address this. And the problem was that when it was created, no one actually looked if it's serving its purpose, or is it? Can we actually develop big enough to help us at the later stage? And the answer was obviously not. We understood that we need a bigger and more strategic solution. And something that we can incorporate much more businesses at the later stage. And this is what I was working with. As a product owner, I kind of tried to patch something that we already has have some quick fixes to the strategic solution. And the just enough for us to survive until the tactical version will be ready. Also, what I've noticed is that the because historically, we are used to more traditional ways of working like kind of managing a project with a solution in mind. It's also very, very, very tempting to change back to how you do the ways how you how you used to do and how you used to deliver the projects. And before you notice you're stuck where I was, that was a very odd hybrid of the agile and the traditional project management. And you also need to remember that even if I was doing some Scrum, the whole organization was not so I was kind of forced also to be in this nice hybrid. And that they also think that come before the Agile becomes national, it is really important to pause every now and then and kind of take a take a sip of your tea and just check if what we do is really Agile and Scrum and have we unconsciously kind of moved to something something very different.

Dave West  14:18  
That's interesting. John, what do you know what what was your take on this this journey?

John Coleman  14:25  
Yeah, what I really noticed with Olga is the way she went right back to the essence of agility really, about a group of people with various skills, getting together to try and solve complex problems. And sometimes people forget about the essence, solving complex problems being empirical, working together trying to trust each other. Following the scrum values, things like that are the values that are similar, that help you to be in the spirit of agility. And I really observed At with agar that, and also the way for example, while I've seen another companies as well, where you have to manage the expectations of many, many stakeholders, I noticed that there were some taking styles and behavior styles that Olga was applying. That gave me goosebumps, because you know, these were things that I had managed to do recently, you know, the companies before and I was already doing some of these things. And so I was quite inspired by by her level of agility. And when I come across people who are really living and breathing it, and sometimes they bite and know everything that's in the scrum guide, but it's just so natural to them, that it comes across in the way they're delivering. And if only we had more practitioners like that, who, who really understand the, you know, once thought about,

Dave West  15:52  
I think that particularly algos, you talked about this sort of complex environment in terms of the problem you were solving, but also the necessary complexity of working in a large organization. And they're not all doing Scrum and Agile. They're not all, you know, thinking in that way. But being able to focus on Hey, incremental progress, hey, cross functional team, hey, trust, support, transparency, those principles, as you rightly said, John are the essence of Scrum, we obviously put it in a nice little framework. But the essence and I think that that is, it's often challenging to do that. So it's really exciting to hear that. So how did you go about sort of this implementation, though? How did you, you know, what any obstacles, you know, working incrementally, which is a fundamental in a complex environment, sometimes it's really hard to implement, because you've got this, as you said, solution in mind, because that's how you've always done it. And everybody wants to work to that. And they actually don't want to see if you can if progress can be made in a small chunk first. So tell me a little bit about the obstacles and, and where we, how we went about the change, of

Olga Rownanyk  17:13  
course. So as mentioned, the idea of Scrum is not new to shall, what will give you a little bit of flavor how it looks in the corporations and the big companies like this is I was informed on one of the very formal meetings where we had a weekly catch ups, I was simply informed that from now on, I'm a product owner. And at the same time, I was participating in those in those meetings, because I was the main stakeholder and the recipient of the dashboard. So I kind of fluently transitioned from one role to another. And I had some general training about Scrum kind of I knew what the mythology is about. And I knew what roles I had what was where they, I did a very basic research what the product owner should do. So thank you very much YouTube channels. And there, I was in the middle of the libre huge project with around 20 developers from Master and project manager on top of everything. But I kind of used my vast experience as a manager and the project lead. But I was trying to keep in mind what Scrum and Agile is about. And I was trying to kind of use my common sense to make it work. I was what I what I was trying to do is kind of listen and react to what he needs. I spent a really long time talking with every single one of them, and it was them in groups. And I was asking a lot of questions. And I made sure that we are all on the same page, that we all are talking about the same things and our understanding is exactly the same. And looking at it. From the 18 months perspective, I know what I could do differently and potentially better. But also at the same time, I know what I was that I was really, really lucky that the team that I worked with was experienced and truly self managed team. All the people there are knowledgeable, driven and very curious, which is, in an essence, the recipe for excessive success, it can't go wrong. We were working hand in hand with the project manager to remove kind of all the obstacles from both the project and the organization perspective. And we made sure that people have all the necessary tools and skills to perform other best. So if there is a from heaven that John mentioned sometimes in his jokes, we would be very close with this team.

Dave West  19:40  
i Yes, I would like to be there to the it's really interesting. Firstly, product owner is the hardest job I just just want to get it out there. So congratulations for surviving being a product however, it isn't the easiest of jobs. You're sort of like everyone already, everybody doesn't like you in a way the team because you keep bringing work the stakeholders because you're not doing exactly what they want the customer because it's so it's a really challenging role. So I applaud you for, you know, for surviving and being successful in that. So John, you know, as this as this sort of manifested, you know, we talked a little bit about self management, we talked a little about increments, anything you would like to add to that?

John Coleman  20:28  
Yeah, so one of the things as well, that I noticed in companies like Shell Olga reminded me of essentially when I was working with her was that there are different types of product owner, you've got to ascribe like a, like a bad waiter in a restaurant who just take your order, even if you're ordering the wrong food, you know, and you might have a proxy, someone who should be someone else should be doing it. But they think that the product owner rights product backlog items all day, so they don't want to do that and misunderstand the product owner accountability, and then there's a business representative, which is, where a lot of people would be, and I'll get might be in that kind of situation where you have influence. You don't have the full mandate, you don't have the bag of money. If you're like, you have you have a network of stakeholders that you can you can I'm sure you can engineer a way to get there. But that does require a lot of influence in skills. And that's what I observed. How do you? How do you deal with that, you know, not just all good. But lots of people out there who are what we call business representative by product owner, they don't they're not the sponsor on the bag of money, or they don't, they're not they don't have the full mandate from the organization like someone like Elon Musk would have, for example, as an entrepreneur, whatever you think about him, he would be really high end product owner. And so having those skills where you can buy a mandate for a few weeks at a time. And I've seen this in a few companies, not just showing other places as well, where if you don't actually have that full Monday, what you do is you go to your stakeholders. And I used to call it the Speak now or forever keeper silence meeting with the speaker for the next four weeks. You go to this, maybe review board a steering committee where this kind of like unanimous decision making almost and instead of asking for permission, you tell them what you're going to do. And then let them have an argument with you and that session about what you should do. And then just ask, you know, if you want to change your mind, can you just hold off for four weeks? Because we need to refine this? What have you what have we agree on and then they'll go into a sprint. And as soon as you undermine what the priorities are the people doing the work or the developers, they won't believe me anymore, and they're not helping you and you're not helping yourself. So how about do we do this and Latinas, that's what I'll get was doing. But that's what I've seen a lot of companies like Shell where if you are a business represent, that can be a very useful trick. Even if you don't have a mandate, if you don't have the bag of money, you're just buying enough and every two weeks to go back and get another rolling four week mandate. And it kind of gives you the just enough mandate, keep it going. And I did pick up from Olga that she's got a few tricks in her toolbox as well, that are a bit different, but similar. And I was quite impressed by how she did that.

Dave West  23:04  
Managing stakeholders, managing expectations, managing all of those stakeholders is an incredibly hard job. And I think all those years of experience in the different roles that shell probably gave you a really good set of skills that you could or tools, as you said, John, in your toolbox to do that, Olga. So impressed. Okay, what's next? We're coming to the end of of our time together, unfortunately. But what's next from your perspective? I know, you know what's happening going to happen next shell in your area. With the use of Scrum and Agile?

Olga Rownanyk  23:45  
I think it's a it's a really good question. And I think it's extremely difficult to move organization like Shell to be fully agile, for various reasons. It is first the size and the complexity of the organization, number of people that we're talking about, also the experiences that they have, and sometimes the needs of the of the business simply. But I think the the most important is what we are used to because we tend to stick what we know and what worked for years, and still has years and years of experience of something that worked. So why would we abruptly change it right? That might be also a very unpopular view. But I think that for certain types of projects or activities, or Well, the good old waterfall project management is a better fit. I think we just need to be very reasonable with why we are trying to implement and which circumstances we're trying to implement something. But I also firmly believe that Agile has a lot to offer. So even if you don't utilize 100%, you can always use this kind of approach. And as you mentioned, have this in your toolkit to ready to be used just take it out use it and just put it back on the shelf if you don't use it. And you can use those bits and pieces to accommodate your day to day at work. and that they how, how you how you generally work. And maybe I'm just saying this because during my pspo training, I kind of understood that I am another leader, even even if I haven't realized yet, that my habits and the ways of working are very similar to the Agile leadership, and I use it naturally and very instinctively. And there are multiple feedbacks that I that I got, let me believe that I am a good leader. Yeah,

Dave West  25:26  
I think that this sort of the essence of Scrum is hard to teach or the essence of Agile is hard to teach. But some people have kind of got it. You know, they're good working with stakeholders, they're good breaking down problems into progress, suitable chunks, they're good at encouraging a direction that everybody rallies behind. And, and I think that's what we heard at from your perspective, shell, and then the future continually adding those those, those skills to you and challenging yourself. I also said, I loved algo, what you said about sitting down with a cup of tea once in a while, obviously, I love tea, being English, and stepping back and going, hey, could Am I approaching this right? Is this the right way? Maybe I should be looking at this a little differently. And I think that's great. And having somebody like John can really help. All right. So we've got lots of people listening today, maybe some of them are working in similar situations, maybe even in Shell, because it's such a huge organization. Right. So you might get some internal emails, hopefully, on this. But if you're in a similar position, and you know, before this began, what would you tell that? The the you that's like, in the past, as it were, you know, if they're in that position, what would you tell them? What was the first or the most important thing they should concentrate on?

Olga Rownanyk  26:56  
So I would start with simple, please don't panic. And I'm sure there are plenty people in your organization that are willing to support you and help you at the beginning of your journey. So don't be afraid, simply just to ask for guidance. There are a couple of ground rules that I usually set up for myself, and maybe they will be helpful for you guys as well. The ones that helped me is, first and foremost, ask questions, and be genuinely curious people can feel if you are genuine, and you can feel you're curious. And also explain why you ask. Don't be impatient, both with your speaker and with yourself. And give yourself time. If you don't know something that's perfectly fine, just admitted, but do not treat this as an excuse. Let people know what you plan to do with this information. And also, so they will know what they can expect from you. And also by when that helps in the further conversation. And that also helps to build trust. What personally is really super important, if there isn't a decision to be made, just make the decision. Don't bow by making decisions. Make it as clear as possible, why you decided like this as well, that also helps. And please remember that you made the best possible decision at the time with the variable set of information based on your experience. And yes, it may turn out with the time that it was not the best one. Well, it happened to all of us. So go back review. Another just Well, I would say simple as that. But always own your decisions. And something that I always keep in the back of my mind, I cannot read people's minds, so don't expect them to have the same ability. And as a leader, when I start to build any relationship, either with a team or stakeholder or project team, I say very openly, guys, I have a lot of skills. I can't read your mind. That's not one of the skills that I have. That might sound a little bit odd. But I'm also saying that until you tell me something, I will not know it. Well, I can assume I can think I know I can guess. But if there is anything that you would like me to do, you need to say it out loud. And I think that's it.

Dave West  29:11  
Wow, that is a checklist for being a product owner really isn't that. Remember to be curious. As always explain why. Be transparent. Don't get impatient. Give yourself time. Admit you don't know some things. So be vulnerable when necessary. Because that builds trust as well as actually gets the answers that you're interested in. Make sure you you know, make decisions, but make them transparent. And this is why you made that because I think that's really important. Don't stall in that process and make the information available so that everybody you know, knows why you're making this decision and highlight the fact that you don't read minds even though Everybody would love that if you you could, because that's how often organizations work. Right? You didn't know that. Well, how would I know that? What we just thought you would? I love I love that expression. That's awesome. I'll go awesome. John, what have you got? What's your sort of like, if you're in Olga's position five years ago, three years ago, what would you give advice?

John Coleman  30:22  
I love what Olga said. But I would also say, maybe have a look at the Kanban go for Scrum teams. Because if you don't scrum really well, you can add rocket fuel to metaphorically by adding Kanban make it go much faster. And if you want to make sure the rockets kind of pointing in the right direction, maybe think about doing the new accelerate, as well as a lovely scrum with UX classes from that org as well where you can look at those ideas in your product backlog. And maybe you were not confident we can harvest the value of a lot of them. And so we can save a lot of money by not even putting them into the system in the first place, we can find out through cheap experiments, which ideas are really worth pursuing. And then around the quality switch, it's wrapped with Scrum and deliver a really high quality, highly valuable product. So that'd be the right to tip stuff.

Dave West  31:11  
Awesome tips. I I love that I obviously, when I met Jeff and Josh, the authors of Lean UX, and the help and the authors of the class that you mentioned, they kind of blew my mind and made me go back and instantly change my backlog, which I still sometimes get job done, because it was such a major change of my view of the world about what value really is and how do you get there faster, which is, which is really cool. So thank you, Olga. John, thank you for spending the time on this autumn day, from from Poland and from from England and myself speaking to you from Boston, Massachusetts, in the United States. Thank you for taking the time. I think our listeners definitely will get a lot out of this. And I certainly did it. It actually, interestingly, Olga made me I made me sort of like smile again. And there's so many times I reach organizations that are the size of Shaolin. And it's just this list of impossibilities and fair enough to have an incredibly successful organizations and I get it the the they've evolved these systems and processes over time, but, but at the end of the day, I think the art of the possible, you've made me realize that you can do stuff and it just requires a little bit of leadership, and a little bit of agility and and good good things happen. So thank you for making me smile. I really do appreciate it. Okay, so that was it. Today we heard Olga and John talking about their journey at Shell working with the these key accounts a highly complex environment. You heard about how, you know, stakeholders you heard, really, the essence of Scrum is so important and how you can incrementally get a mandate for change if you're if you're smart about it. So thanks for listening. Thanks for spending the time out of your day. Hopefully you'll join me for other podcasts and Scrum on

 

 


What did you think about this content?