In my last post, I gave a brief intro to Agile, and I promised a post about simple planning. Here you go.

So, to plan software, it should be simple. You know what you want, so just figure out a plan for making it happen, and then follow the plan. What could be easier? If you're planning the entire project up front, nothing could be harder.

If you're reading this post, you already know that plans change. That's why we do Agile. We plan often, and we review the plan daily.

Let's start with the big one, the weekly planning meeting. This meeting is about implementing strategy. By this, I mean that you should have a single client voice for the product telling the implementation team what they want for the week. It's okay if you've got 3 people from the client side at the meeting/listening in on the call -- but only one of them should do 99% of the talking on the client's end. If the client rep asks anyone else on the client side "Should we do A or B?" then you're probably doing it wrong. That's a strategic decision. That's a totally different meeting. The weekly planning meeting is meant for planning the implementation of the strategy. "Here's where we want to go," says the client, "so how do we get there?" That's a good planning meeting.

At the planning meeting, everybody responsible for implementing the plan should be present. So should the client voice person. Anybody else is optional. It's okay to have people listen in, but they shouldn't be talking. If they are, it makes it likely that you're going to get sucked into strategy discussion -- good people are always filled with good thoughts. Ideas are great, but this is not the time for them. Record them on paper or email, and strategize later. Have regular strategy meetings. Send an email on the spot if you have to, with a one sentence reminder that will trigger the later discussion. Just don't do it during an Agile planning meeting. A 5-minute discussion can throw everyone off for twice as long, and the effect is multiplied by the number of people at the meeting.

As far as what you should be doing during the planning meeting? The implementation team (engineers/coders) should listen to what the client wants to have happen next. They should discuss the simplest way to fill the client's needs, and how to break it down. The implementation team should be adding tickets to the system and discussing their estimates of how long tasks will take. You want small tasks. It makes estimates more accurate, since they're planned out well, and it keeps momentum high for the team, since they're constantly closing tickets.

One thing to keep in mind is minimizing risk in your estimates. It's not always possible, but you should try to have estimates based on "this is how long it takes" and not "we'll have to figure that out". Don't figure stuff out mid-task. Do it up front. This is how to reduce risk, and thus, reduce surprises. We don't want surprises. We want steady progress. Sweet, steady progress.

A note about risk. You want to reduce risk. The best way to minimize risk is to have already done the thing before. If you want a login system implemented, we've done it before. Risk is low. But what about integrating with a new API from a company that you and your team have never heard of before? Risk is high.

Here's one trick that I've been using to minimize risk. This is influenced by something I picked up from GTD. Let's go with the new API example. Risk is high, right? If we try and estimate based on how it's similar to an API we've worked with before, you might improve a bit. But, if it's a big API, or implementation is going to be a big factor, just schedule a task for it. Set aside 2-3 hours to review the docs and make sure you get a feel for it. Go through a tutorial. You might even find yourself accidentally producing code that is useful for the main task. I label these R&D tasks: "[C:1] R&D new API -- spend a couple hours on this, and reply to ticket with findings"

For the implementation team: if you are asked to estimate things and something comes up where you're not 100% sure, don't hesitate to spend 10 minutes on R&D right then. If you've been talking for a while, encourage the client to go grab a cup of water, or step outside for a stretch. They could probably use a break from "executing their vision transfer". (My necktie just got a bit tighter with that one :D)

So there you have it. A strong plan for planning weekly. All the implementation team has to do is just follow the directions they wrote. They wrote it, so they know it, and they know what's expected from them. Estimates are solid, so you've filled your week with a sane amount of work. No end-of-week surprises here. Just sweet, steady progress. Your next Agile responsibility will be the daily meeting, so my next responsibility is to blog about that.