eFusion 21 апреля 2021

🗣 Извините, Scrum, для вас игра окончена!

Рынок движется в новом прогрессивном направлении: может ли Scrum найти свое место под солнцем? Попробуем ответить на этот вопрос.
🗣 Извините, Scrum, для вас игра окончена!

Перевод публикуется с сокращениями, автор оригинальной статьи David Pereira.

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

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

Scrum – это не процесс!

Разработка программного обеспечения все еще является относительно новым явлением: первые попытки начались только в 1948 году – Том Килберн не мог бы себе представить, как быстро мир будет развиваться с созданием софта.

Ученый-компьютерщик Том Килберн отвечал за написание самого первого в мире программного обеспечения, которое было запущено 21 июня 1948 года в Манчестерском университете.
Мика Йост, A Brief History of Software Development

До нового тысячелетия компаниям не хватало техники, чтобы соответствовать ожиданиям клиентов. Большинство сосредоточились на совершенствовании процессов разработки. Несмотря на все усилия по внедрению тяжелых процессов, таких как Rational Unified Process, качество все еще оставалось сомнительным, а клиенты – недовольными. Создание бесполезного программного обеспечения разочаровало многих людей, а значит нужна была революция.

Хотя гибкие фреймворки, вроде Scrum и eXtreme Programming, уже существовали, в 2001 году появился Agile Manifesto, значительно повлиявший на разработку софта во всем мире. После этого методика Scrum стала популярна.

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

Возьмем футбол в качестве примера: «Барселона» выиграла 14 титулов за четыре года под руководством Пепа Гвардиолы. С 2008 по 2012 год клуб был лучшей командой в мире. Многие связывали успех с тем, как Гвардиола тренировал команду. Одним из примечательных аспектов была доминирующая игра – команда часто владела мячом 70% времени и более. Значит ли это, что достаточно применить «Tiki Taka» к другой команде, чтобы достичь аналогичных результатов?
Гвардиола тренировал мюнхенскую «Баварию» с 2013 по 2016 год и придерживался того же стиля, что и с Барсой. Тем не менее успех не был продублирован – он выиграл пять национальных титулов и ни одного европейского. Одного процесса недостаточно, чтобы достичь величия – нужно нечто большее.
🗣 Извините, Scrum, для вас игра окончена!

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

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

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

Успешное использование Scrum зависит от того, насколько люди станут более опытными в жизни с пятью ценностями: фокусировкой, сосредоточенностью, открытостью, уважением и смелостью.
The Scrum Guide

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

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

  • расширение возможностей vs микроменеджмент;
  • последствие vs результат;
  • согласование vs консенсус;
  • риск vs следование плану.
Топ-менеджеры считают слишком рискованным иметь полностью самоуправляемые команды. Вот почему Scrum терпит неудачу.
Виллем-Ян Стареет, Scrum has hit the glass ceiling

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

Владелец продукта

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

К сожалению, мутации роли Product Owner являются скорее правилом чем исключением. Вот почему интересно, может ли кто-то быть владельцем продукта Scrum и существует ли владелец продукта Scrum в корпоративном мире?

Сколько компаний вы можете назвать, где владелец продукта действительно имеет главное слово во всех решениях? И если у них нет последнего слова, являются ли они владельцами продукта? Тем не менее сотни тысяч людей со званием владельца продукта не владеют ни одним продуктом.
Мартен Дальмайн, Will the real product owner please stand up

Помимо анти-паттернов можно обратить внимание на то, что многие ориентированные на продукт люди теряют интерес к роли владельца, т. к. им трудно связать ее с продакт-менеджером. Хотя компании часто нанимают владельцев продуктов, многие профессионалы стесняются называться так из-за распространенного мнения (Marty Cagan): владелец продукта – это не работа, а роль, и эта работа намного обширнее, чем предлагает Scrum.

🗣 Извините, Scrum, для вас игра окончена!

Разработчики

Разработчики – люди, которые сами решают как делать свою работу. Они отвечают за реализацию, за технический стек и т. д. Это прекрасная теория, но на практике такое бывает редко. Обычно есть Chief Technology Officer (CTO), технический руководитель или кто-то еще, кто не только принимает решения, но и управляет разработчиками.

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

Scrum Master

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

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

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

Выживет ли Scrum?

Многие опытные профессионалы устали от Scrum и потеряли веру в него. Они хотят чего-то другого – такие профессионалы ищут возможности поэкспериментировать с разными методиками.

Страх перед переменами со стороны руководителей мешает Scrum-командам процветать. Последовательность неправильных решений и неправильных представлений может привести Scrum к закономерному концу. Высшее руководство не может оставить в прошлом свой неадекватный стиль командования и управления.

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

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

SAFe 5.0
SAFe 5.0

Заключение

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

🗣 Извините, Scrum, для вас игра окончена!

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

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

Дополнительные материалы:

Источники

Комментарии

ВАКАНСИИ

Добавить вакансию
Разработчик C++
Москва, по итогам собеседования

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