Poclac что это: «Что такое Poclac в agile?» — Яндекс Кью

Содержание

Стань 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 человек.

Вопрос: Сотрудники каких должностей рассматриваются на данную позицию?

Специальных требований по грейду и должности не установлено. В конкурсе могут принять участие сотрудники Центрального аппарата / ПЦП Блока «Технологии» / «Сбербанк-Технологии» в Москве, которые обладают следующими качествами:

  1. Способны сплотить команду для достижения результата.
  2. Создают вдохновляющую атмосферу и помогают развиваться.
  3. Умеют слушать и находить общий язык с разными людьми.
  4. Понимают природу конфликтов и умеют их разрешать.
  5. Способны лидировать изменения, имеют опыт участия в успешных проектах.
  6. Имеют какой-то опыт в Agile (желательно).
  7. Участвовали в проектах с IT-составляющей (желательно).

Вопрос: Сколько команд будет курировать Agile-коуч?

Один Agile-коуч будет курировать 3-5 команд.

Вопрос: Что именно будет делать Agile-коуч? Это обучение команд или непосредственное участие в проектной деятельности в качестве наставника-консультанта? Обязанности коуча будут ограничены только внедрением Agile, или в ходе настройки новых процессов предполагается решение существенно более широкого круга проблем?

Позиция Agile-коуча не предполагает административных, контрольных или финансовых полномочий. Основные преобразования осуществляются через применение инструментов фасилитации, обучения, отслеживания групповой динамики, бесед «один на один», постановки правильных вопросов.

Основные обязанности и полномочия Agile-коуча:

    1. обучение участников команд
    2. запуск команды, выстраивание процессов поставки результатов
    3. работа над постоянным развитием и улучшением методов Sbergile (совместно с другими Agile-тренерами) и их внедрение в повседневную работу Команд
    4. развитие процедур обмена знаниями и опытом внутри Банка
    5. помощь команде в повышении эффективности и зрелости
    6. отслеживание групповой динамики развития команд
    7. проведение бесед с членами команд в формате «один на один» по вопросам индивидуальной эффективности
    8. идентификация проблем (и успехов) команд, помощь в их решении
    9. участие в совместной регулярной оценке участников команд, поиск возможностей для улучшения и трансляция этих возможностей командам (POCLAC)

Вопрос: Программа рассчитана только для сотрудников подразделений банка, расположенных в Москве?

На первом этапе принято решение о привлечении кандидатур тех сотрудников, которые работают в Центральном аппарате и СБТ И ПЦП московской локации.

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

Вопрос: Какой формат работы планируется? Это full-time или возможен вариант совмещения с текущей деятельностью? Можно ли пройти обучение по данной программе, но остаться в текущем подразделении?

После обучения Agile-коучи будут уделять новым обязанностям 100% своего рабочего времени с полным отрывом от прежнего процесса. Вариант совмещения с текущей деятельностью не предполагается. Пройти обучение, но остаться в своем сегодняшнем подразделении, нельзя.

Вопрос: Где будут находиться территориально коучи во время обучения? После обучения? Возможны ли командировки?

Во время обучения и последующей работы постоянное местонахождение Agile-коуча – ЦА (Москва). Командировки не предусмотрены.

Вопрос: Как непосредственно будет происходить отбор? Только по отправленному эссе и резюме или будут какие-то дополнительные этапы, личные собеседования, что-то еще?

Отбор будет проходить в три этапа:

  1. Рассмотрение резюме, эссе, изучение информации о кандидате из базы HR
  2. Собеседование с рекрутером
  3. Собеседование с двумя членами рабочей группы по 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-команд, которая будет разработана в течение первой волны проекта.

Источник: sberbank-talents.ru

Стань Agile-коучем в Сбербанке!

Метки:AGILE    Управление проектами

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Основополагающие принципы Agile.

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming

Scrum процесс на одном листе

Scrum – это спортивный термин, который пришел к нам из регби, и представляет собой фигуру, которую образуют игроки перед началом игры.

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Получить стоимость обучения Agile/Scrum за 60 минут?

Sprint backlog:

  • Это список всех требований, которые нужно сделать в ближайший спринт.
  • В течение спринта, новые требования не могут появится в Sprint backlog.
  • Все требования должны быть разделены на задачи и оценены.

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

  • это краткое описание того, ради чего выполняется данный спринт.
  • цель на спринт помогает команде принимать обоснованные решения.

Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.

