AoAD2 Practice: Adaptive Planning

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Adaptive Planning

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 a good return on our investment.”

Now what?

Shippable Increments of Value

Shippable Increments of Value (SIVs) are the building blocks of your plan.1 Each one represents concrete, valuable progress. SIVs have three parts:

1In the first edition of this book, I used the term “Minimum Marketable Feature” (MMF) instead of SIV. The term came from [Denne and Cleland-Huang 2004]. SIVs are the same idea, but I’ve changed the name because not everything that’s valuable is marketable.

  1. Shippable. When you finish working on the SIV, you can release it and reap its benefits.

  2. Increment. The SIV doesn’t try to do everything. It’s just one step in the right direction.

  3. Of Value. The SIV brings value to your organization in some way.

As the “What Do Organizations Value” sidebar discusses, there are many ways to provide value, from improving revenue, to reducing risk, to gathering information. Your SIVs will generally fall into these categories:

  • Features. Features are “shipped” when their target audience can use them. For example, if you create a new report for customers, the feature has shipped when real customers are able to run the report.

  • Experiments. Experiments are “shipped” when you’ve created the ability to make an informed decision. For example, if you want to decide whether to change your sign-up flow, you might create an A/B test.2 The experiment has shipped 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.

  • Options. Options are “shipped” when you’ve gained the ability to postpone a decision. For example, rather than committing to a particular vendor, you might modify your software to also support a second vendor. The option has shipped when you can switch between the vendors at will.

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

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

Another way to think about SIVs is to ask yourself what would happen if the team shipped the SIV, then changed direction and never developed it further. Would it still provide value? If so, it’s a SIV. If not, it’s missing the value part.

For every SIV, you should be able to articulate three things:

  1. Why it’s valuable

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

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

Incremental Requirements
Visual Planning

The details come later. You’ll track your SIVs with a short phrase on a card in your visual plan, such as “TPS Report,” “sign-up flow A/B test,” or “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.

If you’re wondering how SIVs and other requirements are documented and communicated, see the “Incremental Requirements” practice.

Focus on One SIV at a Time

Stakeholders love it when teams work on multiple SIVs 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 SIV at a time will improve your delivery speed and increase your value.

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

Four scenarios. Scenario A shows a team working on three SIVs simultaneously over six months. They earn $4 for each one in the seventh month for a total value of $12. Scenario B shows a team focusing on one SIV at a time. They work on SIV 1 in months 1-2 and it earns $4 in months 3-7. They work on SIV 2 in months 3-4 and it earns $4 in months 5-7. They work on SIV 3 in months 5-6 and it earns $4 in month 7. After month 7, SIV 1 has earned $20, SIV 2 has earned $12, and SIV 3 has earned $4, for a total of $36. Scenario C is similar to Scenario B, but it has six SIVs earning $2 per month. After month 7, SIV 1a has earned $12, SIV 1b has earned $10, SIV 2a has earned $8, SIV 2b has earned $6, SIV 3a has earned $4, and SIV 3b has earned $2, for a total of $42. Scenario D is the same as Scenario C, except SIVs 1a and 1b earn $3 per month, SIVs 2a and 2b earn $2 per month, and SIVs 3a and 3b earn $1 per month. After month 7, SIV 1a has earned $18, SIV 1b has earned $15, SIV 2a has earned $8, SIV 2b has earned $6, SIV 3a has earned $2, and SIV 3b has earned $1, for a total of $50.

Figure 1. Effects of focusing on value

In Scenario A, the team works on all three SIVs 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 works on one SIV at a time. They ship SIV #1 after two months—one-third the time of scenario A. It starts earning $4 every month while they switch to SIV #2. It ships after the fourth month—still faster than scenario A—and also starts earning $4 per month. Finally, after the sixth months, they finish SIV #3. 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 ship, the more you get, as Scenario C shows. It’s the same as Scenario B, except that the team has sliced their SIVs more finely. Instead of shipping a $4 SIV in two months, they ship a $2 SIVs in one month. After seven months, they’ve earned $42.

Of course, your SIVs don’t have equal value. Scenario D shows what happens when you ship your most valuable SIVs first. This scenario is the same as Scenario C, in that each SIV still takes one month to complete, but they’re worth different amounts. The total value is unchanged—$12 per month—but Scenario D earns $50 in the time it takes Scenario A to earn $12.

This is the essence of Focusing fluency. Focus on small, shippable increments of value. Focus on shipping one at a time. Focus on the one that’s most valuable. As each one ships, take advantage of any new information you’ve obtained, adapt your plans, and Focus on the highest value that remains.

The scenarios in the “Effects of Focusing On Value” figure are necessarily simplified. Software By Numbers [Denne and Cleland-Huang 2004] (pp. 19-24) 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 AScenario 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 Return12.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. The project should not be funded.

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 $1.6 million investment and yields profits of $3.1 million. This project 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.

Sieve Your SIVs

