Историй много, а вот заметок с какими трудностями они сталкивались - мало. Об эпичных и не очень провалах я вообще молчу - фрезировщик на заводе может по пальцам своей руки их посчитать.
Вот почему? Это же самое ценное и крутое пособие по тому, как реагировать на трудности и какие уроки выносить из своих фейлов! Как раз то, чего не хватает еще зеленым начинающим скрам мастерам.
Когда я только стояла в начале пути неординарного и смелого скрам мастера, где-то на уровне подсознания я понимала, что этот путь не будет безмятежной прогулкой по прекрасному саду, но и подумать не могла, что этот сад будет с разбросанными повсюду граблями. И я, конечно же, наступила на все.
Итак,
Грабли №1. Не бойся задавать вопросы
Даже если они, по мнению других, (твоей команды, коллег - скрам мастеров) тупые. Даже если с 1го, 2го...n-го раза не понимаешь. Поверь, лучше спросить, чем додумать самому и потом сидеть со всей командой и обсуждать, как же такая дичь могла случиться.
Пример: В какой день недели лучше проводить ревью? А в какое время дня? (да-да! Вот прям так детально) А как вы понимаете, что вы именно канбан-команда? А что вы ожидаете от скрам-мастера? А как у вас раньше ретро проходили? А как у остальных команд проходит ревью? А что делают другие скрам-мастера, если их команда...? (боже, мне сейчас кажется, что я тогда всех просто достала своими непрекращающимися вопросами!)
Как быть: прими тот факт, что это нормальный рабочий процесс и он обязателен. Чем больше вопросов вначале, тем легче работать потом.
Грабли №2. Есть что-то ясно тебе, это не значит, что и вся команда понимает
О, да я очевиднее, чем кэп.
Пример: для меня вполне очевидно, что для нового члена нашей команды нужен некий общий обзон технологий, которыми владеет команда (даже если наш "новичок" на самом деле сеньор, даже если он с ними знаком). Для меня ясно, а вот моя команда искренне удивилась: "зачем?".
Как быть: только не будь душной занудой и избавь свою команду от длинных лекций. Озвучь свое мнение и спроси, а чего им не хватало, когда они начинали работу.
Грабли №3. Чем сеньорнее команда, тем более постепенно и с меньшим фанатизмом нужно вносить изменения
Один из моих любимых пунктов. Такая простая истина позналась только эмпирическим путем.
Пример: только представьте: приходит зеленый скрам мастер в систем тим (ох уж этот SAFe), где сидят матерые мужики (простите за сексизм) в составе архитекторов, конфиг-менеджеров и автоматизатора и говорит: "ребята, я тут методичку прочитала на 16 страниц, сертификат получила, сейчас я буду вам рассказывать, как нужно выстраивать скрам/канбан процесс". Реально?? Можно было просто сказать "вы тупые, работали столько лет неправильно, а я умная, сейчас вас научу". Я была бы послана обратно со скоростью пули.
Как быть: проще всего - спрашивать, что каждый из них думает по конкретному изменению. Не приносить изменение, а именно спрашивать их мнение.
Грабли №4. Все в меру, шаг за шагом - не бросаться сразу с кучей процессных изменений
Скорее, продолжение предыдущего пункта, но без него никак.
Пример:
СМ: "нам нужны дейли"
Команда: "фу, снова эти бесполезные скрам-митинги (я удивляюсь, как же канбан-команды ненавидят все, что связано со скрамом, даже если дейли есть и там, и там, все равно фу).
СМ: а как нам общаться?
Команда: ну давайте в чате отписываться.
СМ: если вы считаете, что это эффективно, то давайте попробуем.
Команда: давайте созваниваться и голосом обсуждать, так проще и быстрее.
СМ: то есть дейли?
Команда: окей, пусть это будет называться дейли. Но если нам не понравится, мы отменим.
СМ: конечно-конечно!
Как быть: иногда, чтобы какие-то изменения произошли, нужно дать команде время самой их захотеть. Дайте команде время.
Грабли №5. Слушать команду
Она реально лучше знает, как надо.
Пример: команда должна проводить рефайнмент сессии и оценивать скоуп своих задач. Классно звучит, но мы некоторые задачи не можем оценить и не делаем этого. Вот как можно оценить саппорт скрам-команды, когда она переходит....ну пусть на java 14? Или как можно оценить РоС? А совместный рефакторинг архитектора и команды?
Как быть: методички - класс, их писали не идиоты. Но всегда задавайте вопрос "а что для нас важно: следовать процессу или делать качество?"
Не пытайтесь повторить.
Грабли №6. Не бояться выглядеть некомпетентным в чем-либо
Даже если эта задача - твоя ответственность.
Пример: моя обязанность как скрам-мастера - мигрировать все jira задачи в Miro для PI Planning. У меня были вполне рабочие фильтры для такой задачи. И однажды я пожаловалась своей команде, что это тупая рутинная задача (monkey job) и отнимает слишком много времени. Ребята глянули на мой запрос, поправили, и теперь я трачу считанные минуты на подготовку задач в Miro.
Или другой пример: моя команда предложила проводить дейли для архитекторской и СМ-ской частей отдельно (на это есть реально объективные причины). Встал вопрос, а как оптимизировать jira-доску. У меня были свои идеи, которые я показала команде. Они сами адаптировали эти доски под себя и визуализировать весь рабочий процесс стало намного удобнее.
Как быть: даже если ты не знаешь как делать, покажи команде хоть какой-то результат (даже если это грубый макет, это все же лучше, чем "нуу....я не знаю как это делать" и не принести ничего). Ты всегда получишь обратную связь по улучшениям.
Грабли №7. Всегда озвучивать структуру митинга
Даже если он уже 100-тый на вашем счету.
Пример: не все участники совещания могут прийти подготовленные, не каждый может перед началом звонка прочитать агенду (но все равно писать ее нужно! Всегда!). Из-за этого кто-то может молчать и долго вникать, о чем речь, кто-то может сразу начать предлагать свои решения без обсуждений или все участники могут подключиться, молчать и чего-то ждать. Уверена, с таким сталкивался каждый организатор встреч.
Как быть: не поленись озвучить цель вашего совещания, пройтись по агенде и ожиданиям по окончанию. Поверь, тебе никто не скажет "да мы и так прекрасно знаем, зачем мы собрались". Мне ни разу не сказали))
Грабли №8. Не стесняться заимствовать идеи других команд
Наивно полагать, что ты единственный, кто фонтанирует идеями, поэтому совершенно нормально чьи-то практики использовать самому.
Пример: я часто спрашивала своих коллег и ментора, как они выравнивали дискуссии (чтобы говорил не один участник только). Что-то из их техник я уже пробовала, но мне не подошло, а что-то было "о, прикольно, я попробую".
Как быть: если понимаешь, что твоих навыков недостаточно - обратись за советом или попроси поделиться опытом. Пополняй свою копилку знаний.
Грабли №9. Понимать, когда команда просто хочет пожаловаться в космос, а когда у них реально болит и нужно что-то делать
Пример: на первых порах я с рвением пыталась решить все, что команда высказывала на ретро. А как иначе, это же Impediment! А классный скрам-мастер должен их устранять.
Вот только есть разница между "Provider X does not officially provide required tooling for… и меня это бесит" (что мы в ближайшем будущем не можем изменить) и "current approach…. is not appropriate" ( где команда набросала целый план действий для решения этой проблемы).
Как быть: не принимать каждое непозитивное высказывание как проблему и больше спрашивать команду, что (не конкретно скрам мастер) можно сделать, чтобы болело меньше.
Грабли №10. Научись принимать фидбэк
Скажу честно, я до сих пор не овладела этим умением в совершенстве.
Пример: когда мне кто-нибудь говорит, что я как скрам-мастер не совсем компетентна и у меня проблемы тут, тут и вооон там еще ("ох, ну спасибо большое, что держишь руку на пульсе за меня и всегда готов(а) подсветить и без того ослепительную проблему").
Как быть: самый крутой фидбэк для меня - это фидбэк, после которого хочется захлопнуть ноут, собрать вещички и уйти с позиции, потому что чувствуешь себя еще настолько неопытным! Но это первая реакция, не стоит ее пугаться. На самом деле тебе показали, куда еще нужно расти и что нужно прокачивать - это определенно поможет стать круче.
И в заключении:
Пробежавшись по всем этим пунктам, становится чуть понятнее, что работа скрам-мастера более осязаема, чем кажется на первый взгляд. Ну или можно сделать вывод, что все скрам-мастера - недалекие люди, раз задают вопросы, ответы на которые очевидны. К какому выводу бы ты не пришел - эти выводы имеют место быть.
Delion
Таки а что есть "скрам"?
Teleliukhina Автор
Скрам - это фреймворк, который используют для комплексного управления процессом разработки продукта