В первой части интервью с Валерием мы говорили о том, как вовлеченность персонала влияет на конечный результат разработки продукта и существует ли единый способ правильного внедрения фреймворка в работу компании. В этой статье мы обсудили Scrum-события, метрики эффективности для scrum-команды и пользу внедрения методологии для заказчика.
Как scrum-события (daily meeting, sprint review, retrospective, backlog refinement, sprint planning) влияют на эффективность работы команды?
Валерий: scrum-события серьезно влияют на эффективность тогда, когда используются они все. Если мы уберем какие-то события, а другие оставим, не факт, что это принесет нам эффективность.
Чем daily meeting отличается от обычного совещания? Ничем! Это встреча, где люди обсуждают задачи на текущий день и проблемы, а дальше идут их решать. А что будет, если они не пойдут решать эти проблемы? Они придут на следующий daily, где снова будут жаловаться, и ничего не изменится. Тогда почему в scrum меняется? Потому что кроме daily есть еще sprint review, где команда демонстрирует конечный результат.
На sprint review сидят все: команда, product owner, scrum master и стейкхолдеры. Это всех дисциплинирует с точки зрения общения: ты не будешь вести себя как человек, которому все безразлично. Тебе будет неловко не только перед собой, но и перед командой, инвесторами. Ты понимаешь, что не можешь прийти на sprint review, не сделав ничего, так же как и не хочешь прийти с плохим результатом. Поэтому после дейли митинга, зная, что у тебя впереди ревью, ты начинаешь решать свои задачи. Достаточно один-два раза попасть в неловкое положение, чтобы больше этого не хотеть.
За sprint review сразу же идет ретроспектива в тот же день. В чем смысл такой постановки? Предположим. sprint review прошло неудачно, и мы начинаем думать, что же делать, чтобы больше такого не повторить. Имея результат, показанный на спринт ревью (пусть даже и хороший), мы должны ответить на вопрос “Как достичь лучшего результата в следующий раз?”.
Такая последовательность событий приводит к циклу: события распределены таким образом, что у человека появляется мотивация с каждым новым спринтом делать чуть-чуть лучше, потому что иначе пропадает смысл твоей работы.
При планировании спринта мы берем задачи, которые надо сделать, и далее мы решаем, как это сделать наилучшим образом. Мы не хотим столкнуться с авралом в середине спринта, не хотим решать на daily слишком сложные вопросы, не хотим придти на sprint review с пустыми руками, начнем неэффективно потеряем время потом. Планирование позволяет нам использовать время команды эффективно: мы изначально настроены на длительную встречу, планируем работу и решаем вопросы (по возможности), уточняем детали с product owner и дальше идем к цели.
Что касается оценки бэклога, это как прогрев двигателя перед стартом, мы таким образом делаем разработку плавной:
- Если ты работаешь над оценкой бэклога, ты лучше понимаешь продукт, над которым ты работаешь, смотришь на далекую цель и понимаешь, что тебя ожидает в ближайшем будущем;
- Это уменьшает время на планирование задач, потому что ты знаешь, над чем тебе нужно работать;
- Это позволяет product owner и стейкхолдерам понимать, каким образом распределить работу, чтобы эффективно тратить денежные ресурсы и ресурсы команды.
Таким образом мы выстраиваем цепочку событий, которая позволяет осмысленно и качественно выполнять поставленную перед нами задачу на почти интуитивном уровне.
Что мешает проведению эффективного дейлика: как не проводить собрания для «галочки»?
Валерий: скрам это набор ценностей и принципов, а не инструкция как нам жить. Если люди разделяют эти ценности, они не превратят работу в видимость ее. Если ваши встречи превратились в собрания “для галочки”, скорее всего вам надо работать над ценностями для вашей команды.
Что касается ретроспектив: только ли это разбор работы команды или же еще и способ сплотить и улучшить отношения в коллективе?
Ретроспектива это не только разбор проблем. Что мы обсуждаем?
- Что было хорошо;
- Что можно улучшить;
- От чего можно отказаться.
Это время сплачивает команду: во-первых, мы хвалим друг друга, обсуждаем, что было хорошо. Говорим об отказе от лишней работы. Все эти кейсы – некий командный тренинг. Ретроспективу можно проводить, добавляя элемент игры, чтобы было интереснее. Можно дать роль скрам-мастера разработчику, чтобы участники команды почувствовали себя в другой роли. Если по итогам ретро мы приходим к выводу, что нам нечего улучшать, мы можем себя перехвалить. Если же мы затрагиваем только отрицательные моменты, мы можем себя демотивировать.
Поговорим про метрики эффективности для скрам-команды. Каковы ключевые показатели эффективности, на чем они основаны и как их оценить?
Валерий: метрик эффективности очень много. Существует Evidence-Based Management Guide, который дает ряд метрик для оценки различных параметров: инновационность компании, анализ эффективности скрама, анализ того, как в компании создается ценность продукта. Если говорить в целом, то метрики должны измерять достижение целей, тогда у вас появляется четкое представление, правильно ли мы двигаемся, как работает Scrum, как развивается компания, насколько качественные продукты мы создаем.
Подробно останавливаться на видах метрик значит писать отдельную статью, поэтому здесь я просто даю отсылку к гайду, а каждый уже сам определяет для себя метрики, которые помогут ему измерить достижение целей. Отдельно стоит также уделять внимание работе с субъективными оценками от людей путем опросов: они дают ценную информацию, которую не расскажет статистика, и укажут на точечные проблемы, боли, страхи и препятствия.
Мы много говорили о преимуществах Scrum для команды разработки и продукта в целом. Но так или иначе, в конечном итоге именно заказчик платит за разработку продукта, который должен принести ему результат в виде дохода. Поэтому хочется узнать, что внедрение скрам дает именно заказчику и как это влияет на его цели и задачи?
Валерий: когда мы говорим об эффективности команды, вовлеченности персонала и прочем, то возникает вопрос: если есть люди, которые являются инвесторами и стейкхолдерами продукта, которые выделяют на это бюджет, имеет ли для нас вообще смысл вовлеченность сотрудников? Что нам дает внедрение скрама, какую выгоду это дает продукту? Если мы говорим о продукте, один из ключевых показателей это ROI. Чем нам помогает в данном случае Scrum?
- Честность и открытость. Scrum утверждает: если вы начинаете разработку более-менее крупного продукта, рассматривайте это как бизнес-проект и развивайте его именно так (те кто запускают не первый проект, прекрасно это понимают). Отбросьте иллюзии, ведь на старте вы никогда не знаете наверняка, что требует рынок, что будет успешным решением, а что нет. Точные планы не дают гарантий и полного контроля ситуации, они лишь создают эту иллюзию. Scrum честно говорит: вы знаете цель, примерный путь, а пройти его можно только начав;
- Частные поставки готовых инкрементов продукта, которые могут помочь нам реально увидеть результат: то ли это, что нам надо, востребовано это или нет, подходит ли это для потребителя и готов ли он за это платить. Далее заказчик уже принимает решение, основываясь на фактах. Кроме того, важно понимать, что частые обновления всегда дают актуальные факты, так как факты имеют свойство устаревать, а качество решений тем выше, чем более актуальными фактами мы владеем в моменте;
- Снижение рисков: Заказчик, понимая, насколько его гипотезы верны, куда движется продукт, в любой момент может признать, что он совершил ошибку и изменить стратегию. Если мы говорим про линейную разработку, заказчик может понять, ошибка это или нет, после реализации всего проекта, таким образом риски “ожиданий” в случае использования скрама всегда ниже. Кроме того итеративный процесс позволяет лучше управлять и рыночными и финансовыми рисками, вы можете вносить изменения в любой момент и изменить бюджет оперативно.
Совокупность этих факторов приводит к тому, что создание продукта становится рациональным и эффективным занятием.
Большое спасибо, Валерий! Подводя итог, опишите главное преимущество, на ваш взгляд, которое привносит внедрение scrum в работу компании.
Валерий: scrum, который внедрен корректно и эффективно, подразумевает прозрачность отношений, смелость, уважение, формирует профессиональные команды, сфокусированные на своей работе и ориентированные на результат. Как следствие, формируется доверие между всеми, кто работает над проектом, развиваются долгие и взаимовыгодные партнерские отношения, благодаря чему создается качественный продукт.