As the previous scenarios show, the more finely you can slice your SIVs, the more value you can extract from your team’s work. Beyond that, though, each SIV represents an opportunity to change direction without incurring waste. If you change direction in the middle of working on a SIV, you’re left with partially-completed work you either have to set aside or throw away. (See “Key Idea: Minimize Work in Progress”.) Once a SIV is done, you can change direction without wasting any work.

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

In reality, it’s hard to make your SIVs that small, especially at first. As you go into more detail, you’re likely to see ways to split your SIVs 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 SIVs.

Release Early, Release Often

SIVs are actually shippable. Each SIV can be released on its own. Some people in the Agile community talk about “potentially shippable increments,” which have the technical capability to be shipped, but don’t necessarily have enough value to actually ship. That’s different than a SIV. If a SIV doesn’t have enough value to ship on its own, then it doesn’t qualify to be a SIV.

You can release (ship) each SIV as soon as it’s finished, or you can wait and bundle multiple SIVs together into a single release. Although bundling SIVs into a release delays their value, sometimes it can be more effective to market multiple SIVs together rather than dribbling them out one at a time. Similarly, if there are user interface changes or other release-related costs, it can be easier to absorb those costs all at once rather than continuously making small changes.

Continuous Deployment
Feature Toggles

Delivering teams that use continuous deployment release their code multiple times per day. However, they also techniques such as feature toggles to hide features from users. For these teams, “releasing” a SIV means changing a configuration setting to make the SIV available.

Sometimes teams bundle SIVs together because technical constraints make it too costly to release more frequently. It’s okay to do this, but if you do, be honest with yourself about the reasons. In addition to high release costs, you’re also incurring the costs of increased WIP. (See “Key Idea: Minimize Work in Progress”.) You can eliminate both costs by investing in Delivering fluency.

Some teams use release trains to schedule their releases. A release train is a pre-scheduled series of releases—for example, the first day of every month, or the beginning of every quarter. Any SIVs that are done “get on the train” and are shipped 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.3 Here, I’m using the simpler, original meaning. A release train is just a predefined release schedule. Don’t overthink it.

3The term 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 publically available, but a 1998 conference paper by Johanna Rothman [Rothman 1998] 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—so long as their SIVs are smaller than the release cycle—can commit to release dates without worrying about exactly what they’ll ship on each date.

On the other hand, a decision to delay a SIV, 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 SIVs into releases with the cost of delaying their value, and be honest with yourself about your reasons for delaying.

Your First Release

The first release can be tricky. It needs enough SIVs to be interesting, but not so many that you delay your release and the associated value.

One way to think about your first release 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 ship. 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. [Ries 2011] (pp. 95-96)

Eric Ries


An MVP isn’t necessarily a release, or even a product, in the traditional sense of the terms. 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 release is an MVP in Eric Ries’ sense of the word, or just the smallest release that customers and users will love, is up to you.

Visual Planning
The Planning Game

Adapt Your Plans

You’ll form your initial ideas about SIVs and releases 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. No plan is perfect, but if you change your plan to reflect what you’ve learned—if you adapt—you create more value.

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 SIVs for experiments. Include a way of testing each uncertainty.

For example, if you were creating a collaborative 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 create a report on the capabilities needed to support the types of documents that 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.

Divide SIVs into Stories

The Planning Game

As you’ll see when we look at the planning game, your team should make tangible forward progress multiple times per week. It reduces risk, gives you the ability to share progress with stakeholders, and allows you to collect feedback. Ideally, that progress comes in the form of completed SIVs. The reality, though, is that most SIVs are too large, at least at first.


So instead, Agile has the idea of the “story.” A story is an increment of value, like a SIV, but it isn’t necessarily shippable. It makes progress towards something valuable, and stakeholders recognize that value, but it doesn’t always have enough value to be released on its own.

In a perfect world, every story is a SIV, and vice-versa. But there are two different goals here: First, you need to be able to show progress in small pieces. Second, you need each piece you release to be truly valuable and shippable. Sometimes you can meet both goals at once. But when you can’t, use small stories to incrementally show progress, and larger SIVs to plan releases.

Some people talk about “epics” as a way of grouping stories. (An epic is a big story. Get it?) I use SIVs instead, because “big” isn’t the important part. SIVs stay focused on what matters: they’re shippable; they’re incremental; they’re valuable.

How to Create Your Plan

It takes a lot of time and effort to come up with SIVs, break them into stories, size them, and prioritize them. If you’re adapting your plans as you go, some of that effort will be wasted when your plans change.

Incremental Requirements

To reduce waste, use rolling-wave planning to plan at the last responsible moment (see “Key Idea: The Last Responsible Moment”). In rolling-wave planning, only work that you’re about to do is planned in detail. Work that’s going to be done later is planned approximately. As work gets closer, the plans are refined and broken down into more detail.

A chart showing a funnel on its side. The wide end of the funnel is on the left, labelled “approximate, broad view,” and the narrow end is on the right, labelled “detailed, narrow view.” The funnel is divided into several regions. Each region is labelled, and the regions are separated by a dividing line with a time and the caption “time until work is done.” From left to right, the regions and dividing lines are: “purpose” (region), “six months” (divider), “high-level SIVs” (region), “three months” (divider), “small SIVs” (region), “one month“ (divider), “stories” (region), “one week“ (divider), “tasks and detailed requirements” (region), and “done“ (final divider).

