Don’t Mistake Meetings for Process

2012-04-08

I’ve joined several teams over the last few years, including one or two that effectively had no development process. Even with the smartest engineers in the world, the latter always show the same symptoms:

Does this sound like your team? The problem is almost always the same: lack of communication. The point of development process is simple: ensure team communication. The simplest effective development process for your team ensures that everyone is in sync about the present and near-future goals for the team.

Process gets a bad reputation because often meetings are used as a substitute for process. Since lack of communication is the problem, we should just throw everyone in a room together to talk, right? Good, high-bandwidth meetings can be very useful but just as important are tools which allow the team to communicate on their own schedule (think issue trackers, code review tools, group chat, a pinboard with index cards, etc). Your process should be a mixture of synchronous, high-bandwidth meetings and asynchronous, low-bandwidth tools. There’s no right mixture but your process must have two mandatory properties:

  1. Everyone must sign off on it as “the way”.
  2. Everyone must actually follow it.

I generally try for two team meetings per week: a Monday morning sync about upcoming work for this week and next week and Friday afternoon demo of work accomplished that week (the demo almost always finds bugs and issues to be fixed next week). Monday morning kicks the work week into high gear and Friday afternoon winds down the work so everyone can enjoy their weekend.

Great, which process should you use? Agile, XP, Scrum, Kanban? I treat them like web frameworks: pick one, learn it well and modify it as necessary for your own needs. The one booklet that I keep going back to year after year is this booklet on Scrum and XP practices offered by InfoQ. It’s a very practical, quick read and low tech enough that you can implement it in 2007 or 2017.