Scrum, каким его задумывали

В России и странах СНГ около 95% сотрудников, считающих что используют Scrum, не открывали и не читали 13-страничный Scrum Guide, не понимают даже основ этого фреймворка и предприятия, в которых они работают, этого от них не требуют.

Данная статья описывает Scrum максимально близко к официальной документации. Описание некоторых элементов представлено прямым переводом руководства. Сложные части руководства или части, которые можно свободно интерпретировать (как многие организации успешно делают) уточнялись информацией из работ и тематических исследований (Case Studies) Джеффа Сазерленда как основного продавца Scrum.

Статья состоит из двух частей. Первая — на этой странице, сфокусирована на том каким предполагался фреймворк и почему, а так же какие частые отклонения от него наблюдаются на предприятиях. Авторы статьи признают, что отклонения часто настолько сильные, что единственное что объединяет процесс в организации со Scrum это терминология. Вторая статья сосредоточена на исследовании ограничений, допущений и рисках, которые несёт Scrum организациям, использующим фреймворк.

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

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

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

Скрам сравнивает свой подход с типами жизненного цикла традиционного проектного управления, однако сам Scrum не является методикой или практикой управления проектами. При сравнении скорее имеется в виду парадигма порождения ценности, нежели само управление: проектное или продуктовое.

Для того чтобы понимать почему появились именно эти столпы, ценности, артефакты, мероприятия, команда и её правила и роли нужно вернуться в начало 80-х, когда Scrum обретал свою текущую форму.

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

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

В прогрессивной Японии взрыв рынка производства ПО следовал вслед за рынком производства аппаратного обеспечения. Профессоры Университета Хитоцубаси Hirotaka Takeuchi и Ikujiro Nonaka, изучавшие управление знаниями, наблюдали неоптимальность исторического подхода к разработке ПО и в 1986 разработали основы Scrum, вдохновляясь увиденными и тщательно исследованными практиками некоторых японских компаний (Хонда, Фуджицу-Ксерокс). Предприимчивые Jeff Sutherland, John Scumniotales и Jeff McKenna увидели возможности монетизации подхода, умышленно отступили от общепринятых в те времена терминов, заимствуя новые из регби, опубликовали в 1993 подход к разработке под названием Scrum, в 1995 представили его на конференции OOPSLA и начали активно готовиться к его продажам.

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

Несмотря на отсутствие планирования внедрения изменений процесса в явном виде среди столпов, оно является неотъемлемой частью планирования итераций разработки.

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

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

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

Спринт — это итерация разработки, по сути, проект/фаза проекта со многими его/её характеристиками.

Свойства спринта:

• все спринты одинаковой длины
• новый спринт обязан начинаться после завершения текущего (никакого отдыха!)

Все работы и задачи по разработке выполняются внутри спринта. Все мероприятия Scrum проводятся внутри спринта.

Вне спринтов нет Scrum. Вне спринтов — вакуум, нерегламентированный официальной документацией Scrum.

Во время течение текущего спринта:

• Нельзя менять цель спринта
• Нельзя вносить изменения, которые ставят под угрозу цель спринта;
• Нельзя допускать ухудшения качества инкремента, порождаемого в спринте;
• Состав продукта и его характерных особенностей
  • уточняется по мере необходимости;
  • уточняется или пересматривается с владельцем продукта по мере поступления дополнительной информации.
• Чем короче тем лучше
• Может быть отменён, если цель спринта стала неактуальной, но право отмены есть только у Владельца Продукта.

В первичных официальных методических пособиях говорится о длине от 3 до 6 месяцев. В современном мире со всеми дарами автоматизации, DevOPS культуры и open source спринты длиннее четырёх недель уже считаются спринтами курильщика.

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

Планирование Спринта — совещание Scrum-команды, которое часто носит характер мозгового штурма и направлено на нахождение ответов на следующие вопросы:

• Как спринт добавит стоимости продукту?
• Что можно успеть сделать?
• Как делать запланированную работу?

Результатом такого совещания является Бэклог Спринта (Sprint Backlog) — план, созданный разработчиками на спринт. План должен содержать как минимум:

• цель спринта, т.е. "почему мы это делаем?"
• задачи, которые необходимо завершить для достижения цели спринта и рождения инкремента с ожидаемым набором функциональностей, а также сложность или трудоёмкость задач. Помогает ответить на вопрос "что мы делаем?"
• план действий для успешного выполнения намеченных задач — "как мы это делаем?"

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

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

Бэклог спринта должен быть на виду и доступен любой заинтересованной стороне без отвлечения членов Scrum команды — помним о прозрачности.

Зачастую при оценке задач для определения объёма задач, которые команда может выполнить за спринт, используются безразмерные абстрактные величины. Story points являются примером таких величин.

Идея такого планирования в том, чтобы абстрагироваться от традиционных человеко-дней и за небольшое количество итераций методом проб и ошибок "почувствовать" скольких очков стоит та или иная задача, оценивая каждую всей командой в сравнении с предыдущими. Когда вся команда участвует в оценке задач каждого члена команды — ответственность как за конкретную оценку, так и за общую цель спринта возрастает.

Вопреки популярному мнению Scrum не обязывает использовать ни Story points ни другие абстрактные величины, однако крайне рекомендует именно эмпирическое планирование с учётом итеративной природы работы.

Эмпирическое планирование не запрещает использовать старые добрые человеко-часы.

Единая цель, которую стремится достичь сплочённая ею Scrum-команда за время спринта.

Свойства:

• появляется при планировании спринта;
• разработчики помнят о ней и учитывают её, решая задачи в течение спринта. Часто разработчикам рекомендуют задаваться вопросом "когда я сделаю эту задачу, она приблизит команду к цели спринта?";
• если план спринта по ходу прохождения спринта оказывается невыполнимым или неактуальным — команда совместно с Владельцем Продукта пересматривают план спринта, если это возможно без изменения цели спринта. В противном случае спринт отменяется и цель пересматривается.

Примеры Цели Спринта:

1. Исследовать и разработать прототипы пользовательского пути аутентификации;
2. Реализовать аутентификацию по стандарту OAuth;
3. Подключить способ аутентификации от Apple;
4. Позволить пользователю скрывать Сторис в мобильном приложении;
5. Добавить возможность собирать клиентские метрики приложения;
6. И даже так: Исправить все высокоприоритетные дефекты пром.среды для увеличения степени удовлетворённости клиентов

Типичные ошибки

Самая распространённая — отсутствие цели. Если у вашей команды нет корректно сформулированной цели спринта — вы не работаете по Scrum.

Ежедневная Схватка — совещание, цель которого: обзор и проверка прогресса продвижения к цели спринта и корректировка бэклога спринта при необходимости.

Такое совещание должно

• длиться не более 15 минут, независимо от длины спринта
• проводиться в одно и то же время каждый день

Scrum не предписывает специфическую технику проведения совещания.

Совещание призвано способствовать:

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

Такое совещание, или как его часто называют стендап (standup), нельзя отменить, однако допускается сдвиг по времени, если это единичный случай.

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

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

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

Вторая типичная ошибка — пытаться решить одну или все проблемы прямо на стендапе. Даже ограничение в 15 минут часто не останавливает упорных коллег с плохим пониманием Scrum от того, чтобы превратить короткий обзор статуса и сверку с планом в решение вопроса конкретного члена команды. Это неверный подход. Обозначенные на совещании проблемы должны быть зафиксированы в общедоступном месте и решены в рабочем порядке или на специально посвящённой этому встрече.

Обзор Спринта — совещание, часто носящее характер презентации с последующей сессией мозгового штурма, целями которого являются:

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

Совещание не должно длиться больше четырёх часов при месячном спринте.

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

Вторая частая ошибка — это превращение обзора спринта в приёмочное пользовательское тестирование.

Ретроспектива — совещание, направленное на обсуждение возможности улучшения качества и эффективности процесса разработки ПО. На ретроспективах редко присутствует кто-то кроме scrum-команды.

На совещании должно быть осуществлено

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

Ретроспектива завершает спринт, так что имеет смысл планировать её в последний день спринта.

Ретроспектива не должна длиться более трёх часов для месячного спринта.

Типичные ошибки

1. Не проводить совещание вовсе по разным причинам. Это противоречит целям, ценностям и столпам фреймворка и делает процесс чем-то иным, но не Scrum-ом.

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

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

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

