Думать некогда, трясти надо - или что такое ретроспектива в Agile

Управление - Управление проектом

27
12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

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

На мой взгляд, именно рефлексия “как мы работаем” и корректировка курса при необходимости и является одним из ключевых отличий подхода Agile от подхода “тяп-ляп”, который я описывала в  статье Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? 

Почему это важно?

Идея, что надо оценивать результативность своей работы и вносить коррективы, не нова. Вряд ли Уолтер Шухарт и Эдвард Деминг действительно были первыми, кто ее высказал, но именно им удалось озвучить ее наиболее громко.
Деминг, в поте лица трудившийся в середине 20 века на благо и процветание японской промышленности, активно совершенствование агитировал (хотя здесь за отсутствием идеи самоуправления улучшение вменяется в обязанность не "команде", как в Agile, а "руководству"): “Улучшайте каждый процесс. Улучшайте постоянно, сегодня и всегда все процессы планирования, производства и оказания услуг. Постоянно выискивайте проблемы для того, чтобы улучшать все виды деятельности и функции в компании, повышать качество и производительность и, таким образом, постоянно уменьшать издержки. Непрерывное улучшение системы, включающей в себя разработку и проектирование, поставку комплектующих и материалов, обслуживание и улучшение работы оборудования, методов управления и организации, подготовку и переподготовку кадров — есть первейшая обязанность руководства.”
 
Принцип учета обратной связи используют практически в любой здравомыслящей организации. На производстве при обнаружении проблем применяют цикл Шухарта-Деминга: планируй (Plan), делай (Do), проверяй (Check), применяй (Act). В том смысле, что сначала - придумывай способы решения проблем (Планируй), потом реализуй их (Делай), проверяй что получилось (Проверяй), и действуй на основании полученной информации (Применяй полученные в ходе проверки знания).
Авторы Свода знаний по управлению проектами PMBOK, по сути, положили в его основу тот же самыйцикл и прикрутили к нему инициацию в начале и завершение в конце. Мой коллега Иван Селиховкин превратил эту картинку в симпатичного удава (только не начинайте опять обсуждать, с головы ли проект должен начинаться или наоборот). В-общем, все говорят про усовершенствования.

 

Цикл Деминга-Шухарта в управлении проектами

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

Зачем это надо?

Ретроспектива - это специально организованное мероприятие, где важно создать атмосферу для обмена мнениями и сбора информации. Большинству нормальных людей (особенно русских)  рефлексировать непривычно. “Итак всё понятно, чего тут обсуждать?..”. Но, практика показывает, что при разумной организации процесса (“наша кошка тоже сначала не любила пылесос, а потом - ничего, втянулась”) люди постепенно привыкают, и рефлексировать становится естественным. Хотя, честно скажу, что все команды, с которыми я имела дело, были готовы рефлексировать гораздо меньше, чем призывают делать, например, американские коллеги. Так что читая западные книжки делайте поправку на культурные различия. И еще, кстати, у нас совершенно нет традиции измерять. Что угодно - продуктивность, количество ошибок, динамику и т. п. Типичный ответ “и так понятно”. Что именно “и так понятно” - при этом у всех могут быть разные версии. Но провести измерения - нееет, это лишнее. Но я отвлеклась от основной темы.

Что даст вашей команде специально организованное размышление “как улучшить работу”? Возможность осознать, что именно не работает и как это можно исправить. Наше мышление устроено таким образом, что мы не можем одновременно и думать и действовать. И для того, чтобы увидеть “большую картину” (big picture) происходящего, нужно остановиться и посмотреть на нее со стороны. А то получится как в старом анекдоте:

Решили как-то сравнить прапорщика с обезьяной. Посадили их в две одинаковые комнаты с деревом и бананом на дереве. Обезьяна потрясла, потрясла дерево - банан не падает. Видит палка в углу стоит, зацепила банан палкой, сидит довольная и лакомится.
Прапорщик же трясёт пальму, трясёт... Час трясёт, два трясёт. Ему говорят: "товарищ прапорщик, ну вы подумайте немного", на что тот отвечает: "Чего тут думать! Трясти надо!"


При каких условиях у вас ничего не получится?

Я размышляла, стоит ли добавить этот пункт в мою статью. Позитивное мышление, и всё такое. Но, тем не менее, из песни слова не выкинешь… Итак, у вас врядли получится что-то кроме "поговорили и разошлись", если…

  • Ваша команда замотивирована не на результат, а на имитацию бурной деятельности.
  • Люди не решаются высказывать свою точку зрения, так как нет атмосферы доверия и сотрудничества.
  • Наиболее острые проблемы лежат за пределами зоны ответственности команды, и руководство не готово изменять процессы компании.
  • У ведущего категорически не хватает авторитета для поддержания рамок.
  • Ведущий уже знает ответы на все вопросы, и мнение группы ему не особо интересно.
  • Фокус внимания при обсуждении сместился на вопрос “Кто дурак?” или “Почему я не виноват?”, а не на вопрос “Что нам делать дальше?”

