Как мне разобраться с контрпродуктивной скрам-командой?

Предыстория:
я работал в составе этой команды в течение последних трех лет, и за это время у нас было три разных Scrum Master, которые все работают по-разному.

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

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

Настоящее время:
два месяца назад компания назначила меня Scrum Master из моей команды из-за моей преданности работе Agile и ее принципам.

Я сильно страдаю под атмосферным давлением членов моей команды, которые не хотят делать Scrum.

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

Для них планирование - просто пустая трата времени, потому что мы просто перемещаем переполнение в новый Sprint и не завершаем работу в любом случае, так зачем беспокоиться.

Во время ретроспективы я просто чувствую, что они хотят сказать «Хватит делать Scrum». Один человек делает, но другие молчат, и мне приходится иметь дело с этим каждый раз.

Ежедневные схватки снова для них просто пустая трата времени, потому что никто из них не потрудился поговорить и спланировать день. Они просто заявляют: «Я вчера работал над задачей X и снова буду работать над ней сегодня». И большую часть времени они просто шутят, пока я не становлюсь более суровым.

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

Сегодня человек, который всегда против меня, велел мне перестать говорить: «Они сказали, что это то, что они взяли на себя в этом Спринте», потому что, по его словам, «мы никогда не заканчиваем Спринт. следующий спринт, чтобы заполнить квоту. Мы делаем KanBan на самом деле.

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

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

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

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

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

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

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

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

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

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

Ретроспективный процесс заключается в том, что если вы посещаете все команды в компании, которая хорошо работает, они все делают это несколько по-разному. У нас есть некоторые команды, которые делают Kanban, некоторые, которые делают XP, некоторые, которые делают только stand-up в понедельник, среду, пятницу.

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

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

планирование

Для них планирование - просто пустая трата времени, потому что мы просто перемещаем переполнение в новый Sprint и не завершаем работу в любом случае, так зачем беспокоиться.

Именно так. Если вы последовательно не можете выделить правильное количество времени для задач, и они постоянно недооцениваются, это имеет очень негативные последствия:

• Разработчики чувствуют, что они постоянно находятся под давлением.
• «Я не могу ничего сделать вовремя».
• Поскольку этот процесс не работает, они по праву считают это пустой тратой времени.

Решение : исправьте свои оценки, используя комбинацию:

• Очки истории (как комбинация времени и риска).
• Не допускайте задач в спринте, которые> 55 SP
• Сравнительные оценки
• Доказательное планирование

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

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

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

Если вы раньше не пользовались SP, советую начать с 1 часа по-настоящему честной работы с богом = 5SP в качестве ориентира. Имейте в виду , что в обычной среде разработки, вы получите , возможно , 6 из тех , кто в день, так 30SP / день Макс . Никогда не позволяйте заданию, которое занимает более 2 дней, чтобы попасть на доску. В идеале, по моему опыту, у вас должно быть 2 задания в день.

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

ретроспективный

Во время ретроспективы я просто чувствую, что они хотят сказать «Хватит делать Scrum». Один человек делает, но другие молчат, и мне приходится иметь дело с этим каждый раз.

Напоминает мне о Daily beatings will continue until morale improves!двух прошлых работах. Если вы не устраните препятствия, то они правы, считая, что это пустая трата времени.

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

Так:

• Рассмотрим техники Шести Мыслящих Шляпок, чтобы улучшить общение.
• Сократите время, затрачиваемое на ретроспективу, максимум 30 минут.
• Убедитесь, что жалобы, поданные во время ретроспективы, рассматриваются до следующей.

Ежедневные СКРАМЫ

Ежедневные схватки снова для них просто пустая трата времени, потому что никто из них не потрудился поговорить и спланировать день. Они просто заявляют: «Я вчера работал над задачей X и снова буду работать над ней сегодня». И большую часть времени они просто шутят, пока я не становлюсь более суровым.

Похоже, у вас есть две проблемы: совещания SCRUM слишком длинные, а планирование и создание задач - отстой.

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

Для длины SCRUM:

• Попробуйте максимум 15 минут.
• Попробуйте всех встать.
• Фиксированная формула:
  • Что ты делал вчера?
  • Что ты планируешь сегодня?
  • Что должны знать члены вашей команды (а не вы!) О задании, как оно повлияет на них.
• Не беспокойтесь о препятствиях, если вы не собираетесь их устранять.

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

• Разбейте задачи на точки.
• Убедитесь, что задачи достаточно малы, чтобы занять меньше дня. В идеале, задача ИМО должна длиться ~ 3 часа и быть эквивалентна примерно 13 SP, так что вы можете делать 2 раза в день в большинстве условий.

