Demos are a great way to get feedback.  They generate lots of conversations and good ideas for the next iteration.  This worked or this didn't work or what if we did this...  Encourage questions and discussion.  Know when to spin those off into separate meetings.

To be effective, demos need to be interesting.  The best way I've found to do this is to focus on customer value.  Show how the customer would accomplish things given the new features. And emphasize why that's important.  This keeps the teams grounded in thinking about things from a customer point of view.

We generally do acceptance before the demo.  That way we can focus on the demonstration itself rather than administrative aspects / too much detail.

Demos are a great way to keep the teams energized. They help to show how much progress you're making.  Everyone likes progress.  Demos are a way to make that progress obvious.

Next, each team should have a velocity for the release.  Think high level.  People iterations are useful.  So if you have 5 people and 6 iterations to add features, than you have 30 people iterations of velocity for the release.

Each team will likely have areas that they have traditionally owned.  For each team, have them put high level estimates for each feature based on those areas (going down the list in priority order).  Stop when the team runs out of velocity.

As an aside, we often focus on the developers.  We ensure that QA and doc are present in the right ratios.  But to keep things simple we often don't estimate those independently.

Now a few things should be obvious.  Based on traditional ownership, some teams made it further down the backlog than others.  Look for opportunities for cross training / changing ownership so that you're optimized to make it as far down the list as possible.  Also useful is if you can reduce the number of teams that need to participate in each feature.

Now that you've done some load balancing, start thinking in more detail about what needs to be done to accomplish those features.  In other words, how are you going to break the feature into increments, each of which add customer value?  This can take a week or two given everything else you likely have going on.  If it takes longer, you're probably over thinking it.

By the way, in person is much better.  If your teams are distributed and you're able to spend for travel, release planning is the time to do it.  Consider bringing in the participants for the full week leading up to release planning.

For the release planning meeting itself, allocate a full day.  Start off for an hour or so and make sure you're all on the same page with the priorities for the release and the objectives for the day.

Break out into the individual teams.  Each team maps their cards (each increment goes on a card along with its cost in number of people) to the iterations.  Start with the highest priority card in the first iteration.  Move to iteration 2 when you've used up your velocity, etc.  The really interesting part is looking at the other teams.  Adjust to make sure that you're in synch.

At the end, go through each iteration.  Each team says what they're hoping to accomplish for the iteration.  Other teams ask questions and bring up issues or concerns.  The net result after you've gone through all of the iterations: everyone has a good feel for what you're trying to take on in the release.

This is not a commitment.  Individual estimates might be way off.  Priorities will change every two weeks.  But you start off on the same page and by staying in touch, you can remain there.  More on that later.

Once you're attacking things in iterations, try to pull the full lifecycle into that iteration.  Testing within the iteration is critical.  It requires a lot more interaction between development and QA.  The two need to go hand in hand.  Next is documentation.  Make sure that any changes to the documentation are also done in the iteration.

Once you have those in the iteration, focus on fixing any resulting defects within the iteration as well.  Make sure any changes to the install or upgrade are done within the iteration.  Start focusing on downstream affects like changes to the bill of materials or changes to training materials.

Getting to the point that all of this is done consistently within the iteration can take a while.  It requires a lot of evolution in the organization.  One way to cope in the interim is to add "hardening" iterations.  The objective here is to add some time to clean up anything that you couldn't do within the iteration.  You might start with one or more mid-release hardening iterations.  And leave one through four hardening iterations at the end.  Your goal is then to reduce the need for these with every release.

When an organization first starts doing Agile, the ranking part can be a challenge.  Product Managers are used to putting things in categories: critical, important, useful.  We've got to do all of the critical things.  We should do as many of the important things as we can.  We should work in the useful things as possible.  In Agile, you have to be more granular.  What is the most critical of the criticals?  The second most?

This is hard because they can be very close to each other (a toss up).  Worst case, go with your gut feeling.  If they're that close, it likely won't make a huge difference if you're wrong.  As you do it more, it'll get easier.  Plus, you'll be learning more about the value proposition of each as time passes.  It is better for the Product Manager to make the gut call than the team since he/she is closer to the customer.  If the Product Manager doesn't rank them, the team will.

What's the right level of granularity for a backlog?  If an item has some parts which are optional and can be prioritized independently, they should be broken out into separate backlog items.

The goal of the engineering team is to get as far down that backlog as possible in the release.  As focal areas change from release to release, cross training is important.  Your people or your teams need to be able to work on areas outside of their core (in case that core isn't a focus for the current priorities).

The priorities don't remain constant.  Every iteration you learn more about the customer and the ability of the items in the backlog to help the customer.  That knowledge should be used to re-evaluate / change the backlog based on what you've learned.

Why is prioritization so critical?  If you rank the work and attack in that order, you know that the things that won't make it are less important than anything that did.  The biggest productivity gains from Agile come from what you don't do.

After being acquired, we slowly adapted to the mainstream approach at BMC: Waterfall. We went to longer and longer releases. We began doing requirements documents and functional specifications. We started doing big things (not incremental). We started testing the quality in at the end. It was analogous to the frog in the pot of water. If you raise the temperature of the water gradually, the frog won’t jump out. Eventually the frog dies. We were the frog.

Something happened before we died. In 2004, Israel Gat joined BMC. He was a big proponent of Agile development. But, he didn’t push it on any of us. He encouraged us and supported us in adopting as we saw fit.

We then started a large scale project. We were to bring together the lightweight PATROL Express (remote monitoring) with the more robust PATROL (agent based monitoring) into a single solution: BMC Performance Manager. The issue was that the two were very distinct architecturally and in their capabilities (though they were fundamentally trying to solve similar problems in complementary ways). We could easily have spent two to three years developing a first version only to realize that we missed the mark. We realized that we needed to do it in a way that kept us focused on the most important aspects and let us get lots of feedback as we were going along. Agile seemed the way to go. In retrospect, I can’t see how we would have been successful otherwise.

It was a breath of fresh air. We no longer got mired in the details / debates that in the end didn’t matter. We focused on what was truly important: working software, not specifications. We started working better as a team. And eventually, better as a business unit.

We began using agile on a few of the core teams. We started expanding to more and more. BMC Performance Manager is entirely agile at this point. Service Impact and Event Management (the group I’m in now) is getting there. Agile is like a virus (in a positive way). It has taken root in BMC and we’re seeing a lot of benefits in our ability to put out powerful new features with much higher quality (see http://biz.yahoo.com/bw/070910/20070910005634.html?.v=1 for some recent press on the subject).

My goal with this blog is to share some of the things that we picked up along the way (and the things that we’re still picking up as we expand its usage and take it even further).

Walter