Быть менеджером команды и разработчиком в команде Scrum

Я управляю командой из 6 человек, которая недавно переехала в Scrum.

У нас есть Scrum Master (один из разработчиков в команде) и владелец продукта.

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

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

Как вы думаете, это хорошая идея? Может ли это противоречить «самоорганизации» команды?

Прочитайте развивающиеся мысли Роя Ошерова о лидерстве команды в Agile мире на 5whys.com

Он много говорит о трех ключевых этапах, которые проходит команда, когда она развивается от Водопада до Скрама.

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

Фаза обучения - когда у команды есть время учиться и использовать ее - требует тренера, как лидера, с импульсами контроля, когда для прохождения трудного пути потребуется слишком много времени (например, без контроля источника)

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

Когда я столкнулся с идеями Роя на OpenVolcano '10 , я был в полном недоумении, почему моя команда перестала совершенствоваться. Затем я понял, что команда перешла от Survival к ​​Learning, и я совсем не изменил свой стиль управления. Я так и сделал, и это очень помогло.

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

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

Комментарии pdr действительны, и я согласен с ними. Но я не верю, что они универсальны для всех случаев.

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

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

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

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

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

Я уже проходил подобный опыт, руководя командой из 6 разработчиков в команде Scrum. Помимо того, что упоминали pdr и GlenH7, это помогло:

1. Лучший тестировщик в команде QA действительно хорошо держал нас в ответственности за качество нашей работы, включая работу, которую я делал. Когда я писал код с ошибками, она называла меня так, чтобы это было сложно сделать другому разработчику.
2. Я обычно делал демонстрации спринта, особенно когда у нас были плохие спринты. С тех пор, как я понизил должность генерального директора, мне было неловко, когда что-то не работало. Помимо того, что я понимал особенности, разработанные другими, это также означало, что мои материалы должны быть такими же надежными, как и у других.
3. Я позволяю другим принимать решения. Мой опыт отличается от опыта GlenH7, я всегда считал ошибкой тянуть козырь. Вместо этого я рассказал о различных последствиях решений и дал понять, над чем когда-либо работал разработчик, каковы были последствия для того, что я считаю «неправильным» способом сделать что-то. Есть много причин для этого, но самая главная из них заключается в том, что, будучи руководителем команды, у вас нет времени для принятия всех решений.
4. Использование такого продукта, как Sonar, может сделать вещи вроде качества кода более объективными.