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

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

Кайдзен.Во время каждой ретроспективы команда должна находить одно улучшение, кайдзен, чтобы постараться внедрить его в течение следующего спринта. Это может быть устранение препятствия, ввод нового способа работы или что-то еще, если команда чувствует, что это повысит скорость. Если эксперимент удается, продолжайте действовать так же. Если нет (не все, что вы попробуете, будет работать), отбросьте это улучшение.

Используйте шаблоны Scrum.

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

• Рой, Буфер на отвлечения, Аварийная процедураи Соблюдение чистотыпомогут решить самые распространенные проблемы команды, возникающие во время спринта.

• Scrum для Scrumи Счастье – ключи к постоянному улучшению в устойчивом ритме. Они помогут добиться гиперпродуктивности – цели, для которой был разработан Scrum. Вдвое больше работы за половину времени.

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

1. Определите по меньшей мере по одному примеру мура, м уда и мури на вашем рабочем месте. Как вы можете их исправить?

2. Создайте диаграмму сгорания задач и начните отслеживать прогресс вашей команды на протяжении спринта.

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

Раз есть полезные шаблоны – непременно существуют и такие, которым не стоит следовать, – антишаблоны. Не каждый переход на Scrum сработает. Здесь тоже есть вероятность неудачи. Интересно здесь то, что провалы случаются, как правило, по одним и тем же причинам.

Повторюсь: Scrum создан для быстрого выявления проблем. Зачастую это болезненно. Вот почему иногда организационные изменения невозможны.

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

– Джей Джей, ты меня возненавидишь.

– Что случилось?

– Ничего не работает.

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

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

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

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

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

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

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

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

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

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