Внедрим AGILE в сжатые сроки! Как ошибка в слове СРоКИ повысила вовлеченность сотрудников

Внедрим AGILE в сжатые сроки! Как ошибка в слове СРоКИ повысила вовлеченность сотрудниковАвтор: Артур Леонов, Лига Цифровой Экономики, эксперт по digital-трансформации процессов компаний

Это вторая часть из цикла статей, посвященных вопросу использования AGILE в производстве нематериальных продуктов. В первой части постарался максимально кратко рассказать историю возникновения самого понятия AGILE. И подчеркнуть, что это не методология, а ментальная установка, ставящая во главу угла Человека, а не процессы и регламенты, и оценивающая его профессионализм и умение работать в команде, как главное мерило его достижений.

Начиная со второй половины 00-х годов весь, ИТ мир буквально взрывали новости  о новых победах AGILE! С его помощью, как утверждают эксперты, можно повысить эффективность в десять раз, надо срочно внедрять его у себя или ваша корпорация обречена на провал!  Такой же слоган ворвался  на рынок интеллектуальных продуктов несколько лет назад и у нас в стране.   Своей широкой популярностью AGILE в России обязан начинаниям Германа Оскаровича Грефа, именно он стал главными драйвером этого слова. Журнал Forbes постарался дать свое видение AGILE манифеста 

Еще масла в огонь подлил перевод книги, опубликованной в России под заголовком «Революционный метод управлением проектами». Как видите, в оригинальном названии автор  не употребляет слово PROJECT. Но для многих Прожект Менеджеров она стала настольной книгой.

 

Внедрим AGILE в сжатые сроки!

 

Сразу уточню – это хорошая книга, которую я рекомендую к прочтению.  В ней описаны рабочие методы, которыми я пользуюсь в текущей работе, несмотря на то, что я считаю, что использование Софт-Канбан более эффективным.

Основная мысль книги –  как выполнить сложнейшие проекты в условиях катастрофической нехватки времени, когда единственный выход — это повышение эффективности текущей команды.  Свое решение Джефф назвал SCRUM. И да,  Джефф не призывает отказаться от проектного управления. Он лишь утверждает, что держаться за  диаграммы Ганта, оторванные от реальной картины мира, и тратить 90 процентов времени на согласование изменений – тупиковый путь. Команда вместе с заказчиком должна оперативно решать, что делать в текущий момент.  Несмотря на то, что  сам метод SCRUM появился за 6 лет до рождения AGILE манифеста, сейчас между ними пытаются поставить знак «равно». Я думаю, что  ключевая причина доминирования SCRUM над остальными методами гибкой разработки,  например  над ХР – это  кажущаяся простота внедрения. Вам надо только назначить скрам-мастера и продукт-оуненера и посадить их в месте с командой разработчиков.  Как будут чувствовать себя сотрудники при таких экспериментах, уходило на второй план. Перспективы повысить скорость разработки в два и более раз, убрав при этом высокооплачиваемого проект-менеджера, были слишком привлекательными, чтобы сразу не попробовать.

 

Сейчас мы видим закономерный результат такого подхода. В большинстве случаев утерян главный фокус AGILE на ЧЕЛОВЕКА, его индивидуальность, но работу в команде

 

Теперь первое, что я делаю, услышав от собеседника фразу: «Мы работаем по AGILE  — это прошу рассказать о действиях по AGILE. В 90 процентах случаев я слышу про небольшие команды от 5-7 человек (иногда 30), работу строго по спринтам, ежедневные стенд-апы. Как вы помните,  (из моей прошлой статьи) это артефакты SCRUM. Еще более грустно услышать тишину, задав вопрос про AGILE манифест или услышать: «А это разве не он?»

 

Как это могло случиться, почему произошла подмена смысла?

