Короткая ссылка: AgileDays-2018

Прошла очередная, уже 12 конференция #AgileDays. Как и прошлые конференции, она позволяет составить релевантное представление о жизни Agile-сообщества России, которое за последние пару лет характеризуется мощным развитием, и продвижением за пределы IT-отрасли, включая использование Agile для организации работы госорганизаций, освоение практик бирюзовых организаций, а так же мощное освоение soft skill. Об этом свидетельствует и более 1500 участников конференции.

Но, вместе с тем, на ряде докладов возникает стойкое ощущение де жа вю: тебе рассказывают про поиски пути и решение проблем, о которых ты слышал 5 и более лет назад на прошлых конференциях. И проблемы эти часто связаны с неверным или неполным пониманием agile-фреймворков. Например, с отказом от роли Scrum Master и возлаганием его функций на Product Owner, становящихся очень похожих на продуктовых менеджеров. С понятным результатом: в одних командах проваливается продуктовый фокус, другие - не могут соорганизоваться, третьим - везет, они оказываются слаженные, а PO держит продуктовый фокус. В общем-то все эти результаты можно было предсказать, а не неожиданно обнаруживать...

Хорошая новость - в том, что команды успешно справляются с этим проблемами, о чем и были рассказы в докладах. Но при этом справляются - за счет эмпирических поисков решения, а не за счет опоры на прошлый опыт Agile-сообщества и теоретического знания, которое имеется. И, наверняка преодолеть проблемы получается далеко не у всех - просто те, кто не смог - не выступают на конференциях, а рассказывают, что "Agile не работает".

И здесь надо отметить, что в принципе такая ситуация закономерна в период ажиотажного спроса на новые технологии - а с технологиями Agile мы сейчас имеем именно такую ситуацию. И она связана не только с рекламным hipe, модой и поисками волшебной таблетки, она объективна, поскольку вызовы, приведшие к возникновению Agile в IT идут в другие отрасли. Впрочем, об этом можно прочесть в моей статье Agile - ответ на вызовы нового мира, а здесь я не буду углубляться в тему.

Я лишь отмечу, что такая же ситуация возникает не только в управленческих технологиях - с техническими технологиями ситуация обстоит ровно так же, как было, когда всем компаниям резко потребовались сайты, или мобильные приложения, или интуитивно-понятный интерфейс: профессионализм резко падал и вместо теоретически обоснованных решений приходила эмпирика, которую каждый разработчик накапливал как мог. Но, впрочем, тут необходимо отметить, что в технических аспектах проблема осознана и преодолевается - за счет форумов, общения в профессиональных сообществах, евангилизма новых технологий и многих других инструментах. А в Agile-сообществе по-прежнему практикуются лишь более традиционные формы распространения знаний - тренинги и наставничество, сертификация и стандартизация, на которой и сосредоточен фокус многих институтов распространения Agile. А ведь это все формы - из прошлого, и они плохо работают в новом мире.

Впрочем, думаю, по мере роста разнообразия ситуаций применения Agile, все более будет приходить такое же отношение к управленческому фреймворку, которое присуще техническим фремворкам, когда у тебя есть целостная функциональная структура, узлы которой ты заполняешь элеметами конструкции, реализующими эти функции, заботясь о сопряжении соседних элементов, а не изменяя элементы абы как, с образованием функциональных дыр. Тем более, что уже есть формализм, ориентированный на такой подход - OMG Essence.

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

