How should we limit WIP on the Portfolio Kanban? How is a Portfolio-level kanban system different when it comes to limiting WIP? Shifting from capacity management to leadership focus management

Helping PMOs navigate the apparent clash between their stage-gate models and agile product operating models applied to the portfolio level.

Executives keep hearing that “95 percent of AI projects fail.” The truth is uglier: it’s not the models that are failing, it’s the management operating systems we’re using to leverage them.

When we were developing the Professional Scrum with Kanban guide and class, Daniel Vacanti kept insisting I inspired the Work Item Aging flow metric we introduced. I was complimented, but didn’t recall the exact reference. Well, it turns out I did write and talk about this way earlier than the PSK.

Show me your Review sessions and I'll easily tell you whether you're a process theater, feature factory, or product lab. How do you switch from a feature factory to a product lab? From an organization managing projects and plans to one focused on traction towards outcomes and business impact?

It's ironic how often we leverage traditional project management for the transformation towards more agile, product oriented ways of working. What would it look like to treat a product transformation like a product?

How do you manage your cross-organization initiatives? How can we leverage the project to product shift for cross-org work? Find out what can be learned from Scrum Product Ownership in this article from PST Yuval Yeret.

Coordination tax—that hidden cost of trying to innovate across organizational boundaries that weren’t designed for the outcomes you’re pursuing. How can we evade this tax?

How can we / should we leverage AI to accelerate discovery and product delivery?

If Context is King in AI - Context should be considered a core "platform product" for enabling AI leverage. What might it look like to develop AI Context like a Product?

Ever get the feeling you’re the “agile person” in the room—brought in to run ceremonies, fix Jira boards, or play Scrum cop, but never actually invited to shape real strategy? If that hits close to home, you’ll want to listen in on my latest conversation with Michael Gerharz.

If your teams are busy “doing Agile” or writing OKRs but the business results aren’t showing up, you’re probably stuck in Process Theater—lots of activity, not much real progress. This happens when people focus on following the process instead of connecting it to actual outcomes, missing the crucial middle step of changing behaviors and delivering impact. The fix? Use outcome mapping: clarify the real behaviors and results you want, then set objectives and key results around those—not just process compliance. Build trust by empowering teams to make decisions and measure progress by tangible change, not vanity metrics. That’s how you move from theater to real traction.

I join Jonathan Stark on Ditching Hourly to discuss the current state of Agile as a platform, how it has evolved over the years, and what practitioners should consider when managing their careers as the platform matures.

Discover why engineering-led GenAI projects often stall (like mobile/cloud before them) and how aligning AI with customer outcomes, integrating legal/security early, and solving real friction points drives deployable business impact. In other words - Product thinking for the win.

Ever feel like your product organization is stuck in the mud... You’re not alone. Many teams start strong, laser-focused on delivering value and achieving product-market fit. But as success scales, things get messy.

How do you develop your company/operating model using product techniques? How do you use an Agile Product Operating Model to build your Agile Product Operating Model? Here's a somewhat concrete playbook bringing this thinking to life.

Explore the relationship, differences and synergies between 3 Product-related buzzwords - Product-Led Growth, Product-Led Org, and Product Operating Model.

Struggling with cross-product initiative ownership? Imagine turning complex, strategic bets into streamlined successes with visionary leadership. Discover how product-oriented initiative owners drive outcomes, foster collaboration, and transform challenges into growth opportunities across teams and products.

What gets measured gets managed. But setting OKRs isn't enough. The flow and traction of OKRs need to be managed as well - otherwise, you'll find yourself in the OKR swamp. Using an OKR Kanban can help you both see the swamp and improve the flow and traction of OKRs.

Most organizations wait way too long to adopt some portfolio-level agility practices. But What if fixing what’s broken REQUIRES focusing on the upstream that’s shaping the work and context of these teams?  My secret weapon in these common situations is to ignore common advice and to actually start with the Portfolio level.

Is your Portfolio Kanban Board Busy? Too many cross-product initiatives? Instead of investing in Portfolio management - Descale by Organizing around Outcomes.

So you have a Portfolio Kanban board managing your biggest investments. You’re actively managing the flow by using this Kanban board in your conversations about the portfolio. Kanban/Flow Metrics can help sharpen your flow focus even further. The four flow metrics described in the Kanban Guide for Scrum Teams / Kanban Guide are Work in Process (WIP), Cycle Time, Throughput, Work Item Age (WIA). How can these metrics help us at the Portfolio level?

They tell us a story of slow, centralized decision-making, often related to classic program management culture combined with an iron spaghetti portfolio where delivering product outcomes often requires wide collaboration across teams and even teams of teams.

Whether you're in the "Agile is Dead" camp or not, it is clear that the movement is not well. Agile Theater is rampant. The term Agile is toxic. Here's an alternative approach that you can use to get out of this mess or avoid it in the first place: Focus on agility rather than agile—principles instead of practices. Here's How.

Two Words Check-in - Focusing on the human connection aspects of the Daily Scrum

If you’re leading your organization’s journey from Project to Product, Product Operations capabilities is one area you should be learning about and thinking through as part of the structure of your Product organization.

Is Continuous Deployment a bragging right or a game-changer? 🤔 CD isn’t just about speed. It’s about closing fast feedback loops to adapt quickly, learn from real user interactions, and drive outcomes. Without it, product development often becomes a guessing game, relying on assumptions instead of data.

The Product world is giving up on Agile. What's going on?

Does it make sense to aim for 100% utilization across the organization? Is that efficient? Whether it’s an ad agency, a factory, a product development organization, or any organization – it has a constraint. The constraint/bottleneck should be optimized, but other areas of the process shouldn’t aim for 100% utilization since that would create waste and overload.

While Product Operating Models focus on developing new Products, they have implications and potential benefits for the teams operating the business and supporting these products. How can we improve the interface between product and business operations? Which elements of product operating models can be leveraged by operations-focused teams?

Working Software. Done Increments. Two related concepts in the agile world that people trying to leverage Agile/Scrum’s empiricism outside of the software/technology space struggle with.

"PMs work on the 𝗽𝗿𝗼𝗱𝘂𝗰𝘁. Product leaders work on the 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝗼𝗿𝗴." Ed Biden Let's take it one step further. Product Leaders should work on the Product Organization using a Product Approach. Successful Product Leaders I worked with applied their Product chops to working on their Org. They Hypothesize, Experiment, Keep options open, Inspect and Adapt, Orient to Outcomes, and use Evidence to guide them.

"Think It, Build It, Ship It, Tweak It: A Business Fable" explores a practical, iterative approach to product development and agility. The fable highlights the importance of balancing planning, execution, and learning in real-time, emphasizing adaptability in delivering business value. By focusing on continuous improvement and responsiveness to customer needs, this methodology helps teams stay aligned with evolving market demands while reducing risks and fostering innovation. The story provides actionable insights for leaders seeking to implement agile practices within their organizations for better outcomes.

Your organization moved to a Product Operating Model (POM), and while individual products operate more iteratively and agilely, prioritization and integration across them is still a nightmare. 😩 Aka Herding wildcats 🐆 down a huge Waterfall 💧 So what can you do?

What if you treated your company like a product? Some of the most successful founders have unlocked this powerful mindset, applying the same principles used to build great products—iterative improvement, stakeholder focus, and strategic investment—to shape their organizations. By viewing internal experiences as products in a portfolio, leaders can drive meaningful change and build better companies.

How can we avoid people punting on Professional Scrum because it is "nice-to-have"? How can Product Market Fit thinking help us? How can we focus on demand via an internal case studies perspective?

“OKRs S&%k, but we don’t know anything better” This was a direct quote from a cybersecurity scaleup’s Chief of Staff, but I hear the sentiment way too often from founders, chiefs of staff, COOs, and others in the scaleup ecosystem. I started encountering OKRs when working with scaleups a couple of years ago, helping leaders fix their ways of working to reap the promised benefits of “Agile.”

"We are a team providing services, why should we care about this new Product Operating Model?" Exploring implicit product thinking (aka lazy engineers trying to minimize workload and build leverage) as a way to connect the dots for service-focused teams and individuals.

Listen to the Kanban Guide for Scrum Teams in full - Narrated by one of its co-authors (Yuval Yeret - aka me)

What is SAFe’s perspective on the Product Owner role? How does it differ from the Scrum Guide? Why is Product Ownership split to Product Owner and Product Manager in SAFe? SAFe’s approach to Product Ownership draws quite a bit of criticism. As a Professional Scrum Trainer who’s also a SAFe Fellow/SPCT, here’s my perspective…

Agile was born in software development and has been widely adopted in IT and Product organizations to the point that there's little argument that product/technology organizations should operate using agility principles. More recently, other functions, such as Marketing, have adopted these agility principles and practices. These are useful stopgap measures on the journey toward real organizational agility. The next frontier in expanding the scope of agility is tackling the complex challenge of developing the company as the Product people use Scrum to manage.

The story of Capital One laying off hundreds of people in Agile roles is making the rounds. I have no direct connection to Capital One, so I can’t comment about what’s going on there. I'll just say that based on what I hear from people who've been involved, the reality is more complex than it seems on the surface. Check out my thoughts about the future of agile roles and agility in general.

Many organizations struggle with OKRs (Objectives and Key Results). Let's explore how agility principles and practices such as Scrum can help us use OKRs to improve alignment, focus, empowerment, and empiricism in our organization.

Many organizations are trying to improve the alignment between strategy and execution with the OKRs framework (Objectives and Key Results). There’s good intent there, but more often than not, looking under the hood, you notice:  OKRs that look more like tasks than strategic objectives – especially by the time they reach working teams OKRs are used to micro-manage teams and individuals rather than empower and enable them.  Too many OKRs are set without any respect/consideration of the ability to deliver them sustainably while dealing with other work in the organization. Defining OKRs and then forgetting about them until it's time to grade them. (Even worse, some organizations don’t even bother with a serious consideration of how they did on their OKRs…)  These are smells of "OKR Theater" or "OKRs in Name Only."

In this article, I’ll explore the need for and the attributes of an agile business operating system related to Private Equity (PE) portfolio companies. It hopefully helps leaders of such companies and PE professionals focused on the operations side expand their perspective on what “Agile” and "Agility" mean in their world and how they can help them improve returns realized in their investments. 

Are Scrum Masters here set up for success? Are they “leaders who serve”? Which of the Professional Scrum Master choices/stances can they choose from? Are they a core aspect of our organization's approach to leadership/management? Are they an afterthought to get a higher score on an agile maturity assessment or some RFP? Are they respected, and appreciated by the people they serve? Are they in high demand? Implementing the Scrum Master accountability effectively is hard. It ties straight into creating a servant leadership and self-managemement/empowering culture in which business agility thrives. These are some of the questions leaders should be asking and thinking about.

If you are an agile leader - do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer? 

Aligning Scrum Team Topology to Strategy with OKRs and Product Goals

Leaders use the Scrum Artifacts as a window into the work of the Scrum Team. This transparency enables inspection and adaptation at the appropriate level while enabling the team to self-manage. 

It's time to look at the Scrum Events