Автор канала Асхат Уразбаев, основатель ScrumTrek, Архитектор Процессов и прочии регалии, потом текст доправлю. Наверное.

Agile Coach либо полезен в компании, тогда он занимается Agile от силы 20 процентов времени, либо не нужен.

Последнее время много собеседовал Agile Coaches, поработал внутри, посмотрел как устроено в разных конторах. Мой вывод — если Agile Coach занимается Agile - (все эти наши ретры и планирования), то от него гораздо больше вреда чем пользы.

Поясню свою крамольную мысль тезисно:

✅ За 10 лет сменился стек и поставка стала проще, спасибо за это микросервисной архитектуре и девопсам. Большая часть контор в принципе деливерит норм, может как-то независимо выводить сервисы в прод и даже ± покрывает тестами.
✅ Большинство команд работает по Scrum норм. Есть какие-то бэклоги, что-то показывают, даже планируют. И даже если это не так — поправить можно за пару месяцев, это не full time job. Можно улучшить (всегда можно улучшить), но болит у организации почти всегда в другом месте.
✅ В большинстве контор главная проблема кроется в процессах, которые находятся вне классической зоны внимания Agile Coach, например целеполагание, управление продуктами, оргструктура, платформы, управление знаниями, you name it.
✅ И самое главное: культурно-философская трансформация, которой вроде как должны заниматься коучи в целом завершена. Как нибудь отдельно напишу про менеджмент в ревущие 90-е, но в целом относиться к людям мягче, а на вопросы смотреть ширше люди научились. Это не напоминает розовые сопли мечтателей, но тем не менее гораздо лучше, чем при царизме.

Тут вы должны уже закричать — я и так занимаюсь всем чем угодно, только не Agile! Слушайте, вам не кажется что слово Agile Coach нас жестко ограничивает, господа? Три тезиса почему это плохо:

1️⃣ Ты должен заниматься Agile, а в него НЕ ВХОДИТ ДАЖЕ КАНБАН (только не говорите своему менеджменту), не говоря уже о прочих полезных инструментах типа OKR или DevOps!
2️⃣ Coach! Серьезно? Получается, раз я коуч, мне и пиздюлей навешать нельзя? А если надо для пользы дела? А вы видели как они джиру ведут? (c)
3️⃣ Раз уж вы Коуч по названию, то рано или поздно вас затянет учиться классическому коучингу и пропал человек! Дальше постепенная деградация: начнете с ненасильственного общения, увлечетесь гештальт-терапией, потом цигун, холотропное дыхание и нумерология.

Так что делать? Давайте хотя бы переименуемся?

Когда я был молодой и гораздо более бодрый, до эпохи Agile, я занимал позицию Process Architect. В этом названии мне нравится все: слово архитектор добавляет веса в глазах окружающих. Слово Process означает, что ты не обязан ограничиваться рамками инструментов и философских концепций. Ну и перевести на русский можно гораздо проще.

Долой Agile Coaches! Да здравствуют Архитекторы процессов!

@askhatonline

Так, добавил комментирование, но после публикации поста☝️ так что там оно не работает. Если хотите мне навалить, давайте в этот пост

Внезапно (примерно как на картинке) придумал шутку к прошлому посту, но уже поздно

Почему Agile Coaches часто выглядят как воинствующие фанатики

Меня часто спрашивают (и это правда) почему все Agile Coaches выглядят как воинствующие фанатики?

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

Но курсы тут не причем.

Нет, друзья, теоретические знания о подходе не делают тебя фанатиком! В реальности, ты очень сомневаешься и комплексуешь перед тем, как попробовать первый раз. "Э-э-э-э может попробуем оценить в стори-пойнтах? 😬😬😬 Говорят, классная штука. Нет? Ну ладно... 😩".

