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 see many teams and team members who say, “Agile stinks. It’s a way to force me to work too fast and not finish anything.” When I ask people what’s happening, they say: We’re doing an agile death march because someone else already told us what we have to do and the date it’s due.
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
Susan, a senior leader, wants faster throughput. She can see people working hard. Yet, all the projects seem to take much longer than anyone expects. They’re doing a lot of the right things. No team is multitasking—the teams work on one project at a time. And the teams manage their inside-the-team WIP (Work in Progress).
I’m surprising myself with this experiment and the fact that I am continuing it. I suspect I’m successful because it’s just a minute of some in-progress writing. Transcript: I’m Johanna Rothman, and this is 60 Seconds of Johanna’s WIP for November 9, 2023, where I read an excerpt of just a minute of some
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
My weekly 60 seconds of WIP: This one is also from the project lifecycles book. The Transcript: I’m Johanna Rothman, and this is 60 Seconds of WIP for October 5, 2023, where I read an excerpt that I hope is just a minute of some book in progress. This excerpt is from the currently-named Project
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
I started this series with many specific concerns about a particular interview question: “The product owner and dev team cannot decide on a sprint goal, even after hours of discussion. They (the team) feel that the tasks for the sprint are too varied to manage to a single sprint goal. What should the Scrum Master