Источник фото

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

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

Итак, какие уроки я извлекла и выводы сделала в первый год работы в роли Scrum-мастера (о которых кратко пунктами изложила в самом конце):

Розовые очки

После двухдневного тренинга по Scrum я была готова сворачивать горы, изменять мир на пути компании к лучшему. Ничто так не вдохновляет, как грамотный коуч и команда единомышленников! Но стоит только начать, как вдруг ты остаёшься один на один со своим фреймворком Scrum. Есть ребята, загруженные собственными задачами, есть привычки и ценности, которые уже сложились в работе команды, есть менеджмент, который по-своему видит процессы, и это не всегда идёт параллельно с ценностями и представлениями Agile. В общем, добро пожаловать в реальный мир.

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

Сопротивление

Безусловно, нововведениям и очевидным грядущим изменениям не очень обрадовались. В моем случае скорее это было смирение с тем, что пришёл ещё кто-то, чтобы управлять и учить: «ну ведь и так всё хорошо». Делать нечего – пришлось доказывать, что я пришла помогать, и на практике это демонстрировать.

Важный момент: если в самом начале вы не найдёте в команде разработчиков сторонников, рискуете быть отвергнутыми.

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

Задайте себе вопрос: «какова цель моего присутствия в этой роли и как я могу помочь своей команде улучшить существующие процессы работы?». Если ответ нашёлся – отлично, вперёд к изменениям! Если нет, то стоит понаблюдать ещё.

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

Спешка – худший помощник

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

Готовность к изменениям наступает у команды постепенно. Понаблюдайте за командой в течение 1-2 недель, не вмешиваясь в «естественный» ход вещей. На первых этапах необходимо понять для себя логическую цепочку процессов и сложившихся ценностей, увидеть уязвимые места в работе и, собственно, предложить решение. Шаг за шагом пытайтесь внедрять события и ценности методологии в сознание и жизнедеятельность своей команды.
В этом вам поможет фасилитация встреч, частое взаимодействие с командой, как личное, так и в формате событий, коучинг. И, конечно, доверие и открытость к диалогу.

Понимание среды

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

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

Итак, в самом начале особенно важно:

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

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

Присутствие стратегии

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

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

Чаще всего, приходя в команду, я видела, как ребята проводят ежедневные совещания по 1,5-2 часа, на которых пытаются проработать все вопросы. А это, между прочим, – колоссальное количество времени, которое вычитается из рабочих часов и снижает эффективность работ команд. Да и Scrum Guide предполагает на это событие только 15 минут и ни минутой больше.
Как быть: самым правильным подходом, на мой взгляд, является разделение таких активностей и фокусировка на поставленных задачах в рамках целей Sprint.

Отталкиваясь от болей и наиболее частых вопросов, помимо основных событий Scrum (планирование, daily, demo, retro) может формироваться, например, еженедельная исследовательская встреча, обсуждение бэклога идей или же мозговые штурмы для обсуждения углубленных вопросов, как происходит сегодня у нас в ICL Services. Мы видим боль, знаем, как исправить ситуацию и что нужно сделать – остаётся лишь обсудить изменение формата работ с менеджментом и командой для достижения наилучшего эффекта.

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

Нехватка технических знаний

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

Но и здесь есть довольно простые лайфхаки:

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

Краткие итоги

1. Опирайтесь на уже имеющийся опыт. Поймите, в чём нуждается команда, какие проблемы и недосказанности существуют и как можно ей помочь.
2. Определите, чем изменения могут быть полезны команде, и покажите ей это. Люди не готовы меняться, пока не увидят ценность в этом для себя.
3. Позвольте себе понаблюдать за командой первый Sprint, понимание процессов и ценностей команды приходит без спешки, а готовность к изменениям наступает постепенно.
4. Понимание взаимосвязи между отделами и активная коммуникация с менеджментом – это ценный ресурс, который поможет вам устранять препятствия, отвлекающие команду от главного – создания ИТ-продукта.
5. Задайте себе вопрос «что мы хотим изменить и почему?», и ответом на него станет четкая цель. А в ответ на вопрос «как мы будем это делать?» составьте план, который будет понятен и известен руководству еще до начала изменений, т. к. в него могут внестись весомые правки в зависимости от верхнеуровневых целей компании.
6. Нехватка технических знаний. Если у вас нет технического образования, но есть желание или необходимость освоить терминологию, не бойтесь просить помощи. Хорошим помощником может также стать личный терминологический словарик.

Уверена, что все уроки, полученные мной, помогут и вам сделать выводы и перестроиться в правильном направлении, потому что я на самом деле люблю то, что делаю. И, главное, не бойтесь ошибок, а учитесь на них. Удачи!