Kanban.club: posts tagged scrum

Кейс. Scrum после 3 месяцев работы

Fri, 28 Jun 2019 19:10:23 +0300

Что было выявлено по итогу присутствия на ретроспективе, у команды, которая уже около 3 месяцев работает по Scrum. Команда из 7 человек, причем ВП и СМ находятся в одной локации, а вся остальная команда в другой.

Что имеем из фактуры, над которой можно поработать:

Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина – задачи не связаны друг с другом, а раз так, то и разные цели)
Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)
Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать
На ревью пользователи не приходят, так как им нечего показывать

Варианты, что можно улучшить Скрам-мастеру в его команде:

Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат – демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.

Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т.д.

Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD

Команда формирует много целей спринта, так как видит элементы бэклога разными, но у нас же это команда и она делает общие цели. Для этого нужно посмотреть на нашу цель, на наших пользователей и постараться найти какую-то объединяющую метрику для всех элементов бэклога, так называемую единую линейку, по которой можно мерить все элементы. Если такой общей линейки найти не удается, то тут нужно остановиться и признать, что у нас это не команда и сделать перезапуск.

Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС – для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.

Обязательно не забывать об экологичной обратной связи между всеми участниками процесса, чтобы не получить проблему на пустом месте.

После такого разбора, за такой период, СМ сказал: “Ааа.... я все сломал, ничего не работает, я почти убил команду” :)

И здесь лежит ловушка в том, что Scrum всегда не работает – и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.

Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.

Автор Роман Петров

Инструмент “Паутинка” для оценки событий Scrum

Tue, 30 Apr 2019 16:36:35 +0300

Порой Scrum-мастер задаётся вопросом: “Хорошо ли у нас проходят события Scrum?” однако, не может найти подходящий инструмент.

Инструмент “Паутинка” позволит команде на ретроспективе оценить события и совместно разработать план по улучшению.

Инструмент состоит из 3-х частей:
I часть – выравнивание критериев оценки с командой, что для команды 1, а что 5
II часть – совместная оценка событий участниками команды
III часть – сведение полученных оценок и разработка плана по улучшению

I. Выравнивание критериев оценки с командой

Подготовка: флипчарт с нарисованной шкалой оценки от 1 до 5

Команда и Scrum-мастер пишут на стикерах, что для них оценка “1”, а что оценка “5”.
Например:
“1” – нет цели/регулярное опоздание участников/плавающие события (в разное время)/отсутствие участников без уважительной причины;
“2” – тайминг не соблюдён/цель не досигнута/отсутствие участников без уважительной причины;
“3” – тайминг соблюдён/цель достигнута;
“4” – всё хорошо, фасилитирует Scrum-мастер;
“5” – команда всё делает сама, Scrum-мастер фасилитирует только ретроспективу

Команды, начинающие использовать данный инструмент, вырабатывают критерии оценок, которые будут подходить для всех событий. Освоив инструмент, команды придут к тому, что захотят расширить критерии для каждого события.

II. Совместная оценка событий участниками команды

Подготовка: флипчарт с матрицей событий

После того как команда договорилась об оценках, Scrum-мастер просит участников команды оценить каждое событие Scrum. Для этого достаточно подготовить флипчарт с названиями событий и попросить каждого участника написать на стикере свою оценку для каждого события и прикрепить к соответствующему:

DSM (или Stand-up);
Планирование;
PBR (согласно Scrum guide не является отдельным событием, однако эта активность крайне важна для команды)
Обзор спринта
Ретроспектива
Спринт (как в целом команда оценивает достижение цели спринта, дополнительно можно включить оценку выполнения роли Владелец продукта и Scrum-мастер)

После того, как все наклеили, Scrum-мастер считает среднюю по каждой ячейке.
Оценки Scrum-мастера не учитываются при подсчёте средней они потребуются немного позже.

III часть – сведение полученных оценок и разработка плана по улучшению

Подготовка: флипчарт с паутинкой

На соответствующие оси “Паутинки” наносим разными цветами оценку команды и Scrum-мастера (см. картинку)

