КошмарСкрам-мастера№2:СкоростьработыКомандынерастёт

Команда/ Сотрудники Скрам-мастер

Скрам-мастер Семён в печали: последние Спринты Команда не показывала стабильного прироста своей скорости (Velocity). А согласно KPI, Команда должна была увеличить её на 20%.
Кошмар Скрам-мастера № 2: Скорость работы Команды не растёт

Мой совет Семёну: перестать беспокоиться о скорости и сделать всё возможное, чтобы у Команды не было никакой материальной мотивации, связанной со скоростью. К сожалению, в некоторых организациях признаком успеха Команды принято считать рост числа сторипоинтов, которые Команда «выполняет» в Спринт. Это не имеет смысла и наносит вред Команде.

Давайте вспомним, что такое скорость. Согласно официальному словарю Скрама, скорость — необязательный, но часто используемый усреднённый показатель объёма Бэклога Продукта, превращаемого в Инкремент в течение Спринта. Отслеживается Командой Разработки для использования внутри Скрам-команды.

Иными словами, скорость — это такой ковш определённого размера, которым Команда зачерпывает задачи из Бэклога Продукта, чтобы в течение Спринта превратить их в нечто готовое к использованию.
Знание скорости может помочь Команде Разработки спрогнозировать работу на ближайший Спринт, а Владельцу Продукта — прикинуть, через сколько Спринтов будет сделан интересующий его объём работ. На этом польза скорости заканчивается.

Разберём, почему скорость нельзя использовать для оценки эффективности Команды.

Скорость работы Команды не равна ценности её работы

Представьте себе, что Бэклог Продукта — это мешок с мукой. В начале Спринта Команда Разработки зачерпывает ковшом муку, которую в течение Спринта превращает во вкусные кренделя. А теперь ответьте на вопрос: «Как количество зачерпнутой муки связано с успехом кренделей на рынке?» Никак. Можно сделать вкусные кренделя из небольшого количества муки, и они порадуют покупателей. А можно сделать много невкусных кренделей, которые никто не купит.

Скорость не имеет никакого отношения к ценности, создаваемой Командой. Не надо меряться, у кого ковш больше. Это глупо!

Скорость — это субъективный показатель

Любая метрика, привязанная к деньгам или подаркам, всегда будет подогнана под нужные значения. Однажды я работал в компании, которая решила платить бонусы командам за сокращение количества дефектов по Продукту. Разработчики команд быстро научились договариваться с заказчиком переименовывать дефекты в «улучшения», а также собирать дефекты в пачки!

Люди придумают, как формально увеличить показатели скорости ради денежного вознаграждения.

Реальность всегда вносит свои коррективы

Разработка продуктов происходит в среде высокой неопределённости. Прогноз того, сколько Команда сделает в течение Спринта, — это догадка. Мы не знаем, какие проблемы возникнут и сколько Команда на самом деле сможет сделать за Спринт.

На скорость Команды влияет множество факторов, которые мы не можем предвидеть.

Измерять скорость бессмысленно, если Продукт не готов

Если в конце Спринта Продукту ещё требуются любые виды тестирования или приёмки, то скорость Команды равняется нулю, потому что Продукт недоступен конечным пользователям, ценность не создана. Бесполезно оценивать, как быстро мы делали кренделя, если в итоге они не готовы к немедленной продаже.

Создавать готовый Продукт в конце каждого Спринта — гораздо более важная задача, чем погоня за скоростью. Сфокусируйтесь на ней.

Андрей Толмачев Сертифицированный тренер по Скраму от Scrum.org

Твитнуть

Плюсануть

Отправить

Класснуть

Линкануть

Вотсапнуть

Запинить

Ещё по теме

Как сдать экзамены PSM I и PSPO I

