Большинству компаний не требуется масштабирующая структура, чтобы добиться успеха в многокомандном Scrum.
К сожалению, вы работаете в компании, где все команды работают разрозненно. Когда вам неожиданно нужно обратиться за помощью к другой команде, потому что вы зависите от нее, - вы облажались. Это эквивалент спринта.
Когда вы просите о помощи, вы часто получаете ответ примерно следующего содержания:
«Почему вы сейчас нас этим беспокоите? Вы могли знать об этом раньше. Наш Спринт уже начался, вы опоздали. Наш Спринт заполнен, и у нас есть важный проект, который нам нужно реализовать. Пожалуйста, не беспокойте нас, и мы не надеемся, что сможем помочь вам в следующих нескольких спринтах ».
С этим ваше разочарование взлетает до небес. Почему бы нам просто не помочь друг другу, неужели так сложно протянуть руку помощи? Другая команда имеет свои собственные обязательства по выполнению и не желает подвергать это риску, помогая кому-либо.
Обычное явление в Скраме происходит после начала Спринта - команды фиксируют свои спринты сильнее, чем Форт-Нокс. Смена спринта или, что еще хуже, обращение за помощью к другой команде означает потерю лица. Вы признаете, что не все учли. Это также может означать наказание, так как все, что присутствует в Спринте, является целью. Все, что меньше всего, разочаровывает.
Член команды предлагает решить эти проблемы совместной работы, внедрив структуру масштабирования. Мы страдаем от проблем с масштабированием, потому что у нас много команд, работающих над одним и тем же продуктом. Если мы просто выберем правильный фреймворк из множества вариантов масштабирования - Scrum @ Scale, SAFe, LeSS, Nexus или Scrum of Scrums - тогда мы золотые.
Это заблуждение. Рамки масштабирования никогда не устранят негибкость внутри команд и между ними.
Вы не можете согласовать то, чего не знаете
Люди - существа, склонные к ошибкам, и разработка продукта очень сложна и неопределенна. Вечное планирование, анализ, дизайн и координация не предотвратят всех ошибок. И даже если бы вы могли выполнять свою работу идеально, всегда есть вещи, о которых вы не можете знать, прежде чем приступить к работе. Проблемы, вызванные открывающимися неизвестными вещами, - это то, что бросает песок в вашу шестерню.
Когда у команд нет времени помогать друг другу, это часто неправильно воспринимается как проблема координации. Большинство команд пытаются решить проблему сотрудничества и общения, внедряя структуру масштабирования. Давайте проведем Scrum of Scrums, Nexus или LeSS, чтобы улучшить взаимодействие и взаимодействие наших команд друг с другом.
Но как вы сотрудничаете и координируете то, чего еще не знаете? В лучшем случае вы просто поделитесь тем же, что и раньше, но вместо этого это будет в заранее определенный и организованный момент. Базовая негибкость не будет устранена рамкой масштабирования.
Команды Scrum должны быть гибкими, в том числе по отношению друг к другу. Вот соответствующий отрывок из руководства по Scrum:
Суть Scrum - это небольшая команда людей. Индивидуальная команда очень гибкая и адаптивная
Насколько он гибок и адаптивен, если вам нужна масштабируемая структура для формализации взаимодействий, делающих возможными координацию и сотрудничество? Вам не нужна масштабируемая структура, чтобы команды могли гибко взаимодействовать друг с другом. Правильно выполненный Scrum по умолчанию обеспечивает гибкость.
Скрам имеет гибкую и адаптивную основу эмпиризма за счет дизайна. В сложной среде неизвестно больше, чем известно, и вам следует принимать решения на основе того, что известно. Принятие решений на месте означает (повторные) действия на основе последней информации.
Чтобы иметь возможность действовать, используя самую последнюю и лучшую информацию по мере ее обнаружения, вам нужна гибкость. По мере того, как вы узнаете больше, вам нужно дать возможность проявиться в своих планах.
Четыре ингредиента гибкости
Чтобы команды могли быть гибкими по отношению друг к другу, вам нужны четыре элемента:
- Цель спринта. Обязательная всеобъемлющая цель, которая не использует все возможности команды Scrum. Команда Scrum планирует использовать максимум 70% мощности только для оптимизации потока и для того, чтобы иметь возможность справляться с неожиданностями. У полностью занятых Scrum-команд никогда не будет места, чтобы справиться с неожиданностями или помочь друг другу.
- Гибкость бэклога спринта. Бэклог спринта появляется во время спринта, и команда пытается найти наименее сложный способ достижения цели спринта. Это нормально, если элементы невыполненной работы спринта переносятся на следующий спринт, которые не имеют отношения к цели спринта.
- Межкомандная гибкость. Когда другая команда просит о помощи, вы найдете время, чтобы помочь им. По умолчанию позиция должна заключаться в сотрудничестве, а не в переговорах. Конечно, если запрос ставит под угрозу цель спринта, тогда это другое дело. Вы все еще можете помочь в той степени, в которой не подвергаете риску цель спринта. Вы также можете принять совместное решение сделать одну цель спринта более важной, чем другую, если это принесет больше пользы компании. Конечно, это должны решать команды Scrum (включая владельцев продуктов).
- Психологическая безопасность. Если команды будут наказаны за проявление инициативы и принятие решений, вы уничтожите всю инициативу. Придерживаться исходного плана становится вариантом по умолчанию, даже если он не имеет смысла.
Даже когда у вас есть эти четыре элемента, то, как вы справляетесь с невыполнением целей спринта, играет ключевую роль в том, насколько гибкими будут ваши команды.
Несоблюдение цели спринта не обязательно должно рассматриваться как неудача, если команда приложила все усилия. Несоблюдение цели спринта часто является ошибкой ожиданий: цель спринта оказалась более сложной, чем ожидалось. Возможно, с учетом обстоятельств команда добилась максимального прогресса. Это все еще победа, и это не повод для горечи.
Также может быть, что одна команда не достигает своей цели спринта, потому что она помогла другой команде с более ценной целью спринта. Как это можно воспринимать как что-то плохое? Больше пользы было доставлено за счет меньшей ценности спринт-цели. Командная работа должна распространяться не только на одну Скрам-команду. Командная работа должна распространяться на разные команды Scrum, работающие над одним и тем же продуктом.
Если цель спринта не достигнута из-за неэффективной работы команды или других проблем, которые необходимо решить, это ценная информация - то, над чем стоит подумать и попытаться извлечь уроки, а не наказывать.
Какую проблему масштабирования вы пытаетесь решить?
Подумайте, какую проблему вы пытаетесь решить, когда в следующий раз кто-нибудь скажет: «Давайте воспользуемся рамкой масштабирования. Фреймворки масштабирования волшебным образом не сделают команды гибкими по отношению друг к другу. Слаженное общение и координация не дают волшебным образом гибкости, когда случается непредвиденное. Фреймворки масштабирования могут просто добавить ненужные уровни бюрократии, в то время как основные проблемы останутся.
Если гибкость - ваша самая большая проблема, вы должны сначала исправить это. После этого оцените, нужна ли вам еще инфраструктура масштабирования. Подход Форт-Нокса отлично подходит, если вы хотите не пускать людей - есть причина, по которой Джеймс Бонд - единственный человек, который пытался прорваться в Форт-Нокс, - но он не работает, если вам нужно наладить активное сотрудничество между многими командами.
Перестань относиться к своим спринтам, как к Форт-Ноксу изначально было опубликовано на mdalmijn.com
