Мой первый фейл во внедрении Agile-культуры

Мы продолжаем серию бесед о самоорганизованных и кросс-функциональных командах с Вячеславом Москаленко, первым сертифицированным тренером Scrum в Украине, сооснователем Agile.Live. (О начале дискурса можете прочитать в предыдущей статье “Самоорганизованные и кроссфункциональные команды в Scrum“, где Вячеслав рассказал о специфике скрам-команд и главные трудности возникающие при попытке ввести аджайл). На этот раз Вячеслав поделится ценным опытом.

[Вячеслав Москаленко]: “Думал — вот оно, счастье. Но нет, опять опыт”. Хочу рассказать о неудаче, которая постигла меня в начале карьеры в Scrum. Почему это важно:

1. Существует некая идеализация экспертов. Вместо того, чтобы мотивировать, она часто демотивирует. Человек рассуждает “Я никогда не достигну такого уровня” и опускает руки, вместо того, чтобы с энтузиазмом воплощать изменения, двигаясь в направлении “Да, поэтому” (о разных способах говорить “Да” см. нашу статью “Четыре ‘да’ и дихотомия Гюнтера Верхейна”).
2. Компаниям необходимо слышать не только “правильные ответы”, но и учиться на ошибках. Лучше, когда это ошибки других.
3. История о фейле — на самом деле ценный инсайт, который помогает лучше понять аджайл-культуру и перенести идеи из книжек и тренингов в реальные жизненные ситуации.

В 2008 году я имел честь работать в компании Ciklum над разработкой платформы для крупного мобильного оператора, цифровыми решениями для маркетинга и другими проектами.

Тогда я был лидером команды и работал вместе с менеджером проекта, программистами разных уровней, тестировщиками и другими участниками разработки.

Мы действовали по “старой” модели (беру в кавычки, потому что имею в виду классическую модель управления проектами, актуальную до сих пор для многих сфер профессиональной деятельности, например, строительства), известную как каскадная или водопадная (waterfall) — подробно разрабатываем проект в соответствии со спецификациями, разбиваем на этапы, в конце имеем результат, который соответствует “техническому заданию” и требованиям заказчика.

С точки зрения организационного менеджмента (особенно на постсоветском пространстве), у каждого проекта должен быть руководитель. Именно он решает, что нужно делать, как, в какие сроки. Согласование вопросов касается заказчика, а не команды. Участники разработки — его подчиненные.

Такая формулировка старого доброго менеджмента, очевидно, не академическая, но доходчивая.
Мне она очень нравилось. Я сам занимался планированием, сам назначал задания, сам указывал, кто что должен делать.

Я наслаждался важностью собственной персоны, возможностью все контролировать, своим авторитетом, зависимостью других от меня. Мне нравилось управлять.

Когда кто-то не мог выполнить задание, делал это некачественно или не укладывался в отведенное время, я ругал “кто-то”. Или стыдил. Парадоксально, но практика стыдить и бранить доставляла мне брутальное удовольствие!

Далее, с позиции старшего брата — более мудрого, более опытного, более правильного, — как отец сыну (даже если “сыну” было за сорок), я объяснял, как нужно выполнить какое-то пустяковое задание.

Настало время перемен (менеджер проекта прочитал книжку о скраме). Особенно ему понравилась идея Daily Scrum — пятнадцатиминутные встречи, на которых появлялась возможность держать руку на пульсе — быстро обсудить то, что было выполнено вчера, чем нужно заниматься сегодня, какие трудности имеются и в какой помощи нуждаемся. Недолго думая, он распорядился внедрить некоторые практики со Scrum.

Скрам был чем-то новым для большинства компаний. Не хватало опытных специалистов и знаний на эту тему; мы не были исключением.

Итеративно-инкрементальный подход заинтересовал лидеров компании из-за того, что решал главную задачу — в краткий срок существенно повысить эффективность. Понятию “самоорганизованные команды” мало кто придавал тогда значение, потому что от болтовни о “единстве в команде”, “командном духе“, “Тим-билдинге” все успели устать.

Тогда мы еще не догадывались, что для введения инкрементально-итеративного подхода необходимо ввести и скрам-культуру работы в команде, иначе нечего говорить об эффективности фреймворка.

