Johanna Rothman, Management Consultant
Expert in Managing Product Development
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support. …
Continue reading “Three Ways to Manage “Extra” Work in an Iteration”
I’ve been working at the intersection of the project portfolio and the product roadmaps. (You can tell because of the various posts about information persistence.) Here’s what I find when I work with my clients: They have years worth of projects in the project portfolio. They have years worth of ideas in various states of description in …
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”
Summary: Too often, customers have a “fake certainty” about the problems they want to solve. They might not have defined the real problem, but they have frequently defined the solution anyway. The risk is that we might build the wrong thing. When the product owner works with the customers to define the problem, then works …
Continue reading “Eliminate Fake Certainty and Solve the Real Problem”
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”
You’ve got interdependencies across the organization for a given project or program to release a product. You can see demos. That’s not the problem. You need enough insight or prediction to start the marketing campaign or to create training videos or product documentation. You need some kind of milestone criteria so you know you can complete …
Continue reading “Agile Milestone Criteria for Projects and Programs”
Many product owners and customers believe they know the problem they want to solve. That fake certainty causes them to define solutions, instead of solving the problem at hand. John Le Drew and I pair-wrote an article describing this problem and how to solve it. See Eliminate Fake Certainty and Solve the Real Problem. Yes, I’ve …
Continue reading “Fake Certainty Article Posted on AgileConnection”
One of the big problems I see with a product orientation (as opposed to a project) is in preparing for ongoing work. You might not start the next project for this product after you complete this project. You might have to round-robin projects for various products because you don’t have enough people to do all …
Continue reading “Product Orientation Requires Technical Excellence”