внедрение agile
Управление проектами Мысли вслух

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

-
26 июля, 2021

После статьи о мифах связанных с гибкими методологиями, было бы странно не порассуждать о том: как понять правильно ли проведено внедрение 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 “звездный игрок”. Также будет необходим умелый Скрам-мастер, который сможет донести старичкам, что им ничего не угрожает, и в то же время настроит новичков на уважительное отношение к более опытным. По возможности желательно еще и физически переместить команду из того места, где ранее сидела “звезда”.

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

ТЕГИ
RELATED POSTS

ОСТАВИТЬ КОММЕНТАРИЙ

Николай Сарры
Харьков, Украина

Меня зовут Николай, я руководитель проектов по внедрению Битрикс24 и его долгосрочному сопровождению. Лофт с заметками, статьями, идеями и мыслями по управлению проектами, использованию гибких методологий разработки. Здесь собраны мои мысли, решения, заметки и статьи. В основном по управлению проектами, PHP-разработке и используемым инструментам, обзоры прочитанных статей, тезисы посещенных конференций.