Внедрение scrum в командах разработчиков

Мой опыт внедрения scrum в командах разработчика.

Процесс внедрения
1. Посадить людей вместе.
Люди не любят перемен. Даже если это перемены к лучшему. Простая задача - рассадить 5 существующих команд в одной большой комнате, чтобы каждая команда была вместе - очевидно полезное решение. Люди будут меньше мешать друг другу. Но в процессе перестановке получили часть недовольных изменениями. Через некоторое время (2 недели) люди оценили плюсы и согласились, что так лучше. Еще пара изменений составов команд и перемещений по комнате прошли уже достаточно гладко.
2. Купить доску.
В большой организации это, оказывается, проблема. Купил доску и позже выбил с организации деньги. Для команды из 2 человек хватает доски 60 на 90 см. Для команды 5 человек нужна доска 90*180 см. У одних команд были пробковые доски, у других пластиковые магнитные с возможностью на них писать. Лучше всего 2 доски - 1 для крепления задач, другая для рисования на ней.
3. Выделить роли в команде.
Определить, кто является членом команды, кто product owner, кто заказчиком. Что делать, если несколько product owner - найти главного product owner.
4. Составить плоский список задач.
Все любят создавать сложные иерархии работ. Так логичнее, есть логика и т.д. Но создать простой плоский список работ - непривычный опыт.
5. Product owner расставляет приоритеты
Вначале команда не сработана, никто не кому не доверяет. Product owner ставит разные приоритеты у задач, жестко определяя порядок. Через некоторое время (2-3 месяца) Product owner начинает доверять команды и ставить у нескольких задач одинаковый приоритет, доверяя команде в определении последовательности
6. Оценка работа командой
Product owner присутствует, но желательно поменьше вмешиваться. Можно использовать карты для оценки, можно нет, работает оба варианта, надо пробовать, что лучше для вашей команды.
7. После оценки приоритеты могут изменяться
8. Стартуем итерацию.
9. Понимаем, что нужны критерии Test, WIP, Test, Done. Пишем и печатаем на доску. Понимаем, что в задачах нужен критерий How to demo: не берем в план, если не описано.
10. По окончании итерации считаем фокус фактор как отношение суммы первоначальных оценок задач в Done к общему рабочему времени команды.
11. Проводим ретроспективу.
Первые 2 месяца все жалуются на бытовые условия. После надо начинать фиксировать проблемы в процессах и в технологиях.
12. Планируем 2 итерацию, уже есть фокус фактор, можем оценить, сколько задач выполним.
Фокус фактор стабилизируется через 3 недели совместной работы над одинаковыми задачами.
13. Дотачиваем процесс
Уточняем критерии Plan, WIP, Test, Done. Регулярно добиваемся работы по приоритетам. Добиваемся фиксации технического лога и регулярное включение его в итерацию. Увеличиваем размер команды.

Результаты
У нас были недельные итерации.
По моему опыту шаги 1-12 занимают минимум 3 - 12 недель.
Чтобы внедрение успешно прошло, внедряющий scrum должен первые 2 недели быть в команде. Затем периодически следить за изменением фокус фактора.
В результате фокус фактор стабилизировался на отметке 40-70%.
Непривычным оказалось, что неважно, в чем оценивать задачи: в днях, часах, идеальных днях. С помощью фокус фактора это все переводится в часы.
Чтобы все это работало Product Owner должен понять, что если он хочет добавить что-то, то он должен убрать что-то. Если он будет давить на команду, то команда сделает то, что он просит, но не сделает что-то другое и scrum позволяет это видеть до завершения итерации.
Важно - не делать лишнего. Если что-то в пределах не требует фиксации в электронном виде - не фиксируйте. Клейте листочки, но не фиксируйте. Но когда итерация закончена, все оставшееся надо зафиксировать.