6. Правило 60-30-10
Эффективность новой команды
зависит:
—60% дизайн команды
—30% запуск команды
—10% коучинг команды
J. Richard Hackman, Collaborative Intelligence: Using Teams to Solve Hard Problems
(https://www.amazon.com/Collaborative-Intelligence-Using-Teams-Problems/dp/1605099902)
7. Статистика влияния дизайна на
эффективность команды
Программа
проектов
> 500 сотрудников,
30+ команд
Экспресс-аудит
через полгода
Экспресс-аудит – экспертиза ScrumTrek по оценке эффективности внедрения процессов и
инструментов, определению относительной зрелости команд и выявлению системных проблем в
большом количестве связанных команд
8. Модель зрелости экспресс-аудита:
4 уровня и 5 компетенций
Предусло-
вия старта
работы по
Agile
Прозрач-
ность и
предсказуе-
мость
процесса
Качество и
надеж-
ность
поставки
Бизнес-
ценность
поставки
1. Процессы и коммуникации
2. Планирование и проектирование решения
3. Контроль качества
4. Инженерная культура
5. Взаимодействие с другими командами
9. Примеры выявленных корреляций
по итогам экспресс-аудита
Scrum-процесс не
работает там, где не
выполнены
предусловия
• Недостаточная кросс-
функциональность
• Не поставлены
процессы: новые или
удаленные команды
• Не определен
заказчик
Внедряют
системную
интеграцию, если
• Поставлен Scrum-
процесс
• Есть оперативная
синхронизация
между
командами по
планам
Есть тенденция, что
более «старые»
команды
• Меньше участвуют в
формальных
церемониях по
синхронизации
• Начинают
контролировать
технический долг
13. На что может влиять отсутствие
тестировщиков в команде?
0 1 2 3 4
СТЕПЕНЬ РЕАЛИЗАЦИИ КОМПЕТЕНЦИИ, БАЛЛЫ
КОМАНДЫ
Доступ к интегрируемым системам
Тестирование внутри спринтов
Фокус команды на качество
Системная интеграцияНет
тестировщиков
Мало
тестировщиков
Чем больше систем доступно в интеграции, тем больше работы для тестирования в спринтах,
команда фокусируется на качестве и начинает внедрять системную интеграцию
Заметна
корреляция
15. Осмотическое взаимодействие
Стив Макконнел
Период полураспада
доверия – 6 недель
Мелвин Конвей
Организации, которые
разрабатывают системы,
неизбежно создают
структуры, воспроизводящие
схемы коммуникации внутри
самих организаций
16. На что может влиять
распределение команды?
0 1 2 3 4
СТЕПЕНЬ РЕАЛИЗАЦИИ ПРЕДВАРИТЕЛЬНЫХ УСЛОВИЙ, БАЛЛЫ
КОМАНДЫ
Кросс-функциональность, вовлечение
бизнеса
Все в одном месте
Доступ к интегрируемым системам
Вся техническая экспертиза
Распределенные
команды, или
только
стартовали, или не
было kick-off
Заметна
корреляция
В распределенных командах в сравнении с остальными нет всей необходимой технической
экспертизы и доступов к интегрируемым системам
17. На что еще может влиять
распределение команды?
• Организуют тестирование
внутри спринтов
• Обеспечивают большую
прозрачность и
предсказуемость
Не сильно
распре-
деленные
команды
21. Бизнес-контекст
—Рассказывайте так, как если бы рассказывали
инвесторам и клиентам
—Лучший способ сбора требований – Face to face
общение
—Двигайтесь от общего к частному – расскажите о
целях, клиентах, их проблемах, которые вы хотите
решить
—Переходите к составлению бэклога продукта
—Будьте рядом весь день
35. Как выбрать Скрам-мастера?
• В закрытую пишем на стикерах:
– фамилию и имя Скрам-мастера
– можно выдвигать себя
• Вскрываемся и спрашиваем
согласие победителя
• Нет победителя или согласия –
повторяем все с начала
39. Давайте представим #1
—Ваша организация начинает разработку нового
продукта – есть 200 человек. Они имеют все
необходимые технические навыки и опыт
—Руководство просит вас, как эксперта, разделить их
на команды разработки
—Что вы будете учитывать? Как вы будете
действовать?
42. Давайте представим #2
—Теория, опыт и практика говорят нам
– Запуск делается для одной команды
– Запуск проводит опытный Agile-коуч
—А у вас
– 80+ команд
– 10 Agile-коучей
– 1 месяц на все
—Вы немножко сходите с ума и говорите
– Это невозможно!
Есть среди нас Agile-коучи?
А кто-то занимался трансформацией? Менеджеры, технические директора, руководители проектных офисов. Внедрение процессных изменений? Изменение организационной структуры? А запуск команд?
А у кого из вас Agile не взлетел? Не работает этот ваш Agile? Agile is dead?
Об аудите
Заказчик – ScrumTrek
Цели:
Определить приживаемость Скрама
Оценить эффективность внедренных инструментов
Увидеть, кому нужен коучинг
Выявить системные (общие) проблемы, которые нужно решать на уровне программы
Предупреждение
Эта информация – для НАШЕГО использования
Обратная связь командам в стиле «прошу исправить» приведет к ухудшению
Снизится прозрачность процесса
Улучшение будет строится командами формально
Ограничения модели зрелости
Позволяет выявить:
Системные проблемы на уровне программы
Симптомы, но не причины проблем конкретных команд
Для детального анализа нужно еще время
Формат оценки
Очное интервью 1-1,5 часа Agile-коучем по всем командам
Скрам-мастера
Владельца продукта
Вопросы по 5 компетенциям 3 уровней зрелости
Экспертная оценка
По 1 баллу максимум за полное достижение 1 компетенции 1 уровня
Несколько Agile-коучей периодически синхронизируют свои оценки (шкалы)
http://skillswiki.net/Resource/raspredelennyjj-scrum-514
Scrum ничего не говорит о распределенных командах разработки. Однако, коммуникации в этом случае становятся дополнительным препятствием, которое команда Scrum вынуждена преодолевать на пути повышения производительности. Какие основные проблемы встают перед распределенной командой?
Закон Конвея гласит, что "организации, которые разрабатывают системы, неизбежно создают структуры, воспроизводящие схемы коммуникации внутри самих организаций". Когда члены команды распределены, они стремятся создавать в коде больше уровней абстракции, пытаясь изолироваться друг от друга. Таким образом непреднамеренно усложняется программный код.
Стив Макконнелл говорил, что "период полураспада доверия составляет 6 недель". Когда коллеги перестают видеться каждый день и не работают рядом друг с другом, уровень доверя в отношениях между ними снижается. Это приводит к меньшей терпимости к ошибкам коллег и взаимопомощи, разрушению единства команды между распределенными группами, воспринимающими друг друга как "мы и они".
Алистер Кобер называл это осмотическим взаимодействием, когда расположение всех членов команды в одном помещении позволяет всем быть контексте общей работы. Один сотрудник задает вопрос вслух, другие присутствующие могут подключиться к беседе или, наоборот, отключиться, продолжив работу. Удаленная разработка может привести к потере текущей ситуации членами команды.