Adaptive Planning

Audience

Product Managers, Customers

We plan for success.

Imagine you’ve been freed from the shackles of predetermined plans. “Maximize our return on investment,” your boss says. “We’ve already talked about the purpose of this team. I’m counting on you to work out the details. Create your own plans and set your own release dates—just make sure we get good value.”

Now what?

Valuable Increments

Build your plans out of valuable increments.

Build your plans out of valuable increments.¹ Valuable increments have three characteristics:

¹In the first edition of this book, instead of “valuable increment,” I used the term “Minimum Marketable Feature” (MMF) from [Denne2004]. Valuable increments are the same idea, but I’ve changed the name because not everything that’s valuable is marketable, or a feature.

1. Releasable. When you finish working on the increment, you can release it and reap its benefits, even if you never work on it again.

2. Valuable. The increment benefits your organization in some way. (See the “What Do Organizations Value” sidebar.)

3. Incremental. It doesn’t do everything. It’s one step in the right direction.

Don’t confuse “valuable increments” with “potentially shippable increments,” another common term in the Agile community. Potentially shippable increments are about a team’s technical ability to release changes. Valuable increments are about changes that actually make an appreciable difference to your business.

Ally

Continuous Deployment

Similarly, a valuable increment is “released” only when you can achieve its value. Teams using continuous deployment will deploy their software multiple times per day, but it isn’t released until a configuration switch is flipped and the increment is available to its intended audience.

Valuable increments generally fall into these categories:

• Direct Value. You build something, change something, or fix something that has value. It’s “released” when your organization can reap the benefit. For example, if you think you can improve customer retention by adding a new report, you’ve released the report when real customers can run it.

• Learning Value. You conduct an experiment that gives you insight into how to increase value. It’s “released” when the experiment is ready to run, including decisions about how to interpret the results. For example, if you think you can increase customer sign-ups by changing your sign-up flow, but you’re not sure which flow is best, you might create an A/B test.² The experiment has been released when the A/B test is active, the point at which the data will be evaluated has been decided, and the criteria for keeping or discarding the new flow has been determined.

• Option Value. You create the ability to postpone or change a decision, so that you can take advantage of a valuable opportunity in the future. It’s “released” when you can safely postpone or change the decision. For example, if you think a vendor is trying to create lock-in so they can raise their prices, you might modify your software to also support a second vendor. The option has been released when you can switch between vendors at will.

²A/B testing is when you show different things to different groups of people and evaluate which one had the best results.

Learning and option increments require people to be comfortable with uncertainty and ambiguity, so they tend to be used by Optimizing teams. But any team can use them.

Allies

Stories

Visual Planning

Purpose

Incremental Requirements

You’ll track your increments with stories in your visual plan. For example, the previous examples might be written as “TPS Report,” “sign-up flow A/B test,” and “authentication vendor independence.” If you want to keep more detailed notes, you can, but for most product managers I meet, a short phrase is enough of a reminder. You need to be able to articulate three things:

1. Why the increment is valuable

2. How the value relates to the team’s purpose

3. What “released” looks like, at a high level

The details are decided later, as I’ll discuss in the “How to Create Your Plan” section.

Focus on One Increment at a Time

Focusing on one increment at a time will improve delivery speed and increase value.

Stakeholders love it when teams work on multiple ideas simultaneously. It feels like a lot of work is being done, and everything gets to be top priority! So easy. And so very, very wasteful. Focusing on one increment at a time will improve delivery speed and increase value.

Consider a team that has three valuable increments, as shown in the “Effects of Focusing on Value” figure. In this simplified example, each increment has equal value: when complete, each will yield $4 in value every month. Each increment takes two months to complete.

Figure 1. Effects of focusing on value

In Scenario A, the team works on all three increments simultaneously. It takes them six months to finish all three. When they’re done, they start collecting $12 every month.

In Scenario B, the team focuses on one increment at a time. They release their first increment after two months—one-third the time of Scenario A. It starts earning money while they work on the next increment. By the end of the seventh month, they’ve earned $36 in the time it took Scenario A to earn $12. And that’s ignoring the costs of task switching and the benefits of getting to market sooner. It’s free money.

