Journey from Scrum Master to Program Portfolio Manager

Read the Full Transcript

The following transcript has been altered for readability.

Becky Flint: Welcome everyone. My name is Becky Flint, I am the founder and CEO of Dragonboat. And here with me, I’m very excited to introduce you to two of our guests, Susan Rainsbarger and Mauro Martins.

They will share their journeys from starting in various technical roles and scrum masters to becoming a portfolio program manager and a leader in this space that truly makes an impact on the business.

And before that, I just want to do a quick intro to my company, Dragonboat. We are a responsive portfolio platform that’s why we’re interested in program management. We are the sole leader in the responsive PPM space. And we have customers in more than 20 countries including both fortune 500 startups and global 1000.

So with that, we’ll pass it over to Susan Rainsbarger.

Susan Rainsbarger: Welcome, everybody. Susan Rainsparger. I have been with Ruan transportation now for about a year and a half. Prior to that, I worked for a financial company here in Des Moines, Iowa.

I started my actual agile career with another company. So I’ve been a scrum master for about six going on seven years. Shortly after joining with Ruan, they asked me to take on a more portfolio level for our IT department. It started more as an admin piece. But then I started asking quite a few questions. And it has kind of expanded upon that. I will pass it onto Mauro Martins.

Mauro Martins: My name is Mauro Martins, I’m from Portugal, and I started my career as a Delivery Manager. I was an engineer at heart, and I was basically a programmer. And I then started a Delivery Manager role for a betting company with Betfair. And back in the day the Delivery Manager role also took on the role of scrum master.

Fast forward a couple of years, I moved to C Drive, which was the last company I worked for. Eventually, I started a program manager/ portfolio management role.

Right now, I work in portfolio management for a company called Basecone. They are one of the leads on tax and accounting here in Europe, mainly the Netherlands.

Becky Flint: Great, now I want to turn to Susan. First off, when you become a Portfolio Manager versus a Scrum manager, what were your different focuses? What did you do differently?

Susan Rainsbarger: When I look at the differences between those two, from a scrum master aspect, I’m looking at the day-to-day, the two-week sprint, or from a Kanban aspect, the first-in, first-out priorities.

You think of things in the now, what are the roadblocks there? What can we do differently to make ourselves more efficient? Are we going to meet that two-week timeline?

But at the portfolio level, I’m now looking at the department. So more resource capacity.

We have always had a gut feel, we feel busy, we feel like we’re strapped for time. And the Strategic Initiatives started stacking on top of each other. And you could feel that the strain was happening.

You need to look at that piece and take a look at what our leadership says. How should we prioritize those buckets of work because we have some teams, buckets, and priorities in a different order.

Talking about resource capacity is the main thing that we were never able to do ahead before. So that’s one thing. Another thing is actually talking about those interdependencies between the teams, and what are the risks of the Strategic Initiatives? And how do we need to get those aligned? Lastly, just because a business partner says they want this strategic work done, doesn’t mean it’ll be easy. I usually take a look and say, “well, that’s nice, but something’s got to give”. Because if this is truly locked in, then we have to have that honest conversation about what’s going to change. That’s how it changed for me and when trying to manage the two different hats.

Mauro Martins: Yeah, it’s very similar to what Susan said. So what I noticed was that as a scrum master, you are either inside the team and get this as a sub role or you work with a scrum master of maybe two teams. You work on the day to day and your sphere of influence is small.

So what you can do, it’s always tied to day-to-day moments, is look at things your team can improve on. Start analyzing velocity, number of work-items that start committed versus delivered, and the different types of work that your team is doing, then challenge them. Then you do the same thing with the product, and you will be very valuable to the product owner. What you are doing here is you are helping the product owner understand where we are going? Where and how we are moving with this specific team.

As a scrum master, it’s valuable for you to talk about your challenges with other scrum masters. That’s because there’s always someone who has had the same problem and you can work together to find a solution.

I still remember my first job as a scrum master. I was blown away that instead of improving on the top 3 things, you start with 20-25. And the good thing is that as you start to talk with the scrum masters, they start doing the same. Eventually, you push the teams forward, you move them into different levels of maturity for instance. And it was great, I enjoy the day-to-day and seeing the teams get better every day.

