перевод оригинального паттерна Sprint Retrospective.
Sprint Retrospective**
…вы подошли к концу Sprint и готовитесь к следующему. Разумеется, независимо от того, насколько хорошо он прошел, вы хотели бы улучшиться.
✥ ✥ ✥
Без должного внимания процессы и дисциплина со временем ухудшаются. Люди становятся небрежными. Изолированные изменения усиливают энтропию, а без регулярных изменений команда упускает возможности для роста ценности.
Вы хотите постоянно улучшаться. Daily Scrum дает командам возможность исследовать себя и улучшать продукт ежедневно. Однако, Daily Scrum не подходит для изменения процесса по нескольким причинам.
Во-первых, производительность меняется ежедневно. Бессмысленно вносить коррективы в ответ на обычную вариативность процесса. День (от одного Daily Scrum до другого) - слишком короткий промежуток времени, чтобы увидеть, принесли ли внесенные изменения желаемый результат. Кроме того, изменение процессов в середине спринта разрушительно.
Во-вторых, фокус Daily Scrum - инспекция и адаптация прогресса по достижению Sprint Goal. Таким образом, горизонт планирования краткосрочный, и Development Team фокусируется на выполнении работы в Спринте, а не системных проблемах.
Третья причина заключается в том, что в середине Sprint вы, вероятнее всего, увидите только одну или две перспективы на проблему, а не полную картину влияющих на нее факторов. Команде опасно делать выводы исходя из неполной информации.
На Sprint Review, команда обозревает продукт со стейкхолдерами. Это событие не место для анализа проблем и улучшений, оно сфокусировано на продукте. Development Team и Product Owner должны принять ответственность за проблемы, как самоорганизованная команда (Self-Organizing Team) и решить, как с ними поступить за пределами Sprint Review, без стейкхолдеров. Фокус Sprint Review — продукт. Он объединяет команду и заинтересованные стороны вокруг единичных проблем. Тем не менее, еще более важно в Скраме исследовать паттерны процессов, которые способствуют возникновению проблем, кажущихся независимыми и несвязанными, но редко таковыми являющимися.
Так как спринты следуют один за другим, хочется броситься из одного спринта сразу в другой, не задумываясь, как команда выполнила (или не выполнила) работу. Это приводит к повторению одних и тех же действий, совершению одних и тех же ошибок.
Сделав несколько улучшений, Scrum Team может прийти к убеждению, что они уже и так хорошо работают и что новых улучшений не нужно («Мы и так здорово работаем!»). Добавленная ценность улучшений снижается и поэтому команда может рассматривать это как пустую трату времени («Мы слишком заняты!»).
Когда команда инспектирует себя, ее участники становятся уязвимыми для критики. Люди могут чувствовать смущение, страх, чувствовать некомпетентность. Это может привести к защитному поведению, при котором участники команды отрицают свою ответственность, как индивидуальную, так и коллективную, и экстернализируют проблему.
Поэтому:
В конце каждого Sprint, есть событие, где Scrum Team может оценить, как она выполняла свою работу в ходе Sprint.
Проводите Sprint Retrospective в конце Sprint. Это естественное время для рефлексии. Изучение завершенной работы открывает полную перспективу системы (где система — это команда и ее процессы). Оценка того, как идут дела в середине процесса, дает лишь частичную картину, причем с очень ограниченной точки зрения. Поэтому мы приурочиваем ретроспективы к завершению работы в рамках Sprint. Кроме того, проблемы и победы Sprint еще свежи в памяти каждого.
Команда предлагает изменения процесса в интересах достижения Greatest Value. Изменение процесса может касаться людей, отношений, процесса, окружения или инструментов.
✥ ✥ ✥
Корни Скрама в Производственной Системе Тойоты (TPS), сердце которой - процесс улучшения. В руководстве TPS есть инструкция “Проверить Хансей”. Хансей - это глубокая форма личного или коллективного сожаления о неудаче. Хорошая Scrum Team производит хансей над своими неудачами, а затем перенаправляет энергию сожаления в позитивную энергию для устранения проблемы; см. Scrumming the Scrum. Поэтому Sprint Retrospective также является временем исцеления и обновления для команды. Бережливое сообщество считает Тайичи Оно основателем TPS. Известная цитата, которую обычно приписывают ему:
Ни у кого нет больших проблем, чем у человека, который утверждает, что у него нет проблем. (Отсутствие проблем - самая большая проблема из всех).
Фокусируйтесь на развитии культуры, где Sprint Retrospective становится неотъемлемой частью каждого Sprint. Встраивайте ее в регулярный ритм работы команды. Избегайте искушения пропустить ретроспективу, потому что кажется, что нужно еще время для завершения работы в спринте. Это только укрепит культурное убеждение, что ретроспективы не важны.
Ограничивайте встречу по времени. Дайте достаточно времени для глубокого изучения проблем, при этом не делайте ретроспективу настолько длинной, чтобы люди заскучали. Скрам рекомендует ограничить событие максимум тремя часами на месячный Sprint. Для более коротких Sprints, событие обычно короче.
Обычно, вся Scrum Team участвует, включая Product Owner. Изредка, если участники Development Team чувствуют, что Product Owner доминирует или иным образом подавляет честное и открытое обсуждение, они могут попросить Product Owner не участвовать. Это сигнал большой проблемы, потому что Скрам помогает устранять проблемы для достижения еще большей ценности, а, так как Product Owner находится в центре ценностного предложения, доверительное участие Product Owner в этих встречах является ключом к долгосрочному успеху.
Один из принципов Аджайл Манифеста:
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Ретроспективы, особенно регулярные, могут легко превратиться в поверхностные встречи, на которых не рассматриваются существенные вопросы. Чтобы справиться с этим, используйте известные эффективные форматы ретроспективы, например, описанные в книге Эстер Дерби и Дианы Ларсен “Аджайл Ретроспектива: как превратить хорошую команду в великую”. Например, один из форматов заключается в определении того, что прошло хорошо, текущих проблем и конкретных действий, которые необходимо предпринять. Время от времени меняйте форматы. Выстраивайте обсуждение основываясь на эмпирических данных. Например, изучите такие метрики, как процент выполнения Sprint Backlog и скорость команды. Кроме того, определите конкретные изменения процесса, которые команда внесет во время следующего Sprint.
Храните и упорядочивайте изменения в Impediment List. Паттерн One Step at a Time рекомендует команде делать одно изменение за раз, чтобы понимать, как каждое изменение влияет на процесс улучшения; посмотрите также Scrumming the Scrum. Паттерн Happiness Metric предлагает принять те изменения, которые в наибольшей степени повышают энтузиазм и вовлеченность команды. Убедитесь, что вы можете измерить выгоды и последствия, которые влечет за собой каждое изменение: его стоимость, преимущества и недостатки (см. Testable Improvements).
Постоянное использование Sprint Retrospective не гарантирует улучшение процесса или его стабильность. Недостаточно просто проводить ретроспективы, необходимо регулярно поднимать вопрос о кайдзен-мышлении (см. Kaizen and Kaikaku). Если все сделано правильно, Sprint Retrospective вдохновляют команду и вселяют в них гордость за то, что они улучшаются с течением времени; см. Product Pride.
Ретроспективы могут легко превратиться в сеансы нытья. Чтобы бороться с этим, начинайте Ретроспективу, следуя основной директиве Норма Керта: «Независимо от того, что мы обнаружим, мы понимаем и искренне верим, что каждый сделал все, что мог, учитывая то, что он знал в то время, навыки и способности, доступные ресурсы и сложившуюся ситуацию». Для этого требуется сообщество, подобное описанному в разделе Community of Trust. Убедитесь, что команда понимает, что она способна, а что не может изменить в краткосрочной перспективе, а может быть, и никогда. Поднимайте как позитивные, так и проблемные вопросы. Не исследуйте только плохое. Хорошее, возможно, стоит записывать. Например, Definition of Done должен расширяться по мере того, как команда открывает и изучает новые способы достижения «Готово» (см. Definition of Done). Нытье также может указывать на более глубокие проблемы, и Scrum Master должен пристально следить за признаками более глубоких проблем в общем тоне Ретроспективы.
Обратите внимание, что ретроспективы продолжительностью в два или три часа, как правило, недостаточны для изучения глубоких вопросов. Поэтому Sprint Retrospective является неким компромиссом между глубиной обсуждения и продолжительностью встречи. Проблема, обнаруженная во время Sprint Retrospective, может быть связана с более глубокими, сложными взаимоотношениями, которые группа не может должным образом раскрыть и изучить всего за три часа. В отчете Джеффа Сазерленда, основанном на опыте общения с Investment Group, отмечается следующее:
Препятствия подобны комарам. Вы прихлопнете одного, а 25 вернутся. Поэтому вам нужно найти корневую причину. Чтобы комары перестали прилетать, нужно осушить болото.
Для того чтобы "осушить болото", можно рассмотреть возможность работы на уровне двух- или даже трехконтурного обучения, описанного Свиринга и Вирдсма. Вкратце: одноконтурное обучение заключается в изменении правил, а двухконтурное - в изменении базовой структуры. Трехконтурное обучение имеет дело с основными принципами и ценностями, лежащими в основе организации и ее истории.
Норм Керт предлагает выделить три дня на изучение глубоких структурных проблем в организации. Он предложил структуру для трехдневных выездных ретроспектив, которые ведут к этому уровню улучшения. Обширная Ретроспектива Керта больше подходит для работы с глубокими уязвимостями команды, потому в ней уделяется больше времени на создание доверия между членами команды, чем в относительно коротких Sprint Retrospective. Это также позволяет производить более глубокие Kaikaku (непрерывные изменения), выходящие за рамки эволюционных изменений, на которых сфокусирована Sprint Retrospective.
Команда аудиовизуальных инженеров Skype, отвечавшая в то время за высокое качество звука и видео в Skype, а также за разработку кодеков, время от времени проводила двух-трехдневные выездные встречи в связи со своими Team Sprints. Эти события привели к новым изобретениям, изменению дизайна собственного рабочего пространства и инновациям в процессе разработки.
