Ретроспектива Agile. Взгляд с точки зрения Lean

Ретроспектива Agile. Взгляд с точки зрения Lean

Ретроспектива является одной из священных традиций Agile в разработке программного обеспечения. Ретроспектива – один из двенадцати принципов в Манифесте Agile. Наконец, ретроспектива – одно из четырех регулярных занятий, описанных в руководстве по scrum (скрам). У каждой Agile команды, с которыми я когда-либо сталкивался, была ретроспектива. И все знают, для чего все это? Непрерывное улучшение! Это Святой Грааль, верно? Кайдзен! Истинное сердце Lean и Agile. Кайдзен означает «улучшения». И это изменения, улучшения, рост и обучение, верно?

Все это хорошо. Но никто не говорит вот о чем: ретроспективы – это не постоянное улучшение.

Что такое ретроспективы?

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

Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Это довольно хорошее описание ретроспектив. Так в чем проблема? На самом деле их две. Во-первых, они не являются непрерывными. Во-вторых, они часто не имеют отношения к улучшениям.

Регулярные интервалы не являются непрерывными

Если вы делаете что-то раз в неделю, раз в месяц или раз в две недели, это не является непрерывным действием. На самом деле это называется «дискретным», что на самом деле является противоположностью непрерывного. Непрерывный означает «все время». Не какое-то время, не часть времени, не один раз время от времени, но все это чертово время. Ты никогда не перестаешь это делать. Это Кайдзен.

Ретроспективы часто не имеют отношения к улучшениям

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

Но это просто означает, что мы плохо проводим ретроспективы, верно?

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

Непрерывное улучшение – не то, что вы думаете

Непрерывное улучшение – это старая концепция Lean, а не Agile, и это не эквивалент ретроспективы. Это фундаментальное изменение в структуре и культуре работы в организации.

Это ответственность всей организации

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

Это происходит (в значительной степени) все время

Постоянное улучшение не означает, что время от времени вы перестаете делать то, что делали, и думаете о том, как все было раньше. Это не непрерывно. Думайте об этом так: почему люди поднимают проблемы на ретроспективе? Исправление проблем в том месте и времени, где и когда они происходят, является лучшим из возможных способов. Почему эти проблемы не были подняты тогда, а только теперь – на ретроспективе?

Если кто-то на ретроспективе говорит, что «программа сломалась в прошлую среду, остановив наше тестирование», почему это не было поднято, обсуждено, исправлено и навсегда устранено в прошлую среду? Если кто-то говорит «новая процедура утверждения замедлила мою работу», почему эта процедура не была сразу оспорена, улучшена или удалена?

Еще рекомендуем:  Agile – это не инструменты и процессы

Потому что это сложно. Действительно сложно. Большинство организаций не готовы поддержать такой подход к работе. Это настоящий кайдзен, Lean кайдзен, который я люблю переводить так: «остановись и исправь». Если вы видите что-то плохое, или неисправное, или медленное, или ненужное, или неправильное, тогда вы все останавливаетесь и сразу исправляете это, в том месте и в тот момент. Не через неделю, не через месяц, не в виде стикера на доске через три недели, прямо там и тогда.

Andon (андон)

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

Подумайте минуту о своей работе. Представьте, что каждый раз, когда кто-то сталкивался бы с глупым правилом, ненужным процессом, плохим инструментом, медленным или ошибочным программным обеспечением, он не мирился бы с этим. Он тянул бы за шнур, звал свою команду и менеджера и говорил: «вот это неправильно, мы должны это исправить». И все бросили бы все, что они делали, и исправили проблему навсегда. (Кстати, вы знаете, что не делают в Toyota? Ретроспективу спринта).

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

Это инструмент Lean, а не Agile

Непрерывное улучшение основано на кайдзен, то есть Lean. И это старый японский производственный подход, а не модный американский подход к разработке программного обеспечения. Это также подход для управления организацией, а не для управления проектом или разработкой продукта. Это не просто проведение традиционного для «водопада» обзора после внедрения (PIR), только в каждом спринте. Конечно, ретроспектива в конце спринта – это огромное улучшение по сравнению с обзором в самом конце проекта. Но одной ретроспективы и поддержки Манифеста Agile на их сайте недостаточно, чтобы даже заикнуться о непрерывном совершенствовании.

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

Я все еще считаю, что проводить ретроспективы нужно

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

Они также являются важным первым шагом на трудном пути к непрерывному совершенствованию. И большинство компаний в мире не сделали даже этот первый шаг.

Но давайте не будем обманывать себя

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

Блог Leon Tranter

P.S.: Через неделю мы представим взгляд на ретроспективу с точки зрения ТОС. Ретроспектива может быть результативной!

2 комментариев “Ретроспектива Agile. Взгляд с точки зрения Lean

  1. Читал и радовался. Думал: какую классную статью Владимир написал, а я и не знал, что у него есть опыт работы с эджайл-командами, надо же…
    И тут в конце “бац”: “Автор: Leon Tranter”… Эххх… 😉 А я думал – автор Владимир Речкалов. 😉

      Цитировать  Ответить

Давайте обсудим...

Ваш e-mail не будет опубликован. Обязательные поля помечены *