Как я вижу, это закономерное следствие желания получить быстрый результат без погружения в суть решаемой проблемы. Появился некий хайп — AGILE. Команды, которые внедрили у себя данный метод разработки, упомянутые авторами AGILE манифеста, добились выдающихся результатов. Многие захотели попробовать этот опыт у себя. Как правило, самым доступным способом внедрить у себя AGILE —  было нанять сотрудников из организации, в которой уже есть AGILE культура. Если это были разработчики, работающие по SCRUM, то AGILE превращался в SCRUM, так как они находились уже внутри системы и не могли объяснить,  какие базовые ценности находятся во главе угла.

Ситуация еще больше усугублялась тем, что на роль SCRUM master назначали даже не менеджера, а тимлида, то есть самого сильного разработчика в команде, в результате фокус еще больше смещался на процесс разработки и поддержание ритуалов.  Новичков, приходящих в такие команды, подкупало видимое отсутствие руководства и явного контроля с его стороны. Это, в свою очередь, приводило к потере фокуса на конечный результат, сроки и качество. И, как следствие, вызывало резкую критику уже SCRUM,  как метода разработки, и всего AGILE в целом.

На западе, осознав проблему, постарались ее решить, создав институт сертифицированных AGILE-coach, которые, помимо практического опыта, проходили соответствующее обучение и тестирование. Для нашей страны этот процесс был затруднен тем, что, например, получить сертификат ICP в России стало возможно только в конце прошлого года, а для подтверждения своих знаний по Софт-Канбан придется ехать в Европу. Это привело к очень большому числу самопровозглашённых  Аджаил-коучей со своим видением на AGILE.

В результате даже один самых эффективных подходов – Scrum, начал претерпевать изменения в угоду существующей структуре или интересам внедряющих этот метод. Так, например, скрам-команда могла быть в тридцать человек (полная потеря связей внутри команды) или отказ от одного из главных артефактов, улучшающих процесс и продукт, — ретроспективы. Как показал мой грустный  опыт в отечественной среде, даже среди руководителей ИТ компаний под AGILE  подразумевают один из методов гибкой разработки, забывая о главном фокусе на человека, выраженном в AGILE Манифесте.

Как очевидно из всего выше сказанного, произошла подмена понятий. И именно эта подмена является одной из основных причин такого большого количества проваленных проектов, которые пытались реализовать по SCRUM.  Во многих книгах и статьях подробно разобрано, какие ошибки бывают, когда руководство не вовлечено  или вовлечено формально в процесс трансформации подразделений, занимающихся разработкой нематериальных продуктов. Все они подробно разбирают частные случаи, когда, например, руководство не приходит на демонстрации готового продукта или отменяет ретроспективы, а вместо планирования, проводимого всей командой, навязывает ТЗ. Безусловно, это показательные примеры, но, если посмотреть на картину в целом, то становится очевидным пренебрежение и невнимание к главному ресурсу любой корпорации, занимающейся созданием интеллектуальных продуктов – человеку.

 

 Внедрение любого из методов гибкой разработки без вовлечения сотрудников приведет к сильному сопротивлению и желанию саботировать процесс или просто уйти

 

Даже декларативное внедрение Софт-Канбан может приводить к сопротивлению, несмотря на главную парадигму Софт-Канбан: уважение к людям и текущим процессам.  Безусловно, без поддержки высшего руководства, внедрение новых методов управления производством, а в особенности AGILE-методов, требующих для их эффективной работы глубокой трансформации ценностей организации, задача практически невыполнимая.

Поэтому я искренне призываю всех руководителей, собирающихся начинать процессы трансформации в своих организациях, очень внимательно изучить базу, на которой основывается как успех внедрения методологий AGILE, так и провал очень многих проектов. Помните, ни одна методика не сможет поднять эффективность сотрудника, занятого интеллектуальным трудом, без его вовлеченности и желания работать по новым правилам.

Чем выше интеллект и творческий потенциал сотрудников, тем изощреннее они будут убивать все плюсы нового подхода и дискредитировать его в глазах остальных коллег и руководства

 

