/ интервью

Интервью с управляющим партнёром ScrumTrek Василием Савуновым об Agile и Scrum

Внимание! Это "режиссёрская" версией интервью с Василием Савуновым с Хабрахабр, но без выпиленных администрацией Хабра ссылок и имен :) Вопросы лучше задавать Василию на Хабре — тут он их не увидит.

Привет, Василий!

Привет!

Давай разберёмся в терминах. Если читать статьи в интернете, например статью на 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. Подробнее можно прочитать тут: https://scrumtrek.ru/blog/less-scrum-na-bolshih-masshtabah/

SAFe помогает работать на еще больших масштабах: 500-2000 человек. К примеру, “Сбербанк” использует SAFe. Система очень сложная, и не берусь рассказать это в интервью. Есть целый портал, посвященный тому, как его применять: https://www.scaledagileframework.com/

Как стать “командой мечты”?

Начну с того, что Agile и Scrum не для всех. Он — для тех, кто умеет думать головой, кто хочет понимать и готов вникать в бизнес-процессы и бизнес-логику. И точно не для тех, кто работает с 9 до 18:00 и только по чёткому ТЗ.

Поясню, почему это так.
Одна из ценностей Agile звучит так: “взаимодействие с заказчиком важнее согласований условий контракта”. Контрактом в данном случае считается и техническое задание тоже. Программисты — люди квалифицированные, и очень хорошо умеют манипулировать контрактом. Нередки случаи, когда при сдаче проекта заказчик спрашивает: “А почему вы не сделали вот эту функцию? Она сюда напрашивалась сама собой”. На что программисты отвечают: “Этого не было в ТЗ. Не написали - не сделано. В следующий раз пишите”. Потому что ТЗ - это контракт.

Заказчик может спросить: “А поговорить?“, на что программисты говорят: “А за разговоры нам денег не платят”. И начинается “битва за контракт”, когда программисты требуют все более подробное ТЗ, а потом интерпретируют его в свою пользу. В свою очередь, заказчик может вписать в ТЗ какое-то требование, которое трудно осуществимо, но раз есть в ТЗ, а это контракт, то начинается “выкручивание рук” программистам, что это требование должно быть сделано.

Мы бьемся вокруг формулировок, а продукт при этом страдает.
Поэтому Agile прямо декларирует: сперва поговорите, обсудите вместе нюансы с заказчиком, а потом уже фиксируйте договоренности на бумаге. Не наоборот.

По поводу этапов формирования “команды мечты”. У каждой команды будут определённые этапы, которые они будут проходить. Эти этапы хорошо описываются в так называемой модели Брюса Такмана.

1

Первый этап называется “форминг” (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-Days, в которой рассказываю о самоорганизации: http://www.authorstream.com/Presentation/babr79-3406788/.

Василий, спасибо за столь развернутые ответы!

Подписывайтесь на канал о фрилансе и продуктивности в Телеграм @ilyadzenski_channel и узнайте первыми, как работать на фрилансе и быть на пике своей производительности. Если ссылка не работает — введите в поиск @ilyadzenski_channel.

comments powered by HyperComments