SAFe — это полная противоположность тому, что использовала бы сильная продуктовая компания. Это так называемый Agile в масштабе. Это не Agile. Это просто маркетинг.
«Так много крупных компаний пристрастились к процессу, и они думают, что ответ — это процесс… Даже если они используют слово «гибкий», они часто используют такие нелепые процессы, как SAFe или LeSS. Это полная противоположность тому, что использовала бы хорошая продуктовая компания. На самом деле я не могу указать ни на одну сильную производственную компанию, которая использует любой из них. Они так называемые Agile at Scale. Они совсем не Agile. Это просто маркетинг, и все эти люди повелись на маркетинговый ход.
— Марти Кейган, 2022 г.
Марти Кейган является основателем и партнером Silicon Valley product Group (SPVG) и автором бестселлеров INSPIRED и EMPOWERED. Марти, который имеет 20-летний опыт работы в отрасли в качестве лидера по продуктам, теперь работает с технологическими компаниями со всего мира, помогая им трансформировать продукты с помощью инноваций, скорости и гибкости. Его часто называют самым влиятельным человеком в продуктовом пространстве.
TLDR;
Современные гибкие методологии включают сложные системы для отслеживания того, выполняет ли команда работу, которую они взяли на себя на уровне PI. Без надлежащей стратегии управления продуктом (поскольку это не может происходить несколько дней в квартал) инженеры тратят огромное количество времени, лгая о своих оценках, занижая обещания и пытаясь геймифицировать общие показатели. Это вызывает огромные проблемы с мотивацией инженеров. Самоэффективность, которая является частью установленной модели психологического благополучия (модель Циммермана, объясняющая саморегуляцию), — это вера в то, что вы можете что-то сделать, и мотивация, связанная с этим. Если ваши сроки и оценки не имеют смысла, и вы слишком долго лжете об этом, то вы не можете построить структуру убеждений или мотивацию вокруг выполнения этого, что затем влияет на ваш интерес даже к попытке сделать это.
Что такое САФе?
Scaled Agile Framework® (SAFe®) представляет собой набор шаблонов организации и рабочего процесса для внедрения гибких практик в масштабе предприятия. Структура представляет собой совокупность знаний, которая включает в себя структурированное руководство по ролям и обязанностям, тому, как планировать работу и управлять ею, а также ценности, которые необходимо поддерживать.
SAFe утверждает, что более 1 000 000 специалистов прошли обучение по SAFe в более чем 110 странах. Значит, в этом что-то должно быть?
Безопасная реализация
Первый шаг, согласно схеме SAFe, заключается в том, чтобы выбрать группу сотрудников, которые станут консультантами программы Safe.
«Обучать агентов изменений Lean-Agile в качестве сертифицированных консультантов программы SAFe® (SPC)».
Стоимость сертификации составляет около 3000 долларов США за SPC, и это не включает расходы на отправку ваших руководителей и общего персонала для прохождения других сертификаций, которые SAFe рекомендует вашей организации.
Предполагаемый результат? Теперь у вас есть преданные своему делу сотрудники, которые живут и дышат SAFe и продвигают программу SAFe в своей организации. Это буквально пирамида в действии.
Фирменный Agile
Следующий отрывок о брендированном Agile взят из Understanding Fake Agile Стива Деннинга, 2019 г.
Особенно неудачная форма «фирменной гибкости» касается масштабируемых фреймворков. Это схемы, направленные на помощь фирмам, в которых есть несколько команд, внедряющих методы Agile, и которые хотят устранить противоречия между Agile-командами и бэк-офисными системами организации (такими как стратегия, планирование, бюджет, HR, финансы), которые обычно являются монолитными. и бюрократический.
Задача обычно представляется как «расширение масштаба agile». Проблема здесь в том, что если фирма думает о «расширении agile», она уже на неверном пути. Задача настоящего agile заключается в том, как преобразовать большие монолитные, ориентированные на внутренние системы системы в задачи, которые могут выполняться небольшими самоуправляемыми командами, ориентированными на клиента.
Особенно тревожным вариантом является Scaled Agile Framework или SAFe. По сути, это кодифицированная бюрократия, в которой почти полностью отсутствует заказчик. В настоящее время он широко распространен в крупных фирмах, потому что дает руководству право называть себя гибкими и продолжать делать то, что они делали всегда. По сути, он подчиняет agile-команды бюрократии вместо того, чтобы делать то, что необходимо для достижения гибкости бизнеса, а именно, трансформировать большие монолитные внутренние системы в механизмы, в которых бюджеты, HR, финансы и т. д. гибки и ориентированы на внешнюю поддержку. Agile-команды в работе. Незначительная роль клиента в приведенной выше диаграмме свидетельствует о проблеме.
Существует риск того, что SAFe дискредитирует настоящий Agile. Это иллюстрация закона Грешема: плохие деньги вытесняют хорошие. Когда это происходит, SAFe становится воплощением «фальшивого Agile». Вполне возможно, что когда SAFe внедряется менеджерами с подлинным мышлением Agile, его негативные побочные эффекты могут быть смягчены. Мой вопрос был бы таким: зачем кому-то с подлинным мышлением Agile вообще использовать SAFe?
Общие требования безопасности
Ниже приведен набор более мелких моментов, которые не заслуживают отдельного раздела в этой статье:
- SAFe описывает команду разработчиков как состоящую из «разработчиков и тестировщиков», а не как полностью кроссфункциональную.
- SAFe пытается внедрить методы обеспечения качества кода, адаптированные из XP.
- SAFe говорит: «Разрабатывай в темпе, доставляй по требованию», но также использует «Поезда релизов». Последовательности релизов — это большие отправляемые инкременты. Это не выполняется по запросу. Доставка осуществляется каждые 10 недель по графику.
- SAFe предполагает, что 6-й спринт должен быть посвящен «укреплению, инновациям и планированию». Это модель «старт-стоп». Всякий раз, когда есть остановка, есть ненужная трата. Бизнес и клиенты не ложатся спать на 2 недели каждые 3 месяца, и это не вписывается в настоящую модель DevOps.
- SAFe говорит, что вам нужно как минимум 50+ человек, чтобы сделать SAFe.
- SAFe предполагает, что каждый проект, над которым вы работаете, огромен и требует выполнения несколькими командами. В действительности это не так. Команды, ориентированные на продукт и ориентированные на него, могут самостоятельно и по требованию выполнять комплексные задачи.
- SAFe претендует на то, чтобы быть бережливым и гибким, но противоречит многим принципам бережливого производства и почти всему манифесту agile.
- SAFe намеренно слишком сложен и каждый год обновляет спецификацию, чтобы продвигать и продавать сертификаты.
- SAFe упакован и разработан специально для менеджеров и руководителей, которые не понимают Agile и не хотят заниматься настоящей трансформацией продукта.
Критика планирования PI
Инкремент программы (PI) — это временной интервал, в течение которого Agile Release Train (ART) обеспечивает дополнительную ценность в виде работающего, протестированного программного обеспечения и систем. ИП обычно длятся 8–12 недель. Наиболее распространенный шаблон для PI — это четыре итерации разработки, за которыми следует одна итерация инноваций и планирования (IP). — PI Increment, SAFe, 2021 г.
Создание диаграммы Ганта и использование слова «Спринт» в середине 10 раз — это не Agile. Это Водопад.
Консультанты программы SAFe:
«ЭТО НЕ ДИАГРАММА ГАНТА. ЭТО ДИАГРАММА ПЕРТА».
SAfe, кажется, бросает вызов этому, проповедуя разновидность ПЛАНИРОВАТЬ, ДЕЛАТЬ, ДЕЙСТВОВАТЬ, но в принципе вы готовитесь к 12-недельной работе, которая когда-то представила высшему руководству удары реальности, которые они отслеживают, что, по их мнению, является обязательством выполнять именно эту работу. Вы можете сколько угодно спорить, что это не является намерением PI, но в реальном мире руководство часто интерпретирует это именно так, а SAFe только поощряет такое плохое поведение.
Ваша диаграмма PERT — или SAFe PI board, которая является одним из ключевых артефактов, получаемых от PI, — может показаться ценной за счет определения и управления зависимостями между командами, но это ложная гибкая дихотомия. Настоящая компания, ориентированная на продукт, строит «слабо связанную архитектуру», которая позволяет командам тестировать и развертывать любые изменения полностью независимо друг от друга, не полагаясь на поддержку и услуги кого-либо еще.
Другой анти-шаблон, который поощряет SAFe (хотя опять же потенциально аргументируется плохой реализацией), заключается в том, что вы реагируете/адаптируетесь к изменяющимся требованиям клиентов только 4 раза в год.
PI основан на относительной оценке. См. мою статью о том, почему Относительная оценка — пустая трата времени.
Фиксированные интервалы планирования никогда не соответствуют действительности. В Lean планирование должно происходить по требованию. Не через фиксированные промежутки времени.
На самом деле при фиксированном планировании всегда есть 2 результата:
- Команда инженеров заканчивает свою рабочую книгу ДО следующего PI. Поэтому они выполняют меньше работы в оставшееся время без четкого направления или снова начинают планировать вне PI.
- Команда инженеров заканчивает свою рабочую книгу ПОСЛЕ следующего PI. Во время PI они планируют новую работу до того, как закончат предыдущую работу. Когда PI заканчивается, они либо возвращаются к тому, над чем работали раньше, либо отказываются от части этого, чтобы работать над новой вещью. Это вызывает дополнительные проблемы с переключением контекста.
Инженеры также не участвуют в течение 4-дневного сеанса планирования PI. Команды эксплуатации, SRE или DevOps жалуются, что не могут запланировать отпуск и в конечном итоге работают дольше. Инженеры из разных мест и часовых поясов вынуждены присоединяться к звонкам рано или поздно вечером.
Если вы развертываете по требованию, автоматически заполняйте и обновляйте свой невыполненный заказ на основе сигналов запуска и остановки, практикуйте непрерывный сбор требований, отслеживайте работу до разработки инженеров (т. работать в модели непрерывной доставки, то в этом случае нет необходимости в масштабном планировании, и, следовательно, это пустая трата времени.
Оспаривание лучших практик
Последнее из сообщения в блоге Дэна Норта…
Организации часто внедряют лучшие практики как часть программы изменений или инициативы по обеспечению качества. Они могут принимать различные формы, от «поваренных книг» и шпаргалок до полномасштабных методологий под руководством консультантов, дополненных необходимым аудитом и аккредитацией.
В этой статье представлена модель обучения Дрейфуса, чтобы бросить вызов стратегии наивного применения лучших практик, и показано, как они могут не только не помочь, но даже оказать серьезное негативное влияние на ваших лучших исполнителей.
- Дэн Норт, 2008 г.
Так зачем кому-то с подлинным мышлением Agile вообще использовать SAFe?