Sprint Burndown Chart

  • дословно “диаграмма сгорания”
  • в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
  • диаграмма обновляется каждый раз, когда завершается какая-либо задача.

Внешний вид диаграммы на рисунке ниже. На практике такая диаграмма очень наглядна: каждый день можно быстро узнать, насколько команда продвинулась вперед.

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

  • Product Owner
  • Scrum Master
  • Team.

Роль Product Owner

  • формулирует требования
  • приоритезирует требования
  • корректирует приоритеты на каждом спринте
  • несет персональную ответственность за ценность требований для рынка/пользователей
  • отвечает за взаимодействие с рынком
  • только один человек

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

  • иметь личную вовлеченность в проект и его результаты;
  • хорошо владеть навыком написания требований.

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

  • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
  • организует работу команды и обеспечивает её всем необходимым
  • защищает команду, несёт ответственность за её эффективность
  • только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи – это делает сама команда;
  • Мастер не заставляет людей делать работу – это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

  • кросс-функциональная
  • взаимозаменяемая
  • самоорганизующаяся
  • с фиксированным составом (в ходе спринта)
  • 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

  • продолжительность спринта
  • емкость (capacity) команды
  • размер её фокус фактора (коэффициент слаженности)
  • трудоемкость требований, которые будут реализованы в спринте
  • очередность выполнения задач и много другое.

Команда НЕ принимает решений:

  • какие требования являются приоритетными – это делает Product Owner.

На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

Команда проводит “ритуал” Daily Meeting

Для компаний, которые решили системно перейти на методологию Scrum, я рекомендую ознакомиться со структурой проекта внедрения и рекомендациями заказчику.

Ритуалы (процессы в Scrum)

В скрам есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.

Ритуалы в скрам это:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

  • выполняется всей командой перед началом спринта
  • команда выбирает требования из Product Backlog и формирует Sprint Backlog
  • если требуется учесть взаимосвязи между операциями, то это делается здесь
  • команда декомпозирует требования на задачи (tasks)
  • каждая задача проходит оценку в трудозатратах или универсальных единицах
  • во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

  • представление и пояснение Product Owner’ом списка требований
  • вопросы со стороны команды
  • /рекомендуется перерыв/
  • декомпозиция требований на задачи (tasks)
  • оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

  • проходит ежедневно и только в одно и то же время;
  • встреча проходит только стоя;
  • поэтому длительность встречи не более 15 минут;
  • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

На ежедневной встрече команда обменивается опытом. Также становится понятно, кто и над какими задачами будет сегодня трудиться. Важно, чтобы команда делала этот ритуал самостоятельно. Я вообще рекомендую Scrum Masters не вмешиваться в ход встречи до тех пор, пока соблюдаются все требования к этому ритуалу.

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review – сдача спринта Product Owner

По завершению каждого спринта команда обязана провести демонстрацию полученного результат. Ценность этого ритуала я поясню отдельно.

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

  • команда зачитывает требования из Sprint Backlog
  • по каждому критерию приемки происходит демонстрация полученных результатов
  • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
  • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

  • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
  • какие проблемы мешают команде выполнять взятые на себя обязательства?
  • как улучшить взаимодействие с Product Owner’ом?
  • какие ошибки совершает команда и почему.

Решения должны быть записаны на отдельной доске. После всеобщего голосования решения принимаются к исполнению со следующего спринта. Scrum Master контролирует ход встречи и следит за её регламентом.
Ознакомьтесь со списком наших курсов по управлению проектами.

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

  1. Заказчик не может сформировать четкие требования к ПО;
  2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
  3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

В начальной фазе проекта заказчик не может сформулировать исчерпывающие требования к продукту. Этому есть несколько причин:

  • у Заказчика существует только идея приложения и он не представляет всю его функциональность;
  • у группы проекта есть разный взгляд на функциональность приложения;
  • команда не может договориться, как же будет удобнее/разумнее реализовать ту или иную часть функциональности приложения.

Один из принципов Agile гласит «Используйте прототипы и делайте поставки продукта как можно чаще». Это позволит снять неопределенность в требованиях и проверить, как с ней будут работать реальные пользователи.

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы – управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile – это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

Средняя оценка
Оцените!