Первый - рассказ о применении Канбана в Центральном банке, при чем не в IT, а в функциональном подразделении. Очень по делу, с крутыми фишками по организации Kanban-доски, и ясным пониманием решаемых задач, и представлении о достигаемом эффекте. Agile-методы тут выступают как средство, и их внедряют для более эффективной работы, а не для отчета.
Второй - рассказ Павла Рабиновича о применении Agile в школе для организации уроков. Который вписан в существующее нормативное* регулирование школ - оказывается, оно нормирует результат и форму его проверки, а не процесс, который вполне можно перестроить. И особенно импонирует целевая аудитория: речь идет не об элитных школах, действие развертывается в рядовых подмосковных школах, а эффект измеряется из сравнения успеваемости того же класса с тем же учителем при старой организации и при новой - при том, что успеваемость проверяется теми же самыми контрольными работами, они не реорганизуются, потому что являются нормативно определенной формой контроля результата.
А еще был замечательный доклад Александра Горника о бирюзовой организации MindBox с открытыми зарплатами, раскрывающий способы* самоуправления, и путь, которым они постепенно шли к открытым зарплатам, выравнивая перекосы.

На этом я, пожалуй, закончу обзор, и далее соберу те посты на FB, которые я делал на самой конференции. Как обычно, хочу отметить, что я слушал, наверное, 1/8 от общего числа докладов, во-первых, потому что параллельно шло 5 треков конференции и можно было быть только на одном, а, во-вторых, главное на конференции, все-таки, не доклады, а общение, которого у меня было очень много. И на часть интересных докладов я не пошел, потому что на других конференциях уже слышал примерно об этом и предпочел неизвестное. А доклады можно послушать потом, в записи. Хотя, надо отметить, ыто уже несколько лет ScrumTrek ленится и обрабатывает только лучшие доклады конференции, а не все. Это, на мой взгляд, - неправильно, потому что выбирая между докладами на конференции, где часто параллельно идет несколько интересных докладов, ты рискуешь не услышать нужного тебе. Я надеюсь, что все-таки вернется практика выкладывания всех докладов.

Да, на конференции, как это сейчас распространено, вели скрайбинг докладов и пару фоток я здесь публикую. Многие из них вызвали интересное обсуждение на FB, так что стоит сходить по ссылкам.

Заметки с конференции

Пост FB Антон Тарасенко (Anton Tarasenko). Масштабирование команды Agile Бизнес. Проблемная завязка понятна: MVP выкатили быстро, пошел рост бизнеса и рост команды. По мере роста команды возникала специализация по платформам (web, мобилки и т.п.) и по доменам (платежи, мессенджер и т.п.). Проблемы коммуникации. В результате - перешли на продуктовые команды и микросервисные. И команд - fullstack. То есть сделать большую часть задач. В команде - ядро, опытные ребята, к которым добавляем джунов и они обучают.

Что здесь важно: на момент разделения приложения на каждой платформе обычно монолитные (Web, мобильный клиент, CRM, backend), и каждую часть ведет своя команда. Когда мы делаем продуктовые команды, то получаются, что в общий код продукта вносят изменения разные команды. И тут есть два способа борьбы: можно либо разделять это архитектурно, делать микросервисы, либо делать более сложную организационную конструкцию с архитектурным надзором и контролем кода. Тинькофф идет по первому пути, а на #teamleadconf Евгений Россинский из ivi рассказывал про второй путь, при котором бизнес-команды работают с общим кодом приложений, и есть отдельные команды, которые смотрят за приложением в целом, ведут журнал рефакторинга и т.п. Хотя, возможно, эти два пути ведут, на самом деле, примерно к одному целевому состоянию.

Пост FB The Great ScrumMaster. Zuzana Sochova. Модель команды-болота, довольного собой, которую SM должен растормошить и вдохновить... А не снимать напряжения. Понятно, что роль SM зависит от команды и обстановки в ней, и такие команды тоже встречаются. Но тут есть важный акцент: насколько обоснована удовлетворенность команды своим продвижением профессионализмом этой команды. Потому что если команда состоит из людей, которые уверенно и профессионально делают свое дело, то попытка их зажечь и растормошить приведет просто к их демотивации и уходу в другую организацию. Все-таки, SM - помогает соорганизоваться и убирает препятствия, и помощь должна быть запрошена.