The more frequently you release, the more value you get.

The more frequently you release, the more you get, as Scenario C shows. It’s the same as Scenario B, except that the team has figured out how to slice each of their increments in half. Instead of releasing a $4 increment in two months, they release a $2 increment in one month. After seven months, they’ve earned $42.

Of course, some ideas are more valuable than others. Scenario D shows what happens when you split the most valuable parts out and work on them first. This scenario is the same as Scenario C, but the increments are worth different amounts. Reordering increments to release the most valuable ones first allows Scenario D to earn $50. Three months of free money relative to Scenario A.

This is the essence of Focusing fluency. Focus on small, valuable increments. Focus on releasing one at a time. Focus on the most valuable ideas first. After each release, take advantage of any new information you’ve learned, adapt your plans, and Focus on the highest value that remains.

The scenarios in the “Effects of Focusing on Value” figure are simplified. Software By Numbers [Denne2004] (ch. 2) has a more sophisticated example based on a real product, shown in the “Realistic Example of Focusing on Value” table. In their example, the authors convert a five-year project with two end-of-project releases (Scenario A) into five yearly releases ordered by value (Scenario B). The team’s productivity was the same in each scenario.

Table 1. Realistic example of focusing on value

	Scenario A	Scenario B
Total Cost	$4.312 million	$4.712 million
Revenue	$5.600 million	$7.800 million
Investment	$2.760 million	$1.640 million
Payback	$1.288 million	$3.088 million
Net Present Value @ 10%	$0.194 million	$1.594 million
Internal Rate of Return	12.8%	36.3%

Scenario A is a marginal investment with a 12.8% rate of return. It requires an investment of $2.8 million and yields profits of $1.3 million. Considering the risk of software development, the investors can put that money to better use elsewhere.

Scenario B—the same product released more often—is an excellent investment with a 36.3% rate of return. Although Scenario B costs more, because it conducts more releases, those releases allow the product to be self-funding. As a result, it requires a smaller investment—$1.6 million—and yields profits of $3.1 million. This scenario is well worth funding.

Look at these examples again. Each shows impressive increases in value. Yet nothing changes except the way the teams release their software.

Slice Your Increments

As the examples showed, the more finely you can slice your increments, the more value you can extract from your team’s work. Beyond that, though, each increment represents an opportunity to change direction without incurring waste. If you change direction in the middle of working on a increment, you’re left with partially completed work you either have to set aside or throw away. Once an increment is done, you can change direction without wasting any work.

The smaller your increments, the more agile you can be.

The smaller your increments, the more frequently you can adapt your plans, and the more agile you can be. In a perfect world, your increments should be broken down to the smallest fundamental pieces that can still have releasable value.

In reality, it’s hard to make your increments that small, especially at first. As time passes, you’re likely to see ways to split your increments further. It’s okay to start with your best guess and split them later. Agile’s iterative. You’ll have plenty of opportunities to improve your increments.

Key Idea: Minimize Work in Progress

Work in progress (WIP) is work that’s been started, but hasn’t yet released. Agile teams try to minimize WIP for several reasons. First, it’s an investment awaiting return. As the “Effects of Focusing on Value” figure shows, the more frequently you release—the less WIP you have—the better the return on your work investment.

Second, WIP makes changes more costly. When you change your plans, any work that isn’t done has to be set aside. As time goes on, the decisions that went into that work become outdated and have to be redone. Code for incomplete increments is particularly expensive: either it increases the size and cost of maintaining your production codebase, or it’s stored in a separate branch where it becomes increasingly difficult to merge back into production.

Metaphorically, WIP rusts away. It either has to be maintained, reworked, or thrown away, and that’s wasteful. Keep it to a minimum.

Release Early, Release Often

Ally

Continuous Deployment

You can release a valuable increment as soon as it’s finished, or you can wait to bundle multiple increments together into a single release. Although releasing immediately has the highest value, sometimes it can be more effective to market multiple increments together rather than dribbling them out one at a time. Similarly, if there are UI changes or other release-related costs, it can be easier to absorb those costs all at once rather than continuously making small changes.