В какой момент следует проводить ретроспективы? 

  • Если у вас  есть четко ограниченные итерации с демонстрацией продукта заказчику - как, например, в Scrum -  то ретроспективы логично проводить сразу после. 

Если нет - допустим, вы работаете по Канбан-системе, или вообще сочетаете работу “по водопаду” с “гибкими методами” - то ретро можно проводить в любой момент, когда вам это удобно. Например:

  • Если у вас состоялся релиз
  • Если вы сделали логически законченный кусок работы
  • Если у вас давно не было ретроспектив (уже несколько недель)
  • Если вы чувствуете, что застряли и вам нужно сдвинуться с мертвой точки


Как можно проводить ретроспективы и как сделать ретроспективу интересной?

Тренд современности - геймификация. Взрослые люди организуют свое время при помощи помидорок, авторы серьезных статей меряются лайками, а солидные доклады перемежают смешными видеороликами. 
Вот и для того, чтобы обсуждение работы не превратилось в скучное просиживание штанов, на ретроспективе надо играть. Не надо думать, что вы люди серьезные, и игры не для вас. Самые серьезные совещания, стратегические сессии, деловые переговоры прекрасно оживляются при помощи комплекта разноцветных стикеров, маркеров и красивых картинок. 
Ниже предлагаю вариант, как можно ретроспективу провести:
(просто пример, не обязательно руководство к действию)

1. Устанавливаем рамки

Договариваемся о правилах игры, о правилах взаимодействия (их полезно выработать совместно).
Практика показывает, что очень важно на начальном этапе, во-первых, всех посадить вместе (никакого “я останусь за своим рабочим местом, мне и отсюда всё прекрасно слышно”), во-вторых, чтобы каждый хоть что-нибудь сказал (хотя бы назвал свое имя или сказал “мне пока нечего сказать, я пропускаю очередь” - это поможет молчаливым участникам включиться.
Как можно геймифицировать? Мне нравится для запуска ретроспективы игра ESVP (Explorer - Исследователь или Экспериментатор, Shopper - Покупатель, Vacationer - Отдыхающий, Prisioner - Заключенный - по-русски можно использовать аббревиатуру ЭЗОП). 
В начале каждому из участников предлагаем анонимно написать на листочке (букву или номер), в какой роли он  на сегодняшней ретроспективе: пришел искать решения проблемам (Исследователь/Экспериментатор), посмотреть, чего интересненького дадут, просто отвлечься от работы, или ему пришлось сюда припереться, так как неизбежно. 
Ведущий перемешивает листочки, чтобы было непонятно, кто что ответил, и записывает результаты на доске. 
Что здесь ценно? Мы видим картинку, насколько команде важно, что происходит. Те, кому не важно (в первую очередь “Заключенные”) видят уважение к своей позиции.
Можно предложить им после перерыва покинуть это собрание - в конце концов, насильно мил не будешь. Если “заключенных” большинство, ретроспективу лучше провести максимально оперативно и конструктивно ))),

Проблемное поле2. Собираем информацию

В начале ретроспективы важно возобновить в памяти, что произошло за последнее время. Это важно, во-первых, чтобы вспомнить, во-вторых, чтобы сместить фокус внимание с фактов на отношение к ним. Можно вспомнить ключевые проблемы, с которыми столкнулась команда.
Как можно геймифицировать? Красивая техника для этого - Линия времени, когда участники вспоминают события и размещают их на линии времени.
Еще интересный подход - техника Mad, Sad, Glad (Бесит-Печалит-Радует), когда участников просят вспомнить (можно в парах), какие события за обсуждаемый период времени их Взбесили-Опечалили-Порадовали. Дальше можно их разместить на трёх частях доски. И используем собранную информацию для следующего этапа ретроспективы.

 

3. Генерируем идеи

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

4. Решаем, что делать

После обсуждения высказанных вариантов надо принять решения, какие именно изменения мы внедрим. Типичная ошибка неофитов в Agile - попытка изменить “всё и сразу”.  “У нас с вами не получилось сделать полезный пользователю продукт, не работает самоуправление, куча претензий к качеству, отклонение по срокам - давайте это всё в следующий раз улучшим” - такой подход, к сожалению не работает. Нужно выбрать несколько, с одной стороны, важных, а с другой - посильных моментов, и работать именно над ними. 
Как можно геймифицировать? 
Мне нравится использовать разные техники приоритизации (см. мою предыдущую статью Приоритизировали, приоритизировали, да не выприоритизировали... , я там немного про это рассказывала).

