Scrum – это не для всех

Гибкие методологии – тренд в управлении проектами и работой с командами последние лет пять. Вокруг них много споров и разговоров, но в грамотных руках этот инструмент может творить чудеса. Одной из таких методологий является Scrum, ставший популярным в 2012 году после использования в разработке системы «Страж» для ФБР.

Сегодня я расскажу вам, как мы внедрили Scrum в работу над нашим проектом Workly – сервисом, который помогает оптимизировать работу коллектива.

Проблема

В 2010 году мы запустились.

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

Отсутствие синхронизации у менеджмента убивало у разработчиков ответственность за результат, лишало их «маленьких побед». Все это демотивировало коллектив в целом – и в итоге стало самой большой проблемой в работе. Команда не видела общих ценностей и не чувствовала сплоченности.

Для решения этой проблемы мы решили попробовать перестроить работу по гибким методологиям, а именно – по Scrum.

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

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

Начало. Как переходить на Scrum?

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

С чего нужно начинать?

1. Убрать опасения

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

2. Повысить значимость отдельного человека

Очень важно, чтобы люди чувствовали себя командой, а не исполнителями. Не делили коллектив на «мы» – команда, и «они» – руководители.

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

3. Определить главную цель и ценности компании

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

4. Избавиться от внеплановых задач

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

5. Уметь говорить начальнику «нет»

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

Небольшие сложности

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

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

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

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

Первые результаты

Команда была готова к работе с методологией только после того, как мы обеспечили условия для работы:

• Один посредник между руководством и разработчиками,
• Условный срок на выполнение задач,
• Заинтересованность в результате каждого,
• Фокусировка на своих целях и ценностях.

У команды появились ценности. Вот какие ценности мы определили:

1. Мы решаем задачи, а не пишем код.
2. Если правило мешает нам быть эффективными – мы от него отказываемся.
3. Идеальная задача выглядит как потребность, а не как требование. Мы сами решим, что и как делать, чтобы решить задачу.
4. Мы честны друг перед другом – и поэтому доверяем.
5. Каждый делает все, что от него зависит, настолько хорошо, насколько может, и с тем, что имеет в сложившейся ситуации.
6. Мы не ищем виноватых, мы ищем наилучшие пути решения проблемы.
7. Мы стараемся не повторять ошибки, мы не стесняемся их. Ошибки – это наш путь к улучшению себя и нашего продукта.
8. Нам как профессионалам доверяют задачи, а мы выбираем пути решения –­ и поэтому несем ответственность за результат, принимаясь за работу.
9. Мы не говорим «кажется/по идее/теоретически, это работает так», мы говорим – «это работает так».
10. Если нужно решить проблему, мы встаем и решаем, мы идем и спрашиваем, мы говорим о проблемах открыто – потому что не хотим впоследствии искать виноватых.
    

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

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

Как изменился формат работы?

• Два часа на планирование спринта. Поступает задача и определяется продолжительность спринта.
• По 15 минут в день на Scrum-стендап. Каждый член команды рассказывает о выполнении задач, возникающих проблемах и вариантах их решения.
• Полтора часа презентации в конце спринта. Еще один важный инструмент в методологии, тонизирующий команду и позволяющий гордиться своими результатами.
• Ретроспектива после презентации. Командная работа над ошибками, в процессе которой выясняются причины, почему спринт прошел не так гладко, как ожидалось, и что мешало идеальной работе. Важно, чтобы во время спринта все члены команды были максимально откровенны и честны друг с другом.
• В методологии Scrum вообще важна взаимозаменяемость членов команды. Особенностью нашего рабочего процесса стала ротация разработчиков между отделами — завершив работу в одном проекте, сотрудник (при желании) может перейти в другой проект и поделиться имеющимся опытом. В итоге все члены команды готовы были решать поступающие проблемы, стали организованными и взаимозаменяемыми.

Материалы по теме:

Пословицы и поговорки из мира IT

Холакратия – смерть для компании?

6 этапов «студийной» разработки стартапа

12 полезных книг для руководителя

Когда проекту нужно посмотреть в прошлое?

Фото на обложке: Shutterstock.