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

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

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

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

Аварийная процедура

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

Именно поэтому, когда вы видите, что показатели команды находятся в верхней части диаграммы сгорания задач, примените технику, которой постоянно пользуются пилоты. Когда случаются неприятности, запустите аварийную процедуру, разработанную специально для вашей проблемы[39].

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

Мой отец был летчиком-истребителем во Вьетнаме. Он говорит, что, когда в самолете случаются неполадки, нужно немедленно запустить аварийную процедуру. До момента, когда вы поймете, в чем проблема, можно и не дожить. Именно поэтому к левому бедру крепился список действий, и в аварийной ситуации пилоты начинали ему следовать. Без вопросов. В Scrum тоже есть похожий список, и scrum-мастер должен начать следовать ему незамедлительно – таково правило.

Список выглядит так.

АВАРИЙНАЯ ПРОЦЕДУРА SCRUM (ВЫПОЛНИТЕ РОВНО СТОЛЬКО ШАГОВ, СКОЛЬКО НЕОБХОДИМО.)

1. Измените способы работы команды. Сделайте что-то иначе.

2. Попросите помощи, передайте элементы бэклога спринта кому-то еще.

3. Уменьшите объем работ.

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

Автоматически следуйте шагам в списке. Если вы ничего не предпримете, вся команда потерпит крушение. Тяните штурвал на себя.

Дэвид из 3M HIS сказал, что Тэмми периодически сталкивается с аварийными ситуациями: «Тэмми использовала “бэт-сигнал”, чтобы прояснить ситуацию. Такое случалось, наверное, раз пять». На самом деле Тэмми хочет, чтобы ее команды пользовались аварийными сигналами чаще, не жертвовали качеством ради скорости. Используйте «бэт-сигнал». Он позволяет обозначить проблемы. Если команды этого не делают, то и вы не можете понять, почему начинает падать качество или сроки затягиваются. Вам нужно поощрять свои команды. Хвалите их за то, что они сообщают вам об аварийных ситуациях.

Scrum для Scrum