Пост FB Сбербанк Онлайн. Святослав Островский. "Недостаток Agile в том, что люди в операционном ритме склонны мельчить, не успевают выглянуть за горизонт". Можно подумать, что в обычных организациях все работают в стратегическом видении, а не текучке. Вывод-то правилен - надо давать стратегическое видение, специально заботиться о показе долгосрочных целей, но agile здесь не причем. Интересно, что они не только это делают через мероприятия, но и в таск-трекере ведут трассировку конкретных задач до иерархии долгосрочных целей, проявляя value.

Пост FB Сбербанк Онлайн. Святослав Островский. Надо продумать, как будет строиться карьера в Agile - многих это волнует. В целом доклад - о том, как скрестить Agile-процессы с традиционной корпоративной культурой. Об этом говорит и вопрос про карьеру, и акцент на получение прозрачности работ, как результат ценностной трансформации и много других маркеров. Но доя организации масштаба Сбербанка это естественно.

Пост FB Сбербанк Онлайн. Святослав Островский. Scrum Master - во второй версии нет роли, ушли. PO играет эту роль, задает ритм команды. Красное лидерство. Минус - они не успевают работать с клиентскими вещами. Зрелые команды ушли от этого. По сути, они идут от паттерна классического менеджмента "один менеджер отвечает за все". У них не получилось обеспечить реальное разделение позиций на PO и SM, заложенное в Scrum и воспользоваться этим преимуществом. В результате PO у них занимается организацией работы команды, и теряет клиентский фокус. Зрелые команды соорганизуются, и этот процесс идет. Вопрос в том, будет ли псевдо-PO, который занимался именно организацией, интересно переключиться на продуктовый фокус? У меня в этом сомнения. Хотя, естественно, все люди разные и кому-то будет интересно.

Пост FB Банк России: знать путь и пройти его — не одно и то же. Николай Арапов, Светлана Иванова (видео). Рассказ про внедрение Agile в Банке России. Они - в начале пути, 3 scrum-команды, 7 - Kanban-команд, первой из них - полгода. Подробный рассказ про канбан, много элементов визуализации на стикерах - разные цвета и размеры карточек, фотки и точки на них, дорожки для разделения работ разных заказчиков и многое другое. Доски - аналоговые, а не электронные, и они становятся "информационными радиаторами", излучая информацию на все подразделение, и давая представление о прогрессе работы. Есть феерические эффекты, когда по проекту, который не запускался полгода, после перезапуска в скрам-команде за 1.5 месяцев получали первую версию или когда проект создания распределенной структуры, который сделать "за год - точно не реально" - тоже выдавал первые результаты через пару месяцев. А в среднем производительность - на 30-40%. Но, я думаю, они точно не измеряли - потому что как померить предшествующие результаты, если трекера задач не было... И я знаю, что это - не единственная госорганизация в России, которая идет этим путем. И я думаю, что в целом это будет способствовать прогрессу нашего государства.

Пост FB Agile и атомный инжиниринг. Сергей Малоземов. Опыт применения agile для адаптации проекта АЭС под требования Евросоюза без увеличения стоимости и увеличения размеров здания. И еще - в краткие сроки. Очень интересно. Хотя я слушал Сергея на AgileBusiness-2017, поэтому убежал на другие доклады.

Пост FB Просто, как 1-2-3: как мы повысили прозрачность 25 команд. Алекс Трошин (Alex Troshin). Конкретный набор метрик, за которым смотрят за здоровьем разработки у 25 разнородных команд. Для начала - проанализировали процесс, у каждой команды свой workflow в jira - и они выделели основные состояния, которые есть везде (об этом был отдельный доклад). Очень простые: число задач in progress, число приостановленных (waiting), и число на приемке (чтобы не завязывали бантики бесконечно). Нормировано на число людей в команде, светофорная модель сейчас и по средней за две недели. И отдельно - метрика забытых задач, по которым долго не было движения. И результат достигнут - точку проблемы он видит раньше, чем руководство. А улучшения - пока на уровне команды, но в перспективе можно тоже придумывать метрики.

