Почему команда может не принять Scrum
История о проблемах внедрения Scrum достаточно холиварная. Вы наверняка видели, слышали, читали и обсуждали множество статей и выступлений на эту тему. Здесь люди делятся на два лагеря: нужен нам Scrum или не нужен.
На мой взгляд, очень многие проблемы вызваны тем, что сама команда не принимает подход Scrum. Из-за этого люди начинают отторгать все изменения, и в результате рождаются те самые статьи, в которых Scrum – это ерунда и даром никому не нужен.
Эта статья будет интересна в первую очередь тимлидам. Но тем, кто не является тимлидом, однако уже переходит на Scrum или только планирует это сделать, она тоже может быть полезна. Вы сможете понять, какие проблемы существуют в вашей команде, и, возможно, подсказать наиболее оптимальные пути их решения или самостоятельно продвигать эти решения.
Почему эта статья появилась именно у меня? В прошлом году наша компания провела глобальную трансформацию, в рамках которой мы перешли на продуктовые команды и Scrum. Все проблемы, с которыми сталкиваются люди при таком переходе, из-за масштабности нашей компании начали выстреливать.
Я аккумулировала этот опыт, собрала проблемы, которые возникали в моей команде и встречались у коллег, и попробовала представить их как практический опыт: какие ошибки не стоит допускать и какие оптимальные пути решения можно найти в подобных ситуациях.
Мы рассмотрим шесть наиболее ярких проблем, которые возникают при переходе на Scrum.
Первая и самая классическая – «Не чините то, что не сломано!» Мне кажется, большинство людей, работающих в IT, знают правило: если код работает шикарно, не трогай его. Лучше не затрагивать то, что и так работает хорошо. Поэтому, когда вы приходите к команде и говорите, что теперь меняются подходы и формат работы, первое, с чем вы сталкиваетесь, – классическая консервативная реакция: «Мы не хотим ничего менять, все и так работает прекрасно».
Вторая проблема – совещания съели всю работу. Никто из нас не любит долгие совещания. При этом Scrum известен тем, что не меньше 30% рабочего времени будут занимать встречи. Когда календарь неожиданно начинает заполняться огромным количеством совещаний, это вызывает отторжение и у вас, и у вашей команды. Эту проблему тоже необходимо решать.
Третья классическая ситуация возникает, когда ретроспективы проводятся некорректно. В результате не достигаются цели, которые должны быть достигнуты по итогам ретро, а люди не понимают, зачем нужны эти встречи, что на них обсуждать и что это вообще за формат общения.
Четвертая достаточно интересная проблема – призрак Скрам-Мастера. Найти огромное количество скрам-мастеров для большой компании на рынке банально сложно. Поэтому на период трансформации компании часто наделяют ролью скрам-мастера кого-то из сотрудников команды. Ситуация, когда скрам-мастер вроде бы есть и одновременно его нет, приносит достаточно много боли.
Последние две проблемы не являются классическими проблемами Scrum и не всегда типичны для перехода на него. Но во время трансформации они выстреливают не меньше. Если в команде есть Гуру, авторитетная звезда или человек, который пытается всех спасти, это влияет на всю команду. Для Scrum-подхода такой эффект оказывается более сильным, чем для проектных команд или каскадных моделей внедрения.
Не чините то, что не сломано!
Классическая история: вы приходите в команду и говорите: «Все, теперь мы работаем по Scrum». Первое, что вы слышите: «Мы и раньше хорошо работали. Зачем нам меняться?»
Люди не понимают, зачем происходят эти изменения. Часто это вызвано не только тем, что они в принципе не хотят меняться. Все люди достаточно консервативны и не готовы к внезапным изменениям, особенно если они не несут какого-то явного профита.
Кроме того, у людей может быть негативный бэкграунд. Например, они работали в другой компании, где подобная трансформация прошла неудачно. В этом случае новые изменения сразу вызывают негативную реакцию.
Что нужно и чего не нужно делать в подобных ситуациях?
Первое, чего нельзя делать ни в коем случае, – внедрять Scrum ради самого внедрения.
Когда человеку говорят: «Внедряйте Scrum», а у команды это вызывает жесткое отторжение, возникает соблазн провести формальное внедрение. Сделать так, чтобы везде было видно, что у вас вроде бы Scrum, а на самом деле продолжить работать по-старому.
Проблемы, которые из этого выльются, придется разгребать очень долго. Если вся компания перешла на Scrum, а вы сделали это только формально, проблемы будут накапливаться. Со временем при перестроении процессов вам будет все сложнее имитировать эту Scrum-историю.
Вторая ошибка возникает, когда переход на Scrum не решает реальных проблем. Ни вы не можете подсветить команде, какую именно проблему решает трансформация, ни сами не видите, какие изменения она должна принести.
Причем часто дело не в том, что переход на Scrum действительно не решает никаких проблем. Просто вы сами не попытались найти или выяснить, какие предпосылки для него были у компании.
Отсюда следует еще одна ошибка: переход на Scrum не дает ощущения ценности. У команды нет ценного опыта или заметного эффекта от того, что она начала работать по-новому.
Что же правильно делать в этой ситуации?
Если проблем не видно, не значит, что их нет. В первую очередь необходимо выяснить, какую конкретно проблему решает трансформация в вашей компании. Эта информация наверняка будет до вас доведена, но вы также можете самостоятельно обсудить ситуацию и выяснить причины перехода.
Как это происходило у нас?
Моя команда много лет работала в формате реализации законодательных проектов. Такие проекты достаточно ясны и понятны: есть определенные сроки и требования от государства. Да, они могут немного меняться, но обычно эти изменения не настолько значительны, чтобы сильно аффектить проект.
Когда мы начали трансформацию и перешли на Scrum, нам поставили совсем другую задачу: перевести на ЭДО весь электронный документооборот по договорам в компании.
Речь идет не менее чем о трехстах видах договоров. Объем измеряется десятками, а то и сотнями тысяч документов. Такой огромный объем, как большого слона, невозможно съесть целиком. Необходимо пробовать, прощупывать и кусочками, через MVP, реализовывать то, что можно сделать в конкретной ситуации.
Когда я подсветила команде, что наша новая задача как раз красиво ложится на Scrum и Scrum-подход будет нам только в помощь, мне удалось получить положительный отклик на трансформацию.
Еще один важный принцип – внедряйтесь постепенно.
Если температура в помещении резко понизится на 15–20 градусов, людям будет некомфортно. Они будут удивлены и недовольны. Но если температура будет понижаться постепенно, кто-то достанет кофту, кто-то сходит в гардероб за верхней одеждой. Люди будут понемногу привыкать к тому, что становится холоднее.
Так же происходит и в команде. Когда вы начинаете плавный переход, постепенно внедряете ритуалы и объясняете подходы, команда воспринимает изменения более лояльно.
Кроме того, защищайте команду.
Во время продуктовой трансформации команда часто формируется не только из тех людей, которые уже работали вместе. В нее могут набирать сотрудников из смежных команд, людей могут переформировывать и по-разному миксовать.
В результате у сотрудников остаются старые долги. К ним по привычке может приходить бизнес с какими-то прежними задачами. У человека из-за сохранившихся договоренностей фактически получается двойной объем работы.
Вы требуете от него выполнения задач новой команды, а бизнес или кто-то еще по старой привычке требует решить задачи, которые были поставлены раньше. Поэтому вы как тимлид должны оберегать сотрудников и пытаться снизить их нагрузку, если у них остались старые договоренности или кто-то пытается добиться выполнения задач, уже не относящихся к их текущей сфере деятельности.
Отмечайте победы и признавайте ошибки. Все любят, когда их хвалят. Если у команды хорошо получается переходить на Scrum, не забывайте это отмечать.
Одновременно необходимо признавать ошибки, особенно если вы как тимлид допустили их во время перехода и что-то пошло не так. Пытайтесь решить эти проблемы и честно говорите, если что-то не получается.
Совещания съели всю работу
Первое, что я услышала после того, как заполнила календарь команды ритуалами Scrum: «А когда нам работать, если мы все время совещаемся?»
Это был классический вопрос от разработчика. Раньше у человека были в основном технические задания и один-два созвона в месяц, а все остальное время он просто сидел и писал код. Теперь появилось 30% рабочего времени, которое нужно было почему-то просиживать на встречах.
Как решать такую ситуацию, когда сотрудники приходят с подобными вопросами?
Самая большая ошибка, которую часто допускают, – пустить события на самотек. Люди рассуждают так: «У нас же самоорганизующиеся команды по Scrum. Сотрудники постепенно привыкнут. И вообще, что такого в совещаниях? Посидели, послушали и разошлись». Нет, так это работать не будет.
Я столкнулась с эффектом своеобразной итальянской забастовки, когда люди просто пересиживали совещания. Были и интересные истории, когда сотрудники в явном виде пытались прогуливать встречи.
Причины звучали по-разному: «У меня отключили интернет», «У меня выключился свет», «Заболела любимая кошка моей тетушки, и мне срочно нужно к ней ехать».
Вариантов было много. Но если посмотреть на тенденцию, оказывалось, что все эти события происходили именно тогда, когда нужно было провести большое совещание вместе с командой.
Это явные звоночки: человек не хочет посещать встречи, потому что они его по какой-то причине не устраивают.
Одна из возможных причин – совещания превращаются в бесцельную говорильню. Вы приходите, просто разговариваете, но не получаете никакого результата. Переливаете одну и ту же тему из пустого в порожнее, а смысл и цель совещания так и не достигаются.
Формат необходимо менять, чтобы люди получали какой-то профит от того, что пришли на встречу.
Еще одна частая ошибка, которую я уже упоминала, – ритуалы ради ритуалов. Вы пытаетесь формально показать, что соблюдаете все требования. В Scrum Guide написано, что необходимо проводить определенные встречи, поэтому вы заполняете календарь – и все. При этом сами встречи не несут никакой смысловой нагрузки.
Что положительно влияет на принятие командой большого количества встреч?
Первое – жесткое соблюдение тайминга.
Scrum и так требует около 30% рабочего времени. Жесткое соблюдение тайминга позволит хотя бы не выйти за пределы этого большого процента. Иногда 30% легко превращаются в 40 или даже в 50%.
Следите за временем. Можно составить для себя график и записывать, сколько заняло то или иное совещание.
Например, когда я поняла, что мои дейлики выходят за рамки заложенных 10–15 минут, я стала записывать их и анализировать, что происходит на встречах и почему мы не укладываемся в тайминг.
В результате я выяснила, что сама проводила дейлик как тимлид и периодически начинала вовлекаться в диалог с сотрудником о возникших у него проблемах. Тем самым я сама растягивала время совещания.
Чтобы этого не происходило, я стала по очереди делегировать проведение дейликов сотрудникам команды, а сама выступала в роли модератора или фасилитатора. Если человек, проводивший дейлик, задавал вопросы и пытался вовлечься в дискуссию, я останавливала разговор и говорила: «Коллеги, паркуем этот вопрос и переносим на отдельную встречу». Это позволило установить более четкий тайминг дейлика и не выходить за отведенное время.
Следующий принцип – фокусируйтесь на Цели Спринта.
Цель Спринта – самое главное в Scrum. Вы к ней стремитесь, поэтому не забывайте за ней следить. Если совещание уходит куда-то в сторону и команда начинает обсуждать множество разных вопросов, старайтесь возвращаться к цели.
Можно выписать или вывести на экран цель спринта и в течение совещания отслеживать, не ушли ли вы в сторону.
Измеряйте ценность, а не активность. Не говорите: «Мы провели пять дейликов» или «Мы провели ретро». Говорите о том, какие именно цели были достигнуты благодаря этим встречам.
Например: «Благодаря дейлику мы выявили, что у нас есть проседание по срокам в такой-то задаче». Или: «У коллег возникли проблемы, поэтому мы выделили дополнительного разработчика, который поможет им закрыть задачу и достичь цели спринта».
Еще один интересный вариант – экспериментировать с форматами. Не делайте все совещания одинаковыми и монотонными. Пытайтесь менять формат и проводить встречи по-новому.
Ретроспектива: от пустой рутины до поля битвы
Правильная ретроспектива должна быть нацелена не только на освещение положительных моментов, происходящих в команде, но и на выявление проблем и поиск путей их решения.
Однако, когда вы только начинаете внедрять Scrum, обычно возникают два полюса.
Первый: команда полностью игнорирует ретро. Вы как тимлид пытаетесь вовлечь сотрудников, буквально прыгаете вокруг них, а они просто заваривают чай, сидят и наслаждаются дополнительным перерывом, воспринимая встречу как еще один обед.
Второй вариант: команда вовлекается, но боится говорить о проблемах. В этом случае получается своеобразная ярмарка тщеславия. Каждый хвалит себя и рассказывает, какой он молодец. Кто-то может похвалить коллегу: «Петя мне помог, все хорошо».
Вы выходите с совещания с ощущением, что у вас все прекрасно. Но на самом деле никто просто не озвучил существующие проблемы. Все боятся говорить о том, что не работает.
Что не нужно делать?
Не нужно проводить одно и то же месяцами. Как я уже говорила, старайтесь менять форматы. Именно для ретроспективы особенно важно, чтобы встреча не была монотонной. Иначе люди начинают готовиться по шаблону: «Так, я подготовил два стикера о том, что мне нравится, и три тезиса о том, что мне не нравится. Все замечательно».
Не нужно ретро превращать в говорильню. Когда вы начинаете вовлекать команду в ретро, то можете использовать какой-нибудь формат для растапливания льда. Но есть опасность, что вы будете топить этот айсберг весь час или даже все два часа ретроспективы и так и не перейдете к сути. Команда раскрылась, люди пообщались, но никаких других эффектов вы не получили.
Наверное, самая жесткая ошибка – игнорировать предыдущие договоренности.
Команда раскрылась, рассказала о проблемах, вы обсудили, как будете их решать. Но через спринт вы приходите на новое ретро, а ничего не изменилось. Все проблемы остались на месте, а договоренности не выполнялись.
Что делать правильно?
Первое – создать правила безопасности. Их можно зафиксировать в явном виде или проговорить, чтобы люди не боялись раскрываться.
Важно начинать с отчета по прошлым действиям. Если вы о чем-то договорились, откройте материалы предыдущего ретро, поднимите договоренности и проговорите, что именно было выполнено командой.
Если принятое решение не сработало, можно обсудить на новом ретро, как поменять подход к решению проблемы.
И последнее – меняйте форматы и ведущих. Существуют сайты, на которых собраны разные сценарии для ретро, а также различные форматы проведения других Scrum-встреч. Они описаны достаточно просто и понятно.
Я часто пользуюсь такими подборками, когда не успеваю подготовиться, а ретро нужно провести срочно. Открываю сайт, выбираю наиболее подходящий формат – и буквально через 20 минут встреча готова.
Призрак Скрам-Мастера
Как я уже говорила, достаточно распространена ситуация, когда ролью скрам-мастера наделяют тимлида или другого сотрудника команды.
По сути, у человека начинает развиваться биполярное расстройство: он не понимает, кто он сейчас – скрам-мастер или тимлид. Причем такой же эффект возникает у всех членов команды.
Как решить эту проблему?
В первую очередь нужно понимать, чем занимается скрам-мастер и чем занимается тимлид, если вы оказались в подобной ситуации.
Тимлид – это человек, который прежде всего следит за задачами и за тем, как они выполняются. Скрам-мастер не должен оценивать людей по задачам.
Если вы продолжаете натягивать на себя роль тимлида даже в те моменты, когда должны выступать как скрам-мастер, у команды начинается диссонанс.
Еще одна явная ошибка – игнорировать мелкие «странности».
Например, вы подключаетесь к совещанию немного позже, и разговор в команде сразу замолкает. Такие мелкие звоночки показывают, что внутри команды что-то не так и люди воспринимают вас странным образом.
Как упростить жизнь себе и команде?
Во-первых, физически маркировать роли.
Хороший вариант – перед совещанием в явном виде проговаривать: «Сейчас я выполняю роль скрам-мастера» или «Сейчас я выполняю роль тимлида».
Если в течение всей встречи вы выступаете как скрам-мастер, в отдельные моменты можно делать вставки: «Коллеги, сейчас я скажу не как скрам-мастер, а как тимлид. Здесь необходимо поступить иначе».
Можно заранее договориться с командой о визуальном маркере, который поможет отличить одну роль от другой.
Например, на встречах, где вы выступаете как скрам-мастер, вы включаете камеру, а на совещаниях, где выступаете в роли тимлида, – не включаете. Это прекрасный визуальный маркер. Можно придумать и какой-то другой вариант.
Важно помнить, что скрам-мастер – это человек, который задает вопросы, а не дает ответы. Вы должны подталкивать команду к самостоятельным решениям. Не забывайте об этом и правильно распределяйте роли.
Гуру, перед которым все молчат
Следующая ситуация связана с авторитетным звездным сотрудником, который является явным экспертом.
Такой человек может подавлять команду настолько, что, даже если вся команда в рамках спринта на полном ходу летит навстречу айсбергу, но решение предложил эксперт, все будут идти до последнего, пока действительно не столкнутся с этим айсбергом.
Что не стоит делать в подобных ситуациях?
В первую очередь не стоит публично пытаться переубедить Гуру, доказать, что он неправ, переспорить или подавить его.
Если у человека есть авторитет и он является признанным экспертом, не факт, что вы сможете его продавить. Не факт и то, что команда поддержит вас, а не его. Важно понимать, что такой эксперт удобен для команды.
Все привыкли к тому, что можно обратиться к Google, а теперь и к искусственному интеллекту, задать вопрос и получить ответ, которому с большой долей вероятности поверишь.
А здесь под рукой находится своеобразный ручной искусственный интеллект. Всегда можно прийти к эксперту, который скажет: «Да, нужно делать именно так. Это правильное решение». После этого человек выдыхает и думает: «Мне дали экспертное заключение». Так происходит, когда Гуру имеет очень сильный авторитет в команде.
Не стоит просто ждать, когда команда самоорганизуется. Да, Scrum-команды являются самоорганизующимися, но вы должны им в этом помочь. Пока один человек подавляет остальных, команда продолжает строиться вокруг него.
Еще один вариант, который многие пытаются использовать, – просто загрузить Гуру задачами. Они рассуждают так: «Давайте завалим его работой, чтобы он даже лишнего слова сказать не мог. Пусть будет занят задачами по самую макушку».
К чему это приведет? В результате вы получите выгорание эксперта, который является признанным авторитетом для команды. Одновременно у вас останется целая команда людей, которые не готовы принимать решения и недостаточно глубоко погружены в работу.
Они все время доверяли авторитетному сотруднику, не особенно думали своей головой и не погружались в детали, потому что всегда были уверены: любой вопрос можно задать ему. Но выгоревший человек – это не тот, кто готов продолжать консультировать. В результате команда развалится – просто не сразу, а немного позже.
Что стоит сделать?
В первую очередь можно ввести анонимность в обсуждениях.
Если у вас удаленная команда, придумайте формат, при котором все участники одновременно присылают стикеры. Их можно сделать скрытыми до тех пор, пока не выскажутся все. После этого вы откроете и рассмотрите рекомендации каждого члена команды.
Можно договориться с Гуру о роли «последнего голоса».
Поговорите с ним один на один и предложите такой формат. Обозначьте, что цените его как эксперта и хотите, чтобы он выступал в конце и финализировал все, что сказала команда. Это позволит остальным вначале подумать самостоятельно, прежде чем бездумно обращаться к решениям, которые дает эксперт.
Самый интересный вариант – выделить для Гуру роль наставника.
Вы не обесцениваете его авторитет, а, наоборот, наделяете его дополнительной ролью, вниманием и, возможно, определенной властью – тем, чем такие люди обычно готовы наслаждаться. Вы говорите ему: «У тебя есть сотрудники. Обучай их, делись с ними своим экспертным мнением». Такой формат наверняка устроит большинство людей, которые выступают в командах явными экспертами и авторитетами.
«Спаситель» команды, который сгорит первым
Последняя проблема, о которой я хочу поговорить, – Спаситель команды.
Некоторые люди бывают гиперответственными. Им кажется, что все будет плохо, если команда не достигнет цели спринта, и они начинают буквально гореть работой.
Человеку поставили задачу, а на следующий день он приходит и говорит:
«Я уже все выполнил».
«Как?»
«Я сидел ночью. У меня появилась идея. А давайте я еще возьму задачу у Пети. Да, я понимаю, что он должен приступить к ней на следующей неделе, потому что спринт длится две недели. Но я уже на этой неделе все за него доделаю».
Человек горит и боится, что при невыполнении задач или недостижении цели спринта что-то пойдет плохо. Возможно, он просто сильно переживает или хочет сделать все лучше всех.
Чего в этом случае нельзя делать ни в коем случае?
Нельзя хвалить человека за героизм и переработки, хотя это очень хочется сделать.
У меня была ситуация, когда мы действительно не успевали достичь всех целей спринта. Задачи были не закончены, оставалось несколько дней, и человек по собственной инициативе ночью сидел и писал код. На следующий день он пришел, выложил результат и сказал: «Коллеги, я все сделал, все работает шикарно. Тестируем и закрываем».
Спринт закрыт на 100%, все довольны. Кажется, что человека хочется поблагодарить и сказать: «Ты молодец». Но одновременно ты понимаешь, что этим делаешь только хуже и подталкиваешь его поступать так и дальше.
Не стоит позволять Спасителю переделывать чужую работу.
Это еще одна типичная история. Человек находит у кого-то ошибку и говорит: «Я сейчас все исправлю. Зачем мне кому-то что-то объяснять?» Или он вообще никому ничего не говорит: ночью находит ошибку в коде и самостоятельно идет ее исправлять.
Не нужно и нагружать Спасителя еще больше. Это тоже пытаются делать очень часто: кто тянет, на том и едут. Человек справляется, все выполняет хорошо и быстро, поэтому возникает соблазн накидать ему еще больше задач на следующий спринт.
Что правильно делать в этой ситуации?
У человека однозначно есть энтузиазм и силы на то, чтобы прорабатывать проблемы. Хвалите его за то, что он задает вопросы, не решает все самостоятельно, а подсвечивает сложности.
Хвалите его за то, что он выполняет роль наставника. Эту роль можно выделить в явном виде, чтобы человек делился своей экспертностью и опытом с другими сотрудниками команды.
Важно снизить нагрузку Спасителя на 20–30% в следующем спринте, если вы выявили такую ситуацию.
Конечно, вам будет неприятно, какие-то метрики могут просесть. Но человек, у которого появилось свободное время, сможет выполнить роль наставника и поделиться своей экспертностью.
Кроме того, важно нормировать время ответов на вопросы.
Часто в команде формируется подход: «Пойдем спросим у Васи». А Вася всегда готов тратить рабочее время на ответы.
Установите ограничения. Например, выделите два часа на ответы на вопросы, а все остальное время сотрудник должен заниматься собственными задачами.
Надеюсь, вам понравилась статья и вы сможете применить на практике то, что мы рассмотрели.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