This differs between program management and portfolio management because you only see the difference in 3-6 months, or 1 year. And we’ve always operated on a big scale and timeline, and the impact is not that straightforward. And so you end up having to focus on the long run.

Another thing is that you are not part of any team, and you’re not part of any department. You’re that person in the middle, that challenges everyone in the room and asks if we’re doing the correct thing? Are we doing the correct thing with the time that we have? Are we expanding or correctly expanding our resources? It’s not easy, because a lot has to happen in the company for you to ask this question. Do you have the objective, the annual objectives, or quarterly objectives in place? Because without them, you cannot go into a meeting and challenge anyone.

Becky Flint: One thing you also mentioned is that there are so many things you want to do. There are more things the company wants to do, more things your stakeholder wants to do, but too many limits. So how do you handle that in your row? That’s a big part of being a portfolio manager- how do you take all these inputs from a different area?

Susan Rainsbarger: For us, we have pulled together a new team, so to speak, where we’re trying to do a new process of having all of the requests funneled in one way. Because right now, it’s scattered, you’ve got emails, you’ve got people pinging the CIO, etc. So we are actually trying to funnel the process into one way. And then we have architects that take a look at the work, size it, get more information, and dive into the task. And so upon that, then we have a few different routes for approval.

If it’s a small and medium work effort, then those go straight to the team and the product owner. And the product owner is going to do their normal prioritization.

If we have an extra-large work effort, it turns into our strategic initiatives. Then it’s either going to be approved by our IT leadership or by the steering committee. If it’s approved, then it actually will come to us. And that’s when we start putting it in the tool. We start looking at resources, we start looking at timings, we start looking at dependencies on other teams. And then we can create the roadmap and everything and decide how we want to adjust? Because if we’ve got competing priorities, then we need to have a conversation.

Becky Flint: IT organizations have so many moving pieces that you go through a rigorous process of approvals and governance. And I also heard you mentioned that smaller features and requests will be prioritized by product. It’s really interesting that the big rock and pebble kind of process is being applied here. It’s definitely a tricky art, handling demands with team limitations?

Mauro Martins: Yeah, I always say that execution and preparation are the keys here. You need to almost set up this execution and preparation, the way it’s almost like, rhythmic. There is a cadence where things will go through certain phases. And if you don’t, you need to figure out the rhythm that these things happen.

What we have done is each department has its own roadmap because everyone wants something, right? They will fight for it, so you need to create these types of funnels. So you have the product roadmap, the customer success roadmap, the sales roadmap, the marketing roadmap, etc. And what I’ve done is that multiple funnels are happening here, so these groups, between themselves or these departments, will have to figure out and prioritize their needs. That way, you don’t end up with 300 requests or asks for our needs.

Make sure that each department has their own roadmap, they set up their specifications and priorities, and find a way to funnel into the same place that then funnels into the teams. I guess that’s the key. That’s where the rhythm enters- the weekly, biweekly, monthly, quarterly, and annually. We call it the product development lifecycle.

At the front of the development lifecycle where we basically have these funnels and these departments funneling the needs. And one thing that I noticed with this setup is, sometimes people don’t want to have this because it’s easier to go to the CTO and ask for something. That way, you automatically get feedback. And you don’t have to wait weeks, you get the buy-in because people know what is happening. But on the other end, people are deciding what to do with what you just requested- you get the feedback loop. And that’s how you probably sell but you get the buying of these things on both sides.

Becky Flint: It’s very interesting, I think there are two things you mentioned in your chat. One is when you talk about a roadmap, everyone means different things.

Yesterday I was talking to someone about this company with only one product manager and only one scrum team but multiple roadmaps.

He was like, “how could that be? “

I said, “Look, as a product manager, you have a product roadmap, that’s where you want a product to be, right. And as a scrum team, the scrum team has its own roadmap, because that’s what they’re supposed to work on. And that is not the same as what product wants. The reason is because the scrum team has production issues, they have a tech roadmap for that. So all of a sudden, you’re dealing with a portfolio, even if you just have one scrum team because you have competing needs, right?”

That is why portfolio management skills are so valuable to carry from place to place. One of the key things is to prioritize, evaluate, and decide what your team works on before you go to your team. So your team has a clear priority, and not just turning all over.

