As we got into our project, and started analyzing the requirements, we came to a major realization: The benefit we were getting from gathering requirements was dwindling. We had a solid set of base requirements, but the details were difficult to lay out.

So we moved the project to more of an agile approach. And we've been going more in that direction the longer the project goes on. At first, we used it because it was convenient. We could start building parts of the system to do what we wanted it to do, and as the customer saw what we were building, they were better able to provide the details.

The power of a working module is amazing. We could talk for hours about the benefits of A over B, or B over C, or C over A. And nothing would be decided. If this ever happens, build A, and then show the client what you did. I think you'll be amazed at the results. You'll get the feedback you wanted in the beginning. We've found that, instead of discussing something for a couple of hours, we take a best guess, build it, and ask for feedback after we have a first cut. Now we get five minute conversations. And so far, we're right about 70% of the time, and the other 30% is never a complete rewrite. It's more along the line of slight modifications.

Anyway, back on track. Focus! So we started by building parts of the system that do what we need them to do, and refactoring as new requirements are added to the system.

But this caused two problems for us. One, we never had a full layout of what needed to be done, and two, jumping from task to task caused things to get dropped.

How do we prevent that now? Come into the Philadelphia room (our "war room"), and you'll see a wall full of requirements on post it notes (well, slightly bigger than that - basically 5 x 7 notecards that are sticky). As each task is assigned to a person, its given an hours estimate and is moved to the other wall - a wall of windows with each team member's name on the window, and across the window are the days left until we go live. We then schedule tasks so that each developer can see what tasks they have to work on.

Once a task is done, it's moved to another wall, and marked as complete. The number of hours it actually took is marked down as well. We also have a section for tasks that will be postponed beyond the initial release. As we get closer to the deadline, we'll work actively with the customer to prioritize everything, and start scheduling tasks so that we can get a feel for how much we can squeeze in, and what needs to be postponed.

It solves the two biggest problems. Everyone on the team knows what needs to be done to finish this version and it's all laid out - not just in one person's head, and two, nothing gets lost. Either the task is completed, or it's not. And if something comes up, there's now a process to get it into the schedule - put the post it on the wall.

We've only been using the post it notes for a few days now, but we've already moved a few to the completed section, and it feels pretty good. There definitely is some peer pressure - if your colleague is knocking off tasks left and right (even if they are 1 hour tasks) and you're taking longer to get something done (even if it's a four hour task), there's some competition there!