I guess I have to vent about this, but it would probably help to know I'm not alone and others have been in the same situation. (Not that I'd wish it on anybody!) I joined a team to work on what was originally a jam game, but they decided to rebuild it as something much bigger. I'm the programmer, but I seem to have taken the role of being a team leader. I don't like bossing people around and I try my best to be empathetic about things, but the rest of the team doesn't seem to have any organisational skills. That doesn't really matter with a 48-hour game jam, but with a full game if everything is jumbled about the game's progress is going to suffer. I take every single idea from the other members on board, and so we can choose something that's we all agree on we've run polls.

Sometimes my team has been very helpful and we've spend hours at a time discussing the game's development, and also watching films together (synchronised) with a similar narrative, as it's a quest/adventure. (Think like Phoenix Wright or Hotel Dusk in gameplay.) The thing with indie games is that everybody usually has different priorities and amounts of free time. It seems the rest of my team has plenty of their own and I probably have more hours to give to the project. That's why I set up a Google Calendar solution for us, and we all created our own entries with designated times to discuss what we're working on and plan ahead. The problem is, my team is regularly missing these times. I just don't know what to do when they're not showing up, despite them expressing their interest in the game.

If I keep badgering them to get to work on it I'll seem bossy and obsessive. If I just walk out on them, that's the programming out of the window. Hypothetically speaking, I could effectively "fire" them to find different team members, but since we agreed to work on it with equal ownership do I really have the right to do that? For every scenario I can think of, I'm the bad guy and it's a very interesting game I don't want to simply give up on.

Have you ever faced a similar problem? I think with no money incentive (at least upfront) a lot of people won't put their heart into a project. That's why I feel like just entering game jams for the foreseeable future where these issues aren't typically a factor.

Sorry for such a long thread, but damn, it feels good to get this off my chest.

This is a problem I've totally run into before, and have been on both sides of from when I was a little kid posting in Usenet in the mid-1990's until today where I've tried on a few occasions to support groups doing fan games or open source games.

Basically, if you aren't paying people, then you are throwing a party, and if your party isn't great, people check out. Motivation, drive, focus are things you end up with by  accident, and when it's a group project it becomes very tempting to let someone else make the first move and not look like a fool. And anything you do might be worthy of extended discussion the first time you do it. Which in combination with large scope(which tends to inflate as a way of avoiding reaching a concrete and coherent resolution on any decision), makes things go slower, and slower, and slower, until everyone has given up. 

Plus it's easy to build a very flimsy kind of hype around the idea of "making a game" because games are fun at the surface, so lots of people sign up for what they hope will be a lightweight experience only for it to gradually sink in that there is a huge boulder to push up the mountain before the game can even resemble anything, and the things they thought they would work on and want to voice their opinions about are actually pretty simple decisions or only become relevant much later, while the majority of the work consists of blundering through the dark barely understanding how to move the project forward and learning new skills constantly to do so.

And even if you are paying people, this happens. Hiring people is a two-way thing in that while on a small team you would like for them to self-start and cover for you on many different fronts like intelligent automatons, the reality is that the average candidate will tend to hope that the job will be a straightforward fit to their very specific fixations and not require anything outside of that. Even more so when they're on a short term contract and already have the next gig on their mind - they may put on a brave face to pay bills, but no spoons will be spared to give your project special consideration, and if you let someone on who isn't up to it or is given insufficient direction, they crumble with anxiety and may be damaged by this toxic mix of obligations and inability to fulfill them.

And when put that way it becomes a little more apparent that team building is a kind of design process - you have to design both roles that you can fill and a workflow that puts those roles together in a way that does not blow up. Functioning game studios end up with a lot of overhead in the process because, as it turns out, what's acceptable for most people tends to be that mix of regular hours, a desk, bosses, meetings, and separations between "creative" and "business" roles. With all that stuff in place, the team can move forward and accomplish things even though not every member of it is a perfect fit or wholly engaged every day.

