3 Шага к Эффективной Ретроспективе

Перевод оригинального гайда 3 Steps to Effective Retrospective Джеффа Сазерленда.

Также вы можете скачать статью в формате PDF на русском со страницы "Материалы для скачивания"

ОБНОВЛЕНИЕ ВАШЕЙ РЕТРОСПЕКТИВЫ 

Скрам - простой фреймворк, который состоит из определенных Ролей, Артефактов и Событий. Скрам команды часто используют Ежедневный Скрам, Планирование Спринта и Обзор Спринта, но когда дело доходит до Ретроспективы, то у многих часто возникает вопрос -  а зачем это нужно? Что получит команда от Ретроспективы? Возможно, Ваша Ретроспектива стала неэффективной, поверхностной или скучной. Вместо того, чтобы оставить эту практику, обновите ее. И вот почему.

ПОЧЕМУ РЕСТРОСПЕКТИВА ТАК ВАЖНА?

Как?

Ретроспектива Спринта – возможность инспектировать и адаптировать процесс Команды. Эта встреча ограничивается тремя часами (в зависимости от длины Вашего Спринта) и фасилитируется Скрам Мастером. Она предполагает, что вся команда собирается и обсуждает, каким образом следующий Спринт можно сделать более продуктивным и комфортным, чем предыдущий.

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

Почему?

Существует много техник для эффективного проведения Ретроспектив и книга Аджайл Ретроспективы (Дерби, Ларсен 2006) представляет полезный набора таких практик. Самый простой способ начать обсуждение – нарисовать две колонки на доске с надписями «Что Было Хорошо», «Что Могло Быть Лучше». Затем собранные у команды ответы поместить в соответствующие колонки. После пусть Команда найдет причины возникновения проблем и выделит одно улучшение на следующий Спринт со встроенным приемочным тестом и обязательством проверить результаты на следующей Ретроспективе.

ПОЧЕМУ РЕТРОСПЕКТИВА НЕ РАБОТАЕТ?

Со временем некоторые практики Скрама начинают игнорироваться или становиться поверхностными и малоэффективными. Давайте взглянем на наиболее частые оправдания, из-за которых Ретроспективы становятся неэффективными.

Наиболее распространенные оправдания

«Команда считает, что это трата времени».

«Ретроспективы не нужны, потому что у команды нет никаких проблем».

«Если бы Скрам Гайд детально описывал то, как сделать Ретроспективу лучше…»

«Рестроспективу слишком сложно проводить».

«У нас есть Рестроспективы, но они не оказывают никакого эффекта на наш процесс».

«Ретроспективы показали нам, что Скрам не работает».

Реальность

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

1.       «Команда считает, что для нас это трата времени». Спросите, почему команда так считает? Скорее всего, это не так, а просто встреча проводится неэффективно и результаты ее не материализуются.

2.       «У команды нет препятствий». Команда, говорящая это, скорее всего, имеет огромную проблему, которую тяжело разглядеть. Это может быть нехватка доверия или боязнь конфликта.

3.       «Скажи нам, что делать, Скрам Гайд!» Действительно, в Скрам Гайде мало написано о том, каким образом нужно эффективно проводить Ретроспективу, но это не мешает Команде и Скрам Мастеру быть креативными.

4.       «Ретроспективы не оказывают никакого эффекта на наш процесс». Часто команды останавливаются в своем развитии, достигнув приемлемого уровня Велосити. Скрам был создан с целью получать лучшие результаты за меньшее время с постоянным ростом производительности. Если производительность вашей команды не растет – велики шансы того, что вы не находите глубинные причины ваших проблем на Ретроспективе.

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

ПОРА ЧТО-ТО МЕНЯТЬ

Шаг Первый

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

Шаг Второй

Четко определите для себя, почему Ретроспектива так важна. Скрам тесно связан с постоянным совершенствованием. Если вы постоянно не будете искать пути для улучшения, то потеряете конкурентное преимущество, которое дает вам Скрам.

Шаг Третий

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

Метрика Счастья – простой инструмент, позволяющий собрать полезную информацию на Ретроспективе. Ее следует использовать следующим способом:

Задайте следующие вопросы каждому члену вашей Команды:

1.       Используя шкалу от 1 до 5, насколько вы довольны вашей ролью в организации?

2.       Используя ту же шкалу, насколько вы счастливы в вашей организации?

3.       Что сделало вас более счастливым в прошлом Спринте?

4.       Что особенно разочаровало вас в прошлом Спринте?

5.       Что могло бы сделать вас более счастливым в следующем Спринте?

Задайте следующие вопросы Команде:

1.       Что могло бы сделать команду счастливее в следующем Спринте?

2.       Выявите наиболее приоритетное изменение или Кайзен.

3.       Внесите Кайзен в Спринт Бэклог вместе с приемочным тестом

 

Просто попробуйте это

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

Скрам за три дня до конца света

За три дня до предполагаемого конца света, в Днепропетровском офисе компании EPAM собрались 16 человек, которые решили обсудить минимальный Фреймворк Скрама. Теперь, чтобы не произошло 21 числа, мы будем во всеоружии!

В этот раз мы решили сделать основной упор на Роли и Ответственности. Это как раз та область, в которой многие «плавают» и чувствуют себя неуверенно.

Действительно, из-за того, что классического Менеджера Проекта в Скраме просто взяли и взорвали, а обломки его былых полномочий упали на три роли (The Product Owner, The Scrum Master, The Development Team),  часто возникают непонимания относительно того, в чьей зоне ответственности находится та или иная активность.

К примеру, многие не понимают, что план итерации (Спринт Бэклог) принадлежит исключительно команде, и никто не смеет без согласия Команды вносить в этот план какие либо изменения. С другой стороны, План Релиза находится безоговорочно в компетенции Владельца Продукта (The Product Owner).

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

 

Мой опыт сдачи Certified Scrum Professional (CSP)

Получить от Скрам Альянса статус Certified Scrum Professional я решил еще этой весной, но, как это часто бывает, сначала не было времени,  а позже возможности из-за перегруженности на работе. 

Но в ноябре так сложились звезды (нет, гороскопы я не читаю), что 12.12.12 я приехал в Киев с целью, наконец , осуществить задуманное. Еще год назад возможность сдачи Certified Scrum Professional была только во Львове , теперь же вы можете сертифицироваться и в Киеве (офисе SMART Business м.  Шевченко).

С полным описанием сертификации вы можете ознакомиться тут.

Как это было

Полчаса девушка, ассистирующая на экзамене, не могла войти в систему Castle WorldWide и заметно нервничала. К сожалению, это волнение передалось и мне. Когда же у нее все получилось, она караулила меня и ходила по пятам, когда я направлялся за очередной чашкой чая на кухню. На весь экзамен я потратил 1 час 20 минут с учетом 24 вопросов, которые отметил на последующую проверку. Набрал 569 из 600 баллов. Всего вам отводится 3 часа, за которые вы должны ответить на 150 вопросов. Результат выдается по шкале от 300 до 600 с порогом прохождения 450.

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

Структура вопросов по сложности

• ·         20% - сложные, близкие к тем 35 вопросам, которые Альянс предлагает приобрести здесь.
• ·         60% - средней сложности, требующие глубокого понимания ролей, ответственностей, теории Скрама и хорошего знания технических практик (TDD, Pair Programming, CI, Test-first design, Simple Design).
• ·         20% - примитивные вопросы:  «Какой оптимальный размер Скрам команды?» и т.д.

Структура экзамена по тематике

• ·         Scrum Basics - 10%
• ·         Roles and Responsibilities in Scrum – 40%
• ·         Scrum on Enterprise level – 15%
• ·         Retrospectives – 5%
• ·         Agile Practices – 15%
• ·         Colocation, Collaboration, Cooperation – 5%
• ·         Other Agile methodologies/frameworks – 1 question
• ·         Definition of Done – 5%
• ·         Different – 5%

Как готовиться?

Рекомендую прочитать следующие книги для подготовки к экзамену:

• ·         Succeeding with Agile: Software Development Using Scrum (Mike Cohn) – концепции из этой книги встречались в тесте очень часто. Вы должны знать, что такое Improvement Communities и для чего они создаются, принципы перестройки компаний на рельсы Аджайл.
• ·         Agile Estimating and Planning (Mike Cohn) – библия Аджайл планирования, комментировать особо нечего, если вы не читали эту книгу то вы не знакомы с Аджайлом.
• ·         Agile Product Management with Scrum (Roman Pichler) – прочитав эту книгу, вы глубоко поймете роль Владельца Продукта.
• ·         Agile Retrospectives (Esther Derby and Diana Larsen) – лучшая книга по Ретроспективам. На экзамене я встретил несколько вопросов, непосредственно относящихся к этой книге. Запомните названия основных активностей, структура проведения ретроспектив.
• ·         How Do We Know When We Are Done? (Mitch Lacey) – замечательная статья на сайте Альянса, объясняющая детали Definition of Done и для чего это нужно.
• ·         What is Definition of Done (DoD)? (Dhaval Panchal) – еще одна статья  о Definition of Done.
• ·         The Art of Agile Development (James Shore) – читайте обязательно, чтобы понять принципе экстремального программирования.
• ·         Agile Software Development with Scrum ( Ken Schwaber, Mike Beedle) – классика жанра, первая книга по Скраму.

Это минимальный джентельменский набор для экзамена.

Еще хочу поделиться с вами одним секретом. Несколько месяцев тому назад вышла книга, которая может заменить многие из перечисленных выше. В моем личном рейтинге на сегодняшний день это лучшая книга по Скраму – Essential Scrum (Kenneth S. Rubin). Этой книги нет в списке рекомендованной литературы, но знаниями она может вас накачать очень быстро.

Сравнение с другими Аджайл Сертификациями

Вопросы не сбалансированы по сложности как в PMI-ACP. Как мне кажется, слишком большое количество неоднозначностей (некоторые, я уверен, будут считать это плюсом). Не покидало ощущение, что они были составлены разными людьми с разной стилистикой и скинуты в одну кучу. Не хватило некой последовательности, которую я ощутил при сдаче PMI-ACP.  Я поймал себя на мысли, что экзамен не держал меня в напряжении, в отличии от PSM (Professional Scrum Master) и PMI-ACP (Agile Certified Practitioner).  Времени – вагон, вопросы не ахти какой сложности и порог прохождения (50%)  - слишком малое испытание для человека, желающего называть себя Скрам Профессионалом.

Выводы

К сожалению, автоматически назвать человека, сдавшего CSP, профессионалом я не могу. А хотел бы. Для этого нужно поднять планку прохождения желательно до 80%, как минимум до 70%, чтобы у многих «профессионалов» отбить охоту  и возможность легкой сдачи. За исключением этого – тест совсем неплох и многими местами очень даже радовал.

И главное – поездка в Киев, все таки, оказалась удачной.

The End.