Participate in the making of a new book on Agile

James Shore, a local consultant here in Portland along with Shane Warden, are writing a book called The Art of Agile Development to be published later this year. If you want to get a glimpse of what the book will be about, they have a working draft on Jim's website.

Here's a portion of the preface to give you an idea of what the book is about:

We want to help you master the art of agile development.

Agile development, like any approach to team-based software development, is a fundamentally human art, one subject to the vagaries of individuals and their interactions. To master agile development, you must learn to evaluate myriad possibilities, moment to moment, and intuitively pick the best of course of action.

How can you possibly learn such a difficult skill? Practice!

Most of this book is an étude. An étude is a piece of music that's also a teaching tool. Études help the artist learn difficult technical skills. The best études are also musically beautiful.

Our agile étude serves two purposes. First and foremost, it's a detailed description of one way to practice agile development. It's a practical guide that, if followed mindfully, will allow you to successful bring agile development to your team—or help you decide that it isn't a good choice in your situation.

Our second purpose is to help you master the art of agile development. Team software development is too nuanced for any book to tell you how to master it. Mastery comes from within: from experience and an intuitive understanding of ripples caused by the pebble of a choice.

We can't teach you how your choices will ripple throughout your organization. We don't try. You must provide the nuance and understanding. This is the only way to master the art. Follow the practices. Watch what happens. Think about why they worked... or didn't work. Then do them again. Watch what happens. What was the same? What was different? Why? Then do it again. And again. Watch what happens each time.

At first, you may struggle to understand how to do each practice. They will look easy on paper, but putting each practice into action will sometimes be difficult. Keep practicing until it's easy.

As it gets easier, you will discover that some of our rules don't work for you. In the beginning, you won't be able to tell if the problem is in our rules or in the way you're following them. Keep practicing until you're certain. Then break the rules.

Parts I and II of this book contain our agile étude. Part I helps you get started; Part II provides detailed guidance for each practice. Parts I and II should keep you occupied for many months.

When you're ready to break the rules, turn to Part III. A word of warning: there is nothing in Part III that will help you practice agile development. Instead, it's full of ideas that will help you break rules.

One day you'll discover that rules no longer hold any interest for you. After all, agile development isn't about following rules. "It's about simplicity, and feedback... communication and trust," you'll think. "It's about delivering value—and having the courage to do the right thing at the right time." You'll intuitively evaluate myriad possibilities, moment to moment, and pick the best course of action.

When you do, pass this book on to someone else, dogeared and ragged though it may be, so that they too may master the art of agile development.

But just don't take a look at this draft of the book, help the authors out! You can participate in the review process by joining the art-of-agile mailing list! I'm sure that they will appreciate the help and you can feel good in contributing back to the Agile community!

Games that you can plan with

Mike Griffiths from Leading Answers has a great post called "Release and Iteration Planning with Innovation Games". Here is his introduction:

In this post I outline some really useful techniques for planning releases and iterations. They are adapted from a great book called “Innovation Games: Creating Breakthrough Products through Collaborative Play" by Luke Hohmann

I have never been a fan of suggesting the use of “games” in the enterprise workplace, as in XP’s “Planning Game”. The term does not sit well with some traditional-type folks; to them it sounds unprofessional and not serious enough for important work. Yet the Innovation Games described by Hohmann are high performance facilitated workshop exercises that produce great results. If the project is serious enough to engage busy stakeholders then I think we owe it to the business to use the most effective tools at our disposal. If calling them “facilitated workshop exercises” eases their acceptance then I’m all for it, because it is the results I’m really interested in, not so much what we call them.

In Luke’s book, he outlines a number of games (exercises) that can be used in a variety of settings. Some like “Design the Product Box” and “Buy a Feature” are probably familiar to many people working on agile projects, others will likely be new. To keep this post a reasonable length I will focus on adapting three exercises for use in release and iteration planning.

The three we will look at are “Remember the Future”, “Prune the Product Tree”, and “Speedboat”. I use slight variations on the last two, I call them “Shape the Product Tree” and “Sailboat” and I will explain the differences when we get to them...

Read more in his post on these three tools. Personally, I like tools like these especially for people who think more visually. Plus, by using stickers you have plenty of flexibility as you brainstorm with others and determine what the release will look like. I definitely plan on buying the book.