Тренеры, которые не видели "продвинутые" Agile-организации, склонны рассматривать "правила" Scrum, как целевое состояние, а не как отправную точку.

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

Поначалу это воодушевляло. Все были вовлечены и полны энтузиазма.

Были сформированы стабильные команды, и работа распределена между ними в соответствии с цепочками ценности. Люди стали работать в помещениях, спроектированных для совместной работы, а не сидя в изолированных ячейках, как отшельники.

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

Пусть всегда будет солнце

Жизнь была хороша.

И время шло. И шло.

И шло.

Узнав всё, что нужно было знать обо всех видах работ, которые выполняли их стабильные команды, люди начали задаваться вопросом, когда и каким образом они могут получить возможность учиться чему-то новому. Жизнь приняла форму бесконечного сериала из пользовательских историй, ведущих к однотипным изменениям одних и тех же частей одного и того же кода снова и снова.

И время шло.

Как насчёт коллективной ответственности? Самоорганизации? Ретроспективного анализа?

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

Все разобщены и все безразличны.

Как зомби.

Руководство и заказчики из бизнеса не видят проблемы. Они получают необходимую им ценность стабильно, предсказуемо и более эффективно, чем было до внедрения Scrum.

Команды управления портфелем и программами проектов (или их эквиваленты под любым другим именем) не видят проблемы. Ведь Команды поставки принимают пользовательские истории (User Stories) в работу в соответствии с определёнными приоритетами и стабильно предоставляют результаты.

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

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

Добавим коучей

Здорово иметь себе в помощь Agile-коучей! Что они скажут о ситуации?

Они скажут что-то вроде этого:

Вы самоорганизующаяся команда! Вы можете в этом разобраться!

• Поднимите этот вопрос на следующей ретроспективе. Не забудьте определить необходимые пункты действий!
• Если вы не можете решить проблему на уровне команды, эскалируйте!
• Agile-люди увлечены своей работой. Отыщите в себе азарт!
• Смотрите на этот вдохновляющий постер о Scrum, пока не почувствуете себя лучше.

Ладно, последний пункт немного язвительный. Но только немного. Самое печальное, что это не очень далеко от истины. Это практически Scrum-эквивалент традиционной мантры "The beatings will continue until morale improves" ("Избиение продолжится, пока не возрастёт мораль", имеется в виду непродуктивность принуждения к чему-либо, примечание переводчика).

Чрезмерная сертификация

По неофициальным данным, которые у меня есть, более 400 000 человек прошли сертифицированный курс ScrumMaster (CSM), предлагаемый Scrum Alliance. На сайте Scrum.org, принадлежащем этой организации, указано, что более 100 000 человек являются обладателями профессиональных Scrum-сертификатов . Это довольно много.

Почему, в таком случае, так мало Agile- или Scrum-тренеров, которые могут работать выше начального уровня? Может быть, это тот самый случай, когда "хорошего нужно понемножку"?

Люди, которые интересуются Scrum, но не очень хорошо понимают, о чём это, как правило, рассматривают сертификацию, как форму гарантии того, что они слушают правильных людей. Scrum Alliance и Scrum.org рады предложить программы сертификации. Многие Agile-тренеры имеют базовые сертификаты от одной или от обеих этих организаций. У многих из них есть опыт запуска основных практик Scrum в командах и организациях. Их карьерный путь заключается в запуске Scum в одной организации, потом в следующей, потом ещё в одной… думаю, вы понимаете, к чему это приводит. У большинства Agile- и Scrum-тренеров нет опыта работы за пределами начальных этапов запуска в организации Agile-подхода в целом и Scrum в частности. Они не в курсе проблем, которые обычно возникают после длительной серии спринтов.

Может что-то не так с процессом сертификации? Ну, не совсем. Вы же должны с чего-то начать. Но базовый уровень сертификации, Certified ScrumMaster (CSM), на удивление легко получить. Один мой коллега сообщил, что его ребенок сдал этот экзамен с первой попытки. При этом ребенок никогда не обучался на курсе CSM и интересовался Agile ровно настолько, насколько любой другой ребенок (читай, не очень).

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

Зомби-Scrum – это абсолютно нормальный и предсказуемый этап в развитии организации. Большинство тренеров не знают, как помочь командам зомби-Scrum, потому что они никогда не оставались с командами настолько долго, чтобы увидеть проблемы на практике.

