4 простых способа сделать ваши команды более автономными

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

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

Независимо от того, являетесь ли вы частью команды лидеров в организации, владельцем продукта или скрам-мастером / тренером, вот как вы можете использовать четыре Т в качестве руководства для повышения автономности ваших команд разработчиков:

их задача

  • Как владелец продукта, не пытайтесь диктовать или давить на команду в отношении того, сколько работы они могут выполнить в спринте (это в равной степени относится и к руководству). Предоставьте команде полную автономию решать, сколько элементов невыполненной работы они хотят спрогнозировать для спринта. В Scrum Guide 2017 четко указано: «Количество элементов, выбранных из бэклога продукта для спринта, зависит исключительно от команды разработчиков. Только команда разработчиков может оценить, чего она может достичь в предстоящем спринте ».
  • Позвольте команде пользоваться полной автономией над своим бэклогом спринта, пока они сосредоточены на своей цели спринта. Как владелец продукта или заинтересованное лицо вы можете вносить свои предложения и обсуждать с командой, однако бэклог спринта принадлежит команде. Scrum Guide 2017 поддерживает это, говоря: «Только команда разработчиков может изменить свой бэклог спринта во время спринта. Бэклог спринта - это хорошо видимая картина в реальном времени работы, которую команда разработчиков планирует выполнить во время спринта, и она принадлежит исключительно команде разработчиков ».
  • Во время обсуждений доработки бэклога продукта, как владелец продукта, постарайтесь представить формулировку проблемы или цели вместо того, чтобы представлять решения и просить команду просто выполнить их. После того, как вы представите формулировку своей проблемы или цели, вместе с командой наметьте элемент невыполненной работы и возможные подходы к решению. Это повысит уровень автономии, которую команда ощущает в том, что они делают.
  • Не препятствуйте экспериментам. Скорее создайте условия безопасности, способствующие экспериментальному подходу. Поощряйте культуру, в которой можно безопасно потерпеть неудачу. Это один из важнейших способов сделать команды автономными в отношении их задач.
  • Как владелец продукта, предложите команде идеи для новых элементов невыполненной работы. Конечно, владение бэклогом продукта остается за владельцем продукта. Однако важно учитывать отзывы команды при создании и приоритизации элементов невыполненной работы.

их время

  • Одна из худших вещей, которые вы можете сделать, чтобы подорвать автономию команды разработчиков (и многое другое) в Scrum, - это создать план проекта и обеспечить соблюдение ваших собственных сроков поставки для команды на основе вашего плана. Пример: «Вы должны предоставить эту функцию в следующих 3 спринтах!». Не делай этого. Предоставьте им автономию в течение их времени и работайте с ними над прогнозированием сроков, если это необходимо.
  • Что может быть хуже, чем навязывание вашей команде дедлайнов? Ответ: Отслеживание их продуктивности по количеству часов, проведенных ими в каком-нибудь так называемом Agile-инструменте (кто-то сказал Jira?). Даже без такого гибкого инструмента, если вы отслеживаете, сколько часов они проводят, сидя за своим столом перед своими мониторами, подумайте еще раз. Поверьте команде, что они взяли на себя обязательство достичь цели спринта, а затем позвольте им управлять своим временем спринта так, как они хотят.
  • Многие менеджеры, владельцы продуктов и даже некоторые мастера Scrum (вздох!) Испытывают дискомфорт, когда члены команды проводят время в обсуждениях или мозговых штурмах / учебных мероприятиях. Не будь одним из таких людей. Предоставьте им возможность тратить время на изучение новых навыков или обмен знаниями.
  • Некоторые мастера Scrum пытаются установить продолжительность спринта, которая, по их мнению, идеально подходит для команд. Несмотря на то, что предлагать предложения и рекомендации - это хорошо, пожалуйста, позвольте командам выбрать длину спринта, которая лучше всего подходит для них, в сотрудничестве с остальной частью команды Scrum и заинтересованными сторонами. В случае, если несколько команд работают над одним и тем же продуктом, продолжительность спринта может быть согласована между командами - в соответствии с соглашением внутри команд. Дайте им автономию в пределах их временных рамок!

их техника

  • Если вы являетесь архитектором предприятия или руководителем инженерного отдела или занимаетесь каким-либо таким большим титулом в своей организации, вы можете многое сделать, чтобы помочь командам. Однако не лишайте их автономии, навязывая им свои архитектурные дизайнерские решения, выбор технологических инструментов или процессов управления. Сотрудничайте с ними, но позвольте командам принимать решения в этих аспектах, чтобы ответственность оставалась за командами. В Scrum Guide 2017 говорится о командах разработчиков: «Они самоорганизуются. Никто (даже Скрам-мастер) не говорит команде разработчиков, как превратить бэклог продукта в приращения потенциально выпускаемой функциональности »
  • Активные скрам-мастера всегда стараются опробовать различные техники, чтобы помочь командам во время скрам-мероприятий. Когда вы пробуете их, пожалуйста, также ищите отзывы о том, что работает для команды. Не навязывайте технику или формат только потому, что вы чувствуете, что это лучше всего для них. Например, Scrum Guide дает пример формата ежедневного Scrum (с использованием трех вопросов). Не заставляйте команду следовать только этому формату. Пусть они следят за тем, какой формат подходит для них, если он соответствует целям Ежедневного скрама.
  • Другой способ, которым Скрам-мастера могут потенциально снизить автономию команды, - это принуждение их к использованию определенных гибких инструментов. Предоставьте команде возможность самостоятельно решать, какие инструменты они предпочитают или нужны ли они вообще.
  • Для достижения инженерного мастерства существует множество хороших инженерных практик, которые могут быть приняты командами разработчиков - например, разработка через тестирование, парное программирование и т.д. усыновить и когда. Не просите их следовать определенным практикам только потому, что они хорошо себя зарекомендовали в других местах.

их команда

  • Если вы хотите создать сильные команды, которые могут помочь организации приносить пользу клиентам, позвольте командам выбирать, с кем они хотят работать. Дайте им автономию нанимать себе новых членов команды. Предоставьте им возможность попросить конкретного члена команды покинуть команду, если этот человек не подходит.
  • Не только членам команды, дайте автономию своим командам нанимать или выбирать Scrum Masters для себя.
  • Разрешите людям переходить из одной команды в другую в сценариях, когда один человек недоволен в команде, а другая команда рада принять этого человека в свою команду.

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