I’ve been thinking and experimenting a lot about how to use the various LLMs, both in my work and with my clients. I keep seeing a familiar trap: that managers think the gating factor in product development is the speed of coding. But that’s not true. The gating factor is the speed of understanding the […]
I said earlier in this series that no one cares about how “agile” your team is. Or the kind of “agile” your team professess to be. Managers do care about agility: the ability to respond quickly to a changing or changed environment. And that depends on where your team has delays. That’s why value stream
In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. In Part 2, I discussed cooperative teams that have working agreements on when to do code review or make other decisions as a team. While those teams exhibit somewhat more agility, cooperative teams are still not collaborative. So
In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. While those teams are cross-functional, they are not collaborative. However, these expertise-focused “teams” are not the only type of non-collaborative agile teams. There are also cooperative teams. Cooperative teams still tend to work sequentially, focused on each person’s
Maybe your team does have Ready criteria for their backlog. But they look at the backlog item, and they say, “Oh, this is way too big. We have no idea how to start.” That “no idea” often means the work is too large, unclear, or not based on a specific customer with a specific need.
This is Johanna Rothman’s December 2025 Pragmatic Manager newsletter. The Unsubscribe link is at the bottom of this email. In the first part of inviting culture change, I wrote about Stephanie, a senior leader who wants more organizational agility. She’s used the flow metrics to invite that culture change. So far, she’s succeeded with the
This is Johanna Rothman’s November 2025 Pragmatic Manager newsletter. The Unsubscribe link is at the bottom of this email. I’ve been working with Stephanie, a senior leader who’s trying to nudge her organization to more organizational agility. Not because agility is so “good,” but because they want to quickly launch new products and new versions
As far as I can tell, all organizations have the appetite for more work than they have people or time to do that work. It does not matter if the organization is one person or thousands. We all want to accomplish more than we have people. That’s why we need a product vision to drive
So far, I’ve addressed how a project charter can help a team start a project fast and well. That’s why the project charter must clarify product vision, the various project risks, and product risks. And, it’s equally important to know what done means. If the team does not know how little they can do to
In Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project, I explained how project risks can affect the team’s approach to the work. But project risks are not the same as product risks. Product risks are about the need for product innovation. The more innovation this product needs, the more