That’s how it’s helping the team side. I want to flip around this a little bit and ask how does it help your company?

Mauro Martins: Let me use Dragonboat as an example and how we use it in Basecone. The way we set it up was the departments themselves operate under JIRA. So, they have their own project where they can discuss in whatever matter or whatever way they want to. Additionally, they can have their own roadmap and set up prioritization, etc. But then we have a specific option which is inside Jira in the quarter, and you move that ticket from one status to the other and it automatically shows up in Dragonboat. That helps you create this difference between the noise and discussions, and then the things that you actually want to get done, such as asking for resources from the technical scrum teams.

We do that and then we can be sure that we are discussing the things important to the product. And we can do that in Dragonboat because it’s a curated view of the things that we want to do. That’s how it helps my team and all the other companies. We also use the progress dashboard in Dragonboat and send this over to everyone. We do it in a way that you can see which team is doing what and attach objectives of the company or the strategic pillar for the year.

This enables you to do multiple things. You have the team view, the objectives view, what is being done, and you can send this to everyone. And this helps a lot because this is one of the easiest ways to communicate and generate discussion. After that, you generate the consensus or the alignment. And this is where it is important as a part of the visibility. And I can tell you that throughout the process of working with Basecone, we never had that in the past.

Using Dragonboat’s dashboard enables everyone to ask very difficult questions like why are you spending time doing this? And I still remember those were hard conversations, but the interesting part is, in the end, people were happy because they were actually asking good questions. They were actually trying to find out what is the best use of the team’s time. The thing about visibility alignment is that it gives you a much more efficient company. I am helping my team, and I am helping the company also.

Susan Rainsbarger: Yeah, and I’m right there with Mauro on how you help the company. So we’re just now starting to get to the point of tying our strategic initiatives back to higher-level company goals, and actually be able to show them on the dashboards that Mauro had mentioned. Being able to show that is going to be extremely valuable for us in the IT area, one of the things that we look at is reducing tech debt. And so we’re able to actually visualize now what our work efforts are to reduce that tech debt.

And we’re also able to work at a faster rate because of the new technology that we may be implementing. So we’re actually able to show it even from a bottom-line aspect to help the company grow. Now, I haven’t gotten into the bottom-line numbers. I’m leaving that right now to the CIO. But at least I’m able to show that these efforts have reduced our tech debt.

Mauro Martins: Yes, I forgot to mention exactly that. One of the things in the portfolio that really adds value is if you have done it right, all the teams can do whatever you want in the way you want it. But the output in terms of the data needs to be the same.

So if you want to do, let’s say, feature work, you should use user stories. If you want it to be at the technical level, you should use the issue type. And this is important because if you go up one level, you can see all of your resources, the focus of all your teams. Then you start putting these dashboards on top of it, and you can show people what we are spending time on.

What’s happened before is there are a lot of performance issues clients complain about. And then the interesting part from there is seeing the graphics start to change and the technical depth go up. So that is also very important because it helps to steer that data and helps to steer the company. In the end, it helps the team make the best decisions.

Becky Flint: I think the allocation part is key to the portfolio. At the end of the day, what your leadership shouldn’t need to do is micromanage what your team does, right? You align where your goal needs to be, where your focus will be, and then you also need to make the hard decision on how much you will allocate your team’s resources so that your team is set up for success. If you just say, I want to do all these big things, and then don’t have anything to back it, and then your team just does whatever, it won’t be connected. It’s chaos.

And so I want to use this opportunity to also ask, you mentioned in the intro that you started as a scrum master. And then you gradually found that there were more needs and so you started to do a portfolio manager role. There are some of our audience participants that are in some capacity working with the team directly, and want to know how you get into doing what you’re doing? How do you get the leaders and executives listening to you to say, these are the problems, here’s how we fix it.

Susan Rainsbarger: So for me, it came down to asking those tough questions. So when I came to Ruan, as a scrum master, they asked me to take on more of an admin role.

And actually just put together information for the CIO, to talk to our senior leadership team, and it was all around the portfolio. Basically, it was all about me just gathering information, via Gantt charts and Excel. It came down to asking the tough questions of, “are we sure we have the resources working on the right stuff”. Because the reality is, the team is strapped for time, and they’re not able to get everything done.

