Команда в целом должна содержать все компетенции, необходимые для поставки продукта.
… Скрам-команда организует свои усилия в области развития, она выбирает членов команды, или оценивает, как вырастить командный набор навыков.
✥ ✥ ✥
Скрам-команда не может работать автономно, потому что у нее нет всех навыков, необходимых для выполнения сложной цепочки задач. Из-за зависимости от навыков людей за пределами команды, команда не может взять на себя ответственность за выполнение своих задач. Это снижает влияние команды на время, необходимое для завершения, и может снизить качество конечного результата. Основные принципы бережливого производства, заключающиеся в устойчивости и сокращении переделок, зависят от коротких циклов обратной связи. Комплексная разработка требует включения людей с множеством талантов таких, как человеческий фактор, инженерное совершенство и обеспечение качества. Редко можно найти все эти таланты у членов одной команды, не говоря уже о каком-либо отдельном человеке. Команды часто организуются вокруг зон компетенций: рыбак рыбака видит издалека. Иногда это называется функциональной организацией. Тем не менее, координировать эти функции вне границ команды дорого, потому что эффективная коммуникация происходит между теми, кто разделяет контекст текущей работы, и обычно это члены команды.
Комплексный продукт может потребовать от команды освоения многочисленных навыков для разработки Done функциональности (см. Definition of Done). Когда работа требует дополнительного человека для каждого необходимого навыка, команда становится слишком большой, чтобы быть эффективной. У вас может возникнуть соблазн не расширять набор навыков в команде, а вместо этого ввести внешние зависимости. С другой стороны, вы можете поручить работу команде, чтобы они могли развить и изучить требуемые навыки. Но обучение требует времени.
Локальное обучение может стать локальной оптимизацией, когда группа специалистов разрабатывает практики и процессы, оптимизирующие их работу. Специализация, локальные практики и процессы могут быть источниками эффективности в организации, но также могут создавать проблемы на границе группы. Для решения этих проблем организация может определить «контракты», описывающие, как работать друг с другом (например, запросы на обслуживание). Такие контракты могут определять характер работы, которую организация готова выполнять, а также ожидаемую продолжительность ответов на запросы. Любому нуждающемуся в групповой специализации пришлось бы использовать эти контракты. Однако это может замедлить разработку продукта в целом, даже если повысит эффективность отдела локально. Опять же, может возникнуть необходимость в дополнительных координационных группах внутри организации для управления этими пограничными контрактами, для согласования исключений или обеспечения понимания всеми сторонами того, что требуется, а также для обеспечения того, чтобы каждая группа выполняла свои обязательства перед другими командами — и перед заказчиком, в соответствии с обязательствами по этим контрактам.
Новые продукты или новые версии существующих продуктов создают новый мир для пользователей. Поскольку вы не можете заранее знать, каким будет этот новый мир, вы должны сосредоточиться на обучении и экспериментировании по мере развития продукта. Команда должна извлечь уроки из опыта использования каждого инкремента реальными потребителями, а не действовать в соответствии с заранее разработанным планом. И команда должна интегрировать эти уроки в процесс разработки продукта. Все признают преимущества локального потока, автономии и контроля, которые возникают в результате индивидуальной работы на этапе процесса или в функциональной области. Однако такая структура работы уводит всех (кроме человека, выполняющего последний шаг) от конечного пользователя и общих идей, которые приходят в результате взаимодействия на этой границе. Это может привести к неоптимальной локальной оптимизации функций сквозь весь процесс разработки продукта.
Поэтому:
Каждая Скрам-команда должна включать в себя все компетенции, необходимые для реализации Done функциональности.
Хорошая практика обращать внимание на охват набора навыков при первоначальном создании команды, но, что более важно, чтобы члены этой команды разделяли энтузиазм по поводу Видения и чтобы у них был опыт изучения нового. Поскольку со временем все меняется, маловероятно, что команда с самого начала сможет предвидеть все свои долгосрочные потребности в навыках.
✥ ✥ ✥
Вместо того, чтобы менять состав команды по мере появления потребности в новых навыках, растите людей внутри компании и стремитесь к созданию небольших и стабильных команд. Со временем проводите кросс-обучение для участников команды, чтобы они развивали свои навыки, чтобы осваивать все большее количество областей знаний (см.Moderate Truck Number). Это повысит способность команды работать как автономная команда. С кросс-функциональными командами становится проще равномерно распределять работу.
Тогда все участники команды имеют все возможности для изучения вторичных навыков.
Они могут свормиться (см. Swarming: One-Piece Continuous Flow) работая над Элементами Бэклога Продукта (PBIs), который увеличивает возможности для обучения и оптимизирует поток, чтобы помочь быстро получить Done функциональность. Развитие вторичных навыков делает команду более гибкой, так что любой член может заменить другого, который стал недоступен. Команда всегда прогрессирует и автономна.
Скрам ничего не говорит о том, что делать с недостатком компетенции. Пусть преобладает здравый смысл; например, попросите помощи у другой команды или заключите субподряд на большие объемы работы, которые могут удивить команду. Это понятно, если команда нуждается в такой помощи время от времени. Но если команда обнаруживает, что часто зависит от внешней помощи, ей следует рассматривать это как препятствие и принимать меры (такие как обучение, реорганизация или найм) для исправления ситуации.
Например, команда программистов может обнаружить, что создает продукт в области за пределами их основной экспертизы, такой как фармацевтика или аэрокосмическая промышленность. Заманчиво назначить человека в команду для каждой из недостаточно представленных компетенций, возможно, проконсультировавшись с внешним экспертом в предметной области. Однако представитель группы может не знать, чего они не знают, и может даже не понимать, какие вопросы задать экспертам в предметной области. Большинство экспертов в предметной области несут в себе знания, как неявные, поэтому они не в состоянии восстановить правильные идеи, чтобы поддержать разработчика программного обеспечения в правильной реализации.
Крайне важно, чтобы члены команды понимали важность рассмотрения предметной области для реализации и хорошо знали как бизнес, так и пространство решений. В недавней статье Джесси Уотсон из Amazon отметил, что крайне важно, чтобы оба этих фактора сосуществовали «в одном черепе». Лучше привлечь эксперта к команде и расшарить знания с помощью перекрестного обучения. Но помните о малых командах: добавление специалистов может привести к тому, что команда вырастет до такой степени, что совместная работа сведется практически к нулю.
Эти команды естественно действуют как “фиче-команды” (см. Conway’s Law) потому что большинство PBIs — фичи: ориентированные на рынок приносящие прибыль элементы. Если кросс-функциональные команды разрабатывают продукт, передачи естественным образом исчезают из Потока Создания Ценности: команда самостоятельно может разработать любую функциональность без помощи извне или вмешательства. Вовлечение нескольких команд приводит к задержкам циклов обратной связи, увеличивает потери (muda) из-за переделки и создает несогласованность (mura) между этапами разработки в Потоке Создания Ценности.
Опубликованное в Harvard Business Review исследование двух корпораций, одна из которых функциональная, а другая продуктовая, говорит о том, что кросс-функциональные группы предоставляет лучшие возможности обоих организационных структур (см. «Организационный выбор: продукт против функции» в (см. “Organizational Choice: Product vs. Functionˮ).
Set-Based Design техника, которая позволяет разработчикам заниматься многими дисциплинами и областями, которые могут иметь отношение к бизнесу, даже если они в конечном итоге не будут использоваться в текущем продукте. Такая практика расширяет базу знаний команды и организации и снижает вероятность того, что команда будет удивлена необходимостью освоить новую дисциплину.
По мере того, как команда интегрирует новые уроки, будут появляться новые продуктовые идеи.
Изменения будут происходить быстро (и нужно позволить, чтобы они пошли быстро). Изменения будут скорее нормой, чем исключением. Для этого требуются небольшие организации, в которых все знают, что происходит: организации, способные принимать изменения, работать в разных специализациях, регулярно приносить пользу и, если не считать другого термина, гибкими.
Игра
Соберите несколько небольших команд, которые будут соревноваться в игре за создание бумажных самолетиков и управление ими. Каждый член команды может делать только одну складку за раз, а затем должен переключиться на работу в другой плоскости. Никакой самолет не может иметь более 15 складок. Он должен быть не менее 15 сантиметров в длину и 8 сантиметров в ширину. У него должен быть тупой кончик шириной не менее 2 сантиметров. Чтобы квалифицироваться как качественный продукт, самолет должен пролететь 3 метра по горизонтали, когда испытатель его проверяет. Тестер может проверить каждый самолет только один раз.
Попробуйте игру, и примените Скрам-паттерны (Swarming), чтобы оптимизировать количество качественных самолетов произведенных в одноминутный Спринт.
