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 […]
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
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
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
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
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
I’m working on my roadmapping talk for Agile 2018. I finally had the transforming idea about how to position the talk: Roadmapping and product planning are about feedback loops. The shorter the feedback loop, the faster and more often we can learn. That feedback loop works in at least these ways: The faster we learn,
Agile approaches can help a team release more often. When a team releases more often, the product people can replan the product roadmaps. The project portfolio people can replan the project portfolio. Not every team releases often enough to take advantage of replanning small and often. Everyone falls prey to “too much” thinking. The product
Sometimes, teams have trouble releasing their work, showing the value of the work they’ve completed. There are many possible reasons for this release problem: The team doesn’t have sufficient working agreements about what “done” means. I’ve written about frictionless releasing. In Create Your Successful Agile Project, I wrote about the done, done-done, and done-done-done words we
I delivered a webinar called Agile Metrics for Team and Product Progress last week, thanks to the nice folks at Innovation Roots. I had fun and so did many of the participants. One person gave me a new saying about metrics (at the end, during the Q&A): Are you data-driven or data-informed? It’s such a great