Перевод публикуется с сокращениями, автор оригинальной статьи David Pereira.
Помимо неудовлетворенных организаций, опытные профессионалы тоже неохотно работают со Scrum. Компании хотят быть гибкими, но изо всех сил пытаются отказаться от старого стиля управления и контроля.
Scrum – это не процесс!
Разработка программного обеспечения все еще является относительно новым явлением: первые попытки начались только в 1948 году – Том Килберн не мог бы себе представить, как быстро мир будет развиваться с созданием софта.
Ученый-компьютерщик Том Килберн отвечал за написание самого первого в мире программного обеспечения, которое было запущено 21 июня 1948 года в Манчестерском университете.
До нового тысячелетия компаниям не хватало техники, чтобы соответствовать ожиданиям клиентов. Большинство сосредоточились на совершенствовании процессов разработки. Несмотря на все усилия по внедрению тяжелых процессов, таких как Rational Unified Process, качество все еще оставалось сомнительным, а клиенты – недовольными. Создание бесполезного программного обеспечения разочаровало многих людей, а значит нужна была революция.
Учитывая ситуацию в начале нынешнего тысячелетия, был ли Scrum способен решить все проблемы с разработкой? Было важно понять первопричину, но многие компании проигнорировали этот шаг и решили найти новый процесс. Просто заменить процесс оказалось недостаточно – именно по этой причине большинство организаций не смогли извлечь выгоду из Scrum.
Возьмем футбол в качестве примера: «Барселона» выиграла 14 титулов за четыре года под руководством Пепа Гвардиолы. С 2008 по 2012 год клуб был лучшей командой в мире. Многие связывали успех с тем, как Гвардиола тренировал команду. Одним из примечательных аспектов была доминирующая игра – команда часто владела мячом 70% времени и более. Значит ли это, что достаточно применить «Tiki Taka» к другой команде, чтобы достичь аналогичных результатов?
Гвардиола тренировал мюнхенскую «Баварию» с 2013 по 2016 год и придерживался того же стиля, что и с Барсой. Тем не менее успех не был продублирован – он выиграл пять национальных титулов и ни одного европейского. Одного процесса недостаточно, чтобы достичь величия – нужно нечто большее.
Компании, которые рассматривали Scrum как процесс, потерпели неудачу. Ни одна гибкая структура не может привести команды к успеху без значительных изменений. Пока компании не решат свои проблемы, окружение не позволит командам преуспеть. Наиболее распространенными дисфункциями являются:
- отсутствие доверия;
- отсутствие направления;
- расстановка приоритетов на основе названия;
- микроменеджмент.
Scrum утверждает, что его легко понять, но трудно освоить. Многие специалисты согласны с этим утверждением, но следовало бы поспорить, так ли прост Scrum. Большая часть фреймворка часто игнорируется: попробуйте спросить у нескольких команд, какова ценность. Вы удивитесь, почти никто этого не знает. Тем не менее, ценности являются важной частью Scrum.
Успешное использование Scrum зависит от того, насколько люди станут более опытными в жизни с пятью ценностями: фокусировкой, сосредоточенностью, открытостью, уважением и смелостью.
Когда организации рассматривают Scrum как процесс реализации, неудачи неизбежны. По замыслу он является неполным, и ни одна команда не может добиться успеха, не адаптировав его к своему сценарию. Например, управление продуктами не является частью Scrum, но это ключевая дисциплина для такого процесса.
Чтобы добиться успеха с помощью Scrum, организации должны пройти через масштабную трансформацию. К сожалению, большинство руководителей не желают делать то, что требуется, чтобы подготовить среду, которая позволяет командам процветать. Существуют следующие парадигмы в бизнесе:
- расширение возможностей vs микроменеджмент;
- последствие vs результат;
- согласование vs консенсус;
- риск vs следование плану.
Топ-менеджеры считают слишком рискованным иметь полностью самоуправляемые команды. Вот почему Scrum терпит неудачу.
Руководители часто не могут наделить людей полномочиями, потому что они хотят сохранить контроль. Вот почему они идут кратчайшим путем. Меняют процесс выполнения, затем, если Scrum докажет свою ценность, изменяют культуру. Это не срабатывает, как задумывалось, результат – всеобщее разочарование. Когда Scrum становится процессом, роли мутируют до чего-то бессмысленного.
Владелец продукта
К сожалению, мутации роли Product Owner являются скорее правилом чем исключением. Вот почему интересно, может ли кто-то быть владельцем продукта Scrum и существует ли владелец продукта Scrum в корпоративном мире?
Сколько компаний вы можете назвать, где владелец продукта действительно имеет главное слово во всех решениях? И если у них нет последнего слова, являются ли они владельцами продукта? Тем не менее сотни тысяч людей со званием владельца продукта не владеют ни одним продуктом.
Помимо анти-паттернов можно обратить внимание на то, что многие ориентированные на продукт люди теряют интерес к роли владельца, т. к. им трудно связать ее с продакт-менеджером. Хотя компании часто нанимают владельцев продуктов, многие профессионалы стесняются называться так из-за распространенного мнения (Marty Cagan): владелец продукта – это не работа, а роль, и эта работа намного обширнее, чем предлагает Scrum.
Разработчики
Scrum претендует на автономию для разработчиков, но получают ли они это? Увы, такое редко случается. Как ни печально, большинство разработчиков получают приказы, следуют им и лишь в редких случаях имеют право заниматься задачами без дедлайна.
Scrum Master
Неизбежно мастера Scrum терпят неудачу, потому что они не могут способствовать необходимым изменениям, чтобы позволить Scrum процветать.
Мастер Scrum ничем не отличается от других ролей. Вряд ли можно найти человека, который может быть именно таким, как предлагает гайдлайн Scrum. Мастера Scrum обычно бессильны и не могут способствовать необходимым изменениям в организациях.
Выживет ли Scrum?
Многие опытные профессионалы устали от Scrum и потеряли веру в него. Они хотят чего-то другого – такие профессионалы ищут возможности поэкспериментировать с разными методиками.
Печальный исход может случиться, т. к. тайный агент SAFe готов занять трон.
Следует остерегаться SAFe, потому что это тяжелый процесс и он совсем не похож на гибкий подход. Как можно запомнить принципы работы этой тяжелой машины? Интересно, почему они осмеливаются называть это Agile?
Заключение
Роли Scrum уже не так очаровательны, как когда-то. Ошибочное восприятие методики во многих компаниях заставляет профессионалов сопротивляться работе с ней. В сценариях, где Scrum становится процессом, люди не хотят быть мастерами Scrum или владельцами продукта.
Достаточно смелые для серьезных изменений компании могут преуспеть в Scrum вне зависимости от происходящего. Речь никогда не идет об определении процесса: все дело в том, чтобы культура была сосредоточена на ранней доставке ценностей. Есть надежда, что некоторые смелые компании могут принять перемены, а наличие следующих признаков свидетельствует о движении в правильном направлении:
- CTO становится частью управляющей команды;
- топ-менеджеры сосредоточены на том, чтобы давать указания, а не инструкции;
- команды Scrum имеют право экспериментировать с различными альтернативами для достижения ключевых результатов;
- открытие продукта установлено, а руководители знают, что необходимо уделять должное время поиску требующих решения проблем.
Дополнительные материалы:
Комментарии