Внедрение Agile. 11 особенностей

После статьи о мифах связанных с гибкими методологиями, было бы странно не порассуждать о том: как понять правильно ли проведено внедрение Agile, какой фреймворк когда стоит применять, кто в компании должен быть ответственным за переход на Agile.

Особенности внедрения Agile я разделил на две категории:связанные с компанией и связанные с командами.

Как специфика компании влияет на внедрение agile?

Особенность №1. Отраслевые предпочтения гибких методологий.

Как показывают исследование, например Agile Russia, в сфере разработки ПО используется в основном Scrum, финансовые учреждения предпочитают Канбан, в телекоммуникационных компаниях встречаются и Скрам и Канбан.

На мой взгляд такая ситуация обусловлена следующими причинами:

• Скорость изменений в IT гораздо выше, чем в финансах. Необходимость в точных метриках для проведения изменений в финансах выше чем в IT. IT-компании предпочитают Scrum поскольку им необходимы быстрые эксперименты, гибкое управление приоритетами, возможность сменить вектор развития в зависимости от внешних изменений и входных данных. Финансовые компании более консервативны..
• Стоимость ошибки в финансах куда выше, чем в IT. Поэтому для них предпочтительнее Канбан, основанный на математике и статистике, а не на экспериментах. Канбан позволяет проводить небольшие постоянные изменения улучшающие рабочий процесс в целом.

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

Особенность №2. Внедрение Agile в мобильной разработке.

Основная сложность разработки мобильных приложений – определение требований к приложению. Сложно на этапе проектирования определить заинтересованных лиц. Эти трудности можно преодолеть используя customer development для проведения исследования клиента и Scrum для анализа продуктовых гипотез.

Customer development – подход к созданию продукта через постоянное тестирование на реальном рынке и проведение изменений по результатам экспериментов. Этот подход чем-то напоминает научный метод, что делает процесс создания продукта научно обоснованным. CustDev – один из элементов методологии Lean Startup, которая является один из Agile-подходов к созданию продуктов.

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

Помимо Scrum здесь применимы подходы предназначенные именно для мобильной разработки. К примеру, подход Mobile-D основан на XP, Crystal и RUP – довольно старых и отработанных подходах. Основным отличием Mobile-D от Scrum является наличие четких фаз и смещение главного акцента на инженерную сторону развития продукта. Mobile-D больше сосредоточен на процессе производства продукта, благодаря практикам XP и позволяет формализовать процесс, что обеспечивает RUP.

Другой подход к мобильной разработке – SLeSS, совмещается Scrum и Lean Six Sigma. Постановка рабочего процесса в этом подходе осуществляется по Scrum, а затем подходы Lean Six Sigma подключаются для управления качеством. SLeSS сочетает гибкость механизма принятия решения с принятием решений на основе статистики.

Однако следует помнить, что Scrum Guide не запрещает включать в рабочий процесс какие-то другие подходы кроме Scrum, как и инструменты, которые могут быть полезны для создания продукта. Поэтому вы можете сочетать “классический” Scrum, с тем, что больше подходит вам.

Особенность №3. Модификация под частные условия.

Рассмотрим отдельно Scrum и Канбан.

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

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

Особенность №4. Применять инструменты нужно с пониманием их использования.

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

Например при внедрении Scrum просто переименовывают менеджера проекта в владельца продукта, а проектную команду в scrum-команду и требуют результатов каждые две недели. Это по каким-то причинам не работает и внедрение Scrum сворачивается, потому что “Scrum не работает”. Но давайте разберемся, почему это происходит:

• Переименование менеджера проекта в Владельца Продукта не дает ему полномочий, а значит он не может формировать видение, менять приоритеты реализации. Он по прежнему должен согласовывать свои действия с вышестоящим руководством и вдобавок зажат рамками требований, сроков, объемом работ. Скорость принятия решение не изменяется. Ускорения и адаптации к изменениям не происходит.
• Проектная команда после переименования в Scrum-команду, тоже не претерпевает никаких более изменений. Сотрудники продолжают находиться в тех же отделах, что и до переименования, а значит продолжают подчиняться свои линейным руководителям, а не Владельцу Продукта напрямую. Следовательно задачи по продукту будут иметь приоритет ниже чем задачи отдела, соответственно скорость реализации продукта никоим образом не повышается.
• Ко всему этому добавляется еще и то, что ни о какой работе команды над одним конкретным проектом речь не идет. Каждый участник команды может быть задействован где-то еще. При том, что Скрам четко оговаривает, что участники команды 100% своего рабочего времени занимаются только тем продуктом, который ведет их Владелец Продукта. Если люди поделены между проектами/продуктами, то они переключаются между ними, что резко снижает вовлеченность, и как следствие эффективность работы над каждым конкретным проектом/продуктом.

