[Перевод] Дорогой Agile, мне надоело притворяться
«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.
Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.
Вот вам тест. Как начинается первая строка манифеста Agile? Не подглядывать. Не знаете? Всё в порядке. Это не имеет значения. Там говорится: «Мы открываем более совершенные методы разработки программного обеспечения…» Стоп. Заметьте, написано: «разработка программного обеспечения». Там не говорится: «вытягивание вашей организации», «погашение долга за трансформацию», «выкраивание его с помощью этого командно-контрольного дерьма», «сосредоточение на результатах и улучшение работы по открытию», «исправление вашей средневековой системы бюджетирования» или любой ещё более продвинутой добавленной ценности, которую люди пытались в него вложить. Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это альтернативная история. Это нечестно.
Заметьте также, что он начинается «Мы открываем…» Он не говорит: «Мы получили свыше…» Вам не кажется, что с 2001 года мы кое-чему научились? Я имею в виду, да, большинство крупных организаций всё ещё застряли в 1987 году, но ладно вам. Вопреки распространённому мнению, фотография ниже на самом деле не из акта подписания Манифеста. Можем мы наконец перестать притворяться?
Манифест служил определённой цели, но он не приведёт вас туда, куда вам нужно. Так что приступайте к учёбе. У наших знаний есть срок годности, и не такой большой, как мы думаем. У всех есть коллеги (обычно начальники), которые утверждают, что у них «нет времени учиться». Вы сами знаете, что они слишком самоуверенны в своих знаниях. Так что найдите хороший список книг. Следите за хорошими блогами. Вот для начала: если вы не читали Sense & Respond, Lean Enterprise, A Seat at the Table и Everyone Is a Change Agent, предлагаю сделать это немедленно. И вашим начальникам.
Начните читать посты Джона Катлера, Мелиссы Перри, Боба Маршалла, Аллена Холуба, Лоры Кляйн, Эрики Холл, Нила Киллика и тех, на кого они ссылаются. Они все согласны друг с другом (или со мной)? Нет, но они умны и вас тоже сделают умнее. Приступайте к чтению и поощряйте других. Fast Company говорит, что средний генеральный директор читает 60 книг в год. Сколько книг читают ваши руководители? И что они читают? (Статьи HBR, репортажи Gartner и романы Мейв Бинчи не в счёт). Потому что давайте посмотрим правде в глаза: если ваши руководители мастера Scrum, то вы прочно застряли в 80-х и 90-х годах.
Давайте перейдём к непрерывному обучению и перестанем притворяться, что Agile — какое-то лекарство. Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы. Только Agile несправедливо вынес под микроскоп команды разработчиков программного обеспечения. Это никак не повышает организационную гибкость. НИКАК. Интересно, что, по словам Кена Швабера (см. его «Небезопасно на любой скорости»), Agile был попыткой «компенсировать ущерб, нанесённый водопадом», и всё же никогда не давал организациям целостную, жизнеспособную альтернативу водопаду. Потому что есть разница между теорией и практикой. Работа над продуктом — это скорее практика. Когда мы жалуемся на AINO (Agile In Name Only), мы не честны с самими собой.
Теория против практики, помните? Мы должны быть прагматичными. Agile на практике почти всегда AINO. Похоже, проблема с самим движением, не так ли? В любом случае, есть более важные вещи, о которых нужно узнать, включая (но не ограничиваясь) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, организационная терапия Маршалла и т. д.
Вы спросите, почему Lean UX возглавляет список? Из-за того, что по своей сути Lean UX популяризует концепцию ориентированности на результат. Подумайте: если вы не знаете, какое изменение поведения пытаетесь создать, то не будете понимать свои действия. Если у вас нет однозначной сигнализации «поворота» (pivoting), то вы уже не можете быть гибким. Вот что такое Agile, в конце концов, это pivoting. Некоторые могут возразить: «Но-но-но, проверять и адаптироваться!» Конечно. Теория против практики, помните? Я не вижу гибких команд, которые проверяют и адаптируются. Я вижу, как команды Agile пытаются наверстать отставание, возятся с Jira и Rally и работают так, будто строят кирпичную стену по приказу.
Agile на самом деле имеет тенденцию маскировать основную проблему — это системное, двунаправленное отсутствие вертикального доверия. Коачи Agile уходят, ухудшив ситуацию: они оставляют после себя менеджеров, говорящих на поросячьей латыни, и команды разработчиков, которые перешли на эсперанто. Команды считают, что управление сломано, а руководство считает, что основное внимание по-прежнему надо уделять объёму, срокам и эффективности, игнорируя, что сроки являются произвольными, а оценки времени являются формой отходов. (Знаете ли вы, что стори-поинты на самом деле изобрели, чтобы скрыть время и помочь решить саму проблему? Здесь тоже появились неприятные последствия, не так ли? Теория и практика).
Угадайте, кто победит? Два лагеря с двумя радикально разными перспективами, где один лагерь получает оценки от другого? Если команды похожи на слепых, которые чувствуют слона и не согласны с тем, что это такое, то руководство похоже на слепых слонов, наступающих на людей и соглашающихся, что они все плоские. Выход в том, чтобы признать, что система — это команда. Кончайте уже с локальными оптимизациями и осознайте, что доверие — это проблема №1. Перестаньте несправедливо помещать разработчиков под микроскоп, позволяя остальным прятаться в чёрном ящике. (Почему нас не интересует, как работают команды стратегического развития? Или как архитекторы легаси являются ограничениями в системе?)
И пока мы этим занимаемся, следует перестать относиться к командам разработчиков так, будто они работают на заводе. Мы не штампуем пластиковую посуду. Мы создаём программное обеспечение. Нужно перестать вести себя так, будто мы заправляем пиццерией. Здесь другие правила. Мы не используем один и тот же проверенный рецепт. Мы разрабатываем рецепты. Если вы ещё не поняли, это работа по открытию, а не просто доставка. Пренебрежение открытием приводит к массовым потерям: неиспользуемые функции и другая работа, которая не достигает результатов. Это обнажает ещё один глубокий недостаток Agile. Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его». За исключением того, что дерьмовый продукт обычно таким и остаётся, не так ли? Будущие улучшения становятся ненужными «затратами».
Но-но-но, Agile действительно нацелен на исследования! Правда? Будем честными. Теория против практики, помните? Если вы зарабатываете на жизнь проектированием или исследованиями, то ответьте на этот вопрос. Как вы обычно относитесь к работе с гибкими командами? Вас изначально рассматривают как ценность и просят помочь «проверить и адаптировать»? Или вас просят «доказать свою ценность»? Как сказал Алан Купер, когда вас просят «доказать свою ценность», вам ясно дают понять, что вы находитесь в системе, которая вас не ценит. Обратите внимание, что они просят отдельного участника доказать свою ценность — они не спрашивают, какая часть их кода на самом деле смещает показатели в правильном направлении. Другими словами, они по-прежнему фокусируются на людях, а не на самой работе. Вероятно, они всё ещё сосредоточены на костах, а не на ценности, игнорируя те области, где значительная часть ценности фактически утекает.
Если вы работаете с гибкими командами, в следующий раз, когда вас попросят «показать свою ценность», попробуйте это. Начните задавать им вопросы. Знают ли они, какова цена задержки? Какие упражнения они используют для оценки этого параметра? Каких конкретных результатов они пытаются достичь? Какая доля их продукта фактически достигает своих показателей? Они не знают? Если есть более быстрые и дешёвые способы узнать, что разрабатывать, кроме как просто выпускать код, заинтересованы ли они в обучении? Какова их эффективность потока? Насколько всё плохо? Сколько времени они проводят на собраниях? Если есть дизайнерские игры и упрощённые действия, которые приведут к лучшим решениям за гораздо меньшее время, они заинтересованы в обучении? Потому что я не просто покажу вам свою ценность — я научу вас создавать больше ценности во всём, что вы делаете.
Это другой способ мышления. Это мета. Это стратегически. Как отмечает Остин Говелла, и Agile, и водопад сосредоточены на разработке. Дизайн — это проверка. Если они не заинтересованы, можно уходить. Если они просто опустив головы выпускают продукт, фокусируясь на издержках, то никогда даже не узнают достаточно, чтобы понять, что вы, как правило, получаете больше того, на чём фокусируетесь (гм, косты). Это фабрика по производству функций. Круговая порука. Они притворяются, что создают пластиковую посуду. У вас есть дела поважнее. Потому что реальная ценность обеспечивается опциями, которые генерируются путём исследования. Чем больше опций вы создаёте и чем более гибок ваш подход, тем больше возможных путей к лучше результат. Чего они пытаются достичь? Исследовали ли они три-пять способов достижения этой цели? Это приведёт к лучшему принятию решений на перспективу. Одна опция — это не выбор. Два — это дилемма. Три — теперь вы кое-чего добились.
Когда-нибудь слышали о Законе необходимого разнообразия? Компонент с наибольшим количеством опций управляет системой. Примените это к тупой борьбе за власть «Agile против водопада». У вас были руководители, которые пытались сохранить контроль над системой сверху, и гибкие команды, которые пытаются приблизить ценность к источнику (реальные пользователи и клиенты). Выход из бессмысленной гражданской войны — научить людей генерировать варианты на всех уровнях. Путь вперёд — не «Agile против водопада». Это умная стратегическая работа сверху вниз (водопад) с эмпирически-ориентированными тактиками снизу вверх. Дизайн и открытие помогают в обоих случаях.
Так… каков выход? Это разумный фокус на чётких результатах, а не на выдаче, с запланированными результатами вместо запланированных отметок, не с проектными, а с надёжными продуктовыми командами, уполномоченными проверять предположения и находить кратчайший путь к ценности.
Теперь к обучению (адаптировано на базе диаграммы Джона Катлера).
Так… значит, Agile уходит? Конечно, нет. Это просто глупое сообщение в блоге. У меня нет никакой власти. И если бы даже была, Agile всё равно не исчез бы. Движение Agile сделало возможным появление многих из упомянутых концепций. Кроме того, вопреки распространённому мнению, гибкие практики не были изобретены движением Agile. Они появились на десятилетия раньше.
Так что нет, я не хочу, чтобы Agile уходил.
Я просто хочу, чтобы мы стали честнее.
