Почему Agile терпит неудачу на крупных предприятиях

Почему Agile терпит неудачу на крупных предприятиях Изучение

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

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

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

Манифест Agile

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

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

Люди и взаимодействие важнее процессов и инструментов

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

Рабочее программное обеспечение, а не исчерпывающая документация.

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

Сотрудничество с клиентами вместо переговоров по контракту.

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

Реагирование на изменения вместо следования плану

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

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

У крупных предприятий глубоко укоренившиеся процессы

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

Как отойти от водопада

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

Так как же крупным предприятиям отказаться от этой модели водопада?

Вот несколько полезных советов для начала:

  • Ограничьте количество лиц, принимающих решения.

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

  • Оставайтесь на той же странице.

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

Как ценить гибкость над предсказуемостью

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

  • Ожидайте неудачи; Итерируйте, чтобы адаптироваться.
Читайте также:  Как проверить использование памяти в Kubernetes Pod?

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

  • Начните с малого с создания самоорганизующихся команд.

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

Вы не можете «масштабировать» Agile

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

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

Выравнивание обеспечивает автономность

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

Генри Книберг представил наглядную диаграмму, описывающую взаи

Каждое предприятие подпадает под шкалу согласованности от низкой к высокой по отношению к автономности от низкой к высокой. Затем каждое предприятие классифицируется по:

  • Тип организации
  • Тип культуры

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

Высокая согласованность / низкая автономность:

  • Авторитетная организация
  • Конформистская культура **

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

Высокая согласованность / высокая автономность:

  • Инновационная организация
  • Культура сотрудничества

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

Низкое выравнивание / низкая автономность:

  • Микроуправляющая организация
  • Безразличная культура

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

Низкое выравнивание / высокая автономность:

  • Предпринимательская организация
  • Хаотическая культура

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

Как преобразовать свою команду

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

Итак, с чего начать?

С чего начать трансформацию

По словам Майка Коттмейера, генерального директора и основателя LeadingAgile, для перехода вашей команды к гибкой методологии необходимы:

  1. Определение того, где находится ваша организация
  2. Помогая ему добиться успеха на месте
  3. Постепенные изменения в сторону гибкости

Определение того, где находится ваша организация

Читайте также:  Как расширить свой набор инженерных навыков, не бросая дневную работу

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

Помогая ему добиться успеха на месте

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

Постепенные изменения в сторону гибкости

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

На чем сосредоточить внимание при постепенных изменениях

Каждая организация приближается к гибкости тремя разными способами:

Культура

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

Упражняться

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

Состав

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

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

  • Задержки

Часто список результатов на большом предприятии заполнен задачами, которые охватывают длительные периоды времени или выделяют большие цели видения. Вместо этого ваш бэклог должен соответствовать критериям ИНВЕСТИРОВАНИЯ и быть заполнен достаточно небольшими задачами, которые можно выполнить в течение дня. Таким образом, ваши невыполненные бэклоги дадут вашей команде больше ясности и цели на протяжении всей последовательности ваших проектов.

ИНВЕСТ — это аббревиатура для оценки качества пользовательской истории:

«Независимый

«Не подлежит обсуждению»

«Ценный

«E» стимулирующий

«Небольшой

«Т» столик

  • Команды

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

  • Работающее протестированное ПО:

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

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

Заключение

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

Оцените статью
bestprogrammer.ru
Добавить комментарий