This is the February 2025 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email. Last month, I wrote about technical leadership micromanagement and the technical leadership overwhelm. (See One Secret to Free Yourself from the Overwhelm of Leadership Work for that post.) I heard from several product managers. […]
When I wrote Manage It!, I included an idea called a Hudson Bay Start. I wrote an article about that later, in How to Use Iteration Zero—Or Not. Hudson Bay Starts are not a new idea. However, you might not know what they are. Here’s the idea: the team chooses one item from their backlog.
I had a wonderful time speaking with Arin Sime on his Scaling Tech podcast. Listen to the podcast here and see all the notes: Mastering True Agility with Johanna Rothman. That page also has a link to the video on YouTube. We had a wide-ranging conversation, all about reducing cycle time so teams and organizations
Have you seen the Forbes article that has zero idea how efficient engineering teams work? They have a whole long list of “inefficiencies”. This is a quote from that article: Marking oneself as “in a meeting” on Slack Scheduling communications (Slack messages, emails, and code commits) for off-hours to appear active Blocking out private calendar
If you use Scrum or any other iteration-based approach to your work, the team plans in batches for that next iteration. The iteration is a timebox. The batch is the amount of work the team thinks they can do in that timebox. If the batch is sufficiently small and your cycle time is sufficiently short,
Several of my clients are trying to do the impossible right now—plan their portfolio for an entire year. Or plan their product backlogs for eighteen months or longer. When I ask them how well that’s worked for them in the past, they often say, “Our planning works great. Our execution? Not so well.” That’s my
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
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