Закрыть

Большое спасибо, что нашли время написать отзыв!

Закрыть

Имя *

Email *

Комментарий

Содержание статьи

Актуальность информации


That’s a good article.Thanks

Супер! Очень понятно.

Супер! Очень понятно.

Не вводите в заблуждение новичков. Перечитайте скрам гайд 2017 года, все станет на свои места. Как пример: в артефактах скрама нет ни чартов ни целей, есть только бэклог продукта, бэклог спринта и инкремент.

Спасибо, для новичков отличный старт!

Спасибо, доступно, общую картину получил

Очень познавательно

Понятно,доступно,емко,спасибо.

Спасибо! Все изложено в доступной форме!

Loading…..Load More Reviews

Жизнь в POCLAC | Проворный Альянс

На Agile2018 я поговорил с Нинке Альмой о ее опыте работы в качестве члена руководящей группы POCLAC в ING.

POCLAC расшифровывается как «Владелец продукта», «Ведущий глава» и «Коуч по Agile» (произносится «Пок-лак»). В 2015 году ING решила создать новую организационную структуру на основе небольших команд или отрядов, состоящих не более чем из девяти человек. Отряды организованы в племена по 150 человек или меньше.

Роль владельца продукта выполняет один из членов команды, помимо ее обычных обязанностей, таких как, например. эксперт по пути клиента (кто-то, кто сочетает в себе маркетинг, управление продуктами и / или бизнес-опыт) или инженер-разработчик.

Глава Ордена вносит свой вклад в создание ценности как член отряда, а также гарантирует, что члены Ордена (те, кто в племени с общим опытом) обладают соответствующими компетенциями и навыками.

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

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

Через два года Ниенке оставила свой POCLAC, чтобы присоединиться к другой группе в ING в качестве тренера по Agile. Ниенке размышляет: «Оглядываясь назад на путь, описанный в этом отчете об опыте, я понимаю, насколько важно делиться опытом между POCLAC и учиться на ошибках. Проблемы, с которыми я столкнулся, не были уникальными, как и решения, хотя тогда я иногда так думал. Поиск решений становится более трудным, если вы не знаете, что уже пробовали другие».

Вот почему я так ценю отчеты об опыте. Вы можете услышать еще больше размышлений Нинке, когда слушаете наш разговор.

Ребекка Вирфс-Брок


Ребекка является президентом Wirfs-Brock Associates и бывшим директором Agile Experience Report Initiative. Она помогает организациям и частным лицам оттачивать свои навыки проектирования и архитектуры, улучшать качество системы и управлять техническим долгом. В дополнение к коучингу и наставничеству она проводит семинары по гибкой архитектуре, эвристике проектирования и прагматическому дизайну программного обеспечения. Она изобрела набор методов проектирования, известный как дизайн, основанный на ответственности (RDD), и случайно создала мем x-DD.

Ребекка также является пастухом для XP 2023 Experience Report Track. Она входит в совет директоров Hillside Group и пишет шаблоны и эссе об устойчивой архитектуре, гибком контроле качества и эвристике проектирования. Если вы хотите поделиться опытом или мудростью в форме шаблона, Ребекка может помочь вам превратить вашу жажду письма в письменное слово.
Прочитайте ее блог на www.wirfs-brock.com/blog и найдите статьи, шаблоны и эссе на ее странице ресурсов, www.wirfs-brock.com/Resources.html


Просмотр профиля

Это сообщение в блоге сообщества Agile Alliance. Представленные мнения являются личными и принадлежат исключительно автору. Они не отражают мнение или политику Agile Alliance.

Путь Agile-лидерской команды

На дворе 2015 год, и компания ING готовится начать захватывающую трансформацию в Нидерландах. Внедряется новый Agile Way of Work, который также требует сложных культурных изменений. В новой организации владелец продукта, руководитель отдела и тренер по Agile образуют виртуальную команду лидеров, поддерживающую отряды. В этом отчете об опыте прослеживается путешествие одной из этих виртуальных команд. Это путешествие со взлетами и падениями, полное знаний о том, как Agile-лидерская команда должна и не должна способствовать оптимальной работе людей и отрядов.

Понедельник, 2 ноября 2015 года, 4 часа, когда я вхожу в конференц-зал на пятом этаже офиса ING в Леувардене, Нидерланды. Когда я смотрю вокруг, я вижу лица новых для меня людей. Это Владельцы Продуктов и Руководители глав четырех команд, с которыми я буду работать в качестве Agile-коуча. «Добро пожаловать на нашу встречу POCL, — говорит один из них, — я думаю, теперь мы можем называть эту встречу POCLAC, поскольку с нами наконец-то появился Agile-коуч!» Представившись, я сажусь и делаю глубокий вдох. Я начинаю наблюдать за собранием, чтобы увидеть, могу ли я определить возможности для улучшения.

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

Этот путь, с самого начала в 2015 году и до того момента, как я покинул отдел в октябре 2017 года, является предметом данного отчета об опыте. Это путешествие, в котором много испытаний, взлетов и падений. Объединение правильных людей не всегда создает правильную команду. Требуются усилия и решимость, чтобы найти наиболее оптимальные способы проявления истинного лидерства. Как сделать так, чтобы люди с разным опытом служили одной общей цели? Что нужно, чтобы руководство связалось с потребностями отрядов? Как они растут? Некоторые ответы на эти вопросы можно найти только в ретроспективе.

Путешествие в этом отчете о впечатлениях описано с точки зрения Agile Coach. Я, Agile-коуч, был частью команды лидеров, а значит, частью всех ее неудач и успехов. Я понял, как важно создавать и оставаться сосредоточенным на общей цели в команде Agile-лидеров. Было важно увеличить автономность отделений, хотя я был удивлен результатами нашего подхода. Кроме того, мой опыт работы в этой команде Agile-лидеров снова напомнил мне о необходимости продолжать оценивать. Я считаю, что этими знаниями стоит поделиться. Однако я не собираюсь представлять полученные знания в качестве передового опыта. То, что является хорошей практикой в ​​контексте этой конкретной руководящей группы в этом конкретном отделе ING, может не быть хорошей практикой в ​​другом контексте. Принимая это во внимание, полученные знания могут оказаться полезными для тех, кто также пытается оптимизировать подход к лидерству в новом, Agile-контексте.

В июне 2015 года ING Domestic Bank в Нидерландах внедрил новый Agile-способ работы во всей организации. С помощью этого нового способа работы ING хотела достичь трех основных целей:

  • Сокращение времени выхода на рынок для более быстрого реагирования на изменяющиеся потребности клиентов
  • Меньше препятствий и передач, чтобы расширить возможности и дать пространство отдельным лицам и командам
  • Более мотивированные, увлеченные и инициативные сотрудники

 

ING искала вдохновения в других успешных компаниях при определении своего собственного Agile-способа работы. Такие компании, как Netflix, Zappos и Spotify, предоставили ценные рекомендации по развитию структур, правил и процессов, необходимых для того, чтобы ING обрела гибкость и оставалась актуальной в долгосрочной перспективе.

Гибкий способ работы ING содержит различные элементы. В этом отчете об опыте я объясню выбор этих элементов, исходя из того, что наиболее важно для понимания основной сюжетной линии.

2.1       Отряды, отделения и племена

Важной отправной точкой Agile-способа работы было правило двух пицц Джеффа Безоса: ваша встреча не может превышать количество людей, которых вы можете накормить двумя пиццами. Чем больше людей, тем больше количество подключений будет расти в геометрической прогрессии. Чем больше соединений, тем медленнее все происходит. Вот почему ING решила построить новую организационную структуру на небольших командах, состоящих не более чем из девяти человек. Эти команды называются «Отряды». Отряды — это BusDevOps (или подмножество этих дисциплин), самоорганизующиеся и кросс-функциональные. Они могут быть функционально-ориентированными, компонентно-ориентированными или коммерчески ориентированными, в зависимости от их назначения.

Личное развитие и развитие мастерства членов отряда организовано в «Главе». Отделения — это формальные группы, состоящие максимум из 10 человек с одинаковыми должностными обязанностями/специализацией, решающие, как следует действовать в своей области знаний; например, глава об аналитике данных, глава о пользовательском опыте или глава о разработке внешнего интерфейса. Главы также являются иерархической линией для членов отряда.

Координация между самоорганизующимися и кросс-функциональными отрядами происходит в «Племях». Племя — это набор отрядов, организованных вокруг одной цели (продукт или услуга), например, ипотека, бизнес-кредитование или частное банковское обслуживание. Отряды внутри племени совместно работают над общей проблемой или работают над общей темой. Общее владение племенем, которое в идеале не превышает 150 человек, принадлежит главе племени (TL).

