Короче говоря, мы создаем продукт, и я представил, а затем внедрил фреймворк Scrum для управления продуктом. Это работает очень хорошо, и моя команда проделала потрясающую работу.
Проблема, с которой я сталкиваюсь сейчас, заключается в том, что основная заинтересованная сторона начинает испытывать потребность в функциях до такой степени, что на качество результатов влияет увеличение количества элементов в спринте.
Каждый раз, когда мы делаем хорошую работу, то есть выполняем спринт, на следующей неделе заинтересованная сторона запрашивает дополнительные функции. Он считает, что, поскольку мы уложились в спринт, мы можем сделать больше работы на следующей неделе.
(Сейчас он хочет выпускать 3 функции в неделю)
Затем моя команда должна компенсировать это, увеличив скорость. В конце концов, дело дошло до того, что за один спринт в нас бросили кухонную раковину, и ожидается, что мы предоставим тройное количество функций по сравнению с предыдущими спринтами. Из-за увеличения скорости это также означает, что появляется больше ошибок из-за функций, которые срочно внедряются в производство.
Сейчас я нахожусь в ситуации, когда мы начинаем отставать в наших спринтах, а мои коллеги жалуются, что нагрузка слишком велика. Я также получаю гораздо больше критики от заинтересованной стороны за то, что не выполнил всю обещанную работу. На нашей следующей встрече команды я думаю о том, чтобы поговорить об этом со своим заинтересованным лицом с командой разработчиков, это хорошая идея?
Как я могу справиться с этим?
На самом деле я должен в какой-то степени не согласиться с Дэвидом Эспиной. В Scrum важно понимать, кому принадлежит какая часть процесса.
Позволяя PO (или, что еще хуже, Заинтересованному лицу) диктовать, что делать в Спринте, вы снижаете эффективность команды и ставите под угрозу качество своей работы, как вы уже отметили в своем посте. Это не означает, что Скрам-мастер или Владелец Продукта не могут поощрять команду брать на себя больше или даже направлять их к агрессивному Коммиту Спринта, но никто, кроме команды, не может зафиксировать элемент в Бэклоге Спринта.
На вашем месте я бы потратил некоторое время, чтобы объяснить заинтересованным сторонам и PO, что, эй, посмотрите, насколько больше мы делаем с помощью Scrum — вы не можете ожидать чуда каждый спринт. Скорость обычно увеличивается, но иногда она также уменьшается (например, если команда делает плохую оценку или что-то является «тяжелой» 8 вместо «легкой».) Я бы сказал им, что нам нужно позволить Команда разработчиков делает то, что у них получается лучше всего, и доверяет команде вкладывать в спринт столько, сколько они могут, не ставя под угрозу качество предоставляемых функций.
Я не совсем то, кто толкает вашу команду. Вы или заинтересованная сторона?
1: очевидно, что любую команду нужно постоянно поощрять и бросать вызов, чтобы добиться большего и стать более продуктивным.
2: опять же, очевидно, независимо от того, «что говорит скрам», сроки имеют значение, если вы хотите получать деньги.
Но! Команда разработчиков должна оценивать задачи в журнале невыполненных работ, а скорость предыдущего спринта должна дать вам оценку того, сколько задач находится в следующем спринте.
Если на команду оказывают давление, чтобы сделать более низкие оценки, это не меняет объем проделанной работы, а только число скорости.
Если заинтересованная сторона довольна большим количеством функций и, возможно, меньшим количеством тестирования или меньшим количеством деталей по каждой функции, то это их решение, и это должно быть отражено в историях. Все мы знаем, что последние 10% истории обычно занимают 90% времени.
Если вы или заинтересованное лицо напрямую оказываете давление на команду, чтобы она работала усерднее, быстрее или дольше, то это всего лишь призыв руководства к тому, считаете ли вы, что они бездельничают или нет.
Однако ваш скрам-мастер должен защищать команду от такого прямого взаимодействия с заинтересованными сторонами.
Поднять планку — это хорошо. Вы должны отступить от этого и продолжать настаивать на большем. Добавление проблем в команду заставляет команду выяснять, как справиться с этими проблемами, и часто очень пессимистичная команда, которая предсказывает, что «это невозможно сделать», добивается своего. Каким-то образом команды адаптируются и внедряют инновации.
Вы также смягчаете такие вещи, как закон Паркинсона и синдром студента, когда постоянно бросаете вызов команде, которая считает, что «это невозможно сделать».
И я согласен, что это не без затрат и риска. Вы должны следить за этими вещами и наблюдать за моральным духом команды, проблемами плотности дефектов, жалобами заинтересованных сторон, когда их ожидания не оправдываются, и т. д. Я думаю, вы будете удивлены, однако, как много из этих затрат и рисков на самом деле не материализуются, когда вы думаете они бы.
Это интересно о планировании ценностей и ожиданиях заинтересованных сторон. Запланируйте 2 функции и достигните их за определенный период времени. Запланируйте 4 и получите 3 за тот же период времени. Первый вы достигли цели. Второй вы пропустили свою цель. Но что на самом деле лучше?
РЕДАКТИРОВАТЬ: К комментарию @bobo2000: я ожидаю, что будет точка убывающей отдачи. По моим наблюдениям, эта точка находится дальше, чем многие верят или предсказывают. Тем не менее, если вы думаете, что находитесь в этой точке, вам нужно научиться говорить клиенту «нет». Если вы решите принять вызов, то вам нужно очень официально и громко обозначить риски, которые вы видите, например, очень вероятно, что мы не достигнем всех целей в этом спринте, или мы, вероятно, увидим всплеск Дефекты Сев 1 и 2 это обойти. В какой-то момент вам нужно начать контролировать разговор. Ваш клиент будет настаивать и настаивать, потому что он смотрит на это с точки зрения «максимальной выгоды на каждый потраченный доллар». Скажите «нет» и увеличьте риск. Это часть вашей работы в качестве PM! Удачи.
@Rubberduck: Увеличение количества дефектов и пропущенных сроков может означать, что вы достигли предела возможностей, если у вас достаточно наблюдений, чтобы исключить нормальную причину. В противном случае у вас может быть ложноположительный результат. Оба являются вероятностными, управляемыми многими стохастическими факторами. Увеличение дефектов само по себе ни о чем не говорит. Если ожидался уровень брака 10 %, они работали, скажем, на уровне 4 %, а затем увеличились до 6 %, говорит ли это о избыточной мощности?
И ваш комментарий об уверенности и процессе как раз соответствует моей точке зрения. Если команда может улучшить свои возможности, улучшив свои процедуры, значит, она изначально не в состоянии.
Команды могут адаптироваться к вызовам за счет инноваций. Если вы не форсируете вызов, команды не будут вводить новшества или адаптироваться. На самом деле, они ухудшают... болезнь Паркинсона!
MasterPJ
Джефф Линдси