Создать крутую команду. Крутая команда сама способна справиться с проблемами. Он постоянно находит зоны роста и способы повышать планку возможностей команды.

Масштаб проблем, которые она способна решить самостоятельно. Способность быстро реагировать на быстро изменяющиеся условия.

Scrum–мастер делает команду, с которой он работает, крутой. Agile–коуч делает подразделение, компанию, бизнес, с которым он работает, крутой.

Зачем нужны скрам–мастера, чем конкретно они занимаются?

Чтобы в этом разобраться, вспомним, как устроены функциональные организации.

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

В каждом отделе есть функциональный руководитель — координатор всего отдела.

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

Всё формируется под команду или проект. Команда небольшая, но фиксированная и понятная. Менеджер раздаёт задачи, тимлид назначает задачи и отвечает за результат.

Схема более эффективная, потому что время производства продукта значительно сокращается. К тому же не нужно выделять ресурсы.

Итог: нужно ещё быстрее. Для этого нужно по–другому ставить задачи.

В ней:

• задачи раздаёт команда
• скрам–мастер отвечает за процессы
• все стремятся к достижению результата

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

Член команды приходит к скрам–мастеру: «У меня проблема!»

Что отвечает ментор: «Попробуй вот так… У меня это работало» Что отвечает тренер: «Сначала А. Потом Б. Затем В» Что отвечает фасилитатор: «Давайте проведём совместное обсуждение» Что отвечает коуч: «Почему ты считаешь это проблемой? Какие варианты решение ты видишь?»

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

Всегда у команды есть проблема, с которой она борется здесь и сейчас. Она может быть внутренней (не хватает ресурсов) или внешней (неисправность техники).

Скрам–мастер быстро ликвидирует препятствия, чтобы команда могла перемещаться в нужном направлении.

Создать крутую команду. Крутая команда сама способна справиться с проблемами.

Пример: команда проводит демо–показ продукта большим начальникам. Но технари что–то не настроили или не доделали. Вы, как скрам–мастер, ожидаете провала, а команда убеждает вас, что всё будет хорошо.

Варианты действий:

• запинать команду и сделать всё вручную
• дать команде возможность ошибиться

Спойлер: верный вариант – второй. И после ошибки будет супер–ретроспектива.

Скрам–мастер тоже может быть не прав. Поэтому следующий уровень его развития заключён в вопросе «Как можно решить проблему так, чтобы зрелость команды выросла?».

Он постоянно находит зоны роста и способы повышать планку возможностей команды.

Он ведёт команду по уровням производства продукта:

• «Давайте поставлять хоть что–то»
• «Давайте поставлять качественно»
• «Давайте поставлять ценно»

«Знаете ли вы вашего пользователя? Что он хочет?» — вот те вопросы, которые задаются на последнем уровне. # Как можно бесконечно повышать эффективность?

Эффективность – это ценность, которую команда приносит в единицу времени. Чем больше и быстрее ценности приносит, тем лучше. Делать то, что нужно, а не то, что попросили.

Сложность задачи должна постоянно возрастать. Если задачи простые, то команда выпадает в зону «Просто. Скучно. Провал маловероятен». Если слишком сложно, то «Сложно. Трудно. Провал вероятен».

Ответ: команда должна быть в состоянии потока: она работает над амбициозными, но выполнимыми задачами.

Крутая команда — это:

• крутые результаты
• синергетический эффект
• общая цель
• общая миссия и идеалы
• дописать ещё по желанию

Масштаб проблем, которые она способна решить самостоятельно. Способность быстро реагировать на быстро изменяющиеся условия.

Scrum–мастер делает команду, с которой он работает, крутой. Agile–коуч делает подразделение, компанию, бизнес, с которым он работает, крутой.

Скрам–мастер больше модерирует процессы производства, коуч чаще выступает в роли фасилитатора и собеседника.

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

• Скрам–мастер работает с командой, помогает ей развиваться и эффективно стремиться к результату
• Он выполняет разные роли – ментор, тренер, фасилитатор, коуч
• Учит команду решать проблемы самостоятельно
• Повышает планку способностей команды через состояние потока

Вот какие антипаттерны могут появляться, когда Scrum Мастер понимает то, что он делает, как обязанности менеджера, а не как служащего лидера:

1.Он решает, кто на встрече будет говорить следующим.

Если участники команды прежде чем заговорить ищут глазами Scrum Мастера, это верный знак: вместо фасилитации он вернулся к роли супервайзера.

