Термин «скрам-бат» (scrumbut) впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.
Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>
Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».
Типичные примеры скрам-батов, соответственно, выглядят так:
- У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
- У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .
Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?
Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».
Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.
Если вы уже работаете по фреймворку скрам, или его модификации, возможно, вы найдете полезным этот список для само-диагностики. Попробуйте задать себе вопросы: «Хм, а почему на самом деле у нас так?» и «Что еще мы можем сделать, что бы изменить ситуацию?» на каждый пункт, который относится к вашему процессу.
Мне стало интересно проранжировать этот список и получить топ-лист препятствий, с которыми приходится сталкиваться командам гибкой разработки на русско-говорящем пространстве. Буду благодарна за помощь в этом (анкета с такими же пунктами по ссылке) и обязательно поделюсь результатами. Итак,
С КАКИМИ ЗАБЛУЖДЕНИЯМИ И ПРЕПЯТСТВИЯМИ ПРИХОДИТСЯ СТАЛКИВАТЬСЯ КОМАНДАМ В AGILE/SCRUM ПРОЕКТАХ
ПРОЦЕСС
- Команда не уполномочена или не информирована о том, что может менять свой процесс разработки
- В команде недостаточно смелости для качественного изменения процесса
- В команде недостаточно усердия для следования принятым изменениям
- Нет списка проблем и систематической работы над их устранением
- Не выделяются инвестиции (время, деньги) для работы над проблемами
- Длина спринта увеличивается в его ходе или часто меняется
- Работа разбита на фазы, каждая из которых выполняется за один спринт (“water-scrum-fall”)
- Команда регулярно оветаймит, что бы достичь цели спринта или выполнить беклог полностью
- Непостоянный ритм разработки с паузами между спринтами
- Нет договоренностей о рабочем процессе (Working agreements)
- При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи
- На поддержку функционирующего продукта не выделены отдельные люди или время команды
- Ограничения приобретенного инструмента обуславливают процесс (Jira, TFS, etc.)
ПРОДУКТ
- Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)
- Видение продукта, цели релизов и спринтов не донесены до всех членов команды
- Цели итераций не корректируются на основании обратной связи от рынка (после выхода в live)
- Беклог продукта содержит конкретные способы реализации
- Беклог продукта не отображает ценность элементов в нем
- Беклог продукта содержит большие истории (размером в полспринта), команда не умеет разбивать их на более мелкие
ТЕХНОЛОГИИ
- Критерии Готовности (Definition of Done) не определены или не донесены членам команды
- Отсутствие или слабое использование инженерных практик (CI, Code Review, Refactoring, TDD, etc.)
- Члены команды комитят код без проверки работоспособности билда
- Работы по тестированию не включены в один спринт с разработкой
- Тестирование не автоматизировано
ВЛАДЕЛЕЦ ПРОДУКТА
- Владелец Продукта недоступен по ходу спринта
- У Владельца Продукта недостаточно времени для работы со всеми командами в достаточном объеме
- У Владельца Продукта нет власти для принятия решений
- Есть несколько Владельцев Продукта для одной команды
- Приоритеты Владельца Продукта не построены на основе стратегии обучения и бизнес-ценности
- Владелец Продукта стремится реализовать все фичи, не используя принцип Парето для работы с беклогом
- Владелец Продукта — босс Скрам-Мастера
- Владельца Продукта не приглашают на ретроспективу
- У Владельца Продукта нет доступной команды для поиска лучших способов реализации историй (Product Discovery Team: PO, UX, Architect)
- Владелец Продукта не знает своих ключевых пользователей и клиентов
- Владелец продукта не дает обратную связь команде
СКРАМ-МАСТЕР
- Нет выделенного Скрам-Мастера или он меняется каждый спринт
- Скрам-Мастер находится в другой локации чем команда
- У Скрам-Мастера недостаточно знаний в области гибкой разработки (принципов, ценностей, практик)
- У Скрам-Мастера недостаточно социальных навыков (soft skills) для работы с людьми
- У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile
- Скрам-Мастер является техническим лидером и диктует свои решения команде
- Скрам-Мастер “по-совместительству” выполняет роль Владельца продукта
- Один Скрам-Мастер работает более чем на 3-4 команды
КОМАНДА
- Нет общей цели (продукта, релиза, спринта)
- Нет ощущения того, что все “плывут в одной лодке”
- Члены команды имеют глубокую специализацию и слабое представление о работе своих коллег
- Команда разработки разделена на специализированные под-команды по компонентам/слоям
- Состав команды изменяется по ходу спринта
- Члены команды параллельно работают над другими проектами
- Члены команды поощряются/наказываются индивидуально
ЕЖЕДНЕВНАЯ РАБОТА
- Дейли митинги проходят несистематично и/или с опозданиям
- Дейли-митинг проводится сидя, за рабочими местами
- Команда разработки на Дейли отчитывается Скрам-Мастеру или Владельцу Продукта
- Технические и бизнес-решение обсуждаются в ходе Дейли, затягивая этот митинг более чем на 15 минут
- В распределенной команде проходят отдельные Дейли по локациям
- Команду отвлекают в ходе проведения встречи (Планирование, Дейли, Ретро, Демо)
- Члены команды отвлекаются на гаджеты на встречах
- Команда работает над беклогом в произвольном порядке, не учитывая приоритеты Владельца Продукта
ПЛАНИРОВАНИЕ
- Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)
- Фокус командного комитмента в ходе планирования направлен на беклог спринта, а не на его цель
- Команда договаривается кто над какими задачами будет работать в ходе спринта
- Незавершенная работа прошлого спринта автоматически переходит на следующий
ДЕМОНСТРАЦИЯ
- Регулярно есть незавершенная работа в конце спринта
- Нет формальной оценки “успешных” и “не успешных” спринтов
- Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта
- В реализованных историях есть баги, при этом они считаются завершенными
- Демонстрации проходят без подготовки, нет структуры встречи
- Команда разработки презентует результаты спринта всегда только Владельцу Продукта
РЕТРОСПЕКТИВА
- Обвинения и поиск виновных имеют место в ходе встречи
- В конце Ретроспективы нет плана действий с датами и именами ответственных
- Слишком много изменений в ходе одной итерации
- Нет метрик и способа оценки изменений в процессе
- Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч
- Проблемы идентифицируются, есть план действий, но нет самих действий
МЕНЕДЖМЕНТ
- Есть менеджер проекта, отвечающий за успешность его реализации перед высшим руководством компании
- Менеджмент не понимает сути командных оценок и от команды требуют “выполнить обещание”
- Есть девелопмент-менеджеры, релиз-менеджеры, скрам-менеджеры и другие типы менеджеров, ответственные за выделенную часть работы
- Менеджеры используют командные артефакты как оценку и ожидают получить “красивые” диаграммы (burndown) и скорость (velocity)
- Менеджеры имеют давление на Скрам-Мастера и “выжимают” скорость работы команды через него
- Насильственное внедрение Scrum менеджментом, который не следует принципам и ценностям Agile
РАБОЧЕЕ ПРОСТРАНСТВО
- Нет удобных средств организации коммуникаций в распределенной команде
- Неудобное пространство для организации командных встреч
- Офис в формате open space с перегородками на столах
- Неудобное помещение для парной работы
Если вы дочитали до этого места — снимаю шляпу! Тогда, возможно, вы хотели бы добавить что-то еще к этому списку? Вы можете сделать это в анкете, правда, ее заполнение займет еще минут 5-ть :) Но благодаря вашей инвестиции времени, мы сможем получить интересную информацию к размышлению и действиям. Нет времени заполнять?) — Просто оставьте комментарий к статье.
Если вы хотите оспорить некоторые пункты списка — боюсь, мне будет не с чем поспорить: ваш контекст лучше вас никто не знает. Эти пункты появились потому, что имели место в командах, с которыми нам в SCRUMguides, или нашим коллегам приходилось работать.
К тому же, споры по 85-ти пунктам, просто не по зубам моим запасам свободного времени :) Но я с удовольствием пообщаюсь лично (skype, почта) и постараюсь ответить тем, кто заполнил форму и/или хочет пообщаться о ситуации в команде в формате коучинга.
Автор: Natatara
