В шапке
Сложности при внедрении подхода Scrum в компаниях, не занимающихся информационными технологиями

Сложности при внедрении подхода Scrum в компаниях, не занимающихся информационными технологиями

Мода на использование Agile для управления проектами наконец-то докатилась и до нашей страны: за последние 4 месяца я уже помог в двух компаниях (одна из Беларуси, вторая – резидент России) на примере двух проектов опробовать Scrum – самый популярный подход из Agile.  В данный момент я помогаю еще в четырех компаниях внедрять этот подход, и по итогу уже есть наблюдения, которыми хочется поделиться.

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

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

Коротко о подходе Scrum я уже писал здесь

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

Отмечу, что список составлен без учета масштаба или важности проблем, а под каждым описанием проблемы дается краткая ее расшифровка:

1. Сотрудники проекта, выполняющие роли владельца продукта и скрам-мастера, не понимают свои функции и не осознают основную цель, которую должны реализовать, выполняя  свою роль.

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

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

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

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

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

Еще один пример непонимания и игнорирования рекомендуемых инструментов – команды не используют BurnDown chart.  Лишь в одной компании в пилотном проекте начали использовать BurnDown chart, т.к. сама команда быстро доработала используемый для проектной деятельности программный продукт в части создания этой диаграммы. В остальных компаниях ИТ-подразделения не оказали никакого содействия командам пилотных проектов в автоматизации ведения диаграммы BurnDown, а вести ее вручную команды сочли слишком трудоемким.  

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

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

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

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

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

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

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

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

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

Предсказуемая проблема: как только сотрудник не находит места для проявления своим амбициям в новой модели командной работы, он начинает саботировать внедрение нововведений. Большинство из нас – эгоисты высшего разряда, и разделять общие цели и ответственность за результат совместного труда – это лозунги и пустые слова.

Надеюсь, у меня хватит сил написать еще одну статью через пару месяцев, чтобы еще раз отрефлексировать полученный опыт внедрения Scrum и дать пару дельных советов тем из вас, кто становится на путь Agile. Ведь правильное использование подхода Scrum  на самом деле может дать великолепный результат, но, как написано в Scrum guide: «Скрам является: компактным, простым для понимания, трудным для совершенного овладения».  Раз не получается внедрять Agile самостоятельно, ищите тренеров, которые имеют опыт внедрения этого подхода.

 

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

 

Комментарии (0)
Войти как