2.2       Главные роли на уровне отряда

Гибкий способ работы создал в ING плоскую организацию. Регулярный прямой контакт между руководителем племени и членами отряда не был чем-то необычным, однако члены отряда чаще всего контактировали с тремя другими ролями: владельцем продукта (PO), руководителем отдела (CL) и тренером по Agile (AC).

Владелец продукта — это роль, которую выполняет один из членов команды, помимо своих обязанностей, таких как, например. эксперт по пути клиента (кто-то, кто сочетает в себе маркетинг, управление продуктами и / или бизнес-опыт) или инженер-разработчик. Владелец продукта владеет и разделяет видение продукта / ИТ-актива.

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

Коуч по Agile прикрепляется к племени из Центра экспертизы коучей по Agile и действует как «независимый от племени консультант». Коучи Agile помогают создать высокоэффективное племя, бросая вызов, обучая и вдохновляя с точки зрения содержания, культуры и процесса на всех уровнях на основе Agile Way of Work. Количество Agile-тренеров в племени зависит от Agile-зрелости племени.

 

Рисунок 1. Ключевые элементы единого метода работы Agile в ING

 

2.3       POCLAC как новая команда руководителей Agile

ING осознала, что внедрение Agile-способа работы в масштабах всей компании невозможно без культурного перехода. Важным источником вдохновения для этого культурного перехода были идеи Дэниела Пинка. В своей книге «Драйв» 1 он пришел к выводу, что целеустремленность, мастерство и самостоятельность являются основными мотиваторами для людей в современном сложном бизнесе. До введения Agile Way of Work цель, мастерство и автономия сотрудников неявно решались в традиционной структуре управления с руководителями команд и отделов. Ответственность за разработку всех трех мотиваторов могла быть у одного менеджера. В Agile Way of Work ответственность за цель, мастерство и автономию на уровне отряда была четко разделена между тремя новыми ролями: владельцем продукта (PO), руководителем отдела (CL) и Agile-коучем (AC). Эти три роли заменили традиционного менеджера новой руководящей командой, удовлетворяющей потребности отрядов: POCLAC.

POCLAC — это коалиция, которая обычно собирается раз в неделю или один раз в спринте, на которых Владелец продукта, Руководители отделений и Agile-коуч каждого отряда обсуждают события в отряде. Встречи POCLAC — это способ работать над оптимальным потенциалом команды и развитием компетенций. Поскольку собрания проходят на уровне отделения, в них может участвовать более одного руководителя отделения.

Рисунок 2. Роли и обязанности POCLAC

 

3.

1       Предыстория: введение в руководящую группу и сферу ее деятельности

Путешествие, описанное в этом отчете об опыте, произошло в племени Daily Banking Services в ING в Нидерландах. Это было большое племя, состоящее из более чем 30 многофункциональных отрядов, расположенных в двух местах. Объем POCLAC в этом отчете об опыте включает в себя четыре группы примерно из девяти человек, все из которых сосредоточены на построении, обслуживании и улучшении клиентских операций с текущими счетами, таких как «открыть новый текущий счет», «изменить текущий счет», « закрыть текущий счет» и «жизненные события, влияющие на текущие счета». Когда в 2015 году началось путешествие POCLAC, эти четыре отряда были типичными составными командами: два отряда были сформированы вокруг клиентских компонентов пути клиента, а два отряда были сформированы вокруг компонентов промежуточного программного обеспечения. Все отряды, подключенные к серверным системам, поддерживаются в других отрядах/племенах.

У каждой команды был свой Владелец Продукта. Члены отряда входили в состав шести различных подразделений: двух ИТ-подразделений и четырех бизнес-подразделений. С одним тренером по Agile получается, что на бумаге общее количество сотрудников POCLAC составляет одиннадцать человек. На практике руководящая группа обычно была меньше. Это будет объяснено в следующем разделе.

3.2       Усовершенствования структуры POCLAC

Добавление большей структуры к собранию POCLAC было первым улучшением, которое я решил сделать после того, как сделал свои наблюдения на собрании. К счастью, мой приезд создал «естественный импульс» для перемен. Другие члены POCLAC проявили интерес к тому, что может принести новая роль Agile Coach, и были открыты для предложений. Дополнительную мотивацию к совершенствованию дал лидер племени, который сделал формирование эффективных POCLAC одним из своих ключевых направлений для улучшения Agile Way of Work в своем племени.

Мы начали изучать несколько практических моментов:

  • Какова область применения нашего POCLAC?

Мы решили продолжать объединять несколько отрядов, поскольку обмен знаниями и опытом приносит дополнительную пользу.

  • Кто входит в POCLAC, а кто нет?

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

  • Как мы организуем наши собрания?

Я ввел фиксированную структуру встреч. Чтобы убедиться, что эта структура понята и соблюдается, описание, представленное ниже, было добавлено к приглашению на собрание в Outlook. Кроме того, мы договорились, что я буду вести беседу во время встречи.

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

3.3       Поворотный момент: от компонентных команд к фиче-командам

У групп может быть много разных триггеров, чтобы они стали командами. Часто это негативные триггеры: трудные времена заставляют людей бороться за свои позиции и находить общую цель. В путешествии POCLAC поворотный момент, который знаменует собой новый этап для команды лидеров, является положительным.

В племени Daily Banking Services другой Agile Coach начал дискуссию о назначении отрядов на основе компонентов. Согласно концепции LESS, «организация чистой функциональной команды идеальна с точки зрения предоставления ценности и организационной гибкости» 9.0095 2 . Большинство ключевых игроков в племени были готовы опробовать функциональное назначение отрядов. Подразделения, которые сосредоточились на пути клиентов текущих счетов, казалось, были лучшим местом, чтобы попробовать это в первую очередь. «Открыть новую текущую учетную запись», «изменить текущую учетную запись», «закрыть текущую учетную запись» и «жизненные события, влияющие на текущие учетные записи» были хорошими целями на основе функций. Нам нужно было только создать оптимальное сочетание инженеров внешнего интерфейса и промежуточного программного обеспечения в отрядах, чтобы сформировать «долгоживущую, кросс-функциональную, кросс-компонентную команду, которая выполняет множество сквозных клиентских функций — одну за другой» 2 .

Поскольку общий объем продуктов отрядов и людей, доступных для отрядов, не изменились, POCLAC получил автономию в племени для реорганизации отрядов текущих счетов. Я ознакомил владельцев продукта и руководителей отделений с важным принципом: новые отряды, скорее всего, будут более успешными, если их участники будут участвовать в реорганизации отрядов. Когда все согласились следовать этому принципу, я предложил подход к реорганизации, основанный на самовыборе 9009.5 3 в рамках набора правил и предварительных условий, определенных POCLAC. Процесс самоотбора прошел успешно: он не только обеспечил хороший старт для всех четырех отрядов, но и впервые представил POCLAC как настоящую команду лидеров. Члены отряда видели, как POCLAC вместе создавали для них оптимальные условия доставки. Кроме того, POCLAC впервые увидели себя как команду, служащую общей цели.

3.4       Ценить автономию

Автономия отрядов и отдельных членов отрядов должна цениться для достижения гибкости, на которую нацелен метод работы ING. POCLAC знал об этом: автономия всегда была одной из ключевых тем, хотя мы должны были понять, что это значит для нас. Было очень заманчиво помочь отрядам, немедленно найдя для них решение, вместо того, чтобы помочь отрядам найти решение самим. Встреча POCLAC оказалась идеальным способом оспорить точку зрения друг друга и согласовать наше послание с отрядами. Таким образом, мы могли бы предотвратить ситуацию, в которой Владелец Продукта начинает решать проблемы, в то время как Руководитель Отдела помогает команде найти решение самостоятельно. Это привело к разговору, как показано ниже:

Владелец продукта: «Кажется, у меня нет ресурсов интерфейса во время отпуска Джейн. Джейн развивает навыки работы с интерфейсом Джона, но Джон пока не может работать один во время ее отпуска. Оба инженера работают в вашем отделении, пожалуйста, помогите».

Глава отделения: «Я не уверен, что у нас действительно есть проблема. Это может происходить и в других отрядах, даже если мы об этом не знаем. Я предлагаю, чтобы Джон сначала связался со своими коллегами из того же отделения, которые работают в других отрядах, чтобы узнать, могут ли они быть его поддержкой во время праздника Джейн, прежде чем мы что-либо предпримем».

