HR-практики в Скрам и LeSS

В этой статье вы найдете информацию о важности HR-практик в LeSS, а также список экспериментов  из книги “Agile Development: Thinking and Organizational for Large-Scale Scrum”, которые вы можете использовать.

Почему HR-практики важны в Скраме и LeSS.

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

Модель Джея Гилбрайта “Star Model” говорит о том, что стратегия, структура, процессы, награды и HR-практики в организации должны находиться в балансе и подкреплять друг друга. Иначе создается напряжение. К примеру, текущая функциональная организационная структура может мешать компании достигать таких стратегических целей, как гибкость.

Читать далее «HR-практики в Скрам и LeSS»

Повышаем гибкость с Feature Team Adoption Map (FTAM)

Перевод оригинальной статьи “Feature Team Adoption Map Explained” Сезарио Рамоса, которая появилась в нашем англоязычном блоге в сентябре 2018 года.

Когда заходит речь про внедрение LeSS, инструмент Feature Team Adoption Map (FTAM, «карта внедрения фиче-команд») часто используется как один из самых мощных инструментов. Это ценный инструмент, который можно использовать для различных целей.

Что это такое?

Мне не удалось найти официальное определение в литературе по LeSS, но, на мой взгляд, следующее определение хорошо отражает суть: «Feature Team Adoption Map — это визуальный график, отражающий способность команды поставить готовый продукт. Эта способность выражается как потенциальный объем работы для команды и степень кросс-функциональности команды».

Критерии Готовности (DoD) показывают возможности команды с точки зрения активностей, необходимых для поставки потенциально готового к релизу продукта, а это то же самое, что и степень кросс-функциональности команды. FTAM дополняет их знанием предметной сферы продукта, а это то же самое, что и степень кросс-компонентных возможностей команды. Другими словами, FTAM — это расширение DoD, добавляющее к этой концепции второе измерение: продукт.

Изображение FTAM, представленное ниже, взято из книги по LeSS.

Читать далее «Повышаем гибкость с Feature Team Adoption Map (FTAM)»

Скрам-мастер: спокойный, бескорыстный и отзывчивый

Недавно Далай Лама опубликовал статью “Почему лидеры должны быть внимательными, бескорыстными и отзывчивыми” в Harvard Business Review. Мне кажется, что эта модель отлично ложится на Скрам-мастера. Предлагаю вам небольшие выдержки. Оцените сами.

Быть спокойным и осознанным

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

Страх и тревога могут привести к гневу и жестокости. Противоположность страха — доверие, которое укрепляет нашу веру в себя. Сострадание также уменьшает страх, поскольку оно олицетворяет собой заботу о благополучии других. Именно эти качества, а не деньги и сила, привлекают друзей. Когда мы находимся под влиянием гнева или одержимости, мы можем не видеть ситуацию целиком или оценивать ее объективно. Когда наш ум полон отзывчивости, он спокоен, и мы используем его здраво, правильно, практично и целенаправленно. Читать далее «Скрам-мастер: спокойный, бескорыстный и отзывчивый»

6 мифов об Аджайл-разработке (Майк Кон)

Перевод оригинальной статьи Майка Кона Six Agile Product Development Myths — Busted

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

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

Однако при том, что у Аджайл философии есть много преимуществ, похоже, что и заблуждений не меньше. В этой статье я хотел бы разрушить шесть мифов о разработке Аджайл-продуктов. Читать далее «6 мифов об Аджайл-разработке (Майк Кон)»

Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)

Обзоры Спринта

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

  • Владелец Продукта открыл встречу и громко зачитал Цели Спринта, над которыми работала продуктовая группа. Затем Владелец Продукта перечислил элементы, которые уже были выполнены.
  • Команды по очереди кратко рассказали о сложностях, с которыми им пришлось столкнуться во время Спринта, и о том, как им удалось (или не удалось) их преодолеть.
  • Гостей пригласили посетить станции. Событие было организовано в формате «базара» или ее более структурированном варианте «выставка». На каждой станции у нас было по меньшей мере два разработчика. Один из них демонстрировал Инкремент и просил дать отзывы о нем, а другой просто все записывал.
  • После демонстрации мы вернулись к формату открытого обсуждения. Владелец Продукта рассказал о новостях рынка, изменил приоритеты элементов Бэклога Продукта и ответил на все вопросы.
  • Затем гости покинули помещение, а команды и Владелец Продукта собрали обратную связь по всем станциям и, когда это требовалось, обновили некоторые из артефактов — карту влияния (impact map), канвас ценностного предложения (value-proposition canvas), карту историй (story mapping) и, конечно, Бэклог Продукта.

Читать далее «Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)»

Почему создание «Центра Аджайл-компетенции» очень плохая идея

Перевод оригинальной статьи Энтони Мерсино “Why an Agile Center of Excellence is a Really Bad Idea”

Многие компании создают специальные подразделения для сопровождения Аджайл-трансформаций. Они получают разные названия. Два варианта, которые я считаю совершенно неудачными, это “Центр Аджайл-компетенции” и “Офис управления Аджайл-проектами”. Я считаю, что создание подобных подразделений вообще плохая идея. Объясню почему.

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

