Есть большая разница между тем, чтобы называть себя Agile и делать Agile. Итеративная доставка ценности опирается на ключевые принципы, так что слепого следования церемониям и лучшим практикам не достаточно.
Есть несколько неочевидных вещей, которые портят принятие Agile в организации. Мы выделим только 5, но уверены, их гораздо больше. Если у вас есть примеры — делитесь в комментариях.
События фреймворка без вовлеченности
В Scrum, как одном из способов реализации Agile, выделяются обязательные события. Каждое из них обладает собственной ценностью и имеет смысл для успешной работы:
- дейли для перепланирования и синхронизации всех членов команды,
- планирование спринта для выделения цели нового спринта и отбор приоритетных PBI, детальное планирование первых дней работы и оценка,
- ревью для сбора обратной связи от стейкхолдеров в ходе демонстрации работающего продукта,
- ретроспектива для того, чтобы обернуться назад и изучить процессы, людей, вещи и события, найти пути улучшения.
Проблема возникает, если команда не понимает ценность каждого из событий. Agile-мировоззрение не предписывает строгого соблюдения этих церемоний. Но если вы считаете, что событие важно для вашего процесса, команда тоже должна это понимать.
Постоянные изменения в составе
Команды должны работать стабильно. Это означает, что команда продолжительное время работает вместе, без изменений. Люди учатся работать вместе и растут друг с другом. Каждый раз, когда уходит или приходит новый человек, химия нарушается. Скорость команды необходимо восстанавливать на основе изменений.
Решений несколько:
- изолируйте команду, по возможности, от изменений. Примите это правило с руководителем разработки.
- новых сотрудников добавляйте только после интервью с командой, пусть те, кому вместе работать, участвуют в отборе.
Выпадающие из спринта дни
Мы подходим к планированию, учитывая ёмкость команды. Это касается личной загруженности каждого, отпусков, праздничных дней, времени, которые уйдут на встречи и прочего. За вычетом этого остаётся «истинная ёмкость» спринта. Помните, что для команды будет разочарованием не прийти к цели спринта, просто потому что на планировании не учли реальное время на разработку.
Решение: создайте календарь в начале каждого спринта, чтобы команда синхронизировалась по возможностям каждого. Сделайте его публичным, чтобы календарь служил напоминанием. При этом не пытайтесь утилизировать время каждого разработчика, просто учитывайте ёмкость для принятия обязательств.
Количество команд на одного scrum-мастера
Scrum-мастер — это лидер-слуга для команды. Его роль заключается в том, чтобы коучить, наставлять, защищать команду и устранять препятствия. Отсюда понятно, почему scrum-мастер должен быть тесно связан с командой. Когда у этого человека слишком много команд, его эффективность значительно снижается.
Есть мнение на этот счет, подтверждённое практикой: на одну незрелую команду — один scrum-мастер, или на две более устойчивые, или на три команды с высокой степенью самоорганизации.
Когда Scrum Master ведёт более трёх команд, ямы скорее всего будем наблюдать снижение способности.
Неподходящий scrum-мастер
Частый сценарий — бывшие проектные менеджеры переходят в роли scrum-мастеров. Это может работать, но люди должны обладать правильной для этой работы личностью и складом характера. Не пытайтесь избежать сокращения штата и хантинга новых людей, если старые кадры не подходят для новой роли.
Может быть так, что традиционный руководитель проекта постоянно подталкивает команду к соблюдению сроков поставки. Scrum-мастер, хотя он вкладывается в результаты работы команды, больше заинтересован в том, чтобы помочь команде и ее членам добиться успеха. Как упоминалось в предыдущем пункте, Scrum Master — это коуч и наставник. Кроме того, Scrum Master должен свободно владеть «гибкими» практиками и практическими приёмами.
Это лишь некоторые примеры тихих киллеров, которые могут серьёзно осложнить принятие Agile в организации. Попробуйте найти другие вещи, которые принято игнорировать, а затем поработайте над уменьшением этого списка.