Также и литература о Scrum ничего не говорит о зомби-командах. Это может плохо сказаться на её продажах.

Все проблемы – это проблемы управления

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

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

Эта искаженная роль ScrumMaster имеет сразу две обязанности, которые находятся в прямом противоречии друг с другом. Одна из них – помогать команде использовать Scrum эффективно и поддерживать её усилия, направленные на постоянное совершенствование. Вторая – это прямая ответственность за обеспечение доставки ценности. Свежеиспечённые Scrum-мастера наследуют эту вторую обязанность от упразднённых менеджеров проектов, которых руководство по-прежнему считает необходимыми.

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

Это не проблема тренера, это проблема менеджмента. Ваша роль определена неправильно.

Можно ли разбудить зомби?

Один из ведущих Scrum-тренеров и консультантов в Европе, Джозеф Пелрин (Joseph Pelrine), описывает модель производительности Scrum-команды, которую он назвал Кулинарная Модель. Когда вы готовите, вам важно, чтобы температура не падала настолько низко, чтобы еда застыла и превратилась в безвкусную массу. В то же время вам важно, чтобы температура не поднималась слишком высоко, иначе ваше блюдо подгорит. Вам важно найти оптимальную температуру для приготовления. Аналогично, существует оптимальная "температура" для scrum-команд. Слишком много стресса, и команда взрывается. Слишком скучно, и члены команды превращаются в зомби.

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

Другой фактор, о котором нужно всегда помнить, следующий: большинство рекомендаций и практик, описанных в литературе по Scrum, являются отправными точками для выстраивания работы scrum-команд. По мере, того, как команды начинают всё больше руководствоваться принципами agile и lean, их рабочие процессы будут требовать всё меньше усилий на управление. Тренеры, которые не видели продвинутых Agile-команд, как правило, рассматривают "правила" Scrum, как описание целевого состояния команды, а не как отправную точку. Когда команды "перерастают" потребность в наличии чётких правил, но им по-прежнему необходимо этим правилам следовать, они уходят. Тренеры, которые не видели этого, не могут знать, как помочь командам преодолеть  совершенно нормальную стадию "зомби Scrum".

Представьте, если бы…

Эти "стартовые правила" включают в себя некоторые "святейшие из святых" постулатов начинающих Agile-тренеров. Межфункциональные команды. Стабильные команды. Ограничение объёма отдельных задач. И так далее.

Все эти "правила" имеют своё назначение. Не стоит забывать, что Scrum был создан в начале 1990-х на базе работы, опубликованной в середине 1980-х. Вспомните состояние области корпоративных ИТ в то время. Матричные организации. Сотрудники, отвечающие сразу за несколько проектов. Деление по функциональным направлениям. Разобщённость, низкая координация работ между направлениями. "Непрямые" коммуникации.

И как результат: очень длинные сроки доставки результатов. Высокий уровень ошибок. Низкая удовлетворенность заказчиков.

Scrum предлагал практические подходы к борьбе с этими проблемами. Следуя "правилам" Scrum, организации 1980-х смогли избавиться от "вредных привычек" и начали добиваться лучших результатов.

Правда ли нам нужны межфункциональные команды? Скажем так, это лучше, чем отдельные люди, разбросанные повсюду, не сотрудничающие между собой и общающиеся только косвенно с помощью "инструментов" и т.д. Но цель состоит не только в том, чтобы сидеть в одной комнате вместе. Цель – сотрудничество. Если люди заинтересованы в сотрудничестве, они найдут способ это делать. Сегодня у нас есть технологии, которые поддерживают дистанционную совместную работу. Больше нет необходимости заставлять всех сидеть вместе физически. На самом деле, это и раньше не было самоцелью. Это было лишь средством достижения других целей.

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

Есть ли во всём этом смысл?

Пожалуй, да. Феномен "зомби Scrum" может быть сигналом к действию, признаком того, что организация готова выйти за рамки практик начального уровня, предоставить командам ещё больше свободы в принятии решений, и осторожно менять или упразднять некоторые "правила". Встряхнуться. Восстановить энтузиазм людей. Расти.

Всё написанное выше – просто пища для размышлений. Между тем, всё это заставило меня почувствовать себя немного голодным. Пожалуйста, передайте мозги.

​Оригинал статьи Zombie SCRUM, автор Дейв Николетт (Dave Nicolette)

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую