Узнайте, почему разработчики чувствуют себя в ловушке Scrum и как адаптироваться к ситуации

"Дерьмо! Сегодня у нас доводка, а я все еще отстаю от своих задач».

«Давайте сегодня пропустим ретроспективу, тогда мы сможем предоставить функции».

«У меня слишком много совещаний, и нет времени сосредоточиться на программировании!»

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

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

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

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

Где начинается проблема?

Цифровая индустрия все еще относительно молода; это было только в 1948 году, когда Том Килберн написал первую строчку кода. И с тех пор мы искали способы извлечь выгоду из разработки программного обеспечения. Я считаю, что мы добились значительного прогресса в этом, поскольку в настоящее время мы делаем почти все в цифровом формате.

Несмотря на наши достижения в цифровом мире, мы по-прежнему не умеем принимать неизвестное.

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

Разработчики — творческие люди; им нравится получать проблемы для решения, а не задачи для реализации. Однако высшее руководство склонно рассматривать их как строителей, которые кладут кирпичи в стену вместо того, чтобы определять, что имеет смысл строить для преодоления конкретных проблем.

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

Что заставляет разработчиков чувствовать себя в ловушке Scrum?

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

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

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

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

  • Во время сеансов уточнения вы говорите о решениях для реализации, требованиях к выполнению, технических проблемах и оценках. Между тем, основная проблема не является частью какого-либо обсуждения, потому что кто-то заранее определил решение, и вы ожидаете, что разработчики предоставят решения, а не решат проблемы.
  • Планирование спринта — это самое механическое собрание, которое у вас есть. Во время мероприятия вы понимаете возможности команды, смотрите на скорость, согласовываете задачи, которые подходят для следующего взаимодействия, и начинаете спринт. Тем не менее, вы не говорите о цели спринта, потому что выбранные вами задачи не связаны друг с другом, поэтому ставить цель бессмысленно.
  • Каждый день, когда вы посещаете Daily Scrum, вы смотрите на диаграмму выгорания и оказываете давление на команду, когда линия кажется плоской. Для вас важно иметь красивую диаграмму выгорания. Каждый разработчик рассказывает о своем «Спринте», поскольку у всех разные цели. Они не находят возможности поддерживать друг друга, да и времени на это у них нет, так как совет полон задач для реализации.
  • Ближе к обзору спринта разработчики в отчаянии и умоляют вас пропустить доработку, потому что у них еще много работы, и вы с этим соглашаетесь. Разработчики идут на компромиссы для выполнения задач, технический долг увеличивается, и вы, как владелец продукта, принимаете это и не решаете проблему.

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

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

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

Раскрытие потенциала разработчиков

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

  • Сосредоточьтесь на меньшем: убедитесь, что разработчики могут работать в команде, а не создавать микрокоманды внутри команды Scrum. Сосредоточьтесь на том, чтобы делать меньше; это оставит пространство для творчества и участия. Если вы не можете установить цель спринта, вы упускаете суть.
  • Читайте между строк: даже если вы получаете четкие инструкции, понимайте цель, стоящую за каждым пунктом. Сосредоточьтесь на достижении цели, а не на соответствии набору требований. Не пытайтесь убедить заинтересованные стороны в других решениях; доказывать результатами вместо аргументов.
  • Решайте проблемы с разработчиками: когда вы понимаете, что разработчики создают технический долг, потому что вы оказываете на них давление, поговорите открыто и найдите способ решить эту проблему. Если сеансы уточнения истощают вашу энергию, потому что разработчики хотят знать каждую мельчайшую деталь, это признак недоверия. Вероятно, они боятся потерпеть неудачу и нести за это ответственность. Пока вы не сможете разрешить конфликты с разработчиками, команда будет нефункциональной.
  • Ставьте цели: вы являетесь владельцем продукта, вы должны занимать руководящую позицию, не быть пассивным. Поймите самую критическую проблему на данный момент, установите цель продукта и убедитесь, что заинтересованные стороны понимают ее важность. Все, что не помогает достичь Цели Продукта, в данный момент не имеет значения, и вам не следует тратить на это время.
  • Расширьте возможности разработчиков: не пытайтесь управлять разработчиками на микроуровне, появляясь на всех ежедневных скрамах и оказывая на них давление для достижения прогресса. Дайте им возможность принимать решения и предоставьте им пространство для творчества. Доверие — основа любой высокоэффективной команды. В надежных Scrum-командах разработчики обладают самоуправлением и обладают всеми необходимыми навыками для создания ценности для бизнеса и конечных пользователей.

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

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

Последние мысли

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

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

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

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

Спасибо, Шёрд Нийланд и Виллем-Ян Агелинг за отзыв.