Editorial note: Edited for readability from podcast audio and diarized into speaker turns.
Introduction & Guest Background
Jim: Hello everyone! Good morning, good evening, whatever time it is where you are. I’m joined by two of my favorite people: I got my normal co-host here, Sander, and our guest today is Yuval. We’re going to hear from him. So, Yuval, will you tell the audience who you are, where you are, and what you do?
Yuval Yeret: Sure. Hi, Jim. Hi, Sander. Great to be here.
Sander: Hi!
Yuval Yeret: Yeah, I guess the best place to start is where I met you guys: as a Professional Scrum Trainer. So, I’m a Professional Scrum Trainer with Scrum.org. I came to be a Professional Scrum Trainer as part of bringing Kanban into the Scrum world. That was an interesting endeavor - getting to talk to a lot of trainers that swear upon story points - at least they were swearing upon story points six or seven years ago, and now they’re going all over the place dumping stickers with “story points are shit” and all that good stuff.
So, that was an interesting thing.
Beyond that, I’m also a SAFe Fellow and SPCT. I kind of have my hands in different aspects of how to help organizations achieve agility at scale, and more recently, generally just figuring out how to deal with growing pains, scaling pains. Agility is one way to deal with some of these challenges, but there could be other ways to help organizations break through hiccups and plateaus on their scaling journey.
Which goes back all the way to what I was doing in my early days of my IT career, which was to optimize networks - helping break through optimization challenges of networks, servers, and operating systems. So, it’s all the same, just working with humans is harder than working with servers, but more interesting!
The Perception and Reality of SAFe
Jim: So, we don’t hold your SAFe fellowship against you. You know that! We’ve talked about it many times.
Yuval Yeret: I’m sure you will!
Sander: Somewhere in this conversation, we will!
Jim: Yes, yes, we’ll take you out behind the old woodshed. But what do you think the industry gets wrong about SAFe? Is all the hate and the polarizing nature of it… What would you put out there for the audience about that?
Yuval Yeret: I find it funny that the pundits like us - and many others on LinkedIn or wherever - find the same thing wrong about SAFe that they’ve been finding wrong about Scrum for many, many years. One of the main things that happened with SAFe is that it became too successful for its own good, like Scrum.
Ken [Schwaber] was a genius - Ken still is a genius. Certifying Scrum Masters was a work of genius. It created a lot of push for agility that was the one thing that really got Agile to cross the chasm, right?
To get Scrum to cross the chasm.
A lot of people started to hate Scrum because of that, and a lot of people these days kind of have a lot of criticism about Scrum if you look at the current trends in product operating models and podcasts in the product world. But that happened not because of what Scrum is, but because of how Scrum turned out to be.
A similar pattern is happening with SAFe. People mainly hate SAFe for:
A) It was very successful, which frustrates a lot of us in this space who are trying to make a business based on different approaches. So, that’s one reason for a lot of criticism about SAFe out there.
B) Another legitimate criticism is that there’s a lot of bad SAFe out there. People aren’t really SAFe in how they practice SAFe. Why is that happening? A big reason why that is happening is the Law of Raspberry Jam - Jerry Weinberg’s Law of Raspberry Jam: SAFe is spread too thin for the level of expertise that is around SAFe.
That’s the way I see it.
It’s become too popular for its own good. The one other interesting question about this from a commercial perspective is: was that the plan? Is that the plan? Do people care? Similar questions could be asked about the Scrum certification business if we’re honest about it. Are we certifying too many people for their own good as Certified Scrum Masters?
Is there still meaning for being a PSM, a CSM, or is anything before a PSM III even worthwhile?
Sander: Yeah, and I think that’s one of the things that I’ve seen happening with myself, because I’m a reformed SPC as well. If you compare those journeys to be a PST - and I don’t want to turn this too much into a roast of SAFe - to become a PST is a very rigorous process before you can actually teach any course that’s even remotely close to anything Professional Scrum.
That threshold is different when it comes to SAFe. I can take a three-day course - it’s four days for SPC - and then I can teach classes. That’s exactly what I did. I came out of my burnout, crawled out of my cave, and my new employer asked me, “Can you teach SAFe classes?” I said, “No, because I don’t think SAFe is a good thing.” But he was like, “Can you try?” All right, I got certified within a week, and I could teach classes without knowing anything or having been part of any practical application or execution of SAFe.
So, the threshold to send static SAFe noise into the ether is just very low.
Yuval Yeret: I agree.
Jim: Well, and that could be said about almost anything. One of the reasons that I like you, Yuval, is because you’re an experienced practitioner. What I have found in all these communities is you’re also pragmatic, because experience normally brings pragmatism, and you have many tools in your toolbox.
So, I think two of the issues at play here that bother people is when somebody who is not experienced goes around wielding an extremely dangerous tool, which is what Sander is referencing. The other thing is the old adage: if you only have a hammer, everything looks like a nail. The experienced practitioners like yourself, and many others, know how to deploy, when to deploy which tools, practices, techniques, and they know how they can go well, they know how they can go poorly, and they know how to help people when they hit those very predictable problems - big problems, little problems.
As a trainer who doesn’t do nearly as much training lately as I used to because I’ve been doing too much doing, it’s a pattern that’s repeated itself over and over again. I’ll bump into somebody in the community or at an event, in my personal life, or in a class, and they’ll say, “Oh, we don’t do Scrum, we do SAFe.” I always smile and chuckle, and I open the website and I’m like, “Hey, you see those little circles down there at the bottom?
What’s that?” And they read, and they’re like, “Oh, there’s Scrum or Kanban.” I’m like, “So, I think I know what you mean. You’re saying we have some different vocabulary, we do some different things, but if you don’t understand the foundational ideas of this - I don’t care what you call it. I don’t care where you get your training, what you call it.
Before anyone blasts me, sure, you can do whatever custom thing that you want that doesn’t go by any name and doesn’t have a website, and it could be amazing, and you could deliver world-class products with it. But if you’re going to say ‘I don’t like mushrooms’ and you’ve never eaten a mushroom… I don’t have a lot of time for that.
If you’re going to say ‘I hate Scrum,’ but you’ve never done it, I’m not going to value that opinion very much. Same thing with SAFe. I did it enough, went through my training, got my SPC to form an opinion about it. And my opinion is, it’s not for me, but there’s a lot of great people involved in it, there’s a lot of great ideas involved in it.
I refer to the website constantly because it’s got a lot of good, consumable information. I don’t know, does that make me a traitor? I don’t think so, I hope not.
Traditional PMO vs. Lean Portfolio Management
Jim: But that’s not what I want to talk about today. What I want to talk about is a couple of the other really big tools in the Yuval toolkit, which are Kanban, OKRs, and this Lean Portfolio thinking. That’s what you and I were talking about recently. Let me just start by asking a very basic question, which is: what is the difference, in your opinion, between a traditional PMO and a Lean Portfolio?
Yuval Yeret: For me, a traditional PMO is the manifestation or the ultimate home of the scope-budget-timeline project mindset. We’ll make a plan, we’ll execute to the plan, what we’ll measure and what we’ll track is whether we’re working according to how we said we will work, whether we delivered what we said we will deliver, and even worse, have we spent our hours on the things we said that we will spend our hours on, is that how we allocated our budget?
For me, that’s the classic traditional PMO.
It’s there to help an organization gain control. It’s there for a good purpose, okay? The purpose is to make sure that the organization is in control, that an organization that is working on multiple programs, multiple investment directions, is heading in the right direction. The intent is good. The application doesn’t really work that well in an environment of uncertainty, complexity, or when the resources that are doing the work are people, with their own motivational factors, intrinsic motivation, the fact that there’s friction between what we think will work, what actually people do, how they hear what we want to try and do, and what are the effects of actually trying to make things work.
That’s the traditional PMO.
Lean Portfolio, Agile Portfolio, whatever you want to call it, tries to bring the principles of agility that are there as part of Scrum at the team level and apply them at a larger scale. Why is it not just Scrum?
Because it’s not necessarily one team where all of the artifacts of Scrum and the accountabilities and the events apply, but it’s the same thinking: it’s empiricism, it’s empowerment, it’s continuous improvement, it’s discover-to-deliver, working continuously, flow. All of these principles are part of what is a leaner approach to portfolio.
It’s measuring outcomes, being more evidence-oriented. You can think of it as applying EBM (Evidence-Based Management) at the portfolio level.
Jim: So, the question that comes to mind is… I have a number of clients right now, but the two biggest ones are both struggling with the same idea, but they’re in very different places on the journey. One of them has no PMO structure whatsoever and is just now, after almost 80 years in business, getting to the point where they need a centralized view of all the innovative things going on.
Then the other one has tried 15 or 20 different things over the life of the company, and right now is six months post-letting the PMO go. They’ve just kind of disbanded the group and all that.
So, my first question is: can these two things coexist, or are they one thing? Because most companies have different types of work. You’ve got this confluence of maybe we’re making some physical products, maybe we’ve got some digital products, maybe we have some traditional waterfall-led, on-time/on-budget/on-scope projects, and then we’ve got these Agile misfits in that other building.
What do you think? Is it a choice, or is it a “yes, and” type answer?
Yuval Yeret: First of all, you can separate things out and say these are Lean Portfolio / Agile Portfolio, and this is the portfolio of the traditional things. Should you? I don’t think you should. Because I think more and more stuff that’s happening in an organization - whether you’re using Agile at the team level or not - has uncertainty, has complexity.
Whether you’re building technology, whether you’re working on the company, whether it is figuring out how to introduce new sales techniques, moving from on-prem to cloud, from perpetual license to subscription models… Whatever it is in the playbook that you’re trying to implement right now, or problem that you’re trying to solve, that’s something that probably would benefit from outcome orientation and evidence-based management.
Looking at it from the perspective of an Agile portfolio or evidence-based portfolio management - if you want to choose that language - probably makes sense. In my experience, it actually starts to drive the principles and the mindset in the right direction. Everything - whether it is building software, configuring IT systems, or working on the business - you should first talk about your hypothesis.
Do people really need this? Whether it’s people inside the organization or outside, is it desirable? Is it viable? Is it feasible? What should we go and learn on? Okay, let’s first discover before we fully commit to going and doing that thing. That mindset should apply to the whole organization, and that’s not how most organizations think.
I don’t know about your two clients there, but I would imagine that if they’re anywhere like my clients, that thinking is not yet prevalent in the C-suite or the leadership team, or wherever the portfolio leadership team for a BU is. Any tool that they can use to actually help them think this way is worth using.
That’s what I really find powerful about Lean or Agile portfolio: it’s a very lightweight intervention. It doesn’t require you to go and do Agile, Scrum, Kanban, SAFe throughout the organization. It’s just a lightweight intervention, typically with Kanban at the level of your biggest initiatives, together with setting some goals and guardrails that ideally push control and empower people with context.
It can really start to change the mindset and drive agility in the organization.
Portfolio Alignments: Work vs. Teams
Jim: I have a model or a way of talking about this complex idea, and I’m not going to say it’s the right one, I’m just curious - I want to run it by you. When I’m asked what the difference between those things are - PMOs, Agile PMOs, Lean Portfolio Management, etc. - I normally come back to the dictionary term.
Look, I get it, none of us like people that throw that pedantic dictionary term out, but if you think about the dictionary definition of a portfolio: “a range of investments across an organization.” I would say you need to have one of those things. Your investment might look different on a waterfall project than it looks on an Agile project, which means if it’s a different investment, you might need to measure different things.
Think about like a stock portfolio: a blue-chip stock versus something with high risk/high reward. You’re going to measure different things, you might make different decisions, so you can’t use the same dials and levers to manage those two things.
We just talked to Denise Tilles a lot about Product Ops, product ways of working. Products are different things; products go in a portfolio. Platforms, programs… Those are other kinds of “P” words that I find get all lumped in together, and I just see them as different.
If we stay at that portfolio level, the question I ask my clients all the time is - because they tend to want to look at things as there’s like one of these two or three doors that work goes through, like the Agile door, the waterfall door, or maybe door number three - and I ask them: “Is work Agile, or are people and teams Agile?
Or is even the department or group of teams Agile?” The first time I asked somebody that, I was shocked that they were shocked! Because to me, I didn’t think anything of it, it was just on my mind so I said it, and they’re like, “Holy crap, I never thought about it like that.” I’m like, “Well, right.
So, do you have Agile teams?” Because this client was telling me they have Agile teams, and I’m like, “Well, are they only doing Agile work? Are they only doing new product, new value generation, new innovation type work?
No, they’re doing waterfall projects, they’re doing maintenance and operational type work, and they’re doing innovative work.” And I said, “Okay, so sounds like you have an Agile team.” They’re like, “No, no, no, we have Agile projects, and then we have non-Agile.” And I’m like, “Well, then what happens?”
It just really quickly went off the rails and helped them realize that they couldn’t point to one definition that would tell them how to manage those things.
Sander: Doesn’t that also inherently make the whole focus not on the product anymore, but around the process? If you’re going to focus on “these are Agile projects” and “these are not,” then you’re focusing on the environment and the way you approach it, not optimizing the solution for your stakeholders, right?
Jim: I think you’re right, Sander. It does come back to the process, but I think it also highlights the difference in what you need to measure and manage by. So like OKRs, metrics, EBM, and all that is going to look different for different types of work. But when you have one group of human beings with hopes, dreams, and emotions, how do they balance the complexity of managing all these different things, different ways, towards different goals?
I think that’s the struggle that a PMO is intended to help with. Is that right, Yuval?
Yuval Yeret: Maybe let’s take a step back. I’m not even sure that “Agile” is useful in this conversation for PMOs. The demarcation between “Agile projects” or not… It might be a red herring.
I guess the question that I like to ask is, when you’re looking at a portfolio, there are a couple of things that you want to do. One is, you want to look at how much… How do you spread your investments, right?
How much do you want to spend on different things? Okay, that’s part of the portfolio picture. But then there’s the question of how do you manage risk? What are the risks that portfolio management is there to tackle?
One is that inside those areas of investment, people are going out of bounds, they’re not aligned with where the organization wants to go. They’re working on the wrong things maybe, the wrong way.
So, one thing that portfolio management should do is find effective ways both to provide context, provide alignment, as well as to govern, right? I think the same context-setting mechanisms and governance mechanisms should apply regardless of how you do the work. Whether you do the work with Agile or not, you should still have an idea about what are the outcomes that you’re getting, what’s the flow of value, what’s your time to market.
The kind of things that we talk about in EBM, I would suggest we use them regardless of how the work is getting done, and