Если применяются все мероприятия, используются все артефакты и роли Scrum, но отсутствует столп "приспособление/адаптация" со всеми вытекающими, то это не Scrum, а натягивание его терминологии на собственные закостенелые процессы.

Продуктовый Бэклог — упорядоченный список того, что требуется для развития продукта. Единый источник исполняемых работ Scrum-командой.

• За продуктовым бэклогом требуется ухаживать (grooming):
  • уточнять и декомпозировать, если это требуется для лучшего понимания и большей прозрачности
  • переприоритизировать элементы — по итогу анализа потребностей и требований бизнеса
• размер и оценка элементов бэклога определяется разработчиками
• владелец продукта помогает разработчикам понять контекст

Вопреки очень распространённому недопониманию бэклог не содержит задачи или работы. Это не Work Breakdown Structure из традиционной проектной деятельности. Однако бэклог содержит источник задач и работ.

Часто используемый тип описания бизнес-требований, так называемые пользовательские истории (user story), в своём классическом первоначальном смысле не являются задачами, но характеристикой ПО, функцией ПО или сценарием, вовлекающим множество функций или характеристик, или в простонародье "фичей" (feature), которую использует специфическая роль пользователя ПО.

Одна фича может породить и почти всегда порождает множество задач, таких как анализ и дизайн, разработка, установка и настройка на множество специализированных сред, тестирование разного рода (в зависимости от индустрии и режима работы ПО), верификация и валидация, приёмка, согласование комплаенсом и другими специализированными департаментами, если индустрия этого требует. Как несложно увидеть отношение пользовательской истории к задаче — один ко многим, и в редком частном случае — один к одному.

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

Цель продукта описывает будущее состояние продукта, относительного которого нужно планировать. Цель продукта в Бэклоге продукта.

Бэклог продукта подлежит уходу, чтобы доопределить и детализировать, что именно будет удовлетворять Цели продукта и с какой последовательностью (то есть приоритетом).

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

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

Свойства инкремента:

• удовлетворяет цели продукта
• не противоречит предыдущим инкрементам, а дополняет или изменяет
• имеет ценность, только если им можно пользоваться
• удовлетворяет определению готовности

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

Частые ошибки
Одна из хронических болезней многих организаций — это отсутствие цели. Наполнение бэклога всем подряд независимо от того, удовлетворяет ли элемент бэклога стратегии, целям организации, целям продукта (этого конкретного продукта, а не любого продукта организации) и ожиданиям заинтересованных сторон. Ещё реже проверяется непротиворечие бесцельной кучки пользовательских историй другим таким же других команд организации, из чего часто произрастают ситуации от смешных казусов до полных катастроф.

Иногда бэклог продукта используется как свалка идей любой степени безумия и актуальности: "появилась идея? заведи в бэклог продукта!". Из-за этого в бэклоге может лежать никому не нужный функционал — так называемая лазейка в скоупе (scope creep) , который никак не выделяется относительно других реальных обоснованных требований. Такой подход делает уход за продуктовым бэклогом долгим и сложным, а порой и совсем невозможным, если цели продукта как таковой нет.

Определение Готовности (DoD) — формальное описание соответствия состояния инкремента показателям качества, требуемым для продукта.

Свойства:

• обеспечивает единое понимание масштаба работ, которые должны быть проделаны для производства инкремента
• должно быть понятным и доступным всем заинтересованным сторонам
• если элемент бэклога не удовлетворяет определениям готовности, то он
  • не может быть показан на Обзоре Спринта
  • не может быть выпущен в релиз
  • не является инкрементом

Фреймворк не регламентирует конкретный способ описания определений готовности, главное, чтобы они удовлетворяли свойствам, описанным выше.

Как мы писали в статье прослеживаемость требований является важным результатом применения бизнес-анализа. Scrum реализует прозрачную понятную систему прослеживаемости требований своими обязательными артефактами:

• Цель Продукта уточняет цели и задачи организации
• Бэклог Продукта есть уточнение и декомпозиция Цели Продукта
• Бэклог Спринта есть декомпозиция и уточнение элементов Бэклога Продукта
• Определения готовности отражают требуемое качество инкремента, порождаемого из Беклога Спринта

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