Работа с командой

Сегодня человек, который всегда против меня, велел мне перестать говорить: «Они сказали, что это то, что они взяли на себя в этом Спринте», потому что, по его словам, «мы никогда не заканчиваем Спринт. следующий спринт, чтобы заполнить квоту. Мы делаем KanBan на самом деле.

Он прав. Вы неправы. Вы делаете ублюдочный SCRUM и / или вариацию на Канбан. Не их вина вообще.

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

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

Они просто работают вместо того, чтобы иметь дело с препятствиями.

И тут я подумала, что работа - это то, чем была их работа. Интересно, кто должен был иметь дело с препятствиями ... о, верно. Мастер Скрама. Это твоя работа. Они говорят вам, что не так. Вы это исправите. А не наоборот.

Вероятно, поэтому у вас так много проблем в Ретроспективе.

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

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

Получить в шутку - как в работе с вашей командой, а не против. (Кого волнует fuuuuuuck о деньгах компании? Вы сейчас являетесь акционером?)

Обобщить

Ваше плохое планирование приводит к тому, что другие части SCRUM терпят неудачу, и все, кто участвует, несчастны Они видят, что ничего не меняется, ничего не решается, а их жалобы не слышны.

Улучшите свое планирование, и вы улучшите поток и мораль.

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

Самое главное: слушайте своих людей. Они уже сказали вам (и мне), в чем проблема.

Удачи!

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

Итак, почему бы вам не провести встречу со своей командой и посмотреть, как вы можете улучшить процесс разработки? Если это означает, что нет разборок или случайных встреч, то пусть будет так.

Также вы нарушаете один из принципов гибкого манифеста : «Индивидуумы и взаимодействия над процессами и инструментами».

С другой стороны, если ваша команда считает, что итеративная разработка плохая, то, возможно, вы делаете это неправильно. Не имеет значения, если вы не закончите все, что запланировали за одну итерацию - вы всегда можете переместить вещи на следующую итерацию. Именно поэтому вы помечаете вещи как «должен содержать», «приятно иметь» и т. Д. Пока вы предоставляете новую функциональность, у вас все хорошо.

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

Если вам нравится смотреть действительно хорошее видео о схватках, смотрите « Роберт С. Мартин - Земля, о которой забыли Скрам ».

В качестве приоритета я бы посмотрел на задачи, которые продолжают переноситься. Несоблюдение целей чрезвычайно деморализует. Вы делаете слишком много? Существуют ли жировые отложения, которые следует разбить? Есть ли узкие места вне вашего контроля? У вас есть четкое определение «сделано»? Требования ясны? Являются ли часы на одного разработчика разумными (т. Е. Учитываются ли администратор, ожидания, планирование, ретроспективы, поломки клавиатуры, внепроектная работа).

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

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

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

По моему мнению, единственная важная вещь, которую вы можете сделать, - заставить вашу команду эффективно закрыть свой спринт (как минимум, закрыть 80% историй). Если ваша команда постоянно отсутствует, то это явный признак того, что вам нужно скорректировать свои оценки.

Команда должна быть восприимчивой к этому, хотя может быть очень трудно заставить разработчиков быть более реалистичными в оценках - я работал в команде, которая не закрывала спринт в течение года (последовательно закрывая менее 50% спринта) , всегда недооцениваемый, и в каждом планировании / ретроспективе я был одиноким голосом, который говорил им, что ваши оценки - отстой, вы слишком глупы, не уверены в том, что мешаете вам сделать оценку, и вместо этого скорректируйте оценку, чтобы отразить реальность ( возможно, более дипломатично, чем это, но это было основным настроением) - Когда вы находитесь в таком положении, я полностью согласен с придурком в вашей команде, который говорит, что процесс - пустая трата времени, потому что вы на самом деле делаете KonBon, независимо от как ты это называешь В определенный момент его мнение становится подтвержденным обстоятельствами. Это'

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

Заставить людей принять участие в существенно отличающемся спринте (с точки зрения оценок, планирования и т. Д.) Сложно, в этой команде я, в конце концов, достиг этого благодаря двум факторам. Кто-то просто собирал данные из JIRA и говорил: «Для этого нет оправдания, цифры далеко, они всегда в одном направлении, нам нужно это исправить, я не хочу оправданий в ретро, ​​я хочу числа, которые нужно сложить »- и другим было давление со стороны высшего руководства, которое я в конечном итоге объяснил им как ...« Смысл этого процесса в том, чтобы сделать наш график развития предсказуемым. Если мы выполняем постоянный объем работы каждый Спринт это хорошо, независимо от этого, наша доска должна точно отражать то, что мы делаем. Руководство в большей степени осознает наш успех по отношению к обязательству, чем к нашему фактическому результату. Ради себя, выровняйте прогноз с выходом, чтобы было похоже, что вы выполняете свою работу, а не тратите половину каждого спринта. ничего не делать. Чем дальше удаляются люди с этого времени, тем больше они просто видят, что вы терпите неудачу, оправдания, которые вы делаете в ретро, ​​даже не являются чем-то в их компетенции, они просто видят, что вы терпите неудачу ».

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

