Posts filed under 'Development Teams'

Conquering Meeting Madness

Meeting MadnessMeetings are the bane of their existence for many a programmer but they’re often a necessary evil, particularly if you’re a lead developer. What steps should you take in ensure that your meetings are worthwhile and don’t waste everyone’s time? When should you call a meeting and when shouldn’t you call one? Should you have regularly scheduled weekly team meetings? What time of day is best for scheduling meetings? In this article I’ll examine these questions.

When should you call a meeting?

In general, a meeting is called for when one or two people need to provide information to a larger number of people quickly or when real time interactivity between participants is required.

Here are some situations where a meeting is called for:

  • When there is a need to convey sensitive information at the same time to a number of people. For example, management or other organizational changes, layoffs, work policy changes or other confidential or sensitive matters.
  • A demo or training session on a new tool or product.
  • When the subject at hand would benefit from a meaningful, interactive, discussion by those invited to attend, for example, a joint application development meeting.
  • A brainstorming session to solve a problem that could not be resolved by other forms of office communication.
  • When key meeting participants are only going to be in the office for a short amount of time, for example, a meeting with a consulting team or vendor.

Here are some situations where a meeting is NOT called for:

  • To communicate work status to other members of a project team
  • To deliver project status to project sponsors
  • To make it easier for a manager to keep tabs what everyone is doing
  • To ask and answer questions like, “What have you accomplished this week?”
  • To hand out work assignments

What about having regularly scheduled weekly or bi-weekly team meetings?

My take on this is that these meetings are a waste of time. In most cases, very little information is exchanged, programmers hate the disruption of their work routine and thought processes, they are ineffective for team building and managers or meeting sponsors often feel that they have to fill in the time block with something, even if it is trivial. Also, lazy managers will use them to gather status reports and to pass along information to individuals rather than the team as a whole.

My advice is to avoid calling for any regularly scheduled meetings. Instead, gather status information and make trivial team and company announcements either individually in person or through email or an online forum/blog/wiki format.

What time of day is best for scheduling meetings?

If you must schedule a meeting avoid scheduling one during the middle of the morning or middle of the afternoon. When you do this, you almost guarantee that you will disrupt the work flow of all of the attendees for that half of the day.

Some people recommend meeting first thing in the morning or at the end of the day. This works sometimes but you have to be mindful of individual work schedules and the commute situation in your area. For example, you don’t want to schedule an 8:00 AM meeting when some of the participants regularly arrive at 9:00 since they won’t be there and having the meeting later will disrupt the morning for the early birds. The opposite applies to late afternoon meetings. Also, early meetings can be unexpectedly disrupted when people arrive late due to commuting difficulties, a common problem in most larger cities.

Scheduling just before or just after lunch is generally better since it avoids disrupting the work day as much. However, people will tend to be distracted as lunch time nears and stomachs begin to growl. After lunch works good although some people tend to be a little lethargic at this time.

My favorite time for meeting is lunch. If the matters being discussed aren’t too confidential or don’t require props in the office, take everyone out to lunch at a favorite restaurant. Perhaps you can even get a place with a small meeting room. If the meeting needs to be in the office, order in pizza, Chinese, sandwiches or the like. A free lunch is appreciated by all and people will view it as a nice perk and a long lunch rather than just another boring meeting.

What steps should you take in ensure that your meetings are worthwhile?

Here are some steps you can take that can help you have an effective meeting:

  • Before you call a meeting know what you want to accomplish with it before you call it. If you don’t know or are not sure, postpone it or call it off until you’re ready.
  • Have an agenda and stick to it. Often meeting sponsors will allow the meeting to stray off topic. Avoid this trap by having clear discussion goals that are known by all attendees in advance and by keeping the discussion focused on the topic at hand during the meeting.
  • Achieve the goal of the meeting, even if conditionally. Don’t use the lack of a concrete decision in one meeting as an excuse to schedule yet another meeting. Instead, reach a conditional consensus and an agreed upon follow up plan that doesn’t require more meetings.

One final idea

If you’re the lead or manager, don’t use the meeting to hand out tasks. This tends to make meetings more dreaded by your team and tasks assigned this way tend to be incomplete and vague. Instead, follow up the meeting discussion with emailed or one-on-one in person assignments. You’ll find this to be a more effective use of your personal time as well as the team members.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment July 14th, 2007

Encourage Creativity

A business has to be involving, it has to be fun, and it has to exercise your creative instincts. - Richard BransonThe number one benefit of information technology is that it empowers people to do what they want to do. It lets people be creative. It lets people be productive. It lets people learn things they didn’t think they could learn before, and so in a sense it is all about potential. - Steve Ballmer

Software development is often seen as a purely analytical, linear, “left brain”, exercise. Many organizations manage software development projects this way and have a culture that rejects creativity by individual developers. However, many development projects also require a lot of “right brain”, fuzzy, non-linear, thinking to be their best or, in some cases, successful at all.

One thing I’ve noted about some of the best programmers I’ve worked with is that they also have some kind of artistic outside interest. My own guitar playing would be one example. I’ve worked with several excellent programmers who were also musicians. Others were painters, some were furniture makers, one even wrote novels and short stories. I suspect you’ll find a lot of “frustrated artists” in many IT organizations.

First, let’s not mistake creativity for general hacking a program together without a cohesive plan. To use a musical perspective, when playing in a group jam session everybody needs to know what key they’re playing in and at what tempo, when to take the lead and when to play rhythm, and so forth. In programming, this compares to tools, requirements and design specs that everyone agrees to use. Creativity isn’t simple chaos but the organization of thoughts that transform random bits of information into a useful whole.

Creativity isn’t just a coding thing. It can be used during the requirements gathering and design phase too. Creative “out of the box” collaborative thinking at this phase can greatly improve a project’s outcome. Handing developers a fixed spec and schedule that nips creativity in the bud will ultimately produce a weaker end product. You’ll get a Velvet Elvis rather than a Mona Lisa.

Many managers are concerned that if they allow creativity that the process will fall by the wayside. The overall development process is important, but it also has to support creative thinking. The goal is to make sure that the people on your team see that the process that’s implemented supports their creativity and doesn’t stifle it. Excessive time tracking, ‘TPS’ reports, required staff and company meetings and other such things can be creativity killers. Managers should use their own creative skills to eliminate useless tasks and to keep processes that insure not just a good, but a great, final product.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 28th, 2007

Next Posts


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives