Статься про такие вещи, как скрамтурбация и агиллюзия.
AGILE — это не только:
— Философия разработки софта;
— Подходы повышения эффективности;
— Ещё одна методология управления персоналом.
Вдумайтесь в ценности agile-манифеста.
Ведь это не что иное, как революция!
Откуда идут революции? Снизу, «из масс».
Откуда пришел Agile? Из первоклассных команд.
Но что, если менеджмент видит необходимость переменить процессы?
Как помочь команде «заразить» аджайлом верха?
Как избежать кровавых революций?
Работая коучами и тренерами, мы — мои коллеги и я — обычно наблюдаем в год 10-20 компаний, которые находятся на разных этапах аджализации. Есть очень много позитивных, вдохновляющих примеров.
Но есть и яркие анти-паттерны. Знание о них поможет вам не сбиться с пути.
Расскажу о двух самых опасных.
Но для начала — чуточку контекста.
ЭКОСИСТЕМА ПРОЕКТА
Участников проекта можно условно разбить на два лагеря: верхний и нижний.
Сверху обитают все те, кто причастен к бизнес-решениям, финансовым вопросам, результату проекта. Их кредо — «Do the right things!».
Снизу — все те, кто совместными усилиями разрабатывают продукт. «Do the things right!», – жаждут внизу.
Целью аджализации всегда было сближение этих двух полюсов. «Customer collaboration over contract negotiation», — гласит Манифест.
Работая вместе, полюсы могут общими знаниями и усилиями правильно создавать правильные продукты. Но что может пойти не так при аджализации?
AGILE, ЗАСТРЯВШИЙ ВНИЗУ
Agile, идущий снизу — природный путь развития событий. Так родилось XP — из идеализма программистов, жаждущих делать классные продукты. Так до сих пор многие компании познают дао гибкой разработки.
Но что происходит, если искры agile-революции не достигают верхнего лагеря — заказчиков и менеджеров? «Пусть они там играют в свой Скрам, у нас на это нет времени. Сроки горят!», — говорят сверху.
Типичное развитие событий в таком проекте я называю подпольным аджайлом или скрамтурбацией (уверен, что именно я придумал этот термин в 2013 году: #скрамтурбация, #scrumturbation). Когда команды, не вовлекая заказчиков, строят квази-agile-процесс.
Положительные стороны такого процесса:
- Высокий уровень самооорганизации в команде;
- Повышенное качество кода;
- Растущая мотивация в команде (до поры до времени);
- Персональный рост участников команды;
- Pull-процесс планирования работы — команда берёт на спринт столько, сколько может сделать.
Но минусы тоже очевидны:
- Зказчики не рулят производством, что рано или поздно приведет к кризису, вроде: «Это не то, что мы хотели!», — или: «Почему так медленно и дорого?»;
- У заказчиков нет процесса накопления знаний и итерирования вокруг идей продукта — они живут в своих грезах-гипотезах о том, что нужно сферическому пользователю в вакууме, что в конце концов приведет к кризису: «Проект успешен, продукт к эксплуатации непригоден».
Симптомом такого процесса будет наличие Владельца Продукта на стороне команды, а именно — роли Proxy Product Owner, выбранного из участников команды. Не допускайте этого. Команда должна всеми силами пытаться вовлечь кого-то сверху в процесс разработки.
Регулярные демонстрации версий заказчикам и менеджерам с вопросом: «Что бы вы хотели увидеть на следующей демо?», — постепенно должны дать ожидаемый результат.
Но страшнее всего даже не это.
AGILE, ДАВЯЩИЙ СВЕРХУ
«Мы знаем, что нам нужно. Там внизу должны следовать Скрам-процессу. Мы выделим специально обученных Скрам-мастеров!», — решают сверху.
Так рождается agile-диктатура или агиллюзия (от agile+illusion - #агиллюзия, #agillusion). Это иллюзия гибкой разработки.
В таком процессе рождается страшный зверь — Remote ScrumMaster на стороне заказчиков. Бойтесь попасть в такую ситуацию.
Положительные стороны такого подхода:
- Компания готова к переменам;
- Есть спонсоры процесса и выделенные бюджеты;
- Есть возможность привлечения внешних специалистов — коучей и тренеров.
Основной минус — непонимание философии гибкой разработки со всеми вытекающими осложнениями:
- Давление на команду сроками и планами спринтов;
- Push-процесс, перегружающий команду;
- Отсутствие среды для зарождения самоорганизации в команде;
- Небезопасная среда для процессных улучшений и озвучивания правды;
- Нежелание команды давать оценки объёма работ и брать обязательства;
- Пониженная мотивация сотрудников;
- А хуже всего — так как вся инициатива перестройки процессов подается под лозунгами Agile — в команде вырабатывается устойчивая ненависть к гибкой разработке и Скраму.
Выход из такой ситуации — создание революции, идущей из команды.
Мне приходилось участвовать в нескольких таких процессах в роли коуча. Как правило, это непростой и болезненный процесс.
Не доводите свои команды до такого!
Статья от 02/2013
Как думаете, вам пора начинать революцию?
Write a comment
ZMskyuza (Wednesday, 26 October 2022 17:31)
20
ZMskyuza (Wednesday, 26 October 2022 18:01)
20
ZMskyuza (Wednesday, 26 October 2022 18:04)
20
ZMskyuza (Wednesday, 26 October 2022 23:41)
20
ZMskyuza (Thursday, 27 October 2022 01:31)
20
ZMskyuza (Thursday, 27 October 2022 02:42)
20