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.
Основные выводы, которыми мы хотим поделиться
Основные наши выводы, которые мы считаем значительными, таковы:
- Одно общее видение и одна цель — это очень полезно.
- Совместное составление видения продукта со всеми участниками.
- Регулярное повторение составления видения продукта.
- Понимание цели повышает внутреннюю мотивацию.
- Снижение зависимостей между отрядами
- Наши скводы стали более автономны, так как они теперь меньше зависят друг от друга.
- Работа скводов стала более значимой, потому что она вносит непосредственный вклад в ценность для клиента.
- Создавайте владение продуктом: не говорите людям, что делать, а просите их решать проблемы.
- Используйте все интеллектуальные ресурсы, доступные в вашей группе. Для этого ставьте амбициозные цели и позволяйте людям самим найти решение.
- Вместо создания ложных предсказаний, сначала повышайте собственную надежность.
- Когда люди владеют разными навыками и фиче-команды кросс-компонентны, надежность возрастает, так как скводы лучше приспособлены к решению различных задач. Метрики прогресса прозрачны, так как прогресс измеряется на уровне одной фичи.
- Прогнозы делать сложно. Но чем надежнее качество продукта, тем меньше сюрпризов возникает на фазе стабилизации.
- Непрерывная интеграция и автоматизированные тесты существенно повышают предсказуемость.
- Работа в фиче-командах показала, что люди, которые раньше считались героями, на самом деле сдерживали развитие остальных.
- Это не вопрос автономии, а вопрос приспособленности команд.
- Совместная работа большого числа команд может создать впечатление, что у скводов меньше автономии. Но на самом деле это ложное предположение. Автономия ― это возможность выполнять работу без зависимостей от других. Наша конфигурация процесса снизила зависимости между скводами.
- Главный вывод заключается в том, что автономия повышает приспособленность скводов к работе друг относительно друга. Повышение автономности скводов и движение их в одном направлении требуют от них постоянного повышения навыков и заботы о конечном продукте.
Мы до сих пор ведем постоянную борьбу за улучшения и упорно работаем над ними. Главное различие, которое мы наблюдаем ― улучшения становятся всеобщей заботой. Чувствуется, что вся группа берет на себя ответственность за процесс и проявляет инициативу по его улучшению. Это делает работу более интересной и значимой.
Life in the POCLAC
POCLAC stands for Product Owner, Chapter Lead, and Agile Coach (pronounced Pok-lack). In 2015, ING decided to base it new organizational structure on small teams, or squads, containing no more than nine people. Squads are organized into tribes of 150 people or less.
The Product Owner role is held by one of the squad’s members, on top of her regular responsibilities as e.g. a Customer Journey Expert (someone who combines marketing, product management, and/or business expertise) or a Development Engineer.
The Chapter Lead contributes to the delivery of value as a member of a squad and also ensures that chapter members (those within a tribe with a shared expertise) have appropriate competencies and skills.
And the Agile Coach? Well, in Nienke’s words, “Agile Coaches help to create a high-performing tribe by challenging, coaching, and inspiring in terms of content, culture, and process on all levels.”
What fascinates me about Nienke’s experience is that she started right away by suggesting improvements to the way her POCLAC leadership team worked. Sometimes they faltered, but they kept learning and trying to improve. They consciously worked to make their squads more autonomous. They worked through reorganization, growth, and lots of change.
After two years, Nienke left her POCLAC to join another group in ING as an Agile Coach. Nienke reflects, “Looking back at the journey described in this experience report, I realize now how important it is to share experiences between POCLACs and learn from mistakes. The challenges that I faced were not unique, nor were the solutions, although back then I sometimes thought they were. Finding solutions becomes more difficult if you don’t know what has been tried before by others.”
And that’s why I value experience reports so much. You can hear even more reflections by Nienke as you listen to our conversation.
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They may not represent the opinion or policy of Agile Alliance.
Rebecca Wirfs-Brock
Rebecca is President of Wirfs-Brock Associates and former Director of the Agile Experience Report Initiative. She helps organizations and individuals hone their design and architecture skills, improve system quality and manage technical debt. In addition to coaching and mentoring she conducts workshops on agile architecture, design heuristics, and pragmatic software design. She invented the set of design practices known as Responsibility-Driven Design (RDD) and by accident started the x-DD meme. Rebecca is also a shepherd…
Recent Blog Posts
Recent Posts
Sixty seconds to fun and learning!
Ellen Grove
Sustainability in Focus: Insights from Three Agile Experts
Agile Alliance
Meet the Agile2024 Program Team – Chris Murman
Teresa Foster
Sixty seconds to fun and learning!
Ellen Grove
Sustainability in Focus: Insights from Three Agile Experts
Agile Alliance
Meet the Agile2024 Program Team – Chris Murman
Teresa Foster
Your Bookmarks
No favorites to display. You must have cookies enabled to add bookmarks.
Recent Agile Alliance Blog Posts
Sixty seconds to fun and learning!
Sometimes, you need a really quick game to liven up a meeting or workshop. For October’s Game On!, we hacked some of the popular Minute-to-Win-It Games to add some Agile flavor. Minute-to-Win-It […]
Sustainability in Focus: Insights from Three Agile Experts
As we encounter numerous large-scale environmental challenges, the Agile community is beginning to focus on the pressing concern of sustainability. In the following Q&A session, we talked with three seasoned […]
Meet the Agile2024 Program Team – Chris Murman
Agile2024 is set for July 22-26 in Dallas! Behind every successful conference lies a team of dedicated individuals who work tirelessly to curate an unforgettable experience. We’re going to share a short Q&A with each of those people here, starting with Chris Murman.
Sixty seconds to fun and learning!
Sometimes, you need a really quick game to liven up a meeting or workshop. For October’s Game On!, we hacked some of the popular Minute-to-Win-It Games to add some Agile flavor. Minute-to-Win-It […]
Sustainability in Focus: Insights from Three Agile Experts
As we encounter numerous large-scale environmental challenges, the Agile community is beginning to focus on the pressing concern of sustainability. In the following Q&A session, we talked with three seasoned […]
Meet the Agile2024 Program Team – Chris Murman
Agile2024 is set for July 22-26 in Dallas! Behind every successful conference lies a team of dedicated individuals who work tirelessly to curate an unforgettable experience. We’re going to share a short Q&A with each of those people here, starting with Chris Murman.
Post your comments or questions
Discover the many benefits of membership
Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.
Our Cornerstone Corporate Supporting Members
Our Corporate Supporting Members are vital to the mission of Agile Alliance. Click here to view all corporate members.
Our Corporate Supporting Members are vital to the mission of Agile Alliance.
Click here to view all corporate members.
Agile Community
Agile Essentials
Agile Resources
Global Affiliates
Agile Events
About Us
Membership
Policies + Principles
Sign up for Agile News
Get the latest Agile Alliance news and updates, including event announcements, special offers, discounts, and more by becoming a newsletter subscriber today.
©2023 Agile Alliance | All Rights Reserved | Privacy Policy
Get the Latest Agile News
Get the latest news and updates from Agile Alliance, including event announcements, special offers, discounts, and more by becoming a newsletter subscriber today.
©2023 Agile Alliance
All Rights Reserved | Privacy Policy
- Welcome back!
Not yet a member? Sign up now
- Membership
- Join Us Today
- Why Join?
- Pricing
- Renew Membership
- Membership FAQs
- Terms and Conditions
- Corporate Members
- Member Portal
- Agile Alliance Events
- Agile en Español
- Agile en Chile
- Game On!
- BYOC – Lean Coffee
- Member Meet & Greet
- Agile Tech Talks
- Agile Coaching Network
- Past Conferences & Events
- Community Events
- Community Events
- Agile Training
- Sponsored Meetup Groups
- Submit an Event
- Agile Essentials Overview
- Agile 101
- Agile Manifesto
- 12 Principles Behind the Manifesto
- A Short History of Agile
- Subway Map to Agile Practices
- Agile Glossary
- Introductory Videos
- Resources Overview
- Blog
- Event Sessions
- Videos
- Experience Reports
- Research Papers
- Agile Glossary
- Agile Books
- Content Library by Category
- Member Initiatives
- Community Events
- Community Groups
- Volunteer Signup
- Community Services
- Community Development
- LATAM Community Development
- India Community Development
- About Agile Alliance
- Board of Directors
- Our Team
- Logo and Media Files
- Become a Sponsor
- Corporate Members
- Contact Us
- Code of Conduct
- Policies, Reports & Bylaws
- Content Standards
- Privacy Policy
- Cookie Policy
- Agile Alliance Brazil
- Agile Alliance New Zealand
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies. However you may visit Cookie Settings to provide a controlled consent.
Manage consent
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Please see our Privacy Notice for further information.
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie Duration Description __cfduid 1 month The cookie is used by cdn services like CloudFare to identify individual clients behind a shared IP address and apply security settings on a per-client basis. It does not correspond to any user ID in the web application and does not store any personally identifiable information. _csrf session This cookie is essential for the security of the website and visitor. It ensures visitor browsing security by preventing cross-site request forgery. _GRECAPTCHA 5 months 27 days This cookie is set by Google. In addition to certain standard Google cookies, reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis. cookielawinfo-checbox-analytics 11 months This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category «Analytics». cookielawinfo-checbox-functional 11 months The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category «Functional». cookielawinfo-checbox-others 11 months This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category «Other. cookielawinfo-checkbox-advertisement 1 year The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category «Advertisement». cookielawinfo-checkbox-necessary 11 months This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category «Necessary». cookielawinfo-checkbox-performance 11 months This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category «Performance». gdpr[allowed_cookies] 1 year This cookie is set by the GDPR WordPress plugin. It is used to store the cookies allowed by the logged-in users and the visitors of the website. JSESSIONID session Used by sites written in JSP. General purpose platform session cookies that are used to maintain users’ state across page requests. PHPSESSID session This cookie is native to PHP applications. The cookie is used to store and identify a users’ unique session ID for the purpose of managing user session on the website. The cookie is a session cookies and is deleted when all the browser windows are closed. pmpro_visit The cookie is set by PaidMembership Pro plugin. The cookie is used to manage user memberships. viewed_cookie_policy 11 months The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie Duration Description __atuvc 1 year 1 month This cookie is set by Addthis to make sure you see the updated count if you share a page and return to it before our share count cache is updated. __atuvs 30 minutes This cookie is set by Addthis to make sure you see the updated count if you share a page and return to it before our share count cache is updated. __jid 30 minutes Used to remember the user’s Disqus login credentials across websites that use Disqus aka_debug This cookie is set by the provider Vimeo.This cookie is essential for the website to play video functionality. The cookie collects statistical information like how many times the video is displayed and what settings are used for playback. bcookie 2 years This cookie is set by linkedIn. The purpose of the cookie is to enable LinkedIn functionalities on the page. CONSENT 16 years 8 months 15 days 5 hours Description Pending disqus_unique 1 year Disqus.com internal statistics lang session This cookie is used to store the language preferences of a user to serve up content in that stored language the next time user visit the website. language This cookie is used to store the language preference of the user. lidc 1 day This cookie is set by LinkedIn and used for routing. locale 3 days This cookie is used to store the language preference of a user allowing the website to content relevant to the preferred language. STYXKEY_aa_signup_visited session No description performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Cookie Duration Description _gat_UA-17319182-1 1 minute Set by Google Analytics and Google Tag Manager to enable website owners to track visitor behaviour and measure site performance. These cookies are used to collect information about how you use our website. The information collected includes number of visitors, pages visited and time spent on the website. The information is collected by Google Analytics in aggregated and anonymous form, and we use the data to help us make improvements to the website. YSC session This cookies is set by Youtube and is used to track the views of embedded videos. Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie Duration Description _ga 2 years This cookie is installed by Google Analytics. The cookie is used to calculate visitor, session, campaign data and keep track of site usage for the site’s analytics report. The cookies store information anonymously and assign a randomly generated number to identify unique visitors. _gat_gtag_UA_17319182_1 1 minute Set by Google Analytics and Google Tag Manager to enable website owners to track visitor behaviour and measure site performance. These cookies are used to collect information about how you use our website. The information collected includes number of visitors, pages visited and time spent on the website. The information is collected by Google Analytics in aggregated and anonymous form, and we use the data to help us make improvements to the website. _gat_UA-0000000-1 1 minute Set by Google Analytics and Google Tag Manager to enable website owners to track visitor behaviour and measure site performance. These cookies are used to collect information about how you use our website. The information collected includes number of visitors, pages visited and time spent on the website. The information is collected by Google Analytics in aggregated and anonymous form, and we use the data to help us make improvements to the website. _gid 1 day This cookie is installed by Google Analytics. The cookie is used to store information of how visitors use a website and helps in creating an analytics report of how the website is doing. The data collected including the number visitors, the source where they have come from, and the pages visted in an anonymous form. eud 1 year 24 days The domain of this cookie is owned by Rocketfuel. This cookie is used to sync with partner systems to identify the users. This cookie contains partner user IDs and last successful match time. S 1 hour domain .google.com uvc 1 year 1 month The cookie is set by addthis.com to determine the usage of Addthis.com service. vuid 2 years This domain of this cookie is owned by Vimeo. This cookie is used by vimeo to collect tracking information. It sets a unique ID to embed videos to the website. Improving Agility with POCLAC Meetings: A Guide for Agile Organizations
The acronym POCLAC may sound unfamiliar to some, while others are well-versed in its meaning. This term refers to three vital roles in Agile methodology, namely, the Product Owner (PO), Chapter Lead (CL), and Agile Coach (AC).
Agile methodology is an iterative and collaborative approach to software development that emphasizes teamwork, customer satisfaction, and continuous improvement. In an Agile organization, the Product Owner, Chapter Lead, and Agile Coach play critical roles in ensuring the success of the Agile process. The POCLAC meeting is a forum for these three roles to collaborate, share updates, and ensure that the team is aligned with the product vision and priorities.
To ensure the success of POCLAC meetings, each role has specific responsibilities.
Product Owner:
The Product Owner is responsible for representing the customer’s needs and priorities in the product development process. In a POCLAC meeting, the Product Owner is expected to share the product vision and goals, discuss any changes or updates to the product backlog and prioritize the backlog items based on business value. Additionally, the Product Owner should highlight any concerns or issues with the product that require the attention of the Chapter Leads and Agile Coach. Finally, the Product Owner should work with the Chapter Leads and Agile Coach to ensure that the team is aligned with the product vision and priorities.
Chapter Lead:
The Chapter Lead is responsible for the performance and development of a group of individuals within the team. In a POCLAC meeting, the Chapter Lead is expected to share updates on the team’s progress, including any blockers or challenges. Additionally, the Chapter Lead should provide feedback to the Product Owner on the prioritization of backlog items based on the team’s capacity and skill set. The Chapter Lead should also collaborate with the Agile Coach to identify any process improvements that could benefit the team’s performance. Finally, the Chapter Lead should work with the Product Owner and Agile Coach to ensure the team’s work aligns with the product vision and priorities.
Agile Coach:
The Agile Coach guides the team in the Agile development process and promotes Agile principles and practices. In a POCLAC meeting, the Agile Coach is expected to facilitate the meeting to ensure that everyone has an opportunity to share their perspective. The Agile Coach should also guide Agile practices and processes, including suggestions for improvements. Additionally, the Agile Coach should work with the Product Owner and Chapter Leads to identify and mitigate potential risks to the product development process. Finally, the Agile Coach should ensure that the team is following the Agile principles and practices.
Major benefits of POCLAC meetings:
Alignment:
POCLAC meetings provide an opportunity for the Product Owner, Chapter Leads, and Agile Coach to align the product vision and goals with the chapter’s objectives. This ensures that everyone is on the same page regarding the product and the work being done. The alignment of the team towards a common goal is critical for ensuring that everyone understands their role in achieving that goal.
Collaboration:
Cross-functional collaboration is essential for success in an Agile organization. POCLAC meetings provide an opportunity for the Product Owner, Chapter Leads, and Agile Coach to collaborate and work together to identify potential issues and come up with solutions. This collaboration can help ensure that everyone is working towards the same goal and can lead to better outcomes.
Continuous Improvement:
Agile methodology is built on the principles of continuous improvement and adaptation. POCLAC meetings provide an opportunity for the Agile Coach to suggest improvements to the Agile practices and processes, and the Chapter Leads can provide feedback on how to improve the team’s performance. Additionally, the Product Owner can provide feedback and insights into the product development process. This feedback can help identify areas for improvement and lead to a more effective Agile process.
Risk Management:
In any software development project, some risks must be managed. POCLAC meetings can help with risk management by providing a forum for the Product Owner to highlight any issues or concerns with the product. The Chapter Leads and Agile Coach can then work together to mitigate those risks. This collaboration can help identify and manage risks, leading to a more successful product development process.
Best Practices for POCLAC Meetings:
To ensure that POCLAC meetings are effective, Agile organizations should follow these best practices:
Schedule regular POCLAC meetings:
POCLAC meetings should be scheduled regularly, such as weekly or bi-weekly. This ensures that everyone is up-to-date on the latest developments and aligned with the product vision and priorities. One common practice is to conduct a POCLAC meeting once during each sprint.
Keep the meeting focused:
POCLAC meetings should focus on the product development process and alignment. Discussions should revolve around issues related to the product development process, and each role should provide updates relevant to its area of responsibility.
Encourage open communication:
Open communication is critical in an Agile organization, and POCLAC meetings should be a safe space for everyone to share their perspectives and provide feedback. Encourage each role to be transparent about any issues or concerns they have and provide constructive feedback.
Take action:
POCLAC meetings are only effective if action is taken based on the discussions and feedback provided. Each role should take action on the feedback provided to ensure that improvements are made and risks are managed effectively.
In conclusion, POCLAC meetings are not only a crucial element of Agile methodology, but also an exciting opportunity for the Product Owner, Chapter Lead, and Agile Coach to come together and collaborate on their shared goal of producing high-quality software that meets customer needs. By following best practices and conducting regular POCLAC meetings, Agile organizations can ensure alignment, promote collaboration, continuously improve their processes, and manage risks effectively. This dynamic forum of open communication and constructive feedback ensures that everyone is working towards the same goal, and ultimately leads to more successful product development outcomes. With POCLAC meetings, Agile organizations can truly unleash the full potential of their team and achieve their business objectives with flying colors!
Adapt, Improve, Succeed: Embrace the Agile Way.