Some teams use continuous deployment to deploy their code multiple times per day, but deploying code isn’t the same as releasing an increment. An increment isn’t “released” until it’s available to be used. For teams using continuous deployment, “releasing” usually involves changing a configuration setting.

Sometimes teams bundle increments together because technical constraints make frequent releases too costly. It’s okay to do this, if you must, but be honest with yourself about the reasons. In addition to high release costs, you’re also incurring the costs of increased work in progress. You can eliminate both costs by investing in Delivering fluency.

The release train always leaves on time.

Some teams use release trains to schedule their releases. A release train is a pre-scheduled series of releases, such as the first Monday of every month. Finished increments “get on the train” and are included in that release. The rest wait for the next train. It doesn’t matter how close they are to being done; the train always leaves on time.

The Scaled Agile Framework (SAFe) defines an “Agile Release Train” as a container for teams, which is an unfortunate redefinition of the term.³ Here, I’m using the simpler, original meaning. A release train is just a predefined release schedule. Don’t overthink it.

³The term “release train” dates to well before SAFe. The earliest reference I’m aware of is Sun’s Software Development Framework from 1993, which defined the term in the same way I do here. That document isn’t publicly available, but [Rothman1998] references the term and uses a similar definition. Many thanks to Howard Fear and Dave Hounslow for digging up these references.

Release trains have a lot of benefits. They give marketers an event to celebrate. They give users a date to anticipate. They give stakeholders certainty about when they can expect progress, and they take pressure off teams, who—as long as their increments are smaller than the release cycle—can commit to release dates without worrying about exactly what they’ll release on each date.

On the other hand, a decision to delay an increment, either by bundling it into a one-off release or using a release train, is a decision to delay value. Organizations also tend to use release trains to paper over technical and organizational deficiencies that prevent more frequent releases. When you think about your release strategy, trade off the benefits of bundling increments into releases with the cost of delaying their value, and be honest with yourself about your reasons for delaying.

Cargo Cult: The Cattle Car

“The next release train leaves in three months!” Your release manager, Ezekiel, has called a meeting of all the product owners. “What are you committing to deliver?”

You exchange a glance with Lavona, one of the other product owners, who mimes cracking a whip. You stifle a grin, then put on your best “team player” face as Ezekiel turns his attention to you.

You got your team to estimate and commit to features last week, but they’re getting more sullen about it every quarter. “Hashtag no estimates,” your best developer, Rose, said afterward, right before handing in her notice. You share their commitment with Ezekiel, but you dread what the next three months are going to be like.

As you trudge out of the meeting, Lavona falls into step beside you, letting out a soft “Moooo.” “You know the cows on the train are going to the slaughterhouse, right?” she says. You shake your head and sigh. “I know who’s going to take the blame if we don’t deliver.”

Lavona stops and looks you in the eye. “I’ve been doing some research,” she says. “Agile isn’t supposed to be like this. We’re not supposed to be cracking the whip on our teams, then taking the blame when things go wrong.”

“Sure,” you say. “Rose says we’re doing iterated waterfall, not Agile. But what can we do?”

Lavona smiles. “Here? Not much. But I’ve been recruited, and they want me to bring another good product manager with me. You in?”

She shares the details, and your mood lifts. It’s time to get off this train.

Your First Increment

Your first increment can be tricky. It needs enough content to be interesting, but not so much that you delay your release.

One way to think about your first increment is to think in terms of a minimum viable product (MVP). Contrary to the common understanding of this term, an MVP isn’t the smallest product you can successfully release. Instead, it’s a way of validating your product ideas. Eric Ries defined the term in his influential book, The Lean Startup:

A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.

Contrary to traditional product development, which usually involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses. [Ries2011] (ch. 6)

Eric Ries

An MVP isn’t necessarily a release, or even a product, in the traditional sense. It’s an experiment, and you can have more than one. As such, true MVPs are most often used by Optimizing teams.

Whether your first increment is an MVP in Eric Ries’s sense of the word, or just the smallest increment that buyers and users will love, is up to you.

