Методологии совместного программирования?
Поделюсь взглядом со стороны программиста.

Вот мы делаем проект командой из 3-5 человек. Проект длинный, больше года. В итоге каждый отвечает только за свою часть, в чужой ничего не понимает. Некоторые вещи реализуются независимо два, а то и три(!) раза, потом с матами приходится рефакторить всё к единому виду.
Программисты не смотрят код друг-друга, потому что времени на это нет. Начальство ждёт продвижения по плану работ, на встрече тебя спрашивают: успеешь сделать вот это за N дней? Ты прикидываешь на пальцах, умножаешь время на pi, как положено, и говоришь «да успею». В итоге даже успеваешь, но посмотреть чужой код времени не остаётся почти.
Из плюсов совместной разработки: если один человек уходит в отпуск, другой сможет хотя бы собрать билд. Плюсов можно найти больше, если среди программистов найдётся человек, которому не пофиг. Тогда даже может появиться какая-никакая документация. Если всем пофиг, то без разницы, сколько человек будет работать над проектом — документация не появится. Извинте, наболело.

Насчёт подгонять. Не знаю как где, но по моему опыту кодер кодит с постоянной скоростью, независимо ни от чего. Если один человек задерживает каким-то образом остальных, то это просто повод отдохнуть или начать кодить другую задачу. Думаете, будут подгонять?

Ещё есть мнение, что девять беременных женщин не смогут родить одного ребёнка за месяц. Если проект реально разделить на более-менее независимые части, то можно дать их разным программистам. Если процесс работы можно нарезать на маленькие части, которые можно делать параллельно, то их тоже можно распределить на несколько человек. Но выяснять этот вопрос тоже лучше всего у программистов.
Срочно сбросьте с себя это ярмо. Пускай разработчики сами разбирают задачи, ориентируясь на свой опыт. Количество работников на проекте может быть динамичное. У нас даже джуниоры сами себе таски набирают. 
Если на проекте один разработчик, то на время добрасывайте второго, пускай парнопрограммируют, чтобы проект полностью не был завязан на одном разработчике.

Я подобную систему советовал сестре для её тестеров. Правда, у них получилось, что часть важных задач всё же распределяет она. Здесь всё сильно зависит от команды и нужно подстраиваться, делая ретроспективы и обсуждая что последнее время делалось хорошо, что плохо, решать проблемы.