Fan-out Release Planning

[D. André Dhondt]

(double-posted from http://dhondtsayitsagile.blogspot.com)

Fan-out release planning integrates set-based design, weekly intermediate deliverables (and validated learning), sustainable pace, top-down budgeting, risk management, and deliberate prioritization to deliver a valuable product in sync with business, marketing, and sales plans. We do this from a Product Owner's perspective by selecting epics for the release, establishing a budget for each topic based on the business value, reality-checking the expectations with the development team (and trimming scope as necessary), and then scheduling the work strictly in order of priority, stoping development when we've run out of time.

The differences between fan-out planning and traditional XP planning are:

• an emphasis on exploration, especially during the beginning of an iteration/release
• top-down scheduling
• an explicit allowance for functional debt until the end of the release. (Functional debt, for example, is present in a new file editor that allows us to create and save documents, but not yet load them. We could address creating and saving first because the team identified these functions as the most risky, and identified a fail-safe plan of using a plain-text editor to display the files if we don't get a chance to work on loading/rendering issues. This gives us more time to focus on the core value provided by our editor, for example, auto-completion.)
• an emphasis on slack time, both creative and buffer slack

We use fan-out planning at an iteration level for cards that we can't readily estimate (because the solution or need is vague). Instead of doing pre-work on a card in an iteration before a story has been slated, we'll schedule it without an estimate, and let the team say what is feasible during the week. What does this do to a week's commitment? It makes it more fluid--people do the work that they can. The goal is to find the essence--the core value of a card--and do something that will yield feedback (validated learning). Normally an un-estimated card only produces a spike or more cards with estimates, but if the developers who took it find the work easy and relatively small (less than a day), they'll often move it to Done-Done. In any case, we have something to show for the work, that can be validated with a client, and we've left the production code in a healthy state (often by using options that hide new features).

Why Change the Planning Game?

Traditional XP release planning leaves little room for slack, and as a result, I think it doesn't get as creative. We also see cycle-time waste when we're doing analysis for story cards that aren't going to be picked for an iteration or more. So instead of nailing things down enough for estimation, we just 'take it offline' and talk when the card has been picked. This can be risky, because bottom-up scheduling and estimation protect a team's sustainable pace. We counter-balance this risk with adequate slack.

Another benefit of fan-out planning, counter-intuitive as it may be, is the increased predictability it gives us. It may be a bit premature to say it, but we've been doing fan-out planning for about 15 iterations, including one major release, and we find we are more capable of responding to changes in the market place, more capable of finishing strategic plans, and more predictable. By always focusing on the absolute minimal feature set, we gave ourselves enough slack to become predictable.

When we're beginning a new release, we need to provide some visibility to our marketing, sales, and support teams about what's coming with the next version of the product (we make internal releases each one-week iteration, and sometimes deploy those intermediate deliverables to a new client, but most existing clients only upgrade our product every 3-12 months). There's a lot of risk involved in promising a fixed scope with a fixed delivery date--so instead we commit to a delivery date and a vague set of release goals/epics/themes. By using fan-out planning, we attack several candidate solutions, show them to our stakeholders, and wait until later in the release plan to commit to a particular solution.

Does this sound familiar?

Fan-out release planning is, as far as I know, unique to my team (but inspired by XP, Scrum, and Lean ideas)--and I'd be happy to hear about other teams that are doing something similar, or about any resources/books that describe it, or of any concerns you might have about the process!