Consultants and writers share a common problem: we are business owners. That means we manage our businesses. Yes, I manage my own product development and my business. The great Joanna Penn interviewed me and the podcast is now live: Strategy And Business Plans For Authors With Johanna Rothman. If you write and self-publish, you should listen […]
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
The Value of Planning I like my plans. I have several levels of plans: a year or so specifically for books and workshops, a 6-month roadmap so I stay on track or change my track, a one-month week-by-week proposed roadmap, and a weekly plan. I use a kanban board to manage my weekly plans. (See
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
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
It seems as if the larger the agile program, the bigger the planning. Many organizations try to plan for an entire quarter at a time. They bring everyone on the program together in a large room (often a hotel ballroom) and attempt to plan the next quarter’s work. That kind of planning works for some
Many agile teams attempt to plan for an entire quarter at a time. Sometimes, that works quite well. You have deliverables, and everyone understands the order in which you need to deliver them. You use agile because you can receive feedback about the work as you proceed. You might make small adjustments, and you manage