My solution has been to downscope to a project size that works for me alone and then fill in gaps by adding other people only once I think I have a clear role for them that doesn't cascade into "now you do all the work for me" - a lot of the fantasy of team building is that you just assemble the "artists/programmers/designers/writers" in a room and they automatically know what to do and how to resolve project decisions. Nobody does. Even if you've got motivated and skilled folks they will have blinders and bottlenecks. Even major, apparently better financed and organized stakeholders like publishers will fail at giving your project special attention and default to giving the low-quality, polish-focused feedback that you could get from any random player.

If you don't actually have the game done in any form yet I suggest rebooting it in a limited format that you can adapt from - the PICO-8, Twine or Bitsy version of the experience. Throw on as many limits as you can to avoid upscoping, even if it that means it becomes more like a mockup than a functioning game. If you can't finish it in that form, where the limits stop you from tacking on more stuff, then you don't have the game yet, you have an incoherent mess to untangle and prioritize. The team will have a much easier time seeing a working result and giving feedback on that than sitting in a long meeting going, "well, we could do any of these 50 things, let's keep all our options on the table."

Laatly, remember to mix group interactions with one on one interviewing. People share themselves differently in the two contexts and a lot of basic management issues can be resolved by going to person A and asking, "what's bugging you right now?" and then going to person B and saying "hey, person A is worried about X. Do you think you can help?" Because it will turn out that the communication just didn't happen before and they needed a go-between.

Nearly every team that I've been on that wasn't a jam team has fallen apart for many of the reasons listed above. But if you can find a team that has the same level of ambition and passion to make a game, it is a fantastic experience you will have compared to working by yourself.

Entering game jams is a fantastic way to meet new people and to get a feel for working on team if you have no experience. Especially if you're #notatGDC

In reference to OP's post, all of the scenarios you've mentioned seem to be worst case scenarios that you've built up in your own head. You should at least "be the bad guy" and bring up the subject of missing deadlines to your team. If they get mad at you for even mentioning something like that, then it's likely a team you want no part of anyway. Regardless of how passionate you are for a project, it will be negatively impacted due to toxicity within a team.  But I would try having a constructive conversation about the deadlines and see where you end up. If it's not meant to be, then you can always move on to your next project.

For anyone working with a new team, you could even try to design a loose "contract" that basically outlines expectations. Getting an agreement in writing makes it much easier to deal with team members that aren't sharing the workload or hitting their deadlines.

Interesting post and answers.  We're very much a team, and experiences are as follows:

1) The proposal was for a huge game, and most of that has been mapped out, however having something "real", a product, helps, so we broke the initial proposal down into "chapters".  The feeling was that if we had something working, something to show for the effort, then that would serve as motivation to continue.  That sort of approach isn't always possible we know, but it worked for us.  Essentially it was almost like an "Agile" project in terms of how we worked on it.

2) Sort of related to the above, when a member of the team would bring something in, everybody else would get excited about it. So if we had new graphics, or new music, everybody felt like they wanted to do more.  I think we were lucky because whenever anyone said "I'll get the music for that done by next week", they actually did it!

3) We have a project manager acting as our team leader, but it's not about being pushy or "the boss".  In fact he often said that he was just there to make things easier for us to complete, so the team were the boss, and the project manager removed barriers for everyone, and supported them.  The PM was also able to identify everyone's skills and played to everyone's strengths.

4) Meeting in person made things easier.  Some projects are done with contributions from all over the globe, but having that physical meeting, or at the very least a Skype call, helped tremendously.

5) It was fun doing it

6) It was fun doing it.  Yes this is repeated twice, but it's really the key motivation for producing the game that we did.

Hope some of these comments help!

    Good tips so far. One thing that helps is to clearly define who is responsible for what and keep it that way. What has always wrecked team efforts for me is a "fix your stuff" culture. It is always an excuse for someone to weasel out of something that should be doing by jumping onto someone else's work that is already partially done so they don't have to stick their necks out. If you ever hear someone say that they have to "fix" someone else's stuff it's usually a sign that they are too lazy and/or are not up to the tasks that they should personally be doing. It also creates division within the team as in order for someone to "fix" some else's stuff they have to call out another team member as being incompetent and creates a very toxic working environment.