When some people hear the words "agile planning," they think it is an oxymoron. While more knowledgeable people think of agile planning as getting ready for one iteration of development, there is more to agile product planning than a single iteration. Although agile teams like to focus on one iteration at a time, what do we say when executive management asks questions like "What will this product actually do?" or “When will it be ready for the customer?" or "How much will it cost?" When the answer "You'll get it when you get it" just won't sell, you must perform high-level release planning to address these important questions. Stacia Broderick describes an agile release planning framework under which agile development can be effective. Stacia takes you through the complete process she recommends for release planning and explains, most importantly, why and how the agile release plan can and must remain just that-agile.

Agile practitioners are aware of the business benefits that can be derived from faster and more effective software delivery. At the same time, companies in many industries are facing increasing regulatory compliance issues. What do you do when you want to apply agile software development methodologies in an audited, validated industry? How do you get regulators, who want your software to work right and who have the force of the law behind them, to believe that it's all going to be OK using agile development? Eugene Levin describes the motivation for introducing an agile methodology framework to complement Citigroup's waterfall SDLC process, the challenges related to using a light-weight agile methodology in a regulated industry, the experience of defining Citigroup's Disciplined Agility process, and the lessons learned in piloting the company-wide adoption of agile development.

As agile software development methodologies take hold in the mainstream, organizations are finding that working with outside consultants poses a new set of challenges. In some instances, consulting organizations are able to work within an agile framework quite well. But in other situations, working with a consulting company can be more challenging than the project itself. Connecting outside consultants to your inside processes must be done. Consultants who are interested in, but not experienced with, agile will need an introduction and coaching. Consultants who aren't interested in changing their methodologies will need adaptive processes to match their approach with yours. Alicia Yanik describes how to work with vendors already under contract as well as how to contract with future vendors.

• Adopting an agile methodology after project inception
• Aligning consultant relationships with agile principles

In large organizations, it is simply not practical to just "flip a switch" and have your development department start doing full-on agile all at once. Newer agile teams and more traditional or waterfall teams find themselves having to work together during a long transition period or even permanently. Whether your agile-traditional project is dealing with waterfall-up-front (a project approval process), waterfall-at-end (separate system testing), or waterfall-in-tandem (products so complex that multiple teams work together to complete a release), Michele Sliger presents techniques she has used to make coexisting less painful and more productive. Find out the specific points in the project where agile and traditional teams must plan their work together. Learn the special techniques you can use to coordinate ongoing efforts of all participants and ways to review and understand each other's work patterns and artifacts.