Друзья, привет! Меня зовут Александр Еремин, я – скрам-мастер продуктовой команды PRO Daily Banking Росбанка. Мы работаем с сегментом малого и среднего бизнеса.
Сегодня я поделюсь наблюдениями скрам-мастера о первом годе жизни команды в новом фреймворке.
Почему мы решили пойти в Scrum? Причины банальные для многих компаний:
Движение к Kick-Off у нас заняло около полугода (с начала 2019 года): изучение, обучение, подготовка материалов и сбор необходимой информации. И вот, наконец,
3 июня 2019 года мы стартанули первый спринт.
Первый год в новом фреймворке – это вызов как для команды, так и для скрам-мастера. Необходимо кардинально изменить mindset и начать все делать по-другому.
Скрам-мастер – не обувь, он не должен быть удобным. Необходимо вырабатывать устойчивый навык отзеркаливания команде и ее отдельным членам нездоровых паттернов поведения. Очень важно научиться правильно и своевременно давать обратную связь, даже если это выведет из зоны комфорта и скрам-мастера, и оппонента.
Необходимо мыслить в масштабе команды, а не отдельных личностей. На команду нужно смотреть как на живой организм и помнить, что если «заболевают отдельные органы», то хандрить может начать весь организм. Если продолжить аналогию, то скрам-мастер – это терапевт. Не хирург, а именно терапевт, поэтому тяжелые клинические случаи – это к другим специалистам.
Scrum, как и LeSS, не терпят личной незрелости участников команд. Если команда не знает, что такое Scrum, никогда не работала в этом фреймворке и, тем более, если до этого уже работала в текущем составе, то я бы рекомендовал воздерживаться от флипа в LeSS сразу.
Выявление добровольцев на Kick-off (на который обычно отводится три дня) внутри ранее не работавшей по Scrum команде, скорее, носит фейковый характер. Если люди ранее не работали в этом фреймворке, едва ли они реально осознают, что это такое, и действительно могут говорить о своей готовности так работать.
Харды — это далеко не все. Если с софтами беда, то даже очень крутой по хардам разработчик может стать большой проблемой.
В самоорганизующихся командах могут гармонично жить и существовать люди с развитой рефлексией, эмоциональным интеллектом и стремлением к непрерывному саморазвитию, расширению сознания и готовностью к смене парадигмы.
Наивно полагать, что ты умнее всех. Очень важно донести эту мысль до каждого члена команды. Проникновение в этот простейший mindset порождает множество плюсов, нежели недостатков: начиная от взаимоуважения, заканчивая “чувством локтя”.
Самое тяжелое – работать с ответственностью. Важно, чтобы люди понимали, что «добровольность» – это не только про волеизъявление и готовность работать в Scrum. Это про готовность развиваться, расти над собой, учиться давать обратную связь и получать ее, рефлексировать и совершать изменения. Это про непрерывный процесс улучшений не только процессов, но и самих себя.
Люди часто не понимают, зачем нужен скрам-мастер. И здесь, проведя много разных диалогов и воркшопов, обсуждений и общений, я пришел к выводу, что это непонимание часто обусловлено неготовностью это понимать. Скрам-мастер должен об этом помнить и продолжать над этим работать.
«Бизнес» и «разработка» стали неразделимы – перестало существовать понимание «мы» и «они». Бизнес-эксперты работают вместе с разработчиками в одних командах. Теперь понимание того, что нужно бизнесу живет внутри команд разработки. В результате мы значительно улучшили скорость поставки: теперь релизы происходят раз в спринт. В настоящий момент живем в трехнедельных спринтах. Раньше фактическая скорость релизов была не чаще одного раза в 1,5 месяца.
Мы узаконили работу с техническим долгом и начали отводить ему время в спринтах. Договорились о пропорции 70% VS 30%, где 30% отвели на техдолг.
За год мы смогли втянуть все критичные компетенции внутрь команды, отказались от вендоров и провели интернализацию разработки. Влияние каждого на результаты разработки и на реализуемые решения значительно повысилось. Значительно выросла погруженность разработчиков в продукт и клиентский контекст. Соответственно качественно изменилась смысловая нагрузка «Зачем?».
Запустили процесс Discovery – значительно усилили погружение в «шкуру клиента». Теперь все наши идеи, относительно того, что нам кажется, клиенту было бы полезно, мы проверяем непосредственно с клиентами. Создали среду, готовую к экспериментам и культуру готовности экспериментировать.
Внедрили CI/CD.
Покрыли автотестами фактически весь функционал WEB приложения, что позволило существенно сократить время и трудозатраты на ручной регресс.
Начали переход на микросервисную архитектуру, что должно добавить командам разработки большей независимости.
Внедрили систему мониторинга приложений и железа: теперь в режиме on-line есть возможность следить за состоянием одного и другого, и иногда получать сигналы до того, как пойдут звонки от клиентов. Построили ряд дашбордов для мониторинга бизнес-показателей, включая KPI в автоматическом режиме.
За год мы многое успели сделать, но наш путь еще продолжается.
P.S.: Я намеренно не стал писать про этапы внедрения Scrum. Об этом сейчас много где можно прочитать. Если интересно, то потом могу написать отдельную статью.
Сегодня я поделюсь наблюдениями скрам-мастера о первом годе жизни команды в новом фреймворке.
Почему мы решили пойти в 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. Об этом сейчас много где можно прочитать. Если интересно, то потом могу написать отдельную статью.
GraDea
А что из этого нельзя было сделать без Скрама? Возможна ли дружба бизнеса и разработчиков без фреймворка? Возможны ли хорошие инженерные практики? Какие механики/принципы Скрама позволили качественно поменять ситуацию?