An Example Increment

In 2005, a small team launched Writely, an online word processing application. Then, as now, the market for word processors was quite mature, so creating a small first increment might seem impossible. There’s so much to do just to match the competition, let alone to provide something new and compelling. You need basic formatting, spellchecking, grammar checking, tables, images, printing...the list goes on forever.

Rather than trying to match the competition, Writely focused on features that would set it apart: collaboration, remote document editing, secure online storage, and ease of use. They built just the minimum necessary to prove out their concept. According to venture capitalist Peter Rip, the developers released the first alpha of Writely two weeks after they decided to create it.⁴

⁴Sources: Writely’s website and Peter Rip’s blog. The pages no longer appear to be online, but they can be found in the Internet Archive: Writely’s home page, “Writely is the seed of a Big Idea”, “Writely—The Back Story”.

Of course, you’ve probably never heard of Writely. Did the incremental approach fail? Not at all. Eight months after Writely’s launch, the company was acquired. It’s now known as Google Docs.

Adapt Your Plans

You’ll think of your first increments before a single line of code is written. This is when you know the least about what will make the software valuable. You might know a lot, but you’ll always know more after you talk with stakeholders, show them demos, and conduct actual releases. Over time, you’ll discover that some of your initial ideas about value were incorrect. If you change your plan to reflect what you’ve learned—if you adapt—you’ll create a more valuable result.

Think of your plan as a plan for learning as much as it is a plan for building.

To increase the value of your software, create opportunities to learn. Think of your plan as a plan for learning as much as it is a plan for building. Focus on what you don’t know. What are you uncertain about? What might be a good idea? Which good ideas can you prove in practice? Don’t just speculate—create increments for learning. Test each uncertainty, then adapt your plan.

For example, if you were creating an online word processor, you might not be sure how extensive your support for importing Microsoft Word documents should be. Some sort of support is necessary, but how much? Supporting all possible Word documents would take a long time to implement. It would take time away from adding other, possibly more valuable features. Too little support could damage your credibility and cause you to lose customers.

To test this uncertainty, you could add a rudimentary import feature to your software (clearly marked “experimental”), release it, and have it report the types of documents real users try to import. The information you gather will help you adapt your plan and increase your team’s value.

Users of web-based software are used to “beta” web applications, so releasing an experimental, incomplete feature is possible in that context. A product with less forgiving users may require the use of a pre-release program, focus groups, or some other feedback mechanism.

Key Idea: The Last Responsible Moment

Agile teams delay decisions until the last responsible moment.⁵ Making decisions at the last responsible moment decreases your costs and increases your agility.

⁵The Lean Construction Institute coined the term “last responsible moment.” [Poppendieck2003] popularized it in relation to software development.

Imagine you’re an evil despot on a tight schedule. You promised your emperor that you’ll put his new toy for blowing up planets back on schedule. Now you’re stuck. There were complications you didn’t foresee. To save face, you tell the emperor that his battlestation is fully armed and operational, even though it’s not quite done yet. Next thing you know, a plucky band of photogenic youngsters is destroying your Death Star. Again.

The earlier you make a decision, the more likely you are to miss something important. If you do, you either have to redo your work or put up with a bad decision. That’s wasteful. By waiting until the last responsible moment, you maximize your information, which leads to better decisions, which leads to less waste. Changes are easier, too, because you’ll have less work to undo.

Note that the phrase is last responsible moment, not last possible moment. As [Poppendieck2003] says, make decisions at “the moment at which failing to make a decision eliminates an important alternative. If commitments are delayed beyond the last responsible moment, then decisions are made by default, which is generally not a good approach to making decisions.”

How to Create Your Plan

Valuable increments are the building blocks of your plan, but they don’t have any details. Those details take a lot of time and work. Worse, when you adapt your plans, some of that work could be thrown away.

To reduce waste and make planning easier, use rolling-wave planning to plan at the last responsible moment. In rolling-wave planning, detail is added gradually, just before it’s needed.

Allies

Purpose

Visual Planning

The Planning Game

Task Planning

Incremental Requirements

