Цитаты из книги «Путь скрам-мастера»

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

Оборона Готовность к обороне является вторым наиболее распространенным типом токсичного поведения, которого хорошая команда должна всячески избегать. Оно часто начинает проявляться в ответ на обвинения. В продолжение предыдущего примера Владелец продукта может ответить: «Это не моя вина! Не я планирую бэклог спринта. Кроме того, он прошел через груминг

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

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

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

Последним слоем пирамиды командных пороков является безразличие к результатам, иными словами — преследование неких индивидуальных, частных целей вместо одной общей. А ведь именно общая цель — это то, чего мы стремимся достичь с помощью Scrum. Вместо собрания отдельных индивидуумов со своими ноу-хау, создающих отдельные коды или тесты, должна возникнуть команда, объединенная общей целью — принести пользу заказчику. Это требует огромного сдвига в сознании, но очень важно для успеха.

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

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

Уход от конфликтов В такой команде все избегают конфликтов, стремясь сохранить искусственную гармонию. Как в фазе шторминга по модели Такмана, здесь стараются не затевать никаких обсуждений, которые могли бы стать трудными, продолжают разделять общую работу на отдельные персональные зоны ответственности, основанные на технических знаниях или знаниях продукта, и придерживаются этого. Здесь вы услышите: «Почему мы должны тратить время на дискуссии, когда у каждого есть отдельный сегмент работы?» или «Не имеет смысла всем вместе заниматься каждой отдельной пользовательской историей, это приведет лишь к ненужной путанице в командном общении».

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