Agile хайп делает свое дело: многие компании от крупных банков до растущих стартапов ринулись трансформироваться в Agile. Но все так или иначе наступают на грабли: Нужно ли менять организационную структуру компании или не стоит? В какой момент это делать? Если менять, то как? Есть ли какие-то шаблоны или нужно использовать другие подходы? Как формировать Agile команды? Довериться мнению бизнеса, функциональных руководителей IT? Я расскажу о нетривиальных проблемах, в решении которых я участвовал за предыдущий год в крупных компаниях (количество команд >= 5), и, конечно же, о решениях.
12. Бизнес
Подразделение 1 /
Продукт 1
Владелец
Продукта 1
Специалист
от бизнеса 1
Разработчик
С1
Разработчик
С2
QA
Подразделение 2 /
Продукт 2
Владелец
Продукта 2
Специалист
от бизнеса 1
Специалист
от бизнеса 2
Разработчик
С2
Разработчик
С3
Подразделение
N
IT
Трансформация всей компании
18. Ретроспектива пилотных команд
• Зачем?
• Системное решение сложных
проблем команд
• Кто участвует?
• Команда трансформации
• PO, SM пилотных команд
• 1-2 представителя пилотной
команды
• Как часто проводить?
• Каждый спринт
• Как отслеживать задачи?
• Доска команды трансформации
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.
25. Как сформировать структуру
команд?
• Директивный – команды формируются экспертами “сверху”
• Ответственность за структуру команды остается на экспертах
• Не учитываются нюансы и баланс компетенций, который виден
только участникам команд
• Self-design – команды формируются самими участниками,
в ограничениях заданных “сверху”
• Ответственность за структуру команд участники берут на себя
• Участники учитывают видимые только им нюансы в балансе
компетенций, эмоциональном комфорте и т.п.
26. Самодизайн команд
• Продолжительность Workshop –
полдня
• В workshop участвуют потенциальные
участники команд
• Владелец продукта презентует задачи,
которые стоят перед продуктом
• Участники договариваются об
ограничениях структуры команд
(кроссфункциональность, 7±2 чел и
т.п.)
• В течении дня происходит несколько
циклов определения-корректировки
структуры команд
https://goo.gl/SJc9Y8