⚡️ Максимизируйте зависимости между командами

Звучит почти как вредный совет. Мы привыкли считать зависимости проблемой и проектировать команды так, чтобы они как можно меньше зависели друг от друга.

Бас Водди, со-создатель LeSS, собрал хороший список практик командной работы. Для контекста: LeSS — это мультикомандный Scrum, когда несколько команд вместе разрабатывают один продукт.

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

Что стоит избегать внутри команды:
- каждый работает над своей задачей;
- работа идет по цепочке UX → разработка → тестирование;
- каждый держится только за свою специализацию;
- большие фичи растягиваются на много спринтов;
- команда блокируется зависимостями и берет следующую работу.

Что пробовать внутри команды:
- детальная вторая часть Sprint Planning и мелкие задачи;
- несколько Daily Scrum за день;
- несколько пар работают над одной задачей;
- вся команда работает над кодом вместе (моб-программирование);
- вся команда сосредотачивается на одной задаче (сворминг);
- пожертвовать одним человеком: он берет на себя внешние прерывания, пока остальные работают вместе.

И самое интересное — практики между командами:
- никакой предварительной раздачи задач командам;
- максимизировать зависимости: связанные задачи специально брать разным командам;
- временно объединять две команды на спринт;
- проводить общую вторую часть Sprint Planning;
- подключаться ко второй части Sprint Planning другой команды;
- временно переходить в другую команду (путешественник);
- выделять ведущую команду для большой инициативы (Leading Team).

Мне особенно нравится идея максимизации зависимостей. Если постоянно защищать команды от совместной работы, знания и контекст тоже останутся внутри отдельных команд. А здесь зависимость сознательно используют как повод работать и учиться вместе.

Какие практики попробовали бы?