Agile — Низкая Зрелость Команды Разработчиков И Самоорганизация В Scrum.

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

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

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

Когда я присоединился, у меня не было никакой документации (архитектура, процессы и т. д.), 0 CI/CD, и даже связаться с командой разработчиков было сложно (не было возможности обмениваться мгновенными сообщениями, они не часто проверяли свою электронную почту). Люди регулярно не появлялись на ежедневных стендапах без каких-либо объяснений. Добавьте к этому тот факт, что иногда во время обзора спринта всплывало (!), что у кого-то были сомнения относительно США, над которыми они должны были работать, и только во время обзора они прояснялись и могли начать над ними работать. Добавьте к этому, что обновления статуса были крайне ненадежны (говорилось, что какая-то задача была выполнена, и когда я проверил ее, выяснилось, что это не так, затем я спросил, могут ли они исправить, они сказали, что да, я проверил и заметил, что они не работают) 'т и т. д. Это может занять недели).

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

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

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

#скрам #гибкий

Что мне следует делать, чтобы прогрессировать в организации, в которой я работаю?

Начните с понимания того, чего хочет и ценит организация, а затем выясните, каковы ваши собственные цели.

Посмотрите на это с точки зрения команды: до вашего появления все ехали с комфортом. На самом деле ничего не было сделано (или сделано хорошо), но, очевидно, все было в порядке, и никто не жаловался и не заботился об этом.

Итак, приходит пользователь 42891 и все смешивает. Объективно, команда теперь работает намного лучше, коммуникация стала более четкой, пропускная способность выросла, результаты должны быть лучше и быстрее. Однако субъективно их жизнь стала хуже: им приходится вкладывать больше времени и усилий, появляется больше контроля, и им приходится делать больше того, что им не нравится. Конечно, они будут недовольны этим.

Несколько вещей, которые нужно сделать

1. Узнайте, почему состояние до user42891 было нормальным. Поговорите со скрам-мастером, владельцем продукта или со своей собственной пищевой цепочкой. Каковы были ожидания/цели этой команды и как они противостояли им?
2. Поймите, как работает и думает ваша новая организация. Если прошлое поведение было хорошим, какая польза от его изменения и как оно вписывается в общий ландшафт.
3. Убедитесь, что ваши цели совпадают с целями организации. Критически исследуйте свои собственные ценности и ценности окружающих вас лидеров. Возможно, они не совпадают: если вы хотите надрать задницу, а люди вокруг вас согласны просто путешествовать, то здесь у вас разрыв связи.
4. Если вы хотите осуществить изменения, вам необходимо стимулировать команду. Если производительность растет (а производительность действительно имеет значение), тогда будет легко оправдать некоторые вознаграждения: дополнительный отпуск, бонус, приятную прогулку и т. д.
5. Если это не удалось, можно попытаться мотивировать себя словами: «Это правильный поступок, и приятно чувствовать себя продуктивным, таким образом вы можете стать лучшим разработчиком», но это тяжелая битва для аутсорсинговой команды, поскольку к ним в первую очередь относятся (и чувствуют себя) как к наемникам. .

самоорганизация – это навык. Команды должны этому научиться. Есть множество статей о том, как привлечь туда свою команду, поэтому я не буду здесь все это повторять. Это может оказаться длинным, вам следует поискать в Google и прочитать.

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

Конечно, они жалуются на то, что вы соблюдаете правила, потому что это означает работу.

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