Помните также, что если вы, как руководитель, не сможете донести и продать те преимущества, которые скрывают в себе методики AGILE, самые талантливые, но не вовлеченные, очень быстро найдут все слабые места и воспользуются ими уже в своих личных интересах, которые уже никак не будут пересекаться с интересами компании. Вы — руководитель и вы должны не только помнить принципы AGILE манифеста, но и руководствоваться ими при принятии даже самых непростых решений. Помните, манифест придумали разработчики, он не отрицает ни организаций, ни регламентов, ни договоров. Он говорит, что в первую очередь надо смотреть на личность, команду, состоящую из личностей. Анархия и попустительство так же вредны, как и жесткие регламенты и планы, потерявшую всякую актуальность, но которым заставляют следовать. Вам необходим баланс, терпение и вера в свою команду.

Оглядываясь назад, я отчётливо вижу, что те фантастические успехи, которых добилась моя команда, в первую очередь связаны с духом взаимного уважения и открытости. Мы просто верили в себя и знали, что мы лучшие и нам по плечу сделать этот проект, я был экспертом в решении одних задач и новичком в других, и все мы были готовы помочь друг другу. Мы добровольно трудились иногда по 18-20 часов в сутки, потому что мы взяли задачу и теперь должны ее выполнить. Без такой установки я не верю в возможность создавать достойные решения и выполнять фантастические проекты. Мне потребовалось достаточно много времени, чтобы осознать главный источник нашего успеха. К сожалению, и я очень долго уходил вначале от XP, затем от SCRUM. Теперь я отдаю предпочтение  Soft-Kanban, как самому экологичному методу, фундаментом в котором служит уважение к людям.

 

Видео. Что Agile меняет в работе с сотрудниками?

 

В завершение я хочу рассказать одну историю: 

Один крупный руководитель решил внедрить у себя в компании Аджаил, о чем решил сообщить всем сотрудниками, отправив письмо со следующим заголовком: «Внедрим AGILE в сжатые сроки!»  Он ошибся в слове СРоКИ, случайно заменив букву о на А. Получив письмо с таким заголовком, сотрудники  почувствовали, что год будет непростым. К счастью, директор и сам заметил свою ошибку. Он не стал оправдываться, а лично провел первую встречу с сотрудниками и экспертами по AGILE, извинился за свою опечатку и сам рассказал о принципах AGILE манифеста и том, что лично он разделяет эти ценности и руководствуется ими. Также он попросил давать лично ему обратную связь и информировать в случае возникновения организационных проблем.

 

Как результат, все сотрудники увидели новые возможности, которые дает AGILE. Это дало ощущение уверенности, безопасности и, как следствие, повысило вовлеченность.

Процесс трансформации начался с доверия и открытости, благодаря чему самый трудный первый этап, когда обычно возникает спад производства, связанный с освоением новых приемов и методов, прошел намного быстрее. Уже спустя несколько месяцев компании удалось решить ряд проблем, связанных со срывами сроков реализации и качеством своих продуктов.  Если есть вера в себя и команду, даже ошибки приносят на пользу.

 

Видео. Лидер в Agile и лидер традиционном понимании — в чем разница

 

Автор публикации

Коллеги ! Рады Вашим публикациям !
Зарегистрируйтесь в личном кабинете, как автор и самостоятельно ведите свою колонку ! Все уникальные статьи попадут в еженедельную рассылку.
Комментарии: 30Публикации: 1592Регистрация: 05-06-2013

Редакция

Коллеги ! Рады Вашим публикациям ! Зарегистрируйтесь в личном кабинете, как автор и самостоятельно ведите свою колонку ! Все уникальные статьи попадут в еженедельную рассылку.

Вам также может понравиться

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Авторизация
*
*
Войти с помощью: 
Регистрация
*
*
*
Пароль не введен
Войти с помощью: 
Генерация пароля