Давайте историю расскажу. Когда то очень давно (20 лет назад?) в Люксофте я собеседовал человека на должность процессного инженера. Он поведал действительно впечатляющую историю как он внедрил Code Review у себя в конторе и как им это помогло. Супер, даю кейс на разбор. Товарищ: я бы тут внедрил Сode Review бла-бла. Ну ок 🤷‍♂️. Даю второй кейс. И опять: тут бы нам помогло Code Review. Пытаюсь навести на другие возможные решения — нет, только Code Review! Даю кейс, где Code Review вообще не пристегнуть. Так и в этом случае нас спасет Code Review! Я уже кричу: "Да почему Code Review опять!??". Товарищ смотрит на меня горящими глазами и говорит: "Да чем вам Code Review не нравится??? 👿👿👿".

Именно успешный опыт превращает тебя в фанатика метода. Внезапно у проблемы есть решение и оно точно работает. Ты знаешь ПРАВИЛЬНЫЙ ПОХОД. Ну дружище, теперь от тебя не скрыться 😀 На каждом углу ты будешь рассказывать про свою волшебную пилюлю всем, кто готов слушать. Ты придумаешь, как ее применить в соседних сферах. Прикрутишь к ней сакральность, построишь вокруг философию и найдешь исторические аналогии. С тобой будет тяжело общаться! Жена будет избегать внедренных тобой в семье стендапов, а дети возненавидят слово бэклог 🙃.

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

Этот фанатизм улетучивается после череды провалов. После первого-второго ты еще будешь винить "не таких" людей, "неправильную" культуру и недалекое начальство. По настоящему тяжелый удар фанатической вере нанесет другой подход к той же проблеме, который сработает. После рефлексии ты поймешь, что, оказывается, все немного сложнее. Ты разучишься видеть ПРАВИЛЬНЫЙ ПОДХОД. Мир превратится в гораздо менее детерменированный. Есть много вариантов решения. Черт его знает, что сработает. Надо пробовать...

Твой арсенал методов сильно вырастет. Ты увидишь множество проблем и еще гораздо больше методов решений. Например, обнаружишь, что ничего не делать тоже работает 🤭.

Стал ли ты эффективнее как профессионал? Конечно! Ты стал опытнее и мудрее. Но со знаниями пришла скорбь и ограничения.

✅ Например, раньше ты четко знал, что правильно, а что нет и мог дать ответ на любой практический вопрос. Теперь это в прошлом. Alistair Cockburn на все вопросы отвечает "everything depends on everything". James Coplien изворачивается фразой "Scrum doesn't say...". Теперь и ты отвечаешь "можно по разному делать" и твои ответы никому не нравятся.
✅Раньше твой фанатизм вел за собой. Твоя кипучая энергия и уверенность в итоговом результате заражала людей. Теперь ты душнила, потому что преисполнен сомнений.

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

Так что вперед к очередному провалу! Вам аджайл коуч не нужен случайно? (это шутка)

Саша Андронов прислал статейку как они выстраивают в роли в команде в DoDo Engineering. У них есть 4 роли в команде: PO, TechLead, People Lead и Process Lead. Последний как раз и отвечает за процессы. За это прям 🔥 летят Саше:

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

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

Продакт, техлид и People&Process Lead. Тройка, которая рулит продуктом

Что не так с софт-скилами? Да все с ними так!

Вот эта цитата отсюда задела какое-то невероятное количество людей:

Раз уж вы Коуч по названию, то рано или поздно вас затянет учиться классическому коучингу и пропал человек! Дальше постепенная деградация: начнете с ненасильственного общения, увлечетесь гештальт-терапией, потом цигун, холотропное дыхание и нумерология.

Кое-кто (кое-кто) даже в запальчивости стал утверждать, что Асхат (основатель ScrumTrek на минуточку!) отрицает важность soft skills у аджайл коучей🤔. Тут конечно же сразу со Мной Сразу Все Ясно (всегда интересно на каком по счету комментарии это выяснится). Нет, друзья аджайл-коучи, софт скиллс — это супер важное оружие в попытке добиться целей и учиться им нужно обязательно. Powerful Questions, Active Listening, Conflict Resolution просто часть профессии!!! Не умеете — вы не Agile Coach! И не Process Lead 🙂 Вы просто не сможете работать.

