Первые 90 дней Scrum-мастера в новой команде

Вы сдали PSM I, знаете наизусть все пять событий, три ответственности и три артефакта. В понедельник вы выходите в команду, которая работает шесть лет, ненавидит слово «эджайл», проводит дейли по сорок минут в формате доклада тимлиду и называет спринтом двухнедельный отрезок между релизами. Что вы делаете во вторник?

Неправильный ответ — «начинаю чинить». Этот ответ стоит карьеры чаще, чем незнание Scrum Guide.

Эта статья — про то, как превратить теорию тринадцати предыдущих статей в работающую практику за первые три месяца. Она завершает курс и специально построена как руководство к действию, а не как конспект.

Предупреждение о статусе материала

Курс всё время разделял три уровня утверждений, и здесь это особенно важно.

Так написано в Scrum Guide. О первых 90 днях там нет ни слова. Scrum Guide описывает фреймворк, а не онбординг человека в роль. В нём есть определение ответственности Scrum-мастера («отвечает за результативность Scrum-команды», служит команде, Product Owner и организации), но нет ни плана входа, ни последовательности действий, ни срока.

Так делают на практике. Всё остальное в этой статье — обобщённая практика: книги (Майкл Уоткинс, «The First 90 Days», hbr.org), материалы Scrum.org, опыт команд. Это не канон, это эвристики, у которых есть контекст применимости.

Так делать не стоит. Отдельно помечено то, что регулярно встречается и регулярно ломается.

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

Почему 90 дней, а не 30 и не год

Число не магическое, у него есть два основания.

Первое — ритм эмпиризма. При двухнедельном спринте 90 дней — это шесть полных циклов «планирование → работа → обзор → ретроспектива». Меньше трёх циклов — вы не отличите закономерность от случайности: одна плохая ретроспектива может быть следствием того, что у человека болел зуб. Шесть циклов уже дают вам данные, а не впечатления.

Второе — терпение организации. Примерно через квартал руководитель, который вас нанял, задаёт себе вопрос «стало ли лучше». Если к этому моменту вы не можете назвать ни одного конкретного изменения и ни одного факта, подтверждающего эффект, вы начинаете тратить не свой кредит, а чужой.

Отсюда главное напряжение первых месяцев: нужно и не спешить с изменениями, и предъявить результат. Разрешается оно не компромиссом («менять понемногу всё»), а последовательностью фаз.

Смысл картинки простой. Право менять способ работы команда выдаёт вам порциями, и выдаёт по факту пользы, а не по факту должности. Если объём изменений обгоняет накопленный кредит, происходит откат: команда формально соглашается, тихо саботирует и через месяц возвращается к прежнему, а вы получаете ярлык «тот, кто хотел всё переделать». Восстанавливать кредит после этого дороже, чем зарабатывать с нуля.

Обратите внимание: снятие внешних препятствий идёт через все 90 дней и начинается почти сразу. Это единственная категория действий, которую можно делать с первой недели, — о ней ниже.

Фаза ноль: до первого рабочего дня

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

Вопросы, ответы на которые нужно получить явно:

