Я скрам-мастер/коуч по agile, и команда, в которую меня назначили, слишком большая, 13 человек!
У меня есть полное право изменить это, однако я хочу сформулировать хороший план для этого.
Может ли кто-нибудь предложить, как я могу инициировать этот процесс. Так что не то, где происходит раскол, а то, как к нему подойти.
Мой примерный план состоял в том, чтобы встретиться со всеми один на один и посмотреть, есть ли что-то общее. Кажется, что я навязываю им концепцию ретро.
Есть идеи?
Кажется, что я навязываю им концепцию ретро.
Почему вы в это верите? Чем он отличается от подхода «один на один»? Какой совет дают вам ценности, содержащиеся в Манифесте гибкой разработки программного обеспечения ? Можете ли вы применить ценности и правила из The Scrum Guide к этой ситуации?
Самоорганизованные команды начинают с самоорганизации.
Обычный совет, который я даю клиентам, состоит в том, чтобы создать пользовательскую историю для того, что является «хорошей командой» с явным признанием.
Тогда вы соберете всех в комнату. Вы показываете им пользовательскую историю, говорите им, сколько команд должно существовать, а затем позволяете им самоорганизоваться в команды. Обычно вы проходите через 2-3 итерации, прежде чем у вас будет окончательный набор.
Как говорит Саймон Синек: «Нанимая за отношение, вы можете научить навыкам». Для команд, которые в первую очередь подходят. Навыки улучшатся быстрее с хорошей командой.
амельвин