Это типа "сферического коня в вакууме"?

Это типа объективная реальность данная нам в ощущениях. В скрам команде никто никем не командует. Анархия - мать порядка. Если не считать скрам-мастера членом команды. Потому как он может командовать на митингах.

А команда откуда берется и где "живет"?

Мнэ... Из роддома? Не понял вопроса. Программистов нанимают или переводят из существующих команд. В идеале - в одном помещении. Или в кабинетах расположенных по соседству. Чтобы было легко подойти и посмотреть или подойти и задать вопрос.

Можно и так, только новые требования - это не перенести кнопочку на страницу 3

Ну так требования ничем не ограничены. Вернее не так - надо чтобы их могли хоть как-то озвучить. Вот только недавно доделали задачу - сделать консольные команды для программки со сложным гуем. Теперь Jenkins может скриптами тестировать и передачу сообщений по нашему ESB (к вопросу у гуях и консоли :))

открываем репозиторий скачиваем проект и меняем. Хотя опять таки, не все всегда одинаково.

И вы через два года знаете что и зачем там делал предыдущий программист? Или сначала надо разобраться с проектом?

Есть старая прога которая может работать исключительно под 32 битной ОС. Пришла хотелка 64 бита - пришлось писать по новой.

Оффтоп: Правда всё? Не какие-то части, связанные с чем-то хардварно близким, пару типов переименовать, или я не знаю, какие-нибуть расширения использовать чтобы вектора перемножать, а действительно всё? Как же вы там живёте под виндусями-то... Программку, без привязки к хардварю, написанную на 32-х битном линуксе, заставил компилироваться на 64-х битном солярисе - насколько помню только несколько хедеров и имён типов поменять пришлось. На солярисе uint32_t по другому назывался вроде бы. Забыл уже... А попозже вообще без проблем стало. Главное архитектуру в configure не забывать задавать. Ну и писать программки надо задумываясь о том что их на разных архитектурах собирать будут, не без этого.

Важное замечание о проекте - в единственном числе.

Различных проектов на порядок больше чем имеется людей и даже для прочтения описания что же проект делает нужно время, не говоря уже о понятии кода. И это относительно простые проекты.

А чтобы только понять как работает более сложная система счет может идти на дни. Так что говорить о скорости исправления ошибки "в параллель" говорить не приходится.

Это вам так неправильно кажется. У нас скрам-команда "Утилиты" отвечает ммм... проектов за 12. Если ничего не забыл. В одном спринте могут быть задания для нескольких проектов. Тяжелее всего тут ПО - ему решать что важнее, для какого проекта что они делают сейчас, а какой подождёт до следующего спринта. Все 6 человек более-менее разбираются во всех 12 проектах. Т.е. им не надо рассказывать что это за проект, где его документация и кого можно поспрашивать если сам не можешь разобраться. Пока что 2 (скорее 3) не рискнут что-то сильно менять в проектах с Eclipse RCP, еще парочка не полезет ковыряться в одном новом проекте, там слишком много SQL-я а они с ним на вы. Ну так и команде меньше года. Еще через годик подтянутся. Но и теперь не сидят и не ждут если кто-то в отпуске, в командировке или болеет.

такого мне еще не попадалось, да и представить как то сложно

Представьте себе что это обычный отдел. В котором начальник ПО, но который не может принимать никаких решений по персоналу. Зарплата, найм, увольнение - за это отвечает другой менеджер.