Термин «скрам-бат» (от «scrum, but..») впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.

Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>

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

Типичные примеры скрам-батов, соответственно, выглядят так:

• У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
• У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .

Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?

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

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

Если вы уже работаете по фреймворку скрам, или его модификации, возможно, вы найдете полезным этот список для само-диагностики. Попробуйте задать себе вопросы: «Хм, а почему на самом деле у нас так?» и «Что еще мы можем сделать, что бы изменить ситуацию?» на каждый пункт, который относится к вашему процессу.

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

С КАКИМИ ЗАБЛУЖДЕНИЯМИ И ПРЕПЯТСТВИЯМИ ПРИХОДИТСЯ СТАЛКИВАТЬСЯ КОМАНДАМ В AGILE/SCRUM ПРОЕКТАХ

ПРОЦЕСС

1. Команда не уполномочена или не информирована о том, что может менять свой процесс разработки
2. В команде недостаточно смелости для качественного изменения процесса
3. В команде недостаточно усердия для следования принятым изменениям
4. Нет списка проблем и систематической работы над их устранением
5. Не выделяются инвестиции (время, деньги) для работы над проблемами
6. Длина спринта увеличивается в его ходе или часто меняется
7. Работа разбита на фазы, каждая из которых выполняется за один спринт (“water-scrum-fall”)
8. Команда регулярно оветаймит, что бы достичь цели спринта или выполнить беклог полностью
9. Непостоянный ритм разработки с паузами между спринтами
10. Нет договоренностей о рабочем процессе (Working agreements)
11. При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи
12. На поддержку функционирующего продукта не выделены отдельные люди или время команды
13. Ограничения приобретенного инструмента обуславливают процесс (Jira, TFS, etc.)

ПРОДУКТ

1. Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)
2. Видение продукта, цели релизов и спринтов не донесены до всех членов команды
3. Цели итераций не корректируются на основании обратной связи от рынка (после выхода в live)
4. Беклог продукта содержит конкретные способы реализации
5. Беклог продукта не отображает ценность элементов в нем
6. Беклог продукта содержит большие истории (размером в полспринта), команда не умеет разбивать их на более мелкие

ТЕХНОЛОГИИ

1. Критерии Готовности (Definition of Done) не определены или не донесены членам команды
2. Отсутствие или слабое использование инженерных практик (CI, Code Review, Refactoring, TDD, etc.)
3. Члены команды комитят код без проверки работоспособности билда
4. Работы по тестированию не включены в один спринт с разработкой
5. Тестирование не автоматизировано

ВЛАДЕЛЕЦ ПРОДУКТА

1. Владелец Продукта недоступен по ходу спринта
2. У Владельца Продукта недостаточно времени для работы со всеми командами в достаточном объеме
3. У Владельца Продукта нет власти для принятия решений
4. Есть несколько Владельцев Продукта для одной команды
5. Приоритеты Владельца Продукта не построены на основе стратегии обучения и бизнес-ценности
6. Владелец Продукта стремится реализовать все фичи, не используя принцип Парето для работы с беклогом
7. Владелец Продукта — босс Скрам-Мастера
8. Владельца Продукта не приглашают на ретроспективу
9. У Владельца Продукта нет доступной команды для поиска лучших способов реализации историй (Product Discovery Team: PO, UX, Architect)
10. Владелец Продукта не знает своих ключевых пользователей и клиентов
11. Владелец продукта не дает обратную связь команде

СКРАМ-МАСТЕР

1. Нет выделенного Скрам-Мастера или он меняется каждый спринт
2. Скрам-Мастер находится в другой локации чем команда
3. У Скрам-Мастера недостаточно знаний в области гибкой разработки (принципов, ценностей, практик)
4. У Скрам-Мастера недостаточно социальных навыков (soft skills) для работы с людьми
5. У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile
6. Скрам-Мастер является техническим лидером и диктует свои решения команде
7. Скрам-Мастер “по-совместительству” выполняет роль Владельца продукта
8. Один Скрам-Мастер работает более чем на 3-4 команды

КОМАНДА

