1. Идеи
1.1. Выделить ответственного в каждом офисе
1.2. Перенести позицию тимлида в москву
1.3. Перейти на канбан?
1.4. Нормализовать команды
1.4.1. В каждой - разработчики и тестировщики
1.4.2. Scrum of scrums
1.5. сократить участие PO в стендапах
1.6. Делать демо должны команды
1.6.1. Ижевск и Москва
1.7. Налаживать личный контакт с людьми
1.7.1. Организовать командировки между офисами
2. Эксперименты
2.1. Меняем тимлида
2.1.1. Новый тимлид в Москве
2.1.2. Текущий остается на позиции архитектора пока нужно
2.1.3. Регулярные созвоны (не стендап)
2.2. Вводим тимлида в Ижевске
2.2.1. Следит за субординацией
2.2.2. и за мотивацией
2.2.3. контролирует резульаты
2.2.4. Обеспечивает процесс
2.2.4.1. Стендапы
2.2.4.2. Ретроспектива
2.3. Product Owner не участвует в стендапах
2.3.1. Нет язвкового барьера
2.3.1.1. Повышение эффективности коммуникаций
2.3.2. Нет напряженности у PO
2.3.3. Регулярные созвоны и внутренние презентации
2.4. Формальное планирование и распределение задач
2.4.1. Четкое разграничение ответственности
2.4.1.1. Нет перекидывания задач туда-сюда
2.4.2. Понятные требования и задачи
2.4.2.1. меньше багов
2.4.3. Ясные сроки
2.4.3.1. Легче следить за выполнением итерации
2.4.4. Уменьшение размера задач
2.4.4.1. Больше прозрачность
2.4.5. Тимлиды выполняют эту роль если команда не проявляет инициативы
2.4.5.1. Постепенный переход на самостоятельное планирование командами
2.5. Ввод метрик
2.5.1. Количество закрытых User Stories за итерацию
2.5.1.1. Общая Velocity
2.5.2. Завершение итерации вовремя
2.6. Демо делают команды, а не один тимлид
3. Симптомы
3.1. Большая разница во времени
3.1.1. С тимлидом и владельцем продукта
3.2. Итерации не успеваются
3.2.1. нет функциональности к концу итерации
3.3. Долгие стендапы
3.4. Пассивная Ижевская команда
3.4.1. Делают, что скажут
3.5. Низкая эффективность удаленной команды
3.5.1. с точки зрения Москвы
3.6. Москва недовольна
3.6.1. (как всегда)
3.6.2. Много факапов у удаленной команды
3.7. Халатность разработчиков
3.7.1. Много багов
3.7.2. Разработчики "спихивают" функциональность на тестеров
3.7.2.1. в Ижевск
4. Проблемы
4.1. Метрик нет
4.1.1. неочевиден масштаб трагедии
4.1.2. нет прозрачности
4.2. Низкая эффективность коммуникаций
4.2.1. Тайм-зоны
4.2.2. Языковой барьер
4.2.3. Плохая организация процесса
4.2.3.1. Скрам мастер - тряпка
4.2.4. Нет общения между командами
4.3. Тимлид неэффективен
4.3.1. Непонятно чем занят
4.3.2. Удален
4.3.3. Нет личного контакта
4.3.4. Малое перекрытие по времени с командой
4.4. У Ижевской команды нет лидера
4.4.1. Пассивность
4.4.2. Нет прозрачности
4.4.3. Нет контроля
4.4.4. нет мотивации
4.5. Низкая эффективность Ижевской команды
4.5.1. Плохая визибилити
4.5.2. Низкая квалификация
4.5.3. Игнорирование результатов Москвой
4.5.4. Низкая вовлеченность
4.5.4.1. Нет общей картины?
4.5.4.2. Нет заинтересованности в результате
4.6. Формальный подход к работе
4.6.1. Низкое качество решений
4.6.2. Перекидывание задач
4.6.3. Уход от ответвенности
4.6.4. Снобизм
4.7. Большое количество багов в конце итерации
4.7.1. Тестировщики недовольны
4.7.2. Уходит время на доделку
4.7.2.1. Функционал итерации не завершен
4.7.3. Снижение мотивации
4.8. Плохое планирование
4.8.1. Москва не знает что делает Ижевск
4.8.2. Ижевск не понимает что нужно сделать
5. Цели
5.1. Повысить эффективность
5.2. Увеличить вовлеченность
5.2.1. коллективная ответственность