Что такое scrum мастер
Разбор полётов. Уроки и выводы начинающего Scrum-мастера
Источник фото
Уже третий год я внедряю ценности и принципы Agile в жизни команд разработчиков. За плечами – работа Scrum-мастером в двух крупных компаниях, опыт удаленного внедрения гибких методологий в совершенно разных отраслях, бесчисленное количество прочитанных книг и посещенных митапов.
Но начиналось всё с малого, и за это время я набила не одну шишку. А со временем стала замечать, что шишки эти были довольно типовыми, и коллеги-новички сталкиваются с ними на регулярной основе. Не желая оставаться в стороне, и дабы предостеречь коллег от возможных неудач, решила поделиться своим опытом в этой статье.
Итак, какие уроки я извлекла и выводы сделала в первый год работы в роли Scrum-мастера (о которых кратко пунктами изложила в самом конце):
Розовые очки
После двухдневного тренинга по Scrum я была готова сворачивать горы, изменять мир на пути компании к лучшему. Ничто так не вдохновляет, как грамотный коуч и команда единомышленников! Но стоит только начать, как вдруг ты остаёшься один на один со своим фреймворком Scrum. Есть ребята, загруженные собственными задачами, есть привычки и ценности, которые уже сложились в работе команды, есть менеджмент, который по-своему видит процессы, и это не всегда идёт параллельно с ценностями и представлениями Agile. В общем, добро пожаловать в реальный мир.
А потому еще в начале предстоит заслужить доверие и открытость команды. Важно опираться на свой предыдущий опыт и здравый смысл. Поймите, в чём действительно сейчас нуждается ваша команда, какие проблемы и недосказанности существуют и как вы можете им помочь, чтобы закрыть хотя бы часть возникающих вопросов.
Сопротивление
Безусловно, нововведениям и очевидным грядущим изменениям не очень обрадовались. В моем случае скорее это было смирение с тем, что пришёл ещё кто-то, чтобы управлять и учить: «ну ведь и так всё хорошо». Делать нечего – пришлось доказывать, что я пришла помогать, и на практике это демонстрировать.
Важный момент: если в самом начале вы не найдёте в команде разработчиков сторонников, рискуете быть отвергнутыми.
Первое, с чем сталкивается новоиспечённый Scrum-мастер при попытке изменения, – это сопротивление. Процесс, конечно, естественный, но не безболезненный. Люди готовы меняться только тогда, когда видят в этом ценность для себя. Поэтому самый выигрышный вариант – дать возможность команде самой прийти к мысли, что Scrum улучшит и их процессы, и жизнь.
Задайте себе вопрос: «какова цель моего присутствия в этой роли и как я могу помочь своей команде улучшить существующие процессы работы?». Если ответ нашёлся – отлично, вперёд к изменениям! Если нет, то стоит понаблюдать ещё.
Говоря об улучшении – можно провести серию встреч, направленных на выявление болей команды и формирование открытости, к примеру. Но об этом я хочу поговорить в следующих статьях.
Спешка – худший помощник
Спешка и желание показать себя с первых дней работы – наверное, самая большая ошибка начинающего Scrum-мастера. Жизненно важно знать, что резкие изменения без понимания, зачем это нужно и как повлияет на сложившийся уклад жизни команды, может вызвать ещё большее сопротивление и недоверие. Бывали случаи, когда Scrum-мастер вредил командам именно вследствие непродуманных и непроработанных изменений.
Готовность к изменениям наступает у команды постепенно. Понаблюдайте за командой в течение 1-2 недель, не вмешиваясь в «естественный» ход вещей. На первых этапах необходимо понять для себя логическую цепочку процессов и сложившихся ценностей, увидеть уязвимые места в работе и, собственно, предложить решение. Шаг за шагом пытайтесь внедрять события и ценности методологии в сознание и жизнедеятельность своей команды.
В этом вам поможет фасилитация встреч, частое взаимодействие с командой, как личное, так и в формате событий, коучинг. И, конечно, доверие и открытость к диалогу.
Понимание среды
Когда я лишь начинала работу с командой, допустила большую оплошность, которая поначалу не бросалась в глаза и казалась пустяком. А именно – упускала из виду множество тематических чатов разработчиков, которые раскрывали их с другой стороны. Дистанцировалась от руководства и пропускала важную информацию, которую можно было бы, в свою очередь, донести до команды.
Не повторяйте мою ошибку: не важно, маленькая у вас компания или большая, но понимать коммуникацию между отделами и знать лично пару ключевых коллег нужно. Говорят, что Scrum-мастер должен устранять препятствия, отвлекающие команду от создания ИТ-продукта. Но как это сделать, если вы не будете знать, к кому обратиться?
Итак, в самом начале особенно важно:
Присутствие стратегии
И вот мы поговорили с командой и руководством, задали интересующие вопросы, получили на них ответы, зашли во все чаты и получили приглашения на все мероприятия. Мы видим проблему, знаем цели менеджмента – но с чего начать, чтобы её решить, пока не понятно. Что делать дальше?
Для того, чтобы прийти к решению, важно сформулировать чёткие цели того, что именно и почему мы хотим изменить. А после – составить план работ, отвечающий на вопрос, «как мы это будем делать?».
Чаще всего, приходя в команду, я видела, как ребята проводят ежедневные совещания по 1,5-2 часа, на которых пытаются проработать все вопросы. А это, между прочим, – колоссальное количество времени, которое вычитается из рабочих часов и снижает эффективность работ команд. Да и Scrum Guide предполагает на это событие только 15 минут и ни минутой больше.
Как быть: самым правильным подходом, на мой взгляд, является разделение таких активностей и фокусировка на поставленных задачах в рамках целей Sprint.
Отталкиваясь от болей и наиболее частых вопросов, помимо основных событий Scrum (планирование, daily, demo, retro) может формироваться, например, еженедельная исследовательская встреча, обсуждение бэклога идей или же мозговые штурмы для обсуждения углубленных вопросов, как происходит сегодня у нас в ICL Services. Мы видим боль, знаем, как исправить ситуацию и что нужно сделать – остаётся лишь обсудить изменение формата работ с менеджментом и командой для достижения наилучшего эффекта.
План тоже должен быть гибким и изменяться в зависимости от условий и особенностей членов команды. Немаловажно обсудить намеченный путь с руководством, ведь не всегда всё предложенное вами будет немедленно внедрено в работу. А что-то и вовсе может видоизмениться в зависимости от целеполагания и запросов самого руководства.
Нехватка технических знаний
Технического образования у меня нет, а потому досконально разобраться в обширной терминологии команды разработчиков для меня было (и местами остаётся) довольно сложной задачей, учитывая, что технологии не стоят на месте.
Но и здесь есть довольно простые лайфхаки:
Кто эти люди? Зачем я им нужна? и другие проблемы скрам-мастера
Что чувствует скрам-мастер, который знает о скраме только из гайда? Как он пытается помочь команде не развалить и улучшить существующие процессы? Статья о трудностях, с которыми я столкнулась в начале своего пути самурая.
Команда, в которую я пришла как QA-инженер, была уже сформирована: стандартные процессы построены, атмосфера в коллективе — дружелюбная и спокойная. Через год моей работы встал вопрос о том, кто заменит скрам-мастера, который перешел в другую команду. Мне захотелось попробовать. Опыта в управлении и построении процессов не было, но почва для старта доброжелательная. Почему бы и нет?
Сложности
Через неделю эйфории (еее, новая ачивка!) на голову свалилась тысяча и одна проблема (мама, помоги!). Большая часть из них — личные, банальные или решаются прохождением пары тренингов. Я хочу поделиться четырьмя основными сложностями, с которыми может столкнуться начинающий скрам-мастер.
Отсутствие авторитета
Несмотря на то, что я работала в команде год, роль скрам-мастера была для меня новой. Для построения новых процессов авторитет — одна из важных составляющих. Когда пытаешься изменить привычные практики, основываясь только на теоретических знаниях, скептического отношения со стороны команды избежать сложно. Даже введение одной из самых распространенных практик — скрам-покера — было для меня проблематичным.
Тень бывшего мастера
От сравнений никуда не деться. Если до моего появления что-то работало плохо, и после моего прихода ничего не изменилось, возникали запросы: «У нас слишком сложный планнинг, давай сделаем уже что-нибудь с ним!». В случае, когда что-то было удобно для команды, например, физическая доска на дейли, а после появилась я и сказала: «Мне неудобно, давайте менять!», команда не понимала, зачем это необходимо.
Другая сложность связана с коммуникацией. Предыдущий скрам-мастер довольно остро воспринимал отзывы о своей работе, а мне было важно получать обратную связь. В итоге, первый полезный фидбек удалось собрать только через пару месяцев — помогли упорство и разговоры с глазу на глаз. На личных встречах некоторые ребята рассказали, что им было некомфортно критиковать мою работу: предыдущий опыт говорил о том, что задеть чувства скрам-мастера легко, и фидбек воспринимается как оскорбление.
Коммуникация с командой
Идеальный скрам-мастер наблюдает за настроением в команде, анализирует, как работают процессы, понимает, как команда реагирует на изменения. Как не перепутать безразличие к процессу со стороны команды с тем, что уже хорошо работает? Как собрать адекватный фидбек? Здесь мне явно не хватало практики. Особенно сильно эти вопросы беспокоили на ретроспективе, когда на общей встрече на обсуждение выносились незначительные проблемы или не выносились вовсе. Такое происходит, если команда хорошо провела спринт или если проблемы умалчиваются.
Синдром волонтера
В начале пути хочется выложиться на максимум, чтобы команда сразу осознала, какая я крутая и как много могу. Почему я должна делать меньше, если могу делать больше?
Способы решения
Универсального решения для всех трудностей быть не может. Ниже перечислю шаблоны поведения, которые мне когда-то помогли привыкнуть к новой роли.
Решать проблемы поэтапно
Роль скрам-мастера я совмещала с должностью QA-инженера и физически не могла позволить себе заниматься только улучшением процессов в команде. Я пыталась найти баланс и, как следствие, избежала серьезных проблем от изменения всего и вся в команде. Поэтапное решение помогало не только не закопаться в изменениях ради изменений, но и отслеживать, как какое-то конкретное нововведение повлияло на проблему, которая решалась изначально.
Я хотела изменить несколько вещей в работе команды. Одной из них была физическая доска для дейли. Мне было лень заниматься её оформлением из спринта в спринт. Ситуация усложнялась тем, что эта проблема не затрагивала всю команду. Другая проблема с доской — это реактивное обновление статусов задач. Так как команда находилась в одном кабинете, узнать прогресс по задаче было достаточно легко — спросить коллегу или посмотреть на доску. Трудности в тот момент это не вызывало, но могло поломать процессы в случае продолжительной удаленной работы кого-нибудь из коллег или появления удаленного сотрудника.
Решением первой проблемы было делегирование оформления доски или переход на какой-нибудь электронный инструмент. Второй — развитие культуры поддержания порядка. Кстати, аргумент «когда-нибудь нам это, может быть, поможет» недостаточно мотивирует команду на изменения.
Аргументировать любое изменение
Не нужно бросаться с места в карьер с криком: «Сейчас всё будет!». В самом начале пути скрам-мастерства есть вероятность наворотить процессы ради процессов, это может ухудшить карму. Сначала стоит понять, зачем, а потом транслировать идею команде.
В ситуации с отказом от физической доски, я проговорила команде, что мне сложно заниматься оформлением, а если альтернативного варианта для доски не найдется, то я попрошу команду разделить со мной обязанности по разрезанию и развешиванию стикеров.
Изучить поведение авторитета
Видите, что кто-то в команде удачно рассказывает о своих идеях? К мнению лидера прислушиваются? Можно понаблюдать за тем, как этот человек доносит информацию, скорее всего, он с командой на одной волне. Важно так же настроиться на эту волну.
Душой нашей команды был менеджер продукта. Важность и необходимость фичей, над которыми он предлагал работать, команда разделяла. И дело не только в том, что это были очевидно необходимые и важные изменения. Менеджер аргументировал предложение, освещал плюсы, вносил ясность — это помогало осознать и принять новую задачу.
Найти единомышленников
Одна голова хорошо, а имей сто друзей. Коллективный разум — это прекрасно, но не все вопросы можно выносить на командное обсуждение. Можете найти одного/двух неравнодушных коллег и советоваться с ними. Но разные члены команды обладают навыками в разных аспектах работы, поэтому лучше не держать фокус на паре советников. Расширяйте круг общения.
За новыми идеями по части процессов я обращалась к менеджеру продукта. Острые углы и проблемы мне помог найти инженер по тестированию. На выходе получалось приятное и провалидированное решение.
Необходимый для скрам-мастера опыт помогут получить книги, тренинги и практика. Но количество советов зашкаливает, и трудности вызывает даже приоритезация советов в порядке необходимости. Осознание сложностей — шаг в правильном направлении к поддержанию и построению процессов.
А что дальше?
Теперь, когда хаос упорядочен, можно подумать о работе над конкретными навыками и задачами.
Кто такой Scrum-мастер, и зачем он нужен команде
Есть два способа объяснить, кто такой Scrum-мастер. Первый — короткий, но сложный; второй — длинный, подробный и понятный.
Начнем с короткого. Scrum-мастер — это специальная роль во фреймворке Scrum. Цель Scrum-мастера состоит в том, чтобы научить Scrum-команду работать по Scrum, помочь ей улучшать методы своей работы и привести ее к самоуправлению и высокой эффективности. При этом у Scrum-мастера нет властных полномочий, он не может раздавать задания, не может принимать решения за команду или отдельных ее участников.
Если вам все понятно, то поздравляю вас. Можно дальше не читать. Спасибо, что уделили время, и можно переходить к чтиву посложнее:
Уровни зрелости Scrum-мастера: от проповедника механического Скрама до агента изменений во всей компании.
Обычно короткий ответ ничего не объясняет: в частности, неясно, за счет чего самоуправляемая команда со скрам-мастером эффективнее классической команды во главе с руководителем и/или тим-лидом. В коротком ответе слишком много абстрактных терминов.
В этой статье я опишу конкретные обязанности скрам-мастера, не заваливая вас десятками специфических терминов Scrum — таких как инспекция, адаптация, кросс-функциональность, инкремент, бэклог и даже владелец продукта. Разъяснения всех 40+ терминов вы найдете в глоссарии Scrum, однако это скорее для тех, кто хочет понять формулировки официального Руководства по Скраму. А эта статья имеет другую цель: максимально простыми словами объяснить вам смысл роли скрам-мастера и его обязанности по отношению к скрам-команде.
На конкретном примере я покажу, почему скрам-мастер необходим и как он делает эффективной работу команды, состоящей из творческих людей и решающей комплексную проблему.
Именно для решения таких нетривиальных проблем и предназначен Scrum. Если же люди выполняют повторяющиеся предсказуемые задачи (пусть сложные, но похожие друг на друга проекты с четкими и слабо меняющимися требованиями) — тогда применение Scrum приведет лишь к неоправданным расходам, а вместо скрам-мастера нужен классический менеджер.
Пример комплексной проблемы
Давайте представим себе ситуацию: вы литературный менеджер. У вас есть несколько писателей. И заказчик поставил вам задачу — написать роман. Да не просто роман, а такой, какого еще не было! И чтобы обязательно продавался лучше всех. И выпускать этот роман надо по частям, что позволит подогревать интерес к книге. Так многие делали в начале XX века. Конан Дойл печатал свои произведения про Шерлока Холмса таким образом.
Основные требования от заказчика:
Итак, у вас есть группа семи эрудированных, опытных, жаждущих успеха писателей.
Ваша задача: организовать их работу так, чтобы они вместе придумали сюжет книги, главных героев, основные повороты сюжета, договориться как именно они будут писать книгу (по очереди главу, или коллективно или как-то еще), как будут обеспечивать логическую стройность повествования, и цельность сюжета, как будут вычитывать, править и так далее и так далее, пока книга не будет написана.
Каждый из писателей этот роман может сам написать. Но условие, что каждую неделю должно выходить по главе, задает слишком жесткий темп, который не всякий писатель выдержит…
Чтобы участники группы помогали друг другу, нужна общая, вдохновляющая цель. Например — попасть в книгу рекордов Гиннесса с книгой, написанной наибольшим коллективом авторов, или выиграть премию «Русский букер», или еще что-то подобное.
Вы, как менеджер в этом коллективе, в писательском ремесле не разбираетесь. Ваша задача — сделать так, чтобы эти семь человек выдавали результат каждую неделю, и делали это талантливо и качественно.
При этом заказчик не сказал ни тему романа, ни кто главный герой, ни основные завязки сюжета. Ни-Че-Го. Классика, в общем. Главное — чтобы денег заработать, и чтобы книга долго приносила доход.
Что делать? Управлять написанием книги в ручном режиме вы не можете — квалификация не позволяет. Поручить написание книги одному из семи писателей — велики риски сорвать план по выпуску глав книги.
Остается один выход — как-то так организовать процесс, чтобы писатели в группе сами выбрали тему, опробовали ее на ограниченной аудитории, и дальше, помогая друг другу каждую неделю придумывали сюжет новой главы, писали ее, вычитывали на предмет ошибок и отправляли в литературную газету для публикации.
Важно, чтобы при этом они смогли договориться между собой и не поссориться. Идеально, чтобы они еще обучали друг друга и делились лучшими практиками.
Представили? Сложная проблема? А ведь именно с такой проблемой сталкивается большинство Scrum-команд:
Единственное, что упрощает решение такой проблемы — это наличие вдохновляющей общей цели. Но этого отнюдь недостаточно для того, чтобы творческие люди самоорганизовались и выполнили поставленную задачу в этих жестких условиях.
Для успешного выполнения таких задач нужен скрам-мастер, и ему нужно делать очень многое: развивать командную ответственность, поддерживать конструктивное общение, стимулировать постоянные улучшения процесса и результативности работы.
Посмотрим подробнее на эти обязанности скрам-мастера.
Развитие ответственности в команде
Как Scrum-мастеру нужно организовать работу, чтобы весь коллектив работал на одну цель, и чтобы все между собой общались?
В первую очередь, надо, чтобы команда постепенно начала осознавать свою коллективную ответственность за результат. В Scrum для этого есть набор встреч, целью которых является коллективное принятие решений и повышение командной ответственности.
Первая встреча, которая приучает к общей ответственности, — это Обзор спринта в конце итерации (итерации работы в Scrum называются спринтами и длятся 1-4 недели). На обзоре вся команда презентует заказчику результат. На этой встрече заказчик впервые увидит, что сделала команда за прошедшую итерацию, и даст обратную связь: что, по его мнению, стоит добавить, усилить или убрать в этой главе книги, а что стоит учесть при написании следующих глав.
Задача Scrum-мастера — это все организовать так, чтобы каждый участник команды принял участие в презентации, ответил на вопросы заказчика, и не затерялся среди коллег. Поначалу скрам-мастер это организует сам, но постепенно обучает команду планировать содержание встречи и управлять дискуссией по ходу встречи. Это еще больше развивает их командную ответственность.
Если писателей объединяет общая цель, и они совместно трудились на главой целую неделю, то им наверняка есть что рассказать на обзоре спринта. Как развивался сюжет, как менялись отношения главных героев, какие трудности были при написании, о чем вообще эта глава, и как она укладывается общее повествование и т.п.
Вторая встреча, которая способствует осознанию ответственности — Планирование спринта в начале итерации. Это встреча, предназначенная для коллективного разбора предстоящих задач и коллективной оценки этих задач.
Раз уж наши писатели создают целостную историю, и то им волей-неволей придется договариваться о том, как будут развиваться отношения персонажей, какие события их ждут, и каковы будут их реакции на эти события. Например, они могут решить, что каждый из них прорабатывает конкретного персонажа. Тогда на планировании им надо решить, какие основные события ждут всех персонажей. Как меняется внешняя среда, или какие возникают важные события, которые влияют на всех персонажей. На этой же встрече участники должны договориться о цели спринта — о главном достижении, которое должно быть достигнуто по итогам спринта.
Например, писатели могут решить, что целью ближайшего спринта будет описать, как главные герои выберутся из затруднительного положения, в которое они попали в прошлой главе. Дальше писатели могут накидать «канву» главы, чтобы были понятны основные сюжетные повороты, которые каждому из них надо учесть.
Чтобы не «промахнуться» в сроках, команде нужно оценить задуманное, чтобы убедиться, что они успеют все проработать, сделать и вычитать за неделю. Оценка может производиться экспертно или с помощью каких-то систем оценок, но в обязательном порядке с итоговой оценкой должны согласиться все участники. Это важно, поскольку результат общий, и на обзоре спринта отмолчаться не удастся — каждый должен будет рассказать о своем вкладе в общий результат.
Все это должно быть сделано на планировании спринта. А дальше каждый писатель, имея «канву» будущей главы, должен будет проработать своего персонажа в связке с другими персонажами.
Ежедневные встречи
После планирования спринта начинается сама итерация работы — спринт. В течении спринта участники команды реализуют то, о чем договорились. Чтобы результат в конце итерации получился согласованным, проводится 15-минутный Ежедневный Скрам. На этой встрече участники команды вкратце рассказывают, как идет работа над задачей, подсвечивают возникшие проблемы и договариваются о том, кому с кем в течении дня надо поговорить по возникшим проблемам, разногласиям и непоняткам.
Легко представить себе, как наш коллектив писателей встречается утром за чашкой кофе, и каждый рассказывает, что он придумал о своем персонаже, какие сюжетные коллизии и проблемы возникли в процессе проработки персонажа главы, какие у него возникли сомнения или вопросы к остальным участникам. По итогам станет ясно, что нескольким писателям надо встретиться позже, чтобы обсудить взаимоотношения своих персонажей в главе.
Таким образом достигается фокусировка на целях спринта и гарантируется согласованная работа.
Но причем здесь скрам-мастер? Если команда поняла и приняла смысл ежедневного скрама, то он почти не причем.
Скрам-мастер обязан лишь убедиться, что эта встреча проводится ежедневно, укладывается в 15 минут и достигает своих целей (синхронизация работ, выявление препятствий на пути к цели спринта и совместная корректировка планов на день).
Ежедневный скрам проще других встреч, и он обычно является первой встречей, которую люди обучаются проводить эффективно даже в отсутствие скрам-мастера. Если не отклоняться от целей ежедневного скрама, то за 15 минут сложно даже поссориться 😉
Фасилитация обсуждений и конфликтов
Вторая обязанность Scrum-мастера — научить участников, как им договориться между собой и не перессориться. Тут уже вступает в силу умение скрам-мастера фасилитировать встречи.
Фасилитировать — значит организовывать и проводить встречи таким образом, чтобы:
1) все участники свободно высказывались и полноценно вовлекались в обсуждение;
2) по итогам обсуждения было принято решение, с которым согласен каждый участник команды, и которое каждый принимает как свое.
Фасилитируя обсуждение, скрам-мастер не может навязывать свое видение команде, а лишь помогать участникам быть услышанными, и слышать других, и совместно выбирать, какой из предложенных вариантов будет наилучшим в данной ситуации. Подробнее о том, как скрам-мастер может сохранять нейтралитет, а не навязывать свое мнение, можно посмотреть в этом 2-минутном видео:
Кроме того, Scrum-мастер должен учить команду тому, как конструктивно говорить о разногласиях и решать их. Конструктивный конфликт — то есть разность мнений — это хорошо для развития команды. Но чтобы это стало возможным, нужно научиться переводить разговор в конструктивную плоскость.
Ретроспектива и постоянные улучшения
Третья обязанность скрам-мастера — самая трудная, но очень важная. Она имеет непосредственное отношение к его основной цели:
Scrum-мастер отвечает за эффективность Scrum-команды. Он делает это, помогая Scrum-команде улучшать свои методы работы.
Руководство по Scrum 2020
Scrum-мастер отвечает за эффективность Scrum-команды. Он делает это, помогая Scrum-команде улучшать свои методы работы. Чтобы команда повышала свою эффективность (т.е. качество и/или скорость работы), необходимо регулярно анализировать прошедшие спринты, выявлять проблемы, избавляться от неудачных элементов рабочего процесса и, наоборот, закреплять хорошие практики.
Как правило, люди не привыкли тратить время даже на выявление проблем своей работы. В команде людям трудно договориться между собой: что хорошо, что плохо и что не важно, какие препятствия стоит устранять и какие лучшие практики стоит распространять на всю команду. А еще труднее потом выполнять эти договоренности. Это самые сложные моменты в работе Scrum-мастера, требующие длительного времени и большого опыта.
Помогает скрам-мастеру в этом встреча под названием «Ретроспектива». Она завершает собой каждый спринт в скрам-команде.
Цель ретроспективы — совместное обсуждение и анализ всего того, что произошло за спринт. Нужно честно рассказать друг другу о том, какие были трудности и какие успехи. И совместно — это важно — договориться о том, как участники команды вместе будут справляться с этими трудностями и как усиливать то, что способствует успеху.
Например, наши писатели могут собраться на ретроспективу, и Scrum-мастер задаст им вопрос: «Что вам помогало сделать вашу работу хорошо в этом спринте?». Один писатель ответит, что ему помог коллега, который вовремя подкинул идею. Другой скажет, что стал носить с собой блокнот везде, и записывать любые мысли о том, как лучше написать главу, и это помогло ему ничего не забыть. Третий расскажет про «метод помидора» для управления временем. И так далее. Благодаря этому участники команды поделятся лучшими практиками, чему-то научатся друг у дружки, и порадуются своим успехам, что повысит их уверенность в себе и даст энергию.
Затем Scrum-мастер задаст вопрос «А что вам мешало делать свою работу хорошо в течении спринта?». И кто-то отметит, что не все поняли задумки сюжета, так как все торопились на планировании, и не все успели задать вопросы. А кто-то скажет, что потерял записи, и долго не мог их найти. Другой скажет, что ежедневные скрамы иногда затягиваются и отнимают много времени. И так далее: каждый найдет что-то, над чем надо поработать.
В завершение ретроспективы, скрам-мастер предложит проголосовать за те пункты «что мешало», которые кажутся участникам команды самыми важными и требующими обязательной проработки. После голосования выделятся топ-3 пункта, которые требуют решения в ближайших спринтах. Задача скрам-мастера — так организовать дальнейшее обсуждение этих пунктов, чтобы группа докопалась до реальной причины, придумала контрмеру, чтобы устранить эту причину, и чтобы кто-то обязательно взял на себя реализацию этой контрмеры.
Таким образом, по итогам ретроспективы у команды есть план улучшений. Создавая и выполняя этот план каждый спринт, команда непрерывно улучшает свою деятельность, наращивая скорость, эффективность и слаженность совместной работы.
Организация и проведение ретроспективы — прерогатива Scrum-мастера. От того, как она пройдет, какие решения будут приняты по итогам, и какие из этих решений будут реализованы к следующей ретроспективе, будет напрямую зависеть атмосфера в команде и эффективность команды.
Более того, от ретроспективы зависит, станет ли она полноценной командой или останется просто группой людей, которых судьба свела работать вместе. Полноценная команда отличается от рабочей группы тем, что ее участники дополняют друг друга ради общей цели. Там, где слаб один, силен другой. Если проводить ретроспективы правильно, то возникнет синергия, и результат команды будет значительно больше, чем сумма результатов каждого участника по отдельности. На практике это очень сложно, и без скрам-мастера почти невозможно достичь синергии и, как следствие, максимальной эффективности.
Обучение
Также Scrum-мастер должен обеспечить, чтобы каждый участник команды четко понимал смысл Scrum. Важно не просто механически делать то, что написано в Scrum Guide, а понимать, что стоит за встречами Scrum, как они связаны, что будет, если какую-то из встреч убрать или проигнорировать. Важно, чтобы скрам-команда понимала зоны ответственности всех, кто в нее входит, — скрам-мастера, владельца продукта и разработчиков. От слаженной работы всех этих людей зависит общий результат.
Задача Scrum-мастера — обеспечить, чтобы все это скрам-команда знала и понимала.
Заключение: обязанности скрам-мастера
Итак, скрам-мастер имеет много важных и непростых обязанностей по отношению к скрам-команде:
Кроме этих функций, у скрам-мастера есть и другие, связанные с его поддержкой для Владельца продукта и для организации в целом. Но скрам-мастер обычно фокусируется на эти функции лишь на следующих этапах — уже после того, как команда научилась правильно понимать смысл Scrum-встреч, добиваться все лучших результатов с точки зрения бизнеса, а также самостоятельно организовывать свою работу и договариваться друг с другом.
При реализации Scrum есть много нюансов, и большинство из них касаются именно работы скрам-мастера. Как говорится в Руководстве по Скраму, «Scrum прост для понимания, но сложен для овладения в совершенстве».
На онлайн-тренинге Скрам-мастер, краткий курс выживания я на конкретных примерах показываю, что важно учесть на старте, как фасилитировать Scrum-встречи и как все организовать максимально эффективно, чтобы команда слаженно делала свою работу.
А если вам понравились картинки Scrum-встреч из этой статьи, рекомендую скачать для своей команды плакат по Scrum Guide 2020, содержащий эти картинки и не только их: все понятия Scrum в одном месте!