Наличие нескольких ролей (технический руководитель + программист + скрам-мастер) противоречит методологии Scrum/Agile?

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

Я создал программное обеспечение и нанял в основном младших программистов.

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

Теперь я предложил курс Agile всем, включая менеджеров, и начал действовать как Scrum Master, потому что я хочу, чтобы люди брали на себя больше ответственности и разделяли роли (и потому что у нас нет ресурсов, чтобы нанять Scrum Master на полный рабочий день). У меня есть сертификат Scrum Master, но это мой первый практический опыт.

Однако я чувствую, что я все... - соучредитель (поэтому, вероятно, заинтересован в методологии Agile) - технический директор - Scrum Master - технический руководитель - и да, программист

Не противоречит ли это немного методологии Scrum/Agile? Как мне быть с этим (поскольку личные проблемы от группы, вероятно, возникнут)?

Ответы (2)

Ни в подходе Agile, ни в структуре Scrum нет ничего, что говорило бы о том, что один человек не может иметь несколько ролей.

Однако выбранный вами подход сопряжен с некоторыми рисками:

  • У вас есть время, чтобы эффективно выполнять все эти роли?
  • В команде разработки Scrum нет других ролей, кроме «члена команды». Наличие в команде технического директора или технического руководителя может ограничить преимущества самоорганизации и расширения возможностей фреймворка Scrum.
  • Между заинтересованными сторонами и ролями Scrum Master может возникнуть конфликт интересов. Скрам-мастер должен сосредоточиться на фасилитации и обеспечении бесперебойной работы. Это сложно сделать, расставляя приоритеты и объясняя требования.

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

Я понимаю, что в команде разработчиков нет ролей, но моя роль "естественна"... возникает из-за моего опыта и ответственности... Я подчеркиваю, что в команде нет ролей...
Всегда есть опасность, что младший разработчик не сочтет себя вправе спорить с техническим директором. Но если это сработает для вас, и члены команды будут рады отстаивать свою позицию в спорах, то вам не о чем беспокоиться!

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

Привет, пользователь, добро пожаловать в PMSE! Кажется, что ваш ответ является частью ЭТОГО поста в БЛОГЕ - в этом случае было бы неплохо добавить отказ от ответственности к вашему ответу.