This is Johanna Rothman’s May 2026 Pragmatic Manager Newsletter. The Unsubscribe link is at the bottom of this newsletter. Several colleagues recently told me their companies asked them to change roles: Steve, a Scrum Master, is now an agile project manager. Polly, a project manager, is now a product manager. And the biggest change of […]
The more work we put into backlogs, roadmaps, and the portfolio, the more product certainty we appear to have. But can we trust that product certainty? No. There’s the Aging problem. Then, there’s the fact that we can’t tell what the future will bring. Even if a team has a relatively low and consistent cycle
A reader asked me these questions about reliable estimation metrics: Would you explain leading and lagging indicators? Can I use a burndown chart to see accurate progress? Is that burndown chart useful if the team has not yet finished grooming the work? These are great questions because too many of us think the answers are
If you are like me, you use apps and websites to finish work every day. How often do those apps and sites break? Way too often. When possible, I report the problem. How long does it take to fix the problem? Sometimes, it takes those vendors days to fix their site. I expect only ten
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
Many of my management clients tell me, “time is money.” That is only partially correct. Once you decide to invest a dollar, that dollar has the same value as any other dollar. Instead of focusing on the expense of a dollar, look for the value that dollar can return. (Because no one ever knows how
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
We talk about cross-functional agile “teams” as if they are the norm. That’s what I show in this image: some responsible person creates a ranked backlog that the cross-functional, collaborative team works on. That team delivers increments of value on a regular basis. At some point, the team will demo their work and retrospect on