❓Что делать если команда не хочет проводить Ретро?
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями, обесцениваниями и токсичными замечаниями.
2. Команда не видит большой пользы от Ретро
❤️🩹 Первую ситуацию обычно достаточно легко изменить, предложив попробовать с другим фасилитатором и с обещанием фокусироваться на том, чтобы не допускать ошибок, а не искать виноватых. В этом плане очень помогает пресуппозиция Норма Кёрта:
💬 «Независимо от того, что мы обнаружим, мы должны считать и искренне верить, что каждый сделал лучшее, на что был способен, с учетом доступной на тот момент информации, обладая своими навыками и способностями, при наличии доступных ему ресурсов и сложившейся на тот момент ситуации»
Со второй проблемой могут быть нюансы:
2.1. У команды в принципе не было удачного опыта Ретро
2.2. В команде настолько низкий уровень доверия, что обсуждение проблем и вариантов их решения либо не происходит, либо превращается в фарс
2.3. Команда уже решила все проблемы, которые могла решить самостоятельно.
Давайте сегодня разберем первый вариант. В следующих заметках остальные.
2️⃣.1️⃣. У команды не было опыта проведения полезного Ретро.
Ситуация похожая на кейс с негативным Ретро, не проще тем, что у участников нет отторжения к Ретро, скорее скепсис и их проще убедить попробовать ещё разок. Тут даже необязательно предлагать другого фасилитатора, достаточно анонсировать, что Ретро пройдёт в новом формате.
Но естественно в этот раз вы точно должны провести полезное Ретро для участников иначе поднимите их скепсис до небес.
🏓 И здесь важно даже не то, что вы найдете новый крутой формат Ретро, а важно понять, что болит у команды и подумать, как провести встречу, чтобы эти проблемы были подняты и хотя бы часть из ни была решена.
💡Если вы не уверены, что до Ретроспективы знаете основные боли команды, то пообщайтесь тет-а-тет хотя бы с половиной участников команды. Ещё очень полезно пообщаться с заказчиком и/или руководителем, какие у него есть пожелания к работе команды. Это особенно важно, если участники команды утверждают, что у них всё прекрасно и нет никаких проблем.
📆 Кроме этого, если вы не работаете постоянно с командой, полезно посетить их регулярные встречи, чтобы посмотреть на то, какие проблемы есть там.
📊 Узнав какие есть неудовлетворённости, вы уже можете планировать саму сессию. Можно договориться с участниками по отдельности, кто какую проблему точно поднимет, можно принести самому(ой) список проблем, опять же договорившись будет он анонимный или нет. Если недовольство есть только снаружи команды, то принесите это недовольство максимально задокументировано: обратная связь от клиентов/пользователей, цитата руководителя, Release Burndown Chart, Velocity Chart, статистика удачных сборок, статистика багов и т.д.
🔀 В случае, если договорились с участниками, что они сами озвучивают проблемы, а они это не делают, то будьте готовы поменять дизайн Ретро и достать собранный вами список проблем.
📣 В случае, если команда не согласна собранной обратной связью, поднимите вопрос, как так вышло, что команда до сих пор не собирает обратную связь сама, и в рамках Ретро подумайте, как делать это команде в будущем напрямую, а не через Скрам-Мастера или Agile-коуча.
В следующий раз поговорим, что делать, если в команде настолько низкий уровень доверия, что обсуждение проблем и вариантов их решения либо не происходит, либо превращается в фарс
#facilitation
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями, обесцениваниями и токсичными замечаниями.
2. Команда не видит большой пользы от Ретро
❤️🩹 Первую ситуацию обычно достаточно легко изменить, предложив попробовать с другим фасилитатором и с обещанием фокусироваться на том, чтобы не допускать ошибок, а не искать виноватых. В этом плане очень помогает пресуппозиция Норма Кёрта:
💬 «Независимо от того, что мы обнаружим, мы должны считать и искренне верить, что каждый сделал лучшее, на что был способен, с учетом доступной на тот момент информации, обладая своими навыками и способностями, при наличии доступных ему ресурсов и сложившейся на тот момент ситуации»
Со второй проблемой могут быть нюансы:
2.1. У команды в принципе не было удачного опыта Ретро
2.2. В команде настолько низкий уровень доверия, что обсуждение проблем и вариантов их решения либо не происходит, либо превращается в фарс
2.3. Команда уже решила все проблемы, которые могла решить самостоятельно.
Давайте сегодня разберем первый вариант. В следующих заметках остальные.
2️⃣.1️⃣. У команды не было опыта проведения полезного Ретро.
Ситуация похожая на кейс с негативным Ретро, не проще тем, что у участников нет отторжения к Ретро, скорее скепсис и их проще убедить попробовать ещё разок. Тут даже необязательно предлагать другого фасилитатора, достаточно анонсировать, что Ретро пройдёт в новом формате.
Но естественно в этот раз вы точно должны провести полезное Ретро для участников иначе поднимите их скепсис до небес.
🏓 И здесь важно даже не то, что вы найдете новый крутой формат Ретро, а важно понять, что болит у команды и подумать, как провести встречу, чтобы эти проблемы были подняты и хотя бы часть из ни была решена.
💡Если вы не уверены, что до Ретроспективы знаете основные боли команды, то пообщайтесь тет-а-тет хотя бы с половиной участников команды. Ещё очень полезно пообщаться с заказчиком и/или руководителем, какие у него есть пожелания к работе команды. Это особенно важно, если участники команды утверждают, что у них всё прекрасно и нет никаких проблем.
📆 Кроме этого, если вы не работаете постоянно с командой, полезно посетить их регулярные встречи, чтобы посмотреть на то, какие проблемы есть там.
📊 Узнав какие есть неудовлетворённости, вы уже можете планировать саму сессию. Можно договориться с участниками по отдельности, кто какую проблему точно поднимет, можно принести самому(ой) список проблем, опять же договорившись будет он анонимный или нет. Если недовольство есть только снаружи команды, то принесите это недовольство максимально задокументировано: обратная связь от клиентов/пользователей, цитата руководителя, Release Burndown Chart, Velocity Chart, статистика удачных сборок, статистика багов и т.д.
🔀 В случае, если договорились с участниками, что они сами озвучивают проблемы, а они это не делают, то будьте готовы поменять дизайн Ретро и достать собранный вами список проблем.
📣 В случае, если команда не согласна собранной обратной связью, поднимите вопрос, как так вышло, что команда до сих пор не собирает обратную связь сама, и в рамках Ретро подумайте, как делать это команде в будущем напрямую, а не через Скрам-Мастера или Agile-коуча.
В следующий раз поговорим, что делать, если в команде настолько низкий уровень доверия, что обсуждение проблем и вариантов их решения либо не происходит, либо превращается в фарс
#facilitation
Telegram
Agile Collage
❓Что делать если команда не хочет проводить Ретро?
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями…
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями…
👍3
Интересная история от Артёма Мушина-Македонского:
"... слово «Ответственность» в компании MARS обрело особый смысл, когда CEO компании во время совещания правления вышел из зала, чтобы вернуться через 10 минут с лампой в руках. Все это время длинная потолочная лампа резко мигала, и никто не брался это исправить.
CEO знал, какой смыл он хотел заложить в слово «Ответственность», и создал историю своими действиями."
#teal #SpiralDynamics #CorporateCulture
"... слово «Ответственность» в компании MARS обрело особый смысл, когда CEO компании во время совещания правления вышел из зала, чтобы вернуться через 10 минут с лампой в руках. Все это время длинная потолочная лампа резко мигала, и никто не брался это исправить.
CEO знал, какой смыл он хотел заложить в слово «Ответственность», и создал историю своими действиями."
#teal #SpiralDynamics #CorporateCulture
⚡2👍1
Agile Collage
Интересная история от Артёма Мушина-Македонского: "... слово «Ответственность» в компании MARS обрело особый смысл, когда CEO компании во время совещания правления вышел из зала, чтобы вернуться через 10 минут с лампой в руках. Все это время длинная потолочная…
На прошлой неделе обсудили, что делать если у команды нет позитивного опыта проведения Ретроспективы.
Сегодня поговорим на тему, что делать если...
2️⃣.2️⃣. Уровень доверия в команде не позволяет обсуждать проблемы
Это, пожалуй, самая сложна и длительная для разрешения ситуация.
Опять же может быть несколько причин:
2.2.1. Команда ещё новая
2.2.2. Команда уже не новая, но не было необходимости и/или желания в выстраивании доверия.
2.2.3. В команде небезопасно высказываться искренне
2️⃣.2️⃣.1️⃣. Первый случай самый простой. В течении пары спринтов нужно провести несколько активностей для выстраивания доверия. И ретроспектива – это удачное место для таких активностей.
🤝 Хорошо помогают в выстраивании доверия:
- Любые игры и активности на знакомство: 2 правды и одна лож, карточки с вопросами про прошлое, рассказ про свой бэкграунд и хобби, рассказ о своих факапах,
- Ретро Personal Map, разминка с кубиком, Coffee brake,
- Ретро по 5 порокам команды
Можно проводить либо целиком 1-2 Ретроспекстивы в форме таких активностей, либо начинать Ретро с такой разминки, не скупясь временем.
🌡 Главный подводный камень всех активностей на доверие: кто-то задает планку уязвимости, и все остальные равняются на неё. Поэтому при возможности определите очередность так, чтобы начинал про себя рассказывал самый откровенный участник команды, далее чуть менее откровенный и т.д. Я, иногда если чувствую, что эта планка у команды слишком низкая, начинаю сам и задираю чуть ли ни до интимных подробностей. Например, рассказываю про купный факап.
😱Однажды первый участник рассказал, что он наркоман, и после этого такие истории пошли от остальных участников... В общем у этой команды с доверием больше вообще никаких проблем не было.
2️⃣.2️⃣.2️⃣. В случае, если команда не новая, заставить знакомится ближе команду достаточно сложно.
Здесь уже приходится поступать сложнее и мотивировать их становиться более уязвимыми:
- играть в игры с ненулевой суммой типа "Красное и белое" (можно прямо вместо Ретро)
- опять же провести Ретро по 5 порокам команды
💪 Как и в случае с новой командой здорово найти самого откровенного участника команды, кто бы задавал планку доверия, причем ни сколько в рассказах о прошло, а сколько признании своих ошибок в текущей работе. Когда остальные видят, что кто-то признаётся в косяках, и с ним ничего плохого не происходит, а наоборот команда начинает помогать ему разобраться с проблемой, то и все начинают говорить более откровенно. Тут очень важна роль фасилитатора, чтобы никто не высмеивал и не обесценивал признание ошибок, и чтобы все подключали эмпатию и думали, как решить эту проблему или не допустить подобную в будущем. ❤️
2️⃣.2️⃣.3️⃣. И последний на сегодня кейс и самый сложный. Если в команде уже укоренилась убеждённость, что откровенность карается. Причем, караться она может административно: недополучение премии, объяснительные, выговоры и даже увольнения. А может просто подвергаться насмешкам и троллингу коллегами.
🥊 И если в административном варианте в идеале нужно менять руководителя, ибо старый руководитель будет и у команды ассоциироваться с карающим органом, и самому ему будет не просто перестроиться на новый стиль управления.
- Конечно, нужно отменять всякие наказания, если об ошибке сообщили вовремя, когда цена её устранения сравнительно невысока.
- В целом вместо наказания за ошибки ввести обсуждение, как её решить или предотвратить в будущем без поиска виноватых.
🦸♂️ Тут, как и в прошлых двух вариантах, нужен «пионер-всем пример», но здесь скорее всего вам нужен либо новый участник в команде, либо тот, кто достаточно недавно и не успел проникнутся культурой.
🦠 А вот в случае с токсичной культурой в коллективе вам придётся превратиться прямо в детектива: поговорить чуть ли ни с каждым участником отдельно, чтобы понять кто поддерживает культуру, а кому она не очень нравится, а самое главное найти неформального лидера, кто по факту эту культуру взрастил.
[Окончание в комментарии]
#facilitation
Сегодня поговорим на тему, что делать если...
2️⃣.2️⃣. Уровень доверия в команде не позволяет обсуждать проблемы
Это, пожалуй, самая сложна и длительная для разрешения ситуация.
Опять же может быть несколько причин:
2.2.1. Команда ещё новая
2.2.2. Команда уже не новая, но не было необходимости и/или желания в выстраивании доверия.
2.2.3. В команде небезопасно высказываться искренне
2️⃣.2️⃣.1️⃣. Первый случай самый простой. В течении пары спринтов нужно провести несколько активностей для выстраивания доверия. И ретроспектива – это удачное место для таких активностей.
🤝 Хорошо помогают в выстраивании доверия:
- Любые игры и активности на знакомство: 2 правды и одна лож, карточки с вопросами про прошлое, рассказ про свой бэкграунд и хобби, рассказ о своих факапах,
- Ретро Personal Map, разминка с кубиком, Coffee brake,
- Ретро по 5 порокам команды
Можно проводить либо целиком 1-2 Ретроспекстивы в форме таких активностей, либо начинать Ретро с такой разминки, не скупясь временем.
🌡 Главный подводный камень всех активностей на доверие: кто-то задает планку уязвимости, и все остальные равняются на неё. Поэтому при возможности определите очередность так, чтобы начинал про себя рассказывал самый откровенный участник команды, далее чуть менее откровенный и т.д. Я, иногда если чувствую, что эта планка у команды слишком низкая, начинаю сам и задираю чуть ли ни до интимных подробностей. Например, рассказываю про купный факап.
😱Однажды первый участник рассказал, что он наркоман, и после этого такие истории пошли от остальных участников... В общем у этой команды с доверием больше вообще никаких проблем не было.
2️⃣.2️⃣.2️⃣. В случае, если команда не новая, заставить знакомится ближе команду достаточно сложно.
Здесь уже приходится поступать сложнее и мотивировать их становиться более уязвимыми:
- играть в игры с ненулевой суммой типа "Красное и белое" (можно прямо вместо Ретро)
- опять же провести Ретро по 5 порокам команды
💪 Как и в случае с новой командой здорово найти самого откровенного участника команды, кто бы задавал планку доверия, причем ни сколько в рассказах о прошло, а сколько признании своих ошибок в текущей работе. Когда остальные видят, что кто-то признаётся в косяках, и с ним ничего плохого не происходит, а наоборот команда начинает помогать ему разобраться с проблемой, то и все начинают говорить более откровенно. Тут очень важна роль фасилитатора, чтобы никто не высмеивал и не обесценивал признание ошибок, и чтобы все подключали эмпатию и думали, как решить эту проблему или не допустить подобную в будущем. ❤️
2️⃣.2️⃣.3️⃣. И последний на сегодня кейс и самый сложный. Если в команде уже укоренилась убеждённость, что откровенность карается. Причем, караться она может административно: недополучение премии, объяснительные, выговоры и даже увольнения. А может просто подвергаться насмешкам и троллингу коллегами.
🥊 И если в административном варианте в идеале нужно менять руководителя, ибо старый руководитель будет и у команды ассоциироваться с карающим органом, и самому ему будет не просто перестроиться на новый стиль управления.
- Конечно, нужно отменять всякие наказания, если об ошибке сообщили вовремя, когда цена её устранения сравнительно невысока.
- В целом вместо наказания за ошибки ввести обсуждение, как её решить или предотвратить в будущем без поиска виноватых.
🦸♂️ Тут, как и в прошлых двух вариантах, нужен «пионер-всем пример», но здесь скорее всего вам нужен либо новый участник в команде, либо тот, кто достаточно недавно и не успел проникнутся культурой.
🦠 А вот в случае с токсичной культурой в коллективе вам придётся превратиться прямо в детектива: поговорить чуть ли ни с каждым участником отдельно, чтобы понять кто поддерживает культуру, а кому она не очень нравится, а самое главное найти неформального лидера, кто по факту эту культуру взрастил.
[Окончание в комментарии]
#facilitation
Telegram
Agile Collage
❓Что делать если команда не хочет проводить Ретро?
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями…
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями…
👍3
Оптимизация процессов в Т
Видео с митапа:
- 🧔🏻♂️Михаил Мартынов - Как не навредить себе и коллегам? Стратегия проведения изменений
- 👨🏫 Денис Тучин - 3 основных ошибки агента изменений
- 👩🦰 Римма Денисовец - Пять этапов для успешных изменений ADKAR
Все слайды тут
#Transformation
- 🧔🏻♂️Михаил Мартынов - Как не навредить себе и коллегам? Стратегия проведения изменений
- 👨🏫 Денис Тучин - 3 основных ошибки агента изменений
- 👩🦰 Римма Денисовец - Пять этапов для успешных изменений ADKAR
Все слайды тут
#Transformation
Forwarded from OKR Russia (Kate Dulina)
🔥ScrumTrek проведет бесплатный двухчасовой онлайн-интенсив 12 января 2023 года: «Обзор OKR: собери свои первые цели по Objectives and Key Results».
В программе:
📈 Эволюция целеполагания: MBO/KPI, S.M.A.R.T., BSC, OKR
⚖️ OKR и KPI: отличия, область применения и взаимосвязь между инструментами
🔎 Свойства и примеры OKR
👥 Организационные уровни и ритмы постановки OKR
🎯 Сложности при постановке и внедрении OKR
💼 Кейсы применения OKR в различных отраслях российского бизнеса для роста и выхода из кризиса
☝️Обязательно присутствовать тем, кто хотел разобраться в теме целеполагания, а также выяснить, чем подход может быть полезен бизнесу в текущих условиях!
👉Ссылка на регистрацию👈
@okr_ru
#okr #okr_russia
В программе:
📈 Эволюция целеполагания: MBO/KPI, S.M.A.R.T., BSC, OKR
⚖️ OKR и KPI: отличия, область применения и взаимосвязь между инструментами
🔎 Свойства и примеры OKR
👥 Организационные уровни и ритмы постановки OKR
🎯 Сложности при постановке и внедрении OKR
💼 Кейсы применения OKR в различных отраслях российского бизнеса для роста и выхода из кризиса
☝️Обязательно присутствовать тем, кто хотел разобраться в теме целеполагания, а также выяснить, чем подход может быть полезен бизнесу в текущих условиях!
👉Ссылка на регистрацию👈
@okr_ru
#okr #okr_russia
🔥1
Друзья, небольшой опрос, есть ли в вашей компании Agile PlayBook, Cookbook или другой свод знаний, как компания работает по Agile?
Anonymous Poll
53%
Нет
36%
Есть
12%
Сам(а) принимал(а) участие в написании
5%
Я - консультант, писать плеёбуки - моя работа)
2%
Свой вариант (напишу в комментарии)
Сегодня заключительная часть на тему Что делать, если команда не хочет проводить Ретро?
В прошлые разы мы рассмотрели что делать если
- у команды нет позитивного опыта проведения Ретроспективы
- уровень доверия в команде не позволяет обсуждать проблемы
Сегодня поговорим, пожалуй, про самый распространённый случай:
2️⃣.3️⃣. Что делать, если команда уже решила все проблемы, которые могла решить самостоятельно.
Команда не видит смысла обсуждать, проблемы, которые не в её зоне влияния, а всё что в её зоны влияния уже решено или решается по ходу спринта.
🤔 Тут всё дело в том, что ретроспектива была изначально неправильно позиционирована в команде, либо со временем забылось и осталось в голове, что ретро – место для решения проблем.
📕 Давайте вспомним, что написано в Руководстве по Scrum про Ретроспективу:
Да слово «проблемы» тут присутствует, но фокус не столько на них, сколько на повышении качества и эффективности работы.
А если вспомнить 8 принцип Agile-манифеста:
💪
Если исходить из этого, то ретроспективу можно строить совсем по-другому. Вот лишь немногие из вариантов:
2.3.1. Выбрать командой метрики качества и эффективности (возможно ещё какие-то важные для команжы метрики) и начать придумывать как мы их можем повышать.
2.3.2. Собрать обратную связь от пользователей и других стейкхолдеров по поводу качества, скорости работы и всего что пожелают важным высказать заинтересованные лица и планомерно отрабатывать обратную связь
2.3.3. Провести футуроспективу, используя один из подходов к диагностике команды.
2.3.4. Просто сесть с командой и подумать, что мы можем делать лучше
2️⃣.3️⃣.1️⃣. Придумав идеи улучшений метрик качества и эффективности, стоит их приоритезировать, например, методом ICE.
А дальше брать из этого «бэклога улучшений по 1-2 на спринт. А ещё лучше даже договориться с Владельцем Продукта включить улучшения в Бэклог Продукта, объяснив ему какой эффект от какого улучшения ожидается, чтобы он сам мог приоритезировать их по сравнению с другими элементами бэклога.
2️⃣.3️⃣.2️⃣. Обратную связь конечно нужно тщательно обработать и сформировать гипотезы на её основе, что, например, «если будем показывать пользователям промежуточные результаты, то снизим риск появления инцидентов на Production на 20%». Имея, такие гипотезы их также можно приоритезировать, как в случае 2.3.1.
2️⃣.3️⃣.3️⃣. Про футуроспективу точно стоит уже сделать отдельный вебинар или статью. Сейчас пока накидаю, что можно попробовать:
- Agile Team Health Check
- Team Radar
- Спиральная динамика
- Практически универсальная Ретро по 5 порокам команды
- Моя любимая Toyota Improvement Kata (можно совмещать со всеми выше перечисленными)
[Окончание в комментарии]
#facilitation
В прошлые разы мы рассмотрели что делать если
- у команды нет позитивного опыта проведения Ретроспективы
- уровень доверия в команде не позволяет обсуждать проблемы
Сегодня поговорим, пожалуй, про самый распространённый случай:
2️⃣.3️⃣. Что делать, если команда уже решила все проблемы, которые могла решить самостоятельно.
Команда не видит смысла обсуждать, проблемы, которые не в её зоне влияния, а всё что в её зоны влияния уже решено или решается по ходу спринта.
🤔 Тут всё дело в том, что ретроспектива была изначально неправильно позиционирована в команде, либо со временем забылось и осталось в голове, что ретро – место для решения проблем.
📕 Давайте вспомним, что написано в Руководстве по Scrum про Ретроспективу:
«Цель Sprint Retrospective — запланировать повышение качества и эффективности.
Scrum Team инспектирует то, как прошел последний Sprint в отношении людей, взаимодействий, процессов, инструментов и определения готовности. Инспектируемые элементы зависят от предметной области выполняемой работы и могут быть очень разными. Выявляются предположения, которые сбили Scrum Team с пути, и исследуется их происхождение. Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они столкнулись, и как эти проблемы были (или не были) решены. Scrum Team определяет наиболее полезные для повышения эффективности изменения. Улучшения с самым высоким влиянием реализуются в кратчайшие сроки. Они могут даже быть добавлены в Sprint Backlog следующего Sprint» Да слово «проблемы» тут присутствует, но фокус не столько на них, сколько на повышении качества и эффективности работы.
А если вспомнить 8 принцип Agile-манифеста:
«Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.»то становится понятно, что качество и эффективность мы должны улучшать не путём выжимания всех соков из команды, а путём совершенствования процессов, чтобы участники команды, работая в нормальном режиме, могли допускать меньше ошибок и создавать больше полезного для пользователей.
Если исходить из этого, то ретроспективу можно строить совсем по-другому. Вот лишь немногие из вариантов:
2.3.1. Выбрать командой метрики качества и эффективности (возможно ещё какие-то важные для команжы метрики) и начать придумывать как мы их можем повышать.
2.3.2. Собрать обратную связь от пользователей и других стейкхолдеров по поводу качества, скорости работы и всего что пожелают важным высказать заинтересованные лица и планомерно отрабатывать обратную связь
2.3.3. Провести футуроспективу, используя один из подходов к диагностике команды.
2.3.4. Просто сесть с командой и подумать, что мы можем делать лучше
2️⃣.3️⃣.1️⃣. Придумав идеи улучшений метрик качества и эффективности, стоит их приоритезировать, например, методом ICE.
А дальше брать из этого «бэклога улучшений по 1-2 на спринт. А ещё лучше даже договориться с Владельцем Продукта включить улучшения в Бэклог Продукта, объяснив ему какой эффект от какого улучшения ожидается, чтобы он сам мог приоритезировать их по сравнению с другими элементами бэклога.
2️⃣.3️⃣.2️⃣. Обратную связь конечно нужно тщательно обработать и сформировать гипотезы на её основе, что, например, «если будем показывать пользователям промежуточные результаты, то снизим риск появления инцидентов на Production на 20%». Имея, такие гипотезы их также можно приоритезировать, как в случае 2.3.1.
2️⃣.3️⃣.3️⃣. Про футуроспективу точно стоит уже сделать отдельный вебинар или статью. Сейчас пока накидаю, что можно попробовать:
- Agile Team Health Check
- Team Radar
- Спиральная динамика
- Практически универсальная Ретро по 5 порокам команды
- Моя любимая Toyota Improvement Kata (можно совмещать со всеми выше перечисленными)
[Окончание в комментарии]
#facilitation
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Agile Collage
❓Что делать если команда не хочет проводить Ретро?
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями…
Это один из самых частых вопросов Скрам-Мастеров.
Понятно, что команда не хочет это делать не со зла. По большому счёту есть две основных причины:
1. Команда имела крайне негативный опыт Ретро: с обвинениями…
👍7
Друзья, провел небольшой опрос в 5 соцсетях и получил интересные результаты.
Поделитесь в комментах, какая основная мотивация писать Agile Playbook в вашей организации
#BusinessAgility
Поделитесь в комментах, какая основная мотивация писать Agile Playbook в вашей организации
#BusinessAgility
👍1
Forwarded from Agile Lab Consulting
Коллеги, приглашаем вас 1 февраля в 18:00 (UTC+2) на бесплатный AgileLAB Webinar: Арка Системного Коучинга в Agile трансформациях.
С более подробной информацией можно ознакомиться на нашем сайте.
С более подробной информацией можно ознакомиться на нашем сайте.
agilelab.org
AgileLAB Webinar: Дизайн Мышление: Уникальный подход к решению проблем
25 Января 2024 года команда AgileLAB приглашает вас на бесплатный Webinar. Мероприятие для участников тренингов AgileLAB и всех желающих.
Когда речь заходит про Agile в системах безопасности и медицине, часто звучит "нам это не подойдёт", нам у нас нельзя проводить "безопасные эксперименты".
На самом деле, я как выпускник аэрокосмического ВУЗа поделюсь, что безопасные эксперименты проводятся с авиационной и космической отрасли чуть ли не с их зарождения, главное, правильный эксперимент запланировать.
Но сегодня не об этом. Хочу с вами поделиться ссылкой на видео про компанию из отрасли безопасности, которая перешла сначала на Agile, а потом вообще на Социократию.
#BusinessAgility #Agile #Teal #Sociocracy
На самом деле, я как выпускник аэрокосмического ВУЗа поделюсь, что безопасные эксперименты проводятся с авиационной и космической отрасли чуть ли не с их зарождения, главное, правильный эксперимент запланировать.
Но сегодня не об этом. Хочу с вами поделиться ссылкой на видео про компанию из отрасли безопасности, которая перешла сначала на Agile, а потом вообще на Социократию.
#BusinessAgility #Agile #Teal #Sociocracy
YouTube
Спикеры 2023: Андрей Васильев (ВИДЕОГЛАЗ)
Сегодня наше интервью с Андреем Васильевым – основателем и генеральным директором технологической компании «ВИДЕОГЛАЗ». Компании 20 лет и на сегодняшний день «ВИДЕОГЛАЗ» являются разработчиками и производителями решений для систем безопасности, а также одним…
❤3
Место тестировщика в Agile процессе
22 февраля в 19:00 (МСК) пройдёт вебинар, в рамках которого обсудим место тестировщика в Agile процессе.
Agile принципы и практики стали необходимой частью организации бизнес-процессов в современных компаниях и имеют значительное влияние на развитие продуктов. Однако, многие организации, используя Agile-практики, продолжают применять старые методы обеспечения качества. На данном встрече рассмотрим различия между процессом обеспечения качества в Agile организациях и способы избегания излишней нагрузки на процесс обеспечения качества.
Спикер:
Андрей Нодь (Executive Senior QA Consultant / Testautomation)
Регистрация и подробности
#DevOps #AgileСобытие
22 февраля в 19:00 (МСК) пройдёт вебинар, в рамках которого обсудим место тестировщика в Agile процессе.
Agile принципы и практики стали необходимой частью организации бизнес-процессов в современных компаниях и имеют значительное влияние на развитие продуктов. Однако, многие организации, используя Agile-практики, продолжают применять старые методы обеспечения качества. На данном встрече рассмотрим различия между процессом обеспечения качества в Agile организациях и способы избегания излишней нагрузки на процесс обеспечения качества.
Спикер:
Андрей Нодь (Executive Senior QA Consultant / Testautomation)
Регистрация и подробности
#DevOps #AgileСобытие
Forwarded from Адаптивные организации
Шесть способов построения доверия в команде 👬👭
Возникновение доверия в команде выглядит чем-то загадочным. Иногда кажется, что влиять на этот процесс мы не можем, но это не так! Есть конкретные действия, которые укрепляют доверие, а есть те, которые гарантировано разрушают его.
💛В своей статье Эстер Дерби делится 6 способами построения доверия в команде,
рассказываем о них.
0. Демонстрируй доверие к другим людям
Один из способов сделать это - не критиковать, когда кто-то совершает ошибку или в чем-то разочаровывает вас.
👎Люди, которые всегда делают наихудшие выводы о компетентности и мотивации других, внушают настороженность, а не доверие.
1. Решайте проблемы напрямую
Если кто-то в команде раздражает вас, поговорите с ним напрямую. Это укрепляет доверие.
👎Если вы хотите подорвать доверие к коллегам, пустите сплетню или пожалуйтесь менеджерам.
2. Делитесь личной информацией
Люди склонны доверять людям, которых они знают лично. Общий опыт, общие интересы формируют прочную основу и делают людей “настоящими”. На все это можно опереться, когда возникают трения и конфликты.
👎Если вы хотите разрушить доверие, скрывайте свое мнение или озабоченность каким-то вопросом, вернитесь позже и скажите: “Я с самого начала думал, что это была плохая идея”.
3. Выполняйте взятые на себя обязательства или предупреждайте заранее, если не сможете сделать обещанное
Чтобы команда работала, ее участники должны верить, что их коллеги надежны и будут нести свою долю бремени. Без этой уверенности немногие посвятят себя общей цели. Никто не ожидает, что кто-то сможет постоянно выполнять все свои обязательства. Поэтому, сообщайте коллегам как можно раньше, если не укладываетесь в прогнозируемые сроки.
👎Если хотите казаться ненадежным, сообщите команде о том, что задача не выполнена постфактум.
4. Говорите «нет», когда действительно подразумеваете «нет»
Если вы не можете взяться за задачу или выполнить просьбу, о которой кто-то просит, скажите «нет» и позвольте человеку найти решение в другом месте.👎Скажите «да», но не доведите задачу до конца, чтобы люди начали сомневаться в ваших словах.
5. Делитесь тем, что вы знаете, и тем, чего вы не знаете
Формирование доверия к компетентности — то есть доверия ваших коллег к вашим способностям — означает признание того, что у вас нет ответов на все вопросы. Обращение за помощью помогает другим увидеть в вас настоящего человека, плюс людям обычно нравится быть полезными.
👎Не признавайтесь, когда не знаете ответов. Всезнайка, который ошибается не вызывает доверия.
Как обстоят дела с доверием внутри вашей команды?
Возникновение доверия в команде выглядит чем-то загадочным. Иногда кажется, что влиять на этот процесс мы не можем, но это не так! Есть конкретные действия, которые укрепляют доверие, а есть те, которые гарантировано разрушают его.
💛В своей статье Эстер Дерби делится 6 способами построения доверия в команде,
рассказываем о них.
0. Демонстрируй доверие к другим людям
Один из способов сделать это - не критиковать, когда кто-то совершает ошибку или в чем-то разочаровывает вас.
👎Люди, которые всегда делают наихудшие выводы о компетентности и мотивации других, внушают настороженность, а не доверие.
1. Решайте проблемы напрямую
Если кто-то в команде раздражает вас, поговорите с ним напрямую. Это укрепляет доверие.
👎Если вы хотите подорвать доверие к коллегам, пустите сплетню или пожалуйтесь менеджерам.
2. Делитесь личной информацией
Люди склонны доверять людям, которых они знают лично. Общий опыт, общие интересы формируют прочную основу и делают людей “настоящими”. На все это можно опереться, когда возникают трения и конфликты.
👎Если вы хотите разрушить доверие, скрывайте свое мнение или озабоченность каким-то вопросом, вернитесь позже и скажите: “Я с самого начала думал, что это была плохая идея”.
3. Выполняйте взятые на себя обязательства или предупреждайте заранее, если не сможете сделать обещанное
Чтобы команда работала, ее участники должны верить, что их коллеги надежны и будут нести свою долю бремени. Без этой уверенности немногие посвятят себя общей цели. Никто не ожидает, что кто-то сможет постоянно выполнять все свои обязательства. Поэтому, сообщайте коллегам как можно раньше, если не укладываетесь в прогнозируемые сроки.
👎Если хотите казаться ненадежным, сообщите команде о том, что задача не выполнена постфактум.
4. Говорите «нет», когда действительно подразумеваете «нет»
Если вы не можете взяться за задачу или выполнить просьбу, о которой кто-то просит, скажите «нет» и позвольте человеку найти решение в другом месте.👎Скажите «да», но не доведите задачу до конца, чтобы люди начали сомневаться в ваших словах.
5. Делитесь тем, что вы знаете, и тем, чего вы не знаете
Формирование доверия к компетентности — то есть доверия ваших коллег к вашим способностям — означает признание того, что у вас нет ответов на все вопросы. Обращение за помощью помогает другим увидеть в вас настоящего человека, плюс людям обычно нравится быть полезными.
👎Не признавайтесь, когда не знаете ответов. Всезнайка, который ошибается не вызывает доверия.
Как обстоят дела с доверием внутри вашей команды?
🔥4
Привет!
Сегодня кейс, возможно, напрямую не связанный со Скрамом, но точно связанное с работой Agile-коуча или Сркам-мастера.
Ваша команда работает c очень старым legacy-кодом. К сожалению, команда была создана недавно и не имеет соответствующих знаний о старой платформе. Все Спринты заканчиваются с очень низкой скоростью и без ощутимых результатов.
Что бы вы сделали, чтобы помочь команде добиться успеха?
#AgileCase
Сегодня кейс, возможно, напрямую не связанный со Скрамом, но точно связанное с работой Agile-коуча или Сркам-мастера.
Ваша команда работает c очень старым legacy-кодом. К сожалению, команда была создана недавно и не имеет соответствующих знаний о старой платформе. Все Спринты заканчиваются с очень низкой скоростью и без ощутимых результатов.
Что бы вы сделали, чтобы помочь команде добиться успеха?
#AgileCase
Agile Collage
Привет! Сегодня кейс, возможно, напрямую не связанный со Скрамом, но точно связанное с работой Agile-коуча или Сркам-мастера. Ваша команда работает c очень старым legacy-кодом. К сожалению, команда была создана недавно и не имеет соответствующих знаний…
Не пойму, то ли кейс слишком простым оказался, то ли слишком сложным.
Поставьте тут реакцию
👌 - если слишком простой
😱 - если слишком сложном
🤔 - если просто скучным, либо лень было решать.
В целом @walltouch дал достаточно развернутый и хороший ответ.
От себя лишь добавлю, что стоит понять, какие ожидания у стейкхолдеров от команды, тогда станет понятнее какую стратегию выбрать при работе с ней.
В целом я в таких ситуация обычно использую правило бойскаутов:
Если разработчик вносит изменение в какой-то кусок кода, то должен оставить этот модуль "чище", чем он был до этого, т.е., например, покрыть Unit-тестами и описать комментарии, как он работает.
Код постепенно начнёт улучшаться и не смотря на то что на старте скорость появления бизнес-значимых доработок будет низкая, она начнёт постепенно расти, за счёт того, что код становится качественнее, а разработчикам всё проще разбираться в нем, т.к. коллеги постарались с документированием кода и тестами.
#AgileCase
Поставьте тут реакцию
👌 - если слишком простой
😱 - если слишком сложном
🤔 - если просто скучным, либо лень было решать.
В целом @walltouch дал достаточно развернутый и хороший ответ.
От себя лишь добавлю, что стоит понять, какие ожидания у стейкхолдеров от команды, тогда станет понятнее какую стратегию выбрать при работе с ней.
В целом я в таких ситуация обычно использую правило бойскаутов:
Если разработчик вносит изменение в какой-то кусок кода, то должен оставить этот модуль "чище", чем он был до этого, т.е., например, покрыть Unit-тестами и описать комментарии, как он работает.
Код постепенно начнёт улучшаться и не смотря на то что на старте скорость появления бизнес-значимых доработок будет низкая, она начнёт постепенно расти, за счёт того, что код становится качественнее, а разработчикам всё проще разбираться в нем, т.к. коллеги постарались с документированием кода и тестами.
#AgileCase
Telegram
Agile Collage
Привет!
Сегодня кейс, возможно, напрямую не связанный со Скрамом, но точно связанное с работой Agile-коуча или Сркам-мастера.
Ваша команда работает c очень старым legacy-кодом. К сожалению, команда была создана недавно и не имеет соответствующих знаний…
Сегодня кейс, возможно, напрямую не связанный со Скрамом, но точно связанное с работой Agile-коуча или Сркам-мастера.
Ваша команда работает c очень старым legacy-кодом. К сожалению, команда была создана недавно и не имеет соответствующих знаний…
🤔3👍2😱1🏆1
Друзья, как и обещал отдельная статья про футуроспективу. Правда, на английском: https://link.medium.com/0Mv2b8y8exb
Я использую футуроспективу как правило в двух случаях:
🤔 команда решила все очевидные проблемы, которые могла
🎄либо на Новый год
#facilitation
Я использую футуроспективу как правило в двух случаях:
🤔 команда решила все очевидные проблемы, которые могла
🎄либо на Новый год
#facilitation
Telegram
Agile Collage
Сегодня заключительная часть на тему Что делать, если команда не хочет проводить Ретро?
В прошлые разы мы рассмотрели что делать если
- у команды нет позитивного опыта проведения Ретроспективы
- уровень доверия в команде не позволяет обсуждать проблемы…
В прошлые разы мы рассмотрели что делать если
- у команды нет позитивного опыта проведения Ретроспективы
- уровень доверия в команде не позволяет обсуждать проблемы…
🔥3👍1😁1
Друзья, какой контент вы предпочитаете видеть в этом канале
Anonymous Poll
59%
Статьи, заметки непсредственно в канале
53%
Ссылки на интересные статьи и сайты с короткой пометкой, о чем ссылка
41%
Веселые или интересные картикуи на тему канала
25%
Опросы и/или квизы
63%
Кейсы для решения
0%
Свой ваниант (напишу в комментарии)
User Story Mapping.pdf
544.7 KB
Друзья, кто был на моем мастер-классе по User Story Mapping, держите презентацию.
Спасибо Systems.Education за организацию
#ProductManagement
Спасибо Systems.Education за организацию
#ProductManagement
👍4
Коллега посоветовал инструмент для команд, чьи участники работают в разных часовых поясах.
https://www.worldtimebuddy.com/ - не требует даже авторизации
Поделитесь в коментах, что вы используете, чтобы не запутаться в часовых поясах?
#AgileTools
https://www.worldtimebuddy.com/ - не требует даже авторизации
Поделитесь в коментах, что вы используете, чтобы не запутаться в часовых поясах?
#AgileTools
👍5🤔2
Друзья ещё один вопрос, чтобы улучшить канал. На каком языке готовы читать информацию по ссылкам
Anonymous Poll
24%
Только на русском
50%
Русский и английский
26%
Любой язык - электронные перерводчики легко справляются
Наткнулся на шпаргалку по фаситилитации в сложных ситуациях.
http://www.masterfacilitatorjournal.com/archives/skill223.html
#facilitation
http://www.masterfacilitatorjournal.com/archives/skill223.html
#facilitation
👍2