Мой первый “дейли скрам” напоминал первый блин комом. Наш менеджер проекта объявил о том, что отныне мы работаем по-новому. Это вызвало больше вопросов, чем ответов. Слишком много деятелей заявляло о том, что будут создавать что-то “по-новому”. К тому же, в народе говорят, не все новое — чудесное, и не все чудесное — новое. Поэтому участники команды по привычке ждали новых распоряжений от меня как технического лидера.

Мы запустили практику ежедневных пятнадцатиминуток (Daily Scrum), во время которой я продолжал быть боссом, а участники разработки — безынициативным и пассивным коллективом подчиненных.

Я задавал вопросы, соблюдая требования фреймворка, однако ответы были формальными. Все и так знали: все будет так, как решит Слава Москаленко.

Собственно, так все и происходило. Я продолжал контролировать работу нашей команды. Когда что-то шло не так, я искал виноватого и, как всегда, объяснял ему, как надо делать правильно.

Интересно, что атмосфера оставалась позитивной. Недовольных не было. Просто все привыкли так работать в старой парадигме.

Никто не хотел проявлять инициативу, не говоря об ответственности. Я тоже не хотел никаких инициатив, кроме собственных, чтобы не лишить себя возможности наслаждаться ролью руководителя.

Таким образом, извне, формально мы внедряли скрам, однако внутри команды все осталось старым. Мы проводили встречи для “статусности” и “прозрачности” (чтобы все видели, кто чем занимается). Де-юре существовала вновь созданная скрам-команда, де-факто-пассивный коллектив во главе с руководителем проекта и техническим лидером.

Абсурдность ситуации достигла своего апогея, когда я вдруг заметил, что сам указываю “подчиненным” на то, что им говорить на “Дейли Скраме”, а что — нет!

Это также заметил и мой менеджер. К счастью, он проявил понимание и помог мне ускорить переход от старого образа мышления к новому.

Сначала я сопротивлялся, находил море причин сохранять статус кво (“Мы не можем быть самоорганизованными, поскольку…”, “Мы хотим перемен, только команда еще незрелая” и тому подобное), но в конце концов сказал: “Да!” без всяких “но” (см. “Четыре ‘да’ и дихотомия Гюнтера Верхейна”).

Что мне пришлось изменить в себе

Труднее всего мне было с такими вопросами:

1. Принять факт необходимости делиться властью.
2. Отпустить вожжи контроля.
3. Создать благоприятные условия для команды, чтобы она могла самостоятельно решать проблемы.
4. Не вмешиваться, когда возникают препятствия, доверять команде.
5. Сформировать новый набор навыков для формирования самоорганизованной и самоуправляемой команды, связанные со сферой эмоционального интеллекта, эмпатией, умению адаптироваться к новым обстоятельствам.

Итоги

Мы рассмотрели пример неудачного начала внедрения скрам и пришли к таким выводам:

1. Внедрять скрам в парадигме “руководитель-подчиненные” — грубая ошибка.
2. Прежде, чем внедрять Scrum, следует четко понимать разницу между каскадной моделью (waterfall) и итеративно-инкрементальным подходом.
3. Не нужно удерживать командира (инициатора, царя, босса, шефа, “лидера”, “начальника”), который не желает делиться властью и уменьшать вес собственной персоны в разработке продукта. Такие индивидуумы будут блокировать инициативу команды и создавать зависимость от должностного лица, вместо взаимозависимости между членами кроссфункциональной команды.
4. Лидеру команды не обязательно вмешиваться, когда возникает проблема или преграда. Лучше позволить команде самостоятельно найти решение.
5. Все ошибаются. Это нормально.
6. Не нужно верить в “идеальную команду”. Идеальные скрам-команды обычно существуют в книгах. Чрезмерная идеализация часто демотивирует, вместо того, чтобы мотивировать.
7. Мы хотим Scrum или его иллюзию?
8. Начинающим важно иметь наставника, чтобы ускорить переход на скрам.
9. Задача лидера в парадигме Scrum — создать среду, что делает возможным продуктивную работу команды.

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live