Студент Unusual Concepts делится ценными советами по сдаче экзамена PSM и PSPO 1. Цена попытки — 200$, но лучше сходить на тренинг Unusual Concepts. Рекомендую! Выйдет в четыре раза дороже, но оно того стоит. 2. Внимательно и вдумчиво изучить scrum guide на английском (!) языке. Что угодно делайте, чтобы понять и запомнить всё, что там написано. Мне лично помогло рисовать mind maps. Кому-то помогает внимательно прочесть 3 раза. 3. Пройти open assessments на сайте scrum.org (open, product owner, developer). Nexus не надо. Здесь задача в том, чтобы понять логику того, кто эти тесты делал (эта же самая логика используется и в сертификационном экзамене). Проходить советую вдумчиво, читая то, что написано. Не советую тупо запоминать вопросы и ответы на них, т.к. хотя в экзамене и есть copy-paste из open assessment, их, во-первых, всего лишь около половины, а во-вторых, это вам только помешает понять суть. Из этих же соображений советую тренироваться по одной попытке на каждый open assessment и потом перерыв. Потом опять по одной на каждый и опять перерыв. Идеально, если чередовать с изучением scrum guide. Обязательно читаем результаты теста! Там годные комментарии к ответам. Добивайтесь устойчивого 100% результата. 4. Если у вас с английским языком проблемы — то советую подтянуть. Лучший способ, на мой взгляд, делать всё, что я тут описал, но со словарём. Добиваемся, чтобы весь scrum guide и все open assessments были понятны без словаря. Во время экзамена словарь держите под рукой — попадаются непонятные слова, но целиком полагаться на него не стоит (один товарищ пытался загонять все вопросы в он-лайн переводчик, и в результате получил 53% правильных ответов). 5. Сертификационный экзамен сдаётся на сайте scrum.org, где другой интерфейс, чем у тестовых экзаменов. Это может добавить мандража, если станет неожиданностью. Но существенных отличий там нет. Разве только можно закладки ставить. 6. Перед сдачей самого экзамена убеждаемся, что у нас есть час времени, когда точно никто не будет отвлекать и интернет точно не отвалится. Я перестраховывался 3g модемом, но, слава Богу, не пришлось. 7. Во время экзамена ни в коем случае не надо париться над сложными вопросами! Если вопрос сложный, то выбирайте то, что вам кажется верным, ставьте на вопрос закладку (bookmark) и идите дальше. Большинство вопросов (около 60 из 80), при условии что всё вышеописанное вами сделано добросовестно, вы отобъёте за 30 минут. Оставшиеся 30 минут можно потратить, чтобы внимательно и вдумчиво разобрать все закладки. У меня даже получалось в интернете поискать варианты в это время. 8. Не надо ставить закладку на все вопросы, в которых у вас есть сомнения. Ставьте закладку только там, где вы вообще не уверены. Иначе получится неприятная картинка, когда сначала вы закладки ставили на средне-сложные вопросы, а потом стали ставить только на очень сложные, и в результате под конец теста у вас не 20 закладок, а 40, и времени в обрез. 9. Помните — это экзамен. Не надо быть самоуверенным, а то завалить его проще простого. Но и мандражить сильно не надо. Просто тщательно подготовьтесь, и всё будет хорошо. Оригинал поста в Фейсбуке

Три Спринта на фичу. Что делать?

Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.

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

Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:

возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
рабочий процесс перестаёт быть прозрачным.

По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:

объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
визуализировать поток работы. Прозрачность — залог успеха;
устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.

Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:

декомпозиция работы на небольшие PBI;
визуализация потока работы в Спринте и поиск основных узких мест;
устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
планомерная ликвидация технического долга.

Комментарии

Ольга, 10 мая 2018

Добрый день! У меня вопрос.
Если скрам-мастер является менеджером процесса, то может ли быть показателем его работы в том числе и рост эффективности команды? Т.е. у команды настолько выстроен процесс, что это естественно должно приводить к росту эффективности. А эффективность мы можем мерить в выполненных стори-поитах, в количестве и качестве доставленной ценности (в этом случае, правда, не очень понимаю, как это можно померить, кроме как в деньгах). Может ли это быть показателем хорошей работы скрам-мастера? Заранее благодарю за ответ))