Стань Agile-коучем в Сбербанке!
Осенью 2016 года Сбербанк сообщил о запуске программы трансформации Sbergile(Sberbank + Agile), которая основана на методологии Agile software development («Гибкая методология разработки») и позиционируется как самое значимое событие в истории банка.
«Agile – может быть, самая радикальная трансформация в нашей истории, за все 175 лет нашего с вами развития», – сообщил глава «Сбербанка» Герман Греф.
Ключевая роль в программе отводится Agile-коучам и ниже приведено описание данной вакансии в режиме “вопрос-ответ”.
Agile-коучи: вопросы и ответы
Вопрос: Сообщите, пожалуйста, можно ли рассчитывать на продление сроков приема заявок или на еще одну итерацию набора в группу коучей через некоторое время?
Срок приема заявок продлен на 1 неделю (до 20 июня). В настоящий момент идет отбор в команду agile-коучей для первой волны agile-трансформации. Решения о том, каким образом будет происходить отбор agile-коучей для второй волны, пока не принято.
Вопрос: Пожалуйста, подскажите, когда появится информация о точных датах проведения обучения и сроках проведения интервью с кандидатами?
Интервью с кандидатами уже начались. Каждый участник конкурса, успешно прошедший первый этап отбора (на основании резюме) получит индивидуальное приглашение на интервью. Каждый кандидат должен будет пройти интервью с двумя членами рабочей группы по agile-трансформации Банка. Группы для обучения будут формироваться после 15 июля. Обучение участников первой волны Agile-трансформации начнется c 1 августа 2016 года.
Вопрос: Каковы перспективы развития и карьеры Agile-коуча?
Вы получаете уникальную возможность развить одни из наиболее востребованных на сегодняшний день на рынке компетенций. В отношении карьерного роста: в Agile нет иерархии должностей (начальник-подчиненный), а есть иерархия компетенций (выше ценится тот, кто наиболее полезен команде для решения поставленных задач).
Вопрос: Внедрение Agile мне напоминает внедрение ПСС. Или есть принципиальные отличия?
Основное отличие заключается в том, что в Agile команды отвечают за продукт, который будет предоставлен конечному потребителю. В то время как подразделения ПСС должны заниматься совершенствованием процессов и внедрением культуры постоянных улучшений, помогать другим подразделениям стать более эффективными.
Вопрос: Вы просите заранее сообщать своему руководителю, что участвуете в отборе. Но не указываете, что требуется получить согласование руководителя. Верно ли, что на участие в конкурсе согласие получать не нужно, в случае успешного прохождения отбора руководитель не сможет наложить вето?
Да, все правильно. Но вы должны понимать, что процесс перехода необходимо сделать максимально безболезненным для подразделения, из которого вы уходите.
Вопрос: Сколько всего коучей планируется набрать?
На первом этапе планируется набрать 30 человек.
Вопрос: Сотрудники каких должностей рассматриваются на данную позицию?
Специальных требований по грейду и должности не установлено. В конкурсе могут принять участие сотрудники Центрального аппарата / ПЦП Блока «Технологии» / «Сбербанк-Технологии» в Москве, которые обладают следующими качествами:
- Способны сплотить команду для достижения результата.
- Создают вдохновляющую атмосферу и помогают развиваться.
- Умеют слушать и находить общий язык с разными людьми.
- Понимают природу конфликтов и умеют их разрешать.
- Способны лидировать изменения, имеют опыт участия в успешных проектах.
- Имеют какой-то опыт в Agile (желательно).
- Участвовали в проектах с IT-составляющей (желательно).
Вопрос: Сколько команд будет курировать Agile-коуч?
Один Agile-коуч будет курировать 3-5 команд.
Вопрос: Что именно будет делать Agile-коуч? Это обучение команд или непосредственное участие в проектной деятельности в качестве наставника-консультанта? Обязанности коуча будут ограничены только внедрением Agile, или в ходе настройки новых процессов предполагается решение существенно более широкого круга проблем?
Позиция Agile-коуча не предполагает административных, контрольных или финансовых полномочий. Основные преобразования осуществляются через применение инструментов фасилитации, обучения, отслеживания групповой динамики, бесед «один на один», постановки правильных вопросов.
Основные обязанности и полномочия Agile-коуча:
-
- обучение участников команд
- запуск команды, выстраивание процессов поставки результатов
- работа над постоянным развитием и улучшением методов Sbergile (совместно с другими Agile-тренерами) и их внедрение в повседневную работу Команд
- развитие процедур обмена знаниями и опытом внутри Банка
- помощь команде в повышении эффективности и зрелости
- отслеживание групповой динамики развития команд
- проведение бесед с членами команд в формате «один на один» по вопросам индивидуальной эффективности
- идентификация проблем (и успехов) команд, помощь в их решении
- участие в совместной регулярной оценке участников команд, поиск возможностей для улучшения и трансляция этих возможностей командам (POCLAC)
Вопрос: Программа рассчитана только для сотрудников подразделений банка, расположенных в Москве?
На первом этапе принято решение о привлечении кандидатур тех сотрудников, которые работают в Центральном аппарате и СБТ И ПЦП московской локации. Это связано, в первую очередь с тем, что кандидатам предоставляется трехмесячный срок, в течение которого они могут вернуться на свое рабочее место. Соответственно, руководители кандидатов должны будут сохранять эти позиции незанятыми в течение этого срока. В отношении территориальных банков таких договоренностей пока не существует. Кроме того, в бюджет проекта на этом этапе не заложены затраты на релокацию.
Вопрос: Какой формат работы планируется? Это full-time или возможен вариант совмещения с текущей деятельностью? Можно ли пройти обучение по данной программе, но остаться в текущем подразделении?
После обучения Agile-коучи будут уделять новым обязанностям 100% своего рабочего времени с полным отрывом от прежнего процесса. Вариант совмещения с текущей деятельностью не предполагается. Пройти обучение, но остаться в своем сегодняшнем подразделении, нельзя.
Вопрос: Где будут находиться территориально коучи во время обучения? После обучения? Возможны ли командировки?
Во время обучения и последующей работы постоянное местонахождение Agile-коуча – ЦА (Москва). Командировки не предусмотрены.
Вопрос: Как непосредственно будет происходить отбор? Только по отправленному эссе и резюме или будут какие-то дополнительные этапы, личные собеседования, что-то еще?
Отбор будет проходить в три этапа:
- Рассмотрение резюме, эссе, изучение информации о кандидате из базы HR
- Собеседование с рекрутером
- Собеседование с двумя членами рабочей группы по Agile-трансформации, в том числе с опытным Agile-коучем
Вопрос: Когда будут подведены итоги конкурса?
Итоги конкурса будут подведены в конце июля. Но решения по конкретным кандидатам могут быть приняты раньше
Вопрос: Могу ли я подать заявку, если мной еще не пройден испытательный срок?
Можете, если соответствуете предъявляемым к кандидатам требованиям
Вопрос: Требуется ли знание английского языка? И на каком уровне?
Знание английского приветствуется на уровне Intermediate, так как потребуется изучение различных непереводных текстов, презентаций, видео материалов.
Вопрос: Сколько времени будет проходить обучение? Можно ли во время обучения совмещать его с текущей работой?
Обучение Agile-коучей в первой волне проекта начнется 1 августа и будет проходить модулями в течение примерно двух недель. Программа обучения в настоящее время уточняется. После этого они будут проходить практику вместе с опытными agile-коучами с внешнего рынка. Во время обучения потребуется 100% отвлечение от рабочего процесса. Более детальная информация по вопросам обучения появится в ближайшее время.
Вопрос: Подскажите, пожалуйста, можно ли на данную программу пойти параллельно с шестым потоком Сбербанк 500?
Совмещение работы в роли agile-коуча и обучение по программе Сбербанк 500 возможно. При этом необходимо учитывать, что переход на позицию agile-коуча предполагает освоение новой специальности и потребует много сил и времени. Как следствие совмещение роли agile-коуча с обучением на уровневой программе Сбербанк 500 может оказаться очень непростым.
Вопрос: Будут ли после прохождения (до прохождения) коучинга образовано постоянное структурное подразделение по Agile? Коуч будет работать в этой структуре или вернется на прежнее место работы?
После 3-х месячного периода тестирования agile-коучи будут переведены в отдельное структурное подразделение.
Вопрос: Что означает трехмесячный срок, в течение которогоможно вернуться на свою прежнюю позицию и заниматься тем же, чем занимался до Agile? С какого времени исчисляется этот срок?
Трехмесячный период дается для тех случаев, когда сотрудник по каким-то причинам не сможет продолжить свою карьеру в качестве agile-коуча. Это может быть его решение или решение команды. Эта роль совсем новая и многие вопросы, связанные с ее функциями, сегодня ясны не до конца. Поэтому было принято решение сохранить для сотрудника его прежнюю должность в течение трех месяцев, после чего он сможет (если будет необходимость) вернуться к прежним функциям без каких-либо негативных последствий.
Вопрос: Что значит: «будут уделять новым обязанностям 100% своего рабочего времени» в совокупности с «прежнее место работы будет закреплено за Agile-коучами»? Три месяца коучи будут числиться в своём исходном отделе/управлении, но выполнять обязанности, связанные с коучингом, получая задачи от другого руководителя?
Совершенно верно. Первые три месяца кандидат будет числиться в прежнем подразделении, но на 100% выполнять новые функции, исходя из задач, которые будут формироваться совместно с новой командой. И на оценку работы коучей будет влиять оценка команд, с которыми он работает.
Вопрос: Будет ли связано поле деятельности Agile-коучей с исходным отделом после истечения трех месяцев? Будет ли после этого иметь к ним отношение руководитель их исходного отдела?
Нельзя исключать вероятность кросс-функциональное взаимодействия Agile-команд с подразделениями, в котором раньше работали кандидаты, но в целом работа будет вестись независимо.
Вопрос: Предусмотрен ли перевод сотрудников в другие отделы/должности по итогам обучения и работы?
Цель обучения – обеспечить потребности банка в Agile-коучах. После трехмесячного периода тестирования agile-коучи будут переведены в отдельное структурное подразделение. Если же по каким-то причинам кандидат вернется на прежнее место работы в течение трехмесячного срока, то его перевод на другое место работы или продвижение по должности будут находиться в компетенции прежнего руководителя.
Вопрос: Как будет компенсироваться труд Agile-коучей? Что вообще имеется в виду под компенсацией?
Под компенсацией понимаются условия материального вознаграждения, которые применяются в банке и СБТ и ПЦП сейчас.До конца года условия материального вознаграждения будут сохранены. Затем будет использоваться система материального вознаграждения для Agile-команд, которая будет разработана в течение первой волны проекта.
Вопрос: Вы пишите о том, что до конца 2016 года компенсация Agile-коучей будет соответствовать условиям на их прежней позиции. Есть большое желание стать Agile-коучем, однако, по предварительному согласованию с директором Департамента, я рассчитываю в ближайшее время получить повышение и быть переведенным на грейд выше. Правильно ли я понимаю, что в случае, если я пройду отбор на Agile-коуча, то я не смогу получить ожидаемое мною повышение до конца 2016 года?
В течение трех месяцев Вы остаетесь сотрудником того подразделения, в котором работаете сейчас. Если Ваш руководитель решит увеличить Ваш грейд в течение этого периода – он может это сделать и обсудить свое предложение с Вами.
Вопрос: Какие грейды будут у Agile-коучей?
Вопрос грейдирования Agile-коучей будет решаться в течение первого этапа пилота. Система грейдирования в agile-командах, возможно, будет отличаться от действующей сейчас в Банке. Задача сохранения дохода – это задача подтверждения своих компетенций и навыков, а не сохранения грейда. Пока, на первом этапе, сохранятся те грейды, которые есть сейчас, то есть до конца 2016 года компенсация Agile-коучей будет соответствовать условиям на их прежней позиции.
Вопрос: Касательно условий вознаграждения – в бизнес-подразделениях основная часть вознаграждения приходится на бонусную часть. Как это будет учтено за 2016 г.?
До конца года условия материального вознаграждения будут сохранены. Затем будет использоваться система материального вознаграждения для agile-команд, которая будет разработана в течение первой волны проекта.
Стань Agile-коучем в Сбербанке!
- ← Анализ бизнес-моделей 5 ведущих hi-tech компаний
- McKinsey: Как банк ING встал на Agile-рельсы →
How to turn a good squad into a great one? 8 POCLAC do’s and dont’s
These past few months, we’ve introduced so many new words in our company that it can make our heads spin. Some of them sound hilarious when you hear them for the first time. One of the real funny ones is the “POCLAC.” What the hell? What to make of that and how to take it seriously?
Well, It is actually serious business. No kidding. In an agile organization, a POCLAC is a special coalition between the product owner (PO), the Chapter Lead (CL) and the Agile Coach (AC). Duh! It all makes sense now, doesn’t it? In the POCLAC, the PO, CL and AC join forces, knowledge and insights for one objective: help the squad to perform even better. It’s meant to be a regular meeting – at least once per sprint. The product owner is there to represent the purpose of the squad, the chapter lead to bring knowledge and as resource responsible and the agile coach to drive autonomy and focus on agile methodology and processes within the squad. If done well, this is a killer combination. Together, these three roles should be able to help the squad into a higher level of performance. Something like the Royal Air Force Red Arrows teams ��
Looks and sounds great on paper! Now the reality check. Honestly, it took me a while to really grasp what this meeting is all about. And it took us a few trials – and errors – to get a first POCLAC where we actually felt that were helping the squad. So don’t get desperate if at the start it’s hard! Keep trying, adjusting and communicating and at some point the “aha” moment will come!
How to get the “POCLAC magic” to work? 8 do’s and don’ts
- Be on the look constantly for input for the POCLAC. The retrospective will bring great insights into the team dynamics. The product roadmap will indicate the required skills for the future, etc.
- A POCLAC is not a one night stand! It has to happen at least once every sprint. Even a high performing squad can always do better. So don’t skip it because you think you do not need it! Don’t be that arrogant ��
- A POCLAC is not a backlog meeting, neither a status update. So stay away from discussing the backlog or the next major milestone on the roadmap and focus on the squad. By the way, this is the most common misuse I’ve seen so far of the POCALC meeting!
- Don’t allow other stakeholders to join the POCLAC. There are not meant to be there, even when they tell you the contrary. It’s either the PO, CL and AC in there or no POCLAC at all!
- The goal of the POCLAC is not to discuss individuals! Don’t give into the temptation to go over the individuals in the squad as a rule of thumb. The goal of the POCLAC is to enhance squad performance. So discussing an individual contribution is only allowed when it is directly linked to squad performance. Outcome of such a discussion can vary from giving a big compliment to somebody who has positively influenced squads performance or having a chat with somebody in the squad who is struggling and make a plan to help that individual grow.
- Don’t make it a secret, mysterious get together! If you can’t repeat the stuff that is discussed in the POCLAC outside the room, it shouldn’t be discussed at all! If you start making it a secretive meeting, your position as PO will be hard to maintain in the squad, you will lose credibility as an AC and you will have a hard time in your one-on-ones as CL!
- Focus on the positive rather than the negative! Ok, this is a very easy thing to say. We humans tend to focus on everything that can be improved. And yes, sometimes there are issues that need to be handled. But I believe the focus should be on the aspects of the squads dynamics and capacities that are really great, and try to build on that!
- Stick to your role! The CL, PO and AC all have very specific knowledge and responsibilities. They share a desire to improve squad performance but the way they can individually contribute to that goal differs! A CL shouldn’t interfere with squad priorities and a PO is not HR responsible one for the individuals in the squad. Join forces but be disciplined not to overstep your role.
So! In the end, I find the POCLAC a very useful meeting to discuss my squads highs and lows and ask for help when needed. I really feel that we are all there to join forces to make the squad better.
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
Большой Голландский Банк | Наш путь к масштабируемой гибкости
В этой статье мы расскажем о том, как мы улучшили модель на базе Spotify в трайбе Голландского Банка.
Cезарио Рамос, г-н А, г-жа Б и г-н В
ПО ПРИЧИНАМ ПРАВОВОГО ХАРАКТЕРА Я НЕ МОГУ НАЗВАТЬ РЕАЛЬНЫХ ИМЕН КОМПАНИЙ И УЧАСТНИКОВ
Введение
В этой статье мы расскажем о том, как мы улучшили модель на базе Spotify в трайбе Голландского Банка.
Над нашим продуктом кредитования бизнеса работают более 20 команд.
Мы разрабатываем наш продукт в трех локациях со смешанными командами. Участники каждой из команд владеют навыками бизнеса, ИТ и операционными навыками. При такой схеме работы мы поставляем нашим клиентам ценный продукт каждые две недели. Мы достигли этого, помимо прочего, благодаря внедрению принципов LeSS для оптимизации нашего способа работы в стиле Spotify.
Итак, что мы изменили?
В этой статье мы расскажем нашу историю с четырех различных точек зрения.
- лидера трайба,
- консультанта,
- главы ИТ-отдела,
- Владельца Продукта для части продукта, связанной со всеми циклами взаимодействия с клиентом.
Наблюдения: зачем мы это делали?
Около полутора лет назад я (рассказывает руководитель) начал руководить трайбом ― группой из 500 человек, в которой представители бизнеса и ИТ работали совместно в скводах, создавая продукт кредитования бизнеса и взаимодействуя с командами, отвечающими за лояльность клиентов. До этого я занимался созданием розничного банка с нуля и развитием решений для ипотечного кредитования. Во время моей предыдущей деятельности я интенсивно работал над превращением работы по Аджайлу в модель, подходящую для эффективной организации.
В первые несколько недель я решил понаблюдать за группой.
Мои наблюдения показали, что команды работали с удовольствием и, казалось, оперативно продвигались к достижению целей своих скводов. Команды работали автономно и для организации своей работы использовали многочисленные стикеры и стендап-митинги.
Казалось, все шло хорошо, пока мы не подошли к первому большому релизу продукта.
Мы выпускали продукт в течение шести месячных релизов. И за каждым из этих релизов следовало два месяца исправлений ошибок, в течение которых мы старались стабилизировать продукт, чтобы подготовить его к выходу на рынок. В этих релизах мы выпускали множество разных функций, но не все выпущенные решения были правильными. Долгий этап релиза, а также период исправления ошибок, полный сюрпризов, очень мешали нам выдавать нашим клиентам и руководству правдоподобные прогнозы выхода продукта на рынок.
Я был твердо намерен изменить этот болезненный цикл релиза. Я организовывал многочисленные встречи с людьми из разных частей трайба, чтобы определиться с действиями по улучшению. Представители бизнеса отмечали, что представители ИТ не могут выдать им качественный код. В свою очередь, представители ИТ утверждали, что представители бизнеса не понимают свои сценарии взаимодействия с клиентами и выдают им неверные входные данные. Поэтому мы начали устраивать обучающие сессии, в которых участвовали все, кто хотел поделиться своим видением, идеями и перспективами, чтобы обучиться на наших ошибках. Это был первый большой шаг к более открытому образу мышления. Осознавая это, мы подходили к необходимости значительных изменений.
Я предложил новичкам (тем, кто проработал в нашем трайбе менее 6 месяцев) поделиться со мной своим видением, и они также отметили отсутствие взаимопонимания между представителями бизнеса и ИТ. Кроме того, они выразили сомнение в том, что функции, над которыми работали скводы (команды), действительно были самыми важными для клиента и клана, а не только для самих этих скводов.
В то же время, при создании целевой платформы для Бельгии и Нидерландов, я столкнулся с проблемами, связанными с отсутствием требований к ее возможностям, необходимым каждой из этих стран, а также образом мышления в стиле «они и мы». Как же свести все это воедино…
Линия поддержки: однажды…
Я не знал, что делать, поэтому начал искать помощи. К счастью, примерно в это время на нашу обучающую сессию зашел ИТ-директор, и я рассказал ему о нашей ситуации. Он сказал, что знает кое-кого, кто мог бы мне помочь и даже когда-то проводил Go See (сессии выявления проблем) для моих команд ― он представил меня Сезарио.
Я (рассказывает консультант) познакомился с представителями Голландского Банка, когда выступал с докладом на встрече. Моя лекция была о программистах в условиях крупномасштабной разработки. После лекции ко мне подошел один джентльмен и рассказал о проблемах, которые он наблюдал в своей группе. Позже он представился как ИТ-директор из Голландского Банка в Нидерландах.
Пару дней спустя он позвонил мне. Он поинтересовался, не мог бы я приехать и посмотреть на работу его группы. Это было в конце 2017 года.
Я не был в этом особенно заинтересован, так что сказал, что отправлю ему свое предложение позже на этой неделе. Он ответил: «Хм-м… Я думал, что Аджайл подразумевает, что сотрудничество с клиентами важнее условий контракта?»… Его ответ заинтриговал меня, и я решил съездить в Голландский Банк и посмотреть, что же там происходит.
Итак, пару недель спустя я поехал туда, чтобы провести там сессию Go See в течение пары дней.
Понимание динамики системы
Я часто начинаю совместную работу с сессии Go See. Я провожу такие сессии, чтобы выразить свое уважение команде и ее руководству, а также понять, как выглядит работа команд.
Один из моментов, на которые я обращаю внимание ― повторяющиеся события. Паттерны событий, которые происходят снова и снова через некоторые время. Почему? Потому что такие паттерны ― результат организационной структуры, процессов и политик, с которыми работают люди. И систематически возникающие проблемы, скорее всего, можно решить лишь с помощью улучшения организационного дизайна. Вопреки распространенному убеждению, полностью исправить системные проблемы невозможно путем одной лишь работы с людьми.
К сожалению, у меня нет возможности присутствовать там на протяжении нескольких месяцев, чтобы увидеть своими глазами, как систематические шаблонные проблемы повторяются вновь. Вместо этого я полагаюсь на истории людей, которые там работают, собственные наблюдения, вопросы и исследования, чтобы получить представление о динамике системы.
Я провел ряд бесед и воркшопов с командами разработки и руководителями. Я наблюдал за встречами и инженерными практиками, участвовал в парном программировании и изучал бэклоги, чтобы понять, как все работает.
На основе всей этой информации я сформировал у себя понимание того, как происходит работа, и использовал это для составления рекомендаций.
Далее я расскажу о своих наблюдениях, имеющих отношение к теме этой статьи.
Модель Голландского банка на базе Spotify
Продуктовая группа называется трайб. Ее директор ― представитель бизнеса и эксперт в области рынка кредитования бизнеса. Его называют лидером трайба. Команды называют скводами. В сквод входят носители бизнес-знаний (CJE), навыков ИТ и разработки, а также DevOps. В каждом скводе есть Владелец Продукта, который управляет Бэклогом сквода. За развитие навыков и компетенций людей отвечает чаптер лид. Они есть как в ИТ, так и в бизнесе.
Аджайл-коуч поддерживает работу клана в соответствии со стандартом Аджайла Голландского Банка. Владелец Продукта, чаптер лид и Аджайл-коуч объединены в тройку, называемую POCLAC. Участники POCLAC регулярно встречаются, чтобы обсудить проблемы и решения возможных проблем скводов.
Ниже изображена схема такой организационной структуры.
Локальная оптимизация скводов
Трайб состоял из 24 скводов. Некоторые скводы были территориально распределены. И большинство скводов было тем, что в терминологии LeSS мы называем компонентными командами.
Я также заметил, что в них было 24 командных «Владельца Продукта». Они были постоянно заняты уточнением требований, управлением бэклога, координацией работы команд и управлением командами.
Изменения, которые проводили командные «Владельцы Продукта», были локальными. Я нашел множество примеров, которые это подтверждают. Вот один из них: Скводу 3 требовались изменения в API, а Сквод 6 планировал выполнить эти изменения. Позже в Скводе 6 решили не выполнять этих изменений, и Сквод 3 не смог завершить свою работу. Этим отрядам было очень трудно согласовать свою работу с целями трайба и продукта в целом.
Хотя у каждого сквода была четкая цель, зачастую эта цель не была значимой для конечных пользователей. Из этого факта явно следовало, что большинство отрядов были не в состоянии доставить ценность конечным пользователям самостоятельно. По отдельности эти отряды могли только выполнять часть всей фичи. Большинство скводов зависели друг от друга, и степень этой зависимости составляла от 30 % до 80 %. Зависимости замедляют разработку фич, удлиняют очереди задач различных скводов, увеличивают петлю обратной связи на рынке, а также снижают гибкость на уровне трайба и предсказуемость на уровне продукта. Это большая проблема, которая при добавлении новых компонентных команд может вырасти экспоненциально.
Я подумал, что этот способ работы ― идеальный пример реализации принципа Copy-Paste масштабирования [1]. Это распространенная ментальная модель для масштабирования Аджайл-подходов, которая не дает хороших результатов.
Такая организация работы часто приводит к повторяющимся проблемам, связанным с ненадежными прогнозами, низким фокусом на цели всего трайба и неспособностью реагировать на поступающие идеи.
Проанализируйте работу и оптимизируйте самое важное
Когда я анализировал работу трайба, которую предполагалось выполнить в ближайшем году, я выявил три области высоких зависимостей, которые, по правовым причинам, мы будем условно называть в этой статье «синей», «серой» и «оранжевой». В «синей» области мы обнаружили, что семь отрядов были постоянно загружены работой, тогда как три остальных отряда нужны были время от времени.
На этом графике изображены результаты изучения зависимостей в трайбе, состоящем из скводов. Цвет каждого круга обозначает, на сколько процентов загружен тот или иной отряд разработкой фич для конечных пользователей в определенной области. Если круг полностью окрашен в синий цвет, это означает, что соответствующий сквод загружен на 100 % в «синей» области.
Выяснилось, что отряды с синими кругами (1, 2, 3, 4, 5, 7, 8, 18 и 21) должны вместе работать над одним продуктом, потому что эти отряды нужны практически для каждой фичи.
Монофункциональные менеджеры и POCLAC
Чаптер лидеры вели себя как монофункциональные менеджеры. Например, для каждой конкретной технологии (Pega или Java) был свой ИТ-лид чаптера. Монофункциональные менеджеры предлагают своим сотрудникам карьерный рост лишь в области одного конкретного навыка. Они не могут предложить им расти в области нескольких навыков, хотя именно это требуется для создания адаптивной команды.
Проблемы команд часто вообще не обсуждались командами или напрямую с командами. Вместо этого их обсуждали Владелец Продукта, Аджайл-коуч и чаптера лидер на встречах POCLAC. Такие встречи лишают команды владения процессом, автономии решений и самоорганизации в работе.
Несмотря на то, что вы стремитесь к постоянному улучшению команд, вы получаете обратный эффект. Неудивительно, что при таком подходе владение процессом в командах снижалось, а деятельность POCLAC значительно возрастала.
Непрерывная интеграция
Семнадцать скводов работали в фиче-бранчах. Это означало, что они неделями, а иногда даже месяцами, работали изолированно, без интеграции своего кода с кодом других скводов. Я выяснил, что особой причины наличия такого большого количества веток не было, кроме той «здесь так принято работать».
Ветвление приводит к замедлению координирования, к задержкам, проблемам интеграции, снижению возможности рефакторинга и долгим и болезненным фазам стабилизации, которые полны сюрпризов. В отсутствии непрерывной интеграции координация затруднена.
Неудивительно, что в таких условиях релизы постоянно проходили болезненно и прогнозы были непредсказуемыми.[2]
Разработка через выдаваемые решения
Последнее наблюдение, которым я хотел бы поделиться, связано с разработкой через выдаваемые решения. Раз в квартал проводились сессии квартального уточнения бэклога (QBR), где отрядам выдавались задачи Epic, состоящие из нескольких историй, которые необходимо было выполнить. Производительность измерялась по мере выполнения задач Epic и входящих в них историй. Целью отрядов было выдать все истории в начале следующего квартала, как и планировалось. Чем более вы предсказуемы, тем лучше результат.
В этом подходе было два основных момента, о которых следовало помнить. Во-первых, задачи Epic, которые вы хотите завершить к началу квартала, могут на самом деле не решать проблем клиента или не соответствовать вашим бизнес-целям. Почему? Потому что вы можете не знать, решает ли на самом деле ваша функциональность проблему клиента. Более того, вы можете решать не ту проблему клиента, которую нужно решать в первую очередь.
То есть целью было доставить определенный набор задач или решений Epic. Вместо достижения определенного значимого результата. Командам выдавалась работа для выполнения, а не проблемы для решения.
Во-вторых, при разработке через выдаваемые решения у команд нет стимула проверять предположения, о которых я писал выше, более того, подобная проверка не поощряется. Вы рискуете выдать много решений, которые решают не те проблемы. В трайбе использовалось предсказательное планирование вместо адаптивного планирования, которое необходимо при разработке комплексного программного обеспечения.
Проблемы руководства и организационный дизайн
Мы применили двойственный подход. Во-первых, руководство занялось согласованием целей. Какие проблемы необходимо было решить? Во-вторых, мы стали выяснять, какой организационный дизайн необходим для решения этих проблем.
Нам предстояло получить ответы на следующие вопросы:
- Как повысить надежность трайба?
- Как повысить фокус и соответствие цели внутри трайба?
- Как быть с разработкой в нескольких локациях?
Выводы, к которым мы пришли в результате сессий Go See, позволили нам выработать дальнейшее направление работы.
Как повысить надежность трайба?
Надежность наверняка была бы выше, если бы мы понимали, где находится наш трайб в любой момент времени относительно наших квартальных целей.
Мы решили, что прозрачность нашей работы возрастет, если каждые две недели мы будем знать, что было и что не было сделано на уровне всего продукта.
Поэтому мы решили:
- Постараться ставить перед командами проблемы, а не говорить им, какое «решение» необходимо создать.
- Постараться сделать так, чтобы скводы брали на себя ответственность за рабочий продукт в конце каждого Спринта. Вместо того, чтобы чувствовать ответственность лишь за свою часть продукта.
- Постараться постепенно избавиться от веток. Все команды выполняют коммиты в основную ветку. Использовать ветки только для релиза продукта. Это повышает координацию, снижает задержки и ускоряет работу. (Сначала люди были очень удивлены, если не сказать больше. Выполнение непрерывной интеграции (CI) с имеющейся структурой и технологиями казалось невозможным.)
Как повысить фокус и соответствие цели внутри трайба?
Основываясь на результатах сессий Go See, мы пришли к выводу, что фокус и соответствие цели на уровне трайба, вероятно, можно повысить, если сократить автономию скводов, попросив их достигать какой-либо общей цели в каждом Спринте.
Поэтому мы решили:
- Постараться создать скводы («синего цвета») в области Предложения для клиентов. Эти отряды должны работать над одним и тем же бэклогом. Это должно повысить их скорость и адаптивность.
- Попробовать создать новые области LeSS для других отрядов после того, как убедимся, что первая область работает.
- Постараться проводить планирование через результат, а не через выдачу решений. Например, не надо просить команды доставить эти «пять Epic-задач». Вместо этого попросите их, к примеру, найти решение для сокращения времени на одобрение кредита.
- Постараться интегрировать код всех скводов в основную ветку, как минимум, два раза в день. Это сокращает риск обнаружения ошибок в разработке или даже после поставки продукта.
Как быть с разработкой в разных локациях?
Исторически сложилось так, что скводы работали независимо в двух локациях. Но теперь нам требовалось начать разрабатывать единый продукт. В каждой локации люди были в курсе только своих специфичных деталей продукта, систем, клиентов и динамики рынка. Из-за этого системы, данные и процессы часто дублировались, а теперь их необходимо было объединить.
Итак, нам нужно было найти способ дальнейшей разработки продукта с сохранением фокуса на цели и надежности на уровне трайба. Кроме того, нам была нужна гарантия, что после миграции систем и данных из одной локации в другую все участники останутся на своих местах.
Поэтому мы решили:
- Попробовать временно работать с так называемыми смешанными командами. Это означает, что в каждый сквод должны входить люди из обеих локаций.
- Принять трудности распределенной работы смешанных команд ради растущего понимания и соответствия цели внутри трайба.
Так что на первом этапе мы не использовали колоцированный команды. Вместо этого мы использовали смешанные команды, состоящие из участников из разных локаций, чтобы ускорить изучение ими систем, бизнес-процессов и клиентов из другой страны.
Нарушение правил
Вы можете чему-то научиться, делая вещи, которые считаете правильными, а также делая вещи, которые считаете неправильными. Например, когда вы пробуете сделать что-то, ожидая, что это будет работать, и это на самом деле работает, вы подтверждаете свои текущие допущения и ценности. С другой стороны, если вы пробуете сделать что-то, ожидая, что это не будет работать, а на самом деле это работает, вы узнаете о том, что какие-то из ваших допущений, ценностей или шаблонов мышления ошибочны.
Проблема в том, что обычно мы предпочитаем не делать того, что, по нашим ожиданиям, работать не должно.
Во время внедрения новых способов работы мы сделали много того, что по моим ожиданиям, не должны было сработать.
То есть мы не придерживались общепринятых идей по поводу того, как должно происходить подобное внедрение. Мы разрушили множество «правил»:
- Не обучали каждого или даже не обучали никого. Вместо этого люди учились новым способам работы, применяя их. Мы начинали каждую сессию с объяснения, почему мы это делаем, нашей цели и тактики. Мы проводили небольшие воркшопы, на которых люди могли обсудить настоящие проблемы, с которыми они сталкиваются в реальной жизни.
- Не использовали волонтеров. Вместо этого людей приглашали в команду, и добровольная работа была возможна лишь после появления у них опыта работы в течение нескольких Спринтов.
- Не ликвидировали роль Владельца Продукта на уровне команды. Вместо этого Владельцы Продукта в командах сами добровольно сняли с себя эту роль после первого Спринта.
- Не подготавливали систему непрерывной интеграции перед изменениями. Вместо этого мы поместили непрерывную интеграцию в начало итогового бэклога на несколько месяцев. Это стало возможным, так как мы перешли к работе с одним Владельцем Продукта.
- Не использовали колоцированные команды. Вместо этого мы использовали смешанные команды, состоящие из участников из Бельгии и Нидерландов, чтобы ускорить изучение ими систем, бизнес-процессов и клиентов из другой страны.
- Не использовали роль Скрам-мастера для команд 1–3, а точнее, мы вообще не использовали эту роль. Вместо этого у нас было четыре постоянно работающих Аджайл-коуча, которые помогали нам во время мульти-командных событий.
- Не использовали термин LeSS. Вместо этого мы сосредоточились на изменениях. Через несколько месяцев я сказал участникам — то, что мы делаем, называется LeSS, и они ответили: «Да, мы знаем это, мы не глупы».
Как мы работаем?
Мы (рассказывает Владелец Продукта) ставим перед собой следующие цели по улучшению процесса:
- Повысить процент завершенных задач Epic
- Повышать фокус с помощью одного Бэклога Продукта, приоритет которого ― создание наивысшей ценности для клиентов
- Поставлять ценность в каждом Спринте
- Быть готовыми к поставке рабочего продукта с помощью кросс-функциональных и кросс-компонентных команд
- Повышать удовлетворенность и расширять навыки участников команд
- Способствовать развитию навыков и экспертизы участников команд, повышая таким образом качество создаваемых решений
Первым шагом проекта кредитования бизнеса в Голландском Банке стала работа с семью скводами и одним Владельцем Продукта. Скводы работают в соответствии со стандартным процессом LeSS. Стоит отметить лишь один момент.
Все скводы участвуют в нескольких синхронных мульти-командных воркшопах по Уточнению Бэклога в каждом Спринте. Это способствует распространению знаний и снижает зависимость одной команды от другой. Люди добровольно делятся тем, что они знают, например, о разработке на Pega.
Все скводы переезжают из одной страны в другую во время Обзора Спринта. А поскольку продолжительность Спринта составляет две недели, получается, что раз в месяц все люди из Нидерландов приезжают в Бельгию и наоборот. Поскольку мы все делаем вместе, мы используем целый день, чтобы закрыть один Спринт и начать следующий.
Типичная повестка дня на Обзоре Спринта включает в себя: Видение Продукта, Цели Спринта, несколько параллельных демонстраций, корректировку работы на основе обратной связи и обзор планов на следующие Спринты.
Это было нелегко!
Скводы в течение долгого периода времени работали над своими локальными частями продукта, процесса или базы клиентов. Это изменилось за один день и принесло нам новые большие возможности для обучения и видения мира с другой точки зрения. Вместе с тем людям было нелегко избавляться от старых привычек и не слишком оптимальных решений.
Ниже я приведу несколько проблем, которыми мы хотели бы поделиться:
Почему нам нужно меняться? Ведь я уже знаю, что нужно делать.
В течение первых нескольких Спринтов некоторые участники считали, что наши мульти-командные Уточнения Бэклога — всего лишь напрасная трата времени. Они утверждали, что и так хорошо знают, что нужно делать. Так почему они должны обсуждать все это заново с людьми, которые, возможно, даже не работали в таких условиях? Это неэффективно и кажется им нерациональным.
Я бы ответил им так: «Я понимаю, что вы все знаете об этом конкретном элементе Бэклога Продукта, но что вы знаете о других участниках своей команды?
Как вы можете знать все, если остальные этого не знают, тогда как наша цель — чтобы любой сквод мог взять в работу любой элемент Бэклога Продукта? Если вы эксперт в теме “А”, а все остальные участники команды — эксперты в теме “Б”, то что случится, если в нашем Бэклоге Продукта останется только тема “А”? Это не то, чего мы хотим».
Каков наш план?
Люди традиционно работали с долговременными и довольно подробными планами. При новом способе работы план на ближайший квартал был подробным, но вместе с тем он содержал только ожидаемые результаты для бизнеса.
Я бы сказал: «Мы даем оценку влияния на бизнес, но не можем оценить, какую функциональность (истории) мы доставим и когда. Конкретная функциональность изменяется по мере того, как мы получаем фидбек о нашей готовой функциональности и ее влиянию на бизнес».
В добавок ко всему, люди привыкли выполнять задачи, но не привыкли решать проблемы. С новым образом мышления они получали возможность использовать свои навыки и творческий подход, чтобы найти прекрасные решения для наших клиентов.
Понять это было невероятно трудно как для участников скводов, так и для руководителей за пределами трайба. И мы до сих пор боремся за достижение этого понимания.
Расставьте приоритеты, «почему я должен заниматься этим?»
Скводы работали с одним и тем же Бэклогом Продукта. Приоритеты расставлялись на основании того, что имеет наибольшую ценность для трайба. Этот подход отличался от предыдущего, когда приоритеты в Бэклоге Продукта расставлялись так, чтобы все скводы были заняты и были локально эффективны.
Образ мышления, привязанный к локальной эффективности, выявился во время Планирования Спринта. На Планировании Спринта скводы могли выбирать, над какими элементами Бэклога Продукта они хотят работать. Естественно, скводы выбирали те элементы, с которыми они были хорошо знакомы. Скводы не выбирали элементы согласно приоритетам. На рисунке ниже изображен Бэклог Продукта после того, как скводы выбрали для себя его элементы.
Иллюстрация показывает, что скводы выбирали элементы из верхней и нижней частей Бэклога. Они чаще выбирали элементы с меньшей ценностью из нижней части, чем элементы с большей ценностью из средней части.
Когда коучи спросили их о причинах такого выбора, скводы ответили, что выбирать элементы из средней части неэффективно, так как они лучше понимают элементы из нижней части.
Несколько раз мне приходилось стоять, держа в руках карточки элементов из средней части и предлагать их скводам. При этом я повторял, что это поможет им расширить свое понимание продукта в целом. Наша цель заключается в том, чтобы каждый сквод мог взять любой элемент из Бэклога Продукта. Это было нелегко, и прошло много времени, пока скводы свыклись с этой новой идеей. Сначала один сквод решился взять такой элемент, а вскоре за ним последовали остальные. Особенно после того, как скводы, которые избегали выбора элементов, в которых они не были экспертами, оказались перед лицом тех, кто на это решился.
Слишком много работы для Владельца Продукта
В ранних Спринтах я очень хотел достичь успеха и делал для этого все возможное. Это был период долгих дней и коротких ночей. Я отвечал на вопросы, разговаривал с многими пользователями и стейкхолдерами, писал истории и задачи Epic, организовывал встречи и так далее. Я был просто невыносим. Это не могло продолжаться долго. Как я мог быть Владельцем Продукта для семи скводов?
Я понял, что для исправления этой ситуации скводы должны были сами начать уточнять элементы вместе с клиентами. Мне необходимо было сосредоточиться на общем планировании, работать с клиентами и стейкхолдерами, думать о приоритезации задач Epic, заботиться об ожидаемых результатах этих задач и формулировать критерии их приемки с точки зрения бизнеса. Мне нужно было больше работать над стратегией.
Ситуация изменилась после того, как мы попросили участников команд самостоятельно создавать карты историй для решения наших главных проблем. Решение проблем стало их заботой, и это действительно помогло нам сделать уточнение Бэклога проще и эффективнее.
Владение продуктом и непрерывное совершенствование
Раньше улучшения в командах проводились их Владельцами Продукта и Аджайл-коучем. А поскольку их поле деятельности было ограничено, эти улучшения в основным были локальными для команд. Выполнять более крупные улучшения, затрагивающие несколько команд, было сложнее.
Введение Общей Ретроспективы существенно изменило эту динамику. В конце каждого Спринта представители скводов и руководители собирались вместе, чтобы обсудить имеющиеся проблемы. Скводам была предоставлена полная свобода улучшать то, что они хотят. Это привело к многочисленным действиям по улучшению работы, например, сессиям группового программирования, сессиям обмена знаниями, введению всевозможных стандартов, изменению способа проведения Уточнения Бэклога, изменению состава скводов и даже изменению способа проведения ими Общей Ретроспективы.
Основные результаты
Мы проработали в такой конфигурации уже шесть месяцев и можем поделиться с вами некоторыми интересными результатами.
- Завершение задач Epiс
- Стремительное ускорение достижения запланированных результатов: c 55 % до 80 % за три квартала.
- Поставка ценности в каждом Спринте
- Более 50 согласований ценности поставляемой функциональности с нашими пользователями и клиентами. Раньше их было менее десяти.
- Повышение удовлетворенности и расширение навыков участников команды
- Незначительный рост показателей удовлетворенности сотрудников: с 5,85 до 6,04.
Основные выводы, которыми мы хотим поделиться
Основные наши выводы, которые мы считаем значительными, таковы:
- Одно общее видение и одна цель — это очень полезно.
- Совместное составление видения продукта со всеми участниками.
- Регулярное повторение составления видения продукта.
- Понимание цели повышает внутреннюю мотивацию.
- Снижение зависимостей между отрядами
- Наши скводы стали более автономны, так как они теперь меньше зависят друг от друга.
- Работа скводов стала более значимой, потому что она вносит непосредственный вклад в ценность для клиента.
- Создавайте владение продуктом: не говорите людям, что делать, а просите их решать проблемы.
- Используйте все интеллектуальные ресурсы, доступные в вашей группе. Для этого ставьте амбициозные цели и позволяйте людям самим найти решение.
- Вместо создания ложных предсказаний, сначала повышайте собственную надежность.
- Когда люди владеют разными навыками и фиче-команды кросс-компонентны, надежность возрастает, так как скводы лучше приспособлены к решению различных задач. Метрики прогресса прозрачны, так как прогресс измеряется на уровне одной фичи.
- Прогнозы делать сложно. Но чем надежнее качество продукта, тем меньше сюрпризов возникает на фазе стабилизации.
- Непрерывная интеграция и автоматизированные тесты существенно повышают предсказуемость.
- Работа в фиче-командах показала, что люди, которые раньше считались героями, на самом деле сдерживали развитие остальных.
- Это не вопрос автономии, а вопрос приспособленности команд.
- Совместная работа большого числа команд может создать впечатление, что у скводов меньше автономии. Но на самом деле это ложное предположение. Автономия ― это возможность выполнять работу без зависимостей от других. Наша конфигурация процесса снизила зависимости между скводами.
- Главный вывод заключается в том, что автономия повышает приспособленность скводов к работе друг относительно друга. Повышение автономности скводов и движение их в одном направлении требуют от них постоянного повышения навыков и заботы о конечном продукте.
Мы до сих пор ведем постоянную борьбу за улучшения и упорно работаем над ними. Главное различие, которое мы наблюдаем ― улучшения становятся всеобщей заботой. Чувствуется, что вся группа берет на себя ответственность за процесс и проявляет инициативу по его улучшению. Это делает работу более интересной и значимой.
Обзор Agile. Что это: методология, метод или философия?
В русскоязычных книгах и статьях Agile (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако …
Стоит разделять Agile как семейство гибких подходов и Agile как философию и систему ценностей. В этой статье я лишь кратко опишу самые популярные подходы (Scrum и Kanban), а более подробно рассмотрю второй аспект: зачем нужны ценности Agile, что стоит за ними, где их можно применять и каково место Agile в общей картине управления процессами, продуктами и бизнесами.
Этот обзор Agile предназначен скорее для «чайников», которые начинают свое знакомство с темой. Но если вы уже знакомы с Аджайлом, используйте эту статью как навигатор: в каждом ее разделе есть ссылки для углубления: детальные статьи, учебные видео, литература.
→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT
Чем Agile отличается от методологий
Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.
Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.
Методология — это совокупность методов и приемов, которые используются в разных сферах деятельности.
Метод — это способ достижения какой-либо цели.
Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:
- Например, в гибкую методологию XP (экстремальное программирование) входят такие приемы как парное программирование и игра в планирование, которые указывают вполне конкретные алгоритмы действий.
- И даже гибкий фреймворк Scrum, который по определению «не является процессом, техникой или методом», все же предписывает применять несколько ролей, мероприятий и артефактов. Каждый элемент Скрама является обязательным для его успешного использования.
В отличие от методологий, методов и фреймворков разработки ПО, в основе Agile — не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности.
Следование этим ценностям повышает скорость разработки и бизнес-эффект от разрабатываемых продуктов. При этом стоимость разработки может увеличиваться, поэтому Agile нужен не всегда. Подробнее см. в разделе Область применения Agile.
Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2012), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.
Ценности Agile простыми словами
Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.
Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:
- люди,
- работающий продукт,
- сотрудничество с заказчиком,
- готовность к изменениям.
Посмотрим, зачем нужны эти ценности Agile.
1. Люди и их взаимодействие важнее процессов и инструментов
Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более программный инструмент не диктует, что людям делать. Более того, они сами решают, как менять процессы/инструменты своей работы.
Чтобы ускорить процесс разработки, люди также должны взаимодействовать напрямую (без посредников в виде документов или других людей), активно общаться между собой лично, а не письменно. Правда, в современном бизнесе общение часто вынуждено переходить в онлайн. Но тогда это должна быть видеосвязь с интерактивными онлайн-досками, а не только письма и чаты.
2. Работающий продукт важнее исчерпывающей документации
Чтобы клиенты были довольны, им нужен именно работающий продукт. Поэтому разработчики продукта должны фокусироваться именно на том, чтобы продуктом можно было как можно скорее воспользоваться, а не на составлении списков, диаграмм, требований, отчетов перед заказчиком.
Чтобы укладываться в сжатые сроки с минимумом затрат, зачастую не стоит связывать себя документацией. Поддержка документации в адекватном продукту состоянии нередко замедляет разработку и требует неоправданно больших затрат.
3. Сотрудничество с заказчиком важнее согласований условий контракта
Чтобы на выходе получить продукт, действительно ценный для заказчика, стоит отказаться от излишних деталей в контракте между подрядчиком и заказчиком (равно как и в требованиях внутреннего заказчика к внутреннему разработчику продукта). Будучи жестко заданы на старте, детали контракта мешают учитывать новые данные и приоритеты, появляющиеся лишь во время разработки.
Чтобы бизнес-ценность продукта быстро росла, заказчик с разработчиком должны плотно общаться по ходу работы. В этом случае все возникающие изменения и проблемы оперативно обрабатываются обеими сторонами.
А чтобы такое сотрудничество исполнителя и заказчика стало возможным, нужно выстраивать их доверие друг к другу.
4. Готовность к изменениям важнее, чем следование плану
Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.
Чтобы в первую очередь делалось самое ценное, текущее видение бизнес-ценности и позиционирования продукта должно быть прозрачно для разработчиков, а процесс их работы должен позволять вносить существенные изменения в прежние планы. В том числе, разработчики должны быть готовы добавлять в продукт незапланированные новые возможности, если они стали ценными в изменившейся ситуации.
Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.
Agile — философия, Scrum — ее реализация
Таким образом, Agile — это не методология разработки, а система ценностей, помогающих разработчикам делать новые продукты быстрее и с бОльшим эффектом для бизнеса:
- за счет более эффективного взаимодействия с заказчиком и друг с другом, которое не ограничивается жестким контрактом или жестким внутренним процессом;
- за счет быстрой реакции на изменения, причем с обеих сторон;
- за счет фокуса на работающий продукт, а не на вспомогательные вещи вроде документации.
Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.
Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.
Изменить образ мышления руководителей и исполнителей с традиционного на гибкий — это самое сложное из того, что нужно сделать для применения какого-либо Agile-подхода в команде или в компании.
Образ мышления Agile сейчас чаще всего реализуется через фреймворк Scrum, поэтому неудивительно, что эти два слова очень часто используются вместе.
- Если Agile-мышление не свойственно людям, Scrum приводит лишь к удорожанию разработки, поскольку нужно больше времени выделять на коммуникации и обратную связь, требуются новые роли, нужны ресурсы на обучение, на повышение взаимозаменяемости сотрудников и т.д.
- И наоборот: без конкретного подхода (вроде Scrum) Agile останется лишь красивой философией — абстракцией, которую большинство людей не смогут превратить в руководство для повседневной работы.
Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.
Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.
Agile сложнее, чем 4 ценности
Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.
Во-вторых, в статье «Что такое Agile-подход и зачем он нужен бизнесу» вы найдете подробное изложение 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведу их здесь кратко:
- Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
- Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
- Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
- Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
- Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
- Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.
Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.
Кратко о том, что входит в Agile сегодня
К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).
В Scrum работа ведется спринтами — одинаковыми по продолжительности короткими итерациями. Вся работа выполняется силами небольшой (до 10 человек) команды, в которую входят разработчики, владелец продукта (отвечающий за успех продукта) и скрам-мастер (отвечающий за эффективность и правильное применение Scrum). Команда самостоятельно решает, кто, что, когда и как делает.
Все участники команды совместно планируют спринт, совместно демонстрируют результаты заинтересованным лицам и совместно ищут способы решения проблем как с продуктом, так и с процессом работы. В ходе спринта разработчики ежедневно и устно обсуждают препятствия, краткосрочные планы и разделение работы между собой.
Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.
Канбан отличается от Скрама по многим параметрам, в частности:
- имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
- в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
- нацелен не только на ускорение, но и на равномерность процессов;
- имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
- отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).
Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:
Конечно, Scrum и Kanban — это далеко не единственные подходы, входящие в Agile. Но большинство других активно развивающихся сейчас гибких подходов касаются проблем другого уровня, нежели описанные в этой статье.
Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.
Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на одном экране, скачав нашу карту гибких подходов для бизнеса в виде картинки и в виде пригодного к печати плаката.
Область применения Agile
В основу Agile были заложены общепонятные ценности. Поэтому Agile применяют в самых разных отраслях: в банках и страховых компаниях, в розничных сетях и телекомах, и даже в энергетике и промышленности. Формулировки многих принципов Agile относятся лишь к разработке программного обеспечения, но большинство из них применимы и вне IT.
Судя по числу участников исследования Agile в России 2019, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.
Agile — это уже давно не только про разработку программного обеспечения.
Но это не значит, что гибкие подходы есть смысл применять везде без ограничений.
Одно из ключевых ограничений Agile кроется в словах «для разработки новых продуктов». Пусть «продукт» здесь употребляется в самом широком смысле, но вот новые продукты все-таки разрабатывает лишь небольшой процент людей. А особенно эффективно Agile себя проявляет лишь в творческой работе и/или в условиях неопределенности. В противном случае накладные расходы на Agile-процессы могут превышать выгоды от Agile с точки зрения бизнеса, особенно при неумелой настройке этих процессов.
- Agile целесообразно применять в ситуации, когда первую версию продукта нужно выпустить на рынок как можно быстрее, иначе конкурентная борьба может быть проиграна.
- Другая ситуация, когда ценности Agile будут наиболее эффективны: инновационный продукт с заранее непредсказуемыми свойствами и/или с нестандартными средствами (новыми технологиями) для его разработки.
Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:
Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).
Книги об Agile по-русски
Список литературы по Agile на русском языке может насчитывать два десятка изданий. Но я приведу лишь 4 книги, которые слабо пересекаются друг с другом по назначению. Две первые книги подходят для первого ознакомления с Agile, две вторые — скорее для тех, кто уже применяет гибкие подходы в работе.
Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban.
Авторы: Роб Коул, Эдвард Скотчер
Книга ориентирована в первую очередь на тех, кто планирует переходить от классического проектного менеджмента к гибкому.
Эпоха Agile. Как умные компании меняются и достигают результатов.
Автор: Стивен Деннинг
В книге описано, как работают гибкие методы управления на разных уровнях вплоть до топ-менеджмента, как правильно ставить цели на пути развития компании и как их достигать.
Scrum. Революционный метод управления проектами.
Автор: Джефф Сазерленд
Книга от основателя фреймворка Scrum. В русском переводе название книги неточное (Scrum — не про управление проектами), но все равно она считается обязательной для прочтения скрам-мастерами. Книга хорошо читается и раскрывает пользу от каждого элемента Cкрама.
Scrum и Kanban: выжимаем максимум.
Авторы: Хенрик Книберг, Маттиас Скарин
Электронная книга в открытом доступе, при этом она отлично иллюстрирована примерами и содержит подробное сравнение Скрама с Канбаном. Особенно полезна будет тимлидам, скрам-мастерам и всем, кто управляет кем-либо или чем-либо на уровне отдельной команды, особенно «айтишной».
Резюме. Место Agile среди родственных управленческих подходов
Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.
Это слово сейчас имеет два основных значения:
- Agile — это система ценностей (или образ мышления, или философия, если вам так больше нравится), которая способствует быстрой разработке новых продуктов, максимально отвечающих потребностям клиентов.
- Agile — это также собирательное название очень разных подходов к управлению разработкой, некоторые из которых даже не разделяют все 4 ценности Agile (пример — Kanban). Так уж исторически сложилось.
Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.
С другой стороны, Agile — это про организацию процесса разработки, а не про технические детали реализации, зависящие от индустрии. Например, в IT-индустрии с той же целью (быстрая поставка ценности клиенту) применяются так называемые инженерные практики и DevOps, но они в Agile не входят.
- сократить время вывода продуктов на рынок / время их поставки потребителю;
- ускорить принятие решений на уровне команд и выше.
Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.
Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2010-х годов. В гибкость бизнеса входит не только быстрая поставка ценности клиентам и быстрая реакция на изменения, но также гибкость целеполагания и распределения ресурсов в организации.
Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.
Таким образом, хотя Agile появился намного раньше других модных управленческих терминов, он не теряет своей актуальности. Будь вы хоть топ-менеджером, хоть руководителем проектов, хоть разработчиком продуктов, ценности и принципы Agile-манифеста вам стоит понять и запомнить, чтобы ваш гибкий процесс приносил ожидаемую пользу.
Надеюсь, эта обзорная статья послужит вам хорошим навигатором для дальнейшего углубления в тему Agile. Как минимум, она позволит вам отличать грамотные статьи, видео и курсы по гибким подходам от непрофессиональных аналогов, а также убережет вас от применения Agile в тех ситуациях, когда это нецелесообразно.