The distance each level of detail looks into the future is called its planning horizon. An Agile plan has multiple planning horizons, as illustrated in the “Planning Horizons” figure:

1. Start with the purpose for the team, which will include the team’s mission.

2. Use visual planning to create a map of possible valuable increments for achieving the mission.

3. Continue using visual planning to break the first few increments into the smallest valuable increments you can think of.

4. Use the planning game to break the first small increments down even further, into stories that are sized “just right.”

5. Use task planning to break the first few stories into development tasks.

6. Just prior to starting development on a story, use incremental requirements to determine requirements details.

Figure 2. Planning horizons

The “Your First Week” section describes how to get started. Once the plan is in place, you’ll use a pull system to maintain it. In a pull system, rather than doing work at predefined intervals, you do work in response to demand. In this case, the “pull” comes from finishing tasks.

1. When your team finishes its tasks, you’ll need more tasks. You’ll use task planning to pull stories out of the visual plan and onto your task board, where you’ll break them into tasks.

2. This could lead you to needing more stories. When you do, you’ll schedule a planning game session and pull stories out of your next small, valuable increment.

3. When you finish an increment, you’ll use visual planning to pull a new small increment out of your possible increments.

4. And when you need more ideas for possible increments, you’ll pull them out of your purpose and mission.

5. And finally, when you’re close to completing your mission, you’ll go back to your sponsor and pull a new mission out of your team vision and purpose.

Different skills are needed for each level of detail, as the “Planning Skills” figure shows.

Figure 3. Planning skills

An Example Plan

Imagine your team is responsible for an online shopping site. How would rolling-wave planning work for you? Here’s a simplified example that shows how the levels of detail fit together.

1. Purpose. Your team’s overall vision is to be the leading seller in your market niche. Your specific mission is to improve conversion rates: to have more people who visit the site actually buy something.

2. Possible valuable increments. To accomplish this mission, you think of several possible valuable increments. One idea is to make the site work better on mobile devices. Another is to improve the check-out page. A third is to improve search. A fourth is to provide curated product reviews.

3. Smallest valuable increments. After discussing the ideas with various stakeholders, you decide that an enhanced check-out page will have the best bang for the buck. A lot of customers abandon the site when they reach the check-out page. You come up with the smallest valuable increments you can think of: supporting gift cards, remembering people’s credit cards, adding support for coupons, adding support for PayPal, and so forth.

4. “Just right” stories. According to your market research, customers in Europe are less comfortable using credit cards online, and when you look at your stats, it’s Europeans who have the highest rate of abandoned shopping cards. You decide that supporting PayPal will be your next increment. You get the whole team together to split it down further. Together, you come up with more detailed stories, including “embed PayPal into check-out page,” “allow PayPal for subscription products,” “handle PayPal errors,” “handle PayPal outage,” “refund PayPal charge,” and “customer support interface for PayPal charges.”

5. Tasks. During task planning, you choose several stories for the team to work on first and developers break them into tasks. “Customer support interface for PayPal charges” gets tasks such as “migrate CS UI to current version of frontend framework,” “add PayPal to CS frontend,” and “add PayPal to CS backend.”

6. Details. While developers are laying their groundwork, the team’s UX designer creates a mock-up showing the potential revisions to the support UI and reviews it with the customer support department. When it’s ready, the developers use the mock-up to guide their changes, then review the finished result with the other on-site customers and the CS department.

Balancing Adaptability and Predictability

Each level of detail in your plan has an associated planning horizon. For example, the “Planning Horizons” figure shows that tasks are planned for the next week; stories are planned for the next month; small increments are planned for the next three months; and possible increments are planned for the next six months.

Choose your planning horizons based on how you want to trade off adaptability and predictability.

Those horizons are just an example. You should choose your own planning horizons based on how you want to trade off adaptability and predictability. For example, if your plans change a lot, you might create “just right” stories only two weeks in advance and small increments just a month in advance. On the other hand, if your stakeholders need a lot of certainty, you could create “just right” stories three months in advance and small increments six months in advance.

Allies

Roadmaps

Forecasting