5. Завершаем ретроспективу

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

-В позапрошлом году мы посадили 100 Га пшеницы, но все пожрал проклятый хомяк! В прошлом году мы посадили 200 Га пшеницы, и снова все пожрал проклятый хомяк! А в этом году мы посадим 500 Га пшеницы, и пусть подавится этот проклятый хомяк!
 

Как можно геймифицировать?

Хорошая техника - термометр. Отслеживаем, где мы сейчас находимся, и куда можем двигаться дальше.

 

Термометр

 

Здесь я рассказала рекомендуемую структуру ретроспективы, и привела только один пример, как можно это делать на практике. Подробное описание структуры ретроспективы и большое количество разных игр и активностей можно найти в книжке Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers), авторы  Esther Derby, Diana Larsen, Ken Schwaber. Книжка, кстати, хорошая, рекомендую - в русском переводе, говорят, тоже есть. 
 

27

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. sloneg 47 13.11.18 17:02 Сейчас в теме
Классная статья! Хотелось бы немного добавить.

При каких условиях у вас ничего не получится?
- команда не следит за выполнением выработанных решений.

Как контролируем это мы:
1. Все выработанные решения превращаются в задачи и вешаются в бэклог с конкретным исполнителем (если возможно назначить);
2. Скрам-мастер контролирует исполнение задач и напоминает команде о том что выработанные решения не исполняются;
3. После открытия ретроспективы можно проверять выполнение домашних заданий с прошлых ретро.

Плюс неочевидное: ретроспективу можно проводить на конкретные мероприятия скрама. Например, ретроспектива на обзор спринта или ретроспектива на ретроспективу. И эту тему стоит обозначить в начале мероприятия.

Для начинающих скрам-мастеров есть такая штукенция - ретромат https://retromat.org/ru/
Там своеобразная рулетка по проведению ретроспектив, если все уже испробовали и команда скучает и перестает генерить проблемы.
MariaTemchina; VladimirL; +2 Ответить
2. acanta 46 13.11.18 17:51 Сейчас в теме
(1) Если вы так делаете, у вас должна быть статистика причин неисполнения решений. (доля отмазок / найденных неоптимальностей / таймауты, превышающие объективно необходимые сроки, необходимость серьезной подготовительной работы и что-либо другое).

Мне очень понравилась аналогия APDEX и Agile. Клиент назначает требуемую максимальную продолжительность выполнения операции в APDEX.
Так же клиент имеет право установить срок выполнения в Agile какого то участка работ ("К вечеру надо создать.").
Но для того чтобы подобная оценка была возможной, должны быть результаты "замеров" именно этой операции или "предыдущего спринта" именно в этом направлении.
3. sloneg 47 13.11.18 18:30 Сейчас в теме
(2)
(1) Если вы так делаете, у вас должна быть статистика причин неисполнения решений. (доля отмазок / найденных неоптимальностей / таймауты, превышающие необходимые сроки, необходимость серьезной подготовительной работы и что-либо другое)


Как в сериале "Кремниевая долина" один из героев говорил: "Стало похоже на работу":)

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

Так же клиент имеет право установить срок выполнения в Agile какого то участка работ ("К вечеру надо создать.").
Но для того чтобы подобная оценка была возможной, должны быть результаты "замеров" именно этой операции или "предыдущего спринта" именно в этом направлении.


Вы про какой фреймворк? В скраме есть спринт и вкидывать туда "к вечеру надо создать" не совсем правильно, если говорите о velocity, то возможно. Если речь о канбан, то там есть типы задач, которые могут иметь разный lead time и этот lead time желательно улучшать.
8. MariaTemchina 424 14.11.18 10:04 Сейчас в теме
(3)
Вы про какой фреймворк? В скраме есть спринт и вкидывать туда "к вечеру надо создать" не совсем правильно, если говорите о velocity, то возможно. Если речь о канбан, то там есть типы задач, которые могут иметь разный lead time и этот lead time желательно улучшать.

Не знаю о чем говорит автор комментария, но в Канбан-систему такой подход как раз хорошо вписывается - что может быть "срочная" задача, и специальная плавательная дорожка для срочных задач с небольшим WIP-лимитом (допустим, одна или две). Мы так делали, хотя в итоге пришли от физической разметки дорожек к цветовой разметке и разметки в виде тэгов - так оказалось удобнее.
4. acanta 46 13.11.18 18:38 Сейчас в теме
Насколько оправдано разделять поток задач на разные фреймворки? Часть работ (грубо говоря разработка) отдается под канбан, а текучка ложится под velocity?
И главное - как вы бы предложили совмещать указанные вами цели в процессе работы?
Поиск виновного, оценка ущерба и наказание - это типичный бизнес процесс, никак не связанный с процессом разработки, но возможно присутствующий перманентно в атмосфере (как часть корпоративного стиля "Никто не выйдет отсюда чистеньким") и прорабатывающий каждую обнаруженную ошибку по цепи взаимодействий и причинно-следственных связей.
В таком случае возникает вопрос, является ли 1с (в любом ее виде) самодостаточным мотивом для того, чтобы плодотворно работать в подобной атмосфере?
И насколько разработчики 1с (защищая собственные интересы даже не столько авторские, сколько в вопросах об ответственности в причинении ущерба третьим лицам) это, по-вашему, понимают.
5. sloneg 47 13.11.18 18:41 Сейчас в теме
(4)
Насколько оправдано разделять поток задач на разные фреймворки? Часть работ (грубо говоря разработка) отдается под канбан, а текучка ложится под velocity?


Да философия разная просто. И метрики.
6. sloneg 47 13.11.18 18:59 Сейчас в теме
(4) не совсем понятно о чем Вы.
7. acanta 46 13.11.18 19:02 Сейчас в теме
(6) о том, что думать некогда.
9. MariaTemchina 424 14.11.18 10:08 Сейчас в теме
(4)
фреймворки? Часть работ (грубо говоря разработка) отдается под канбан, а текучка ложится под velocity?

По мне так наоборот, текучкой логичнее управлять по Канбан (ибо задачи прибегают в неустановленное время, и подгонять релизы к фиксированным датам не всегда удобно), а разработкой, которую можно заранее спланировать и структурировать, можно управлять по скраму (хотя по мне я Канбан больше люблю). Но совмещать одно и другое - это же неудобно!... Чем дальше вам удалось уйти от многозадачности, тем лучше команде работается. Другой вопрос, что есть идеальная модель, а есть суровая реальность, когда разработчики вынуждены сидеть на техподдержке...
16. Rustig 1033 15.11.18 18:49 Сейчас в теме
(4)
В таком случае возникает вопрос, является ли 1с (в любом ее виде) самодостаточным мотивом для того, чтобы плодотворно работать в подобной атмосфере?
И насколько разработчики 1с (защищая собственные интересы даже не столько авторские, сколько в вопросах об ответственности в причинении ущерба третьим лицам) это, по-вашему, понимают.

вот тут ответ https://infostart.ru/video/w878512/
10. acanta 46 14.11.18 18:05 Сейчас в теме
Разработчики никогда не сидят на техподдержке. Если один сидит на техподдержке это уже не разработчик.
11. MariaTemchina 424 15.11.18 09:49 Сейчас в теме
(10)
Разработчики никогда не сидят на техподдержке. Если один сидит на техподдержке это уже не разработчик.

Вы сейчас применяете знаменитую логическую уловку "Ни один истинный шотландец"

Мне больше нравится формулировка "Разработчики не должны сидеть на техподдержке. Если им приходится это делать - значит, процесс организован не самым разумным образом..."
12. DenisCh 15.11.18 09:52 Сейчас в теме
(11)А если разработчик - на второй линии и отвечает за то, что он пропустил в продакшн?
13. MariaTemchina 424 15.11.18 09:54 Сейчас в теме
(12) Да, спасибо. Я подумала про то, что точнее написать "на первой линии техподдержки", но поленилась ))).
На второй линии, возможно, тоже лучше сидеть службе сопровождения специально организованной. Но тогда понадобится третья линия, для тех косяков, которые все-таки без автора не решить ))).
14. acanta 46 15.11.18 11:15 Сейчас в теме
(11) не совсем так. Сформулированная вами логическая уловка описывает ЧСВ.
Я говорю о причинно-следственной связи (курица или яйцо). Невозможно осуществлять техподдержку какой-либо линии если нет уже разработанного продукта.
Техподдержка осуществляется когда продукт уже есть (т.е. это отладка/решение конфликтов и обеспечение успешной приемки работ, выполняемых разработчиком).
То что днем один человек может быть техподдержкой, а ночью разработчиком ни для кого не секрет (а вот здесь уже играет некоторую роль и ЧСВ).
Но одновременно это невозможно.
15. MariaTemchina 424 15.11.18 11:20 Сейчас в теме
(14)
Невозможно осуществлять техподдержку какой-либо линии если нет уже разработанного продукта.

И да и нет. Потому что если у нас разработка осуществляется по Agile, то есть итеративно и инкрементально, то после первого же промежуточного релиза у нас уже есть продукт в эксплуатации (опытной или промышленной) и продолжение разработки параллельно...
Оставьте свое сообщение