2.Скрам мастер навязывает команде Burn Down чарты.

При таком антипаттерне Scrum Мастер существенное время вкладывает в обновление этих графиков. Если команде нужны Burn Down чарты, в этом нет ничего дурного, хотя их в принципе можно заменить регулярно обновляемой доской спринта.

Если же Burn Down чарты нужны только для того, чтобы отчитываться, команде стоит пересмотреть эту практику.

3.Менеджмента нет в принципе.

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

4.Scrum Мастер контролирует команду через показатели личной эффективности.

Такими показателями могут быть стори–пойнты каждого разработчика за спринт. Это классический способ протащить в аджайл принципы вертикального управления с черного хода.

5.Scrum Мастер подгоняет команду, чтобы вписаться в дедлайн.

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

6.Слишком заботится о гармонии в команде.

Бывает так, что под названием Scrum master понимают обязанность красиво заминать все конфликты и противоречия вместо того, чтобы открыто разбираться с ними на ретроспективе. Такое поведение выдает манипуляции и желание вписаться в ценности организации, которые противоречат принципам Скрама.

7.Члены команды без возражений принимают огромный бэклог спринта.

Команда регулярно берется за большее количество задач, чем ей удалось бы без уловок Scrum Мастера. В конце спринта 50% задач остаются невыполненными, и их перебрасывают в следующий спринт.

Если такое вошло в привычку, то команда практикует не Скрам… а, например, Канбан с таймбоксами. Что тоже неплохо, только вам нужно определиться и придерживаться одной линии.

8.В Бэклог берут неупорядоченные истории.

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

9.100%-ная занятость.

Владелец Продукта вводит в бэклог максимум функциональной работы, а Scrum Мастер не отстаивает тот факт, что часть времени нужна на расслабление. Эффективность команды сильно снизится, если каждый спринт не оценивать ее технический долг. Когда команда занята под завязку, она всегда хуже работает в долгосрочной перспективе.

10.Нарушение рабочего потока.

Это вмешательство стейкхолдеров, которое хороший специалист должен предотвращать. Примеры:

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

11.Разработчики получают дополнительные задания.

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

12.Scrum Мастер определяет технические решения.

Такое бывает, когда Scrum Мастером становится бывший разработчик, и команда обращается к нему за подсказками.

13.Недостаточно поддержки.

Роль Scrum Мастера предусматривает поддержку людей, которые не справляются с задачами. Например, задача создана на день, а разработчик выполняет ее два дня. В здоровой Скрам–практике такие задачи на доске отмечают красными точками, а разработчику нужно помочь справиться с трудностями. К сожалению, иногда это правило игнорируют.

14.День сурка.

Ретроспективы не меняются ни по структуре, ни по месту, ни по продолжительности: все шансы решать одну и ту же проблему ретроспектива за ретроспективой — без шансов на хеппи–энд.

15.«Я подумаю об этом завтра».

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

16.#NoRetro.

Во время спринта Scrum Мастер не собирает данные, которые бы пригодились команде на ретроспективе. Это может быть признаком его профессионального выгорания.

1. Ретроспектива не документируется.

Заметки и видео с ретроспектив — не формальность, а способ поддержать должное серьезное отношение к этой встрече в команде.

17.Вопросы психологической безопасности.

Ретроспектива превращается в бесконечный поиск виноватых, а Scrum Мастер ничего с этим не делает, проигрывает вся команда.

18.Травля в команде.

Ретроспектива должна быть безопасным способом обратной связи для всех участников команды, в том числе неразговорчивых или, например, не самых популярных в коллективе людей. Если на ней кто–то кому–то будет угрожать, а Scrum Мастер не вмешается, она перестанет быть безопасным местом для высказываний, и люди будут ее избегать. Например: время на высказывание в эффективных командах Google распределяется поровну между участниками. Больше материала по этой теме есть в статье " What Google Learned From Its Quest to Build the Perfect Team".

19.Участие стейкхолдеров.

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

На трех уровнях:

1. Почему\Зачем делаем? — это бизнес кейс (business case) = цель продукта (product goal) — что продаем ?

«Осуществить свою мечту прямо сейчас — взять потребительский кредит»

2. Что делаем? — это беклог продукта (product backlog) — список функциональности продукта

3. Как делаем? — это беклог спринта (sprint backlog) — мгновенное подтверждение кредита

Декомпозируем на задачи (tasks) — подключиться к вебсервису, передать паспортные данные, получить кредитную историю.