Четыре несбалансированных ответственности, которые могут навредить вашей команде Scrum


Найти баланс в вашей команде Scrum.

Scrum требует, чтобы самоорганизованная команда предоставляла готовые приращения в конце каждого спринта. Эта особенность иногда вызывает критику и вопросы, когда речь идет об обучении или при обучении клиентов: как можно работать в команде без лидера? Как мы собираемся делать свою работу, если никто не говорит нам, что или как это сделать?

Вам также может понравиться:
Ответственность – это не та проблема, которую вы хотите решить

Scrum Guide говорится, что:

«Команды Scrum самоорганизуются и кросс-функциональны. Самоорганизующиеся команды выбирают, как лучше всего выполнять свою работу, а не руководят другими людьми вне команды ».

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

Я считаю, что, чтобы позволить команде самоорганизоваться, вам нужно сочетание вера, доверять, а также мужество:

  • Вера в схватку: благодаря высокой частоте проверок и адаптации люди будут заниматься улучшением своей работы.
  • Доверять другим: их добросовестность! Потому что каждый человек, имеющий ясную цель, хочет сделать все возможное для ее достижения.
  • Мужество, чтобы отпуститьпусть люди потратят время на эксперименты и понимание. Будучи доступными друг другу, чтобы помогать друг другу, указывать на любое поведение, которое не способствует самоорганизации.

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

Несбалансированная ответственность № 1 – владелец продукта – король

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

Уверенная позиция Владельца продукта подталкивает DevTeam к поставке количества, качество мало обсуждается.

Высоки шансы, что без каких-либо улучшений команда Scrum создаст технический долг, а команда разработчиков будет страдать от низкого морального духа и текучести кадров.

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

Несбалансированная ответственность № 2 – Диктатура команды разработчиков

DevTeam диктатураВ высокотехнологичных средах, где у архитекторов программного обеспечения и систем есть много возможностей, а сотрудничество между бизнесом и ИТ ограничено, я видел команды разработчиков, работающие над красивыми техническими продуктами, но создают ли они ценность?

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

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

Несбалансированная ответственность № 3 – Scrum Master – руководитель проекта

Скрам Мастер / Руководитель проектаЭто особенно знакомо мне, потому что я был таким Scrum Masterом в своем первом опыте, мне жаль команду (если вы читаете)!

Как руководители проектов, люди несут ответственность за соблюдение графика, времени и бюджета. Командование и управление очень распространены, и, прежде всего, все решения принимаются или подтверждаются одним человеком, Scrum Master / Project Manager.

В этой ситуации, если Scrum Master / Project Manager отсутствует, могут быть приняты некоторые решения, в большинстве случаев предпочтительным решением является ожидание возвращения менеджера проекта!

В этом случае команда не самоорганизуется из-за неправильного понимания Мастером Скрама своей роли Лидера Слуги.

Несбалансированная ответственность № 4 – организация – хозяин, никто не решаетОрганизация Босс

Возможно, одна из худших ситуаций. Scrum Team является жертвой раздробленных обязанностей в организации и сложности иерархической цепочки командования.

Как следствие, Владелец Продукта не имеет полномочий и законности в отношении Продукта, и решения часто принимаются другими лицами.

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

В этом случае корпоративная культура и недоразумение Scrum могут стать препятствием для самоорганизующихся команд.

Как преодолеть несбалансированную ответственность?

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

Scrum Guide красиво и четко определяет три простых подотчётностидля каждой роли:

  • Владелец продукта: оптимизирует стоимость продукта.
  • Команда разработчиков: доставляет «Готово» на каждом спринте.
  • Скрам Мастер: устраняет препятствия.

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

Я рекомендую прочитать некоторые книги, которые помогли мне в путешествии:

Выводы

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

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

  • Роли четко и просто определены, Scrum Guide очень помогает в этом.
  • Роли понятны и уважаемы всеми в команде и организации.
  • Люди становятся ответственными за свои роли, а другие – за свои.
  • Люди поняли ценности Scrum и создали надежную среду, идеальную для быстрого обучения.
  • Проверка и адаптация метода работы Скрам Команды производятся с высокой частотой (Спринт Ретроспективы).

Наслаждайся путешествием!

Дальнейшее чтение

Подотчетность и гибкость команды

Балансировка автономии с подотчетностью

Scrum Master – конфликты не плохи все время!