Негативных последствий у такого неумелого внедрения множество. Источником является попытка воспроизвести механику, но не суть Scrum.

Особенность №5. Гибкая методология должна быть грамотно внедрена в компанию.

С учетом того, что основа Scrum – командная работа,а приоритетом является скорость поставки продукта потребителю, для проверки успешности внедрения правильнее всего проводить опросы 360.

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

Особенности связанные с командой

Особенность №6. Инициатива внедрения должна исходить от бизнеса.

Внедрение Scrum всегда начинается с бизнес-цели. Поэтому в первую очередь об ускорении процесса должен задуматься заказчик – внешний либо внутренний. Необходимо проработать концепцию продукта таким образом, чтобы его можно было выпускать итеративно. После этого и только после этого, можно начинать формировать команду. Подход “Scrum ради Scrum” не работает. Он приведет к трате ресурсов на решение задач без достижения желаемого результата.

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

Идеальным случаем является когда инициативу проявляет топ-менеджмент.

Особенность №7. Обязательные и опциональные роли и функции, связанные с гибкой методологией.

Например в случае со Scrum это: Scrum Master, владелец продукта, scrum-команда. Все эти роли обязательны. Команда разработки – это также “роль”, поскольку она объединяет всех лиц задействованных в процессе работы над продуктом: аналитиков, дизайнеров, программистов, тестировщиков и т.п.

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

Владелец продукта – это чаще всего, но не обязательно, человек от бизнеса.  Если мы скажем создаем инженерное решение для производства, то в этой роли может выступать главный инженер. Если мы создаем решение для бухгалтерии, то главный бухгалтер. Простыми словами – это человек, который лучше всех понимает, для чего и кого мы делаем продукт, какие проблемы собираемся решать с его помощью, какой приоритет должен быть у задач при его реализации. Важно чтобы у владельца продукта были необходимые полномочия для самостоятельного определения состава продукта. Он должен иметь право говорить “нет” всем заинтересованным лицам с которыми он взаимодействует. Это необходимо для согласованности приоритетов и оперативного принятия решений.

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

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

Пример. К руководителю приходит подчиненный и говорит “Я не могу выбрать вариант реализации. Выбери ты.”. Если использовать наставнический подход, то необходимо задать вопросы “Почему именно эти варианты?”, “В чем сложность выбора?”, “Какие сильные и слабые стороны у каждого?” и так далее. С помощью таких вопросов руководитель, помогает сотрудники провести исследование. В итоге человек сам понимает как выбор следует сделать и договориться о сроках с руководителем.

После делегирования идет – визирование. При визирующем подходе команда выходит на уровень ответственности при котором, руководитель осуществляет только верхнеуровневую постановку задачи с позиции бизнеса. Команда самостоятельно определяет варианты решения, оценивает сроки, выявляет риски. Руководитель остается только визировать это и возможно добавить что-то с позиции экспертизы и внести при необходимости коррективы. Затем стороны договариваются о сроках показа результатов. Далее команда несет ответственность за реализацию и представление результатов. При визирующем подходе руководитель выступает в роли куратора для команды в рамках реализации бизнес-задачи.

Еще может быть Agile-консультант. Его задачи: настройка рабочего процесса, обучение людей работы в нем, предоставление инструментов для деятельности в рамках методологии, в том числе и для решения конфликтных ситуаций. В идеале, он должен выполнить свою работу таким образом, чтобы в дальнейшем его участие вообще не требовалось.

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

При масштабировании могут вводиться дополнительные роли, но в их основе все равно должны лежать принципы работы Scrum-мастера или владельца продукта, просто они располагаются на своем уровне иерархии относительно продукта.

Особенность №8. Разграничение функций владельца продукта и Scrum-мастера.

Нередко когда компания внедряя Scrum вешает роль скрам-мастера и владельца продукта на одного человека. Чаще всего это происходит из экономии. Но это кардинально разные роли с различными зонами ответственности.

Scrum-мастер отвечает за жизнеспособность и эффективность команды, в то время как владелец продукта несет ответственность за соблюдение интересов бизнеса.

Чтобы команда достигала успешных результатов необходимо чтобы система была в балансе. Если “передавит” владелец продукта, команда будет перерабатывать и в результате мы получим демотивированных и не вовлеченных сотрудников. Если “пережмет” скрам-мастер, то разработка будет идти кое-как с постоянными обсуждениями дольше положенного времени.

В идеальном мире, картина должна выглядеть следующим образом. Итак, представим себе что перед началом очередного спринта встречаются Скрам-мастер (СМ) и Владелец Продукта (ВП).

ВП: Нам нужно реализовать вот такую вот фичу! В прошлом спринте мы отлично поработали, так что я думаю, что все успеем!

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

ВП: Все так плохо? Тогда давай обсудим с командой, нужно определить что мы можем сделать за спринт, не прибегая к переработкам. Нужно определить, что в этой фиче мы можем выполнить, что не выглядит сложным. Она должна быть хотя бы частично реализована в обязательном порядке.

СМ: Согласен. Только команда может решить это. Я подготовлю встречу.

ВП: Отлично.

Особенность №9. Сотрудник собирающийся примерить одну из описанных ролей должен освоить методологию и управленческую модель.

В том что касается бизнес-компетенций отличий от классического менеджмента нет никаких, за исключением определения приоритетов по этапам и более тесного взаимодействия с командой.

Владелец продукта должен освоить Lean Startup, Customer Development и прочие подходы к созданию продукта, чтобы при старте разработки нового выбрать наиболее подходящую методологию или инструменты.

Скрам-мастер должен обладать более широким спектром навыков среди которых: фасилитация, конфликтология, групповая динамика, коучинг, консалтинг, практика Agile. В целом ему не требуются какие-то технические знания, а больше навыки из области психологии.

Особенность №10. Коллективное владение кодом.

Это возможно и без гибких методологий. Достаточно договориться о code review и прочих формальных правилах. Разработчики при этом могут продолжать действовать независимо.

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

Вопрос о найме “Звезды” это выбор между краткосрочным и долгосрочным успехом. В первом приближении  найм “звезды” выглядит как спасательный круг для бизнеса. Но задумайтесь, что произойдет через три, пять, десять лет? Он станет незаменимым, а вы столкнетесь со следующими проблемами:

• У “Звезды” нет свободного времени. Частично это провоцирует сама компания “Мы платим тебе большую зарплату не за отдых”. Это приводит к тому, что человек либо выгорает, либо становится циником и извлекает максимум выгоды для себя из этого положения.
• На “Звезду” нет рычагов воздействия. В долгосрочной перспективе такой сотрудник начинает управлять приоритетами компании. Вместо того, чтобы решать бизнес-задачу, он самостоятельно принимает решение, что будет делать, а что нет. За несколько лет работы он узнал все о продукте и системе, и самое страшное – он знает о них больше чем кто бы то ни был еще. Такие специалисты не спешат и не хотят делиться знаниями, они держат эти знания в себе и используют их как страховку или рычаг давления при угрозе увольнения или понижения зарплаты, а иногда и для повышения в должности или повышения зарплаты.
• Вы потеряете масштабируемость. Вы не сможете ускорить разработку, если “звезду” все устраивает как есть и она не собирается ничего менять. Если вы наберете новичков, то вас ожидает разочарование и большая текучка, поскольку новичкам будет некомфортно работать в среде, где им никто ничем не хочет помогать, поскольку “звезды” не хотят делиться опытом и знаниями, ведь им не нужны конкуренты.

Особенность №11. Командный подход.

• Примите риск того, что вы потеряете “звезд”. Не все сотрудники согласятся с новым подходом. Это неизбежно.
• Изменить структуру посещений. Например, ввести бонусы за написание документации или за обучение новых сотрудников, чтобы это стало обыденной практикой.
• Найти “звезд”, которые хотят расти и готовы делиться своими знаниями и опытом и помочь им освоить навыки менеджмента, фасилитации, коучинга. Показать им новые возможности. Не все согласятся. Но те кто согласится будут хорошими приверженцами нового подхода к работе.
• Размывать сложившиеся команды вырывая “звезд” из привычной среды. Следить чтобы в команду из 4-5 человек был всего 1 “звездный игрок”. Также будет необходим умелый Скрам-мастер, который сможет донести старичкам, что им ничего не угрожает, и в то же время настроит новичков на уважительное отношение к более опытным. По возможности желательно еще и физически переместить команду из того места, где ранее сидела “звезда”.

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