Johanna Rothman, Management Consultant
Expert in Managing Product Development
Michael Mahlberg taught me something cool last week. We’re writing an article together. Part of the article is about forecasts. I was ranting and raving about how to help people see their confidence levels. He pointed me to this slideshare: Lightweight Kanban Metrics (in German). (Don’t worry about the language.) Go to slides 24, 25, …
Continue reading “Low Tech Way to Visualize Your Percentile Confidence for Forecasts”
What happens when you use the word “estimate?” For many of my clients, “estimate”== guarantee. Which is not what those words mean. Even if you update the estimate based on data, too many managers still want to know, “When will it be done?” Emphasis on done. And, while managers might not remember the assumptions you …
Continue reading “Estimates Anchor Expectations; Forecasts Include Uncertainty”
You’ve got an impossible project. You have no flexibility. The project is a fixed-price, fixed-scope, fixed-date project. And, you have a specific team to do the work. (There are other impossible projects. Such as when you have a collection of people who multitask among several projects.) Can an agile approach save these projects? No. An agile …
Continue reading “Agile Approaches Can’t Save Impossible Projects: Fixed Cost, Scope, Date”
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points? …
I’m not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.) Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish …
Part 1 was about seeing the value in the various projects. I called the value stream a product so that people would think about who would use it and why. I suggested that we stop work on specific products when you have more products than teams. That would allow you to work on other projects …
Continue reading “Projects, Products, and the Project Portfolio: Part 2, Assess & Rank the Work”
Too many teams have overloaded Product Owners. The teams and PO have trouble connecting the organization’s strategy to what the teams deliver. The teams, PO, management, all think they need big planning. Too often, the POs don’t do small-enough replanning. They’re not living the principles of the agile manifesto. That insufficient collaboration means the PO …
Continue reading “Product Roles, Part 8: Summary: Collaborate at All Levels for the Product”
I started this series with the question: If we have teams for all other aspects of an agile approach, why wouldn’t we want the product owner to also work as part of a team? Could a team reduce the feedback loop durations? In Phase Gate or Other Serial Approaches… When projects use a phase gate …
Continue reading “Product Roles, Part 7: Collaboration Can Shorten Feedback Loops”
As I’ve written these product role posts, a number of you have asked about how to use component teams. You might have a security team. Maybe a performance team. Regardless of my desire, you have component teams. You want a more agile approach to manage the interdependencies among the teams. You want to be able …
Continue reading “Product Roles, Part 5: Component Teams to Create Slices”
An agile approach requires a cross-functional team. That means that everyone on the team focuses on the same intent. That intent might be an entire product. It might be a feature set as part of a larger program. But, the team focuses as a team. That cross-functional team is a product team or a feature …
Continue reading “Product Roles, Part 3: Product or Feature Teams vs Project Teams”