Стандартизация — звучит прекрасно, пока вы не начинаете понимать, что она душит инновации и отбивает желание экспериментировать, так как небольшая группа людей уже решила за всех остальных, как они должны двигаться вперед. Власть и контроль полностью формализованы. Централизация убивает эффективность. И в результате вместо того, чтобы вдохновлять людей и доверять им, отгородившись от сотрудников, руководители подразделения решают, как будет лучше для всех. Читать далее «Почему создание «Центра Аджайл-компетенции» очень плохая идея»

Мультикомандное уточнение Бэклога Продукта

Перевод оригинальной статьи Сезарио Рамоса «Multi-team Backlog Refinement»

В этой небольшой статье я поделюсь с вами некоторыми советами по мультикомандному Уточнению Бэклога Продукта.

Что такое Уточнение Бэклога Продукта?

Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта (Product Backlog Items, PBI), которые предстоит взять в работу в следующих Спринтах. В однокомандном Скраме команда обычно проводит одну или несколько подобных встреч за Спринт. 

Ниже приведены примеры связанных с этим событием активностей:

  • Понимание того, какую проблему надо решить: Владелец Продукта рассказывает несколько последовательных историй и связывает их с текущими бизнес-целями. Команда обсуждает “почему мы это делаем?”, “как понять, что мы решаем нужную проблему?”. Некоторые команды используют карту историй (story mapping), карту влияния (impact mapping), игры «Speedboat», «Я и моя тень» и технику «5 почему». 
  • Разбивка больших элементов для более простого обсуждения и изучения.
  • Оценка элементов.
  • Понимание потребностей клиента: команда обсуждает“Почему пользователь хочет этого?”, “Правильно ли мы решаем его проблему?”. Некоторые команды используют доску историй (storyboard)  до и после, карты Pain Gain.
  • Прояснение элементов: Некоторые команды используют технику спецификации на примерах (Specification By Example) и создают приемочные тесты для пользовательских историй, используют описание историй с помощью спецификаций языка Gherkin, таблицы потоков и/или таблицы решений.
  • Определение планов исследовательского тестирования: Выявление рисков при достижении цели, выявление фич, которые требуют ручного тестирования. Некоторые команды используют план исследовательского тестирования (Exploratory Test Charter) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
  • Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…

Читать далее «Мультикомандное уточнение Бэклога Продукта»

6 причин, почему внедрение Канбана может оказаться неудачным

Перевод оригинальной статьи «6 Reasons You May Fail with Kanban Implementation«.

Внедрение Канбана в организации может показаться лёгким процессом, но на самом деле тут есть свои подводные камни. Если вы не уделите должного внимания деталям, внедрение может пойти не так. Читать далее «6 причин, почему внедрение Канбана может оказаться неудачным»

Почему фокус на Velocity убивает Agility

В этой статье я расскажу об опасной динамике, которая возникает в случае, когда Владелец Продукта, Скрам-мастер и/или менеджмент организации фокусируют Команду Разработки на Velocity.

О чем говорит Velocity.

Концепция Velocity означает:

Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.

Обратите особое внимание на выделенные слова. Velocity применима тогда, когда Команда Разработки может доставлять каждый Спринт готовый к релизу инкремент. В этом случае Done = DoD = releasable.

Но даже в этом случае Velocity не показывает:

  • Была ли решена проблема клиента.
  • Занимаемся ли мы самыми приоритетными проблемами клиента.
  • Объем поставленной ценности.
  • Степень удовлетворенности клиента.

Velocity лишь показывает, что команда была чем-то занята.

Является ли это достоверной оценкой успешности ваших продуктов и сервисов? Оценивают ли клиенты ваши продукта по тому, насколько были заняты сотрудники компании?

Если хотите, Velocity отражает объем “выработки” Команды Разработки. К сожалению, этого недостаточно для создания успешных продуктов и сервисов. Читать далее «Почему фокус на Velocity убивает Agility»

PBR в LeSS (кейс МТС Касса часть 9-я)

Уточнение Бэклога Продукта (PBR) в LeSS

В масштабируемом Скраме PBR становятся обязательным событием (а не активностью). Это происходит, потому что в крупных продуктовых группах PBI получаются очень большими и возникает необходимость в масштабном обучении и координации между командами. Появляется необходимость планировать минимальное количество встреч с клиентами и пользователями. В LeSS есть несколько вариантов проведения PBR (руководство «Типы Уточнений Бэклога Продукта»):

  • Общее Уточнение Бэклога Продукта с представителями команд, которое предполагает высокоуровневый анализ и видение, оценку и разбиение элементов (руководство «Общее Уточнение Бэклога Продукта»).
  • Мультикомандное Уточнение Бэклога Продукта. Несколько команд в одной комнате уточняют несколько PBI одновременно (предпочтительно) (руководство «Мультикомандное Уточнение Бэклога Продукта»).
  • Однокомандное Уточнение Бэклога Продукта. Проводится как в Скраме для одной команды.

Нет каких-либо особых правил по комбинированию PBR, однако LeSS рекомендует проводить мультикомандные PBR. Давайте остановимся на их подробнее. Читать далее «PBR в LeSS (кейс МТС Касса часть 9-я)»