Asking those questions and starting to push those trade-offs gave me a better understanding of what we needed and wanted. And then I put the spin on it and said, “I’m going out to these teams, and they’re telling me they’re strapped for time”. That’s pretty much how mine got started. I started to take a look at all of the teams, all of those buckets, because one of our buckets, as an example, is our prod support. No matter what team you’re on prod support is the number one. Get your break fixes done.

And it was really, truly starting to dive into understanding what that percentage was for each team. From there, you just want to ask the question, “how much time are you spending on prod support?”

Then you take a look at and ask the CIO, “you’ve got all these strategic initiatives, and this is the way they’re stacking up? Are you taking into account these other buckets out here?”

And amazingly enough, the answer was, “no, we’re just looking at strategic initiatives”. I’m like, you really can’t do that. Because you’re not going to get those strategic initiatives done if you’re not taking into account the capacity and other things. So for my evolution, it was just asking questions and starting to show what the possibilities were. It was a gradual evolution from “there’s got to be a better way to do it than an Excel” to looking across the board at several different products because some of our teams use JIRA, some don’t. So it was how do you mesh and work between those two obstacles? Were the metrics aren’t 100% gonna match up? Right? Because not everybody’s using JIRA.

So it was just starting to put those pieces together and start showing what the possibilities were. That’s how I got to be where I’m at right now.

Mauro Martins: Okay, so on my side, I guess that’s very common. When you enter a company, you can probably start as a scrum master or, or a project manager if the team is small or the company is small. And then the people that were doing the work that they’re doing somewhere, they start having the time to do it, and they start stacking more teams and more teams, and we start having dependencies, then something happens and someone says, “I don’t have the time to do it, let’s find someone to help.” And that’s when you start to move more to the project management side where you take care of the dependencies, maybe you just take care of your team and/or two teams.

For me, portfolio management and project management were a subtle way to teams. And the work starts to show with the start of spring reports and offsprings reports. People started to see the value because they never actually read this. It gets to a point where you, yourself cannot do anything more than this. And you ask for help. And then you start evolving the team, multiple times.

It happens because people need help understanding what is going on. And I still remember when I joined my second company, the person that hired me was the CEO or CTO. I always told him that I’m not here to make his life easier. I’m here to challenge all your decisions. That’s it. So you start to go into project management and you are helping them but at the same time, you reveal problems they had no idea about because things evolve so quickly. And it’s usually the case for the technology. And then when they see the numbers and they see what is happening. They realize maybe they need more of this. Because either I need to justify a decision, or I need more information to make the correct decisions. That’s how we come in to help.

You go into project management to help one or two teams, and you start slowly showing these. And sometimes the changes come from the people in your team and sometimes it is your curiosity that triggers that.

Becky Flint: It’s very similar from company to company. Most times when the first Scrum Master arrives you need a clinical fixed route, but then very quickly, once everything is fixed and they know what to do, they don’t need you anymore. Then you realize you better go find another job.

That’s why I then became a program manager to try and cross teams. However, eventually, you get to a certain point of maturity and you need to become a portfolio manager because you want to make cross-team dependencies and good decisions with your position of visibility. So say you get yourself out of the job at each level to the point where you truly add a strategic impact. Now, you still probably do some of the scrum master roles, but you definitely would kind of balance different things like Susan and Mauro mentioned.

So you get to do multiple roles, depending on the needs. You take on challenges and try to solve the problem. That’s really what leads you to where you are today.

We have a question from one of the audience members, which is, what is your role in managing planned versus unplanned work? And how do you use toolings like Dragonboat to help identify the resource constraints?

Susan Rainsbarger: Okay so multiple pieces there. Typically for my role, I work with the planned. I bring awareness to any of the unplanned. Product owners should be the ones coming and talking to us about unplanned but that typically always has an exception. Our perspective is at this team level so where I worry about the unplanned is when we start taking a look at prod support issues or the time that is escalating and taking away from that strategic work. That’s when I start bringing that up and then we talk about it at our portfolio meeting.

We talk about the risks, what are we seeing, are we seeing any delays in that work, etc. So I typically look at the planned stuff at the portfolio level, and Dragonboat has been a wonderful help for me regarding the resources mainly because under that forecast module you can start working with your estimates and you can start seeing its color. So you start seeing when you stack things up with reds and greens. It is helpful because my leaders are also visual people. And from there, I can start moving things for them and they start seeing the resources adjust at the bottom, and that’s huge for me.

