Agile хайп делает свое дело: многие компании от крупных банков до растущих стартапов ринулись трансформироваться в Agile. Но все так или иначе наступают на грабли: Нужно ли менять организационную структуру компании или не стоит? В какой момент это делать? Если менять, то как? Есть ли какие-то шаблоны или нужно использовать другие подходы? Как формировать Agile команды? Довериться мнению бизнеса, функциональных руководителей IT? Я расскажу о нетривиальных проблемах, в решении которых я участвовал за предыдущий год в крупных компаниях (количество команд >= 5), и, конечно же, о решениях.

1. Как не собрать все
грабли при Agile
трансформации
Алексей Воронин, ScrumTrek

2. Алексей Воронин
• Agile Coach / ScrumTrek
• В прошлом разработчик, Scrum
Master, Консультант, Release
Manager, Change Agent, Руководитель
отдела планирования
• МТС ИТ, NVision Software Solutions,
Asteros Labs, Asteros Consulting
avoronin@scrumtrek.ru
av0r0nin

3. https://agilerussia.timepad.ru/events
Agile Russia
Agile Kitchen

5. Кейсы

6. Что такое Agile трансформация?

7. Agile
Фокус на потребителе Скорость изменений

8. Вертикальная
коммуникация
Ценность не соответствует
колодцам
Задача: соединить колодцы
Трения между
колодцами
Рассадка по
функциям
Политические
барьеры

9. Грабли №1
Что конкретно трансформируем?

10. Бизнес
Подразделение
1
Подразделение
N
IT
Разработка
Системы 1
Разработка
Системы 2
Разработка
Системы N
Разработка
Шины
QA
Бизнес недоволен скоростью разработки IT систем!
Что делать?

11. Бизнес
Подразделение
1
Подразделение
N
IT
Кроссф команда
Системы 1
Владелец
Системы 1
Разработчик С1
Разработчик
Шины
QA
Кроссф команда
Системы 2
Владелец
Системы 2
Разработчик С2
Разработчик
Шины
QA
Кроссф команда
Системы N
Владелец
Системы N
Разработчик СN
Разработчик
Шины
QA
Трансформация IT

12. Бизнес
Подразделение 1 /
Продукт 1
Владелец
Продукта 1
Специалист
от бизнеса 1
Разработчик
С1
Разработчик
С2
QA
Подразделение 2 /
Продукт 2
Владелец
Продукта 2
Специалист
от бизнеса 1
Специалист
от бизнеса 2
Разработчик
С2
Разработчик
С3
Подразделение
N
IT
Трансформация всей компании

13. Грабли №2
Как проводить изменения?

14. Как провести изменения?
Big Bang
Iterative Incremental

15. Собираем
пилотные
команды
Формируем
Vision
Подключаем
к пилоту
новые
команды
+
Оперативно
исправляем
проблемы
Проводим
системные
изменения
Собираем
грабли на
пилотных
командах

16. Грабли №3
Как не заморозить изменения?

17. Собираем
пилотные
команды
Формируем
Vision
Подключаем
к пилоту
новые
команды
+
Оперативно
исправляем
проблемы
Проводим
системные
изменения
Собираем
грабли на
пилотных
командах

18. Ретроспектива пилотных команд
• Зачем?
• Системное решение сложных
проблем команд
• Кто участвует?
• Команда трансформации
• PO, SM пилотных команд
• 1-2 представителя пилотной
команды
• Как часто проводить?
• Каждый спринт
• Как отслеживать задачи?
• Доска команды трансформации

20. Грабли №4
Менять оргструктуру или не менять?

21. Larman’s Laws
• 1. Organizations are implicitly optimized to avoid changing the
status quo middle- and first-level manager and “specialist”
positions & power structures.
• 2. As a corollary to (1), any change initiative will be reduced to
redefining or overloading the new terminology to mean
basically the same as status quo.
• 3. As a corollary to (1), any change initiative will be derided as
“purist”, “theoretical”, “revolutionary”, "religion", and
“needing pragmatic customization for local concerns” — which
deflects from addressing weaknesses and manager/specialist
status quo.
• 4. As a corollary to (1), if after changing the change some
managers and single-specialists are still displaced, they
become “coaches/trainers” for the change, frequently
reinforcing (2) and (3).
• 5. Culture follows structure.

22. Грабли №5
Дизайн команд

23. Собираем
пилотные
команды
Формируем
Vision
Подключаем
к пилоту
новые
команды
+
Оперативно
исправляем
проблемы
Проводим
системные
изменения
Собираем
грабли на
пилотных
командах

24. Дизайн команд – от бизнес
направлений / продуктов

25. Как сформировать структуру
команд?
• Директивный – команды формируются экспертами “сверху”
• Ответственность за структуру команды остается на экспертах
• Не учитываются нюансы и баланс компетенций, который виден
только участникам команд
• Self-design – команды формируются самими участниками,
в ограничениях заданных “сверху”
• Ответственность за структуру команд участники берут на себя
• Участники учитывают видимые только им нюансы в балансе
компетенций, эмоциональном комфорте и т.п.

26. Самодизайн команд
• Продолжительность Workshop –
полдня
• В workshop участвуют потенциальные
участники команд
• Владелец продукта презентует задачи,
которые стоят перед продуктом
• Участники договариваются об
ограничениях структуры команд
(кроссфункциональность, 7±2 чел и
т.п.)
• В течении дня происходит несколько
циклов определения-корректировки
структуры команд
https://goo.gl/SJc9Y8

27. Самодизайн одной
команды
•Правила примерно такие же
•Происходит во время запуска
команды после тренинга
•Требуется максимум 30 минут

28. Дизайн команд – сколько нужно
PO?

30. Сколько нужно скрам-мастеров?

31. Сколько нужно Agile Coach?

32. Грабли №6
Масштабирование изменений

33. Собираем
пилотные
команды
Формируем
Vision
Подключаем
к пилоту
новые
команды
+
Оперативно
исправляем
проблемы
Проводим
системные
изменения
Собираем
грабли на
пилотных
командах

34. Масштабирование изменений
Agile Coach Scrum Master
пилотной команды

35. Грабли №7
Какой framework выбрать?

36. Где же правда – SAFe, LeSS,
Nexus, Scrum@Scale, Spotify, …?

37. ВОПРОСЫ?
facebook.com/groups/enterpriseagilerussia
Enterprise Agile Russiaavoronin@scrumtrek.ru
av0r0nin