Джей Сазерленд - Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

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

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

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

Абекассис утверждает: тогда им казалось, будто они упали на самое дно. «В тот момент они сделали шаг назад и сказали: “Хорошо, мы это сделаем”. И это создало ускорение, которое привело к повышению продуктивности нашей команды. Но главное – мы трансформировали нашу организацию так, что она превратилась в одну команду с общей миссией. Это было похоже на волшебство».

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

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

Один из распространенных способов избежать таких атак – внедрить двойную операционную систему. С одной стороны очень яркой линии у вас находятся ваши agile-команды; с другой – традиционная иерархия. И вам нужно установить четко определенные способы взаимодействия между ними.

Приведу пример. Компания Markem Imaje производит промышленные продукты для отслеживания, определения и наклеивания ярлыков на все – от косметики до конфет и молочных продуктов. Б о льшая часть их производственной линейки – промышленные принтеры. Высокоскоростные принтеры вроде тех, что печатают даты производства на упаковках пищевых продуктов. Компания ведет бизнес уже более ста лет. Десятилетиями каждый раз, когда они выпускали новый принтер, вместе с ним открывался специальный кол-центр и создавалась ударная группа из специалистов, которые быстро исправляли все дефекты в новом поколении устройств. Мучительный процесс. Недовольные покупатели. Ситуация изматывала всю компанию. Вдобавок это было еще и накладно: после определенного числа неудачных выпусков покупателям меньше хочется приобретать следующий продукт.

Несколько лет назад, чтобы разработать принтер нового поколения, Markem Imaje создали небольшое бизнес-подразделение, собрав вместе разные команды: программное обеспечение, электромеханику, химию, маркетинг, продажи, производство, контроль качества. Крис Салливан обратился в Scrum Inc., чтобы мы помогли командам, занимающимся ПО, перейти к новым способам работы. Он хотел быстро получить высокое качество и решил, что для этого командам нужно как минимум перейти к фреймворку Scrum. С командой разработки ПО все сложилось. Но остальные не хотели использовать Scrum.

Они не понимали преимуществ Scrum или не видели причин менять способы работы, к которым привыкли. «Хорошо, – сказал им Крис. – Тогда сделайте только одно. Я хочу каждый день по пятнадцать минут проводить встречи с представителями групп – лидерами, которые могут влиять на изменения в группе. Всего пятнадцать минут. Я хочу использовать масштабированный ежедневный Scrum, чтобы мы могли координировать наши усилия». Он сказал, что сначала процесс был очень неудобен. Люди не хотели говорить о проблемах открыто. Но само мероприятие изменило многое. Коммуникация стала быстрее, время передачи решений сократилось. Проблемы, которые раньше рассматривались месяцами, стали видны, появилась возможность решить их за несколько часов. Например, сотрудники из команды, занятой электромеханикой, могли упомянуть, что немного изменили форму печатающей головки по каким-то причинам, а специалисты-химики отвечали: «Слава богу, что вы нам об этом сказали! Мы собрались изменить вязкость чернил».

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

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

Я хочу рассказать вам чуть больше об одной из команд в Schlumberger. Она отвечала за преобразование данных, полученных от этих 150 унаследованных систем в разных частях Северной Америки. Они стремились конвертировать 70 % унаследованных систем в каждой точке. Однако самый высокий их результат составлял 17 %. Можете себе представить, насколько счастливы были менеджеры.

После перехода к использованию Scrum они испытывали такие же трудности, как и многие другие команды. Они находились далеко друг от друга: члены команды жили в Техасе, Франции и Индии. У них был ограничен доступ к специалистам в предметных областях (СПО); один из СПО и вовсе должен был работать в четырех разных scrum-командах одновременно. Им не хватало людей. Было сложно.

Александра Уриарте, коуч и тренер Scrum Inc., которая работала с командой несколько месяцев, сказала мне, что ключом к решению проблемы станет выделенность и работа на полный день в команде scrum-мастера и владельца продукта. Владелец продукта Уолтер сказал, что после обучения у Алекс они приняли решение: «Мы действительно хотели использовать на практике все, что узнали за время обучения. Мы знали, что наши старые методы не работали».

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