The other nice thing about Dragonboat is it has what you guys call a draft mode. From there I can take a look in draft mode and move things around. If I change the timing, the resources free up which were previously in red.

So it’s very visual for me and I love that it identifies where there are constrained resources. That’s a great impact for us.

Mauro Martins: On my side, the experience doing the what-if analysis interval of resourcing is gold because when you see the costs or the effort for the epics, in terms of resources you can see the demand coming in.

Let’s say from the product after they did all the prioritization and you put them into an estimation of effort. Then you put that into a timeline. Already, you can start seeing all rights which means that you are over-allocated and that starts to be a problem with the CTO because he says I don’t have enough resources to generate or produce the roadmap you’re requesting from the resource that I have.

However, if you create the dependency connection in Dragonboat you see that the red arrows also start flashing and so if there’re too many reds you know you’re not in a good position. I’ve spent so much time and effort before trying to make allocation and quarterly planning perfect, but things don’t always go to plan so it was a waste of time.

Becky Flint: True, you can never plan everything but I think having a plan as you said is important to see. At least you see the major problems ahead so you don’t just toss your team and they have to figure it out because it’s very expensive. It’s demoralizing so at least you figure out let’s say the next month so you know you can proceed and then you can move on. You know you have been in your career for a while and if you look back to your younger self or to those people who are out there what would you do differently if anything?

Susan Rainsbarger:  Based on everything that happened throughout my career I don’t know there would be anything I would do differently. I had a path of learning to understand the efficiencies which led me straight into project management and understanding how to get all the pieces to work together. The only thing I would have done differently would be I would notify my younger self earlier about the agile practice and start diving in there a little bit earlier because I think it would have helped the way I look at agile. I think that you can use shorter increments to get the business what they need sooner and then tweak along the way. That way, you get that business value faster. So I would just tell my younger self to take an interest in that earlier.

Mauro Martins: So this is probably the fourth company where I do the same thing. I start at around 30- 40 people then we scale up to whatever number and I learned that no company is the same when you try to work in this type of role where you basically try to be the glue but at the same time you’re there to ask tough questions and show hard truths. No company is the same, no process is the same because you have very different people. You need to remember this when you enter because you will always be in that pushy position where you’re there to act upon change and create the change even when it’s uncomfortable.

It’s your job to get a buy-in from the guys who don’t want to change. I mean the others will always ask you for something but go for the ones that don’t believe that this is the thing because you’re there to force them to show a lot of the things that maybe they don’t want to be shown.

Start asking where are the worst things that you are dealing with. What are the things

that have a negative impact every day in your work and try to build from there.

Also, don’t ever think that talking with people inside your company and having regular one-on-ones with very different people outside even of your team is a waste of time because you’ll see or you will notice things and you will learn so many things just by doing that. In the end, it will fuel a lot of the things you get a lot of feedback on.

Let’s say that you talk with the CX, you talk with the product, and you talk with technology. From that, you start seeing how these people in these departments interact and you start to understand where they are struggling. That’s how you get people to trust in you when you’re solving the issues for them.

I will say that I already joined companies where I said “oh okay so I have everything figured out. I’ve done it in the past so let’s start doing this. Maybe your boss will like you but the people that do the work that will enable you to show your boss something, will not. In the end that is way more stressful and way worse.

Becky Flint: Yeah, it’s funny you both have a very similar way of talking about the curiosity that gets you to talk to people about the challenges. The other part that leads to growth is agile. When you think about it, when you go to a company, the way you try to instill a change is you will find naysayers and try to turn them around, and then from there, it’s easier to turn more people around. You can almost call it the agile change management or agile process rollout.

Mauro Martins: The job is highly rewarding because you see a lot of different things

happening because you started them and because you light up something in people. You get to see people having hard discussions and that’s where you get to say, “yeah I’ve done it. I’ve done something right because these guys are having hard conversations.”

The funny part is they leave the conversations happier because they are discussing the things that matter to them.

Susan Rainsbarger: Exactly, you can see that you are having an impact at the team level, across the department, to across the company.