Путь скрам-мастера Шохова Зузана

Я Зузи, ваш новый друг и наставник. Расслабьтесь и выслушайте все, что я собираюсь вам сказать. Вы можете доверять мне. Десять лет назад, когда в качестве разработчика я присоединилась к своей первой scrum-команде, мне самой не очень нравился этот, как мне тогда казалось, неудобный способ работы. Я была такой же «неподдающейся», как большинство моих нынешних клиентов, находящихся в начале своих agile-путешествий. Это было нечто новое и необычное. И как бы наши agile-коучи ни пытались его объяснить, я не понимала…

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

И тогда я поняла, как всем нам не хватает доходчивого объяснения роли scrum-мастера. И позже описала ее с помощью концепции #ScrumMasterWay, которой собираюсь поделиться с вами в этой книге и которая наконец дала scrum-мастерам ответ на их самый «больной» вопрос: «Что должен делать scrum-мастер после того, как команда стала самоорганизовывающейся?» После коучинга многих scrum-мастеров в компаниях и проведения курсов SCM (Certified Scrum Master – сертифицированный scrum-мастер) я могу с уверенностью сказать, что ответы типа «перейти в другую команду», «ничего не делать» или «всегда будет какая-то работа» не спасают. Scrum-мастера чувствуют себя растерянными, так же как и я когда-то.

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

Кому следует прочесть эту книгу

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

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

Обратите внимание, что книга не объясняет базовых правил и принципов Scrum, поскольку предполагается, что вы уже знакомы с Agile и Scrum и у вас есть опыт работы scrum-мастером.

Как читать эту книгу

Книга разделена на восемь глав, которые шаг за шагом формируют осознание и понимание роли выдающегося scrum-мастера.

В главе 1 «Роли и обязанности scrum-мастера» мы знакомимся с основными обязанностями scrum-мастера.

В главе 2 «Состояние модели сознания» я представляю модель, которая помогает scrum-мастерам решать, какой подход они будут применять для решения проблем в повседневных ситуациях.

Глава 3 «#ScrumMasterWay» знакомит с носящей это название концепцией, подчеркивающей сложность роли scrum-мастера, необходимость построения сообщества scrum-мастеров и создания на ее основе agile-организации.

В главе 4 «Метанавыки и компетенции» мы поговорим о том, что позволит вам стать выдающимся scrum-мастером.

Глава 5 «Построение команд» посвящена теории создания команды и практическим примерам из agile-среды.

Глава 6 «Осуществление изменений» обращена к теме реализации и динамике изменений.

В главе 7 «Инструменты scrum-мастера» вы найдете описание различных инструментов, которые сможете использовать в своей работе scrum-мастера.

Глава 8 «Я верю…» завершает повествование, как бы закругляя его.

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

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

Роль scrum-мастера – одна из самых недооцененных в Scrum и Agile. Большинство начинающих команд не видят особого смысла в том, чтобы scrum-мастер работал на полной ставке, и, дабы «занять его работой», пытаются совместить эту должность с позицией разработчика или тестировщика. Это одна из самых распространенных ошибок в понимании роли scrum-мастера, свойственная большинству начинающих групп. Объясняется это примерно так: «Мы понимаем, что члены команды должны производить программный продукт, упорно трудиться. Они должны развивать кросс-функциональность и помогать друг другу. Должны сотрудничать. Мы также высоко оцениваем роль Владельца продукта, потому что этот человек определяет общее видение и согласовывает требования с клиентами. А как насчет scrum-мастера? Что делает он?» В таких условиях scrum-мастер часто превращается просто в секретаря – довольно скучная позиция, не правда ли? Он заботится о карточках на scrum-доске, сам устраняет все препятствия и близок к тому, чтобы начать готовить кофе для команды, пока она сосредоточена исключительно на работе. Знакомая ситуация?

Тогда продолжайте читать, потому что все описанное выше даже приблизительно не определяет основной роли scrum-мастера и его предназначения…

Другое весьма распространенное ошибочное отношение к роли scrum-мастера связано с тем, что кто-то берет ее на себя просто потому, что компании необходимо перейти на Scrum, – обычно такое происходит в крупных корпорациях. Там рассуждают примерно так: «Нам нужен scrum-мастер, чтобы воплощать Scrum, верно? Но мы не можем использовать для этого хорошего разработчика или тестировщика, потому что они должны заниматься программированием/тестированием». И scrum-мастером в таких случаях нередко становится какой-нибудь малоспособный, тихий человек, назначение которого scrum-мастером стало возможным лишь потому, что он не слишком хорош как разработчик.

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

Помните

Scrum-мастер – это не секретарь.

Scrum-мастер – это не «дополнительные расходы», а человек, создающий высокопроизводительную команду.

Scrum-мастер – это эксперт по agile- и scrum-мышлению, искренне верящий в то, что Agile и Scrum – верный путь к успеху.

Самоорганизующаяся команда

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

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

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

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

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

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

Джон расстроен. Снова и снова повторяется одна и та же проблема. Наконец он обращается к команде: «Я не получил никаких данных из системы! У вас есть идеи, как это можно исправить?»

Реакция команды:

Фред: «Да, это печально».

Жан [задумчиво]: «Слава богу, что я не выбрал сегодня эту задачу».

Рон: «Когда я вчера это пробовал, все было прекрасно».

Джейн: «Мне прошлой ночью помогла перезагрузка моего ПК».

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

Джон расстроен. Снова и снова повторяется одна и та же проблема. Наконец он обращается к команде: «Я не получил никаких данных из системы! У вас есть идеи, как это можно исправить?»

Реакция команды:

Жан: «Я могу взглянуть на Git[1], чтобы увидеть, вносил ли кто-то какие-нибудь изменения».

Джейн: «Я могу попробовать зайти в систему со своего компьютера, чтобы проверить, есть ли у меня та же проблема. Тогда мы сможем вместе проанализировать, что происходит».

Рон: «Это слишком часто стало нас беспокоить… Я, пожалуй, подумаю о том, как сделать, чтобы автоматизированные тесты выявляли проблему раньше».

Фред: «Ты прав, я помогу тебе с тестом».

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