1. Нет общей цели (продукта, релиза, спринта)
2. Нет ощущения того, что все “плывут в одной лодке”
3. Члены команды имеют глубокую специализацию и слабое представление о работе своих коллег
4. Команда разработки разделена на специализированные под-команды по компонентам/слоям
5. Состав команды изменяется по ходу спринта
6. Члены команды параллельно работают над другими проектами
7. Члены команды поощряются/наказываются индивидуально

ЕЖЕДНЕВНАЯ РАБОТА

1. Дейли митинги проходят несистематично и/или с опозданиям
2. Дейли-митинг проводится сидя, за рабочими местами
3. Команда разработки на Дейли отчитывается Скрам-Мастеру или Владельцу Продукта
4. Технические и бизнес-решение обсуждаются в ходе Дейли, затягивая этот митинг более чем на 15 минут
5. В распределенной команде проходят отдельные Дейли по локациям
6. Команду отвлекают в ходе проведения встречи (Планирование, Дейли, Ретро, Демо)
7. Члены команды отвлекаются на гаджеты на встречах
8. Команда работает над беклогом в произвольном порядке, не учитывая приоритеты Владельца Продукта

ПЛАНИРОВАНИЕ

1. Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)
2. Фокус командного комитмента в ходе планирования направлен на беклог спринта, а не на его цель
3. Команда договаривается кто над какими задачами будет работать в ходе спринта
4. Незавершенная работа прошлого спринта автоматически переходит на следующий

ДЕМОНСТРАЦИЯ

1. Регулярно есть незавершенная работа в конце спринта
2. Нет формальной оценки “успешных” и “не успешных” спринтов
3. Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта
4. В реализованных историях есть баги, при этом они считаются завершенными
5. Демонстрации проходят без подготовки, нет структуры встречи
6. Команда разработки презентует результаты спринта всегда только Владельцу Продукта

РЕТРОСПЕКТИВА

1. Обвинения и поиск виновных имеют место в ходе встречи
2. В конце Ретроспективы нет плана действий с датами и именами ответственных
3. Слишком много изменений в ходе одной итерации
4. Нет метрик и способа оценки изменений в процессе
5. Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч
6. Проблемы идентифицируются, есть план действий, но нет самих действий

МЕНЕДЖМЕНТ

1. Есть менеджер проекта, отвечающий за успешность его реализации перед высшим руководством компании
2. Менеджмент не понимает сути командных оценок и от команды требуют “выполнить обещание”
3. Есть девелопмент-менеджеры, релиз-менеджеры, скрам-менеджеры и другие типы менеджеров, ответственные за выделенную часть работы
4. Менеджеры используют командные артефакты как оценку и ожидают получить “красивые” диаграммы (burndown) и скорость (velocity)
5. Менеджеры имеют давление на Скрам-Мастера и “выжимают” скорость работы команды через него
6. Насильственное внедрение Scrum менеджментом, который не следует принципам и ценностям Agile

РАБОЧЕЕ ПРОСТРАНСТВО

1. Нет удобных средств организации коммуникаций в распределенной команде
2. Неудобное пространство для организации командных встреч
3. Офис в формате open space с перегородками на столах
4. Неудобное помещение для парной работы

Если вы дочитали до этого места — снимаю шляпу! Тогда, возможно, вы хотели бы добавить что-то еще к этому списку? Вы можете сделать это в анкете, правда, ее заполнение займет еще минут 5-ть :) Но благодаря вашей инвестиции времени, мы сможем получить интересную информацию к размышлению и действиям. Нет времени заполнять?) — Просто оставьте комментарий к статье.

Если вы хотите оспорить некоторые пункты списка — боюсь, мне будет не с чем поспорить: ваш контекст лучше вас никто не знает. Эти пункты появились потому, что имели место в командах, с которыми нам в SCRUMguides, или нашим коллегам приходилось работать.

К тому же, споры по 85-ти пунктам, просто не по зубам моим запасам свободного времени :) Но я с удовольствием пообщаюсь лично (skype, почта) и постараюсь ответить тем, кто заполнил форму и/или хочет пообщаться о ситуации в команде в формате коучинга.

Автор: Natatara

Источник