Figure 2. Planning horizons

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:

Visual Planning
The Planning Game
Task Planning
Incremental Requirements
  1. Start with the purpose for the team.

  2. Use visual planning to create a map of high-level SIVs.

  3. Break the first few high-level SIVs down into the smallest possible SIVs.

  4. Use the planning game to break the first few small SIVs into stories.

  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 details.

As your team completes work, you’ll “pull” from the next level up. When you finish your tasks, you’ll use task planning to break the next stories into tasks. When you need more stories, you’ll use the planning game to break the next SIVs into stories. When you need more SIVs, you’ll use visual planning to refine your SIVs and create new ones. As you get close to finishing your SIVs, you’ll go back to your sponsor to create a new purpose.

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

This chart shows the same image as the “planning horizons” figure, except the funnel and regions are in the background. The names of several skills are overlaid on the funnel, with arrows showing which regions the skills apply to. From left to right, they are: “sponsor and key stakeholders,” which overlays the “purpose” and “high-level SIVs” regions; “product management,“ which overlays “purpose” (partially); “high-level SIVs,” “small SIVs,” and “stories” (partially); “domain expertise and UX design,” which overlays “high-level SIVs” (partially), “small SIVs,” “stories,” and “tasks and detailed requirements”; “business-focused testing,” which overlays “small SIVs (partially), “stories,” and “tasks and detailed requirements”; and finally “programming, operations, and technology-focused testing,” which overlays “small SIVs” (slightly), “stories,” and “tasks and detailed requirements.”

Figure 3. Planning skills

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 SIVs are planned for the next three months; and high-level SIVs are planned for the next six months.

Your planning horizons are a tradeoff between adaptability and predictability. For example, if you’re likely to change your plans, you might plan stories just two weeks in advance, and small SIVs just a month in advance. On the other hand, if your stakeholders need a lot of certainty, you could plan stories three months in advance, and small SIVs six months in advance.


The longer your planning horizons, the more work you’ll throw away when things change, and the more people will resist making changes. (People get attached to plans.) 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 tradeoff 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 tradeoffs. If you aren’t sure what to choose, start with the horizons shown in the “Planning Horizons” figure.

Adaptive Planning and Organizational Culture

Does the idea of spending two months travelling 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), some 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 their purpose even though they won’t be able to say exactly what they’ll deliver.

No aspect of Agile challenges organizational culture more than the transition to adaptive planning. It requires changes not only to the development team, but 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.


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 towards a more adaptive plan.


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

There’s no problem with defining a release date in advance. You won’t know exactly what will be in that release, but you can adjust your plans as you go to have at least one SIV ready to release on time.


If you need to plan for specific SIVs on a specific date, or predict when a SIV will be done, you can use the forecasting practice to do so. 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. At a minimum, you’ll be able to tell them which SIV you’re working on and what’s currently planned to come next. You may have a pre-planned release date, and, if you do, you can share that date with confidence, along with any SIVs that are finished and ready to be part of that release.

Planning at the last responsible moment means we can’t show exactly what we’ll deliver. Doesn’t that require too much trust from stakeholders?


Any development effort requires that stakeholders trust the team to do its job. In many organizations, though, that trust has been lost. If stakeholders require a detailed plan in order to trust you, use longer planning horizons that allow you to provide the plan they desire. Developing Delivering fluency can help, too, because that will allow you to use forecasts to make and meet commitments more reliably.

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 SIVs that are experiments, extend 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.

No matter your decision, clearly convey your concern to your business stakeholders, and let them know how you intend to address the uncertainty.


Adaptive planning requires manager and stakeholder buy-in (see the “Invest in Change” chapter). The one thing that any team can do is to plan in terms of SIVs and stories. From there, it depends on how much buy-in you have.

Working on one SIV 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 that your customers and users be able to accept more 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.

Whole Team

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 with product management and other customer skills who are responsible for maintaining 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 concrete goals in the next three months, such as a release or mission test (discussed in the “Purpose” practice). Although those goals shouldn’t be treated as commitments, it’s easy to wander off course without the checkpoint and urgency of a near-term goal.


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

  • The team and its stakeholders all know where the team is heading.

  • 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 ship 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.

  • Stakeholders and the team agree that each release is better than originally planned.

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.

Evolutionary Design

If you don’t have a Delivering team, you might run into questions about how to plan for technical infrastructure. [Denne and Cleland-Huang 2004] 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 SIVs or releases, these teams work from a small list of stories and constantly release minor changes. You can think of this is 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 really 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 [Denne and Cleland-Huang 2004] provides a compelling and detailed case for conducting frequent releases.

Agile Software Development Ecosystems [Highsmith 2002] has an excellent discussion of adaptive planning in Chapter 15.

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

XXX Consider Reinertson, The Principles of Product Development Flow: Second Generation Lean Product Development

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.