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

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

Она была права.

По этой причине Scrum Inc. прекратила сотрудничество с той компанией. Мы не можем заставить людей меняться – можем только помочь им измениться самим.

Годами я составлял список подобных проблем, постоянно возникающих в компаниях. И я понял: знать, как не нужно делать, так же важно, как и знать, что нужно. Вот список антишаблонов и контрмер для них.

Что делать лидерам

НЕ ОСТАНАВЛИВАЙТЕСЬ НА ПОЛПУТИ

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

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

Мой отец руководил техническим отделом компании. Он встретился с CEO PatientKeeper и рассказал ему, как собирался использовать Scrum. «Хорошо, – сказал тот, – но я устал слышать от команд, что все “готово”. Единственное “готово”, которое имеет значение, – выплаты от больниц и отсутствие спорных вопросов».

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

Как только они это сделали, CEO сказал, что теперь они могут менять приоритеты каждую неделю. По понедельникам он организовал собрания владельцев продуктов и scrum-мастеров, чтобы проводить обзоры их прогресса в доставке; изменять все, что требовало перемен; выделять средства на то, во что нужно вложить деньги; переводить фокус внимания на клиентов или конкурентов, по вине которых возникали проблемы. Сотрудники говорили, что CEO действует, как будто он scrum-мастер в команде владельцев продуктов. Он позволил ведущему владельцу продукта управлять процессом и вмешивался, только чтобы устранить препятствия в тот же день, включая смену руководства, если того требовала ситуация. Мой отец говорит, что он был похож на английского солдата былых времен. Каждую неделю владельцы продукта расставляли пушки, чтобы он мог стрелять в своих врагов. Новая неделя – новая цель. Через год у компании не осталось конкурентов. Значительную часть времени стал занимать демонтаж продуктов конкурентов в больницах, одной за другой. Прибыль подскочила на 400 % в год.

Тогда мой отец решил обучать людей использованию Scrum и основал Scrum Inc. Его преемник в PatientKeeper привлекал новые больницы каждый спринт как по часам. Несколько лет спустя он ушел из компании, и CEO нанял нового технического руководителя, который не понимал Scrum. Уже через месяц компания не могла доставлять ценность. CEO сказал новому руководителю: «Верни все как было – или ты уволен». Но ситуация повторилась. Тогда CEO решил взять на себя отдел и восстановил каскадную модель управления проектами. Доставки стали затруднительны и занимали много времени. Прибыль упала вдвое. PatientKeeper влачила жалкое существование еще несколько лет и стала примером отличной компании, которую разрушили старые практики.

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

Я видел такие случаи несколько раз. Исполнительный руководитель внедряет что-то новое в бизнес-подразделении или всей компании, но у него нет поддержки сверху. И как только его переводят в другое подразделение или он увольняется, новый способ работы исчезает. Лидеров это обычно шокирует. Как же так: те же люди делают то же самое, и вдруг их методы не работают? Причина в том, что они не приняли до конца переход к Scrum – либо для себя, либо для компании. Сотрудники, которых они направляют, напротив, обычно не удивлены тем, как меняется вектор движения руководства. Они уже видели такое раньше.