Susan, a new-to-the-company program manager, could not understand why Product A was so late. The teams used a well-known agile approach. They weren’t working on anything else except for production support. Yet, even though the teams worked hard, not one team could meet any of their deadlines. The teams were unhappy with their progress. They […]
Back when I wrote Writing Secret 5: Decide on One Ideal Reader, I suggested there was one primary reader and other secondary readers. That’s not wrong, but it’s incomplete. Nonfiction writing causes people to decide, rethink, or change their actions, all a change of some sort. That means the ideal reader for a given piece
Your customers can’t take your product more often than once or twice a year. Because the product doesn’t need to leave the building, the teams don’t release internally. Nor do the teams demo on a regular basis. The teams miss the feedback loops so critical for an agile approach. Their agile transformation falls apart. Rethink Your Definition
My most recent article on projectmanagement.com is 3 Questions to Ask Before Estimating an Agile Program. In both Create Your Successful Agile Project and Agile and Lean Program Management, I talk about the reality of estimates in most settings. The question is what kind of an estimate does your project or program need? I’m not opposed to
Many organizations want to see an estimate for your program (a collection of projects with one business deliverable) before they fund it. So, the teams might spend significant time estimating everything the product owners and managers hope will be in the product from today’s perspective. Or, you might try a “sprint zero” to understand the
Let me summarize what I’ve been talking about in these posts. The problem I’m seeing is that too many teams and organizations plan too much in too much detail too soon. Instead of architectural BDUF (Big Design Up Front), it’s project planning as BDUF. They expect one single person (a product manager or a product
You’ve started thinking in feature sets. Maybe you’ve experimented with rolling wave plans inside one quarter, so you can change and replan as you need to support your project or program. You’ve discussed flow-based roadmapping as a way to create MVPs and MVEs, release smaller value more often so you can make better decisions. You
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