Метрики - простые, и можно пробовать примерить их на свою команду.

Пост FB Проекты, меняющие школу: Agile-трансформация. Павел Рабинович (Pavel Rabinovich). Я об этом рассказывал, суперинтересный проект по изменению содержания уроков в школе, переводу их на адаптированный скрам. И фишка в том, что это встраивается существующий нормативный процесс в школе. Оказывается, стандарт нормирует результат и ограничивает условия, а остальное - на инициативе и можно перестраивать по-своему. И вот тут принципиальное отличие от мегапроектов по кардинальной перестройки содержания школьного образования: те требуют изменение системы, а эта - встраивается внутрь существующей системы, при чем они следят, чтобы каждая сельская школа могла применить. И это меняет мир прямо сейчас.

Пост FB От выполнения бизнес-требований к решению бизнес-задач. Евгений Абрамзон. Рассказ о том, как MVideo задумался о value конкретных задач, которые IT делает и начал его мерить, по сути рассматривая задачу как мини-проект и оценивать возврат инвестиций, а при планировании - выбирать наиболее перспективные по этому критерию, а не просто стремясь не обидеть любого из стейкхолдеров. У них получилось, по пути выяснили много интересного. Например, то, что бизнес часто приносит гипотезу о ценной фиче, но не просто не готов оценить примерный эффект, но даже не представляет, как его можно было бы измерить. Впрочем, это - старая новость, работать на уровне возврата инвестиций и оценки финансового эффекта умеет не так много людей. А еще проявилось, что разные подразделения-заказчики имеют разные целевые KPI, и потому их текущие представления о приоритетах конфликтуют между собой, хотя в теории все должно трассироваться на уровень удовлетворенности потребителей. Но процесс - идет, за год достигнуты результаты. Доклад - интересный, по сути это - о разнице между Task Stream и Value Stream и контроле за ней.

Пост FB Пименов. Agile - на hipe вызывает bandwagon эффект: "все берут, и я беру, все говорят, что работает - и я скажу". И петля затягивается.

Пост FB Основы Business Agility. Алексей Пименов (Alexey Pimenov). Доклад вбрасывает достаточно много концептов, но вот их сопряжения я не чувствую. Поэтому краткий конспект для памяти.

Совершенно правильный тезис о том, что Agility - внешнее свойство компании, а методы Agile - способы организации, с помощью которых можно обеспечить Agility, а можно обеспечить что-то другое. И наоборот, Agility можно обеспечивать другими способами, в том числе классического производства. Agility - это Fitness for Purpose.
Концепт цепочки создания ценности, где в финале - восторженные пользователи. А перед ними - ценность - продукты и услуи - поизводство. И мы выстраиваем по этапам-слоям. И это можно делать в одной команде, а можно - выстраивать в цепочку. И в цепочке может быть сочетание разных способов организации работы - это верно.
Но! развернув проблемы agility и хрупкости в принципе не говорят о том, как эту ценность предугадывать. Примеры - несколько о другом. Zara - это последователи за лидерами, которые научились это делать очень быстро, даже опережая лидеров. Clever перенес на книжный рынок выпуск новых коллекций с распродажами. Да, удачно, и это - отдельные модели. Ну и что? Есть много удачных моделей у разных компаний.

Пост FB Самоуправление и открытые зарплаты. Александр Горник (Alexander Gornik) (видео). Mindbox, 70 человек. Рассказ о самоуправляемой компании с открытыми зарплатами и минимальным менеджментом - все задачи едут по конвейерам Kanban. Утверждения и согласования запрещены, но есть право вето, после которого - переговоры. Ответственность связана с исполнением: написал код - правь ошибки, собеседовал - решай про испытательный срок. Критерий автономности: есть метрика, и руководство может вмешиваться только в случае, если она нарушается. Сначала сформулировали запрос на необходимость такой метрики, потом - договорились о метрике. Командные собеседования. Были эксперты, а это оказалось круче. И на собеседованиях - рассказывают истории. "Расскажите, когда вам было интересно" - это не сыграешь. И сразу вопрос - а сколько вы хотите денег. И когда человек его озвучивает в начале собеседования - совсем разные отношения.

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