Как Scrum Master, вы тренируете и руководите командой, чтобы стать более продуктивным. Фреймворк Scrum - это мощный инструмент для достижения этой цели, но фреймворк Scrum никогда не должен сам по себе становиться целью, иначе вы делаете Cargo Cult .

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

Планирование - просто пустая трата времени, потому что мы просто перемещаем переполнение в новый Sprint и не завершаем работу в любом случае, так зачем беспокоиться.

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

Во время ретроспективы [...] остальные молчат, и мне приходится иметь дело с этим каждый раз.

Если вы сталкиваетесь с одной и той же проблемой в каждой ретроспективе, люди даже не потрудились (больше?) Говорить во время ретроспективы, это просто пустая трата времени. Если вы или команда не можете каким-то образом решить вопросы, поднятые в Ретроспективе, встреча просто деморализует команду. Вопросы, поднятые в Ретроспективе, должны быть рассмотрены, и к следующей Ретроспективе должен быть достигнут прогресс.

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

Действительно, зачем беспокоиться о том, чтобы тратить время на всех, если они просто работают над одними и теми же задачами несколько дней? Они абсолютно правы в том, что Ежедневный Standup действительно бессмыслен. Standup облегчает тесное сотрудничество по многим задачам, каждое из которых может быть выполнено за полдня или меньше. Если ваши задачи не могут быть разбиты таким образом (из-за неправильного планирования спринтов или из-за того, что ваши задачи на самом деле не очень хорошо подходят для Scrum), нет смысла проводить 5-минутное ежедневное совещание в режиме ожидания. не более 5 минут, верно?).

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

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

Нет, вы абсолютно не понимаете, почему он так говорит . Вы получили коренную причину препятствия, которое вам нужно устранить, неправильно. Им все равно, потому что практика управления проектами команды - отстой. Забота о выполнении Cargo Cult и более сложном выполнении Cargo Cult не мешает ему стать Cargo Cult, одной из худших существующих методологий управления проектами (в вашу защиту: также наиболее широко используемой).

Что вы можете сделать по этому поводу?

1. Слушайте их проблемы. Опять же, вы благословлены тем, что у вас есть умные люди .

2. Помогите им устранить препятствия.

И это все, правда. Вам нужно будет поэкспериментировать с тем, как изменить Планирование Спринта, Ежедневные Скрамы и Ретроспективы, чтобы сделать их ценными для команды - даже если вы хотите отказаться от ярлыка Скрам, у вас все еще будут эти 3 встречи с одинаковой частотой и схожей целью в каждом другом методология управления проектами там. Что касается того, как вы собираетесь экспериментировать (частота, содержание, кто организует собрание, время, продолжительность и т. Д.), То это удивительно просто: спросите команду. Не навязывайте свои идеи им, во всяком случае, вы должны позволить им навязывать вам свои идеи (при условии, что они могут согласиться с некоторыми).

Если вы боитесь, что потеряете контроль, заранее установите некоторые границы, например:

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

Я думаю, что все цитируют одну и ту же строчку из Agile Manifesto . Я сделаю то же самое: «Индивидуумы и взаимодействия над процессами и инструментами».

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

Похоже, команда уже признает, что текущая система не выполняет свою работу. Можете ли вы побудить их поверить в то, что это может сделать работу? Вы упоминаете несколько примеров. Если вы переполняете Спринт, чтобы он всегда протекал ... остановитесь. Это ваша команда SCRUM. Помогите им прекратить чрезмерное совершение. Нажмите на управление, чтобы получить передышку. Используйте SCRUM для того, для чего он хорош. Используйте его, чтобы представить руководству данные, которые они прилагают достаточно для того, чтобы потерять ценность в результате своего процесса. Если руководство хочет SCRUM как процесс, попросите его помочь создать пространство и энергию, необходимые для его исправления. Как мастер SCRUM, ваша задача - решать проблемы, чтобы команда могла работать продуктивно.