1. Кто и зачем создал эту позицию? «У нас должен быть Scrum-мастер, потому что мы делаем Scrum» — это одна ситуация. «Команда постоянно срывает сроки, разберитесь» — совсем другая, и в ней вам уже назначили роль, которая называется иначе.
2. Был ли предыдущий Scrum-мастер и почему он ушёл? Уход в конфликте означает, что команда встретит вас с готовым сценарием ожиданий, чаще негативным.
3. Кто Product Owner и есть ли у него реальные полномочия? Если приоритеты по факту определяет комитет или директор, у вас не PO, а секретарь бэклога, — и это станет вашим главным препятствием на 60–90 дне.
4. Сколько команд? Одна — нормально. Две — тяжело, но реально. Три и больше — вам предлагают не роль Scrum-мастера, а её имитацию: на глубокую работу с командой физически не хватит времени.
5. Кому вы подчиняетесь и как оценивается ваша работа? Если в KPI зашита «скорость команды», вы подписываетесь на конфликт интересов, разобранный в статье про метрики (https://courses.digitable.life/post/scrum-master/09-empiricism-and-metrics/).

Так делать не стоит: соглашаться на формулировку «поднять velocity на 30% за квартал». Это не задача Scrum-мастера, это задача, которую невозможно выполнить честно (её всегда можно выполнить нечестно, раздув оценки). Обсуждать её нужно до выхода, а не на 89-й день.

Дни 1–30: диагностика, а не ремонт

Главное правило месяца формулируется одной фразой: вы приходите изучать систему, а не исправлять её.

Причина не в вежливости. Причина в том, что вы физически не знаете, что видите. Дейли на сорок минут может быть симптомом непонимания цели события — а может быть единственным местом, где распределённая команда вообще разговаривает, потому что всё остальное общение убито процессами. Уберёте — сделаете хуже. Ту же логику мы разбирали в статье про антипаттерны (https://courses.digitable.life/post/scrum-master/10-antipatterns/): одинаковый симптом растёт из разных причин.

Что именно наблюдать

Ходите на все события и не вмешивайтесь, кроме одного случая: событие выходит за таймбокс или явно разрушается. Тогда достаточно мягкой реплики про время, а не переустройства формата.

Так делают на практике: заводят рабочий журнал наблюдений и записывают туда факты, а не выводы. Разница принципиальна.

Плохая запись:  «Дейли неэффективное, все докладывают лиду».
Хорошая запись: «12.01, дейли 38 мин. Все 6 разработчиков говорят,
                 глядя на Игоря (тимлид). Игорь 4 раза сказал
                 "перекинь на Сашу". Sprint Goal не упоминался.
                 После дейли двое остались обсуждать интеграцию 15 мин».

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

Индивидуальные разговоры

За первые две-три недели поговорите один на один со всеми: с каждым разработчиком, с PO, с тимлидом, с руководителем, с 1–2 ключевыми стейкхолдерами. 30–45 минут, без записи в общий канал, без обещаний.

Работающий каркас разговора — пять вопросов:

1. Расскажи, как у вас устроена работа. Что происходит с задачей от идеи до прода?
2. Что в этой работе тебя больше всего раздражает? Что бы ты убрал первым?
3. Что здесь хорошо и что ни в коем случае нельзя ломать?
4. Что пытались менять раньше и чем это кончилось?
5. Чего ты ждёшь от меня? Чего боишься, что я начну делать?

Четвёртый вопрос — самый ценный и его почти никто не задаёт. Ответ «два года назад пробовали story points, всё скатилось в спор с менеджментом» экономит вам месяц и предупреждает: этот рычаг сейчас заминирован.

Пятый вопрос обезоруживает. Люди почти всегда честно говорят «боюсь, что ты начнёшь заставлять нас говорить по шаблону на дейли» — и вы получаете список того, чего делать не надо.

Так делать не стоит: превращать эти разговоры в допрос про Scrum. Не «почему у вас нет Definition of Done», а «как вы понимаете, что задача готова?». Первый вопрос обвиняет и получает оборону; второй описывает реальность и часто сам приводит человека к мысли, что общего понимания нет.

Что уже можно менять в первый месяц

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

• нет доступа к тестовому стенду, заявка висит три недели;
• релиз ждёт человека из соседнего отдела, и никто не знает, кого именно;
• в дейли ходит менеджер и задаёт вопросы про сроки;
• у команды нет прав на изменение конфигурации, каждое — тикет в поддержку.

Это идеальные первые задачи. Они дёшевы для команды (её вообще не трогают), они не про «правильный Scrum», и они дают ровно то, что нужно на старте: доказательство, что от вашего появления жизнь стала легче. Одно закрытое препятствие такого рода даёт больше кредита, чем три семинара про эмпиризм.

Ветка «учу» — про случаи вроде «спринт заканчивается, но инкремент не соответствует Definition of Done, и это никого не смущает». Здесь молчать нельзя даже в первый месяц: рушится прозрачность, то есть основание всего остального. Но и здесь ваш инструмент — объяснение последствий, а не приказ.

Первая ретроспектива

Скорее всего, вести её попросят вас — это ожидаемая часть роли (https://courses.digitable.life/post/scrum-master/07-facilitation/). Правила для первой:

• не приносите свою повестку («сегодня обсудим, почему у нас нет Sprint Goal»);
• используйте максимально нейтральный формат — например, «что помогало / что мешало / что попробуем»;
• дайте команде выбрать одно действие, а не десять;
• запишите это действие туда, где его видно, и на следующей ретро начните с вопроса, что с ним стало.

Последний пункт важнее всех остальных. Команды, где ретро выродились, почти всегда прошли через одно и то же: действия записывались и не выполнялись. Ваша первая ретроспектива ценна не темами, а тем, что после неё хоть что-то реально произошло.

Дни 31–60: одно изменение, доведённое до конца

К концу первого месяца у вас есть список из пятнадцати проблем. Соблазн — взяться за все. Это самая частая ошибка второго месяца, и она гарантирует нулевой результат: пятнадцать одновременных изменений невозможно ни довести, ни оценить (какое из них дало эффект?).

Возьмите одно.

Как выбрать

Два измерения: насколько это болит самой команде и насколько это в зоне вашего влияния.

Правый верхний квадрант — ваш старт. Если команда сама говорит «нас бесит, что задачи неделями висят в „почти готово“», а причина — размытый Definition of Done, то у вас есть и мотивация, и рычаг. Это, кстати, самый частый удачный первый выбор: DoD чинится внутри команды, не требует ничьих согласований и почти сразу меняет разговор на планировании (https://courses.digitable.life/post/scrum-master/05-artifacts/).

Второй по частоте удачный выбор — Sprint Goal. Он бесплатный, не требует разрешений и мгновенно превращает планирование из «набираем задач на 40 очков» в «что мы хотим доказать за этот спринт».

Так делать не стоит в качестве первого изменения:

• менять инструмент (переезд из Jira куда угодно) — огромная стоимость, нулевой эффект на способ мышления;
• менять длину спринта — вы ещё не знаете, почему она такая;
• реорганизовывать команды — это не ваше решение и оно необратимо;
• вводить «настоящие story points» вместо часов, если по этому уже была война (см. четвёртый вопрос из интервью);
• одновременно требовать DoD, Sprint Goal, уточнение бэклога и отмену статусных отчётов.

Формат изменения: эксперимент, а не реформа

Слово «эксперимент» здесь не украшение. Оно снижает сопротивление на порядок, потому что превращает необратимое решение в обратимое.

Рабочий шаблон, который стоит проговорить на ретроспективе вслух и записать:

Эксперимент:  два спринта пишем Sprint Goal на планировании
              и начинаем дейли с его чтения.
Гипотеза:     сейчас в спринт набирается 4–6 несвязанных тем,
              и при срыве одной команда не понимает, что важнее.
Проверим по:  доля спринтов, где команда может назвать,
              что именно она доказала; субъективная оценка
              фокуса на ретро (1–5) в начале и в конце.
Откатим,      если через два спринта команда скажет, что цель
если:         формальная и ни на что не влияет.
Кто отвечает: команда; я фасилитирую и напоминаю.

Четыре элемента — гипотеза, критерий, срок, условие отката — делают из вашего мнения проверяемое утверждение. Это ровно тот же эмпирический цикл, что и в самом Scrum, просто применённый к процессу работы команды.

Замер до, а не после

Если вы хотите на 90-й день сказать что-то осмысленное, снимите базовые показатели до изменения. Не ради отчёта — ради того, чтобы отличить эффект от ощущения.

Что имеет смысл замерить в первый месяц (подробнее — в https://courses.digitable.life/post/scrum-master/09-empiricism-and-metrics/ и в статье о DORA-метриках соседнего трека, https://courses.digitable.life/post/project-management/07-dora-and-engineering-metrics/):

Так делать не стоит: начинать с velocity и делать её первой публичной цифрой. Как только скорость становится показателем успеха Scrum-мастера, она перестаёт быть инструментом планирования команды — механика этого вырождения разобрана в статье про метрики.

Дни 61–90: работа с системой вокруг команды

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

Типичные препятствия этого уровня:

• Product Owner формально есть, но решения о приоритетах принимает комитет, и ответ на вопрос ждут неделю;
• команда организована по компонентам, поэтому любая ценность требует трёх команд (https://courses.digitable.life/post/scrum-master/11-scaling/);
• сверху спущен годовой план с фиксированным объёмом и датой — то есть от команды ждут предсказуемости водопада при неопределённости продукта;
• в спринт постоянно влетают срочные задачи от отдельных руководителей;
• «сделано» у команды и «сделано» у бизнеса означают разное, потому что релиз отдельным процессом раз в месяц.

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

Перевод — ключевой навык. Сравните:

Язык фреймворка (не работает):
  «У нас неправильный Product Owner, по Scrum Guide PO должен
   быть одним человеком с полномочиями».

Язык последствий (работает):
  «За последние 6 спринтов 11 задач ждали решения о приоритете
   в среднем 6 рабочих дней. Это примерно один спринт из шести,
   потраченный на ожидание. Если решение будет принимать один
   человек, мы вернём этот спринт в квартал».

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

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

Четыре реальных сценария и разбор

Сценарий 1. «Мы уже делаем Scrum»

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

Что ломается. Это мини-водопад внутри спринта: инкремента, соответствующего Definition of Done, нет ни в один момент времени, поэтому инспектировать на обзоре нечего, и обратная связь не влияет ни на что. Эмпиризм отсутствует при полном комплекте ритуалов.

Чего не делать. Объявлять на общей встрече, что это не Scrum. Вы будете формально правы и практически мертвы: вы обесценили шесть лет работы людей одной фразой.

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

Чего ждать. Первые два спринта станет хуже: люди будут простаивать, потому что привыкли параллелить. Это нормальная фаза, и её стоит предупредить заранее, иначе откат гарантирован.

Сценарий 2. Тимлид раздаёт задачи, и всех это устраивает

Формально команда самоуправляемая, фактически Игорь каждое утро распределяет работу. Разработчики довольны: думать не надо. PO доволен: есть с кого спросить. Игорь устал, но считает, что иначе развалится.

Что ломается. Самоуправление — не идеологическое требование, а механизм скорости: когда решения принимает один человек, он становится узким местом, и знание концентрируется в нём же. Плюс исчезает совместная ответственность за Sprint Goal: у каждого своя задача, общей цели нет.

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

Что делать. Начать с самого Игоря: почти всегда он выгорает и рад разгрузке, если предложить это как облегчение, а не как лишение власти. Дальше — маленькие обратимые шаги: планирование, где задачи разбирают сами (Игорь молчит первые десять минут); дейли, где команда сама решает, кто что берёт сегодня. Успех измеряется не тем, что Игорь замолчал, а тем, что при его отпуске команда не встала.

Сценарий 3. «Нам нужно, чтобы вы подняли скорость»

Руководитель на второй неделе прямо формулирует задачу: velocity должна вырасти на 30% к концу квартала.

Что ломается. Требование неисполнимо честно, но исполнимо нечестно — достаточно раздуть оценки. Приняв его, вы гарантированно приходите к системе, где цифры растут, а поставка нет, и заодно уничтожаете доверие команды: она мгновенно поймёт, зачем вы пришли.

Чего не делать. Ни соглашаться, ни устраивать лекцию о том, что velocity — не метрика производительности. Оба варианта заканчивают разговор.

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

Сценарий 4. Вы — второй Scrum-мастер, первый ушёл со скандалом

Команда встречает вежливо и глухо. На вопросы отвечает односложно. На ретроспективе — «всё нормально».

Что ломается. Ничего, кроме доверия к роли. Это не ваша проблема, но платить по счетам вам.

Что делать. Первое: спросить прямо и без защиты — «я знаю, что до меня был Scrum-мастер и что закончилось это плохо. Расскажите, что тогда произошло, чтобы я не повторил». Второе: не обещать ничего в первый месяц вообще. Третье: выбрать первым действием исключительно внешнее препятствие — то, что не требует от команды меняться. Молчаливой команде нужен не разговор о ценностях, а доказательство, что вы полезны и безопасны. Работа с сопротивлением подробно разобрана в https://courses.digitable.life/post/scrum-master/08-coaching-and-conflicts/.

Чек-лист 90-го дня

Не «что вы внедрили», а что стало правдой. Честно отметьте, что из этого выполняется.

Про команду

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

Про процесс

• У команды есть письменный Definition of Done, и на планировании на него ссылаются.
• У спринта есть цель, и она формулируется командой, а не мной.
• Обзор спринта — это разговор о том, что делать дальше, а не показ слайдов.
• Я провёл ровно один-два изменения и довёл их до измеримого результата, а не пятнадцать до половины.

Про организацию

• Я снял минимум одно внешнее препятствие, которое команда считала неустранимым.
• У меня есть цифры, а не мнения, по двум-трём ключевым проблемам.
• С руководителем проговорены ожидания на следующие полгода в конкретных формулировках.

Про себя

• Я не стал секретарём Jira и человеком, который собирает статусы.
• Я знаю, какое препятствие возьму следующим и почему именно его.

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

Когда честный ответ — уходить

Редкая, но реальная ситуация: организация наняла Scrum-мастера, чтобы иметь Scrum-мастера, и не собирается ничего менять. Признаки, накопленные к 90-му дню:

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

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

Вопросы в формате PSM I

Экзамен не спрашивает про онбординг напрямую, зато проверяет ровно ту логику, которой вы пользуетесь каждый день первых месяцев: где заканчиваются полномочия Scrum-мастера и начинается ответственность команды. Формат PSM I — 80 вопросов, 60 минут, проходной балл 85% (scrum.org); подробный разбор — в https://courses.digitable.life/post/scrum-master/12-psm-exam/.

Вопрос 1. Scrum-мастер приходит в новую команду и видит, что Daily Scrum длится 35 минут и проходит как доклад каждого разработчика тимлиду. Что должен сделать Scrum-мастер?

• A. Взять ведение Daily Scrum на себя и жёстко следить за таймбоксом.
• B. Отменить Daily Scrum, пока команда не научится его проводить.
• C. Помочь Developers понять назначение события и оставить проведение им.
• D. Сообщить руководителю, что команда не соблюдает Scrum.

Правильный ответ: C. Scrum Guide прямо говорит, что Daily Scrum — событие Developers для инспекции прогресса к Sprint Goal и планирования дня, и что если на нём присутствуют другие, Developers всё равно проводят его сами. Роль Scrum-мастера — учить команду держать событие в пределах таймбокса и понимать его смысл. Вариант A — самая частая ошибка новичка: вы решаете симптом, забирая событие себе, и превращаете доклад тимлиду в доклад Scrum-мастеру, то есть ничего не меняете по существу. B нарушает Scrum (события обязательны и отменять их нельзя). D — эскалация вместо работы, и вдобавок она разрушает доверие с первого месяца.

Вопрос 2. В новой команде нет письменного Definition of Done. В организации стандарта тоже нет. Кто должен его создать?

• A. Scrum-мастер, как ответственный за результативность.
• B. Product Owner, поскольку он отвечает за ценность.
• C. Scrum-команда.
• D. Отдел качества.

Правильный ответ: C. Формулировка Scrum Guide 2020 буквальна: если Definition of Done не является стандартом организации, его должна создать Scrum-команда (Scrum Team). Это осознанная ловушка: редакция 2017 года относила DoD к Development Team, и многие материалы до сих пор повторяют старую формулировку. На экзамене нужна текущая. Практический вывод для первых 90 дней: вы можете быть инициатором и фасилитатором сессии по DoD, но авторство и содержание — за командой, иначе документ не будет исполняться.

Вопрос 3. Руководитель просит Scrum-мастера ежемесячно присылать отчёт о продуктивности каждого разработчика. Как поступить?

• A. Присылать отчёт: руководитель имеет право на информацию.
• B. Отказаться, сославшись на то, что в Scrum нет такой практики.
• C. Понять потребность за запросом и помочь удовлетворить её через прозрачность работы, а не оценку людей.
• D. Передать запрос Product Owner.

Правильный ответ: C. Scrum-мастер служит организации, помогая ей понять эмпирический подход; здесь это означает выяснить настоящую потребность (скорее всего — предсказуемость или обоснование инвестиций) и предложить прозрачность через артефакты и реальный инкремент. A разрушает самоуправление и психологическую безопасность: индивидуальные метрики немедленно меняют поведение людей. B формально ближе к истине, чем A, но это отказ без альтернативы — он оставляет потребность руководителя неудовлетворённой и превращает вас в препятствие. Отличать «не по Scrum» от «вот как решить вашу задачу» — главный навык третьего месяца.

Вопрос 4. Scrum-мастер приходит в команду из 14 разработчиков. Что уместно сделать?

• A. Немедленно разделить команду на две.
• B. Ничего: Scrum Guide не ограничивает размер команды.
• C. Помочь Scrum-команде увидеть влияние размера на коммуникацию и рассмотреть реорганизацию в несколько команд с общим Product Backlog.
• D. Попросить Product Owner сократить состав.

Правильный ответ: C. Scrum Guide указывает, что Scrum-команда обычно состоит из 10 или менее человек, а если она становится слишком большой — следует рассмотреть реорганизацию в несколько сплочённых Scrum-команд, работающих с одним продуктом, одной целью продукта и одним Product Backlog. Обратите внимание на модальность: «следует рассмотреть», а не «обязан разделить». Scrum-мастер не реорганизует команды приказом (A) и не игнорирует проблему (B). D перекладывает не ту ответственность не на того человека.

Вопрос 5. Через месяц работы Scrum-мастер уверен, что команде нужен другой формат ретроспективы. Команда против. Что делать?

• A. Ввести новый формат: Scrum-мастер отвечает за результативность команды.
• B. Оставить как есть навсегда.
• C. Предложить попробовать один раз как эксперимент и вместе оценить результат.
• D. Провести голосование и подчиниться большинству.

Правильный ответ: C. Ответственность Scrum-мастера за результативность реализуется через обучение, фасилитацию и коучинг, а не через директиву: команда самоуправляема и сама решает, как выполняет работу. Формат эксперимента с явной оценкой сохраняет и авторство команды, и вашу возможность влиять. A — подмена лидерства через служение администрированием. B — отказ от роли. D выглядит демократично, но голосование по вопросу, который не обсуждён по существу, лишь фиксирует текущее мнение и не создаёт понимания.

Мини-итог

Первые 90 дней Scrum-мастера — это не программа внедрения фреймворка, а последовательность из трёх разных задач:

1. Дни 1–30 — понять систему. Наблюдать, разговаривать, записывать факты, снимать внешние препятствия. Не чинить внутреннее.
2. Дни 31–60 — довести одно изменение. Выбрать пересечение боли команды и своего влияния, оформить как эксперимент с гипотезой, критерием и условием отката, замерить до и после.
3. Дни 61–90 — выйти на уровень организации. Перевести накопленные факты на язык последствий для бизнеса и договориться об ожиданиях на следующие полгода.

Сквозное правило одно: объём изменений не должен обгонять кредит доверия. Всё остальное — техника, которой вы научились в предыдущих статьях курса. Scrum Guide помещается на четырнадцати страницах; сложность не в нём, а в людях, которые уже шесть лет работают иначе и имеют на это причины.

Источники

• The Scrum Guide (2020) — первоисточник, единственный канон для PSM I.
• Michael Watkins. The First 90 Days — обзор в HBR; откуда вообще взялась рамка 90 дней.
• Geoff Watts. Scrum Mastery: From Good to Great Servant-Leadership — про переход от администрирования к настоящему влиянию.
• Christiaan Verwijs, Johannes Schartau, Barry Overeem. Zombie Scrum Survival Guide и блог The Liberators — диагностика мёртвого Scrum и эксперименты по оживлению.
• Lyssa Adkins. Coaching Agile Teams — модели разговора и работы с командой.
• Scrum.org Resources и PSM I assessment — официальные материалы и формат экзамена.
• Evidence-Based Management Guide — как измерять ценность, а не активность.

Что дальше

Это последняя статья трека. Вы прошли путь от Agile-манифеста (https://courses.digitable.life/post/scrum-master/01-agile-values/) через Scrum Guide построчно (https://courses.digitable.life/post/scrum-master/02-scrum-guide/), ответственности, события и артефакты — до фасилитации, коучинга, метрик и подготовки к экзамену (https://courses.digitable.life/post/scrum-master/12-psm-exam/). Если что-то из чек-листа 90-го дня даётся тяжело, возвращайтесь к соответствующей статье: курс задуман как справочник, а не как чтение в один проход.

Куда двигаться дальше:

• Шире по управлению проектами — https://courses.digitable.life/post/project-management/00-overview/: Kanban и поток, оценка, риски, качество, DORA-метрики и фреймворки масштабирования. Хорошо дополняет трек там, где Scrum намеренно молчит.
• В сторону продукта — https://courses.digitable.life/post/product-management/00-overview/: discovery, приоритизация, метрики, эксперименты. Это язык, на котором говорит ваш Product Owner; понимать его — половина работы с бэклогом (https://courses.digitable.life/post/scrum-master/06-product-backlog/).
• В сторону инженерных практик — https://courses.digitable.life/post/devops/00-overview/ и https://courses.digitable.life/post/testing/00-overview/: без CI, автотестов и коротких релизных циклов Definition of Done упирается в потолок, который никакой фасилитацией не пробить.
• Общая карта портала — https://courses.digitable.life/post/roadmap/: как связаны треки и в каком порядке их проходить, если хочется расти не только вширь.

Удачи в понедельник. Первые тридцать дней — слушайте.