Про Scrum часто можно услышать фразы вроде «православный Scrum», «мы используем best practices из Scrum» или «что почти всегда остается» от техник Scrum при его реализации.
Говоря это, подразумевают, что Scrum — это некоторая эзотерическая методика, которая неприменима в реальной жизни по той или иной причине. Например потому что «для скрам нужно очень много бабла, а мы должны жить по средствам» или «в Scrum разработчики должны быть супер универсальными, а у нас таких нет». А раз так — делается вывод, что «нужно думать головой», и все нужно делать по-своему. В результате такого подхода в рабочем процессе появляются некоторые улучшения, но в целом ничего не меняется, что еще больше убеждает в том что Scrum — это фантазии не имеющие отношения к реальному миру. Это не так.
Практически все кто пытаются внедрить Scrum совершают две ключевые ошибки. Во-первых, пытаются внедрить Scrum только в разработке, не меняя отношения с бизнесом, что гарантирует провал затеи. Во-вторых, Scrum пытаются внедрить частично, что также делает затею безнадежной.
В этом посте я расскажу почему Scrum нужно внедрять в разработке, только добившись поддержки этой идеи во всей компании.
Scrum как Игра
Наиболее точное описание Scrum вынесено на титульный лист Scrum Guide.
Scrum — это правила игры.
Scrum — это не только описание процесса (planning, daily, review, retro), но и определение ролей участников игры, их отношений друг с другом и ценностей которые они разделяют.
Например, шахматы. Два игрока перемещают фигуры на поле. Один — только белые. Другой — только черные. Есть очередность ходов и правила, по которым ходит конь и пешка. В серьезные шахматы играют на время.
Что будет если игроки заявляют, что играют в “шахматы”, а на самом деле продолжат играть в шашки шахматными фигурами? Что будет, если, играя в “шахматы”, один игрок будет следовать правилам настоящих шахмат, а второй будет играть в “Чапаева”?
Scrum Guide — продуманный, разумный, глубокий, сбалансированный, сложный для понимания документ. К текущей редакции 2016 года ему более 20 лет (Scrum был публично анонсирован в 1995), при этом его объем всего 17 страниц. Достаточно ли его одного, чтобы организовать работу компании? Нет, как и шахматных правил недостаточно, чтобы научиться играть хорошо.
В то же время Scrum Guide не появился из вакуума и в действительности основывается на принципах и техниках организации работы, выработанных в производстве и доказавших свою состоятельность на практике. История знает примеры применения теоретических принципов на практике с разной степенью успешности.
Хенниг Бранд, основываясь на принципах алхимии, пытался получить золото, выпаривая воду из мочи. Основная идея была в том, что и то, и другое золотистого цвета. Нельзя сказать, что затея полностью провалилась. В результате он в 1669 году получил фосфор, который, как и золото, имеет определенную коммерческую ценность. Но это все же была чистая удача. Построенный на этих принципах “стартап”, хотя и принес владельцу поначалу некоторый доход, в целом быстро провалился и был продан за сравнительно небольшую сумму.
С другой стороны, Гемфри Деви, основываясь на принципах электролиза, в 1807 году открыл калий, натрий, барий и кальций (И это далеко не полный список химических элементов им открытых). Трудно назвать его результат иначе как закономерным. Что, впрочем, не умаляет его личного таланта, упорства и бесстрашия.
Scrum и теория ограничений Голдратта
Элияху М. Голдратт, признанный гуру теории бизнес менеджмента, автор Теории Ограничений, в книге «The Goal» объясняет техники поиска и устранения узких мест в производственном процессе. В «Isn’t it Obvious?» он рассказывает о том, как увеличить продажи, сократив количество отсутствующих позиций наиболее популярных товаров за счет реорганизации работы системы магазина-склада.
Его теории объединяет идея, что для достижения реальных результатов для компании, все эти процессы должны быть реорганизовывать одновременно, в комплексе и с учетом интересов всех сторон. Эту мысль он высказывает в книге, подводящей итог предыдущим, «Beyond the Goal». Парадокс заключается в том, что оптимизация только части процессов компании, например, только разработки, не только не приведет к росту бизнеса в целом, но и может негативно сказаться на сотрудниках подразделения, добившегося существенных улучшений в продуктивности своей работы.
Это в полной мере относится к Scrum. Внедрять его только в разработке, не достигнув понимания и согласия работы по Scrum во всей компании — заведомо плохая идея. Да, техники Scrum позволяют существенно расширить возможности разработки. Это позволит быстро и качественно выпустить множество новых функций приложения… которые в результате будут совершенно не нужны пользователям. “Ваш продукт слишком сложный, мы не смогли разобраться, грустный смайлик”. Результат — недовольство со стороны бизнеса и разочарование на стороне разработки.
Игра для всех
Прежде чем менять что либо в процессе разработки, необходимо добиться полного признания Scrum всеми в компании. В частности это требует общего принятия ценностей Scrum (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): исполнительность, смелость, сфокусированность, открытость и уважение.
Пренебрегая ценностями Scrum, легко уничтожить все выгоды которые он может дать.
Если владелец бизнеса не уважает право Product Owner’а принимать решения по развитию продукта и навязывает ему конкретный план действий, вся Scrum-команда лишается возможности быстро адаптироваться, поскольку не сможет принять никакие решения самостоятельно.
Если Product Owner не будет исполнять обязательство по увеличению ценности продукта, что является единственной его ответственностью, как он сможет сохранить доверие со стороны владельцев бизнеса?
Если Product Owner не будет иметь смелости менять продукт и пробовать что-то новое, как он сможет добиться увеличения ценности продукта? Ведь любое улучшение — это в конечном итоге изменение.
Если Product Owner не будет уважать право Development Team на самоорганизацию, и на ежедневной основе будет вмешиваться в работу команды, постоянно меняя планы и контролируя все этапы работы, Development Team не сможет улучшить свою производительность. Результат ее работы будет стабильно мизерным и посредственным.
Если Development Team не будет исполнять обещания по достижения целей взятых в спринт, как она сможет сохранить самостоятельность и доверие со стороны Product Owner?
Если Scrum Team не сумеет сфокусировать свою работу на конкретной цели для конкретного спринта, а вместо этого будет распылять усилия по множеству направлений, как она добьется ощутимых результатов? А если от работы не будет видно отдачи, пусть и негативной, как можно будет понять, стоит ли дальше развивать выбранное направление или наоборот нужно вернуть все, как было, и выкинуть то, что сделано. А на то чтобы уметь выкидывать из продукта то, что было сделано, но оказалось ненужным, тоже нужна смелость и решительность.
Если все стороны не будут открыты друг другу в тех проблемах, с которыми они сталкиваются и будут скрывать трудности коммерческого или технического плана, это все равно со временем станет известно. Но доверие и уважение будет потеряно.
Недостаточно просто сказать “да, мол, мы все понимаем, что такое Scrum и будем действовать по его принципам”. Прежде всего всем нужно прочитать Scrum Guide. Серьезно, нужно прочитать. Возникшие вопросы и недопонимания нужно обсудить и согласовать. Когда все конфликты будут разрешены, каждая из сторон должна прямо и недвусмысленно заявить, как она собирается работать по Scrum, либо взаимодействовать со Scrum командами. И только тогда можно будет начинать действовать, и действовать нужно решительно и незамедлительно.
Для достижения общего понимания процесса все должны придерживаться единой терминологии. Хотя это кажется мелочью и формализмом, это действительно важно. Если владелец бизнеса называет Product Owner’а “Продукт-менеджером”, разработчики “начальством”, а сам Product Owner величает себя, например, “Императором”, можно ли говорить о том, что достигнуто взаимопонимание?
Достижение общей стратегии работы компании по Scrum — важная и сложная задача. Без ее решения двигаться дальше бессмысленно. Тем не менее она выполнима. Но это лишь первый шаг, и трудности только начинаются.
В следующем посте я постараюсь подробнее раскрыть типичные ошибки при реализации Scrum в разработке, причины, по которым они сводят пользу от Scrum к нулю и способы их исправления.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Младший оператор баш консоли
Автор: Wrike