Кроме встраивания прослеживаемости, артефакты Scrum повышают прозрачность и измеримость процесса, реализуя взаимосвязи артефактов с их парами-метриками:

• Для Бэклога Продукта это Цель Продукта
• Для Бэклога Спринта это Цель Спринта
• Для продуктового Инкремента — Определение Завершённости

Роли, регламентируемые фреймворком:

• Мастер по Scrum
• Владелец продукта
• Разработчики

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

Основные обязанности:

• планировать спринт
• поддерживать качество ПО, удовлетворяя определениям готовности
• корректировать и уточнять план каждый день для достижения Цели Спринта
• требовать друг от друга профессиональной ответственности
• непосредственно создавать продукт

В команде может быть один или несколько.

Владелец продукта (PO) — это единый голос заказчика и заинтересованных сторон.

Владелец продукта несёт ответственность за максимизацию ценности продукта, полученного в результате работы Scrum-команды.

• "Единый голос заинтересованных сторон" означает, что владелец продукта всегда только один на команду
• Ответственный за работу с продуктовым бэклогом и уходом за ним:
  • Разработка и чёткое, понятное изложение Цели Продукта;
  • Создание, гигиена и коммуникация Бэклога Продукта;
  • Приоритизация элементов Бэклога Продукта;
  • Обеспечение прозрачности, видимости, доступности и понятности Бэклога Продукта и его элементов.

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

И владелец продукта и бизнес-аналитик выполняют бизнес-анализ, сфокусированы на продукте: требованиях к его функциям и характеристикам; их приоритетах; обеспечению понятности и прозрачности всей продуктовой информации для всех заинтересованных сторон на протяжении всего жизненного цикла продукта — для бизнес-аналитика и на протяжении разработки — для PO.

При этом ответственность не значит выполнение, любая описанная обязанность может быть делегирована.

Распространённые недопонимания:
Владелец продукта — это не менеджер или руководитель продукта, несмотря на схожесть названий.

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

Менеджер/руководитель продукта — роль независима от разработки (некоторые продукты вообще не требуют разработки программного обеспечения), которая занимается задачами всего жизненного цикла продукта, включая, но не ограничиваясь:

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

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

В организациях, где инициативы запускаются и финансируются не в проектном режиме, а в режиме потоков создания ценности (value stream) ситуация аналогичная — один руководитель продукта может заниматься несколькими потоками в общем случае, а владельцев продукта нет вовсе, если нет Scrum.

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

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

Scrum мастер (далее СМ) ответственен:

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

Это "настоящий лидер", который служит Scrum-команде:

• Обучает членов команды навыкам самоуправления и кросс-функциональности;
• Помогает команде сосредоточиться на создании инкрементов продукта, соответствующих Определению готовности;
• Устраняет препятствия на пути прогресса команды;
• Способствует тому, чтобы все мероприятия/артефакты проходили своевременно, результативно и эффективно, в том числе укладывались в установленные ограничения по времени.

СМ помогает Владельцу Продукта:

• в поиске методов эффективного определения целей продукта и управления продуктовым бэклогом;
• помогает команде осознать необходимость чётких, кратких и понятных элементов бэклога продукта;
• помогает в разработке эмпирического (то есть основанного на опыте прошлых итераций) плана продукта в комплексной быстроизменяющейся среде;
• способствует и культивирует сотрудничество заинтересованных сторон продукта по запросу или при необходимости.

СМ помогает организации:

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

СМ по определению это лидер-слуга (servant leader) кросс-функциональной команды без иерархии. Звучит противоречиво, но руководство по фреймворку пишет об этом не витиевато.

СМ — роль в рамках процесса Scrum. Если нет разработки ПО, нет и СМ.
Если в организации нет Scrum, соответственно, нет и мастера по данному фреймворку.

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

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

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

Отдадим должное:
Это не единственный фреймворк, пропагандирующий прозрачность и измеримость процесса, но наряду с Lean и некоторыми другими он сделал общее дело и сместил парадигму производства ПО в сторону его современного более оптимального состояния. Если бы не Scrum и его активные продажи, мы могли бы вылезти из наших бункеров сильно позже, особенно на фоне того, как некоторые ИТ-специалисты любят окутывать свою работу священно-сакральным туманом наигранной тайны.

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

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