Что такое agile трансформация бизнеса
Что такое Agile: методология, команда, оценка эффективности
Рассказываем, что представляет собой лежащая в основе методология, раскрываем основные понятия, объясняем, как устроена agile-команда и как оценивается ее эффективность.
Agile — это целое семейство методологий гибкого управления проектами. Интересно, что само понятие управления здесь оказывается не вполне верным. Было бы более точным употреблять формулу «Agile — это способ командного взаимодействия, позволяющий совместно создавать продукты». Однако мы слишком привыкли к силе вертикальных, иерархических связей, поэтому и здесь устойчивым стало употребление слова «управление».
Неудобные вопросы
Управленцы самого разного уровня, от менеджеров низшего звена до директоров корпораций и государственных чиновников, бились над этим десятилетиями. Но до тех пор, пока единственным известным способом более-менее контролируемого создания продуктов и разработки проектов оставался поэтапный — шаг за шагом, одно за другим, — ничего с этими вызовами было не сделать.
Для того чтобы перейти на качественно новый уровень проектной работы, потребовалось коренное изменение парадигмы.
Оказалось, что искать ответы на большинство этих больных вопросов просто незачем. Их нужно снять, а понятия, их породившие, по возможности упразднить. Так на месте поэтапной waterfall-разработки возникли гибкие методологии.
Делай сразу!
Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это как в знаменитой мотивирующей формуле: «„Сделано“ — это лучше, чем „идеально“». Реализуйте первую функцию и начните тестировать её, создавая следующую, и так раз за разом — вот главное правило.
Этап разработки в Agile, это самое «раз за разом», называется итерацией. Итерации имеют одинаковую длительность на протяжении всего проекта и в среднем составляют две недели. В рамках отдельной итерации выполняется конкретная задача, главным свойством которой является то, что ее решение должно обновлять продукт до новой версии или увеличивать его эффективность. Именно по этому признаку такие задачи и отбираются.
Как итеративный подход обеспечивает гибкость? Благодаря тому, что отдельные процессы могут идти параллельно и независимо друг от друга. Да, надо признать, что это может увеличить конечный срок разработки от идеи до полностью готового продукта. Но в том-то и дело, что рабочий, функциональный и уже способный встретиться с конкурентами и порадовать пользователей продукт создаётся в Agile гораздо раньше, а цикличность доработок позволяет добиться куда лучшей проработки таких функций и возможностей, до которых при плановой работе руки бы не дошли никогда.
Горизонтальная организация
Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле — лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах ему, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.
Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:
Ещё одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.
Важно!
Но иметь базовые знания о смежных специализациях в гибкой разработке необходимо.
Изначально предполагалось, что это просто будет повышать эффективность работы и уровень взаимопонимания в команде, но сегодня, с развитием нейронаук, стало понятно, что такой подход вдобавок обеспечивает поддержание мозга в тонусе и динамичное создание новых нейронных связей. Такое «перекрёстное опыление» знаниями в Agile называется t-shape. Иллюстрация ниже объяснит, почему так, лучше всяких слов.
Как внедрить Agile?
Переход от каскадной разработки, до сих пор привычной для многих организаций, к гибким методам работы над проектами может быть довольно болезненным.
Во-первых, вам предстоит упразднить иерархичность и при этом добиться того, чтобы все участники процессов смогли на равных разделить ответственность за результат.
Во-вторых, переход к итеративной разработке заставит сосредоточиться на том, чтобы каждый из этапов гарантированно привносил в продукт что-то новое. Это непросто, инерция плановой разработки будет преследовать вас первые несколько месяцев.
Третий вызов — если вы ведёте заказную разработку, будет непросто объяснить клиентам принципы работы, а если входите в состав крупной организации, та же проблема может возникнуть при обосновании перехода на Agile перед вышестоящими руководителями.
Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается Манифест гибкой разработки:
Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.
Лучше познакомиться с Agile и другими современными методологиями, применяемыми в сферах от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы вы сможете, пройдя курс «Руководитель digital-проектов» от Skillbox.
Основы Agile-трансформации
Хочу поделиться переводом краткой, но достаточно толковой шпаргалки по Agile-трансформации.
Чтобы достичь успеха в сегодняшней рыночной ситуации, компании должны быстро поставлять клиентам качественный инкремент продукта (product increment – «ощутимый результат работы одного спринта» (например, новая функция продукта, прототип приложения и т.д.) — te-st.ru/2017/07/04/12-terms-of-scrum).
Не менее важно быть гибкими и уметь реагировать на обратную связь, полученную от клиентов. Это означает переход к гибкой стратегии от преобладающего сейчас традиционного подхода к организации, управлению и финансированию работы.
У маленьких компаний Agile-трансформация, скорее всего, не вызовет затруднений, так как внедрение этой стратегии можно осуществить, просто собрав всех в одной комнате и договорившись между собой.
Однако в больших организациях со сложной структурой и тяжелой «наследственностью» в виде устаревшей технологической архитектуры трансформацию нужно тщательно спланировать и организовать, чтобы быть уверенными в том, что усилия и инвестиции, вложенные в процесс изменения, создадут ценность для бизнеса и действительно приведут к тому, что компания станет гибкой и легко адаптирующейся к изменениям.
Agile-трансформация – это работа по реорганизации компании, в результате которой она сможет работать по принципам Agile.
В чем смысл Agile-трансформации?
По большому счету, Agile-трансформация – это история о том, как создавать команды, формировать бэклог и регулярно поставлять инкременты протестированного и работоспособного программного обеспечения. В масштабе более крупной организации – это создание сети слабосвязанных команд, координация зависимостей, работа с негативными последствиями, быстрый вывод продукта на рынок, а также измерение пропускной способности команд, а не их производительности.
Смысл Agile-трансформации – как раз в устранении препятствий, которые мешают выполнению всех этих действий.
Стратегия трансформации
Отправной пункт Agile-трансформации – это понимание, где ваша компания находится в данный момент и куда вам нужно двигаться. Чтобы ответить на этот вопрос, необходимо разобраться с двумя понятиями.
Во-первых, следует учитывать ценностные установки вашей компании в контексте планирования. Что для вас более ценно – предсказуемость поставки или способность адаптироваться к изменениям? Для большинства компаний ценным является и то, и другое, и это приводит к негативным последствиям.
Чем более вы настраиваете систему на предсказуемость, тем сложнее ее изменить. И, наоборот, чем больше вы придаете системе адаптивности, тем она менее предсказуема.
Второе, о чем стоит серьезно подумать, — это в чем заключается ценность вашего продукта для клиента с точки зрения планирования. Стараетесь ли вы понять, что нужно вашему клиенту (мы называем это открытой экосистемой – emergent ecosystem), или же вы сосредоточены только на выполнении взятых на себя обязательств (мы называем это замкнутой экосистемой — convergent ecosystem)?
Наша система координат
Мы построили матрицу 2х2, четыре сектора которой помогут вам понять, где ваша компания находится сегодня и решить, в какую сторону вам нужно двигаться, чтобы получить те бизнес-выгоды, на которые вы нацелены.
Путь к адаптивно-открытой компании часто идет через сектор предсказуемости (predictability) и замкнутости (convergence), затем через адаптивно-замкнутый сектор (convergence-adaptability) и только потом достигает адаптивно-открытой части матрицы (adaptability — emergence).
Весь процесс строится вокруг образования команд, определения модели управления по принципам Agile, а также выбора и принятия в качестве отправной точки тех метрик, которые
важны для компании – они будут использоваться для измерения и отслеживания улучшений.
Ваша стратегия Agile-трансформации в конечном итоге будет зависеть от системы ценностей вашей компании и от системы ценностей ваших клиентов.
10 шагов к Agile-трансформации
Самое важное – это понять, как правильно планировать, чтобы трансформация обеспечила регулярные инкрементные поставки бизнес-ценности. Цель в том, чтобы изменить способ выполнения работы. Возможно, вы уже двигаетесь от практики «большого взрыва» – редких и крупных релизов – к регулярным и небольшим поставкам. Управление трансформацией нужно осуществлять точно так же.
Несмотря на то, что Agile-трансформация одной компании не похожа на другие, обычно все компании проходят следующие этапы:
Шаг 1. Сформируйте команду лидеров
Agile-трансформация потребует внедрения изменений во все элементы бизнеса, и поэтому будет нужна поддержка руководства. Удостоверьтесь в том, что топ-менеджеры с вами заодно и в курсе того, что будет происходить.
Шаг 2. Определите видение конечного состояния
Конечно же, нам нужно понимание того, куда мы идем, прежде чем начнем двигаться. Однако, будучи прагматиками, мы понимаем, что план будет претерпевать изменения, ведь он включает в себя рабочие гипотезы о структуре, управлении и метриках, которые мы будем постоянно дорабатывать в ходе трансформации. Существуют хорошо известные практики командообразования в крупных компаниях и координации этих команд для обеспечения их работоспособности.
Шаг 3. Нарисуйте дорожную карту трансформации
С какой команды, ресурса или группы начать трансформацию? Какое подразделение продолжит этот процесс? А кто его поддержит затем? Мы должны рассказать компании о том, что мы собираемся делать, сколько времени это займет, и что мы рассчитываем получить взамен вложенных инвестиций. Мы называем группы, которые проходят трансформацию, экспедициями, а промежуточные результаты, которых они достигают – базовыми лагерями (basecamps).
Шаг 4. Составьте гибкий план на 90 дней
Команда лидеров трансформации встречается для планирования, оценки успехов, корректировки плана в случае необходимости. Основная цель команды – иметь гибкий 90-дневный план и достаточно нестандартное представление о том, что будет происходить. 90-дневный план похож на гибкое планирование релизов или PI-планирование. В плане будут перечислены все процессы в компании, которые будут затронуты трансформацией в течение следующих 90 дней.
Шаг 5. Проводите промежуточную проверку результатов каждые 30 дней
Наподобие цикличности спринта, вам нужно периодически оценивать продвижение трансформации, проводить ретроспективы и корректировать процесс.
Шаг 6. Адаптируйтесь и учитесь
Пересмотрите видение конечного состояния, основываясь на том, как эволюционировало ваше понимание успеха в процессе Agile-трансформации.
Шаг 7. Связывайте свои действия с результатами
Основная причина, по которой вы начали процесс трансформации – это достижение лучших результатов в бизнесе. Мы начинаем оправдывать инвестиции, формируя гипотезы, проводя эксперименты, демонстрируя результаты и изменяя стратегию в зависимости от того, что мы узнали. С учетом того, что вы не будете заранее знать все ваши действия в ходе трансформации, ваша цель – правильно построить последовательность результатов, которых нужно достичь, а также удостовериться в том, что выполненные вами действия соответствуют тем результатам в бизнесе, которых вы хотите достичь.
Шаг 8. Связывайте результаты трансформации с бизнес-целями
Вам нужно отслеживать улучшения системы вплоть до ощутимых выгод для бизнеса, а также регулярно демонстрировать руководству положительную динамику основных бизнес-метрик. Основная цель – это визуализация явной и очевидной связи между вложенными деньгами и достигнутыми измеримыми результатами.
Шаг 9. Управляйте коммуникациями
Регулярные и прозрачные коммуникации по поводу успехов и трудностей, с которыми сталкиваются лидеры трансформации, создадут позитивную атмосферу и придадут вам энергии. Такие встречи часто проходят в формате общего собрания, круглого стола с руководством и других видов информационных встреч.
Шаг 10. Обеспечьте безопасность всех участников процесса
Расскажите всем участникам трансформации, какие выгоды они от нее получат и какое место займут в новой структуре компании. Обеспечьте прозрачность, ответственность и измеримый прогресс для каждого.
Дорожная карта Agile-трансформации
Для успешной трансформации большой и сложной компании абсолютно необходима дорожная карта Agile-трансформации. Подход «как-нибудь-разберетесь-на-ходу» тут просто не сработает. По нашему опыту, успешные трансформации проходят по вот такой дорожной карте:
С чего начать: сформируйте видение конечного состояния
На начальном этапе необходимо посмотреть на вашу компанию в целом и определить бизнес-цели трансформации. Видение конечного состояния определит сценарий формирования команд, последовательность действий, обусловит модель управления, а также создаст метрики и стратегический инструментарий для определения базового уровня производительности и измерения улучшений.
В итоге компания подготовит первую экспедицию и запустит пилотный проект, который поможет определить базовые лагеря, необходимые для реализации изменений.
Трансформация начинается: пилотный проект и запуск
Эта фаза включает в себя формирование, подготовку и обучение команд – эффективно продвигающихся вперед экспедиций, которые постоянно прогрессируют, переходя от одного базового лагеря к другому. По мере созревания команд достигается конечное состояние, собираются базовые метрики, регулярно измеряются улучшения, и открыто распространяется информация о них.
Поддержание непрерывности изменений
На этом этапе структура, управление и метрики начнут консолидироваться в единое целое, и в компании начнет формироваться внутренний набор лучших практик. В течение этого периода и по мере продвижения процесса трансформации централизованное документирование этих практик станет бесценным для вашей компании. Вам нужно будет создавать обучающие и информационные материалы, «шпаргалки» по процессу трансформации. Также будет полезно разработать методы и стратегии адаптации коучей внутри компании, регулярно проводить организационную аттестацию и работу с негативными последствиями.
Автор: Тим Зак, прирожденный айтишник, уже более 10 лет решает маркетинговые задачи с помощью технологий. Компетенции Тима охватывают стратегическое планирование, UX, аналитику, автоматизацию маркетинга, контент-маркетинг и поисковый маркетинг. Одним из его преимуществ является опыт работы в различных отраслях.
Agile-трансформация: всё по-настоящему
Привет, хабровчане. В преддверии старта курса «Agile Project Manager», в создании которого принимал участие, делюсь основанной на собственном опыте статьёй.
Возможности и перспективы agile-трансформации обсуждаются сейчас очень широко, привлекая аудиторию от IT-аналитиков до менеджеров CxO-уровня. Известно несколько западных (пока) школ по достижению так называемого Enterprise Agility – это действительно интересно и даже модно. И как любой hype согласно методике Gartner, по ощущениям, данное направление неуклонно движется к «пику завышенных ожиданий», за которым видимо ждёт «пропасть разочарований» и только потом устойчивое «плато продуктивности».
Вот как это выглядит в общем случае:
Попробуем обобщить предварительные итоги такой трансформации по опыту двух совершенно разных компаний, крупнейших представителей своей отрасли, одними из первых на российском рынке ступивших на стезю полномасштабной agile-трансформации. Непосредственно лидируя отдельные направления в качестве бизнес-архитектора, отвечая за структурирование изменений и разработку целевой модели организации, я пришёл к весьма прагматичным и не совсем ожидаемым выводам, которым кратко поделюсь в данной статье.
Итак, представим, умудренные опытом руководители некой большой компании озабочены повышенными ожиданиями акционеров, ростом конкуренции, перераспределением выручки в пользу цифровых каналов и связанными с этим вызовами. Как всегда, ищутся способы увеличить производительность труда, усилить присутствие бренда на рынке и просто не потерять ставших более разборчивыми клиентов в условиях турбулентности. Прочитаны бизнес-бестселлеры, проведено много часов консультаций, принимается решение последовать актуальному тренду и начать (или ускорить) трансформацию модели управления. Кто-то говорит пора звать «большую четверку», которая всё объяснит, кто-то предлагает внедрять Scrum of Scrum или делать большую общую Kanban-доску…
Первое, с чего стоит начать
— ясное понимание цели, ради которой нам необходимо измениться: какую бизнес-модель компания видит для себя в перспективе и почему для её реализации не обойтись без перестройки организационной структуры для достижения принципиально иного уровня гибкости и осознанности в принятии решений. Это стратегический этап, как обычно в числе прочего характеризующийся оценкой своего положения и конкурентов, выбором ориентиров для сравнения и формированием сценариев будущего с оценкой глобальных преимуществ и потенциальных рисков.
Далее оказывается,
что agile-трансформация крупной компании, вопреки стереотипам, хоть и следует духу agile-манифеста, имеет мало отношения к тому, что общепринято называть agile-методологией. Гибкость зрелой организации начинается не с выделения продуктов и тем более не с определенных церемоний, а в первую очередь – со стратегии управления внутренними инвестициями, а также c совершенно конкретных мер по развитию корпоративной культуры.
Первое проявляется через способность делегировать принятие решений об инвестициях в развитие, перестраивая управление портфелем проектов в пользу децентрализации бюджетов. Одновременно развивается умение каскадировать стратегические цели, устанавливать KPI или OKR, сочетать подходы сверху-вниз и снизу-вверх. Интересны вызовы, например, для команды CFO, – потребность в демократизации финансово-экономического обоснования и последующей оценки эффективности бизнес-инициатив. Суть каскадирования примерно показана на рисунке:
Второе определяется повышением зрелости менеджмента компании — это критично, поскольку, если верить исследованиям, проведенным авторами книги «Лидер и племя», культура команды не сможет держаться выше культурного уровня её лидера (личные наблюдения с этим вполне согласуются). И в целом, необходимо создание условий для вовлеченности сотрудников и мотивации большинства ценить командные достижения выше личных – здесь важно не только обучение, но и ревизия системы компенсаций.
После этого логически следует проработка архитектуры компании, начиная с ключевых потоков создания ценности, приводящая к целевой организационной структуре с соответствующим перераспределением полномочий и бюджетов в сочетании с реформированием коллегиального управления на стратегическом уровне.
Наконец, всё вышесказанное надо запустить в жизнь, невзирая на политику и консерватизм, создавая сотрудникам безопасные условия для перехода.
И лишь на следующем этапе
мы приходим к выстраиванию собственно «кросс-командного» agile: фокусируемся сначала на запуске, потом на взаимодействии конкретных продуктовых команд, следуя рекомендациям LeSS или SAFe (отмечу, что новая версия 5.0 покрывает также большую часть перечисленного выше), либо создавая их производные, как делали мы. Команды можно запускать параллельно, и зачастую они сами принимают решение о своей готовности к применению Scrum, например. Они не всегда оказываются правы, но это точно не основная проблема. Главное не терять из виду фундаментальные основы, без которых трансформация рискует превратиться в игрушку для привлечения талантов.
Конечно, вы на верном пути, если внедряете культуру постоянных улучшений, проводите тренинги для команд, и безусловно стараетесь держать клиента в фокусе внимания. При этом, трансформация не может проводиться «кавалерийским наскоком» и требует внятного экономического обоснования и должной систематизации. Иначе руководство компании попадает в ловушку «видимости agile», когда энергичные заряженные позитивом митинги вселяют веру в успех и помогают переосмыслить мировоззрение (что уже хорошо), но не способствуют структурному подкрепленному надежными данными подходу к реформированию организации и результативному управлению ею в новых условиях. Умение системно и комплексно проводить agile-трансформацию компании с недавнего времени начали называть Structural Agility – это даёт возможность преодолеть инерцию и построить действительно гибкую клиенто-ориентированную, привлекательную для партнеров и инвесторов цифровую организацию, реализующую творческий потенциал своих сотрудников.
Кейсы agile-трансформации, часть третья: производство
В 21 статье серии «Менеджмент цифрового мира» (оглавление) я продолжаю рассмотрение кейсов Agile-трансформации, чтобы в совокупности дать многовариантную картину.
В прошлых статьях был рассказ про банки и про корпорации и госструктуры, в этой я рассказываю про производственные компании: издательство МИФ, медицина, fashion, литейный завод, Scrum в продажах, а следующей будет самая любопытная часть – Agile в школах.
Как я писал в прошлой статье, мои источники — доклады на профильных конференциях AgileDays, Agile Business и других, по которым я обычно выкладываю подробные отчеты на моем сайте, а также разговоры в кулуарах конференций и другие частные разговоры.
Все написанное – моя собственная интерпретация, однако в статье много ссылок на видео докладов и мои конспекты, так что вы можете составить свое собственное мнение.
Disclaimer: все изложенное – моя личная интерпретация событий
Свой рассказ про Agile-трансформации производственных компаний я начну с кейса издательства МИФ (Манн, Иванов, Фабер), о котором на IT Spring-2017 рассказывал Владимир Горшунов, а осенью на Agile Business-2017 у него был совместный доклад с Артемом Степановым «На пути к Business Agility. Трансформация издательства МИФ».
Интересно, что в МИФ было две волны Agile-трансформации. И в первой волне можно увидеть достаточно характерную ошибку: МИФ решил внедрить Scrum для команд, выпускающих книги. Это было сделано, а дальше выяснилось, что такая локальная оптимизация не сильно повлияла на успехи издательства в целом по двум причинам.
Во-первых, срок выхода книги существенно сократить все равно не удалось, он связан больше с внешними технологическими ограничениями, а не с работой самой команды выпуска. Во-вторых, основная прибыль делается издательством не на выпуске отдельных книг, и, тем более, их первого тиража, а на допечатках и проектах по выпуску серии связанных книг, рассматриваемых как продуктовая линейка, а этот уровень трансформацией затронут не был, он был инкапсулирован у топов компании. Вывод из этой истории: перед Agile-трансформацией, да и перед любыми другими тоже, стоит проанализировать цепочки создания ценности компании, чтобы оценить принципиально достижимый потенциал экономического успеха.
Перед Agile-трансформацией стоит проанализировать цепочки создания ценности компании
Однако МИФ быстро развивался, планировал расширять свой бизнес, а существующая структура была ограничением. И компания созрела для следующей итерации внедрения Agile уже на масштабах всей компании, о которой рассказывают доклады. Для внедрения был выбран SAFe фреймворк – он поддерживает сложную работу с цепочками создания ценностей. Собственно, именно в этом было основное изменение и ключ к успеху: преобразование из функциональных отделов в кроссфункциональные команды, которые реализуют конкретные бизнес-проекты, например, вывод на рынок серийных комиксов.
Заметим, что речь идет не об одной книге, а именно о серии, которая образует value stream: сначала запускается первая книга, но все готово к тому, чтобы при успехе можно было выпустить и другие, а при неудаче – наоборот, свернуть с ограниченными потерями. Отдельные проектные потоки (value stream) объединены в три крупных value stream по направлениям бизнеса: розничный, корпоративный и online, при этом за счет каскадирования каждый проект понимает свое место и значение в реализации стратегии в целом. И эта комплексная картина собирается и транслируется на компанию в целом.
Раньше такого представления о производстве компании как о потоках создания ценности не было вообще. А комплексная картина собиралась только в головах топов и не транслировалась на компанию, каждый мыслил только в своем фрагменте.
Помимо бизнесовых value stream, которые зарабатываются деньги, выделяют еще обеспечивающие, которые направлены на решение конкретных проблем в выполнении функций – потому что хотя каждая команда полностью ведет продукт, включая, например, его маркетинг, в целом маркетинг компании должен работать согласовано. Интересно, что в рамках таких потоков у них реально работает коллективное, а не персональное руководство. Преобразование компании тоже ведется командами, при этом отслеживается продвижение к результату, как это принято в Agile. Один из значимых результатов – изменения проходят очень быстро, теперь у них получается за неделю сделать то, на что раньше уходило полтора месяца.
Еще один интересный кейс, о котором я хочу рассказать – Agile-трансформация отдела продаж компании по производству строительной плитки. Марина Симонова (Marina Alex) рассказывала о нем на IT Spring-2017, и на AgileDays-2018 в докладе «Agile трансформация начинаем с продаж». Интересно, что применяется Scrum, хотя, казалось бы, в отделах продаж у нас есть поток задач, такты спринтов носят условный характер. Это, конечно, верно, но в Scrum-фреймворк достаточно жестко заложена командная работа, а для изменений в продажах это принципиально: менеджеры по продажам обычно работают индивидуально, на персональные бонусы, заложенные в KPI.
Естественно, целью трансформации было вовсе не ценности командной работы, задачей было существенно улучшить бизнес-показатели по продажам. И потому для пилота был выбран отдел, который хуже всех выполнял план, вернее, стабильно его существенно не выполнял. Пилот по Scrum с недельными спринтами был успешным, команда из отстающей вышла в передовые и пилот был тиражирован на все отделы.
При трансформации директор по продажам стал Product Owner, он определяет стратегию и ставит задачи, а начальники отделов стали Scrum Master и их задача – чтобы команда совместно придумала идеи для выполнения плана, а потом их сделала. Scrum удерживает команду от возврата к старому управлению на переходном этапе.
Индивидуальные KPI были отменены и заменены командными, и это – обязательное условие. Оказалось, что совместная командная работа, сотрудничество и взаимопомощь дают большой потенциал и дает кратный рост в 1.5-3 раза через два-три месяца после начала трансформации, хотя на первых спринтах возможно проседание. но при этом Agile-коуч обязательно должен работать с ценностями и поведением, участвуя в мероприятиях команды, пока не убедиться в изменениях.
Но самое интересное в этом кейсе то, что увидев изменения в отношениях между сотрудниками, руководство компании, может быть неожиданно для себя, поняло, что оно хотело бы видеть такие изменения во всех отделах, а не только в продажах. И начали тиражирование не только на продажи, но и на другие отделы. При этом компания достаточно характерна для постсоветского пространства, директор, он же владелец в 90-е начинал с ларьков на рынке, торгующих стройматериалами и смог развить бизнес до нескольких заводов.
А Марина развивает применение Agile в продажах, сейчас у нее разработан собственный SWAY-фреймворк для Agile в продажах (здесь по-русски), признанный на международном уровне.
Еще один кейс Марины Симоновой – Agile-трансформация в сети стоматологических клиник, о котором она рассказывала в докладе «Agile в медицине» на Agile Days-2018. Задача – наладить сотрудничество между врачами, медсестрами и вспомогательным персоналом для того, чтобы улучшить клиентский сервис и привлечь новых пациентов и предложить больше услуг существующим. Если кто в курсе, во многих медучреждениях медицине между врачами и медсестрами исторически значительная дистанция, при этом и те и другие не слишком ценят вспомогательный персонал: сотрудников регистратуры, уборщиц, охранников, офис. При этом обслуживание пациента зависит от их совместной работы, а врач с медсестрой вообще работают в паре. Именно с это разобщение сотрудников хотели изменить за счет ценностей Agile, и гипотеза состояла в том, что такое изменение даст существенный выигрыш.
Не удивительно, что внедрение было на основе Scrum, потому что его мероприятия как раз позволяют работу с ценностями. Были сформированы команды, в каждую из которых разные специалисты. При этом традиционный бэклог в поликлинике невозможен – лечение оказывается пациентам при обращении, это нельзя запланировать. Поэтому в бэклоге были задачи, направленные на улучшение процессов работы, которые предлагали сами команды, и в этом отличие от Scrum-фреймворка. А ритуалы в виде недельных итераций, планирования, демо, ретро, daily scrum – работали, хотя в части из них сотрудники участвовали дистанционно, потому что у каждого – персональный посменный график работы и полного совпадения нет.
Внедрение в пилотной клинике было успешным, за 5 месяцев оборот увеличился в 2 раза, и далее было принято решение о тиражировании этого на другие клиники сети, причем силами самих сотрудников, участвовавших в пилоте.
История, на мой взгляд, весьма интересная и любопытная. Потому что она показывает, как за счет изменения культуры и ценностей можно существенно поднять качество клиентского сервиса. При том, что никаких изменений условий функционирования не было: врачи и другие сотрудники, местоположение самой клиники и она сама – не изменились.
Возможно, эти проблемы можно было решить методами процессного менеджмента, а не Agile-методов, однако немного зная fasion-индустрию одежды изнутри, я хочу сказать, что в процессе возникает достаточно много особых случаев, которые надо решать в ручном режиме. Собственно, они так и делали, компания не с самого начала выпускала 12 коллекций в год, постепенно наращивая темп и объем производства в ходе развития. И когда проблемы стали существенными – выбрали Agile-методы, а не регулярный менеджмент для решения своих проблем. И это был осознанный выбор, Иван имеет не только практический опыт, но и менеджерское образование в Сколково, а там приличный уровень.
Действия в теории понятны: визуализировать процесс, выявить узкие места, внедрить чеклисты перехода на следующую стадию, организовать команды в узких местах, в частности Scrum для конструкторов, которые отшивают первый экземпляр, отработать работу сервисных служб в нужном темпе. Доклад рассказывал, как это было сделано практически. А в результате time to market уменьшился с 6 месяцев до двух, и они перешли к регулярному выходу продуктов в запланированные сроки.
Еще один кейс «История о развитии Канбан в машиностроении на литейном заводе» рассказывал Нурмагомед Джафаров, заместитеть гендиретора Литмашдеталь. При этом он специально уточнил, что речь идет не о производственном Kanban Тойоты, а о разработке Андерсона для IT – потому что они включают в цикл непроизводственные подразделения, занимающиеся интеллектуальной деятельностью, а не физическим трудом, и основной эффект был достигнут в маркетинге и продажах. При этом японский Kanban – это жесткие правила и революция, обеспечивающая just in time, а Kanban Андерсена – это быстрая эволюция маленькими шагами.
А с производством у них и так все достаточно хорошо. Они его оптимизировали более 20 лет, развивали организационные принципы и в отдельных рабочих бригадах добились высочайшей эффективности. Недавно окунувшись в изучение Agile, они выяснили, что уровень взаимодействия литейщиков уже практически полностью соответствует business agility: на людях объединили 4 профессии в одну, так что достигли полной кроссфункциональности и взаимозаменяемости людей и способности оперативно обработать любой заказ.
Но тут помог чужой опыт: смежник, поставщик оснастки, внедрил Канбан у себя, и в результате в 1.5 раза взлетела пропускная способность и на 16% выручка, они наняли нового продажника, чтобы загрузить систему. Они пошли смотреть опыт – а там 29 человек и единая Kanban-доска для всех на 80% потока. И тогда они поняли, что недостаточно сделать Kanban на основные процессы. У них 150 человек и процесс больше, одной доски недостаточно – они начали выстраивать длинную последовательность досок end-to-end. В результате вскрыли узкие участки в маркетинге и продажах и начали делать отдельные доски там, чтобы изменить ситуацию. Вот такая история.
В этой и предыдущих статьях было много примеров применения Agile-методов в самых разных компаниях. И может возникнуть впечатление, что Agile и регулярный менеджмент объединяться в некоторую обобщенную конструкцию. С моей точки зрения, так не произойдет по следующей причине. Регулярный менеджмент возник в рамках индустриального общества для эффективной организации преимущественно физического труда.
Интеллектуальный, умственный труд он умеет организовывать только на основе высоких компетенций сотрудников и не слишком эффективно, об этом я писал в статье «Цифровой мир: от физического труда — к умственному». А Agile-методы появились как раз как ответ на вызовы цифрового мира, которые первыми пришли в IT-отрасль, как я отмечал в статье «Agile – ответ IT на вызовы цифрового мира». И хотя они взаимно обогащаются практиками, в целом ситуацию можно представить следующей схемой.
Таким образом, регулярный менеджмент по-прежнему будет развиваться, в том числе адаптируя практики Agile, подходящие для областей своего применения – тех, где применение процедур и регламентов по-прежнему моет служить основой организации деятельности. И наоборот, Agile будет и дальше переосмысливать и адаптировать для организации интеллектуального труда и работе в области высокой неопределенности подходы регулярного менеджмента, как он это уже сделал с Lean, теорией ограничений Голдратта и рядом других.
Во всех этих отчетах Agile-методы рассматриваются без разделения. Но по ним есть отдельная статистика, которую ежегодно публикует Version One а пару лет назад ScrumTrek начал публиковать такую же по России (2018, 2019), на которую можно также опираться, и в полной версии, доступной по ссылкам, есть цифры о целях и достижениях, которые ставят при Agile-трансформации.