2 заметки с тегом

scrum-master

Инструмент «Паутинка» для оценки событий Scrum

Порой Scrum-мастер задаётся вопросом: «Хорошо ли у нас проходят события Scrum?» однако, не может найти подходящий инструмент.

Инструмент «Паутинка» позволит команде на ретроспективе оценить события и совместно разработать план по улучшению.

Инструмент состоит из 3-х частей:
I часть — выравнивание критериев оценки с командой, что для команды 1, а что 5
II часть — совместная оценка событий участниками команды
III часть — сведение полученных оценок и разработка плана по улучшению

I. Выравнивание критериев оценки с командой

Подготовка: флипчарт с нарисованной шкалой оценки от 1 до 5

Команда и Scrum-мастер пишут на стикерах, что для них оценка «1», а что оценка «5».
Например:
«1» — нет цели/регулярное опоздание участников/плавающие события (в разное время)/отсутствие участников без уважительной причины;
«2» — тайминг не соблюдён/цель не досигнута/отсутствие участников без уважительной причины;
«3» — тайминг соблюдён/цель достигнута;
«4» — всё хорошо, фасилитирует Scrum-мастер;
«5» — команда всё делает сама, Scrum-мастер фасилитирует только ретроспективу

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

II. Совместная оценка событий участниками команды

Подготовка: флипчарт с матрицей событий

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

  • DSM (или Stand-up);
  • Планирование;
  • PBR (согласно Scrum guide не является отдельным событием, однако эта активность крайне важна для команды)
  • Обзор спринта
  • Ретроспектива
  • Спринт (как в целом команда оценивает достижение цели спринта, дополнительно можно включить оценку выполнения роли Владелец продукта и Scrum-мастер)

После того, как все наклеили, Scrum-мастер считает среднюю по каждой ячейке.
Оценки Scrum-мастера не учитываются при подсчёте средней они потребуются немного позже.

III часть — сведение полученных оценок и разработка плана по улучшению

Подготовка: флипчарт с паутинкой

На соответствующие оси «Паутинки» наносим разными цветами оценку команды и Scrum-мастера (см. картинку)

Расхождение линий оценки Scrum-мастера и команды — это фокус внимания для Scrum-мастера по тому, как он видит работу внутри команды.

Scrum-мастер фокусирует внимание команды на события, которые получили наименьшую оценку от команды и просит их написать на стикерах ответ на вопрос: «Что нам нужно сделать, чтобы данное событие улучшилось?»

Далее команда голосует точками за улучшение, выбирает ТОП3 для реализации и создаёт «план действий» 

10 Практических советов как стать хорошим скрам-мастером

1. Никогда не принимай решения за команду, не спросив её

Как у скрам-мастера команды, у тебя нет права (власти) принимать от имени команды запросы на изменения (неважно насколько они малы).  Даже если ты абсолютно уверен, что команда справится с этим изменением, ты должен сказать: «Мне нужно обсудить это с командой, прежде чем мы скажем ‘да’»

И конечно же не подписывай команду ни под какие дэдлайны, или что-либо ещё, не пообщавшись сначала с ней (командой). Возможно, тебе не надо говорить со всей командой — для ряда команд достаточно, чтобы часть сказала «да, мы можем это сделать», для ряда команд нужно, чтобы сказали все, без общего собрания.
Но это всё же будет их решение, не скрам-мастера

2. Помни, что ты там, чтобы помочь команде стать лучше

Быть скрам-мастером не про то, чтобы самому стать лучше.
Ты становишься лучше, когда команда становится лучше.
Команда становится лучше, когда делает отличную работу

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

3. Не бей команду по голове книгой с правилами agile

Ни Scrum, ни agile не пришли к нам с книгой правил (несмотря на то, что некоторые пытались её создать)
Если у продукта есть клиент, следует подумать о написании пользовательских историй (user stories), но истории не являются требованиями в agile. Если кому-то необходимо знать, когда будет поставлен продукт — оценивайте, если такой необходимости нет, возможно, и оценка не нужна. Если вам кажется, что обратная связь в конце спринта — это уже поздно, делайте обзоры в то время, как фича сделана.

Быть agile означает соблюдать принципы и ценности, которые лежат в основе agility. Если команда остается верной принципам и ценностям, она не собьется сильно с пути, несмотря на то, что ей говорят другие

4. Ничто не постоянно, поэтому экспериментируй со своим процессом

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

5. Убедись, что команда и стейкхолдеры относятся друг к другу как к равным

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

6. Защищай команду, включая те способы, о которых ты даже и не думал

Возможно, наиболее частый agile-совет — этот тот, что скрам-мастер должен защищать команду от слишком требовательного Владельца продукта или стейкхолдеров. И это хороший совет.
Иногда Владельцы продукта «просят» слишком много, слишком часто и слишком требовательно. Это вынуждает команды ускоряться, чаще всего жертвуя качеством, что позже отразится на продукте. Поэтому хороший скрам-мастер защищает команду от этого.

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

7. Запрети себе использовать слово «провал»

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

8. Хвали чаще, но всегда искренне

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

9. Поощряй команду, если она начала делать твою работу

Команда, для которой agile в новинку, будет в значительной степени полагаться на своего скрам-мастера или agile-коуча. Такая команда может не знать как уложиться в 15 минут на ежедневном скрам митинге (прим. ежедневном стэндапе). Или она может не понимать важности параллельной работы или необходимости быть кросс-функциональной.

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

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

Независимо от того, насколько хороша agile-команда, она получает пользу, от того, что у неё есть cкрам-мастер или agile-коуч. Однако, хорошие agile-команды сами берут на себя некоторые простые коучинговые задачи для освоения навыков, необходимых им в продуктовой разработке.

10. Молчи и слушай

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

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

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

Текст адаптирован с оригинальной статьи:  https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need