3.5       Улучшения совместной работы

У POCLAC была общая цель: способствовать оптимальной работе отрядов. Это не означало, что интересы Agile-коуча, руководителя отдела и владельца продукта всегда совпадали. Иногда краткосрочные потребности Владельца Продукта в реализации могут конфликтовать с долгосрочной стратегией Мастерства Руководителя Отделения, как показано в диалоге ниже:

Владелец Продукта: «Чтобы запустить эту новую функцию как можно скорее, я действительно нужно больше навыков Tibco. У Джона и Джейн есть эти навыки, так что теперь они полностью применяют эти навыки. Конечно, это временно».

Глава отделения: «Я не согласен. Для их будущего как инженера, связанного с будущим ING, важно, чтобы Джон и Джейн развивали свои навыки Java. Их личному развитию будет нанесен серьезный ущерб, если они не смогут использовать Java. Более того, мы оба знаем, что «временное» не такое уж временное. Нам нужно найти другое решение».

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

Нам нужно было узнать, как объединение различных областей деятельности трех ролей может повысить эффективность нашего лидерства. То, как мы улучшили наш процесс найма, является хорошим примером положительных результатов сотрудничества в POCLAC. В начале нашего путешествия процесс найма почти полностью осуществлялся руководителями отделений. Более того, практически не было никакой связи между бизнесом и руководителями ИТ-подразделений. Вскоре мы начали обсуждать, как сопоставить навыки новых людей с потребностями бэклога владельца продукта и пробелами в мастерстве, выявленными членами команды. Позже мы увидели преимущества сотрудничества и в самом процессе найма. В конце пути собеседования всегда проводились парами (например, руководитель бизнес-отдела + руководитель ИТ-отдела или руководитель отдела + владелец продукта). «Во вторник я проведу собеседование с двумя кандидатами в отряды X и Y, кто ко мне присоединится?» стал стандартным вопросом в POCLAC.

3.

6       Проверка реальностью: как мы растем?

В 2017 году была запущена новая сложная программа, которая подняла планку доставки четырех отрядов. В то время мы знали, что POCLAC хорошо известна как эффективная команда лидеров Agile, основываясь на отзывах, которые мы регулярно получали от коллег, работающих в других местах племени. Однако мы поняли, что нам нужно сделать следующий шаг в нашем развитии как Agile-лидерской команды. Это ознаменовало новый этап для POCLAC, характеризующийся неопределенностью: как в отношении эффективности отрядов, так и в отношении нашей собственной эффективности. Мы пришли к неутешительному выводу: мы слишком долго воспринимали наш способ работы как должное, а многие аспекты вокруг нас продолжали меняться. Как тренер по Agile в POCLAC, я чувствовал себя ответственным за то, что мы потратили недостаточно времени на оценку работы отрядов и POCLAC.

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

Сначала мы поразмышляли во время выездной встречи, сосредоточившись на трех областях, которые нас интересовали: Автономия, Мастерство и Целеустремленность. Затем мы запланировали встречу со всеми членами отряда, на которой мы обобщили наш подход и результаты, а также предложили участникам отряда интерактивные способы реагировать, размышлять и выдвигать идеи по улучшению. На сессии мы заявили, что ответы и идеи, представленные членами отряда, будут использоваться в качестве исходных данных для принятия окончательного решения, принятого POCLAC. Конечно, окончательные решения будут открыто сообщаться командам. Одним из наиболее важных решений, которое мы в конечном итоге приняли, была перестановка нескольких членов отряда в другие отряды, чтобы еще раз оптимизировать состав отряда для реализации новой программы. Мы также определились с набором навыков, необходимых для новых людей, и в какой отряд нужно было добавить новых людей.

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

3.7       Возможности роста для POCLAC

