If you need to plan more often than once a quarter, how do you know how to replan? Instead of incurring the time and cost when you bring everyone together, consider the Product Value Team. (In past writing and presentations, I’ve called this the Product Owner Value Team. I am trying to change my term […]
One of my clients was trying—valiantly—to make their quarterly planning sessions work. They prepared, getting the big hotel room. They had plenty of supplies. The planning even went well. However, within two weeks, their plan had no relation to reality. That meant that for the next ten weeks, the product owners were “on their own.”
In Part 1, I wrote about thinking in feature sets so everyone could see smaller chunks of work. (If you can see them, you might be able to plan for smaller and deliver smaller.) In Part 2, I suggested smaller rolling waves than an entire quarter (two months, or preferably one month) so people could
In Part 1, I wrote about thinking in feature sets and how to quickly create a feature set of—with any luck—smaller features. That’s because features don’t arrive at the same rate and they change in value, during a quarter. Because features change in value and because some feature sets need to deliver value on a more regular
Many teams and organizations try to create one-quarter roadmaps. Here are the problems I see: Teams spend a ton of time estimating what they might do and then they select what will fit into a quarter. They feel or are asked to commit to all that work. The product managers and project portfolio managers depend on
I’ve been coaching several teams with a problem: they like to work in iterations. And, they have milestones that are not on a milestone boundary. What should they do? (I suggested flow and you should have heard their response. Well, maybe not.) Here’s why people want these milestones: The team can’t deliver (for whatever reason) as continuous
There’s a twitter conversation about how to manage team compensation. How can we pay people what they are worth and compensate a team for their value? I know there are teams where I was quite valuable—not because I was “the” leader, but because I helped the team achieve our goals. And, there are teams where I
Own Your Leadership, Part 3 I started this story back in Own Your Leadership, Part 1: Dave and Sherry collaborated to facilitate their team’s ability to deliver one completed feature at a time, to improve the team’s throughput and quality. In Own Your Leadership, Part 2, Sherry realized the team doesn’t have a real PO,
Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases; team communication paths square when the team increases linearly. Here is the calculation where N is
One of the things I like about agile is the fact that it encourages me to learn. I wish I were perfect, able to learn things as soon as I try them. However, I am all too human. It takes me time to learn. I just upgraded one of my text-processing programs, and now about