Как выбрать пилотную команду
Даже компаниям, которые запускают масштабную трансформацию, мы рекомендуем начинать с пилотного проекта или 1-3 пилотных команд. На что стоит обратить внимание, чтобы сделать опыт пилота максимально ценным для компании?
1. В команде должны быть все компетенции, необходимые для создания конкретного продукта.
Смысл в том, чтобы команда как можно меньше зависела от внешних факторов (поставщики, согласование и тд) — работа будет продвигаться быстрее.
Важно также, чтобы Владелец продукта имел право принимать решения: так мы тоже уйдем от потери времени на согласования.
2. Команда должна быть небольшой. Scrum-гайд рекомендует придерживаться численности 10 или меньше человек. Один из них обязательно должен отвечать за продукт, то есть быть Владельцем продукта.
Но и в рамках заданной численности важно, чтобы в команде не было людей, которые не делают продукт «руками» (эксперты, менеджеры) — лучше оставить их вне команды и обращаться по мере необходимости.
3. Команда должна быть плоской. Мы не добьемся преимуществ командной работы, если фактически сохранится распределение ролей «начальник - подчиненные».
Желательно, чтобы в команде были один язык и один или близкие часовые пояса — чтобы было проще общаться.
Пилотный проект должен быть достаточно важным, чтобы остальные команды прислушались к этому опыту, а не отмахнулись, потому что «у них-то ерунда, а у нас серьезная работа».
Даже компаниям, которые запускают масштабную трансформацию, мы рекомендуем начинать с пилотного проекта или 1-3 пилотных команд. На что стоит обратить внимание, чтобы сделать опыт пилота максимально ценным для компании?
1. В команде должны быть все компетенции, необходимые для создания конкретного продукта.
Смысл в том, чтобы команда как можно меньше зависела от внешних факторов (поставщики, согласование и тд) — работа будет продвигаться быстрее.
Важно также, чтобы Владелец продукта имел право принимать решения: так мы тоже уйдем от потери времени на согласования.
2. Команда должна быть небольшой. Scrum-гайд рекомендует придерживаться численности 10 или меньше человек. Один из них обязательно должен отвечать за продукт, то есть быть Владельцем продукта.
Но и в рамках заданной численности важно, чтобы в команде не было людей, которые не делают продукт «руками» (эксперты, менеджеры) — лучше оставить их вне команды и обращаться по мере необходимости.
3. Команда должна быть плоской. Мы не добьемся преимуществ командной работы, если фактически сохранится распределение ролей «начальник - подчиненные».
Желательно, чтобы в команде были один язык и один или близкие часовые пояса — чтобы было проще общаться.
Пилотный проект должен быть достаточно важным, чтобы остальные команды прислушались к этому опыту, а не отмахнулись, потому что «у них-то ерунда, а у нас серьезная работа».
Кто делает декомпозицию задач на User Story?
Когда команда начинает внедрять Scrum, одним из ключевых вопросов становится перераспределение зон ответственности. Четкое понимание, кто за что отвечает, необходимо, чтобы выстроить продуктивную командную работу.
Один из таких вопросов нам часто задают на тренингах: кто проводит декомпозицию задач на пользовательские истории?
Обычно за декомпозицию отвечает Владелец продукта, но не всегда у него хватает компетенций. В этом случае мы организуем небольшую встречу, на которой присуствуют аналитик (бизнес или системный), Владелец продукта и Скрам-мастер. Втроем они смогут эффективно провести декомпозицию.
Значит ли такая ситуация, что Владелец продукта «плохой»? Нет. Он может не знать технических аспектов или платформу, на которой ведется разработка. Или он недавно начал работать в этой команде и в этом направлении. Именно здесь его и поддержат коллеги:
- Скрам-мастер может предоставить примеры, опыт и понимание, как эта практика работает.
- А бизнес-контекст добавят аналитик и Владелец продукта.
С точки зрения самой декомпозии желательно формировать User Story так, чтобы каждую из них можно было реализовать в рамках спринта.
Если история настолько большая, что она не помещается в спринт, стоит рассмотреть ее отдельно: нужно понять, что внутри происходит, и декомпозировать, насколько это возможно.
Когда команда начинает внедрять Scrum, одним из ключевых вопросов становится перераспределение зон ответственности. Четкое понимание, кто за что отвечает, необходимо, чтобы выстроить продуктивную командную работу.
Один из таких вопросов нам часто задают на тренингах: кто проводит декомпозицию задач на пользовательские истории?
Обычно за декомпозицию отвечает Владелец продукта, но не всегда у него хватает компетенций. В этом случае мы организуем небольшую встречу, на которой присуствуют аналитик (бизнес или системный), Владелец продукта и Скрам-мастер. Втроем они смогут эффективно провести декомпозицию.
Значит ли такая ситуация, что Владелец продукта «плохой»? Нет. Он может не знать технических аспектов или платформу, на которой ведется разработка. Или он недавно начал работать в этой команде и в этом направлении. Именно здесь его и поддержат коллеги:
- Скрам-мастер может предоставить примеры, опыт и понимание, как эта практика работает.
- А бизнес-контекст добавят аналитик и Владелец продукта.
С точки зрения самой декомпозии желательно формировать User Story так, чтобы каждую из них можно было реализовать в рамках спринта.
Если история настолько большая, что она не помещается в спринт, стоит рассмотреть ее отдельно: нужно понять, что внутри происходит, и декомпозировать, насколько это возможно.
Как уживаются роли Проектного/ Продуктового менеджера и Владельца продукта
Частый вопрос на наших тренингах;) Если говорить про классические подходы, например Scrum, то в них есть только Владелец продукта — проджект-менеджеров нет.
А дальше зависит от подхода:
- В NEXUS и LeSS тоже самое, что и в Scrum — только Владелец продукта.
- В классическом SAFe есть иерархия: на программном уровне находится продукт-менеджер, который работает с Владельцами продукта (до 4 человек, под каждым РО одна — максимум две команды) и является своего рода их руководителем.
- Проджект-менеджеры есть в Disciplined Agile.
Владелец продукта и проджект-менеджер могут существовать параллельно, если компания используют кастомные решения (например, модель Spotify). Тогда часть команд будет работать по agile-подходам — и в них будет Владелец продукта, а часть будет фокусироваться на проектном подходе, и у них останутся проджекты.
Что делать проектному менеджеру, если его компания начинает внедрять agile? Во-первых, не волноваться;) Потребность в вашем профессионализме не пропадает, а только меняет форму.
Часто проджекты во время трансформации превращаются во Владельца продукта или, если компания большая, а человек очень опытный, становят RTE — Release Train Enginee. Также можно занять позицию Скрам-мастера.
Независимо от того, куда классический проджект-менеджер решит эволюционировать, это потребует от него усилий поменять восприятие:
- Переквалифицируется во Владельца продукта — и главным фокусом его внимания станет развитие продукта, а не поставка.
- Того, кто решит стать Скрам-мастером, должен интересовать не столько контроль, сколько максимальная помощь команде и фокус на том, чтобы развивать ее (можно сравнить с играющим тренером).
- На RTE переход самый простой с точки зрения восприятия: здесь вы по сути помогаете командам взаимодействовать и делаете все возможное, чтобы комадны не сошли с тех «рельс», которые построили на PI-планировании. Собственно, RTE и проводит PI-планирование.
Частый вопрос на наших тренингах;) Если говорить про классические подходы, например Scrum, то в них есть только Владелец продукта — проджект-менеджеров нет.
А дальше зависит от подхода:
- В NEXUS и LeSS тоже самое, что и в Scrum — только Владелец продукта.
- В классическом SAFe есть иерархия: на программном уровне находится продукт-менеджер, который работает с Владельцами продукта (до 4 человек, под каждым РО одна — максимум две команды) и является своего рода их руководителем.
- Проджект-менеджеры есть в Disciplined Agile.
Владелец продукта и проджект-менеджер могут существовать параллельно, если компания используют кастомные решения (например, модель Spotify). Тогда часть команд будет работать по agile-подходам — и в них будет Владелец продукта, а часть будет фокусироваться на проектном подходе, и у них останутся проджекты.
Что делать проектному менеджеру, если его компания начинает внедрять agile? Во-первых, не волноваться;) Потребность в вашем профессионализме не пропадает, а только меняет форму.
Часто проджекты во время трансформации превращаются во Владельца продукта или, если компания большая, а человек очень опытный, становят RTE — Release Train Enginee. Также можно занять позицию Скрам-мастера.
Независимо от того, куда классический проджект-менеджер решит эволюционировать, это потребует от него усилий поменять восприятие:
- Переквалифицируется во Владельца продукта — и главным фокусом его внимания станет развитие продукта, а не поставка.
- Того, кто решит стать Скрам-мастером, должен интересовать не столько контроль, сколько максимальная помощь команде и фокус на том, чтобы развивать ее (можно сравнить с играющим тренером).
- На RTE переход самый простой с точки зрения восприятия: здесь вы по сути помогаете командам взаимодействовать и делаете все возможное, чтобы комадны не сошли с тех «рельс», которые построили на PI-планировании. Собственно, RTE и проводит PI-планирование.
Scrum или Канбан — что выбрать?
Вопрос многогранный, но бывают ситуации, когда в компании назрели потребности в изменениях и нужно выбрать вектор, чтобы уже завтра начать что-то делать по-другому.
В этом случае руководствуемся простой логикой: Канбан на старте не требует организационных изменений, Scrum — требует.
Scrum хорошо себя проявляет, когда вы можете четко выделить продукт.
Соотвественно, если вы можете выделить продукты, можете под эти продукты составить полноценные команды — организация работы по Scrum принесет вам огромные бенефиты и вы действительно сможете двигаться вперед семимильными шагами.
Но есть ситуации, когда может не хватать людей или отдельных компетенций.
Возможно, вы работает не столько в продуктовом направлении, сколько в проектном (и у вас множество разных проектов). Или нет возможности сейчас проводить в компании революционные изменения: менять структуру, роли. В этих случаях подходит Канбан.
Потому что основная цель Канбан-метода — сбалансировать систему поставки результата. Не нужно выделять продукты, на первом этапе можно не вводить новые роли. Главное, создать систему, в которой вы будете с регулярной скоростью поставлять ценность. И если у вас несколько заказчиков и всего одна команда, то, скорее всего, вам нужен Канбан.
Продвинутые читатели наверняка заметили, что фреймворки можно комбинировать и получить так называемый Скрамбан. Это так, но в начале знакомства с agile-подходами это может запутать команду. И на практике обычно применяют что-то одно.
Вопрос многогранный, но бывают ситуации, когда в компании назрели потребности в изменениях и нужно выбрать вектор, чтобы уже завтра начать что-то делать по-другому.
В этом случае руководствуемся простой логикой: Канбан на старте не требует организационных изменений, Scrum — требует.
Scrum хорошо себя проявляет, когда вы можете четко выделить продукт.
Соотвественно, если вы можете выделить продукты, можете под эти продукты составить полноценные команды — организация работы по Scrum принесет вам огромные бенефиты и вы действительно сможете двигаться вперед семимильными шагами.
Но есть ситуации, когда может не хватать людей или отдельных компетенций.
Возможно, вы работает не столько в продуктовом направлении, сколько в проектном (и у вас множество разных проектов). Или нет возможности сейчас проводить в компании революционные изменения: менять структуру, роли. В этих случаях подходит Канбан.
Потому что основная цель Канбан-метода — сбалансировать систему поставки результата. Не нужно выделять продукты, на первом этапе можно не вводить новые роли. Главное, создать систему, в которой вы будете с регулярной скоростью поставлять ценность. И если у вас несколько заказчиков и всего одна команда, то, скорее всего, вам нужен Канбан.
Продвинутые читатели наверняка заметили, что фреймворки можно комбинировать и получить так называемый Скрамбан. Это так, но в начале знакомства с agile-подходами это может запутать команду. И на практике обычно применяют что-то одно.
Стоит ли оценивать задачи всей командой?
Когда команда начинает внедрять Scrum, порой возникает возражение, касающееся совместной оценки работы на будущий спринт.
Нам говорят: смотрите, в команде много разных специалистов — iOS разработчик, специалист по Android, back-end, тестировщик. Каждый занимается своей задачей в рамках своих компетенций и не сможет верно оценить трудозатраты не по своей задаче.
Это действительно так: когда каждый работает в обычном формате — в рамках своих задач, — конечно, никто не в курсе про задачи остальных и не может нормально оценить работу коллег.
Scrum хорош тем, что ребята в команде работают максимально тесно друг с другом над общей целью (спринта) и каждый день синхронизируются: у кого как дела, какие есть сложности. Помогают друг другу в тестировании и код-ревью.
Через 2-4 недели работы в таком формате каждый человек уже более-менее легко и точно сможет оценить работу коллеги – потому что очень глубоко в курсе подробностей задачи.
Что дает совместная оценка задач?
- Точность оценки: мы учитываем опыт не одного-двух специалистов, а всей команды.
- Рост экспертности команды: менее опытные сотрудники получают опыт прогнозирования сложности и сроков выполнения задач, в том числе за пределами своей основной специализации.
- Рост вовлеченности команды: мы выстраиваем культуру совместной работы над общей целью и помогаем сотрудникам брать на себя отвественность за результат всей команды.
Когда команда начинает внедрять Scrum, порой возникает возражение, касающееся совместной оценки работы на будущий спринт.
Нам говорят: смотрите, в команде много разных специалистов — iOS разработчик, специалист по Android, back-end, тестировщик. Каждый занимается своей задачей в рамках своих компетенций и не сможет верно оценить трудозатраты не по своей задаче.
Это действительно так: когда каждый работает в обычном формате — в рамках своих задач, — конечно, никто не в курсе про задачи остальных и не может нормально оценить работу коллег.
Scrum хорош тем, что ребята в команде работают максимально тесно друг с другом над общей целью (спринта) и каждый день синхронизируются: у кого как дела, какие есть сложности. Помогают друг другу в тестировании и код-ревью.
Через 2-4 недели работы в таком формате каждый человек уже более-менее легко и точно сможет оценить работу коллеги – потому что очень глубоко в курсе подробностей задачи.
Что дает совместная оценка задач?
- Точность оценки: мы учитываем опыт не одного-двух специалистов, а всей команды.
- Рост экспертности команды: менее опытные сотрудники получают опыт прогнозирования сложности и сроков выполнения задач, в том числе за пределами своей основной специализации.
- Рост вовлеченности команды: мы выстраиваем культуру совместной работы над общей целью и помогаем сотрудникам брать на себя отвественность за результат всей команды.
Как найти нужных людей в команду?
Последнее время наши клиенты часто просят помочь им подобрать персонал. Нужно наполнять команды, а еще нанимать людей на специфичные роли: Скрам-мастеров, Владельцев продуктов, Менеджеров поставок.
Ключевой вопрос не «где найти сотрудников», а «как захантить "своих" людей».
Возникающие сложности можно условно поделить на 2 типа:
❎ Нет четкого понимания, кого ищем — или это понимание неточное.
❎ Недостаток специалистов нужного уровня, находящихся в поиске новой работы.
Написали в блог, как можно обойти эти сложности: https://onagile.ru/trends/talents/headhunting
А как у вас сейчас обстоят дела с пополнением команды?
Последнее время наши клиенты часто просят помочь им подобрать персонал. Нужно наполнять команды, а еще нанимать людей на специфичные роли: Скрам-мастеров, Владельцев продуктов, Менеджеров поставок.
Ключевой вопрос не «где найти сотрудников», а «как захантить "своих" людей».
Возникающие сложности можно условно поделить на 2 типа:
❎ Нет четкого понимания, кого ищем — или это понимание неточное.
❎ Недостаток специалистов нужного уровня, находящихся в поиске новой работы.
Написали в блог, как можно обойти эти сложности: https://onagile.ru/trends/talents/headhunting
А как у вас сейчас обстоят дела с пополнением команды?
Мотивирующий кейс о том, как успешно инициировать изменения в компании «снизу»
Сразу оговорюсь, что речь все же про мидл-менеджмент. Тем не менее, это отличный пример, как инициатива одного человека способна изменить 6 производств внутри огромной международной компании (бренд не называю по условиям NDA).
К нам обратился менеджер, курирующий ряд производственных направлений. Задача состояла в том, чтобы увеличить скорость реализации инициатив на производстве.
Поскольку на скорость влияет сразу множество факторов, решением виделось внедрение проектного подхода, построенного на agile-принципах:
- Инициативы перестают быть фоновой работой сотрудников: проекты считаются ключевыми активностями для улучшения производства.
- Под каждый проект собирается небольшая, но фиксированная команда. Из ежедневной загрузки каждого участника выделяется определенный % времени для работы над проектом в команде.
- Каждая проектная команда сфокусирована на конкретный результат в конце месяца, с еженедельными точками контроля по результатам очередного спринта.
К масштабной трансформации компания была не готова, но руководство дало добро на обучение 1 группы. Поэтому мы собрали самых заинтересованных руководителей — на тренинг пришли люди с десятка производств. Примерно вдвое больше, чем помещается в переговорку;)
Мы провели 8-часовой тренинг: разобрали механику Scrum, прошлись по всем этапам процесса и наметили, в каких частях их проектов будет полезно применить инструменты Agile.
После тренинга менеджеры вернулись к себе на производства, начали пробовать что-то делать по-новому… и через пару месяцев уже целых 6 команд на заводах в разных городах России применяли Scrum!
Ребята из той нашей первой группы поддерживали связь друг с другом, обмениваясь best practices, опытом и результатами. Мы оказывали лишь небольшую консультационную поддержку.
Вслед на первыми scrum-командами, опираясь на их опыт и результаты, гибкие подходы начали внедрять в другие команды внутри производства.
Конечно, гораздо проще, когда измения драйвят или хотя бы активно поддерживают несколько менеджеров уровня СЕО-1. Но и инициатива из «середины» с опорой практически на одни на морально-волевые качества способна привести к впечатляющим результатам.
Со своей стороны мы стараемся найти оптимальный вариант поддержки в условиях клиента. Здорово, когда есть понимание и ресурсы на масштабную трансформацию, но важно помнить, что даже локальные улучшения дают ощутимый результат.
Сразу оговорюсь, что речь все же про мидл-менеджмент. Тем не менее, это отличный пример, как инициатива одного человека способна изменить 6 производств внутри огромной международной компании (бренд не называю по условиям NDA).
К нам обратился менеджер, курирующий ряд производственных направлений. Задача состояла в том, чтобы увеличить скорость реализации инициатив на производстве.
Поскольку на скорость влияет сразу множество факторов, решением виделось внедрение проектного подхода, построенного на agile-принципах:
- Инициативы перестают быть фоновой работой сотрудников: проекты считаются ключевыми активностями для улучшения производства.
- Под каждый проект собирается небольшая, но фиксированная команда. Из ежедневной загрузки каждого участника выделяется определенный % времени для работы над проектом в команде.
- Каждая проектная команда сфокусирована на конкретный результат в конце месяца, с еженедельными точками контроля по результатам очередного спринта.
К масштабной трансформации компания была не готова, но руководство дало добро на обучение 1 группы. Поэтому мы собрали самых заинтересованных руководителей — на тренинг пришли люди с десятка производств. Примерно вдвое больше, чем помещается в переговорку;)
Мы провели 8-часовой тренинг: разобрали механику Scrum, прошлись по всем этапам процесса и наметили, в каких частях их проектов будет полезно применить инструменты Agile.
После тренинга менеджеры вернулись к себе на производства, начали пробовать что-то делать по-новому… и через пару месяцев уже целых 6 команд на заводах в разных городах России применяли Scrum!
Ребята из той нашей первой группы поддерживали связь друг с другом, обмениваясь best practices, опытом и результатами. Мы оказывали лишь небольшую консультационную поддержку.
Вслед на первыми scrum-командами, опираясь на их опыт и результаты, гибкие подходы начали внедрять в другие команды внутри производства.
Конечно, гораздо проще, когда измения драйвят или хотя бы активно поддерживают несколько менеджеров уровня СЕО-1. Но и инициатива из «середины» с опорой практически на одни на морально-волевые качества способна привести к впечатляющим результатам.
Со своей стороны мы стараемся найти оптимальный вариант поддержки в условиях клиента. Здорово, когда есть понимание и ресурсы на масштабную трансформацию, но важно помнить, что даже локальные улучшения дают ощутимый результат.
⚡️Ближайшие тренинги
1️⃣ Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
👉 28-30 июля, 6-8 сентября, 4-6 октября
2️⃣ Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация.
👉 7-9 июля, 20-22 октября
3️⃣ Продвинутый курс для Владельцев продуктов Advanced Product Ownership — проектирование и развитие продукта, управление ожиданиями заказчиков, работа в agile-команде.
👉 25-27 августа, 24-26 ноября
4️⃣ Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
👉 22-24 сентября
5️⃣ Agile in HR — развитие HR-сервисов, мотивационной стратегии и организационной структуры с использованием agile-подходов.
👉15-17 сентября
Вас ждут:
- Разбор актуальных проблем, с которыми сталкиваются команды
- Реальные практические навыки от экспертов, проводящих agile-трансформации в топовых российских и международных компаниях.
- Адаптация программы тренинга с учетом ваших ожиданий
- Международный сертификат от консорциума ICAgile.
Тренинги проходят онлайн: в zoom и miro. Три дня по 4-4,5 часа.
Количество мест ограничено: мы работаем группами до 16 человек.
👉Бронируйте участие заранее
1️⃣ Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
👉 28-30 июля, 6-8 сентября, 4-6 октября
2️⃣ Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация.
👉 7-9 июля, 20-22 октября
3️⃣ Продвинутый курс для Владельцев продуктов Advanced Product Ownership — проектирование и развитие продукта, управление ожиданиями заказчиков, работа в agile-команде.
👉 25-27 августа, 24-26 ноября
4️⃣ Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
👉 22-24 сентября
5️⃣ Agile in HR — развитие HR-сервисов, мотивационной стратегии и организационной структуры с использованием agile-подходов.
👉15-17 сентября
Вас ждут:
- Разбор актуальных проблем, с которыми сталкиваются команды
- Реальные практические навыки от экспертов, проводящих agile-трансформации в топовых российских и международных компаниях.
- Адаптация программы тренинга с учетом ваших ожиданий
- Международный сертификат от консорциума ICAgile.
Тренинги проходят онлайн: в zoom и miro. Три дня по 4-4,5 часа.
Количество мест ограничено: мы работаем группами до 16 человек.
👉Бронируйте участие заранее
Матрица выбора подхода к проектному управлению
Как понять, какая форма проектного управления поможет достичь наилучших результатов в вашем случае? И классическое проектное управление по PMBook’у, и гибридные решения могут работать лучше Agile — все зависит от условий.
Собрали самые показательные критерии в единую матрицу: анкетируйте свой проект и оцените, с каким видом проектного управления больше совпадений.
Остались вопросы? Будем рады обсудить в комментариях)
Как понять, какая форма проектного управления поможет достичь наилучших результатов в вашем случае? И классическое проектное управление по PMBook’у, и гибридные решения могут работать лучше Agile — все зависит от условий.
Собрали самые показательные критерии в единую матрицу: анкетируйте свой проект и оцените, с каким видом проектного управления больше совпадений.
Остались вопросы? Будем рады обсудить в комментариях)
Эффективна ли передача роли Scrum-мастера по очереди каждому участнику команды?
Такой вопрос нам недавно задали на тренинге, и вообще вопросы о Скрам-мастере одни из самых часто задаваемых. Действительно, найм отдельного человека на эту роль — вариант скорее для больших компаний. Обычно такой Скрам-мастер сопровождает до 3 команд.
Но и передавать роль по очереди внутри команды не лучший вариант. Это приведет к тому, что нормального Скрам-мастера у команды в итоге вообще не будет.
Как и любой профессионал, Scrum-мастер должен развиваться, фокусироваться, у него должен быть долгосрочный план. Со «сменным» Скрам-мастером так не получится.
Хороший вариант — когда кто-то из участников команды разработки дополнительно берет на себя роль Скрам-мастера. Главное, не забыть соотвественно уменьшить объем его задач;) И не совмещать роли Скрам-мастера и Владельца продукта.
Вот, например, простая механика, помогающая выбрать Скрам-мастера внутри команды
Такой вопрос нам недавно задали на тренинге, и вообще вопросы о Скрам-мастере одни из самых часто задаваемых. Действительно, найм отдельного человека на эту роль — вариант скорее для больших компаний. Обычно такой Скрам-мастер сопровождает до 3 команд.
Но и передавать роль по очереди внутри команды не лучший вариант. Это приведет к тому, что нормального Скрам-мастера у команды в итоге вообще не будет.
Как и любой профессионал, Scrum-мастер должен развиваться, фокусироваться, у него должен быть долгосрочный план. Со «сменным» Скрам-мастером так не получится.
Хороший вариант — когда кто-то из участников команды разработки дополнительно берет на себя роль Скрам-мастера. Главное, не забыть соотвественно уменьшить объем его задач;) И не совмещать роли Скрам-мастера и Владельца продукта.
Вот, например, простая механика, помогающая выбрать Скрам-мастера внутри команды
Как оценить производительность новой команды?
Для планирования первого спринта нам нужно понимать, какой объем работы команда сможет сделать за итерацию — и соответственно, сколько и каких элементов бэклога мы сможем взять в работу.
На этот случай в SAFe есть отличная практика для оценки производительности команды:
- Например, команда работает в циклах двухнедельных спринтов: берем количество участников команды и умножаем на 8 — получаем ориентировочную производительность команды.
- Если спринт трехнедельный — умножаем на 13.
- Если у кого-то из команды предполагается отпуск или отгул, вычитаем по единице за каждый такой день.
- Затем выбираем из бэклога небольшой элемент, работа над которым по нашим оценкам займет 1 рабочий день (с учетом тестирования). Будем считать этот элемент “единицей”.
- Оцениваем все остальные элементы бэклога относительно этой “единицы”.
Для планирования первого спринта нам нужно понимать, какой объем работы команда сможет сделать за итерацию — и соответственно, сколько и каких элементов бэклога мы сможем взять в работу.
На этот случай в SAFe есть отличная практика для оценки производительности команды:
- Например, команда работает в циклах двухнедельных спринтов: берем количество участников команды и умножаем на 8 — получаем ориентировочную производительность команды.
- Если спринт трехнедельный — умножаем на 13.
- Если у кого-то из команды предполагается отпуск или отгул, вычитаем по единице за каждый такой день.
- Затем выбираем из бэклога небольшой элемент, работа над которым по нашим оценкам займет 1 рабочий день (с учетом тестирования). Будем считать этот элемент “единицей”.
- Оцениваем все остальные элементы бэклога относительно этой “единицы”.
Например, у нас есть команда из 7 человек (не включая Владельца продукта), которая будет работать 2-недельными спринтами, отпусков и отгулов в первом спринте не планируется. Получаем 7 х 8 = 56. Если кто-то из членов команды совмещает свою роль с ролью Scrum-Mastera, можно еще немного уменьшить общую производительность.
Таким образом получаем предполагаемую производительность команды на первый спринт. Для начала этого достаточно, а дальше команда начнет накапливать собственную статистику.
Таким образом получаем предполагаемую производительность команды на первый спринт. Для начала этого достаточно, а дальше команда начнет накапливать собственную статистику.
А отслеживать статистику команды помогает Burndown Chart. На первых этапах он очень полезен для прогресса команды, но и развитым командам рекомендуем не забывать про него и отслеживать динамику своих показателей;)
Друзья, привет! Внезапно освободилось 1 место на завтрашнем тренинге Agile Project Management.
Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)
Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru
Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)
Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru
Как учитывать User Story, которую не успели доделать за спринт?
Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?
Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.
На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.
Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?
Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.
На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.
Когда стоит выполнить переоценку User Story?
В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».
Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.
Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.
Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.
В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».
Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.
Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.
Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.
2 хороших способа приоритизации элементов бэклога
Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
Нужен ли вам аудит команд и чем его заменить
В последнее время нам приходит много запросов на аудит команд и процессов. Поскольку к концу года вопрос особенно актуальный, давайте разбираться, как получить максимум пользы и сэкономить драгоценное время и деньги.
Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.
1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.
С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.
2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.
Слабые места в работе команд обнаружатся в процессе подготовки к внедрению изменений, и мы сможем их пофиксить во время обучения и отладки процессов.
Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.
Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.
—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39
В последнее время нам приходит много запросов на аудит команд и процессов. Поскольку к концу года вопрос особенно актуальный, давайте разбираться, как получить максимум пользы и сэкономить драгоценное время и деньги.
Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.
1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.
С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.
2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.
Слабые места в работе команд обнаружатся в процессе подготовки к внедрению изменений, и мы сможем их пофиксить во время обучения и отладки процессов.
Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.
Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.
—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39