Другим полезным подходом может быть создание нового процесса в старом. Продолжайте использовать SCRUM таким же бесполезным способом, но отключите небольшую часть графика и скажите: «В этой части нашего графика мы собираемся выяснить, как правильно использовать инструменты». Не переусердствуйте там. Используйте ваши метрики. Сосредоточьтесь на всех ваших встречах там. Просто оставшаяся часть вашего проекта «SCRUM» - это щит, который будет радовать управление, пока вы и ваша команда «[откроете] лучшие способы разработки программного обеспечения, делая это и помогая другим делать это». Со временем вы захотите поместить все больше и больше своих ценных задач в это ведро, и старое ведро будет медленно умирать. Вскоре у вас есть живая среда разработки программного обеспечения, и никто не станет мудрее.

Или смешивать и сочетать их. Я работал над программой, которая была анти-Scrum. Клиенты хотели иметь возможность добавлять новые задачи в любой момент во время процесса, и чтобы мы немедленно приступили к ним. (На самом деле это была вменяемая просьба: их работа была крайне нестабильной, и они часто нуждались в быстрой поддержке ... это то, за что нам заплатили). Конечно, нам пришлось выяснить, как справиться с их проблемами "почему не сделано X, когда вы обещали это в спринте". Наше решение было на самом деле построить двухэтапный процесс. Долгосрочные задачи были поставлены в SCRUM для правильной расстановки приоритетов. Краткосрочные задачи были поставлены в доморощенном процессе, который сосредоточен на тесном взаимодействии между клиентом и разработчиком. Понятно, что клиенты могут толкать нас, используя этот краткосрочный процесс, но они понимают, что это подталкивает Спринт ». в сроки, и им было запрещено добавлять запросы без одновременного слушания и решения проблем планирования, которые они вызвали. Результат? Это сработало. Большинство задач были поставлены в процессе SCRUM, как и должно быть, и чрезвычайные ситуации плавно взаимодействовали с ними. Отношение было таково: «Если вы хотите стать клиентом, встаньте в очередь для истории SCRUM. Если вы хотите стать партнером, не стесняйтесь заходить и работать с нами на повседневной основе и заставить этот продукт работать». !»

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

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

Из-за этого изменения в Scrum Masters и их способ управления шоу

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

Мне интересно, откуда команда. Могли ли они быть более или менее автономными до того, как на них напал Скрам (включая неизбежного Скрам-мастера)? Почему Scrum был представлен в первую очередь? Что это должно было решить?

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

Эта проблема не ограничивается программным обеспечением.

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

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

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

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

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

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

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

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

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

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

В моем случае я особенно пострадал по пункту 5. В основном, схватки относились ко мне как к ребенку и неудачнику. Теперь я находчивый со-разработчик, помогающий моим коллегам ... не удивительно, что я бы предпочел!

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

Вы получили много отличных ответов. Вот еще несколько моментов, которые могут быть полезны:

Изменение методологии сложно

Это трудная задача в рабочем пространстве, потому что вы работаете по инерции «это то, как мы делаем вещи» и против давления сроков и потребностей бизнеса.

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

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

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

Личная мотивация: почему кто-то должен заботиться о том, чтобы вести себя определенным образом?
Личные способности: могут ли они сделать это буквально?
Социальная мотивация: есть ли давление со стороны сверстников для такого поведения?
Социальные способности: поддерживают ли меня окружающие люди и помогают ли они мне, когда мне нужна помощь?
Структурная мотивация: существуют ли награды \ наказания за хорошее \ плохое поведение?
Структурная способность: поддерживает ли физическая среда такое поведение?

Вы должны научиться разбивать задачи

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

Здесь действительно полезно научиться разбивать задачи на мелкие компоненты. Что вы ищете, так это ответ на вопрос: «Хорошо, вы работаете над задачей X, но над чем конкретно в задаче X вы работаете сегодня ?»

Некоторые ответы могут быть:

• Я изучаю этот класс унаследованного кода.
• Я исправляю ошибку, симптомы которой (СИМПТОМЫ).
  • Если это какая-то постоянная ошибка, которая требует времени: «Сегодня я собираюсь попробовать… (ПЛАН)»
• Мне нужно изменить этот интерфейс.
• Я пишу тесты.
• Я интегрирую непроверенный код.

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

Сделано против доставлено

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

Проблема в том, что «доставлено как можно скорее» - очень хаотичный процесс. Это поощряет сокращение углов; кодирование «быстро и грязно»; игнорирование руководящих принципов; не убирать за собой. Он поощряет менталитет «попробуй, посмотри, работает ли он. Если да, доставь. Если нет, попробуй что-нибудь другое» - и, сформулируя это, вы можете понять, почему никто не может предсказать, сколько времени займет что-нибудь.

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

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

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

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

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

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