The longer your planning horizons, the more work you’ll throw away when your plan changes, and the more people will resist making changes. On the other hand, longer planning horizons are often needed for good roadmaps, and your story planning horizon determines how far into the future your release forecasts can see.

Ultimately, the choice of planning horizons is a trade-off between less waste and greater agility (shorter planning horizons) and more certainty and predictability (longer planning horizons). There’s no wrong answer; just a choice between trade-offs. If you aren’t sure what to choose, start with the horizons shown in the “Planning Horizons” figure.

Adaptive Planning in Action

A few years after we got married, my wife and I took a two-month vacation in Europe. It was easily the most complicated trip we’d taken. We knew we couldn’t plan it all in advance, so we took an adaptive approach.

We started with our vision for the trip: we agreed to visit a wide variety cities instead of staying in one place. We discussed the countries we wanted to see, but we didn’t make any decisions that would commit us to visiting a particular set.

We identified the last responsible moment for various decisions in our trip. Airline tickets generally get more expensive over time, so we booked our flights in and out of London months in advance, and made plans to stay with relatives there at the beginning and end of our trip. Hotels, however, only need a few days’ notice.

We also took steps that would give us more options. We found a good guidebook that covered all of Europe. We purchased a EuroRail pass, which allowed us to use Europe’s excellent rail system to travel throughout the continent. We paid extra for a pass that would allow us to visit more countries.

With these general decisions made, we left the details for the last responsible moment. While on the trip, a few days before leaving for our next destination, we decided which country and city to visit next. We stopped by the train station, looked up departure times, and made reservations when necessary. We looked up hotels in our guidebook and emailed the three most promising, then went back to enjoying the city.

The next day, we confirmed one of the hotel reservations. On the last day, we lazed about and picked a time to leave from our list of train departure times. We would arrive in the new city four or five hours later, drop off our belongings at the hotel, and go explore.

This approach not only gave us flexibility, it was easy and relaxing. Because we made our reservations a day or two in advance, no hotel ever lost or confused our reservations. If we found that we particularly enjoyed a city, we stayed longer. If we didn’t like it, we left early. On our honeymoon, we had been slaves to a pre-planned itinerary, fretting over details for the entire trip. On this much longer and more complicated trip, we only had to think about the details for our next few days.

The flexibility also allowed us to experience things that we never would have otherwise. In Italy, we discovered that our intention to go to Turkey would eat up a huge amount of time in travel. We exploited our EuroRail passes and went to northern Europe instead. We ended up having some of our most memorable experiences in cities we had never expected to visit.

By creating a rough plan in advance, keeping our options open, and making detailed decisions at the last responsible moment, we had a much better vacation than we would have had otherwise. Similarly, when you use adaptive planning in software development, unpredictable opportunities arise that allow you to increase the value of your software.

Adaptive Planning and Organizational Culture

Does the idea of spending two months traveling in a foreign country without a detailed plan sound scary? In practice, it was easy and relaxing, but when I tell the story of our adaptively planned trip to Europe (see the “Adaptive Planning in Action” sidebar), people get nervous.

Organizations often have a similar reaction to adaptive planning. An adaptive plan works to achieve the team’s purpose. However, just as the trip my wife and I took achieved its purpose—“have fun visiting a lot of European cities”—without choosing specific cities in advance, an adaptive team will achieve its purpose even though it won’t be able to say exactly what it will deliver.

No aspect of Agile challenges organizational culture more than adaptive planning.

No aspect of Agile challenges organizational culture more than adaptive planning. It requires changes not only to the development team, but also to reporting, evaluation, and governance. The choice of adaptive planning extends to surprisingly diverse parts of your stakeholder community, and people often have a shocked or emotional reaction to the idea.

As a result, you may not be able to influence a change to adaptive planning. Unless you have the support of senior leadership, any change that does occur will probably be slow and gradual. Even with leadership support, this change can take time.

Ally

Forecasting

Work within your organization’s culture to introduce adaptive planning gradually. Use rolling-wave planning, but set your planning horizons to match the organization’s expectations. You may need to make forecasts as well, which typically requires Delivering fluency. As your stakeholders gain trust in your ability to deliver, shorten your planning horizons and migrate toward a more adaptive plan.

Questions

We need to commit to specific release dates. What should we do?

See the “Forecasting” practice. If you use date and scope forecasts, you may need to increase your planning horizons, and you’ll typically need Delivering fluency for your forecasts to be useful.

If we don’t plan our releases in detail, what should we tell our stakeholders about our plans?

Although you may not plan out all the details of your releases in advance, you’ll still be able to share a roadmap with stakeholders. If they need a lot of detail, you might need to increase your planning horizons. See the “Roadmaps” practice.

If we use short planning horizons, how can we be sure we’ll fulfill our team’s purpose?

If you’re not sure you can meet your purpose, focus your plan on discovering whether you can. You may need to create increments for learning, increase your planning horizons, or create a small, limited-availability release to test crucial concepts. The details depend on your situation, so if you’re not sure what to do, ask a mentor for guidance.

Prerequisites

Adaptive planning requires manager and stakeholder buy-in. (See the “Invest in Change” chapter.) Any team can plan in terms of valuable increments. Beyond that, it depends on how much buy-in you have.

Working on one increment at a time is a smart, easy way to increase your team’s value. Despite its usefulness, working on one thing at a time is anathema to some stakeholders. Proceed with caution.

Releasing frequently requires your customers and users to be able to accept frequent releases. This is a no-brainer for most web-based software, because users don’t have to do anything to get updates. Other types of software may require painful software rollouts, and some even require expensive certification testing. That can make frequent releases difficult.

Creating experiments, options, and MVPs requires that your organization accept uncertainty, and trust that your team has sufficient market expertise to make good decisions. This often requires your team to have Optimizing fluency.

Rolling-wave planning requires a clear purpose and regular updates to the plan. Use it when you can reliably revisit the plan at least once per week. Be sure your team includes people who have the skills to update and revise the plan.

Adapting your plans requires that your organization think of success in terms of value rather than “delivered on time, on budget, and as specified.” This can be a tough idea for some organizations to swallow. You may be able to assuage fears about adapting plans by committing to a specific release date but leaving the details of the release unspecified.

Finally, be cautious of plans without a release in the next three months. Although those release goals shouldn’t be treated as commitments, it’s easy to wander off course without the checkpoint and urgency of a near-term goal.

Indicators

When you create, maintain, and communicate a good plan:

• The plan shows how the team will achieve its purpose, or learn how to achieve it.

• Team members are confident the plan is achievable.

• You release value regularly and consistently.

When you adapt your plan well:

• You consistently seek out opportunities to learn new things about your plan, your product, and your stakeholders.

• As you learn, you modify your plan to take advantage of new insights.

Alternatives and Experiments

Adaptive planning increases value by being flexible in planning and strategic in releases. Look for opportunities to reduce time spent on plans that are discarded, quicken the feedback loop, improve your plans more often, and shorten time to value.

Ally

Incremental Design

If you don’t have a Delivering team, you might run into questions about how to plan for technical infrastructure. [Denne2004] provides a sophisticated Incremental Funding Methodology that addresses that question. Teams with Delivering fluency sidestep this need, because they use evolutionary design to build their technical infrastructure incrementally.

Teams with an established product don’t always need a sophisticated plan. Rather than thinking in terms of increments or releases, these teams work from a small list of stories and constantly release minor changes. You can think of this as an adaptive plan with very short planning horizons.

Finally, adaptive planning is often seen as an alternative to predictive planning, but as the “Balancing Adaptability and Predictability” section shows, it’s more of a spectrum of different planning horizons. If you’re in an environment that needs predictive planning, see how many adaptive ideas you can use along with your longer planning horizons.

Further Reading

Software By Numbers [Denne2004] provides a compelling and detailed case for conducting frequent releases.

Lean Software Development [Poppendieck2003] discusses postponing decisions and keeping your options open in Chapter 3.

The Principles of Product Development Flow [Reinertson2009] digs deep into principles behind adaptive planning. Although it’s geared towards physical products rather than software, it’s still well worth reading.