company_banner

Год в Scrum: наблюдения скрам-мастера

    Друзья, привет! Меня зовут Александр Еремин, я – скрам-мастер продуктовой команды PRO Daily Banking Росбанка. Мы работаем с сегментом малого и среднего бизнеса.

    Сегодня я поделюсь наблюдениями скрам-мастера о первом годе жизни команды в новом фреймворке.

    image

    Почему мы решили пойти в Scrum? Причины банальные для многих компаний:

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

    Движение к Kick-Off у нас заняло около полугода (с начала 2019 года): изучение, обучение, подготовка материалов и сбор необходимой информации. И вот, наконец,
    3 июня 2019 года мы стартанули первый спринт.

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

    О чем нужно помнить скрам-мастеру в этот период?


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

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

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

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

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

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

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

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

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

    Что нам дал Scrum за год?


    «Бизнес» и «разработка» стали неразделимы – перестало существовать понимание «мы» и «они». Бизнес-эксперты работают вместе с разработчиками в одних командах. Теперь понимание того, что нужно бизнесу живет внутри команд разработки. В результате мы значительно улучшили скорость поставки: теперь релизы происходят раз в спринт. В настоящий момент живем в трехнедельных спринтах. Раньше фактическая скорость релизов была не чаще одного раза в 1,5 месяца.

    Мы узаконили работу с техническим долгом и начали отводить ему время в спринтах. Договорились о пропорции 70% VS 30%, где 30% отвели на техдолг.

    За год мы смогли втянуть все критичные компетенции внутрь команды, отказались от вендоров и провели интернализацию разработки. Влияние каждого на результаты разработки и на реализуемые решения значительно повысилось. Значительно выросла погруженность разработчиков в продукт и клиентский контекст. Соответственно качественно изменилась смысловая нагрузка «Зачем?».

    Запустили процесс Discovery – значительно усилили погружение в «шкуру клиента». Теперь все наши идеи, относительно того, что нам кажется, клиенту было бы полезно, мы проверяем непосредственно с клиентами. Создали среду, готовую к экспериментам и культуру готовности экспериментировать.

    Внедрили CI/CD.

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

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

    Внедрили систему мониторинга приложений и железа: теперь в режиме on-line есть возможность следить за состоянием одного и другого, и иногда получать сигналы до того, как пойдут звонки от клиентов. Построили ряд дашбордов для мониторинга бизнес-показателей, включая KPI в автоматическом режиме.

    За год мы многое успели сделать, но наш путь еще продолжается.

    P.S.: Я намеренно не стал писать про этапы внедрения Scrum. Об этом сейчас много где можно прочитать. Если интересно, то потом могу написать отдельную статью.
    Росбанк
    Компания

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

      +3

      А что из этого нельзя было сделать без Скрама? Возможна ли дружба бизнеса и разработчиков без фреймворка? Возможны ли хорошие инженерные практики? Какие механики/принципы Скрама позволили качественно поменять ситуацию?

        –3

        На самом деле, конечно же, многое можно было сделать и без скрама. И это частая дилемма: "А точно ли скрам нужен?" Что вполне рационально.
        Здесь его преимущество в основном в том, что он изначально прошит несколько иным подходом и майндсетом. Т.е. на входе, как пререквизиты разбираются ценности, которые (в большинстве случаев) раньше были чужды в команде, заключаются новые командные соглашения, кардинально и в моменте пересматривается подход к достижению целей, к командной работе, к работе в целом. На входе в скрам, мы много говорим в т.ч. с менеджментом и стейкхолдерами о высокой необходимости расшивания зависимостей и, тем самым, достижении высокой степени самостоятельности команд. Говорим о человекоцентричном подходе. Часто перепрошивка подхода к процессу, устройству и управлению разработкой требуется именно менеджменту. И это тоже нельзя выпускать из виду.
        Зачастую, чтобы дойти до этого команде и организации эволюционно, требуется много времени, как правило это годы.
        В остальном, конечно, ничто не мешает.
        Однако, важно также признать, что не редки случаи формального внедрения скрам, когда ничего на самом деле особенно не меняется, кроме появившихся кофеносцев в виде скрам мастеров. Фейки повсеместны, от чего понимание пользы и целесообразности сильно размывается.
        UPD:
        В целом не надо забывать, что скрам это лишь набор хороших современных практик, упакованных в одну обертку. Симбиоз, если угодно.


        Если говорить конкретно о нас…
        Всё чаще наблюдаются такие вещи как:


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

          Лично у меня сложилось впечатление, что скрам это лишь метод выжать разработчика до последней капли. Может это и ведёт к ускорению процессов, но так же эта постоянная спешка и гонка за количеством ведёт к неизбежному падению качетсва кода и к выгоранию. Не знаю, что уж тут особо хорошего.
            –1
            Да, действительно, часто наблюдается, что после внедрения это больше похоже на гонку, выматывающую всех участников и выжимающую до последней капли, поверьте, не только разработчиков. Но, на поверку, Скрам здесь не при чем. Чаще причина причина в том, что Скрам воспринимается менеджментом как «волшебная таблетка» хорошо отрекламированная и проданная консультантами и через медиа. Адекватные консультанты открыто говорят о том, что Скрам поможет «полечить», а что нет. Так вот ложные ожидания часто ведут к тому, что давление со стороны менеджмента может только усиливаться, что и ведет к тому, что команда может начать работать на износ.
            Здесь важно соблюдать баланс и многое может зависеть в том числе от опытности, зрелости, смелости и бесстрашности, если угодно, скрам мастера, а также от адекватности менеджмента. Это правда не просто. Чаще всего менеджмент берет верх и ситуация усугубляется.
              –1
              Адекватность и зрелость Продакт Оунера тоже, к стати, никто не отменял. Чаще всего давление на команду транслируется именно через него. К сожалению, многое в Скрам Гайде и других источниках о фреймворке, не раскрыто и имеет свободу для толкования. Это имеет и плюсы и минусы. Когда мы читаем, что PO это своего рода mini CEO — имхо, необходимо это воспринимать со всеми вытекающими… Когда мы говорим об адекватном генеральном мы же все вспоминаем и про эмоциональный интеллект, и про опыт и про зрелось и про заточенность на результат и про то, что хороший ген.дир думает о людях. Почему мы здесь об этом забываем? Почему менеджмент ставит на эти позиции часто не зрелых и не опытных людей в т.ч. без предпринимательского бэкграунда или мышления? Это вопросы риторические, на поразмышлять всем нам…
            +1
            … майндсетом

            скрам-мастер — не скрам-мастер, если не использует это волшебное слово 10 раз в день. А то я начал волноваться, что автор не настоящий скрам-мастер, раз в статье не упомянул майндсет. но теперь я спокоен )))
              0

              Это что-то личное? :))

                0
                Частное наблюдение в ироничной форме, не принимайте близко к телу)
            0

            Расскажите, пожалуйста, подробнее об этом «Бизнес-эксперты работают вместе с разработчиками в одних командах». В каких ролях, по каким процессам?

              0
              Отвечу, как понял вопрос. Если уточните дополнительно, постараюсь дать больше подробностей.
              1. Feature Teams включают в свой состав бизнес-экспертов. В нашем продукте у нас их три — в каждой команде по эксперту.
              2. Процесс у нас на всю продуктовую команду единый и глобально делится на три этапа (каждый из которых содержит в себе по несколько шагов) — Этап Discovery, PBR и Анализ и Delivery. Собственно, последний этап — это уже спринты.
              3. Бизнес-эксперты больше всего заняты в этапе Discovery (раскапывают боли клиента и проверяют гипотезы их устранения) и в Delivery (когда необходимо прорабатывать и изменять бизнес-процессы внутри организации, дабы связь разработки и внутренних процессов не нарушалась). Они также посещают все наши PBR, чтобы дать разработчикам требуемый контекст, если необходимо — какую проблему решаем, в чем смысл и ценность задачи, фичи.
              4. Соответственно, в командах есть непрерывная связь разработчика с источником боли или потребности клиента.
                0

                Спасибо. А как соотносятся области ответственности бизнес-экспертов и product owner?

                  +1

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

              0
              Вот кстати сейчас подумалось: может для коллектива полезнее нанять психолога чтобы следить за душевным состоянием, отношениями, мотивацией? У психолога по крайней мере диплом есть в этой области, а не тренинги и коучинги. Интересно было бы обсудить. (дисклеймер: я не хейтю скрамеров, но размышляю)
                +1

                Есть в этом рациональное зерно. Почему бы и не нанять? Думаю польза была бы от этого.
                В кругу довольно опытных См-ов бытует мнение, что с психологом полезно общаться всем людям, особенно Скрам Мастерам. :)))
                Только вот должен ли скрам мастер обязательно быть профессиональным психологом? Есть ли у него цель заменить его? Заменит ли психолог СМ-а? Не уверен.
                Определённо, многими знаниями из области психологии СМ-у приходится овладевать и ему нужно постоянно качать области сопряженные с ней. Но цели стать психологом для команды у него нет (личные порывы исключаем для чистоты картины).
                В свою очередь, психолог не станет делать для команды то, что должен делать СМ — строить процессы, фасилитировать, обучать инженерке, собирать процессные метрики, устранять зависимости, менять процессы в организации, и пр.
                По моему субъективному мнению зрелым участникам команды (или как ещё говорят — высокомотивированным профессионалам) зачастую психолог не требуется для того, чтобы выстроить эффективное взаимодействие в работе. Вполне достаточно своевременной фасилитации, коучинга, навыка отзеркаливания. Эти навыки, уважающий себя СМ должен прокачивать.
                В статье я провожу аналогию с терапевтом — это как раз о том, что он должен иметь возможность и способность отражать "нездоровье" и говорить об этом. Должен знать простую "таблетку" или "помазать зелёнкой", в отдельных случаях "направить к нужному доктору".
                Надеюсь метафоры понятны…


                Кажется, что Ваш вопрос идёт скорее из непонимания пользы и нужности СМ. Возможно, Вы на практике этого не увидели. Это действительно порой имеет место быть, к сожалению. Но эта проблема настолько же живая и актуальная как и с другими профессиями и компетенциями. Область эта очень молода и неотесана сама по себе. Понимание о том, кто такой СМ до сих пор у большинства смутное, я уже не говорю о понимании, что такое хороший СМ…
                Поверхностное проникновение в суть вещей отдельных представителей, в свою очередь, многих раздражает, вызывает скепсис и недоверие, что конечно усложняет и без того неясную ситуацию.


                Дисклеймер:
                Прошу не воспринимать вышеизложенное, как отнесение себя к хорошим СМ. :)) Я лишь стремлюсь разобраться в этом и увидеть возможные области роста.

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

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