I started this series discussing where AI use might create bottlenecks. The more people work solo on anything, the more likely they become bottlenecks for the team. When each person works solo with AI, they reinforce resource efficiency, where everyone is busy, but the team can’t seem to finish anything when anyone wants it. Instead, […]
In How to Use Value Stream Maps to See Where AI Creates Bottlenecks Part 1, I described three teams that used LLMs. However, those teams only used LLMs as individuals, reinforcing resource-efficiency thinking instead of flow-efficiency thinking. (Resource efficiency makes everything take longer because of the focus on the individual. Flow efficiency allows the work
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
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
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
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.