7 вещей, которые я хотел бы знать, когда стал Скрам-мастером.

7 вещей, которые я хотел бы знать, когда стал Скрам-мастером.

7 вещей, которые я хотел бы знать, когда стал Скрам мастером

Автор: Utpal Vaishnav

Перевод: Гибкие технологии

Ссылка на оригинал: http://www.scrumalliance.org/articles/422-seven-things-i-wish-id-known-when-i-started-out-as-a-scrummaster

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

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

Хотел бы я знать это, когда я впервые начал играть роль скрам-мастера несколько лет назад. Ниже приведены 7 полезных советов, которые я хотел бы знать, когда начинал как скрам-мастер:

1. Работа над одним (и только одним) проектом

"За двумя зайцами погонишься – ни одного не поймаешь". - Русская пословица

Возьмем такой пример: Если ваша отдача была равна 100 %, когда вы решили работать над двумя проектами, то подразумеваем, что занятость будет равна 50% в каждом из них. Это вредит организации, на которую вы работаете, ровно как и приносит недовольство вашим клиентам, не так ли?

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

2. Фокус на повышении эффективности команды

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

В рамках проектов по методологии Скрам, акцент на индивидуальной эффективности является препятствием. Вот главная причина: Для получения индивидуальной эффективности, члены команды, скорее всего, будут уклоняться от практики Скрам принципов (http://gibtech.ru/company/agile_technology/), таких как прозрачность и сотрудничество. Например, если член команды делает упор на достижение индивидуальной эффективности, он может выбрать исключить взаимодействие с другими членами команды, тем самым упуская для себя информацию, которая может быть полезна для проекта и повышение собственной значимости.

Цитируя  Маргарет Карти: "Позитивный аспект совместной работы заключается в том, что у вас всегда есть союзники на вашей стороне". Это перекликается с одним из главных принципов Agile: постоянное взаимодействие внутри команды, поэтому вдохновляйте членов вашей команды работать сообща для достижения общего результата.

3. Не управлять, а способствовать

Это может быть трудным для понимания менеджера, но важно понимать, что Скрам основан на принципе самоорганизации, которая требует максимального упрощения в отношениях внутри команды, а не жесткого административного управления. Таким образом, любая попытка «управлять» это препятствие в работе команды Скрам проекта.

Пит Димир написал  статью о роли менеджера в Скрам. Ниже указаны основные положения этой статьи:

Что не делать:

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

Что можно делать:

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

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

4. Создание баланса "Жизнь - Работа" как можно раньше

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

Каков же результат? Выгорание, депрессии, падение эффективности. Для того, чтобы каждый член команды работал наиболее продуктивно, важно, чтобы работа членов команды была оптимальна. Не требуйте от них проводить долгие часы и в офисе ( в том числе и вместо выходных), за счет их здоровья, отношений, или досуга.

Книга «One Minute manager«, Кеннета Бланшара и Спенсера Джонсона, четко разъясняет: "Люди, которые вы дают хорошие результаты чувствуют себя на высоте». Обеспечивая команду не только работой, но и свободой, вы помогаете людям чувствовать себя на высоте.

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

5. Убедитесь, что каждый член команды понимает критерий готовности продукта

Существует проблема с определением " что сделали" и " как это должно работать". Производство программного продукта является сложной деятельностью, и, безусловно, важно, чтобы все члены команды понимали, что именно  нужно "сделать" по окончании.

Когда член команды говорит, что одна из его задач "выполнена", как он понимает это? Agile-тренер и сертифицированный скрам-мастер Дхавал Панчал  написал очень хорошую статью, чтобы помочь командам понять критерий "сделано". Определение "сделано" – не статично, это как постоянно обновляемый ckeck-list. Таким образом, каждый берет на себя обязательство выполнить свою задачу в рамках спринта или подготовки релиза программного продукта.

6. Если член команды не увлечен проектом и не привержен достижению цели проекта, значит скрам-мастер плохо выполняет свои функции

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

7. Скрам-мастер не босс

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

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

В итоге:

Теперь вы в курсе этих советов, если вы еще не в состоянии практиковать их в своих проектах Скрам или есть некоторые пробелы в понимании и исполнении, то не опускайте руки – Скрам это прежде всего практика!

Рассказать друзьям: