One Scrum Process Story (in Russian)

Алекс Атемасов и Макс Колодезный

Ситуации

Теперь же рассмотрим некоторые «подводные грабли», на которые в свое время наступила наша команда. Как так случилось, как мы с этим справились и что надо сделать, чтобы на них не натыкаться.

Смена Scrum Master'a

Есть на фирме один самый-самый главный топ-девелопер, есть несколько (очень важных!) проектов, которые приносят больше всего прибыли. Самым простым и естественным решением руководства компании стало назначение этого человека как Scrum Master'a на эти проекты. И как Tech Lead'a тоже. Две команды, два проекта. Два полушария мозга, два полушария не только мозга – это не помогает! Страдают обе команды. Поэтому возникла необходимость в разгрузке этого человека — потенциального узкого места. Что в данном случае может сделать непосредственно команда? В частности, снять с этого человека тяжесть Scrum Master'a. Что мы, в свое время, и сделали. Новым SM стал куда менее опытный и матерый девелопер, но когда команда на ходу, все в теме, не надо ничего строить и придумывать, это может пойти только на пользу. Как новому SM, так и команде в целом.

Естественно, все не без сучка без задоринки. Любому человеку в новой роли нужно обжиться и Scrum Master не исключение. В первые пару недель очень важным для нового SM будет и поддержка команды, и помощь предыдущего SM, и подсказки PO. В нашем случае, Product Owner даже перенял некоторые функции Scrum Master'a на некоторое время. И кроме этого оказывал полное доверие и, более того, даже обучал «юного падавана». Особую роль во всем этом переходном процессе играют, конечно же, ретроспективы. На них действия нового SM должны рассматриваться особенно тщательно, тем более, если для возникнут явные причины.

Явные минусы, конечно, тоже есть. Как уже говорилось новый SM был менее опытный специалист, да и более молодой. Это несколько преиуменьшало его вес и мнение в глазах высшего начальства компании по сравнению с предыдущим SM. Кроме этого, отсутствие подобного опыта не может пройти незаметно. И промахи в «работе с людьми» могут случаться чаще. Пройдя этот путь, хочется посоветовать любому Scrum Master'y, молодому или не очень, опытному или новичку: Scrum Master не начальник команды — он главный ее помощник. И возможно единственный.

Новый член команды

Введение в команду нового человека. Основная причина — уход сотрудника и, как следствие, недостаток внутрикомандных ресурсов. Основной ошибкой стало делегирование полномочий по выбору нового члена команды на руководство компании, что привело к выбору из нескольких претендентов, не заинтересованных в Scrum-процессе как в таковом. Если бы эта задача изначально лежала на команде, то основным критерием отбора был бы человеческий фактор и только потом профессиональный уровень, а не наоборот. Если привесьти в команду условного Senior'a, который пускай и круче всех по опыту, знаниям и навыкам, но при этом будет троллем, занудой и просто асоциальным человеком — это будет иметь печальные последствия, вплоть до уменьшения общекомандного КПД. Что мы получили в результате? Потраченное впустую время на интеграцию с командой, ввод в Scrum-процесс, прививание идеологии методики, а также философии и целей команды.

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

Во-первых, не стоит слишком сильно затягивать процесс ввода человека в курс дела. Излишняя жалость и мягкость, дозированность подаваемой информации. Это не позволяло команде чувствовать нового человека своим. Пускай, по-началу, у него кружится голова от кучи нового и неизведанного, но если человек заинтересован в том, чтобы влиться в коллектив (и если он не полный дурак) — он справиться и довольно быстро.

В свою очередь, Scrum Master должен присматривать за выполением основных принципов, идеологий методики и команды. Никто цербер вводить не заставляет, но некоторые правила соблюдать нужно. Чья уж эта задача, как не Scrum Master'a…

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

(По мотивам презентации «One Scrum Process Story» от 12.06.2010)