Хотя SAFe привлекает большое внимание и, как я понимаю, дает лучшие долгосрочные результаты (скорость и общее качество продукта), чем традиционный Agile, мне любопытны его возможные недостатки. Любые мысли по этому поводу будут оценены.
Во-первых, я должен сказать, что мой опыт не соответствует этому утверждению, и я не знаю ни одного исследования, подтверждающего это. Когда SAFe или «чистый» Agile хорошо адаптируются, они оба имеют высокую производительность и качество.
Глядя на различия, я бы сначала посмотрел на то, что мешает им хорошо адаптироваться. В SAFe нужно заполнить много позиций, и это очень похоже на старые позиции в водопаде, но это не так. С точки зрения управления изменениями, заманчиво сказать, что менеджеры или руководители групп становятся инженерами по подготовке релизов и т. д. Именно здесь многие внедрения SAFe разваливаются, потому что люди выполняют свою старую работу, а не новую, и они несут много ошибок. старых дисфункций, которые компания внедряла в SAFe, чтобы исправить вместе с ними.
С более «чистым» agile-подходом проблема обратная (и, как это ни парадоксально, почти такая же). Упрощение организации и децентрализация принятия решений пугают, и многие организации просто этого не делают. Они проводят несколько совещаний, берут несколько терминов из Scrum или Kanban и заканчивают работу. Любой, кто занимается управлением изменениями, скажет вам, что незавершенное изменение — это катастрофа.
Вы спросили о недостатках, и я хотел бы указать на это: какие изменения ваша организация действительно хочет сделать? Оба являются настоящим обязательством, и ни одно из них не должно быть сделано наполовину, иначе вы, вероятно, окажетесь в худшем месте, чем вы начали.
Еще одна вещь, которую следует учитывать: для чего вы оптимизируете? SAFe всегда был разработан для невероятно больших проектов. Я не имею в виду 5 команд, я имею в виду десятки и более. Scrum оптимизирован для быстрого решения проблем и адаптивности (на уровне масштабирования LeSS и Scrum@Scale сохраняют эту направленность). Канбан оптимизирован для потока работы через рабочий процесс. Если вам нужно решать проблемы и адаптироваться к быстро меняющейся среде, SAFe может «работать», но так же, как вы можете забить гвоздь гаечным ключом, если вам нужно. Точно так же я бы не стал управлять масштабными проектами, используя только чистый подход Scrum.
Я не вижу, чтобы SAFe и традиционный Agile действительно были сопоставимы в смысле Apple-Apple.
Традиционный agile — это потрясающе, и если вы сомневаетесь, удвоить agile-фреймворк — отличная идея. Но на фундаментальном уровне, когда вам нужно, чтобы 10 agile-команд работали в одном направлении над одной и той же инициативой, вам нужен способ координировать эту деятельность.
Полноценный SAFe, безусловно, пугает. Но, возможно, лучше рассматривать только программную/основную часть SAFe как способ решения agile в масштабе.
Я менеджер, основанный на фактических данных, то есть моя практика основана на постоянном обзоре научной литературы, поэтому я могу подтвердить заявление Дэниела: нет объективных доказательств того, что SAFe лучше (или хуже) других методов внедрения Agile-менеджмента.
Я рекомендую быть осторожным с терминами, просто чтобы вы получили лучший совет! Agile — это философия или подход к управлению работой, а не метод, поэтому не существует такого понятия, как «традиционный Agile». SAFe — это лишь один из десятков подходов к масштабированию Agile-методов для многих команд, при этом SAFe основан на методе под названием «Scrum». Даниэль упомянул пару других, и я создал свой собственный Full Stack Scrum. Как он и Эрик сказали, нужен ли вам один из них, зависит от того, сколько команд вы пытаетесь скоординировать. Базовый Scrum на самом деле довольно хорошо масштабируется для нескольких команд, если вы просто переводите термины вверх. То есть лечить:
Или пусть все примут участие в одной совместной демонстрационной церемонии, и вам даже не понадобится схватка схваток!
Даниэль
Эмиль Бернар
Эрик