В 2017 году члены отряда ожидали от POCLAC другого поведения, чем в начале пути. Вначале POCLAC рассматривался как традиционная управленческая команда, на которую никто не мог повлиять. Жалобы на работу руководящего состава редко высказывались открыто. В 2017 году члены отряда более открыто просили об открытости и участии. Когда ожидания не оправдались, сразу же было проведено сравнение со старыми управленческими командами, существовавшими до Agile. Поиск правильного ответа на это восприятие POCLAC по-прежнему был для нас проблемой. Мы подошли к членам отряда и спросили их, что должен сделать POCLAC, чтобы создать более открытую атмосферу. Мы поделились как можно большим количеством информации, в то же время продолжая объяснять, что в некоторых случаях темы встреч не могут быть раскрыты сразу. Мы также стали более гибкими в представлении членов POCLAC, когда они отсутствовали на собраниях. Владельцы продукта и руководители отделений могли попросить члена команды представлять их интересы. Это немного помогло: когда член команды увидел, что произошло на собрании, он лучше понял работу POCLAC. Тем не менее, нам никогда не удавалось полностью изменить восприятие.

Мы также оценили эффективность собраний POCLAC. Жалобы руководителей отделений привели к изменению структуры собраний. В первоначальной структуре встречи мы проводили раунд от владельца продукта к владельцу продукта и задавали им стандартные вопросы. Когда на собрании оставалось время, руководитель отделения и тренер по Agile могли предложить дополнительные темы. Это хорошо работало в течение долгого времени, но позже это начало влиять на воспринимаемую иерархию между ролями. Такая структура создавала у глав отделений ощущение, что они менее важны. Чтобы этого не произошло, руководители отделений предложили быть менее строгими в отношении того, кто говорит первым. Вместо этого мы переходили от отряда к отряду и обсуждали вопросы Автономии, Мастерства и Цели в более случайном порядке для каждого отряда.

Мы поняли, что большинство разговоров во время встреч было сосредоточено на решении проблем. Чтобы убедиться, что мы не забудем отпраздновать наши успехи, я внес в структуру встречи один дополнительный вопрос: «Оглядываясь назад на отряд X на прошлой неделе, чем вы гордитесь?» Это была небольшая корректировка, которая существенно повлияла на атмосферу в руководстве команды.

3.8       Конец пути

В октябре 2017 года я начал новую должность тренера по Agile в ING, и моя часть пути команды Agile-лидеров, описанная в этом отчете об опыте, подошла к концу. Это не значит, что этот POCLAC остановился. Я нашел замену, а остальные продолжили свой путь. Оглядываясь назад на два года, в течение которых я был частью пути, я горжусь тем, чего удалось достичь. В 2017 году нам удалось удовлетворить потребность в Цели, Мастерстве и Автономии отрядов лучше, чем в начале 2015 года. Знания, которые мы получили о лидерстве в новой Agile-культуре, вызывают у меня еще большую гордость. Уроки первых двух лет пути составляют основу роста команды Agile-лидеров в следующие два года. Перед этой командой лидеров появятся новые задачи, но я уверен, что их рост продолжится.

В ING есть много других POCLAC. Оглядываясь назад на путешествие, описанное в этом отчете об опыте, я понимаю, насколько важно делиться опытом между POCLAC и учиться на ошибках. Проблемы, с которыми я столкнулся, не были уникальными, как и решения, хотя тогда я иногда так думал. Поиск решений становится более сложным, если вы не знаете, что уже пробовали другие. Поэтому после того, как я покинул племя Daily Banking, я решил более активно способствовать обмену знаниями о работе в POCLAC в сообществе Agile Coaches в ING. Я поделился этой историей, чтобы вызвать ценные разговоры со своими сверстниками. Кроме того, я разработал семинар, основанный на проблемах, с которыми я столкнулся в своей команде Agile-лидеров. С этой целью я стремлюсь повысить осведомленность о важности POCLAC и помочь другим повысить эффективность их руководства. Время покажет, к каким результатам это приведет.

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

  1. Сосредоточьтесь на своей общей цели и четко говорите о ней. Это помогает договориться о дальнейших действиях, особенно когда вы сталкиваетесь с конфликтом интересов.
  1. Будьте готовы к тому моменту, когда ваша культура действительно изменится. Руководящая группа Agile оказывает большое влияние на культуру Agile на рабочем месте. Это означает, что команда руководителей Agile должна оставаться в соответствии с этой культурой
  1. Знайте, на кого вы работаете, и уважайте их. Всегда спрашивайте себя: как это повлияет на автономию людей, когда я это сделаю?
  1. Никогда не переставайте оценивать. Не ждите, чтобы действовать. Просто эксперимент можно улучшить, даже если вы думаете, что у вас уже все хорошо
  1. Повестка дня вашей встречи имеет значение.
РубрикаРазное