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
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
In How Centralization Decisions Create Friction, Increase Cycle Time, and Cost Money, Part 1, I discussed how removing support staff for departments and managers created longer cycle times. (And sometimes, increased friction so much that people could not easily do their jobs.) Removing those support staff was one indication the companies fell into the Economies
In the first post, How Centralization Decisions Create Friction, Increase Cycle Time, and Cost Money, Part 1, I explained how centralizing even relatively small decisions to centralize has high costs. Why do organizations centralize? To supposedly capitalize on “economies of scale.” That’s the problem of understanding the cost of work—but not the value of that
I’ve been thinking about flow… In his first week, Tom, a new manager, realizes the four teams he leads and serves are frantically trying to finish their work. Each team feels too much pressure to have one-on-ones with him, in this, his first week. He first checked the project portfolio. Here’s what he discovered: His
Dan, a VP, knows he needs more people to get the work done. Suzanne, one of the directors, starts to hire and realizes she has several problems. First, their salary bands are too low—candidates want more money. In addition, the people want to collaborate more than the existing people seem to. She meets with Dan