Более того, не бывает бессмысленных НАВЫКОВ. Нравится вам психотерапия, ради бога! Еще один источник дохода, чего нет? Но нужно ли тащить связанную с ней ПРАКТИКУ в команду, с которой вы работаете? У члена команды клиническая депрессия? Он должен пойти к профильному специалисту! У вас ДРУГИЕ ЦЕЛИ!

КРИТИЧЕСКИ важно отличать полезные ПРАКТИКИ от бессмысленных и вредных.

Два реальных примера из жизни:

1️⃣ Компания, где бизнес и разработка вусмерть разосрались и закидывают друг друга какашками через забор. Что делает Agile Coach? Организует мастер-майнд группу для бизнеса, где они обсуждают "Как Общаться с Айтишниками". Фиг знает зачем, наверное потому что они грустят, а вместе не так грустно. Боже, вот пишу это и меня бомбит жестко. БУКВАЛЬНО твоя работа перестроить взаимодействие между ними! Что нужно делать? Выяснить в чем ПРОБЛЕМА (например, PO пишут документы / не участвуют в планировании). Теперь эту проблему надо помочь решить. И тут вам понадобятся буквально ВСЕ софт-скиллы.

2️⃣ Команда не перформит. Все ей недовольны. Сама команда ругается внутри и с коллегами снаружи. И конечно Agile Coach проводит для них тренинг по ненасильственному общению. Ну почему нет, действительно? Ругаются же. Сейчас научим не ругаться. Но этом тестов нет, билд собирается сорок минут, ни разу в прод без критических багов не выходили!!! Как вы думаете, помогло ненасильственное общение это исправить? Риторический вопрос. Теперь вместо решения технических проблем обсуждаем нюансы модели потребностей. Может все таки идентифицируем проблему? Поможем составить план решения? Договоримся с бизнесом? Почему это не сделано?

Успешный Agile Coach добивается целей бизнеса. Он идентифицирует проблемы. Он использует для этого ПОДХОДЯЩИЕ инструменты. Софтскиллы критически важны, но они не являются целью. Решать надо ПРОБЛЕМЫ.

Группа коллег выпустила Product Map https://www.productmap.pro — карту знаний продуктового менеджмента. Это огромный классификатор в фигме, описывающий все, что нужно знать продуктовому менеджеру. Есть даже обзор AI алгоритмов. Его поддерживает сообщество экспертов (в основном наши ребята, часть я знаю). Как по мне, достойная работа!

Зачем идти в консалтинг?

Проводил давеча глубинки начинающих консультантов и хочу вам поведать, зачем люди хотят идти в консалтинг. Так сказать минутка бесполезной информации.

* Широкий Импакт. В отличие от работы в одной компании, где твое влияние ограничено коллегами и пользователями, в консалтинге ты затрагиваешь множество организаций и их клиентов. Плюс, выступая на различных мероприятиях, ты сможешь влиять на людей, о которых даже не подозреваешь, предоставляя ценные советы и знания.
* Возможность применить свои навыки. В родной конторе ты занимаешься плюс-минус одним и тем же. Хочется более широкого фронта для применения своего опыта и знаний, накопленного за годы карьерных странствий.
* Профессиональный рост. Консалтинг выглядит как способ сталкиваться с большим количеством сложных задач. Действительно, никто не позовет консультанта делать простую работу. Также от себя добавлю, что консалтинг здорово увеличивает насмотренность, которая важна для многих профессий.
* Доход. Консалтинг как способ повышения дохода упоминался, хотя далеко не всеми участниками опроса.

Есть что добавить?