Расхождение линий оценки Scrum-мастера и команды – это фокус внимания для Scrum-мастера по тому, как он видит работу внутри команды.

Scrum-мастер фокусирует внимание команды на события, которые получили наименьшую оценку от команды и просит их написать на стикерах ответ на вопрос: “Что нам нужно сделать, чтобы данное событие улучшилось?”

Далее команда голосует точками за улучшение, выбирает ТОП3 для реализации и создаёт “план действий”

Порой Kanban лучше, чем Scrum

Mon, 22 Apr 2019 11:13:27 +0300

В своей статье Брэнан Уовчко эксперт в Kanban и Scrum выделяет 5 условий, при которых Kanban подходит команде лучше, чем Scrum.

1. Низкая терпимость к изменениям

Существует ряд компаний, которым комфортно с тем, как они делают свою работу, даже если не получают результатов. Они не думают о том, чтобы переосмыслить то, как они работают, чаще всего они думают о том, как бы заставить команды работать дольше и усерднее. Scrum для таких компаний – угроза, так как заставляет быстро трансформировать роли и встречи. Kanban, напротив, не заставляет компанию трансформироваться в моменте, а побуждает к эволюционным изменениям. В Kanban вы начинаете с того, что вы делаете сейчас, а потом развиваетесь и эволюционируете. В самом начале Kanban не требует каких-либо изменений в ролях или встречах.

2. Очевидный на всех уровнях

Основное преимущество Kanban перед Scrum, заключается в том, что он сразу же становится интуитивно понятным для всех. Доска Kanban – это инструмент мгновенного осмысления. Она требует нулевого объяснения, чтобы понять. Тем не менее, основным преимуществом Kanban является и его самый большой недостаток. Легко быть обманутым скрытой сложностью Kanban.
Kanban гораздо больше, чем просто инструмент для визуализации. Он создан для скорости, но большинство команд никогда не достигнут этого, потому что их стремление изучить Kanban останавливается на визуализации.

3. Быстро меняющиеся приоритеты

Scrum дает наилучшие результаты, когда команда берет на себя пул задач и остаётся сфокусированной на них на протяжении всей итерации (спринта). Чтобы Scrum был успешным, необходимо чтобы заинтересованные стороны были информированными и эмпатичными, стремились быть agile (гибкими).

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

4. Маленькие команды

Идеальный размер Scrum команды, это команда, которую можно накормить двумя пиццами (two pizza team). Это гарантирует, что команда достаточно маленькая, чтобы быть эффективной и достаточно большая, когда имеет смысл вкладывать временнЫе инвестиции во встречи. Если ваша команда меньше, чем two pizza team, вам больше подойдёт Kanban.

5. Сложное взаимодействие

Scrum изменил взгляд мира на работу – появились кросс-функциональные команды. Идея, что команда состоит из людей из разных отделов и дисциплин, меняет правила игры.

В случае разработки программного обеспечения это уже не просто инженеры и тестировщики. Сегодня у нас есть пользовательский опыт, визуальный дизайн, написание, редактирование и многие другие виды деятельности.

Если у вашей команды большое количество активностей, стратегия забега вперед или использование масштабированного фреймворка может привести к ненужным сложностям и задержкам.

Kanban не использует временные рамки для создания предсказуемости, он использует время выполнения заказа (lead time), поэтому он способен устойчиво поддерживать неограниченное количество действий и взаимодействий.

Scrum и Kanban не являются конкурентами или врагами. Оба являются средством, помогающим командам и их заинтересованным сторонам достичь устойчивого успеха. Не думайте, что лучше всего подойдет то, что вы лучше понимаете или чаще используете. Будьте agile и экспериментируйте с обоими!

Текст адаптирован с оригинальной статьи:

https://www.mountaingoatsoftware.com/blog/when-kanban-is-the-better-choice

Scrum is

Thu, 16 Aug 2018 18:12:07 +0300

Scrum – это организационный дизайн компании, оптимизационные цели которого низкий T2M, обучение и работа над самым важным в каждой итерации в небольших кроссфункциональных командах (бизнес и технические специалисты сидят вместе)