Question

I am a solo developer working on a decently small project with about 3 other people (non-developers). These other people are involved in the project in non-development ways and one is also my manager. Everyone is pretty open to ad hoc discussions, too.

My manager just gave me what seems like a dream come true - I was tasked with determining what meeting structure would work best for the project. This seems like a wonderful way to deal with meeting overload and/or pointless meetings.

With great power comes great responsibility, as now, if I suggest something which ultimately results in much wasted time it's my fault.

I have never had such a blank slate to think how I would structure meetings. My thoughts are:

  • Daily "touch base/status update" meeting for 15min or less (similar to standup meetings) to communicate daily objectives and review previous day. Or, it seems I could just get a whiteboard and put it at my desk to communicate this info.
  • As needed meetings to make specific decisions or address questions any of the team has

... I don't see the need for a weekly "status" project meeting. I'm also not sure the second bullet would require many formally scheduled meetings.

My concern is these "developer focused" (ie me) might cause alienation with others or make my manager feel a loss of control on the project, as this structure would be considerably different than most projects are run.

What project meeting structure should a single developer choose?


Addressing comments:

What are the other people contributing? Are they the intended users of this project? Working on non-development aspects of it (such as website themes & images or a DBA, or QA testing)? Other levels of management/administration?

They are some of the eventual users and are interested in the overall workflow. They are also contributing to several areas of forms/documents (the format of which will not affect any development work).

Are you able to get feedback from the other two members? Some managers need to have a regularly scheduled meeting or they'll never be able to fit it into their schedule.

Getting time does not seem to be a problem going forward.

Was it helpful?

Solution

As a sole developer, your biggest issue is visibility. My recommendation is to do full sprint cycles, like in an Agile project. Every two weeks, demo a little bit more functionality (this could be in a half hour to hour long meeting. Every day have a standup explaining what you did yesterday, what you'll be doing today and any roadblocks you have.

By doing this you will be communicating to the others exactly where the product is at at any one time. They will feel involved, everyone will know exactly where the progress of building the product is at and decisions can be made to scrap/introduce features as necessary.

And a 10 minute standup on a daily basis only "wastes" an hour a week. Having an hour long demo once a fortnight limits your meeting exposure to an average of 1.5h per week, which isn't a lot.

OTHER TIPS

None

Unless you have something that requires a highly interactive group discussion (such as demonstrating an iteration), or just need to be seen working, tying up 4 people in a meeting, even for 15 minutes, will be wasteful.

In-person meetings are the highest-bandwidth form of communication available; they are also the most expensive form of communication. Use them wisely, and only when necessary.

Licensed under: CC-BY-SA with attribution
scroll top