Какую типичную картину вы представляете, когда кто-то говорит, что находится в процессе agile-трансформации?
Обычный сценарий следующий: в зависимости от суммы денег, которой располагает организация, она нанимает либо одного из «Большой тройки», либо «Boutique Agile», либо не очень популярную консалтинговую компанию. Они приходят, проводят от одного до трех месяцев и создают 200-страничный PowerPoint.
Документ наполнен привлекательными графиками, диаграммами, сценариями и ключевыми преимуществами новых подходов. Он также может содержать некоторые предложения о том, какие инструменты использовать, как настроить первую доску Jira, какой ритм календаря адаптировать и в чем разница между горизонтальным и вертикальным разделением невыполненной работы.
Скорее всего, где-то между этими слайдами будет также реализовано какое-то внедрение SAFe — высшее руководство организации не хочет терять контроль, не так ли?
Затем консалтинговая компания уходит.
Менеджеры проектов переименовываются в Scrum Master/Agile Coach/ Owner Product, в зависимости от оценки уровня зрелости, которую старшие руководители решают в своей организации во время семинара по оценке уровня зрелости и, возможно, личных предпочтений конкретного человека (даже предложения, которое описывает, что это не имеет смысла). Затем команды проводят упражнения по Уставу команды, создают Scrum Kanban Boards, уточняют два рабочих спринта и начинают работу.
К этому времени все уже раздражены, потому что:
Знакомо, не так ли? Но правильный ли это подход?
Когда детей впервые знакомят с геометрией в средней школе, все начинается с основ:
С этим базовым легче двигаться вперед.
То же самое и со Scrum. Когда вы открываете Scrum Guide, оно начинается с теории. Он мягко объясняет читателю идею эмпиризма и знакомит с тремя столпами — прозрачностью, контролем и адаптацией. Что бы ни было дальше — правила, события, артефакты и т. д. — все это реализации основ и невозможно без следования им. То же, что и геометрия, не так ли? Если вы открываете задачи для старшеклассников, вы не сможете их решить без базовых знаний, полученных вам в 5 классе.
Постарайтесь сосредоточиться на этих основах. Их нельзя потрогать или увидеть, их сложно измерить и визуализировать на приборной панели. Однако именно ваши ценности действительно раскрывают красоту Scrum и помогают раскрыть «лучшие способы создания программного обеспечения».
Как вы можете продвигать прозрачность и соблюдать ее? Как вы можете быть уверены, что действительно принимаете во внимание некоторые неизвестные факты для улучшения своих процессов? Действительно ли вы видите все ненужные отходы и ищете способы их устранения?
Эти вопросы — квинтэссенция Scrum Guide: «Легко следовать, но трудно освоить». Сосредоточьтесь на понимании того, какой потенциал вы раскрываете посредством конкретных действий. Если вы знаете, что стоит за изменениями/практикой, вашей команде будет легче понять их и следовать им. Вы начнете поддерживать каждое действие вопросом: «Поможет ли это нам добиться лучших результатов? Поддерживаем ли мы наши действия тремя фундаментальными столпами?»
Чтобы убедиться, что вы не совершаете тех же ошибок, с которыми раньше сталкивались многие организации, вступающие на территорию Agile-трансформации, попробуйте еще раз прочитать Agile-манифест и руководство по Scrum. Читая, подумайте о том, как каждый пункт представлен в этих документах, как они поддерживают друг друга и как создают общую структуру, имеющую смысл.
Трансформация принесет пользу только в том случае, если вы будете думать о фундаментальных ценностях каждый раз, когда необходимо принять решение. Если вы допустили ошибку, возможно, придется включить один из ключевых элементов. Безумие ожидать иного результата, не меняя своих действий. Вам все равно нужно что-то изменить, чтобы попробовать еще раз – так почему бы не попробовать вернуться в школу? Постарайтесь понять, какой именно элемент отсутствует. Найдите его, включите в свой процесс, и вы, скорее всего, добьетесь успеха.
Наша главная цель — устранить привычку, которая доминировала на рынке последние двадцать лет, — привычку внедрять инструменты и методы, не задумываясь об их ценности и том, как именно они работают.
Я настоятельно рекомендую изучить Zombie Scrum — это потрясающая книга, а также самая большая библиотека проблем, с которыми может столкнуться ваша команда, если они не учитывают назначение каждого отдельного элемента, который они реализуют из фреймворка.
В чем ваш секрет следования тому, что важно? Поделитесь в комментариях.