Лисса Адкинс - Коучинг agile-команд. Руководство для scrum-мастеров, agile-коучей и руководителей проектов в переходный период

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

Представьте команду, которая допускает ошибки, увеличивает общие ценности, участники которой прощают друг друга и двигаются дальше. Как вы думаете, будет ли такая команда генерировать удивительные идеи? Я думаю, да.

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

Мое предвзятое отношение к определению agile-коуча связано с прошлым опытом. Когда я впервые узнала об Agile, я работала в компании, где роль agile-коуча рассматривалась как способ не зацикливаться на одном инструменте из agile-возможностей. Со временем те команды, с которыми я занималась коучингом, использовали Scrum вместе с практиками бережливого производства, «шести сигм», экстремальным программированием и разработкой, ориентированной на пользователя. В этих ситуациях термин «agile-коуч» подходит больше, чем «scrum-мастер».

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

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

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

Чтобы стать agile-коучем, необходимо начать с осознания того, где вы сейчас находитесь. Даже очень опытные коучи выявляют новые возможные риски, когда изучают методы работы своих коллег, применяемые для обучения людей, команд и целых организаций, выстроенных вокруг команд. Они (и я) все еще в пути.

В главе 13 «Это ваше путешествие»рассказывается о разных типах коучей, имеющих различный бэкграунд.

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

Рис. 1.2. Хотя путь каждого человека к тому, чтобы стать agile-коучем, индивидуален, некоторые вещи могут казаться знакомыми для тех, кто имеет похожий жизненный опыт

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