Agile по правилам Scrum

Про людей и итерации

Подход разработан Кеном Швабером и Джеффом Сазерлендом в середине 90-х годов прошлого века.  Согласно официальному определению, «скрам — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью». Информация о ролях, событиях, артефактах и правилах фреймворка закреплена в Руководстве по скрам, разработанном авторами подхода.

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

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

Длительность спринта варьируется от 1 до 4 недель, но обычно это 2 недели. Чем короче спринт, тем гибче процесс. В идеале каждый спринт должен иметь цель, которая мотивировала бы всю команду.

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

Подробнее о сферах применения и преимуществах Scrum читайте в статье «Agile - новый Lean» 

Scrum на заводе Grass

«Некоторое время назад моя компания помогала внедрять Scrum на заводе Grass, производящем бытовую химию. Годовая выручка компании — несколько миллиардов рублей. В штате работает 800 человек, из которых офисными сотрудниками являются 150. Это те люди, которые занимаются разработкой новых продуктов, продвижением и т.д.

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

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

В результате внедрения Scrum заводу за год удалось добиться 40-процентного роста выручки по отношению к прошлогодним результатам и сократить время вывода нового продукта на рынок на 30%.

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

Алексей Дерюшкин, основатель Better Life Company, консультант по гибким методологиям в бизнесе

подробнее

Scrum как театр

Скрам — ролевая практика, где ключевые функции выполняют:

1. Владелец продукта.

2. Скрам-мастер.

3. Скрам-команда.

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

Если команду рассматривать как микропредприятие внутри большой компании, то владелец продукта — микрособственник.

Алексей Дерюшкин

основатель Better Life Company, консультант по гибким методологиям в бизнесе

Скрам-мастер, или Scrum Master — следит за тем, чтобы процесс разработки проиcходил согласно требованиям Scrum: спринты должны вовремя запускаться, команда разработки должна иметь необходимые ресурсы, собрания должны проводится вовремя. Скрам-мастер также может быть коучем как для команды разработки, так и  для владельца продукта . В некотором смысле скрам-мастера можно назвать евангелистом подхода.

Если владелец продукта отвечает за результат, скрам-мастер — за процесс.

Алексей Дерюшкин

Скрам-команда, или Scrum Team — состоит из кроссфункциональных специалистов, например, дизайнеров, программистов, бизнес-аналитиков, юристов, маркетологов, инженеров и т.д. Руководство по скраму рекомендует включать в команду от 3 до 9 человек.

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

Алексей Дерюшкин

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

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

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

Алексей Дерюшкин

Правила игры

Скрам разделяет проектную деятельность на ряд событий:

1. Планирование спринта. В ходе этого собрания, обычно длящегося 1-2 часа, команда самостоятельно выбирает из бэклога продукта ряд задач для спринта (цель спринта) и формирует из них список подзадач на данный период — бэклог спринта.  

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

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

2. Ежедневный скрам, дейли, дейли-митинг, стендап — 15-минутная ежедневная встреча команды и скрам-мастера. В ходе собрания каждый член команды рассказывает о том, что он сделал вчера и будет делать сегодня, какие видит препятствия для выполнения работы. Причины проблем и способы их устранения на собрании не обсуждаются. Цель ежедневного скрама — отслеживание хода работы команды.

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

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

Как запустить скрам

Процесс трансформации компаний небыстрый. Сначала подход отрабатывается в рамках пилота на одном подразделении компании, далее идет разворачивание на всю компанию и отработка практик. По данным исследования 2019 года, 73% компаний внедряют  Agile  в течение 3 лет экспериментов, а у 41% компаний это занимает не более одного года.

Подробнее об Agile-трансформации читайте в статье «Agile не на словах, а в головах»

Среди главных проблем масштабирования:

1. Недостаточность опыта специалистов.

2. Непоследовательность внедрения практик и процессов.

3. Низкая вовлеченность бизнеса, заказчика или владельца продукта.

4. Доминирование традиционных подходов.

5. Противоречие корпоративной культуры ценностям Agile.

С другой стороны, к факторам, повышающим успех разворачивания гибких подходов управления проектами, можно отнести:

1. Поддержку руководства компании.

2. Поддержку изменений большинством сотрудников.

3. Согласованность между собой процессов и практик.

4. Внедрение общих инструментов между командами.

5. Внутренние тренинги.

6. Внутренних Agile-коучей.  

Давать рекомендации по внедрению Agile по скрам или с помощью любого другого фреймворка — дело неблагодарное, считает Алексей Дерюшкин. В каждом конкретном случае требуется свой подход. Однако ряд общих советов Алексей все же дает:

1. Управляйте не людьми, а задачами.

2. Уберите весь лишний контроль, кроме контроля за результатами.

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

4. Не мешайте людям работать, но проверяйте, как достигаются цели.

Успехов на пути трансформации!