Scrum менеджер профессия есть ли такая

Опубликовано: 02.10.2024

Роль scrum-мастера специфична, она пришла из в фреймворка Scrum. Она часто вызывает недопонимание: кто-то склонен переоценивать её, кто-то готов ей пренебречь.

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

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

Кто такой scrum-мастер

Scrum-мастер помогает команде соответствовать ценностям и принципам гибкого подхода и эффективно поставлять продукт. Согласно Scrum Guide, он «отвечает за продвижение и поддержку Scrum в соответствии со Scrum Guide. помогает всем понять теорию, практику, правила и ценности Scrum».

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

Что делает scrum-мастер

В идеальном случае команда сама управляет процессом разработки, и scrum-мастер не нужен ей постоянно. Так предполагалось исторически, и название роли — «мастер» —говорит о том, что такой сотрудник учит команду работать по Scrum и отпускает ее в свободное плаванье. Практика показала, что большинство команд так не может. Разработчики полагаются на мастера как на руководителя процесса.

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

Scrum-встречи

Мастер организует «ритуалы» Scrum:

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

Организует планирование спринта и разбор бэклога . Scrum-мастер промотает оценить user story и выделить подзадачи. Для этого используются разные методы. Например, он приносит карты с цифрами для покерного планирования или придумывает новую игру для оценки задач. Также scrum-мастер смотрит, чтобы спринт не был перегруженным или чересчур легким.

Принимает участие в ревью спринта . Scrum-мастер помогает владельцу продукта собирать отзывы, а команде представить инкремент продукта в конце спринта. Считается, что лучшая демонстрация — работающие функции. Если это «невидимое» изменение, мастер поможет разработчику понятно подготовить живую презентацию, например, предложит собрать статистику.

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

Визуально-статистические задачи

Scrum-мастер администрирует доску задач. Он готовит карточки с историями и следит за их перемещением, но заполняет и двигает их команда.

Мастер переносит аналоговые истории в цифру, например, в Jira или Kaiten. Чтобы визуализировать работу, оформляет диаграмму сгорания, а по статистике каждого спринта высчитывает Velocity. Есть еще много метрик, которые можно отслеживать. Сами по себе цифры ничего не дадут: в задачи scrum-мастера входит их проанализировать и скорректировать организацию работы команды.

Методология: процессы и люди

Он главный защитник scrum-ценностей, и это его основная обязанность. Все scrum-ритуалы и дашборды ведутся, чтобы сотрудники компании легче принимали ценности Agile и с этим пониманием могли эффективнее работать.

Для этого scrum-мастер:

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

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

Что не делает scrum-мастер

В Scrum Guide scrum-мастер определяется как «лидер-слуга». Слово «слуга» обращает на себя больше внимание. Если проигнорировать ценность Scrum — уважение, — то на мастера можно скинуть много бытовых дел, мотивируя это тем, что они мешают идти к цели спринта. Когда больше половины работы scrum-мастера постоянно состоят из обеспечения задач такого рода, то команде нужен офис-менеджер или отдел снабжения.

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

И последнее, scrum-мастер не тимлид. Когда команде нужен руководитель по развитию, тренер с высокими профессиональными навыками, значит, это еще одна роль, которой не хватает.

Нужен ли команде scrum-мастер и как надолго

Если у компании есть возможность создать эту должность, scrum-мастер нужен. И желательно на полный рабочий день.

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

Например, мы даем некоторым scrum-мастерам одновременно 2 команды. Тогда дел у scrum-мастера хватает, при этом он всегда в офисе со своими командами.

Трудоустройство на неполный день или на некоторые дни не кажется нам эффективным. Собраться на стендап и задать вопросы на ретро можно и не будучи scrum-мастером. А вот обеспечить отлаженный процесс — это уже труднее. Возможно, нужно пригласить опытного agile-коуча на какой-то период.

Есть много команд, где роль scrum-мастера берет на себя один из разработчиков. Гуру по Scrum не считают этот метод подходящим, но, в любом случае необходимость такого scrum-мастера зависит от людей в команде. И будет это провалом или нет, покажет только эксперимент.

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

Основные принципы работы scrum-команды

Чтобы работать по методологии Scrum, команда разработчиков должна соблюдать три основных принципа.

Совершенствование продукта за счет самосовершенствования сотрудника.

Каждый член команды отвечает за свою часть работы и за общий результат.

Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.

Процесс работы scrum-команды

Процесс работы scrum-команды проходит в несколько обязательных этапов.

Планирование бэклога спринта

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

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

Scrum-митинг, или совещание на ходу

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

Что я сделал с момента прошлой встречи?
Чем я займусь сегодня?
Какие есть препятствия?

Scrum-доска

Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.

Когда что-то идет не так

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

Обзор результата

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

Как внедрить scrum-методологию

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

Кажется, что все просто. Нужны несколько последовательных действий.

1. Собрать команду

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

2. Назначить владельца продукта

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

3. Выбрать scrum-мастера

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

4. Создать список требований к продукту

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

5. Спланировать спринт

Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.

6. Постоянно анализировать и оценивать результат

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

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

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

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

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

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

Недавно мы провели опрос в Twitter, и 92 % респондентов сказали, что они применяют собственные методы, а не следуют методу scrum «по книге». Это заставило нас задуматься о том, что это значит для scrum-мастеров, которые должны инструктировать команды и помогать им понять метод scrum? Каким образом они вписываются в этот постоянно меняющийся agile-мир, действующий «не по книге»?

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

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

Обязанности scrum-мастера

В идеальном agile-мире команда управляет собственным процессом и инструментом сама. Но мы обнаружили, что многие команды, перешедшие на agile, часто полагаются на scrum-мастера как на владельца процесса. Чтобы распространить обязанности и полномочия по всей команде, требуется время. В таком трансформирующем контексте эта роль может быть либо совсем простой и сводиться к планированию scrum-церемоний, либо требовать такого же уровня вовлеченности, как от любого другого участника scrum-команды. Хотя в руководстве по scrum описано, каким образом scrum-мастер помогает другим scrum-ролям, этот список обязанностей не является исчерпывающим. Действительно, мы обнаружили, что scrum-мастера часто выполняют некоторые или все из следующих обязанностей, хотя не все они устанавливаются методом scrum:

Стендапы. Практикуйте ежедневные стендапы, или scrum-совещания, по мере необходимости.
Собрания по планированию спринтов или итераций. Берегите команду от чрезмерной нагрузки и расширения области работы. Участвуйте в оценке работы и разбивайте ее на подзадачи.
Обзоры итогов спринтов. Принимайте участие в совещаниях и фиксируйте обратную связь.
Ретроспективы. Отмечайте, что можно улучшить, и планируйте конкретные действия на следующий спринт.
Администрирование досок. Станьте администратором доски scrum. Поддерживайте карточки в актуальном состоянии, а инструмент scrum (например, Jira Software) — в рабочем.
Встречи один на один. Разговаривайте индивидуально с каждым участником команды и заинтересованными сторонами, если необходимо. Улаживайте разногласия по поводу процессов и стиля работы в команде. Многие специалисты scrum против встреч один на один, поскольку убеждены, что все должно обсуждаться во время стендапов. Однако участники многих, особенно новых, команд предпочитают регулярно встречаться с определенными коллегами один на один. Scrum-мастер может признать, что такие личные встречи важны для развития команды и знакомства ее участников друг с другом.
Внутренние консультации. Scrum-мастерам следует быть готовыми к обмену мнениями с другими участниками команды и внутренними заинтересованными сторонами, чтобы вместе решать, как лучше организовывать работу scrum-команды.
Отчеты. Регулярно анализируйте диаграммы Burndown и другие инструменты планирования портфеля, чтобы понимать, какие сборки готовы и как часто выполняются релизы.
Блокеры. Scrum-мастер устраняет внешние блокеры и помогает команде справляться с внутренними препятствиями, улучшая рабочие процессы.
Интенсивная работа. Если scrum-команда не погружена в рабочий процесс, это сигнал для scrum-мастера. Возможно, стоит починить сломанные компьютеры, передвинуть столы или, может быть, просто отрегулировать температуру в офисе. Scrum-мастер должен быть готов создавать условия для работы команды любыми подходящими способами — даже принести кофе и что-нибудь перекусить, если это решит проблему.

Нужен ли мне scrum-мастер?

Любой scrum-тренер учит, что в scrum-команде должен быть scrum-мастер. Без него вы будете работать не совсем так, как предполагает подлинный scrum. Подобную ситуацию часто называют «скрам-бат» (scrum-but).

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

Но все scrum-команды разные. Многие опытные команды выполняют все перечисленные обязанности, действуя как единое целое. Они гордятся и наслаждаются совместным управлением процессом. Роль scrum-мастера дрейфует между участниками команды, которые проводят стендапы и ретроспективы по очереди.

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

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

Scrum-мастер и менеджер по продукту

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

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

Scrum-мастер и менеджер проектов

Нетехническим (или не относящимся к agile) двойником scrum-мастера является менеджер проекта. Обе эти роли концентрируются на том, «как» выполнить работу и решить проблемы рабочего процесса через управление им и координацию. Нужны ли вам обе эти роли? Скорее всего, нет.

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

Scrum-мастер помогает команде улучшать и оптимизировать процессы, с помощью которых она достигает своих целей. Он действует как один из команды, как участник общего дела и в идеале не руководит в традиционном смысле слова. Лучшие scrum-команды практикуют самоорганизацию и потому плохо реагируют на управление «сверху вниз».

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

Scrum-мастер и улучшенная организация

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

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

Что чувствует скрам-мастер, который знает о скраме только из гайда? Как он пытается помочь команде не развалить и улучшить существующие процессы? Статья о трудностях, с которыми я столкнулась в начале своего пути самурая.

Команда, в которую я пришла как QA-инженер, была уже сформирована: стандартные процессы построены, атмосфера в коллективе — дружелюбная и спокойная. Через год моей работы встал вопрос о том, кто заменит скрам-мастера, который перешел в другую команду. Мне захотелось попробовать. Опыта в управлении и построении процессов не было, но почва для старта доброжелательная. Почему бы и нет?

Сложности

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

Отсутствие авторитета

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

Тень бывшего мастера

От сравнений никуда не деться. Если до моего появления что-то работало плохо, и после моего прихода ничего не изменилось, возникали запросы: «У нас слишком сложный планнинг, давай сделаем уже что-нибудь с ним!». В случае, когда что-то было удобно для команды, например, физическая доска на дейли, а после появилась я и сказала: «Мне неудобно, давайте менять!», команда не понимала, зачем это необходимо.

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

Коммуникация с командой

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

Синдром волонтера

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

Способы решения

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

Решать проблемы поэтапно

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

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

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

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

Аргументировать любое изменение

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

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

Изучить поведение авторитета

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

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

Найти единомышленников

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

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

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

А что дальше?

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

Скрам

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

Менеджмент

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

Личностные навыки

Осознавать и контролировать собственные эмоции
Нести ответственность за результат
Быть проактивным и самостоятельным в организации работы

Управление разработкой
Управление проектами
Agile
Управление продуктом

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Скопировать ссылку
Facebook
Twitter
ВКонтакте
Telegram
Pocket

Средняя зарплата в IT

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

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

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

Соглашусь с вами и отвечу в комментарии. Были проблемы с тем, что некоторые задачи занимали больше времени по факту, чем было оговорено на планнинге.

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

Вообще чтобы коллектив работал более эффективно, на мой взгляд нужно:

1. поднять зарплату до конкурентной рыночной участником команды
2. создать доброжелательную не кислотную атмосферу. Исключить публичное обсуждение участников команды
3. контролировать результат, а не процесс работы. Дать человеку возможность заниматься работой, как творчеством

Все остальное — это просто пляски с бубном или вера в волшебную красную кнопку «scrum», что по сути одно и тоже

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

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

Ох, как накинулись-то сразу)
Автору epifan001 — удачи и успехов на новом выбранном пути. Публиковать подобную статью на habr смело, но может быть травмирующе — очень уж здесь сильна культура ненависти к менеджерам и к Agile. Сам факт того, что вы перешли в скрам мастера, делает вас по-умолчанию врагом для большинства аксакалов здесь.
Возвращаясь к статье, становиться скрам мастером из команды действительно тяжело, и да, проблема даже приоритезации новой информации стоит остро. Для того, чтобы понять скрам гайд, что скрывается за его формулировками, требуется опыт, которого начинающим скрам мастерам часто не хватает. Почувствуешь, что не твоё, не идёт — путь назад в тестирование не закрыт навсегда) Советов давать не буду, их и так достаточно со всех сторон.

Вот эта работа, которая выполнялась первое время. Для меня (может я не прав, но предположу) очевидно, что прошлый скрам мастер тоже был/была не особым экспертом, но используя накопленное доверие команды не давал/давала себя ругать. Т.е. он/она за время скрам мастерства уничтожил/уничтожила механизм обратной связи, критически важный для процесса в целом. Официально всё было нормально, работается-работаем (но о проблемах молчать!)… А теперь попробуй-ка улучшить что-то в этой ситуации. А потом начинаешь восстанавливать обратную связь и всё это скрытое и дурно пахнущее выливается на тебя, как будто это ты виноват во всех проблемах команды сейчас (и 1 год назад, и 5, и 10 лет назад проблемы тебе припомнят).

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

Вот поэтому она и начала с поиска союзников, потому что в её команде наверняка есть такие, как вы, с нежеланием слушать, авторитетом в команде, но не готовые взять роль скрам мастера на себя, зато готовые осудить. А потом эти юные скрам мастера послушают вас на паре ретроспектив или планирований спринта и идут плакать в тихую переговорку, собирать себя по кусочкам, чтобы потом вернуться и попытаться помочь команде. За что им это? Не потому, что они не правы, а потому что токсичный красный авторитет уже подмял команду под себя и не готов слушать советы какой-то мелочи зелёной/бирюзовой.

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

puyol_dev2, коротко по вашим советам. №1 — а с чего вы взяли, что у автора в команде не конкурентная зарплата? Что указывает на то, что это проблема в её команде или компании? Это может быть ваш контекст, не её. Насчёт атмосферы она уже сказала

Василий Савунов, agile-коуч компании ScrumTrek, рассказывает, на что обратить внимание новичкам в профессии.

Кто такие Scrum-мастера?

В отличие от Запада, в России скрам-мастера только начинают появляться. В основном эти профессионалы уже работают внутри компаний, редко выходя на рынок труда.

Стать сертифицированным Scrum Master’ом довольно просто: достаточно обучиться в профильных образовательных организациях, выдающих международные дипломы, вроде ICAgile, PMI, Scrum Alliance, Scrum.org, ISQI и пройти у них экзамен — его сдают до 90% студентов. Но дьявол, как известно, в мелочах, и наличие сертификата не гарантирует работодателю ничего, кроме того, что перед вами человек, предпринявший определенные усилия и потративший деньги, чтобы получить официальную бумажку, якобы удостоверяющую его квалификацию. Результата это не гарантирует.

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

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

Творческая работа требует совсем иных способов управления. То, что хорошо при механической работе — четкий план, контроль по срокам и результатам, денежная мотивация, — плохо работает с людьми интеллектуального труда. Например, попытки управлять разработкой ПО через директивные методы приводят к тому, что программисты, чья работа в основном происходит «в уме» и требует творческого подхода, спустя какое-то время начинают работать по принципу «итальянской забастовки», когда делается ровно то, что написано в ТЗ. Без какой-либо попытки творческого осмысления или сотрудничества с заказчиком, чтобы указать на лучшее решение или предупредить о рисках.

Конкурс ВТБ – придумай имя голосовому помощнику и выиграй Iphone 12

Ситуация, при которой в ответ на вопрос заказчика: «А почему эта функция не сделана, она же очевидна для данного продукта?», звучит ответ программиста: «А потому что в ТЗ об этом не было написано» — уже стала классической. Результат, как правило, не устраивает ни заказчика, ни программиста.

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

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

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

Среди российских компаний, которые применяют Scrum для разработки продуктов, можно назвать Сбербанк, «Альфа-банк», Avito, «Билайн», «Теле 2», X5 Retail Group, «Ингосстрах», группу «Ренессанс» и даже такого промышленного гиганта, как «Северсталь». Область применения подхода зависит от отрасли, но, как правило, это вопросы создания новых продуктов (как IT, так и не-IT-сферы), освоение новых каналов продаж, цифровизация бизнеса, проведение продуктовых исследований.

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

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

Как показало исследование компании Google в рамках проекта «Аристотель», в котором исследовались причины успеха 180 команд, именно психологическая безопасность и чувство доверия оказались определяющим фактором, который отличал успешные команды от неуспешных. К сожалению, предоставленная сама себе разнородная группа редко способна в короткие сроки выйти на нужную эффективность, создать атмосферу доверия и преодолеть разобщенность. И здесь на сцену выходит роль Scrum-мастера, задачей которого как раз и является помочь группе пройти через сложные этапы знакомства, притирки, формирования общих правил, решения проблем и так далее, чтобы в итоге получить именно команду, то есть группу, в которой все разделяют общую цель, поддерживают и доверяют друг другу.

Что должен уметь Scrum-мастер

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

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

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

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

А что еще?

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

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

Конечно, всегда остается необходимость поучиться основам Agile/Scrum, фасилитации, конфликтологии, коучингу и так далее, но только наличие первоначального опыта работы с людьми гарантирует успех.

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

Что можно посоветовать людям, которые хотят стать Scrum-мастерами

Обучитесь фасилитации, коучингу, конфликтологии. Эти навыки являются базовыми для любого Scrum-мастера.
Получите 1-2 года опыта управления командой из 5-7 человек. Так вы поймете основные нюансы и трудности, с которыми приходится сталкиваться.
Прочитайте книгу Джеффа Сазерленда «Scrum — революционный метод управления проектами».
Походите на конференции, посвященные Agile, пообщайтесь со спикерами, задавайте вопросы, спрашивайте примеры успешных кейсов.
Попробуйте себя в качестве рядового участника Scrum-команды, проявляйте инициативу, на практике развивайте навыки, которые вы приобрели ранее.
Договоритесь с вашим Scrum-мастером, чтобы он иногда позволял вам проводить Scrum-мероприятия для обретения навыков. Для него это будет возможность снизить нагрузку и вырастить себе смену.
Пройдите сертификационный тренинг по основам Agile/Scrum, чтобы было чем подтвердить свои навыки и образование перед работодателем.

Читайте также: