For years, managers have been trying to find ways to make software product development faster and easier. As an industry, we’ve tried tons of things. Here are just the one I’ve experienced in the 70s, 80s, 90s: Structured Analysis and Design. (That was the precursor to Big Design Up Front.) The SEI’s Capability Maturity Model […]
I had a chance to speak with Tobias Schlottke on his Alphalist podcast: Episode 92: Johanna Rothman The Pragmatic Manager. We had a wide-ranging conversation, mostly about management. We included topics from my programming experience, why multitasking is a disaster, and how to use flow metrics to understand reality. We also touched on many of
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
Some company is buying your company (or vice versa). Why? They claim it’s “Economies of scale,” and the combined organization will save money by centralizing “overhead” and flattening management. You know who that “overhead” is: the people who support the business, such as finance and HR. And, the managers. Worse, the new management asks managers
Many of my middle-management and senior leadership clients want certainty about future work. That’s one of the reasons they create huge backlogs and long roadmaps. Yet, even those backlogs and roadmaps don’t offer certainty. One of these managers said, “I have so much uncertainty and ambiguity. I feel as if I can’t make a good,
Several of my trusted advisor clients have asked this question, “Why do I need to choose between effectiveness and efficiency? Why can’t I have both?” A great question. I recommend they start with effectiveness. That occurs when they say yes to just the work they need now, to reduce the organizational WIP. Start with managing
For years, we’ve used several metaphors to describe software product development: People-based metaphors, such as: Man-weeks for all the humans working on a project or a product. FTE for full-time Equivalent (as in human beings!) “Resources” instead of the words: people, or human beings Construction metaphors, such as: build, which describes how we organize and
Several people on LinkedIn commented on my post, Want Better and Faster Results? Increase Team Size and Reduce WIP. They wondered if adding more people to a small team would violate Brooks’ Law. As with all good questions, the answer is “It depends.” It depends on how your lifecycle manages feedback loops and learning, how
For years, I’ve advocated relatively small teams. Why? Small teams can more easily learn—faster and together. All because they have fewer communication paths. I was only partially right. Smaller teams tend to have lower WIP (Work in Progress). Even if a 5 to 7-person team falls into the Everyone Starts Their Own Story trap (see