I've been posting some highly abstract theories for project management and effectiveness. Well, actually there are even a level removed from that. They are more like analogies for theories. I'll probably still have one of those kinds of posts every once and a while. But I'm also a huge fan of http://www.manager-tools.com and one of the things that makes them so unique and so valuable is that they always give very concrete actions to take and they have a strict focus on behaviors. Heck they even provide ten step instructions on handshakes. So here it goes.

I've always struggled with how to drive and determine schedules. So I thought for my latest project I would focus on them with much more energy than I have in the past. At first I was drawn to abstract tools and prediction techniques, but I knew that it would be a huge job to try and roll out a change in operations across the larger team. I also didn't want to get bogged down in tool complexities. Instead I focused on what I could do on a feature team level. Out of necessity I finally boiled it down to the basics. Also, having recently finished The Influencer I realized that making broader change requires that you change vital behaviors and provide a highly visible example. Rhetoric doesn't work.

My key frustration on every project I have worked on is that there is so many opportunities to game the system. People mean well, but ultimately the bug economy takes over. I think ultimately this is because project leaders focus on the macro approach and confuse the reports with the project itself. I wanted to strip that all away.

The core of a project is tasks. Project management is getting those tasks done on time. (Yes, more management-tools jumping in here. Who Does What by When. ) Once the project tasks were broken down I did the following:

• Printed them all out in a large font

• Taped them to a huge roll of paper

• Drew circles by the tasks where each circle represented a half day of the estimated time it would take to complete the task.
• Pinned it to the wall

• Put a large number of smiley stickers next to the chart. The total number of smiley stickers represents our capacity for the milestone.

Now every day we have a fifteen minute standup meeting. Each developer on the project has to put two stickers on the chart. If they were working on a task, they put the sticker in a circle next to that task. Declares when a task is done and has a special sticker to signify it.

The great thing about this model is that it strips away the fluff and brings you back to the world of actual work. Test is there to make sure things are done when the dev says they are done. Plus you get a highly visible representation of the work done, the work left, and the capacity available in the milestone. Even better, the devs become better estimators because they get a feedback cycle.

So far so good. For the one or two folks who read this, please feel free to jump in and offer opinions.