Перезапуск scrum в командах ч.2

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

Немного предыстории

Команда была очень большая 12 человек, целый мини-бизнес, который существовал длительное время самостоятельно, но не приносил заработка. Соответственно, этим были не довольны. Команду было решено перевести на рельсы scrum. Это уже сейчас я понимаю, что на самом деле, вопросов в скорости доставки новых фич не стояло, а проблемы были с бизнес моделью.

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

У команды сложилась стойкая аллергия на любое упоминание “Agile” и “Scrum”, они не хотели так работать и их можно было понять! Мы поменяли мастера, им стала я, и владельца продукта, когда осознали все произошедшее. Новый владелец свежим взглядом оценил все происходящее, сменил бизнес-модель, что потребовало изменения продукта. Теперь, можно запускать настоящий scrum 🙂

Спустя 3 спринта мы поняли, что бизнес-модель не стреляет и провели мозговой штурм, что можно еще делать, используя уже разработанные кишочки дабы наработки не пропали. Появились кучи идей и над многими мы тогда, честно признаться, ржали, как кони 🙂

Так как команда большая и дорогая, мы отправили владельца думать, а сами встали на другой продукт. Часть команды распределили по другим продуктам и стали более маленькими и маневренными – 6 человек.

Когда наш владелец продукта был готов, мы перезапустились и полетели! Давайте теперь посмотрим на все, что способствовало удачному перезапуску.

Продукт

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

У нас появилось видение продукта, как он будет развиваться, какие фичи от релиза к релизу в нем будут появляться и когда эти релизы запланированы.

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

Раньше на обзор спринта приходили только внутренние заказчики, теперь, стали приходить реальные клиенты, готовые купить определенную партию и ждущие ее.

Работа с помехами

Картинки по запросу пробка

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

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

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

Картинки по запросу паразит

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

Когда команда начала меняться, у них начали появляться приоритеты и свои ценности, паразитация стала очевидна. Дело осталось за малым, правильно все сделать и помочь 🙂

Симбиоз

Картинки по запросу симбиоз

Итак, у нас есть люди и эти люди производят продукт. Важно не только наличие актуального и нужного продукта, но и соблюсти баланс, чтобы люди развивались о создание подобного продукта. Согласитесь, когда ты делаешь в сотый раз одно и то же, становится уже не интересно и скучно?

Картинки по запросу поток состояние

Здесь появляется еще одна интересная фишка, если продукт у нас сложный, но не настолько, что является невыполнимым, люди не просто получают кучу опыта при его создании. Они находятся в состоянии потока, который приносит колоссальную кучу удовлетворения от самого процесса создания. Это финальный штрих, который продвинет вашу команду до нужной производительности 🙂

Поэтому не бойтесь заходить в команды, у которых аллергия на Agile и Scrum, это вызов и это интересно. Кстати, похоже, совсем скоро мне это предстоит вновь.

Перезапуск Scrum в командах ч.1

С тех пор, как кто-то произнес фразу “перезапустить scrum в командах”, я не перестаю думать о ней. И правда, сложности есть и они возникают у всех, не только у нас, но и в ИТ. Хотя там применять этот фреймворк гораздо проще. Это может выражаться в чем угодно:

  • едкие комментарии “это же scrum…” и смешки
  • игнорирование  обязательных меропреятий
  • издевательства над своим scrum-мастером
  • и т.д.

Причины

Почему так может происходить? Я вижу несколько причин.

  1. В большинстве случаев scrum впихивали насильно, скорее всего, сверху. Это не решение самих работников, а просто к ним однажды пришли и сказали, что теперь будем работать по-новому, не так как раньше. Я недавно писала что заставлять людей что-то делать не несет в себе никакой пользы. Страдает скорость, качество, вовлеченность и нет ответственности. Этим очень сильно страдает классический менеджмент. Здесь ровным счетом то же самое. По-другому еще работать не научились и начинаем запускать новое по-старому и раздавать приказы. Это в некотором роде насилие.
  2. Это могли делать очень неумело люди, которые никогда даже scrum-guide не открывали. Они просто не знают, что мастер должен в том числе и защищать команду. У них нет в голове разницы между мастером и менеджером и они насильно запихивают на каждом планировании задачи в команду, а ретро вообще не проводят.

Как сделать лучше?

Если говорить про пункт 2 и отсутствие нужных специалистов, то нанять их 🙂 Как сделать еще лучше? Чтобы сами команды выбирали себе мастеров.

Картинки по запросу выбор пути

Если говорить про пункт 1, то людям надо объяснять выбор нового направления. Правда очень часто при объяснении мы пропускаем промежуточный шаг и начинаем описывать радужное будущее, не останавливаясь на том, почему дальше жить по-старому нельзя. Это очень важный этап без которого у людей не сложится единая картинка.

Как сделать еще лучше? Вообще в идеале людям надо показать не только критичность текущей ситуации и заложить мысль о том, что нужно что-то менять, но и дать выбор. В этом случае вам нужно доверять команде, потому что выбирать новый способ будет она. Помимо этого, у вас должна быть  достаточно высокая экспертиза, какие подходы/фреймворки/методологии, одним словом инструменты, вам сейчас могут помочь. Нужно честно объяснять плюсы и минусы каждого, нужно честно спрашивать как люди хотят работать.

Но это больше про запуск с нуля. А что если команды же стартованы и все катится в тартарары? Глядя на несчастные команды, которые мне доставались после подобных вещей, это ни к чему хорошему не приводит. Минимум это нейтралитет, бывает и явная агрессия на любое упоминание “Agile” и “Scrum”.

В следующий раз я расскажу что делала для перезапуска Scrum в одной из своих новых команд, у которых был негативный опыт, и в чем моя история успеха 🙂