Начали открытие зарплаты новичков - на собеседованиях. Потом выравнивали ведущих, 1.5-2 года занял процесс и два года открыты. И пока не убедились в адекватности между зарплатами и взаимной оценки - не открывали. Для типовых позиций - грейды с вилками. Но грейды - непросто, 10 лет работали над грейдами для разработчиков, по сложности задач разработки или проектирования.

Пост FB Очень важный для меня урок доклада Александр Горник (Alexander Gornik) отчасти парадоксален. Как человек, хорошо разбирающийся в концептах бирюзовых организаций я вижу, где именно идет вольная интерпретация и упрощение, и где не выдержаны акценты идеальной конструкции. Но это упрощение совершенно не мешает созданию работоспособной, эффективной и очень хорошей организационной системы компании. И первая мысль, после того, как это понял - что это касается только организационно-социальных конструкций, в инженерных все строже. А вторая мысль - нет, и в инженерных тоже самое. Мы начинаем использовать фреймворки без глубокого освоения концептов, у нас получается, рассказ об этом тем, кто глубоко разбирается - часто вызывает с их стороны негатив: "разве можно было так поверхностно разобраться и делать поверхностные вещи". Но софт-то при этом работает. И тут можно возмущаться "да, но он же с плохой архитектурой", а можно принять как должное, потому что в нынешней динамичной разработке фреймворков и концептов иначе - нельзя, стройных учебников не будет. И вот получить с неполными представлениями работающий софт - типично айтишный современный скилл. А теперь - он распространяется на социальные и организационные конструкции - что, на мой взгляд, даст быстрое развитие.

Пост FB Agile как эксперимент в Газпром нефть. Нина Сухова (Nina Suhova). Главное, чему научил Agile - он научил мечтать. А еще - позволил создавать новые продукты и изменил корпоративную культуру, привел ее к культуре согласия - и это приняло правление. А еще - имидж на рынке труда. Это - мое краткое изложение, но в нем очень сконцентрировано изложен смысл использования gile в крупном корпоративе: размораживание корпоративной структуры и привнесение умения мечтать, которое в крупном корпоративе почти атрофируется.

Пост FB Agile как эксперимент в Газпром нефть. Дмитрий Гончаров. В команду пришли руководители: "Мы будем в команде". - ОК, разбираем задачи - Нет, мы не в команде, мы вам дадим других - тех, кто будет работать в команде. С третьего раза взлетело. Было заблуждение, что молодые все хотят по Agile. Ан, нет. В традиционную компанию приходят люди, ориентированные на традиционные ценности, вертикаль и понятный рост по ней. Так что получался нежданчик :)

Пост FB Алексей Воропаев (Alexey Voropaev) - опыт АльфаСтрахования ОМС - реинжиниринг IT-ландшафта. Очень понятное содержание доклада. Концентрированный путь в Agile, с инженерными практиками, с осознаванием роли. Путь проходит самостоятельно, потому что коучи на рынке - супер-дорогие. Уроки тоже понятные. Не всякий разработчик хорошо работает в Agile. Коммуникация своя не заводится, надо организовывать. Денежная мотивация, премии - не работает, и, более того - мешает.

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

Оригинал на FB Алексей Дерюжкин

Пост FB В конце конференции был круглый стол с экспертами (и я там участвовал). И получилось, что нас неплохо потроллили парой вопросов. Сначала был вопрос о том, почему тренеры продают процессы, если Agile - про ценности. Ну, на него высказались все по разному, но с общим смыслом про две части.

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

Но, в любом случае, это хорошо проявляет место ценностей в сознании экспертов... Увы, включая меня. Поэтому, кстати, я завершу свой пост схемой Agile на модели Кораблика, которая совмещает ценностную и процессную составляющие компании.