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 […]
So many people (and some teams) work under mandates to “use AI.” While I am a fan of these two functions for the current LLMs: The ability to create fast prototypes for human assessment and judgment. And the ability to gain new insights into you, your team’s, or your organization’s data. (This often requires a
When I posted How to See Your Leading, Lagging, and Reliable Estimation Metrics last week, a colleague suggested I was not quite right. He said that Aging is actually the leading indicator for more reliable data. He is absolutely correct. However, we don’t always see the real problem. The reader who emailed me only saw
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
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.
Does your team feel as if they can’t really start when they take an item off the backlog? The team says the item feels too big. Or the team realizes they need someone else from some other team to solve this problem. Worse, the team needs to decompose the item more to make sure they