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
I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people: People are resources Resources can multitask on several projects at a time If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas
When I teach agile, I explain I like small and short stories. I want to see value in the product every day. Many developers can’t do that. That’s because they have interdependencies with other teams—not developers on their team, but other teams. They can’t implement in the way the picture next to this shows: small,
“George is on his offshoring rampage again,” Cindy said as she slumped down in Ted’s visitor chair. Ted saved his document and turned around. “Oh? Want to tell me about it?” “I need more testers for the feature teams we’re starting, right? I told him. I showed him the project portfolio and the projects we
Shane and the participants and I had a great time at the Geographically Distributed Agile Teams workshop last week. We ran a couple of simulations, and here are some of the emails the teams had: Do you have something for us to test yet? We have completed the card Hi again. I didn’t hear back