Первая ситуация, думаю, знакома многим: есть несколько задач, реализация которых зависит от результатов работы других команд разработки (вам вместе нужно их делать). Как лучше спланировать недельный спринт? Там было два варианта: поставить все кросс-командные задачи как можно плотнее и раньше, а также сделать микс из кросс-командных и внутрикомандных задач.
Ситуация встречается очень часто в архитектуре нескольких команд разработки с пересекающейся зоной ответственности: чаще всего это какая-то инфраструктурная команда и продуктовая либо две продуктовые и инфраструктурная, которые вместе делают интеграцию по API. Так вот, весь смысл гибких методологий разработки заключается в том, что плана, по сути, нет. Есть процесс разведки и исследования проблемы и проекта. То есть нельзя твёрдо полагаться на то, что другая команда сделает что-то в срок, а вы придёте и сделаете на этой основе свою часть работы. Это не строительство, когда одна бригада пришла класть кирпич поверх уже готового фундамента.
Именно поэтому нельзя занимать весь спринт кросс-командными задачами: статистически в них многое пойдёт не так, и в итоге возникнут ожидания и простои. Лучше иметь внутрикомандные (а в идеале так вообще внутрикомандные и индивидуальные) задачи, которые можно делать, пока другая команда что-то пилит.
Но и это не всё. Гораздо более широкая ситуация — выбор senior-тимлида — даже не в этом, а в причинах задержек. Конкретно — что именно привело к тому, что нужно полностью полагаться на другую команду, и можно ли этим как-то управлять.
