Скептик в команде Scrum

Моя компания недавно перешла на Agile способ работы, и как часть этого мы начали использовать SCRUM. Хотя я очень доволен этим и чувствую, что этот способ превосходит традиционный, некоторые из моих товарищей по команде не разделяют это мнение. На самом деле они очень скептически относятся к «всем этим гибким вещам» и не воспринимают это всерьез. Например, один из товарищей по команде всегда опаздывает на встречи, и на самом деле его это не волнует. Руководство IMO старается не замечать этого (возможно, потому что оно новое, и людям нужно время, чтобы привыкнуть к нему).

Мой вопрос: как решить эту проблему, не поднимая конфликт внутри команды?

Когда сталкиваюсь с крайним скептицизмом, я пробую несколько вещей:

1.) Я демонстрирую такие методы, как TDD, непрерывное развертывание, парное программирование, сбор требований с вашими пользователями, короткие итерации и т. Д. Я не называю эти методы Agile или арфой по поводу Agile Manifesto (я действительно говорю о Software Craftsmanship - но это другое дело; р). Я просто показываю членам команды полезные инструменты и методы, которые облегчают их жизнь. Они стремятся запрыгнуть в Agile, когда увидят преимущества изо дня в день.

2.) Я не сразу переключаюсь на полноценную методику SCRUM (или другую). Всегда лучше представить небольшие аспекты Agile одновременно.

3.) Я согласен со скептиками (в точку). Agile - не серебряная пуля, а SCRUM, Kanban, Lean и т. Д. Также не являются серебряной пулей. Вместо этого я работаю с ними, чтобы выяснить, какие аспекты могут принести им немедленную пользу (сервер CI обычно не представляет никакой сложности), а затем я пробую остальное: «Давайте попробуем в течение одной недели выдержки, а затем рассмотрим его».

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

Итак, чтобы перейти непосредственно к вашему вопросу. Поднимите это с командой:

«Я также немного скептически отношусь к противостоянию, но я думаю, что как команда, мы должны дать ей правильную оценку в течение 1 недели (никаких оправданий!), А затем пересмотреть это, чтобы увидеть, сработало ли это для нас. Что люди делают? думать?"

Типичный случай неправильно реализованного Scrum .

Скрам был навязан команде. (Вся) команда не выбрала его.

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

Сопротивление переменам - ваш враг.

Я настоятельно рекомендую вам начать все сначала и представить Scrum команде и позволить им задавать вопросы.

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

Обратите внимание, что Scrum не рекомендуется для вашей компании. Единственные, кто может ответить на этот вопрос - это люди, которые работают на базе. Команда .

Может случиться так, что концепция ежедневных встреч не очень хорошо применяется к тому, что делает человек. Эти встречи не бесплатны.

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

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

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

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

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

Выбранные (лучшие) задания выбираются первыми в начале встречи. Когда прибываете поздно, просто дайте ему то, что осталось на день.

Неважно, является ли он Божьим даром программирования, он получает дерьмовое задание, которого никто больше не хотел. Если он пытается выполнить другое задание или работать над чем-то другим, команде в целом нужно опираться на него и заставлять его работать только над «выбранным» заданием. Вероятно, у вас должен быть мастер сборки, который может отклонить его изменения, если он не работает над выбранной работой.

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

Напомните ему, что если он появляется вовремя, он может участвовать в процессе.

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

Таким образом, очевидный ответ заключается в том, что Scrum Master созывает собрание, объясняет проблему (но не обманывайте себя, все в команде уже точно знают, в чем проблема), а затем говорит им, что у них есть 1 час, чтобы выяснить, что они собираются с этим поделать. Затем он сидит в углу и держит рот на замке.

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

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

Избегание «командного конфликта» вообще не должно быть фактором.

Уволить товарища по команде, тогда он не будет вызывать споров в команде.

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

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

Кто принял решение перейти и почему? Где эти скептики вообще принимали решение, или это решение просто упало на них?

Вы слишком жестки и / или быстры в реализации своих новых методов? Вы выпускали хорошие (не обязательно совершенные) продукты, используя ваши старые методы? Вы продемонстрировали скептикам, как это пойдет им на пользу? Вы можете продемонстрировать это? Те, кто «видел свет», продемонстрировали скептикам, как это выгодно им, команде и компании?

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

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

Конечно, что вы будете делать, если победят скептики?

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

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