Всем привет!
Сегодня у нас на связи agile-коуч Василий Савунов. Немного поговорим об организации работы команды по системе Scrum, а также получим ценные рекомендации по обучению Scrum и Kanban.
Интервьюер — Илья Дзенски, фрилансер, UX/UI дизайнер, адепт Agile.
Илья: Привет, Василий!
Василий: Привет!
Илья: Давай разберёмся в терминах. Если читать статьи в интернете, например статью на Rusbase, то можно запутаться в терминологии. Одни эксперты говорят, что Kanban и Scrum — это что-то из Agile, а другие говорят что Kanban, Scrum, Agile — это три разные вещи, каждую из которых нужно применять в нужное время и место. Кто из них прав?
Василий: Не смотря на то, что Agile проник в Россию относительно давно (первые тренинги по Agile начались где-то в 2007 году), настоящих экспертов по нему не так уж много. Поэтому путаница в терминах до сих пор существует. Когда мы говорим об Agile, мы имеем в виду 4 ценности из Agile-манифеста:
Эти 4 ценности дополняются 12-ми принципами, и всё это вместе называется Agile. Если проводить аналогию, Agile — это как Конституция, она не очень конкретна, но даёт общее направление и концепцию. А Scrum, Feature Driven Development, экстремальное программирование и остальное — это конкретные реализации Agile. Если брать наш пример выше, то Scrum — это закон, который реализует конституцию в виде мероприятий, ролей и артефактов.
Agile — это как зонтичный бренд над agile-подходами и методологиями, которые я назвал выше. И этих инструментов значительно больше. Scrum выиграл маркетинговую войну из-за своей внешней простоты и чаще остальных методологий применяется в компаниях. Но внешняя простота обманчива — в Scrum достаточно много нюансов.
Илья: Ты сказал о том, что у Agile есть 4 ценности. Если я их выполняю, но при этом не использую ни одну из методологий, и у меня нет команды, то выходит, что Agile работает даже с одним человеком?
Василий: Да, Agile-философия может работать с одним человеком.
Но весь дьявол кроется в том, что когда нас становится больше чем один человек (это и заказчик, и исполнитель, и эксперт в своей области), то нам нужно понять и решить, как мы конкретно будем реализовывать Agile. Все методологии, тот же Scrum, пытаются навести в этом порядок. Он говорит: “Вот вам ряд действий и правил. Если вы эти правила и действия соблюдаете, то вы гарантированно Agile. У вас все 4 ценности будут выполняться. Но если вы хоть что-то из этого нарушаете, например, перестаёте проводить ретроспективы, то у вас начинает теряться обратная связь, вы останавливаетесь в бизнес-процессах, и необходимой гибкости так и не достигнете”.
Отвечая на твой вопрос: да, Agile может работать с одним человеком, но изначально он был придуман для команд, чтобы они могли работать в одном ключе.
Илья: Какое оптимальное количество scrum-команд и участников в командах может быть?
Из классического менеджмента известно, что есть определённый операционный максимум. Это количество людей, которыми можно руководить без потери контекста и без потерь коммуникации между ними. Считается, что это 7+-2 человека. Максимум — 9. Только очень талантливый руководитель может ими управлять и быть в контексте, что у них происходит. Если мы выходим за это количество, то начинается дробление на подгруппы, и это дробление происходит естественно. Если команда значительно больше по количеству людей, то начинается начинается существенная потеря и искажение информации при её передаче между участники.
Что касается количества команд. Выделенный Scrum-мастер может успешно вести 3-5 команд. Больше 5 команд одному Scrum-мастеру вести очень сложно: надо быть в контексте всех их проблем, успевать на все мероприятия (планирование, дейли митинг, ретроспектива, демонстрация) во всех командах. Ну и конечно, хорошему Scrum-мастеру нужно понимать профессиональный и технический контекст того, что делают команды.
Задача выделенного Scrum-мастера заключается не в том, чтобы быть незаменимым человеком, обладающим уникальными знаниями и навыками, а в том, чтобы внутри этих самых команд найти или вырастить людей, которым интересно заниматься подобной организационной работой, и способствовать росту эффективности своих команд. Scrum-мастер должен как можно больше передавать своих полномочий и организационных вопросов внутри команд, чтобы повысить устойчивость и стабильность организаций в целом. Тогда необходимость в выделенном Scrum-мастере отпадает, и эту роль может взять кто-то из команды.
Если этого не происходит, то появляется так называемый “bus-фактор”, или “автобусный фактор”. Это несколько шутливый термин, но в нём очень много правды. Звучит он так: “Сколько человек в вашей команде должно быть сбито автобусом, чтобы проект встал?”. Соответственно, чем меньше это число, тем хуже для вас. Если это один человек, то в случае если он заболеет, уволится, или его (не дай Бог) собьет автобус, то команда не сможет двигаться дальше из-за потери уникальной компетенции, проект остановится, или даже “умрет”.
Есть и более изощренные и сложные способы организовать работу по Scrum на большом количестве команд. Для этого существуют процессные фреймворки масштабирования Scrum, такие как LeSS и SAFe.
Классический LeSS, позволяет работать по Scrum до 8 команд. Если у нас появляется больше команд, то применяется Huge LeSS.
SAFe помогает работать на еще больших масштабах: 500-2000 человек. К примеру, “Сбербанк” использует SAFe. Система очень сложная, и не берусь рассказать это в интервью. Есть целый портал, посвященный тому, как его применять: www.scaledagileframework.com
Илья: Как стать “командой мечты”?
Василий: Начну с того, что Agile и Scrum не для всех. Он — для тех, кто умеет думать головой, кто хочет понимать и готов вникать в бизнес-процессы и бизнес-логику. И точно не для тех, кто работает с 9 до 18:00 и только по чёткому ТЗ.
Поясню, почему это так.
Одна из ценностей Agile звучит так: “взаимодействие с заказчиком важнее согласований условий контракта”. Контрактом в данном случае считается и техническое задание тоже. Программисты — люди квалифицированные, и очень хорошо умеют манипулировать контрактом. Нередки случаи, когда при сдаче проекта заказчик спрашивает: “А почему вы не сделали вот эту функцию? Она сюда напрашивалась сама собой”. На что программисты отвечают: “Этого не было в ТЗ. Не написали — не сделано. В следующий раз пишите”. Потому что ТЗ — это контракт.
Заказчик может спросить: “А поговорить?“, на что программисты говорят: “А за разговоры нам денег не платят”. И начинается “битва за контракт”, когда программисты требуют все более подробное ТЗ, а потом интерпретируют его в свою пользу. В свою очередь, заказчик может вписать в ТЗ какое-то требование, которое трудно осуществимо, но раз есть в ТЗ, а это контракт, то начинается “выкручивание рук” программистам, что это требование должно быть сделано.
Мы бьемся вокруг формулировок, а продукт при этом страдает.
Поэтому Agile прямо декларирует: сперва поговорите, обсудите вместе нюансы с заказчиком, а потом уже фиксируйте договоренности на бумаге. Не наоборот.
По поводу этапов формирования “команды мечты”. У каждой команды будут определённые этапы, которые они будут проходить. Эти этапы хорошо описываются в так называемой модели Брюса Такмана.
Первый этап называется “форминг” (forming), когда люди знакомятся между собой, эффективность команд не очень высокая, но и конфликтов особо нет.
Вторая стадия это “шторминг” (storming), когда люди чуть-чуть друг друга узнают, но не достаточно, чтобы сработаться, а им вместе уже надо выполнять какое-то сложное задание. Начинаются конфликты, обиды, и деление на подгруппы.
Именно поэтому в Scrum предусмотрена роль Scrum-мастера. Он должен знать и уметь управлять этой динамикой и помочь группе пройти сложный этап “шторминга”. Для этого он должен уметь грамотно организовывать обсуждения (фасилитация), разрешать конфликты, поддерживать, подбадривать, и помогать команде сработаться, чтобы она могла перейти на следующий этап развития — “норминг” (norming).
На этапе “норминга” (norming) команда уже разрешала основные конфликты, участники команды поняли, кто и чего стоит, как лучше взаимодействовать между собой, выделяются лидеры и отпадают слабые звенья.
Если Scrum-мастер человек умный, то он будет вскрывать конфликты внутри команды, и организует конструктивный поиск решений, с тем чтобы участники команды учились договариваться и налаживать контакты друг с другом. Постепенно команда становится все более устойчивой, за счет обмена опытом и готовности подменить или помочь друг друга ради достижения общей цели. В итоге, выбывание отдельных участников из команды становится не столько критичным. Появляется синергия, взаимодополнение, когда каждый участник команды знает тонкости работы своего коллеги и в случае его отсутствия, может в какой-то степени выполнить часть работы за него, с тем чтобы движение к цели не останавливалось.
Финальная стадия развития команды — это перформинг, когда люди сработались, они замотивированы, они профессионалы, и выходят на максимум своей производительности.
Илья: Представим, что у одного Scrum-мастера в “ведении” находится 5 команд, он проводит встречи, ретроперспективы, и другие мероприятия. Может ли Scrum-мастер совмещать несколько должностей и функций (то есть быть, например, программистом), или это нежелательно?
Василий: Хороший вопрос. Если это локальный мастер внутри одной команды, то тогда совмещение — это хорошо и правильно.
Scrum-мастер — это не должность, это роль. Её может выполнять любой доброволец, который на себя её возьмет. Я знаю позитивные примеры, когда роль Scrum-мастера в команде переходящая. В один спринт работает один скрам-мастер, в другой спринт — другой. Это очень способствует сплочению команды и уважение к этой роли. В этом смысле локальный скрам-мастер и должен быть членом команды.
Крайне не рекомендуется совмещать роль product owner’a и scrum-мастера, так как у них совершенно разные фокусы. У Product owner’a фокус на продукт, а не на людях, а у Scrum-мастера совершенно наоборот. Если эти две роли совместить в одном человеке, получится внутренний конфликт интересов, который очень тяжело разрешить гармонично.
Если Scrum-мастер специально выделен на несколько команд, то совмещать ещё и рабочую должность внутри какой-то из команд для него будет практически не реально. У него просто не будет времени заниматься ничем, кроме организационной деятельности.
Илья: Насколько сложнее организовать удалённую команду, когда участники команды находятся по всей стране или в разных странах?
Василий: Будем честными, Agile довольно тяжело работает в условиях распределённости людей. В моей практике были случаи, когда распредёленная команда смогла найти в себе силы самоорганизоваться. В общем случае это работает только тогда, когда эти люди с регулярностью хотя бы 1-2 месяца встречаются и вместе работают. Иначе не возникает “чувства локтя”.
37 Signals (ныне Basecamp) были первыми кто внедрил удаленную работу. У них не было офисов. На тот момент это было трендом. Есть даже книга Remote, где говорится, что не надо держать офисы, все могут быть в разных странах и городах мира. Но в последнее время жизнь показывает, что это неэффективно. И Nokia, и Apple, сейчас собирают команды локально: перевозят своих сотрудников в офисы, чтобы все сидели рядом и видели друг друга.
Психологически собеседник в Skype или мессенджере воспринимается как картинка на экране. Нет ощущения что ты живой человек, что я за тебя несу ответственность. В интернете можно не ответить сразу на вопрос собеседника, а вот ты попробуй не ответить сразу, если человек прямо перед тобой сидит и тебе задаёт вопрос. Личное общение лицом к лицу, вживую, создает чувство сопричастности, а общение через интернет — нет.
У меня был прецедент, когда мы работали с двумя частями одной команды — одна часть находилась в Москве, а вторая в Ростове. Мы привозили их раз в полтора месяца в Москву, и они по 2 недели работали в одном офисе с московскими коллегами, вместе решали задачи, проводили демонстрации и тд. В результате это дало очень важный эффект: исчезло колоссальное количество конфликтов и недопонимания. Люди действительно почувствовали себя командой. И даже когда они вернулись к себе обратно в разные города, чувство общности сохранялось. Ведь одно дело когда ты общаешься с каким-нибудь “Петей” в чатике, и можешь злится на него, что вот он там “ничего не понимает” или “долго отвечает”, а совсем другое — когда ты этого “Петю” увидел вживую, пообщался, порешал вместе с ним задачи. И после этого в случае недопонимания, ты просто думаешь “Да нормально все, Петя хороший парень, просто что-то мы в чатике запутались. Сейчас я ему позвоню и все быстро решим”.
Стив Макконел ввёл понятие периода полураспада доверия. К примеру, если мы с тобой познакомились, пообщались, а потом полтора месяца не общались, не переписывались и вообще никак не контактировали: ни в мессенджере, ни по телефону, ни по e-mail, то нам с тобой по-новой надо будет знакомиться, так как исчезнет ощущение что мы свои люди, и в распределенных командах это работает точно так же.
Залогом качественной удаленной работы может быть выстроенный процесс синхронизации, и нужно приложить довольно много усилий, чтобы это произошло.
Очень важно понимать, что наличие взаимной ответственности не возникнет, если не будет ощущения опасности. Опасности такого рода: если мы сейчас не договоримся, то позже лажанем так, что плохо станет всем. В Scrum это ощущение создается через демонстрации результата командой заказчику. Если это организовать правильно, то даже в распределенных командах возникнет ощущение, что мы все “в одной лодке”. Даже если ты находишься в другом городе, вполне может возникнуть ситуация, когда именно ты, удаленно, должен будешь продемонстрировать заказчику результат работы команды, и ответить на все вопросы. Вот тут начинаешь живо интересоваться — а кто что сделал? А все ли готово? А тестовый стенд точно работает? А какие средства связи? И тд.
Распределенная команда очень сильно снижает чувство локтя, и требует колоссальных усилий от Scrum-мастера. Но при наличии сильного Scrum-мастера, возможно всё.
Илья: Что тогда делать удалённым командам? Пытаться внедрять Agile или отойти от него, и обратить внимание на какую-то другую методологию?
Василий: Внедрить Agile в удалённой команде возможно, хоть и эффективность её будет значительно ниже. Самая большая проблема удалённых команд — взаимопонимание.
Самое худшее взаимопонимание происходит между людьми, когда они общаются через e-mail, чуть лучше — аудио (по телефону). Идеальный вариант — это общение у доски, когда мы можем говорить и рисовать.
Удалённым командам я рекомендую начать с Kanban, когда мы сперва выстраиваем абсолютная прозрачность нашей работы по этапам, чёткие и ясные приоритеты, видны ограничения команды. Мы начинаем понимать наши Wip-лимиты (ограничения Work in progress — работы в процессе). Мы приучаемся к тому, что важнее завершать начатое, а не начинать новое. Ведь если мы много начинаем делать, но мало заканчиваем, то по сути — “закапываем“ кучу денег “в землю”. Нам нужно как можно быстрее проводить задачки от возникновения, до выкладки на production-сервер. И для этого нужны усилия всей команды.
Когда мы таким образом, выстроим хороший рабочий процесс, мы начнём упираться во взаимодействие людей, и их взаимопонимание. И вот здесь можно начинать задумываться о Scrum.
Канбан и Scrum друг другу не противоречат. Канбан может быть “наложен” на Scrum, эти вещи взаимодополняют друг друга, хоть цели у них разные.
Илья: Представим не редкую ситуацию, когда в удалённую команду внедрён Канбан, но один из участников постоянно тормозит процесс. Что делать с этим человеком: мотивировать или увольнять?
Василий: Тут выход только один. Надо создать человеку должное ощущение опасности.
Другими словами, так как в Канбан мы работаем совершенно прозрачно, и есть статистика работы, то возможен такой диалог с этим человеком: “Смотри, на тебе зависают 50% процессов. Вот статистика: из среднего времени прохождения задач от начала до конца, бОльшая часть задержек и возвратов работы — на твоем этапе. Такое положение длится уже достаточно долго, так что пора с этим что-то делать. Предложи план улучшений, с тем чтобы за 2-3 недели положение выправить, либо нам с тобой придется расстаться, как бы это ни было больно для нас и для тебя”. На практике создание такого ощущения опасности расшевелит даже самые “трудоподъемных” товарищей. Ну а если нет — то надо ли нам с ним продолжать работать?
И повторюсь, что в самом начале следует набирать команду из людей, которые изначально настроены на самоорганизацию.
Илья: Возможно ли научиться Agile самому? Какую литературу ты можешь посоветовать почитать?
Василий: Есть книга на русском языке от основателя Scrum Джефф Сазерленда “Scrum. Революционный метод управления проектами”. Это книга, которая даст необходимую базу. На русском языке, к сожалению, совершенно не правильно перевели название, так как на английском она называется “Как делать в два раза больше вещей за меньшее время”.
Для формирования команды, я всем рекомендую книгу “Пять пороков команды” Патрика Ленсиони, а также “Одноминутный менеджер и обезьяны” Кена Бланшара. Первая книга о том, что такое вообще команда и что нужно сделать, чтобы она появилась, а вторая о том, как через вопросы развивать в участниках команды самостоятельность и самоорганизацию.
Илья: Василий, спасибо за столь развёрнутые ответы!
Подписчикам: если вам интересен Agile, оставляйте ваши комментарии. Василий будет отвечать на них по мере возможности и наличия свободного времени.
Сегодня у нас на связи agile-коуч Василий Савунов. Немного поговорим об организации работы команды по системе Scrum, а также получим ценные рекомендации по обучению Scrum и Kanban.
Интервьюер — Илья Дзенски, фрилансер, UX/UI дизайнер, адепт Agile.
Илья: Привет, Василий!
Василий: Привет!
Илья: Давай разберёмся в терминах. Если читать статьи в интернете, например статью на Rusbase, то можно запутаться в терминологии. Одни эксперты говорят, что Kanban и Scrum — это что-то из Agile, а другие говорят что Kanban, Scrum, Agile — это три разные вещи, каждую из которых нужно применять в нужное время и место. Кто из них прав?
Василий: Не смотря на то, что Agile проник в Россию относительно давно (первые тренинги по Agile начались где-то в 2007 году), настоящих экспертов по нему не так уж много. Поэтому путаница в терминах до сих пор существует. Когда мы говорим об Agile, мы имеем в виду 4 ценности из Agile-манифеста:
- люди и взаимодействие важнее процессов и инструментов;
- работающий продукт важнее исчерпывающей документации;
- сотрудничество с заказчиком важнее согласования условий контракта;
- готовность к изменениям важнее следования первоначальному плану.
Эти 4 ценности дополняются 12-ми принципами, и всё это вместе называется Agile. Если проводить аналогию, Agile — это как Конституция, она не очень конкретна, но даёт общее направление и концепцию. А Scrum, Feature Driven Development, экстремальное программирование и остальное — это конкретные реализации Agile. Если брать наш пример выше, то Scrum — это закон, который реализует конституцию в виде мероприятий, ролей и артефактов.
Agile — это как зонтичный бренд над agile-подходами и методологиями, которые я назвал выше. И этих инструментов значительно больше. Scrum выиграл маркетинговую войну из-за своей внешней простоты и чаще остальных методологий применяется в компаниях. Но внешняя простота обманчива — в Scrum достаточно много нюансов.
Илья: Ты сказал о том, что у Agile есть 4 ценности. Если я их выполняю, но при этом не использую ни одну из методологий, и у меня нет команды, то выходит, что Agile работает даже с одним человеком?
Василий: Да, Agile-философия может работать с одним человеком.
Но весь дьявол кроется в том, что когда нас становится больше чем один человек (это и заказчик, и исполнитель, и эксперт в своей области), то нам нужно понять и решить, как мы конкретно будем реализовывать Agile. Все методологии, тот же Scrum, пытаются навести в этом порядок. Он говорит: “Вот вам ряд действий и правил. Если вы эти правила и действия соблюдаете, то вы гарантированно Agile. У вас все 4 ценности будут выполняться. Но если вы хоть что-то из этого нарушаете, например, перестаёте проводить ретроспективы, то у вас начинает теряться обратная связь, вы останавливаетесь в бизнес-процессах, и необходимой гибкости так и не достигнете”.
Отвечая на твой вопрос: да, Agile может работать с одним человеком, но изначально он был придуман для команд, чтобы они могли работать в одном ключе.
Илья: Какое оптимальное количество scrum-команд и участников в командах может быть?
Из классического менеджмента известно, что есть определённый операционный максимум. Это количество людей, которыми можно руководить без потери контекста и без потерь коммуникации между ними. Считается, что это 7+-2 человека. Максимум — 9. Только очень талантливый руководитель может ими управлять и быть в контексте, что у них происходит. Если мы выходим за это количество, то начинается дробление на подгруппы, и это дробление происходит естественно. Если команда значительно больше по количеству людей, то начинается начинается существенная потеря и искажение информации при её передаче между участники.
Что касается количества команд. Выделенный Scrum-мастер может успешно вести 3-5 команд. Больше 5 команд одному Scrum-мастеру вести очень сложно: надо быть в контексте всех их проблем, успевать на все мероприятия (планирование, дейли митинг, ретроспектива, демонстрация) во всех командах. Ну и конечно, хорошему Scrum-мастеру нужно понимать профессиональный и технический контекст того, что делают команды.
Задача выделенного Scrum-мастера заключается не в том, чтобы быть незаменимым человеком, обладающим уникальными знаниями и навыками, а в том, чтобы внутри этих самых команд найти или вырастить людей, которым интересно заниматься подобной организационной работой, и способствовать росту эффективности своих команд. Scrum-мастер должен как можно больше передавать своих полномочий и организационных вопросов внутри команд, чтобы повысить устойчивость и стабильность организаций в целом. Тогда необходимость в выделенном Scrum-мастере отпадает, и эту роль может взять кто-то из команды.
Если этого не происходит, то появляется так называемый “bus-фактор”, или “автобусный фактор”. Это несколько шутливый термин, но в нём очень много правды. Звучит он так: “Сколько человек в вашей команде должно быть сбито автобусом, чтобы проект встал?”. Соответственно, чем меньше это число, тем хуже для вас. Если это один человек, то в случае если он заболеет, уволится, или его (не дай Бог) собьет автобус, то команда не сможет двигаться дальше из-за потери уникальной компетенции, проект остановится, или даже “умрет”.
Есть и более изощренные и сложные способы организовать работу по Scrum на большом количестве команд. Для этого существуют процессные фреймворки масштабирования Scrum, такие как LeSS и SAFe.
Классический LeSS, позволяет работать по Scrum до 8 команд. Если у нас появляется больше команд, то применяется Huge LeSS.
SAFe помогает работать на еще больших масштабах: 500-2000 человек. К примеру, “Сбербанк” использует SAFe. Система очень сложная, и не берусь рассказать это в интервью. Есть целый портал, посвященный тому, как его применять: www.scaledagileframework.com
Илья: Как стать “командой мечты”?
Василий: Начну с того, что Agile и Scrum не для всех. Он — для тех, кто умеет думать головой, кто хочет понимать и готов вникать в бизнес-процессы и бизнес-логику. И точно не для тех, кто работает с 9 до 18:00 и только по чёткому ТЗ.
Поясню, почему это так.
Одна из ценностей Agile звучит так: “взаимодействие с заказчиком важнее согласований условий контракта”. Контрактом в данном случае считается и техническое задание тоже. Программисты — люди квалифицированные, и очень хорошо умеют манипулировать контрактом. Нередки случаи, когда при сдаче проекта заказчик спрашивает: “А почему вы не сделали вот эту функцию? Она сюда напрашивалась сама собой”. На что программисты отвечают: “Этого не было в ТЗ. Не написали — не сделано. В следующий раз пишите”. Потому что ТЗ — это контракт.
Заказчик может спросить: “А поговорить?“, на что программисты говорят: “А за разговоры нам денег не платят”. И начинается “битва за контракт”, когда программисты требуют все более подробное ТЗ, а потом интерпретируют его в свою пользу. В свою очередь, заказчик может вписать в ТЗ какое-то требование, которое трудно осуществимо, но раз есть в ТЗ, а это контракт, то начинается “выкручивание рук” программистам, что это требование должно быть сделано.
Мы бьемся вокруг формулировок, а продукт при этом страдает.
Поэтому Agile прямо декларирует: сперва поговорите, обсудите вместе нюансы с заказчиком, а потом уже фиксируйте договоренности на бумаге. Не наоборот.
По поводу этапов формирования “команды мечты”. У каждой команды будут определённые этапы, которые они будут проходить. Эти этапы хорошо описываются в так называемой модели Брюса Такмана.
Первый этап называется “форминг” (forming), когда люди знакомятся между собой, эффективность команд не очень высокая, но и конфликтов особо нет.
Вторая стадия это “шторминг” (storming), когда люди чуть-чуть друг друга узнают, но не достаточно, чтобы сработаться, а им вместе уже надо выполнять какое-то сложное задание. Начинаются конфликты, обиды, и деление на подгруппы.
Именно поэтому в Scrum предусмотрена роль Scrum-мастера. Он должен знать и уметь управлять этой динамикой и помочь группе пройти сложный этап “шторминга”. Для этого он должен уметь грамотно организовывать обсуждения (фасилитация), разрешать конфликты, поддерживать, подбадривать, и помогать команде сработаться, чтобы она могла перейти на следующий этап развития — “норминг” (norming).
На этапе “норминга” (norming) команда уже разрешала основные конфликты, участники команды поняли, кто и чего стоит, как лучше взаимодействовать между собой, выделяются лидеры и отпадают слабые звенья.
Если Scrum-мастер человек умный, то он будет вскрывать конфликты внутри команды, и организует конструктивный поиск решений, с тем чтобы участники команды учились договариваться и налаживать контакты друг с другом. Постепенно команда становится все более устойчивой, за счет обмена опытом и готовности подменить или помочь друг друга ради достижения общей цели. В итоге, выбывание отдельных участников из команды становится не столько критичным. Появляется синергия, взаимодополнение, когда каждый участник команды знает тонкости работы своего коллеги и в случае его отсутствия, может в какой-то степени выполнить часть работы за него, с тем чтобы движение к цели не останавливалось.
Финальная стадия развития команды — это перформинг, когда люди сработались, они замотивированы, они профессионалы, и выходят на максимум своей производительности.
Илья: Представим, что у одного Scrum-мастера в “ведении” находится 5 команд, он проводит встречи, ретроперспективы, и другие мероприятия. Может ли Scrum-мастер совмещать несколько должностей и функций (то есть быть, например, программистом), или это нежелательно?
Василий: Хороший вопрос. Если это локальный мастер внутри одной команды, то тогда совмещение — это хорошо и правильно.
Scrum-мастер — это не должность, это роль. Её может выполнять любой доброволец, который на себя её возьмет. Я знаю позитивные примеры, когда роль Scrum-мастера в команде переходящая. В один спринт работает один скрам-мастер, в другой спринт — другой. Это очень способствует сплочению команды и уважение к этой роли. В этом смысле локальный скрам-мастер и должен быть членом команды.
Крайне не рекомендуется совмещать роль product owner’a и scrum-мастера, так как у них совершенно разные фокусы. У Product owner’a фокус на продукт, а не на людях, а у Scrum-мастера совершенно наоборот. Если эти две роли совместить в одном человеке, получится внутренний конфликт интересов, который очень тяжело разрешить гармонично.
Если Scrum-мастер специально выделен на несколько команд, то совмещать ещё и рабочую должность внутри какой-то из команд для него будет практически не реально. У него просто не будет времени заниматься ничем, кроме организационной деятельности.
Илья: Насколько сложнее организовать удалённую команду, когда участники команды находятся по всей стране или в разных странах?
Василий: Будем честными, Agile довольно тяжело работает в условиях распределённости людей. В моей практике были случаи, когда распредёленная команда смогла найти в себе силы самоорганизоваться. В общем случае это работает только тогда, когда эти люди с регулярностью хотя бы 1-2 месяца встречаются и вместе работают. Иначе не возникает “чувства локтя”.
37 Signals (ныне Basecamp) были первыми кто внедрил удаленную работу. У них не было офисов. На тот момент это было трендом. Есть даже книга Remote, где говорится, что не надо держать офисы, все могут быть в разных странах и городах мира. Но в последнее время жизнь показывает, что это неэффективно. И Nokia, и Apple, сейчас собирают команды локально: перевозят своих сотрудников в офисы, чтобы все сидели рядом и видели друг друга.
Психологически собеседник в Skype или мессенджере воспринимается как картинка на экране. Нет ощущения что ты живой человек, что я за тебя несу ответственность. В интернете можно не ответить сразу на вопрос собеседника, а вот ты попробуй не ответить сразу, если человек прямо перед тобой сидит и тебе задаёт вопрос. Личное общение лицом к лицу, вживую, создает чувство сопричастности, а общение через интернет — нет.
У меня был прецедент, когда мы работали с двумя частями одной команды — одна часть находилась в Москве, а вторая в Ростове. Мы привозили их раз в полтора месяца в Москву, и они по 2 недели работали в одном офисе с московскими коллегами, вместе решали задачи, проводили демонстрации и тд. В результате это дало очень важный эффект: исчезло колоссальное количество конфликтов и недопонимания. Люди действительно почувствовали себя командой. И даже когда они вернулись к себе обратно в разные города, чувство общности сохранялось. Ведь одно дело когда ты общаешься с каким-нибудь “Петей” в чатике, и можешь злится на него, что вот он там “ничего не понимает” или “долго отвечает”, а совсем другое — когда ты этого “Петю” увидел вживую, пообщался, порешал вместе с ним задачи. И после этого в случае недопонимания, ты просто думаешь “Да нормально все, Петя хороший парень, просто что-то мы в чатике запутались. Сейчас я ему позвоню и все быстро решим”.
Стив Макконел ввёл понятие периода полураспада доверия. К примеру, если мы с тобой познакомились, пообщались, а потом полтора месяца не общались, не переписывались и вообще никак не контактировали: ни в мессенджере, ни по телефону, ни по e-mail, то нам с тобой по-новой надо будет знакомиться, так как исчезнет ощущение что мы свои люди, и в распределенных командах это работает точно так же.
Залогом качественной удаленной работы может быть выстроенный процесс синхронизации, и нужно приложить довольно много усилий, чтобы это произошло.
Очень важно понимать, что наличие взаимной ответственности не возникнет, если не будет ощущения опасности. Опасности такого рода: если мы сейчас не договоримся, то позже лажанем так, что плохо станет всем. В Scrum это ощущение создается через демонстрации результата командой заказчику. Если это организовать правильно, то даже в распределенных командах возникнет ощущение, что мы все “в одной лодке”. Даже если ты находишься в другом городе, вполне может возникнуть ситуация, когда именно ты, удаленно, должен будешь продемонстрировать заказчику результат работы команды, и ответить на все вопросы. Вот тут начинаешь живо интересоваться — а кто что сделал? А все ли готово? А тестовый стенд точно работает? А какие средства связи? И тд.
Распределенная команда очень сильно снижает чувство локтя, и требует колоссальных усилий от Scrum-мастера. Но при наличии сильного Scrum-мастера, возможно всё.
Илья: Что тогда делать удалённым командам? Пытаться внедрять Agile или отойти от него, и обратить внимание на какую-то другую методологию?
Василий: Внедрить Agile в удалённой команде возможно, хоть и эффективность её будет значительно ниже. Самая большая проблема удалённых команд — взаимопонимание.
Самое худшее взаимопонимание происходит между людьми, когда они общаются через e-mail, чуть лучше — аудио (по телефону). Идеальный вариант — это общение у доски, когда мы можем говорить и рисовать.
Удалённым командам я рекомендую начать с Kanban, когда мы сперва выстраиваем абсолютная прозрачность нашей работы по этапам, чёткие и ясные приоритеты, видны ограничения команды. Мы начинаем понимать наши Wip-лимиты (ограничения Work in progress — работы в процессе). Мы приучаемся к тому, что важнее завершать начатое, а не начинать новое. Ведь если мы много начинаем делать, но мало заканчиваем, то по сути — “закапываем“ кучу денег “в землю”. Нам нужно как можно быстрее проводить задачки от возникновения, до выкладки на production-сервер. И для этого нужны усилия всей команды.
Когда мы таким образом, выстроим хороший рабочий процесс, мы начнём упираться во взаимодействие людей, и их взаимопонимание. И вот здесь можно начинать задумываться о Scrum.
Канбан и Scrum друг другу не противоречат. Канбан может быть “наложен” на Scrum, эти вещи взаимодополняют друг друга, хоть цели у них разные.
Илья: Представим не редкую ситуацию, когда в удалённую команду внедрён Канбан, но один из участников постоянно тормозит процесс. Что делать с этим человеком: мотивировать или увольнять?
Василий: Тут выход только один. Надо создать человеку должное ощущение опасности.
Другими словами, так как в Канбан мы работаем совершенно прозрачно, и есть статистика работы, то возможен такой диалог с этим человеком: “Смотри, на тебе зависают 50% процессов. Вот статистика: из среднего времени прохождения задач от начала до конца, бОльшая часть задержек и возвратов работы — на твоем этапе. Такое положение длится уже достаточно долго, так что пора с этим что-то делать. Предложи план улучшений, с тем чтобы за 2-3 недели положение выправить, либо нам с тобой придется расстаться, как бы это ни было больно для нас и для тебя”. На практике создание такого ощущения опасности расшевелит даже самые “трудоподъемных” товарищей. Ну а если нет — то надо ли нам с ним продолжать работать?
И повторюсь, что в самом начале следует набирать команду из людей, которые изначально настроены на самоорганизацию.
Илья: Возможно ли научиться Agile самому? Какую литературу ты можешь посоветовать почитать?
Василий: Есть книга на русском языке от основателя Scrum Джефф Сазерленда “Scrum. Революционный метод управления проектами”. Это книга, которая даст необходимую базу. На русском языке, к сожалению, совершенно не правильно перевели название, так как на английском она называется “Как делать в два раза больше вещей за меньшее время”.
Для формирования команды, я всем рекомендую книгу “Пять пороков команды” Патрика Ленсиони, а также “Одноминутный менеджер и обезьяны” Кена Бланшара. Первая книга о том, что такое вообще команда и что нужно сделать, чтобы она появилась, а вторая о том, как через вопросы развивать в участниках команды самостоятельность и самоорганизацию.
Илья: Василий, спасибо за столь развёрнутые ответы!
Подписчикам: если вам интересен Agile, оставляйте ваши комментарии. Василий будет отвечать на них по мере возможности и наличия свободного времени.
