I’ve been working with a new-to-the-organization senior leader, Steve, who struggles with this challenge: He wants to capitalize some operational expenses. (That’s a move from OpEx to CapEx.) He is convinced that will give him some freedom to change things while everyone is still working hard. So they’ve asked all the technical people to fill
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
Agile teams have all kinds of ways to deliver value faster, both to verify that the team understands what the customer wants, and to verify that the product works the way everyone expects. The team can slice the stories smaller. Or, it can spike the work to create experiments and learn from them. But every
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