Это статья Стефани Окерман, которую рекомендовал один из наших тренеров Богдан Онищенко на курсе PSPO.

Кстати, здесь вы найдете ближайший тренинг Professional Scrum Product Owner

А статья — о том, как избавиться от “бага” вечного переноса задач из спринта в спринт, что не предусмотрено в скраме. Вот вам ее свободный, дополненный перевод от команды BrainRain.

Как мы знаем из Скрам Гайда, целью скрама является создание полезного инкремента к концу каждого спринта. Такой инкремент называют по-разному: рабочий, годный к использованию, готовый к релизу… Готовый. Совсем готовый 😅  

Так почему же в командах распространена проблема, когда они не успевают сделать готовый инкремент к концу спринта? Ведь не имея рабочего ПО или ценности, которую можно использовать УЖЕ, мы не имеем и прозрачности касательно прогресса и качества. У нас исчезает возможность валидировать гипотезы и учиться.

Итак, вот пять самых распространенных препятствий (блоков) на пути к созданию готового инкремента.

1. Команда не владеет продуктом

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

Характерный признак этой “болячки” — накопление WIP (задачи в колонке “В процессе”). Элементы бэклога продукта в бэклоге спринта переносятся в следующий спринт. Каждый член команды концентрируется на своей задаче и не оглядывается на весь план, на всю команду и весь инкремент.  Случаются и проблемы с качеством, но в команде они не обсуждаются.

Кстати, о колонках. Научиться эффективнее всего объединять скрам с канбаном можно на тренинге PSK, который скоро

2. Нехватка сотрудничества

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

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

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

3. Нечеткая цель спринта

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

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

Ответьте себе на пару вопросов, чтобы узнать, есть ли эта проблема в вашей команде:

  • Цели спринта просто нет. Все, чего от вас ждут, это что вы закончите все элементы бэклога продукта в бэклоге спринта.
  • Расплывчатая цель спринта. Все ли члены команды могут в конце спринта со 100% уверенностью сказать, удалось ли добиться его цели?
  • Слишком большая или собирательная цель спринта.

4. Слишком много изменений во время спринта

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

Так как же сбалансировать срочные и неожиданные задачи с фактическим выполнением инкремента?

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

  • Есть ли внешние стейкхолдеры, добавляющие работы команде? Делают ли члены команды еще какую-то работу?
  • Замечаете ли вы попытки со стороны владельца продукта менять цель спринта во время спринта?
  • Обнаруживаем ли мы разные точки зрения на то, что такое элемент продуктового бэклога, во время спринта?

5. Блоки не убираются

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

Вот несколько вопросов, которые помогут вам выявить распространенные блоки:

  • Часто ли ухудшается ситуация в вашей рабочей среде?
  • Есть ли у команды необходимые знания и инструменты, чтобы внедрять автоматизацию и встраивать качество в продукт?
  • Есть ли кто-то вне команды, кто должен выполнить свои задачи или обеспечить разрешения, чтобы у вас получилось создать готовый инкремент?

Источник: Scrum.org