Как только вы соберете всю команду вместе, результат появится незамедлительно. Уже после первого спринта команда согласится, что это была хорошая идея - собраться всем в одном месте (по моему опыту так и есть, хотя нет никаких гарантий, что команда не окажется слишком упрямой, чтобы это признать).
Да, кстати, а что значит «вместе»? Как должны стоять столы? Ну, лично у меня нет однозначного мнения о наилучшем расположении столов. Но даже если бы и было, я думаю, у большинства команд нет такой роскоши - решать, как будут расставлены столы в их комнате. Всегда существуют физические ограничения -соседняя команда, дверь в туалет, здоровый автомат с батончиками и напитками посреди комнаты - да что угодно.
«Вместе» значит:
В пределах слышимости: каждый в команде может поговорить с любым другим членом команды без крика и не вставая из-за своего стола.
В пределах видимости: каждый член команды может увидеть любого другого. Каждый может видеть доску задач. Не обязательно быть достаточно близко, чтобы
Автономно: если вдруг вся ваша команда поднимется и начнет внезапную и очень оживлённую дискуссию об архитектуре системы, никого из не-членов команды не окажется достаточно близко, чтобы ему это помешало. И наоборот.
«Автономно» не значит, что команда должна быть полностью изолирована. В пространстве, разделённом на секции, вполне может хватить отдельной секции для команды, с достаточно высокими стенами, чтобы не пропускать
А как быть с распределённой командой? Ну, тогда вам не повезло. Чтобы уменьшить негативные последствия, используйте как можно больше технических средств: видеоконференции, вебкамеры, средства для совместного использования рабочего стола и т.п.
Не подпускайте product ownerа слишком близко
Product owner должен находиться настолько близко к команде, чтобы в случае возникновения вопросов, команда могла бы спросить его лично, и чтобы он имел возможность на своих двоих подойти к доске задач. Но он не должен сидеть в одной комнате с командой. Почему? Потому что есть вероятность, что он не сможет не вдаваться в подробности, а команда не сможет правильно сработаться (т.е. не достигнет состояния полной автономности, самомотивации и сверхпродуктивности).
Если честно, то это всего лишь догадки: в действительности, я сам никогда не видел, чтобы product owner сидел рядом с командой, а, значит, у меня нет оснований говорить, что это плохая идея. Мне это просто подсказывает внутреннее чутьё и другие ScrumMaster'а.
Не подпускайте менеджеров и тренеров слишком близко
Эту главу мне писать немного тяжело, ведь я был как менеджером, так и тренером …
Тесная работа с командами входила в мои непосредственные обязанности. Я создавал команды, переходил из одной команды в другую, программировал с ними в парах, тренировал ScrumMaster'ов, организовывал планирования спринтов и т.д. Оглядываясь назад можно сказать, что я творил Хорошие Дела. И это всё благодаря моему опыту в гибкой разработке программного обеспечения.
Но потом меня назначили (звучит тема Дарта Вейдера) руководителем отдела разработки. В общем, я стал менеджером. Это означало, что моё присутствие автоматически делало команду менее самоорганизующейся. «О! Шеф тут. У него, небось, есть куча идей о том, что надо сделать, и кто должен этим заняться. Давай-ка послушаем».
Я придерживаюсь следующей точки зрения: Если вы Scrum-тренер (и возможно совмещаете эту роль с ролью менеджера), не бойтесь очень плотно работать с командой. Но только в течение определённого промежутка времени, а потом оставьте команду в покое и дайте ей возможность сработаться и самоорганизоваться. Время от времени контролируйте её (однако не очень часто). Это можно делать, посещая демо, изучая доску задач или принимая участие в ежедневном Scrum’е. Если вы увидите как можно улучшить процесс, отведите ScrumMaster'а в сторонку и дайте ему дельный совет. Не стоит поучать его на глазах у всей команды. Посещение ретроспективы (см. стр. 51 «Как мы проводим ретроспективы») тоже будет не лишним. Если степень доверия к вам со стороны команды невелика, то сделайте доброе дело, не ходите на ретроспективы, а то ваше присутствие заставит команду молчать о своих проблемах.
Если Scrum-команда работает хорошо, обеспечьте её всем необходимым, а потом оставьте в покое (за исключением демо, разумеется).
Как мы проводим ежедневный Scrum
Наш ежедневный Scrum очень похож на то, как это описывают в книгах. Каждый день он начинается в одно и то же время, в одном и том же месте. Вначале, мы предпочитали проводить его в отдельной комнате (это были дни, когда мы использовали sprint backlog'n в электронном формате), однако сейчас мы проводим ежедневный Scrum у доски задач в комнате команды. Нет ничего лучше!