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
One of my clients wants to use shared services “teams” as they start their agile transformation. Their developers work on a product for months and years at a time. However, the testers and UI people are part of pools of people. The organization calls these testers and UI people, “shared services.” Shared service-thinking denies the
Do you have any idea how long it takes you to make decisions? Or, to clear impediments? Or to report to your team or your boss about your action items? Each of those items is a deliverable. That means we might be able to measure the cycle time for each of these deliverables. Normally, we