10 ошибок при внедрении Scrum

Меня зовут Маргарита Маковеева. Мы поговорим об ошибках, которые встречаются при внедрении Scrum.

 

 

Немного о себе. Я перешла из разработчика в менеджмент, о чем не жалею. До этого управляла продуктовым подразделением в фирме 1С-франчайзи – отвечала за развитие трех тиражных продуктов под брендом 1С.

В 2022 году получила премию Infostart Awards в номинации «Управление командой, мотивация и лидерство». После этого решила, что мне пора расти, и перешла в международную финтех-компанию ROBOFINANCE, чтобы заниматься выстраиванием процессов в достаточно интересной команде, которая несколько лет работала без непосредственного руководителя.

 

Scrum

 

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

 

 

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

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

 

 

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

 

 

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

 

Первая ошибка: внедряем Scrum, потому что это «стильно, модно, молодежно»

 

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

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

 

 

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

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

 

 

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

• Точно ли дело в том, что у вас отсутствует Scrum как таковой?

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

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

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

 

Вторая ошибка: Команда… Точно ли команда?

 

Следующий важный аспект внедрения Scrum – это среда, в которой это внедрение происходит. Как правило, все процессы Scrum транслируются в команду.

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

 

 

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

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

 

Третья ошибка: Митинги – пустая трата времени! И вообще, я – программист, я не обязан ни с кем общаться

 

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

Здесь мы сталкиваемся с первой проблемой – в теории команда может понимать цели всех этих встреч, особенно, если вы подробно объясните сотрудникам, зачем им там необходимо присутствовать. Но на практике может возникнуть проблема, что люди будут приходить туда формально, что сводит пользу таких собраний к минимуму.

 

 

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

1. Что я сделал?

2. Что я собираюсь делать?

3. Есть ли у меня какие-то проблемы.

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

 

 

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

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

 

Четвертая ошибка: Ретро? Да начнется суд!

 

Следующая история про ретро. Если на daily Scrum у нас все сухо, мы четко отвечаем на поставленные вопросы, то с ретро начинается какой-то суд.

 

 

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

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

 

 

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

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

На слайде перечислены правила, которые всегда находятся на нашей доске для Ретро.

 

 

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

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

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

Что мы сделали? Сначала немного отступлю. На слайде есть QR-код – это сервис Retromat. Если у вас возникают сложности с тем, как структурировать ретро и какие активности в него включить, можно воспользоваться этим инструментом.

Но мы решили подойти к организации этих встреч по-другому – на этапе разогрева команды мы использовали игры, которые не связаны с ретроспективой напрямую. Мы выбрали игры «Угадай мелодию», «Шпион» и другие. Причем я не принимала участие в выборе игр – моей задачей было инициировать обсуждение, чтобы ребята сами выбрали, во что играть. И благодаря тому, что команда играет именно в то, что им действительно интересно, они заряжаются позитивом. И когда мы переходим к основной части ретро и обсуждаем результаты спринта на доске, ребята оставляют там друг другу всякие теплые слова.

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

 

 

Для проведения ретро есть специальные шаблоны в Miro. Справа на слайде представлены наши доски с результатами ретроспектив. В таком шаблоне мы фиксировали:

• что у нас получилось хорошо;

• что можно было бы улучшить;

• что не удалось реализовать;

• а внизу подводили итоги – оформляли action point по нашим задачам.

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

 

 

В итоге, так же как и на daily Scrum, на ретро можно наблюдать, какие выводы по своей работе в итоге делают участники. Я в этот процесс не вмешиваюсь – команда сама инспектирует свои процессы и начинает видеть точки роста.

Кроме того, ретро дает возможность порадоваться за коллег.

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

 

Не встречи, а бардак

 

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

 

 

Откуда вообще берутся Scrum-мастера в компаниях, если компания не нанимает специального сертифицированного человека?

Допустим, у нас есть разработчик, к нему в какой-то момент приходит менеджер и говорит: «Молодец, хорошо работаешь, будешь у нас тимлидом».

Потом, когда компания решает внедрять Scrum, к нему опять приходят со словами: «Теперь ты будешь ещё и Scrum-мастером, нам нужен Scrum».

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

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

 

 

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

 

 

Несколько советов по поводу того, на что нужно обратить внимание при фасилитации:

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

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

• Если вы чувствуете себя уставшим или не в лучшей форме, не проводите встречу через силу. Лучше передайте инициативу самому заряженному и софтовому человеку у вас в команде. Это не только поможет вам, но и даст команде возможность развиваться и становиться более самостоятельной.

 

Пятая ошибка: Подумаешь, таска 3 года в бэклоге, она очень нужна

 

Следующая проблема – это бэклог. Причем это самая больная тема, потому что здесь нужны hard-скиллы.

 

 

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

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

• Второе – он должен постоянно обновляться.

И если с постоянным обновлением проблем обычно нет, то с упорядочиванием обычно никто не заморачивается. Хорошо, если команда хотя бы на глаз приоритизирует задачи по важности – но обычно и про это забывают, задача просто встает в конец бэклога.

 

 

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

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

Если у вас такая история, то скорее всего, у вас нет человека, который бы управлял бэклогом. А Scrum говорит о том, что для этого действия нужна отдельная роль – product owner. И здесь тоже может быть две ошибки.

• Бывает, что тимлиду не удается донести руководителю, что команде нужен отдельный product owner – вместо этого он слышит в ответ: «Ты пять лет кодил продукт. Ты его прекрасно знаешь. Кто, если не ты? Вот кто? Вперед!»

• Или другая крайность – когда тимлиду все-таки удается убедить руководителя, что product owner – это отдельная роль, потому что ее нельзя совмещать с ролью Scrum-мастера. Scrum-мастер говорит, как достичь цели, как нам к этому прийти, как привести команду. А product owner – это про то, что нужно делать, какая у нас цель, куда мы бежим. И здесь руководитель тоже может ответить: «Так тебе нужно, чтобы кто-то задачи ставил и писал, что нужно делать? У нас же заказчик говорит, что нужно делать. Значит заказчик и есть product owner! Все, проблема решена».

 

 

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

 

 

Для приоритизации есть простой фреймворк MoSCoW.

 

 

Есть фреймворк Lean Prioritization – он немного посложнее, здесь мы ориентируемся на сложность и ценность.

 

 

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

 

 

Почему при приоритизации задач нельзя опираться на чужое мнение, в том числе, на мнение заказчика? Потому что, если рассмотреть, например, фреймворк приоритизации ICE Scoring, то для чужого мнения, включая мнение менеджмента, он оценивает уровень уверенности в гипотезе (параметр confidence), как «очень низко».

 

 

ICE и RICE – достаточно популярные фреймворки, они используются в таких компаниях как Skyeng, «Леруа» и «М-Видео». Их можно немного адаптировать – некоторые коллеги делились опытом, как они вычисляли баллы по этим формулам и разрабатывали на их основе таблицы с собственными системами оценки.

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

 

 

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

 

Шестая ошибка: «8SP = 8 часов»

 

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

 

 

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

 

 

Существует несколько подходов к относительным оценкам. Мы используем числа Фибоначчи. Знаю, что есть коллеги, которые используют размеры маек.

Что касается инструментов, то мы для оценки задач используем Poker Planner.

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

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

Чтобы экономить время на оценке, составьте список эталонных оценок для уже сделанных задач. Зная, сколько по факту story points потребовалось на аналогичные задачи, можно использовать их как ориентир и быстрее определять, к какой категории относится новая задача.

 

Седьмая ошибка: Добросим в запущенный спринт, ачетакова

 

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

 

 

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

 

 

Причем если мы вобьем в поисковике вопрос: «можно ли добавлять задачи в текущий спринт», то и Яндекс, и «Нетология» нам ответят, что нельзя – даже если появилась срочная важная задача, ее нужно поставить на следующий спринт.

 

 

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

 

 

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

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

Основное, что стоит помнить – Scrum относится к Agile. А Agile – это гибкая система. Не стоит Scrum превращать в Канбан, но в экстренных ситуациях мы не говорим строго «нет» – мы проявляем гибкость.

 

Восьмая ошибка: Не успеваем делать задачи за спринт

 

Еще одна проблема, относящаяся к спринту – это то, когда задачи не успевают сделать за спринт.

 

 

Причин такой ситуации может быть несколько, но основные из них следующие:

1. Длительность спринта не соответствует специфике продукта и рынка. Согласно Scrum, что длительность спринта может быть любая – в большинстве случаев, от недели до месяца. Но большинство почему-то за стандарт берут две недели и не хотят гибко адаптировать под себя. Пообщавшись с некоторыми коллегами, оказалось, что не все в курсе, что Scrum Framework разрешает брать длительность спринта до месяца.

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

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

 

 

На графиках представлены скриншоты из Jira с диаграммой производительности.

Здесь можно отследить динамику работы команды:

• Слева – ситуация того, что у нас было, когда команда пробовала щупать Scrum до моего прихода. Зеленое – это то, что команда выполнила по факту, а серое – это то, что они планировали.Видно, что в первом спринте команда не справилась с планом, но вместо адаптации нагрузки во втором спринте запланировала в два раза больше, в третьем — ещё больше, а в четвёртом наконец-то закрыла накопившиеся задачи и даже перевыполнила план. Можно ошибочно предположить, что оптимальная длительность спринта здесь — месяц, но на самом деле проблема была не в этом. Основные причины:

  • Некачественное описание задач.

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

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

• А справа – ситуация у нас сейчас. Здесь можно увидеть, что производительность по итогу у нас выровнялась – уже нет таких рваных графиков. Бывает, что запланировано меньше, чем выполнен, но это связано с нашими особенностями. Дело в том, что первые две недели у бухгалтерии происходит закрытие месяца, и к нам действительно могут прибежать и сказать, что нужно делать срочно. Как мы делаем? Мы оставляем буфер на такие срочные ситуации, как правило, где-то 10 story points оставляем в запасе, иногда чуть меньше или чуть больше. И можем ориентироваться что в этот буфер дополнительно вносим задачи как бы во время спринта. Но это только первые две недели месяца. Также можно увидеть, что у нас этот разрыв сокращается. Буфер мы стараемся оставлять меньше. Вообще я думаю, что дальше пересмотрим, мы пока еще на этапе внедрения и проб. И производительность растет.

 

Девятая ошибка: Разобрались со Scrum внутри, но забыли про заказчика =(

 

Девятая ошибка – когда внутри команды всё настроено, процессы отлажены, но заказчика никто не предупредил об изменениях. В результате он в недоумении: «Как это вы больше не будете сразу брать задачи, как я прошу?»

Поэтому важно заранее выстраивать коммуникацию.

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

 

Десятая ошибка: Почти Scrum

 

 

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

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

 

 

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

Просто работа по спринтам и нажатие кнопки «Запустить спринт» в таск-трекере – это ещё не Scrum. Поэтому, если что-то идёт не так, то, скорее всего, дело не в том, что Scrum не работает, а в том, что его просто не до конца внедрили.

 

 

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.