4

I am thinking of introducing weekly technology meeting where programmers working on the same project can discuss things like:

  • current status of the project on technical side
  • technology backlog. Things that we may have skipped because of deadlines but now coming back to bite us.
  • technology constraints that are limiting developers from being productive
  • new and emerging technologies that may apply to the project

Basically looking at the project from programmer's perspective, not the business side.

-

What would be some good guidelines for a meeting like this?

  • How long should the meeting last?
  • Is weekly too often?
  • Should we time-limit each topic?
  • What kinda of topics are good for a meeting like this and which ones are bad?
  • Is 10 people too many?

...

CashCow
  • 1,610
  • 13
  • 16
Mag20
  • 3,281
  • 2
  • 23
  • 21
  • If you are doing any kind of iteration back log planning, maybe think of implementing this meeting as a retrospective to the previous iteration. Try and keep it small and at the end of the day. – DevelopingChris Feb 21 '11 at 14:01
  • @DevelopingChris: I strongly disagree with "end of the day". Many programmers like to work late hours to get a period without interruption, and a short meeting just before that is surprisingly disruptive. Paul Graham discusses this in http://www.paulgraham.com/makersschedule.html. – btilly Feb 21 '11 at 16:30
  • @btilly When I read that article, it says, don't do it before or during the maker's schedule, try and make things happen at the end of their day. – DevelopingChris Feb 21 '11 at 16:53
  • @DevelopingChris: Read more carefully. It says, "Don't break up big chunks of time for the maker." I'm pointing out that the end of the manager's day typically falls in the middle of one of those chunks. – btilly Feb 21 '11 at 17:28

4 Answers4

2

I don't think it is fruitful to discuss current status of the project every week. Discussing where the project is requires daily meetings, not weekly meetings. A good question about such meetings was asked here.

Also in my experience it is better to deal with technology backlog during planning.

As for new and emerging technologies - I don't think it's a bad idea per se. It also fits the weekly format. However it is extremely easy to be off-topic on such meetings. Be sure that other people want to contribute, and don't invite too many people (10 is actually a lot, I think).

Community
  • 1
Nikita Barsukov
  • 1,265
  • 1
  • 9
  • 12
  • 1
    I prefer daily meetings with the programming team instead of weekly, but only if you can limit them to about 5-10 minutes. Daily meetings should only be a status report on what each programmer has done and is working on. – Rachel Feb 21 '11 at 15:47
  • 1
    +1: discussing "new and emerging technologies that may apply to the project" every week is a complete waste of time. – S.Lott Feb 21 '11 at 16:03
1

At my job we have a 30 min meeting on Fridays where we talk about where we are with each of our tasks. I've found it helpful in that sometimes when one person is talking about a roadblock they've encountered, another might be able to provide some insight on it. The key is to make sure everyone is prepared prior to the meeting and to keep it as brief as possible.

Bmw
  • 344
  • 1
  • 4
  • +1 for keeping it as brief as possible. If two programmers are talking about something that only they care about, stop them and have them talk about it afterwards once you take care of items the entire team cares about. – Rachel Feb 21 '11 at 15:45
0

There are lots of things you could have in a weekly project meeting, and everyone will have their own opinions.

My feeling on your list is that these 3: - technology backlog. Things that we may have skipped because of deadlines but now coming back to bite us. - technology constraints that are limiting developers from being productive - new and emerging technologies that may apply to the project

....might be a bit much to discuss weekly. Maybe these would be better discussed at the end of a phase of a project.

ozz
  • 8,322
  • 2
  • 29
  • 62
0
  • The meetings should not last longer then is needed to keep things actionable. Only discuss improvements for which you have time and you plan to do in the immediate future. If you know you picked enough for the coming week then stop discussing further items.
  • To be able to prioritize improvements you typically don't need to discuss them full depth. Only do so when you are actually planning to action on it. You could allow some bidding system on these improvements to somewhat democratize prioritization.
  • Don't do too many things simultaneously, limit yourself in how many improvements you work on in parallel.
  • The meetings you hold have no value if you have no time for the formulated actions. How do you create time in between regular project work?
  • You may want to separate project related things from more global concerns like personal skill development and team process ("Should we learn jQuery?", "Do we need a build server?" etc). Things that would improve all projects might best be discussed separate from project context. You may even want to create little internal projects for those.
  • 10 people seems a bit much but if that's the project team's size: do include all involved technical people.
Joppe
  • 4,548
  • 17
  • 25