«Большинство из нас эгоисты высшего разряда!»: какие ошибки совершают компании, первый раз работая по Scrum

Гибкий подход к управлению проектами Scrum используется не только в ИТ-сфере, однако опыта его внедрения у белорусского бизнеса из реального сектора недостаточно. Эксперт по управлению проектами, директор компании «АйТи уит» Максим Якубович рассказывает, с какими сложностями сталкиваются такие компании, начиная работать по Scrum.

— Мода на использование гибкой методологии Agile для управления проектами наконец-то добралась и до нашего региона. За последние 4 месяца я, к примеру, сотрудничал с двумя компаниями. Одна из Беларуси, вторая — из России. Они в своих проектах опробовали Scrum — самый популярный подход в Agile.

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

Уверен, что в белорусских ИТ-компаниях, работающих на Запад, Scrum успешно используется (там давно придерживаются этого подхода). А вот для проектов, где заказчиками являются белорусские предприятия, для многих компаний из реального сектора Scrum пока в диковинку.

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

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

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

• Почти во всех командах, где мы начинали использовать Scrum, скрам-мастера, имеющие опыт работы руководства проектом, продолжали вести себя как руководители, принимая большинство решений по проекту самостоятельно. Это противоречит подходу Scrum. А те из них, кто не имел опыта управления проектами, вообще не понимали, что им делать в роли скрам-мастера
• Владельцы продукта зачастую не понимают, как вносить изменения в журнал продукта (список пожеланий владельца продукта, из которых формируются задачи), как расставлять в нем приоритеты
• Учредители компаний, в которых запускались проекты по Scrum, не будучи назначенными владельцами проекта, ведут себя так, как должен вести себя владелец проекта в этой роли
• Чаще всего формально назначенный владелец проекта сталкивается с отсутствием полномочий и доверия к нему для принятия результатов по спринтам (выполненным этапам работы). Это приводит к возникновению у него ощущения, что Scrum — очередная «игрушка» собственника

2. Участники команды проекта не понимают сути процессов и документов, используемых в Scrum. И потому не осознают, что Scrum — это системный подход.

Большинство команд «пилотных проектов», с которыми я работал, не использовали ежедневные митинги (совещания) до моего прихода. И даже когда мы это внедрили, одна из команд через пару спринтов приняла решение проводить их раз в неделю. Только в одной команде на протяжении двух спринтов участники проводят ежедневные митинги и пока не собираются менять их частоту. Например:

• Некоторые команды не проводили ретроспективы (демонстрация реализованного во время спринта функционала и обсуждение результатов). При этом, в нескольких первых ретроспективах я обычно участвовал в роли модератора, чтобы показать команде и скрам-мастеру, как это делается
• Команды не используют BurnDown chart (диаграмма, которая показывается объем выполненных задач и оставшейся работы). Лишь в одной компании в пилотном проекте начали использовать этот инструмент — команда сама доработала программу, которая помогает создавать такую диаграмму. В остальных компаниях ИТ-подразделения не оказали никакого содействия командам пилотных проектов, чтобы автоматизировать работу с этой диаграммой. А вести ее вручную команды сочли слишком трудоемким

3. Журнал продукта часто ведется «для галочки», из него команда не может понять, над чем она будет работать в ближайшие 2−3 спринта. И тем более никто не понимает, когда, с учетом скорости работы команды, пожелание из журнала продукта попадет в какой-то конкретный спринт.

В некоторых командах во время обсуждения результатов работы выяснялось − участники команды не поняли, что журнал продукта должен показывать:

• Чем они будут заниматься в ближайшие пару спринтов
• Сколько работы осталось до конца проекта

Как правило, это происходило в командах, участники которых не проходили специализированного обучения по Scrum и изучали его самостоятельно по книгам и статьям.

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

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

5. Навыки оценки объемов работ отсутствуют практически у всех начинающих работать по Scrum команд.

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

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

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

Чем это плохо? Участники команды при планировании спринта отслеживают свою загрузку, и при достижении порога загрузки говорят владельцу продукта: «Следующую по важности задачу из журнала продукта мы взять не можем, т.к. наш сотрудник уже перегружен». А на вопрос, может ли кто-то вместо сотрудника сделать эту задачу, участники команды «делают большие глаза» и произносят убедительные речи о том, что этот специалист в команде не заменим. В итоге владельцу продукта приходится отказываться от планирования важных задач в спринт. И думать, чем же загрузить всех узкоспециализированных участников команды.

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

Это предсказуемая проблема: как только сотрудник не находит места для проявления своих амбиций в новой модели командной работы, он начинает саботировать внедрение нововведений.

Большинство из нас — эгоисты высшего разряда, и разделять общие цели и ответственность за результат совместного труда — это лозунги и пустые слова.

Через пару месяцев я еще раз отрефлексирую полученный опыт внедрения Scrum, по завершению проектов, и дам пару дельных советов тем из вас, кто становится на путь Agile.

Ведь правильное использование подхода Scrum на самом деле может дать великолепный результат, но, как написано в Scrum guide: «Скрам является: компактным, простым для понимания, трудным для совершенного овладения».

Успехов вам в реализации проектов и в овладении искусством быть Agile!

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами — с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Приглашенный преподаватель компании «Инфопарк-проект». Опыт преподавания — с 2005 года, за это время около 2300 студентов прошли обучение на его семинарах. Ведущий блога по управлению проектами.