Главная заповедь scrum мастера

Всем привет! У меня появилась небольшое правило и я хочу им поделиться с вами.

“Каждый день приносить пользу команде, даже если она небольшая”

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

Помимо этого, как следствие, появится прозрачность, т.к. команда сейчас находится в состоянии хаоса и трансформации. Станет понятно, за что отвечает скрам мастер и как может помочь. Так же, когда я пару раз проведу их через процессы командной работы, как повторить это самостоятельно и, таким образом, зрелость команды немного повысится.

Если не делать каждый день маленькую пользу для команд и работать с ними только от ретро к ретро, ничего никуда не сдвинется. Очень быстро все съедут на старые рельсы отсутствия ответственности, не желания работать и двигаться самостоятельно. Люди опять скажут, что ваш Scrum не работает и вообще Agile у нас всегда был 🙂

cf7f964d-dd75-4433-8ebd-6aaaafac3fe2PS: Название заметки у меня родилось в самом ее конце, когда я вспомнила как на тренинге для одной из команд, мы рисовали метафору скрам мастера. Одна команда команда изобразила осьминога, у которого одно щупальце выходило их храма Agile

 

 

3 условия применимости scrum

Совсем недавно я сделала небольшой тренинг для одной команды. Как и везде, здесь есть явные евангелисты, благо хоть открытые 🙂 И на самой первой встрече, перед тем как рассказать про scrum, я собрала с них ожидания от тренинга. Одним из ожиданий у главного евангелиста было – “Какие 3 необходимых условия для внедрения/применимости scrum?”

Вчера я готовилась ко второй части тренинга и мне очень захотелось затронуть эту тему на нём. Но не так, что я встану к доске и начну им рассказывать, а через командную работу, чтобы они сформулировали самостоятельно. Конечно, как и всегда, лучшая импровизация – это заранее подготовленное выступление. Поэтому я решила поразмышлять на эту тему самостоятельно. И вот что родилось у меня.

Сразу оговорюсь, когда я упоминаю scrum, я за ним обязательно подразумеваю agile, а не голый фреймворк, поэтому все, что я скажу ниже, нужно воспринимать только через эту призму. Scrum без agile – деньги на ветер 🙂

Первое

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

Второе

Продукт, как мы знаем, невозможно сделать в одиночку. Нужна команда, но я здесь немного схитрю и в один пункт затолкаю два 🙂 Потому что просто команда условие необходимое, но недостаточное. Для настоящего успеха спец-операции нужна команда, разделяющая agile-принципы или хотя бы не сопротивляющаяся в 99% случаев, а готовая к изменениям.

В целом, не беда, если люди еще не поняли или не определились, разделяют ли они необходимые нам ценности и принципы. Это можно объяснить, привить и развить и это одна из задач скрам-мастеров, просто им будет чуть сложнее.

Забегая немного вперед, все мы с рождения agile, просто со временем обрастаем кучей собственных убеждений, которые мешают нам это понимать 🙂

Третье

Вопрос: сколько нужно agile-коучей, чтобы вкрутить лампочку?

Ответ: ни одного, если нет поддержки сверху

Поддержка сверху это то, без чего точно нельзя запускать scrum. Нет, голый фреймворк, конечно, можно, а вот с надстройкой agile нельзя. Без нее не появится так необходимого команде скрам-мастера, который является проводником agile в организации. Без нее не дадут нужной власти владельцам продукта, они так и останутся аналитиками.

Die_drei_Bogatyr

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

По итогам встречи

039

В результате встречи ребята сами сформулировали 3 пункта и у них получилось почти все то же самое. Первое – команда, второе – продукт. Третий пункт был сформулирован немного иначе, но по моему мнению, пересечение в нем почти на 80%.

Ребята сказали, что нужно доверие, причем не внутри команды (оно уже есть), а сверху, чтобы руководство дало карт-бланш на все, что будет происходить в продуктовых командах.

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

Магия ответственности

На прошлой неделе проводила 4-ёх часовой тренинг про основы Agile и Scrum одной большой команде и начала выбиваться из тайминга. Последний час работы должен был быть посвящен игре LegoScrum для наглядной демонстрации процесса, но к этому моменту нам оставалась еще одна тема про оценку задач в story point. Это всегда воспринимается разработчиками в штыки, потому что они всю жизнь оценивают задачи в часах, и для этого хочется чуть подробней на этом остановиться. Мы договорились уделить этому побольше внимания и поиграть потом.

Объяснила я все достаточно быстро, ответила на вопросы и осталось полчаса чтобы собрать обратную связь и подвести итог встречи. Но тут в голову пришла идея попробовать. Действительно, пробовать нужно, чтобы у людей хоть что-то отложилось в голове.

Тему для оценки я выбрала простую – уборка помещения после тренинга. Просто так, шутки ради, ведь мы все прекрасно представляем, как это делается, и здесь точно нет никаких подводных камней. Ребята нагенерили список необходимых работ ,чтобы выполнить эту “цель спринта” все вместе. Затем выбрали самую простую из них, сравнили с ней остальные, немного подискутировали при оценке и, в принципе, все остались довольны пройденным материалом.

IMG_0418

Потом я закончила тренинг. Мне все похлопали, сказали “спасибо” и тут как по волшебству никто не стал уходить, а все начали прибирать помещение! Я не просила, только и успела, что закинуть свои вещи в тренерский чемоданчик, как помещение было убрано 🙂 Это магия!

Вот что происходит, когда люди выбирают, как им работать. Происходит волшебство!

В поисках работы

Знаю, что со стороны выглядит все так, будто я уже не пишу 3 недели в блог 🙂 Поэтому хочу рассказать, что у меня происходит.

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

Очень жаль, что не так много в Новосибирске, а вернее по пальцам можно пересчитать, компаний, которые реально живут Agile. Но цель поставлена, резюме обновлено уже около полутора месяцев назад. Я хочу задуриться и прям статистику поиска за все это время посмотреть 🙂

И начнем мы с воронки:

  1. Резюме на hh опубликовано у меня уже 1,5 месяца. С тех пор просмотров было 141 штук, из которых уникальных всего 111. То есть одна четверть всех работодателей смотрела мое резюме дважды.
  2. Из этих 111 всего 16% связались и пригласили на собеседование.
    • Если внимательней посмотреть на эти 16%: то 11% нашли меня сами, 5% нашла я без помощи сайта hh через знакомых/twitter/блог. Обязательно ищите сами и не ждите, что на вас обрушится счастье с сайта по поиску работы.
    • Кстати по поводу лучшего варианта для связи я оставляла мобильный телефон, а компании все-равно предпочитали писать. Поэтому обязательно проверяйте свой ящик почаще. Функционалом hh, к слову, они вообще не пользуются, за это время ни один работодатель не откликнулся официально 🙂
  3. Следующий этап выбор компаний для собеседования. Из 16% откликнувшихся я оставила всего 7%.
  4. Само собеседование. Со всеми состоялись, затем повторные, а одним даже тестовое делала.
  5. И сейчас я жду офферов. Три уже получила. Один еще на подходе. То есть конверсия в оффер у меня пока составляет 4% из 111 штук 🙂 И с одними я работаю, как внешний консультант, то есть конверсия еще ниже, меньше 1%.

Три типа компаний

Смотрю на это все и получается забавная статистика, где компании можно разделить условно на:

  1. Ищут не пойми кого, наверное, сами еще не определились
  2. Ищут классического PM-а
  3. Ищут Scrum-мастера/Владельца продукта

Начнем с первых

Они в основном и отсеялись на этапе 3, где я выбирала компании для будущего собеседования 🙂 Как видно, процент очень большой — около половины я отбросила. Почему? Часто складывается ощущение, что девочки-HR даже не читают твое резюме, потому что шлют всякую ересь, например:

хз3
Мое самое любимое предложение

У меня подобных писем штук 5 не меньше. Это и злит, и веселит одновременно, но неудобств не вызывает. Кстати, отвечала я тоже всем — хороший тон. И немного себе приятно сделать, поёрничав 🙂

Вторые

Те, которые ищут PM-ов, тоже проблем не вызывают. Они честно заявляют, что scrum-мастер им не нужен, у них все как обычно.

Радует одно, что ребята давно уже не в каменном веке и чистый водопад у них не используется. Многие, кстати, используют scrum/kanban/scrumban в отрыве от Agile, чисто как инструмент и требуют от своего новоявленного PM-чика проведения ретро, пленнигов и прочего. То есть навыки, в принципе, не пропадают даром. Но ты все-равно перекладываешь с одного места в другое информацию и являешься бутылочным горлышком, а Scrum без Agile, как вы знаете, деньги на ветер.

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

Третьи

Это самая проблемная позиция. Они говорят что им нужен мастер или владелец. И вот так с наскоку, не разговаривая и не вчитываясь в вакансию, не определить, что им на самом деле нужен PM. Реально ищущих Agile-специалистов из них единицы. Даже всем известный Luxoft высылал мне такой текст:

Luxoft scrum master

Не смогла удержаться и ответила им резко и категорично. Во-первых, не методология скрам, а фреймворк. Это две большие разницы и люди, которые с этим работают, должны это понимать. Я думала, что в Luxoft точно должны это знать.

Во-вторых, судя по вакансии, там все смешали в кучу: мед, говно и пчел.

  • Мастер никогда не выстраивал взаимоотношения с клиентами/ежедневные отчеты/управление скоупом проекта — это роль менеджера проектов в классическом подходе либо роль овнера.
  • Мастер никогда не управлял баклогом — это точно роль овнера, мастер может только помогать ему в этом, чтобы он появился, чтобы команде он был понятен.
  • Мастер не апдейтит доски, этим занимается сама команда, а он помогает им в этом.
  • У мастера есть только его команда и процесс, которых он защищает и помогает овнеру заниматься видением продукта и развивать его вместе с командой.

Как меня правильно назвал один человек на собеседовании, я Agile-евангелист, наверное, поэтому я так остро реагирую на «методологию скрам» и все такое.

Кстати, одну реальную вакансию мастера отсеяла, потому что звали в Ульяновск, хотя я рассматривала только Мск и Нск. Ну максимум еще в Казань готова поехать 🙂

Вот и осталось всего 7% тех, кто интересны из 111 штук. Среди них попались и второго типа, и третьего типа компании, и Мск и Нск примерно в равной пропорции. Я думаю, этого достаточно, чтобы сделать свой выбор или просто взять и не работать все лето 😉

Что хочется сказать людям, которые в Agile и планируют менять компанию? Сложно вам будет, только если вы не собираетесь в Мск в ближайшее время. Чем ближе вы живете к Мск, скорее всего, тем больше у вас будет возможностей, я говорю и про Екатеринбург, и про Казань.

А в целом, вот такая выходит забавная аналитика!

xat3yo[1]

О применении инструментов

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

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

анализ конкурентов – инструмент, причем классический маркетинговый, я тут не спорю. график этот – не инструмент))

это какое-то притягивание за уши и попытка показать себя на картинке, отстроенным от конкурентов. тут главней как раз суть – что ты за каждым баллом скрываешь, а не вот эти циферки и кривая

После этого я, конечно, дополнила свою заметку расшифровкой баллов, но сестра продолжила 🙂

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

короче, когда у нас был курс по маркетингу и мы придумывали новый продукт, там все это было – анализ конкурентов и их продуктов и позиционирование своего. без всяких голубых океанов)))

И тут я поняла, что действительно упустила существенную часть объяснения, при каких условиях стоит пользоваться этими инструментами. Ее возмущало не только то, что мы называем новыми словами давно забытое старое, но и то, что мы сильно урезаем классический инструментарий и оставляем только визуализацию и некоторые логические выводы. Для меня такая точка зрения была открытием, но она имеет место быть. Как мы знаем, нет правильного и неправильного.

Собираем пазл

Если взглянуть на мир вокруг, то он очень быстро меняется, по сравнению с тем, что было пол столетия назад. Технологии развиваются стремительно, сегодня становится возможно то, что вчера казалось фантастикой, например, 3D-печать. А многие ли из вас смогли объяснить своим дедушке и бабушке, зачем вы заряжаете электронную бритву, сигарету, 3D-очки и зубную щетку? 🙂

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

Короче мир запутанный, но с этим как раз и научился работать Agile. Этот подход предлагает нам все время держать связь со своим пользователем, чтобы радовать его решениями, которые ему нужны. Но как это сделать? Например, scrum, когда мы что-то делаем 1-4 недели и доставляем это пользователю. Он пробует и дает свои комментарии. Или kanban, когда мы находимся в непрерывном потоке доставки ценности.

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

Теперь оборачиваясь на те инструменты, о которых я планирую рассказать, либо уже это сделала, это все инструменты, которые позволяют быстро, не теряя времени сформулировать некоторое предположение, задать вектор движения и начать делать первые шаги. Если мы этого не сделаем:

  • это сделает конкурент
  • мы можем утопать в свои фантазиях и создавать ненужные продукты

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

А если у вас все еще есть сомнения, пишите!