Scrum вам не поможет. Разбираемся, почему

    image
    Картинка взята с данного ресурса.

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

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

    1. Вы планируете совмещать роли из классического проектного менеджмента и Скрама


    Скрам-команда в обязательном порядке должна включать в себя 3 роли: Владелец Продукта, Команда Разработки и Скрам-Мастер. В рамках предложенного состава команда остается «плоской», то есть мы не имеем прямого подчинения между участниками. Такая команда наделена полномочиями самостоятельно принимать все решения относительно разрабатываемого продукта. Роли в Скраме чётко описывают, кто и за какие вопросы ответственен.

    Теперь представьте, что вы планируете внедрять Скрам в команде с классическим проектным менеджментом. Тогда Скрам-команда начинает работать при участии Project Manager’a. Что происходит в таком случае? Фактически, PM просто нечем себя занять в таком проекте. Любые зоны ответственности, которые мы ему передаем, создают дисбаланс в Скрам-команде. Отдадим PM бюджет? Отлично, то есть PM не регулирует ценность и содержание продукта, но в случае проблем именно он будет получать по голове. Отдадим ему ещё и работу с ценностью продукта? Тогда можно будет упразднить Владельца Продукта. Но это будет уже не Скрам.

    image
    Как меняются роли и задачи в команде с приходом Скрам

    2. Вы работаете с предельно понятными требованиями


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

    Когда и так все понятно, зачем усложнять?

    3. Вы работаете с проектами небольшой длительности


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

    4. У команды нет желания менять подход к работе


    Это одно из ключевых ограничений при внедрении Скрама. Внедрять Скрам директивно – почти всегда плохая идея, сначала важно донести ценности до команды, «продать идею». Но даже после этого у вас не будет гарантий, что идеи Скрама будут близки всем её участникам. Те, кто внутренне не принял идеи Скрама и agile-ценности, могут начать разрушать систему изнутри, «раскачивать лодку».

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

    Второй вариант: один или несколько участников не захотят работать в новой системе. Обычно такие ситуации заканчиваются тем, что «проблемный» участник покидает команду самостоятельно.

    image
    Перемен. Мы ждём перемен.
    Картинка взята с данного ресурса.


    5. Вы не готовы использовать все обязательные практики Скрама


    Для этого подхода даже придумали специальный термин ScrumBut. Это когда мы работаем по Скрам, но… Мы не проводим ретроспективы. Но Daily meeting у нас 2 раза в неделю. Но мы отказались от роли Скрам-мастера. И много других подобных «но».

    Фреймворк Скрам даёт простой и понятный ответ на все эти ситуации. Да, вы можете добавлять дополнительные практики в Скрам-процесс вашей команды (например, практики из XP). Но нет, вы не можете отказываться от каких-либо элементов Скрама, так как это уже будет не Скрам.

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

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


    Видели график зависимости времени продуктивной работы от количества проектов, над которыми вы работаете одновременно? Если нет, то смотрите.

    image

    Сама эта диаграмма является лучшим аргументом в пользу вовлечения сотрудников в работу над одним проектом в один момент времени. Но если и она вас не убеждает, вычтите из времени, оставшегося на один проект при работе с несколькими другими, время, которое уйдёт на обязательные встречи (ежедневные митинги, ретро, планирование, обзор спринта). У участника команды останется слишком мало времени на работу по задачам. Оно вам надо?

    Из этого правила есть исключения. Например, Скрам-Мастер может работать сразу с несколькими командами. Но для остальных участников необходимо обеспечить максимальное вовлечение только в этот проект.

    7. У вас нет поддержки со стороны руководства


    Также как мы хотим, чтобы сотрудники приняли новый подход к работе, мы нуждаемся и в поддержке со стороны руководства. Важно понимать, что внедрение Скрама, особенно на
    ранних этапах, может потребовать некоторых вложений. Например, найм Agile-коуча или профессионального Скрам-Мастера, обучение Владельца Продукта, проведение обучения по Скраму для сотрудников и многое другое. Руководитель должен быть готов поддержать новое начинание финансово.

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

    Данный список критериев не претендует на полноту, вы можете дополнить его для себя или поделиться своими кейсами в комментариях.
    ICL Services
    94,92
    Цифровые технологии для бизнеса
    Поделиться публикацией

    Комментарии 15

      0

      Теперь-то я знаю как называется извращённый скрам, спасибо за хороший термин

        0
        А как вам "scrumgile"?
          –1
          «scrumgile»

          Я, кстати, такой термин вижу впервые. Но на первый взгляд он не так страшен, все-таки agile-мышление необходимо для внедрения Скрама. Знак равенства между scrum и agile ставить не корректно, а сочетать ценности и принципы agile-манифеста и самого скрама — это дело правильное.
          Но хорошо бы понимать, что вкладывают в понятие «scrumgile» те, кто его использует)
            0
            Agile — философия, а scrum — фреймворк, в котором эта философия взята за основу. Невозможно успешно внедрить scrum (не but), не разделяя agile философию.
        +1
        Убедительные аргументы. Но руководство такие статьи не читает, грустно.
          +1

          А кто в модели без ПМ отвечает за бюджет, найм, мотивацию (вроде по скраму команда должна быть мотивированной, но самомотивация не обязательна)?

            –1
            Хороший вопрос. В скрам гайде нет прямого ответа, а значит нет и на 100% утвержденного в скраме подхода. Но с опорой на скрам гайд и на опыт можно предложить следующие варианты:
            1. За бюджет отвечает PO, так как именно он владеет бэклогом, а значит определяет приоритеты и решает, как сделать максимально ценный продукт в рамках бюджета. Вообще, правильный PO — это человек «бизнесовый», в команде именно он отвечает за вектор развития, за вИдение и за деньги тоже.
            В идеале при Скрам подходе использовать подход T&M, когда бюджет завязан на времени работы исполнителя, при этом обеспечивая высокую прозрачность рабочего процесса для стейкхоледров. Но это тема для отдельного разговора.
            2. С наймом похожая история — инициаровать подбор нового участника команды может команда разработки, но финальное решение будет за PO, так как за деньги в скрам-команде отвечает он.
            3. По поводу мотивации — зависит от того, что вы вкладываете в это понятие. Если речь идет про материальную мотивацию (зарплата, бонусы и тд), может быть несколько вариантов. Решение может принимать PO единолично (см. прошлые пункты), но в самых зрелых командах оно может быть принято всей командой. Это уже ближе к бирюзовым организациям, но опять же эта тема отдельного разговора.
            Если речь про нематериальную мотивацию, тут важна роль каждого участника команды. Но, пожалуй, наибольшее влияние на мотивацию должен оказывать скрам-мастер. При должном уровне зрелости он помогает решать конфликты, поддерживать команду, умеет подобрать правильные слова и подбодрить остальных.
              0

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

            +1

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


            1. Команда разработки не обладает всеми компетенциями.


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


            2. Проект требует интеграции с продуктами, разрабатываемыми другими командами.


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


              0

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


              • спринт 1, задача на проектирование интерфейса взаимодействия на две команды
              • спринт 2, задача на имплементацию этого интерфейса со стороны, например, фронта
              • спринт N (по готовности бэка во второй команды), задача на интеграцию
                0
                например, задача считается неготовой даже для грубой оценки пока нет дизайна

                и лёгким движением руки скатываем весь процесс в вотерфол :) Что в таком процессе должен нарисовать дизайнер? То, что захотел ПО? А если то, что нарисовал дизайнер, будет технически трудно или в конкретных условиях невозможно реализовать?

                  0

                  Откуда ватерфол? И чем рисунок дизайнера отличается от невозможной текстовой задачи?

                    0

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


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

                      0

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


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


                      В любом случае в таких ситуациях скрам достаточно гибок, по-моему, чтобы переварить отступления от идеального (для кого-то) флоу без поломки принципов и духа, просто, например, изменениями формулировок definition of ready и definition of done, чтобы команда оставалась кроссфункциональной, чтобы могла выполнить за спринт любую готовую к разработке задачу от ready к done.

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

                        В Scrum оцениваются, как правило, только Stories путем коллективной оценки. В этом смысле Exreme Programming лучше справляется с задачей максимально раннего выявления отклонения от плана, поскольку использует двухуровневую оценку, сперва Stories оцениваются коллективно (тут есть отличия между 1-ой и 2-ой версией), а затем, при планировании итерации, уже оцениваются Tasks индивидуально.

                        При этом нужно не забывать, что оценка — это вероятностная распределенность, и, если делать оценивание правильно, то выражать оценку нужно не только вероятностной оценкой, но и ее среднеквадратическим отклонением распределения времени, которое, как раз, и выражает неопределенность оценки и служит бизнесу для грамотного управления бизнес-рисками. Чаще всего для этого используется методика оценки PERT.

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое