🤔 Почему внедрение Agile часто идет не по плану?
Компании, которые пытаются внедрить гибкие подходы самостоятельно, неизбежно наступают на одни и те же грабли. И дело не в том, что следовать принципам agile сложно, просто многим не хочется отказываться от привычных процессов.
Вы ведь тоже слышали фразу, что «agile не работает»?
Так получается, если внедрить только внешние атрибуты гибких методологий — спринты, стендапы и ретроспективы — но при этом не менять корпоративную культуру.
Самая главная суть изменений не «на бумаге», а в том, чтобы выстроить доверие и взять ответственность за результат.
В нашей новой статье рассуждаем об этом и делимся «взглядом снизу» на то, что происходит с людьми и процессами во время перехода на Agile.
📄Читать на VC и на Хабр.
Компании, которые пытаются внедрить гибкие подходы самостоятельно, неизбежно наступают на одни и те же грабли. И дело не в том, что следовать принципам agile сложно, просто многим не хочется отказываться от привычных процессов.
Вы ведь тоже слышали фразу, что «agile не работает»?
Так получается, если внедрить только внешние атрибуты гибких методологий — спринты, стендапы и ретроспективы — но при этом не менять корпоративную культуру.
Самая главная суть изменений не «на бумаге», а в том, чтобы выстроить доверие и взять ответственность за результат.
В нашей новой статье рассуждаем об этом и делимся «взглядом снизу» на то, что происходит с людьми и процессами во время перехода на Agile.
📄Читать на VC и на Хабр.
🔥3❤1👍1
📅 Основные ошибки в применении гибких фреймворков (SAFe, LeSS, FlightLevels).
Друзья, приглашаем вас на бесплатный вебинар по актуальной для многих теме масштабирования Agile подходов.
10 марта в 19.00 (GMT+3), онлайн.
Подробности и регистрация вот здесь: https://onagile.ru/webinars/agile-scaling-issues
Друзья, приглашаем вас на бесплатный вебинар по актуальной для многих теме масштабирования Agile подходов.
10 марта в 19.00 (GMT+3), онлайн.
Подробности и регистрация вот здесь: https://onagile.ru/webinars/agile-scaling-issues
🔥3
🏛️ Как научиться спокойно воспринимать новости в любой ситуации
Всегда найдётся заголовок, который может заставить нас понервничать. Но новости никуда не денутся из нашей жизни, и хочется начать к ним относиться легче. Agile может дать конкурентное преимущество и позволить команде чувствовать себя увереннее на фоне любых событий.
Основная цель внедрения Agile — научиться жить в изменчивой среде
Чтобы не тратить годы на разработку, которая может устареть ещё до релиза, Agile позволяет быстро протестировать гипотезы и сразу внести в план коррективы, если ветер вдруг подует не в вашу сторону. Неактуальные задачи легко удаляются из бэклога, чтобы на них не тратить время, а новые — также легко добавляются и приоритезируются.
Можно не откладывать момент и обсуждать с командой, что работает, а что нет на регулярных встречах, и на месте адаптировать свою стратегию.
Попробовали → оценили результат → сделали выводы → поехали дальше
А ещё в кросс-функциональных командах работают специалисты с разными компетенциями, и это огромный плюс — они смотрят на ситуацию с десятка разных сторон.
Любая неопределённость — это стресс для бизнеса, для руководителей, и для сотрудников. Именно умение быстро реагировать на изменения даёт самое большое конкурентное преимущество, когда всё вокруг может измениться буквально за один вечер — будь то политика, экономика или другие факторы.
Всегда найдётся заголовок, который может заставить нас понервничать. Но новости никуда не денутся из нашей жизни, и хочется начать к ним относиться легче. Agile может дать конкурентное преимущество и позволить команде чувствовать себя увереннее на фоне любых событий.
Основная цель внедрения Agile — научиться жить в изменчивой среде
Чтобы не тратить годы на разработку, которая может устареть ещё до релиза, Agile позволяет быстро протестировать гипотезы и сразу внести в план коррективы, если ветер вдруг подует не в вашу сторону. Неактуальные задачи легко удаляются из бэклога, чтобы на них не тратить время, а новые — также легко добавляются и приоритезируются.
Можно не откладывать момент и обсуждать с командой, что работает, а что нет на регулярных встречах, и на месте адаптировать свою стратегию.
Попробовали → оценили результат → сделали выводы → поехали дальше
А ещё в кросс-функциональных командах работают специалисты с разными компетенциями, и это огромный плюс — они смотрят на ситуацию с десятка разных сторон.
Любая неопределённость — это стресс для бизнеса, для руководителей, и для сотрудников. Именно умение быстро реагировать на изменения даёт самое большое конкурентное преимущество, когда всё вокруг может измениться буквально за один вечер — будь то политика, экономика или другие факторы.
👍5🔥1
💻 Где ваши сотрудники — удаленно, в офисе или чередуют оба формата
Забавно, как быстро меняется мир. Еще недавно все обсуждали, как запустить удаленный офис, а сегодня мы наблюдаем тренд на осознанное возвращение на рабочие места.
Чего нам так не хватает дома? Личного общения, командного духа или закрыть за собой дверь офиса в шесть вечера, чтобы вдохнуть свежий запах окончания работы?
Что изменилось для тех, кто вернулся в офисы
Давайте прогуляемся по современному рабочему пространству: просторные комнаты для планирования спринтов и демо, уютные зоны для daily scrum, тихие пространства для глубокой работы над задачами.
Красота современного подхода в том, каждый уголок имеет свое предназначение. И что к этому моменту команды уже научились оценивать сложность задач и свою скорость через velocity, а не через время, проведенное за столом.
Сами методологии Agile эволюционировали вместе с изменением рабочей культуры. Те же спринты перестали быть прерогативой только IT-команд. Всё больше компаний сейчас начинают видет ценность не столько в наборе практик, сколько в образе мышления, который помогает командам оставаться эффективными при любом формате работы.
Интересно наблюдать, как корпоративне ценности продолжают развиваться, независимо от того, где физически находятся члены команды.
Чувствуете ли вы, что вам не хватает в офисе тех сотрудников, которые сейчас на удалёнке?
Забавно, как быстро меняется мир. Еще недавно все обсуждали, как запустить удаленный офис, а сегодня мы наблюдаем тренд на осознанное возвращение на рабочие места.
Чего нам так не хватает дома? Личного общения, командного духа или закрыть за собой дверь офиса в шесть вечера, чтобы вдохнуть свежий запах окончания работы?
Что изменилось для тех, кто вернулся в офисы
Давайте прогуляемся по современному рабочему пространству: просторные комнаты для планирования спринтов и демо, уютные зоны для daily scrum, тихие пространства для глубокой работы над задачами.
Красота современного подхода в том, каждый уголок имеет свое предназначение. И что к этому моменту команды уже научились оценивать сложность задач и свою скорость через velocity, а не через время, проведенное за столом.
Сами методологии Agile эволюционировали вместе с изменением рабочей культуры. Те же спринты перестали быть прерогативой только IT-команд. Всё больше компаний сейчас начинают видет ценность не столько в наборе практик, сколько в образе мышления, который помогает командам оставаться эффективными при любом формате работы.
При этом сама удаленка никуда не делась — она просто заняла естественное место в рабочей экосистеме.
Интересно наблюдать, как корпоративне ценности продолжают развиваться, независимо от того, где физически находятся члены команды.
Чувствуете ли вы, что вам не хватает в офисе тех сотрудников, которые сейчас на удалёнке?
👍6❤2🔥2
Что общего у директора по продукту (CPO) и робота C-3PO?
Не только названия. Вспомните черты этого легендарного дроида из «Звёздных войнов».
C-3PO изначально создавался как дипломат и голос разума среди людей — а это как раз те качества, которые нужны любому продакту. Но, увы, робота-руководителя нам никто не соберёт.
В гибких организациях за стратегическое видение продукта отвечает именно CPO (Chief Product Officer). Он поддерживает культуру постоянных улучшений, обеспечивает прозрачность и согласованность действий всех команд.
Но самое главное — он объединяет между собой разработчиков, дизайнеров, маркетологов, руководителей компании и бизнес-заказчиков, чтобы все смотрели в одном направлении. Также, как C-3PO объединяет разные культуры, используя шесть миллионов форм общения.
Справился бы C-3PO с управлением продуктом?
Да, этот дроид хороший лидер и умеет сглаживать конфликты, даже с мандалорцами и с теми, кто говорит на разных языках. Например с заказчиками разработки и разработчиками. Заодно он может предупредить команду о возможных рисках, и не стоит игнорировать его советы, как это делает R2-D2.
Его задача — сделать так, чтобы все стороны нашли общий язык. Именно такими навыки хочется, чтобы обладал каждый продуктовый руководитель.
Не только названия. Вспомните черты этого легендарного дроида из «Звёздных войнов».
C-3PO изначально создавался как дипломат и голос разума среди людей — а это как раз те качества, которые нужны любому продакту. Но, увы, робота-руководителя нам никто не соберёт.
В гибких организациях за стратегическое видение продукта отвечает именно CPO (Chief Product Officer). Он поддерживает культуру постоянных улучшений, обеспечивает прозрачность и согласованность действий всех команд.
Но самое главное — он объединяет между собой разработчиков, дизайнеров, маркетологов, руководителей компании и бизнес-заказчиков, чтобы все смотрели в одном направлении. Также, как C-3PO объединяет разные культуры, используя шесть миллионов форм общения.
Справился бы C-3PO с управлением продуктом?
Да, этот дроид хороший лидер и умеет сглаживать конфликты, даже с мандалорцами и с теми, кто говорит на разных языках. Например с заказчиками разработки и разработчиками. Заодно он может предупредить команду о возможных рисках, и не стоит игнорировать его советы, как это делает R2-D2.
Его задача — сделать так, чтобы все стороны нашли общий язык. Именно такими навыки хочется, чтобы обладал каждый продуктовый руководитель.
👍9🥰2😁1
📌 Начинаем знакомство с LeSS
Правильно выстроенный Scrum очень хорош, но при увеличении команды выше 9 человек даже он начинает трещать по швам. Мы часто слышим это от клиентов:
Если вы руководите большой командой и по каким-то причинам не можете её разделить, то классический Scrum придется доработать.
Мы подготовили для вас серию материалов о LeSS (Large-Scale Scrum) — это фреймворк масштабирования, который позволяет большому количеству людей работать над одним продуктом, с едиными продакт-оунером и бэклогом, и при этом по-прежнему каждые две недели поставлять общий интегрированный результат.
Глава 1. Введение в LeSS (Large-Scale Scrum, Скрам в Масштабе)
Глава 2. Роли и организационная структура в LeSS
Материалы на тему LeSS и других подходов к масштабированию будут выходить на нашем сайте — их можно читать в любой последовательности, но лучше по порядку.
Если после прочтения захочется разобраться в деталях, мы подготовили два мероприятия:
📅 Бесплатный вебинар, который пройдёт 10 марта в 19:00 (GMT+3) Основные ошибки в применении гибких фреймворков SAFe, LeSS и FlightLevels.
📅 Полноценный трехдневный тренинг Масштабирование Agile на основе SAFe, LeSS и Fligth Levels 24-26 марта.
И конечно, вы всегда можете задать свой вопрос о масштабировании гибких подходов в комментариях ⤵️
Правильно выстроенный Scrum очень хорош, но при увеличении команды выше 9 человек даже он начинает трещать по швам. Мы часто слышим это от клиентов:
У нас команда из 20 человек, и процессы уже не работают как надо.
Если вы руководите большой командой и по каким-то причинам не можете её разделить, то классический Scrum придется доработать.
Мы подготовили для вас серию материалов о LeSS (Large-Scale Scrum) — это фреймворк масштабирования, который позволяет большому количеству людей работать над одним продуктом, с едиными продакт-оунером и бэклогом, и при этом по-прежнему каждые две недели поставлять общий интегрированный результат.
Глава 1. Введение в LeSS (Large-Scale Scrum, Скрам в Масштабе)
Глава 2. Роли и организационная структура в LeSS
Материалы на тему LeSS и других подходов к масштабированию будут выходить на нашем сайте — их можно читать в любой последовательности, но лучше по порядку.
Если после прочтения захочется разобраться в деталях, мы подготовили два мероприятия:
📅 Бесплатный вебинар, который пройдёт 10 марта в 19:00 (GMT+3) Основные ошибки в применении гибких фреймворков SAFe, LeSS и FlightLevels.
📅 Полноценный трехдневный тренинг Масштабирование Agile на основе SAFe, LeSS и Fligth Levels 24-26 марта.
И конечно, вы всегда можете задать свой вопрос о масштабировании гибких подходов в комментариях ⤵️
🔥6
Когда речь заходит об аппаратной разработке, многие считают, что к ней невозможно применить Agile
Часто мы слышим разные опасения, что Agile нельзя перенести в изначальном виде, и что это слишком рискованно:
Наш кейс показывает, что применить Agile в аппаратной разработке можно, если правильно адаптировать его и быть готовым к изменениям.
Что делать, если статусные отчёты не отражают, когда будет выпущена та или иная модель, а статус «почти готово» держится месяцами?
Рассказываем об этом в нашем новом кейсе, переходите читать.
— Как можно внедрить гибкие методы в разработку электроники, где много физических компонентов и сложных взаимодействий?
Часто мы слышим разные опасения, что Agile нельзя перенести в изначальном виде, и что это слишком рискованно:
— У нас нет возможности выпускать новый инкремент каждые две недели. А ещё, чтобы исправить ошибку в коде нужно потратить пару минут, а переделывать электронику — это долго и дорого.
Наш кейс показывает, что применить Agile в аппаратной разработке можно, если правильно адаптировать его и быть готовым к изменениям.
Что делать, если статусные отчёты не отражают, когда будет выпущена та или иная модель, а статус «почти готово» держится месяцами?
Рассказываем об этом в нашем новом кейсе, переходите читать.
🔥3
Представьте, если бы Скрам-мастер и Владелец продукта пришли в ресторан
Атмосфера была напряжённой. С кухни доносились крики поваров вперемешку с шипением масла, гости прибывали, а офцианты едва успевали справляться и путали заказы. Картина, знакомая многим, кто работал в ресторанной сфере.
Наблюдая за этим, Скрам-мастер отложил меню и предложил собрать команду ресторана на быструю встречу:
Сказал он, доставая стикеры и приклеивая их к стене. На каждом он записал конкретную проблему и возможное решение.
Его первым предложением было — ввести ежедневные 15-минутные собрания перед открытием, чтобы команда могла обсуждать стоп-лист, правила обслуживания и вечернюю посадку.
Вторая идея — кросс-функциональные смены. Пусть официанты проведут день на кухне и в баре, чтобы лучше понимать, как готовятся блюда и напитки, и сколько времени это занимает.
Владелец Продукта тем временем проанализировал отложенное Скрам-мастером меню с точки зрения потребностей гостей:
Он предложил собрать все технологические карты поваров в единый бэклог продукта и приоритезировать их на основе реального спроса. Это помогло бы кухне эффективнее планировать закупки и оптимизировать хранение продуктов.
К концу вечера, у бара тоже появился свой чек-лист:
1. Проверять соответствие заказа перед отдачей
2. Брать бокалы только сухими руками
3. Контролировать сроки годности молока и сливок каждое утро
На следующий вечер в ресторане стало заметно спокойнее: уменьшилось количество задержек по заказам, кухня и зал начали лучше взаимодействовать, а ошибок стало значительно меньше.
Этот пример того, как базовые принципы гибкого управления — ежедневные встречи, прозрачность, кросс-функциональное обучение и внимание к потребностям пользователей — помогают улучшить процессы даже в таком классическом бизнесе, как ресторан.
Атмосфера была напряжённой. С кухни доносились крики поваров вперемешку с шипением масла, гости прибывали, а офцианты едва успевали справляться и путали заказы. Картина, знакомая многим, кто работал в ресторанной сфере.
Наблюдая за этим, Скрам-мастер отложил меню и предложил собрать команду ресторана на быструю встречу:
— Давайте обсудим, что можно улучшить в наших процессах
Сказал он, доставая стикеры и приклеивая их к стене. На каждом он записал конкретную проблему и возможное решение.
Его первым предложением было — ввести ежедневные 15-минутные собрания перед открытием, чтобы команда могла обсуждать стоп-лист, правила обслуживания и вечернюю посадку.
Вторая идея — кросс-функциональные смены. Пусть официанты проведут день на кухне и в баре, чтобы лучше понимать, как готовятся блюда и напитки, и сколько времени это занимает.
Владелец Продукта тем временем проанализировал отложенное Скрам-мастером меню с точки зрения потребностей гостей:
— Нужно обновить меню. В нём не хватает нескольких важных категорий блюд. Я изучил отзывы, и гости часто спрашивают рыбные и вегетарианские позиции.
Он предложил собрать все технологические карты поваров в единый бэклог продукта и приоритезировать их на основе реального спроса. Это помогло бы кухне эффективнее планировать закупки и оптимизировать хранение продуктов.
К концу вечера, у бара тоже появился свой чек-лист:
1. Проверять соответствие заказа перед отдачей
2. Брать бокалы только сухими руками
3. Контролировать сроки годности молока и сливок каждое утро
На следующий вечер в ресторане стало заметно спокойнее: уменьшилось количество задержек по заказам, кухня и зал начали лучше взаимодействовать, а ошибок стало значительно меньше.
Этот пример того, как базовые принципы гибкого управления — ежедневные встречи, прозрачность, кросс-функциональное обучение и внимание к потребностям пользователей — помогают улучшить процессы даже в таком классическом бизнесе, как ресторан.
🔥5👍3😁2
Друзья, уже в ближайший понедельник мы проведём бесплатный вебинар Основные ошибки в применении фреймворков масштабирования SAFe, LeSS и Flight Levels.
📅 10 марта в 19:00 (GMT+3)
Ведущий Артём Гринякин — тренер в области Agile и современных методик управления.
На вебинаре разберём
• Типичные ошибки при внедрении SAFe, LeSS и FlightLevels — как их избежать и сэкономить деньги при трансформации.
• Стратегии трансформации с минимальными рисками — практические советы от экспертов, прошедших через подобные изменения.
• Методы вовлечения сотрудников и руководства.
• Практические кейсы и примеры из реальной жизни.
📎 Чтобы принять участие, регистрируйтесь по ссылке.
📅 10 марта в 19:00 (GMT+3)
Ведущий Артём Гринякин — тренер в области Agile и современных методик управления.
На вебинаре разберём
• Типичные ошибки при внедрении SAFe, LeSS и FlightLevels — как их избежать и сэкономить деньги при трансформации.
• Стратегии трансформации с минимальными рисками — практические советы от экспертов, прошедших через подобные изменения.
• Методы вовлечения сотрудников и руководства.
• Практические кейсы и примеры из реальной жизни.
📎 Чтобы принять участие, регистрируйтесь по ссылке.
❤2🔥1
🤝 Как Agile может усилить бережливое производство
Если вам близки идеи Agile, то вам может быть интересна концепция бережливого производства (Lean Production). Они идут рука об руку, но у них немного разный компас.
Обе эти философии отлично дополняют друг друга и преследуют несколько общих целей: снижение издержек, ускорение принятия решений и повышение конкурентоспособности компании на рынке.
Но каждая из них делает это по-своему
🔸 Lean помогает избежать ненужного, а Agile — создавать нужное.
🔸 Lean — совершенствует существующие процессы, а Agile — помогает управлять ими в быстро меняющихся условиях.
🔸 Lean хорошо работает при стабильном спросе, а Agile, — когда рынок пересатёт быть предсказуемым.
🔸 Lean ориентирован на производство, Agile — на людей.
На одном из недавних тренингов участники разбирали задание, связанное с моделью Кеневин для анализа проблем. И во время обсуждения один из них, руководитель высшего звена на производстве, поделился своим мнением:
Это интересная мысль. У Agile есть преимущество, которое хорошо дополняет Lean Production, — гибкость в условиях перемен.
Когда рыночная ситуация меняется, именно Agile-практики, например Scrum, позволяют быстро адаптироваться за счет коротких итераций с частыми релизами и регулярному вовлечению руководства в проект.
Кроме того, Agile дает командам больше самостоятельности. В гибких организациях сотрудники самим принимают решения, расставляют приоритеты и организуют свою работу, опираясь на задачи в бэклоге.
Если вам близки идеи Agile, то вам может быть интересна концепция бережливого производства (Lean Production). Они идут рука об руку, но у них немного разный компас.
Обе эти философии отлично дополняют друг друга и преследуют несколько общих целей: снижение издержек, ускорение принятия решений и повышение конкурентоспособности компании на рынке.
Но каждая из них делает это по-своему
🔸 Lean помогает избежать ненужного, а Agile — создавать нужное.
🔸 Lean — совершенствует существующие процессы, а Agile — помогает управлять ими в быстро меняющихся условиях.
🔸 Lean хорошо работает при стабильном спросе, а Agile, — когда рынок пересатёт быть предсказуемым.
🔸 Lean ориентирован на производство, Agile — на людей.
На одном из недавних тренингов участники разбирали задание, связанное с моделью Кеневин для анализа проблем. И во время обсуждения один из них, руководитель высшего звена на производстве, поделился своим мнением:
Пока чёткие процедуры не будут отработнаны, компания всегда будет попадать в хаотичную среду. Это во многом перекликается с тем, что мы уже внедрили в рамках бережливого производства, только в контексте бизнес-процессов.
Это интересная мысль. У Agile есть преимущество, которое хорошо дополняет Lean Production, — гибкость в условиях перемен.
Когда рыночная ситуация меняется, именно Agile-практики, например Scrum, позволяют быстро адаптироваться за счет коротких итераций с частыми релизами и регулярному вовлечению руководства в проект.
Кроме того, Agile дает командам больше самостоятельности. В гибких организациях сотрудники самим принимают решения, расставляют приоритеты и организуют свою работу, опираясь на задачи в бэклоге.
🔥5👍2😁2
На прошедшем вебинаре мы говорили об основных ошибках при внедрении фреймворков SAFe, LeSS и Flight Levels. Один из участников задал нам интересный вопрос:
Прежде чем выбрать один фреймворк, хочется как бы повертеть его в руках, будто это деталь, и посмотреть, как она соединится с ситуацией. Но стоит применить его — и что-то не стыкуется. Ведь у каждой компании своя специфика и контексты.
Вначале было бы полезно разобраться в механике — как именно тот или иной подход повлияет на организацию или на отдельные подразделения. Понять, к чему приведут эти изменения и соответствуют ли они ожиданиям. А уже после этого переходить к характеристикам и тонкостям каждого фреймворка.
На карточках мы разобрали, какие изменения происходят в организации при внедрении разных масштабируемых фреймворков. А ещё недавно у нас в блоге вышла статья, где мы детально разобрали каждый из них.
— Я поймал себя на мысли, что, возможно, не до конца понимаю разницу между SAFe, LeSS и Flight Levels. Мы обсуждаем ошибки, связанные с фреймворками, но мне кажется, что сначала нужно чётко понимать различия между ними.
В моей практике я работаю с четырьмя командами и уже адаптировал процессы так, что у нас нет серьёзных сложностей. Есть синхронизация, оптимизированные затраты на встречи, ритуалы занимают не более 10 часов за двухнедельный спринт — считаю это оптимальным.
Но было бы гораздо проще обсуждать ошибки и улучшения, если бы существовал некий наглядный материал, который помог бы чётко понять разницу между этими фреймворками. Тогда логично было бы двигаться дальше — к разбору ошибок и их влиянию на работу команд.
Прежде чем выбрать один фреймворк, хочется как бы повертеть его в руках, будто это деталь, и посмотреть, как она соединится с ситуацией. Но стоит применить его — и что-то не стыкуется. Ведь у каждой компании своя специфика и контексты.
Вначале было бы полезно разобраться в механике — как именно тот или иной подход повлияет на организацию или на отдельные подразделения. Понять, к чему приведут эти изменения и соответствуют ли они ожиданиям. А уже после этого переходить к характеристикам и тонкостям каждого фреймворка.
На карточках мы разобрали, какие изменения происходят в организации при внедрении разных масштабируемых фреймворков. А ещё недавно у нас в блоге вышла статья, где мы детально разобрали каждый из них.
👍3🔥1
🗣 История нашего клиента
Недавно мы поделились кейсом применения Scrum в аппаратной разработке, где в том числе организовали открытый спринт-ревью для всех сотрудников. Другой наш клиент, прочитав кейс, вспомнил свой опыт и решил поделиться:
Давайте разберёмся
Показать итог работы за короткий промежуток времени на широкую аудиторию — это довольно ответственный шаг. Многим, кто привык к традиционному управлению проектами, может казаться, что частые встречи только мешают работе и тормозят процессы.
Но такая ситуация рано или поздно может произойти с теми, кто решился на перемены. Любые изменения переживают фазу сопротивлений, поэтому важно, чтобы в них участвовали только те, кому это искренне интересно, без принуждений.
Можно постараться вовлечь всех участников. Например, добавить больше вопросов к аудитории, обсуждений и живого диалога. Но главное — подготовить получившийся инкремент продукта и результаты гипотез, а не слайды в PowerPoint. Так встреча станет продуктивней и пройдёт с опорой на результат.
Обсудив это с клиентом, мы получили ответ:
Недавно мы поделились кейсом применения Scrum в аппаратной разработке, где в том числе организовали открытый спринт-ревью для всех сотрудников. Другой наш клиент, прочитав кейс, вспомнил свой опыт и решил поделиться:
Мы тоже недавно провели открытый спринт-ревью — результат неоднозначный. Не всем зашло, не все готовы тратить на это время.
Давайте разберёмся
Показать итог работы за короткий промежуток времени на широкую аудиторию — это довольно ответственный шаг. Многим, кто привык к традиционному управлению проектами, может казаться, что частые встречи только мешают работе и тормозят процессы.
Но такая ситуация рано или поздно может произойти с теми, кто решился на перемены. Любые изменения переживают фазу сопротивлений, поэтому важно, чтобы в них участвовали только те, кому это искренне интересно, без принуждений.
Можно постараться вовлечь всех участников. Например, добавить больше вопросов к аудитории, обсуждений и живого диалога. Но главное — подготовить получившийся инкремент продукта и результаты гипотез, а не слайды в PowerPoint. Так встреча станет продуктивней и пройдёт с опорой на результат.
Обсудив это с клиентом, мы получили ответ:
Мы решили продолжить проводить открытые спринт-ревью — нужно время, чтобы осознать ценность. Сворачивать с этого пути не планируем!
👍3🔥1
💭 Тупик в груминге
Представьте, что команда разработчиков собралась на еженедельный груминг и видит на экране список новых задач.
Владелец продукта открывает первую:
Если описания задач будут сформулированы в общих чертах и лишены деталей, то время, отведенное на груминг уйдет не на оценку задач, а на попытки выяснить, что же они значат.
Если в этот момент ни один участник встречи не выскажется, то обсуждение первой задачи может затянуться на 30-40 минут. И только ближе к концу окажется, что её вообще не планировали брать в ближайший спринт.
Может случиться так, что кто-то уткнется в телефон, а фасилитатор не сможет вернуть фокус, и команда окончательно выпадет из процесса. По окончанию груминга у всех останется лишь ощущение впустую потраченного времени, а это может и вовсе демотивировать команду ходить на встречи.
Ответа нет.
Как не потратить время на груминге впустую и решить перечисленные проблемы? Ответили на карточках.
Бывали ли у вас такие ситуации, и как вы с ними справились? Поделитесь в комментариях.
Представьте, что команда разработчиков собралась на еженедельный груминг и видит на экране список новых задач.
Владелец продукта открывает первую:
— «Реализовать улучшение UI перевода между счетами».
— А что конкретно нужно улучшить?
— Ну, чтобы было удобнее. Заказчики говорят, что интерфесн не понятный.
Если описания задач будут сформулированы в общих чертах и лишены деталей, то время, отведенное на груминг уйдет не на оценку задач, а на попытки выяснить, что же они значат.
— Какие у нас приоритетные задачи?
Если в этот момент ни один участник встречи не выскажется, то обсуждение первой задачи может затянуться на 30-40 минут. И только ближе к концу окажется, что её вообще не планировали брать в ближайший спринт.
Может случиться так, что кто-то уткнется в телефон, а фасилитатор не сможет вернуть фокус, и команда окончательно выпадет из процесса. По окончанию груминга у всех останется лишь ощущение впустую потраченного времени, а это может и вовсе демотивировать команду ходить на встречи.
— Что в итоге решили?
Ответа нет.
Как не потратить время на груминге впустую и решить перечисленные проблемы? Ответили на карточках.
Бывали ли у вас такие ситуации, и как вы с ними справились? Поделитесь в комментариях.
👍4🔥1
Недавно с клиентом мы обсуждали, сколько должно длиться планирование спринта. В какой-то момент нам задали вопрос:
Планирование — это встреча, которую обычно проводят в первый день нового спринта. Согласно Scrum Guide, максимальное время, которое можно выделить на неё, составляет 4 часа для двухнедельного спринта, но не больше.
Если планирование регулярно отнимает у команды много времени, хотя она собралась не вчера — значит, что-то идет не так. Причин может быть несколько, вот на что стоит обратить внимание:
• Задачи недостаточно детализированы
• Команда впервые видит задачи
• Нет критериев, когда задача считается готовой к работе
• Сильно углубились в технические детали
В таких ситуациях бывает достаточно качественно описать задачи, чтобы они соответствовали Definition of Ready, и уделить больше внимания грумингу бэклога, чтобы определиться что делать. На планировании команда решает только, какие задачи берёт в спринт и как будет их выполнять. И если все хорошо подготовлено, то двухнедельный спринт можно спланировать за 1,5–2 часа.
— У нас планирование двухнедельного спринта стабильно тянется от 4 часов, хотя команда уже давно работает вместе. Что мы делаем не так, если в нашем случае это должно занимать всего 1,5-2 часа?
Планирование — это встреча, которую обычно проводят в первый день нового спринта. Согласно Scrum Guide, максимальное время, которое можно выделить на неё, составляет 4 часа для двухнедельного спринта, но не больше.
Если планирование регулярно отнимает у команды много времени, хотя она собралась не вчера — значит, что-то идет не так. Причин может быть несколько, вот на что стоит обратить внимание:
• Задачи недостаточно детализированы
• Команда впервые видит задачи
• Нет критериев, когда задача считается готовой к работе
• Сильно углубились в технические детали
В таких ситуациях бывает достаточно качественно описать задачи, чтобы они соответствовали Definition of Ready, и уделить больше внимания грумингу бэклога, чтобы определиться что делать. На планировании команда решает только, какие задачи берёт в спринт и как будет их выполнять. И если все хорошо подготовлено, то двухнедельный спринт можно спланировать за 1,5–2 часа.
👍3🔥1
Крайне интересный факт, если это правда. Похоже, самый длинный контракт на разработку ПО в истории.
Конечно, его необходимо отменить, но интересно то, что его точно не следует заменять на модель оплаты по результатам (пожалуйста!).
Как мы все знаем, такие контракты не работают хорошо и, независимо от стиля управления, 100% приводят к низкому качеству продукта, продлению сроков и перерасходу бюджета.
Базовая причина в том, что никто не может написать настолько исчерпывающие бизнес-требования, чтобы внешние разработчики могли просто преобразовать их в программный продукт, соответствующий ожиданиям.
Всегда есть место для изменений в требованиях, но оплата по результатам — это по сути контракт с фиксированной ценой и фиксированным объёмом работ.
Вот почему Agile подход здесь необходим и должен использоваться в любом случае.
Исходный текст со скриншота:
“Существует закономерность во всех государственных учреждениях, где контракты на "модернизацию" ИТ не оплачивают результаты/производительность; вместо этого они платят за время.
Следовательно, у подрядчиков есть стимул "никогда не заканчивать", что приводит к невероятным растратам.
Например, модернизация Налоговой службы США (IRS) началась в 1990 году с планируемым завершением в 1996 году. Сегодня работа не завершена, и подрядчики говорят, что до завершения ещё 5 лет. 29 лет отставания от графика и примерно 15 млрд долларов перерасхода бюджета.
Проигрывают все, кроме государственных подрядчиков. Это должно измениться.
На этой неделе IRS заморозила контракты на модернизацию на сумму около 1,5 млрд долларов, ни один из которых не влияет на подачу налоговых деклараций. Все эти контракты будут либо отменены, либо условия контрактов будут изменены на оплату по результатам.”
Как вам такое? 🙂
Конечно, его необходимо отменить, но интересно то, что его точно не следует заменять на модель оплаты по результатам (пожалуйста!).
Как мы все знаем, такие контракты не работают хорошо и, независимо от стиля управления, 100% приводят к низкому качеству продукта, продлению сроков и перерасходу бюджета.
Базовая причина в том, что никто не может написать настолько исчерпывающие бизнес-требования, чтобы внешние разработчики могли просто преобразовать их в программный продукт, соответствующий ожиданиям.
Всегда есть место для изменений в требованиях, но оплата по результатам — это по сути контракт с фиксированной ценой и фиксированным объёмом работ.
Вот почему Agile подход здесь необходим и должен использоваться в любом случае.
Исходный текст со скриншота:
“Существует закономерность во всех государственных учреждениях, где контракты на "модернизацию" ИТ не оплачивают результаты/производительность; вместо этого они платят за время.
Следовательно, у подрядчиков есть стимул "никогда не заканчивать", что приводит к невероятным растратам.
Например, модернизация Налоговой службы США (IRS) началась в 1990 году с планируемым завершением в 1996 году. Сегодня работа не завершена, и подрядчики говорят, что до завершения ещё 5 лет. 29 лет отставания от графика и примерно 15 млрд долларов перерасхода бюджета.
Проигрывают все, кроме государственных подрядчиков. Это должно измениться.
На этой неделе IRS заморозила контракты на модернизацию на сумму около 1,5 млрд долларов, ни один из которых не влияет на подачу налоговых деклараций. Все эти контракты будут либо отменены, либо условия контрактов будут изменены на оплату по результатам.”
Как вам такое? 🙂
👍4🤔1