When I posted How to See Your Leading, Lagging, and Reliable Estimation Metrics last week, a colleague suggested I was not quite right. He said that Aging is actually the leading indicator for more reliable data. He is absolutely correct. However, we don’t always see the real problem. The reader who emailed me only saw […]
Does your organization use a PMO as a way to manage the various P functions: project, program, and portfolio management? Plenty of organizations do use PMOs. However, I rarely see them as effective in furthering the organization’s operational excellence or the strategy. Instead, I too often see them as yet another function that creates delays
This is the March 2025 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email. Susan, a product leader, has a big problem. One of the senior managers, Tim, often wants to know the cost (or time) required for a new feature or a new product. So he asks
I had a wonderful time discussing aspects of project management with Sean Trace on his podcast. (That’s a link to the podcast.) We had a wide-ranging conversation about these topics in project management and adaptability: Overarching goals Use value as a way to gauge what to do next. Pivoting and the Sunk Cost Fallacy How
During a sunset sail last week (see the image), I had a lovely conversation with a guy who said he did “accounting” type stuff. I asked him more, and it turns out he works for a three-letter acronym organization. No, I don’t know which one, even though I asked. He’s trying to organize a project
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,
In Effective Agility Requires Cultural Changes: Part 1, I said that real agile approaches require cultural change to focus on flow efficiency, where we focus on watching the work, not the people. Too few organizations can do that. But teams can change how they work—in any approach. Here are three suggestions to emulate flow efficiency
I have a new book: Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility. I wrote it because I’m concerned about what I see in too many supposedly agile teams: Crazy-long backlogs and roadmaps. Those create a serial lifecycle approach with too little experimentation. Worse, sometimes the team doesn’t demo or deliver.
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 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