Editorial note: Edited for readability from local ASR and diarized into speaker turns.
The friction around leadership
Yuval Yeret: Why should private equity operators care about agile at all? Why should they pay close attention to whether the companies they’re buying and operating follow agile theater - just abusing agile rules without understanding the process - or actually leverage agility?
What is the importance of principle-driven agility over rigid adherence to frameworks? And what’s the unique position that private equity firms and consultants can take in driving a transformation towards real agility?
I’ve been an avid listener of the Private Equity FunCast for a while; I find the private growth equity space fascinating. There are lots of potential synergies with agility and with my practice specifically. On the Private Equity FunCast, ParkerGale partners Jim, Devin, and Paul, and their guests share culturally-oriented perspectives and approaches, which is a refreshing take on the private growth equity world.
I had lots of fun discussing the agility ecosystem, especially in the context of middle-market private equity portcos, with Jim Milbery, an operating partner at the firm. I was pleasantly surprised with how much Jim knows about agile and agility, and we even had some laughs about Agile Theater. We dove right into what we’re seeing in the trenches, comparing notes and riffing off each other.
I hope you enjoy this conversation I had with Jim. Five, four, three, two, one… Thunderbirds are go.
Jim Milbery: Welcome, Yuval Yeret! How are you today? Good to see you.
Yuval Yeret: Good to see you again!
Jim Milbery: Today we’re talking about agility in the private equity space, which is going to be a religious war over agile - not really, but it’s a good way to introduce it! You’ve got a great background. Just talk a little bit about your background, how you got into the space, and your focus.
Yuval Yeret: A bit about me: I’ve been in the product development space since starting in the Israeli Air Force back in the 90s - mainframes, TCP/IP installation on mainframes, routing, networking stuff.
Jim Milbery: Hold on, I didn’t know you were a z/OS guy! Interesting! ISPF, you know?
Yuval Yeret: Yes, exactly! I installed TCP/IP on the Israeli Air Force mainframe.
Jim Milbery: Oh, nice. Yeah, that was back when IBM SNA didn’t like TCP. TCP/IP on a non-Unix operating system was a big deal back in the day!
Yuval Yeret: Yes, it was. I was in charge of the VPS - Virtual Printer System. I was pretty good at assembly. My original Israeli Army computer school sent me to the systems team, and from then on my career for about 13 years was lower in the OSI stack - networking, Linux, kernel stuff. Eventually I made my way to leading teams in engineering and product development.
Around 2005 - 2006, I started to feel the pain in how we were working at the time, started looking at different ways to do things, and got the agile bug. We started to use it in my engineering group, and since 2009 I’ve been helping others do this.
A lot of the companies I worked with were in deep technology, networking, and storage, but over time it became more diverse: cybersecurity companies, medical devices, healthcare, banking, fintech, and all the way to companies like Gillette and biotech pharma in the Boston area - helping them figure out how to navigate this space with so much dogma around it.
Jim Milbery: The key is the words around it. Even Martin Fowler, one of the original signatories, claimed that when vendors got involved, they kind of ruined everything when it came to agile.
Because we buy software companies, the interesting part is if you read the original manifesto, a lot of the rules were arbitrary on purpose; they just had to pick something, and then people treated them as a religious endeavor. Kent Beck was kind of the angry young man of agile. His original argument was: software developers have to be flexible about change because customer requirements change, and on the other side, management can’t arbitrarily dictate how long it takes to build without understanding the engineering.
That was the stress between the two.
Yuval Yeret: I still remember sitting on a panel at an agile conference ten years back. There was a question from the audience: “Leadership is asking us for a roadmap and when this thing will be done.” One of the agile pundits dogmatically said: “You can’t say when it’s going to be done - we’re living in a VUCA world!
We simply don’t know.”
My role in that conversation - and in the world in general - is trying to meet people where they are. Both the engineers who are right that we cannot predict everything with certainty, and leadership, management, business, and product people who do need to make plans. How do we make those plans?
What is reasonable to predict, what is unreasonable, and what degrees of freedom can we leverage? That’s my conversation around agility, rather than the dogmatic “you can never predict anything.”
Jim Milbery: I had a boss years ago who was a big fan of Disney. His premise was: we should all be like Disney. When the movie hits, the toys are ready in the store, the rides are ready at the theme park, and the marketing is built around it. It was the whole product release, not just “hey, we got the movie, now what do we do about toys?”
He said, “We’re not there in software, but we should think about that as a goal.” Part of what’s good about agile is recognizing that whole product solution: documentation, marketing materials, sales enablement, value proposition. Most teams I see today are doing some version of agile. The fanatics will tell you that if it’s not orthodox agile, it’s waterfall.
I don’t think that’s true.
Yuval Yeret: I care less about whether it’s uppercase Agile or lowercase agile. Agile as a term has a lot going on that has become unhealthy, even toxic. What is going to replace it - agility, product operating model?
There will always be names, but I hope most of your portfolio companies are at least trying to close fast feedback loops and learn, rather than build for years without validating assumptions.
Because agile started primarily in development, people forgot about go-to-market, product marketing, and operations until DevOps came along. Whether agile was initially framed too narrowly around developer problems or not, it’s clear today that successful application must encompass all of these aspects.
Jim Milbery: Using the agile approach outside of engineering is something we’re still in the early stages of: marketing, tech support, sales. Not having quick feedback loops is a widespread problem. Even in engineering, many teams still fear talking directly to customers. Why assume it’s going to be bad feedback?
They may lead you in a much better direction than you would go on your own.
Yuval Yeret: It’s more vulnerable to say, “I’m not sure, it’s a hypothesis.” As investors, do you acknowledge that your investment thesis is in many cases a hypothesis?
Jim Milbery: It’s always a hypothesis! Anything beyond the next 30 to 60 days is directional; it’s not a rigid plan. We look at it as “it depends.” We have to do a lot of course correction.
Ray Dalio’s approach resonates: Find two really smart people who completely disagree on an issue, get in the middle, and you’ll learn a lot. A great hypothesis is one where you return 100x your money; another great one is killed right away because it was a dumb idea and you didn’t spend six months banging your head against the wall.
I hate the phrase “fail fast” - failing isn’t great, but failing without wasting a ton of time is course correction.
Yuval Yeret: I like to look at it through risk and de-risking. I use IDEO’s model of desirability, viability, and feasibility. The whole purpose of agile is to reduce the risk of taking the wrong approach - either focusing on the wrong problem, taking the wrong direction in solving it, or running into business viability issues.
If we can learn on something as quickly as possible and make a decision on where to go, that’s a success, not a failure.
What is really happening in the system
Jim Milbery: Risk profiles can change almost overnight. Look at how large language models and ChatGPT disrupted software companies with text-heavy workflows. You can do everything right and de-risk along the path, and suddenly a macroeconomic or technological shift requires you to change direction.
Yuval Yeret: COVID was another dramatic example. I was working with an orthopedics network in Maine applying agility across their business operations - merging clinics, new services, electronic medical records - and midway through their 90-day plan, COVID hit. Do you execute the plan or do you pivot to figure out orthopedics over Zoom?
Agility is about learning to surf, snowboard, or ski whatever nature throws at us. Minimize bureaucracy and long-term planning that cannot easily change. In Evidence-Based Management, you have strategic goals, but in the short term you iterate towards intermediate goals - like OKRs or big rocks - testing hypotheses along the way.
Jim Milbery: OKRs often become another religious thing people hang their hat on. OKRs end up driving strategy simply because people are reviewed on them, even when the market conditions have shifted.
Yuval Yeret: That’s OKR theater. OKRs should set direction and mission, not prescribe rigid steps. The dynamic in the market can be summarized as: sitting in an engineering meeting where they show a chart saying “velocity is up,” but they haven’t actually shipped any valuable software!
We have tons of confidence at the peak of “Mount Stupid.” There’s the late Jerry Weinberg’s Law of the Raspberry Jam: when you spread something too thin, there’s not enough substance everywhere. In the skiing world they call it the “tourists” - people on the slopes one day a year who think they know what they’re doing.
Jim Milbery: In our portfolio, we buy founder-owned software businesses where the founder is typically retiring in their 60s. Two things happen where agile unlocks value:
First, founders get nervous about taking risk once the business is generating cash flow and they’ve bought a boat. They become “Chief Worry Officers.”
Second, founders unintentionally teach all managers that every decision goes up through them. When the founder steps down, top managers don’t have built-in cross-functional decision-making processes.
Yuval Yeret: I see a very similar pattern in scale-ups. There is an early culture where all decisions route through leadership, and a lack of an operating system that balances empowerment with alignment.
Look at Brian Chesky at Airbnb: He was told to empower everyone, and ended up frustrated by lack of alignment. What we try to do is build an operating system that creates scale by leading with context, providing alignment, and creating cross-functional teams that push decision rights down.
Jim Milbery: Sometimes when building cross-functional teams, people make them too ceremonial: “We’re going to meet every week for an hour.” I tell them: we don’t need a weekly recurring meeting just to meet. What’s the work session?
If we don’t have something to review until two weeks out, meet in two weeks!
Yuval Yeret: When people have so many things on their plate, they spend 50% or more of their time in meetings about the work rather than doing the work. If all we can do is spend an hour a week on a “strategic” initiative, that’s a smell: we have too many goals. If you have 30 strategic goals, none of them is strategic.
The practical shift
Jim Milbery: My old boss’s favorite malapropism was “we need to focus on everything!” People also copy-paste playbooks like the Amazon six-page memo or two-pizza teams without adapting to their own organizational context.
Yuval Yeret: Agile should be grounded in first principles: empiricism, balancing alignment and autonomy, and continuous learning. But working from first principles requires critical thinking. Late-majority adopters want off-the-shelf playbooks, which fuels agile theater.
A biotech firm in Boston had Scrum perceived as mechanical micromanagement by task-tracking Scrum Masters. We taught them the principles, shed unnecessary mechanics, and focused on genuine agility in how they manage work and strategic planning with OKRs. Once the principles stuck, they didn’t need ongoing consulting because they owned their operating system.
Jim Milbery: Agile isn’t a straight line up and to the right. Like an exercise program, you plateau, catch your breath, and evaluate what’s working before the next push.
Yuval Yeret: That mirrors the evolutionary Kanban approach: start where you are, introduce work-in-progress limits, and evolve sustainably. When people build their own operating system out of modular patterns, it sticks.
What leaders should pay attention to
Jim Milbery: In software businesses, especially founder-led, early sales reps sell custom features to close deals, creating a Frankenstein codebase. A product manager in our portfolio had a great response to prospects: “If I build this one-off custom feature for you, I can’t build all the other great roadmap items for everyone else.” That enabled a Kanban pull system rather than committing to rigid custom roadmaps.
Yuval Yeret: In pharma IT and elsewhere, teams often struggle to shift from a project mindset (doing whatever stakeholders ask) to a product mindset (having a strategic direction and saying no). True product leadership requires looking at market patterns and prioritizing outcomes rather than managing a feature factory.
Jim Milbery: I use the metaphor of the BMW and the bulldozer. If you need to move dirt, buy a bulldozer; if you want to go fast on the highway, buy a BMW. The discipline to walk away from a deal because you’re a BMW and they need a bulldozer saves companies from enormous technical and strategic debt.
Yuval Yeret: And if all your salespeople keep running into customers needing a bulldozer while you sell BMWs, that’s a signal to bring product, sales, marketing, and engineering together - like a rugby team or the Apollo 13 engineering room - to solve the problem collaboratively.
Jim Milbery: In private equity, my job as an operating partner is to go into product sessions and say the provocative things that internal employees might fear asking. We can throw crazy hypotheses at the wall because I don’t care how stupid I look; it frees the team to challenge assumptions and find the real answer.
Yuval Yeret: Exactly. The goal is creating an environment where people feel safe bringing up assumptions and testing them quickly.
Jim Milbery: Yuval, if folks want to get in touch with you, where should they look?
Yuval Yeret: You can read my articles at yuvalyeret.com/blog/. If you search for “Yuval Yeret” on Google or LinkedIn, there’s only one of me! I’m always happy to connect and talk about bringing pragmatic, principle-based thinking to agility and product operating models.
Jim Milbery: Fantastic. Thanks for being on the show, Yuval!
Yuval Yeret: Thank you, Jim!