Портал №1 по управлению цифровыми
и информационными технологиями

SAFe – это троянский конь?

Крис Матц (Chris Matts) на днях опубликовал в своём блоге заметку с забавными, витиеватыми рассуждениями о том, является ли SAFe троянским конём («SAFe is the Trojan Horse»).

SAFe, Scaled Agile Framework – методология масштабирования Agile (речь идёт о попытке масштабировать гибкие подходы на всё предприятие)

Далее – краткий пересказ заметки Криса.

Нередко я слышу, что Agile-коучи отзываются о SAFe как о троянском коне. Так и есть. Только не в том смысле, который они имеют в виду.

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

Однако организации применяют SAFe потому, что они хотят использовать Agile-практики. Т.е. в троянском коне нет необходимости. На самом деле SAFe скорее может оттолкнуть опытных Agile-практиков, которых организация надеется привлечь. В результате, организация вынуждена прибегнуть к помощи «традиционных» консультантов и системных интеграторов, услугами которых пользовалась и ранее.

Получается, SAFe – это троянский конь. Это способ для традиционных консультантов выдать себя за Agile-консультантов, не имея Agile-практики. Короткий учебный курс по SAFe знакомит имеющихся консультантов c новым, ограниченным механизмом управления и контроля.

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

Комментариев: 8

  • Почитал заметку в оригинале и ничего не понял, кроме обильного употребления слова “Троя” и однокоренных.
    Если SAFe (по мнению автора) прикидывается водопадом, чтобы зайти в организации, где водопад любят, а затем магически превращается в Agile, то это как-то глупо. Не превращается.
    Если SAFe прикидывается гибкой, заходит в гибкие организации, и меняет их на водопад, то ещё более глупо.
    Видимо, идею автора мне только предстоит осмыслить…

  • Насколько я понял мысль автора, никто никем не прикидывается.
    Троянский конь – это, с одной стороны, то, что помогает «открыть ворота», проникнуть; с другой – наносит вред.
    SAFe, как и любой продвигаемый бренд, связанный с Agile, расширяет проникновение Agile на рынок. Т.е. в некоторых компаниях Agile (оставим в стороне, в каком виде) появляется благодаря тому, что там начинают исповедовать SAFe.
    Так, по словам автора, считают некоторые опытные Agile-практики, которые SAFe не уважают. Но думают, что благодаря SAFe организации, с него начавшие, вкусив Agile, выбросят SAFe, и «наступит им счастье». Видимо, разделяя с Agile-практиками нелюбовь к SAFe, автор пишет о том, что уважаемые коллеги заблуждаются. Появление в компании SAFe – это «троянский конь» для Agile-сообщества. Для тех самых опытных Agile-практиков. Ибо создаёт иллюзию отсутвия в них необходимости. Зачем они нужны? У нас ведь есть манускрипт, который абсолютно всё объясняет и раскладывает по полочкам. 🙂

  • Противопоставление выглядит искусственным по своей природе.
    Все практики управления, без исключения, соответствуют мантре: “Знание пути – это не то же самое, что движение по нему”.
    Всему остальному, необходимому идущего научит жизнь. Нужно добиваться определенных результатов к установленным срокам – будете управлять проектами. Нужно сокращать сроки доставки бизнес-продуктов – будете инвестировать в разработку и в resilience характеристики продуктов и продуктового бизнес-конвейера. Потребуется совмещать управленческие практики – будете совмещать и никуда не денетесь. Это потребует усилий – да, это космические технологии от управления – нет. Гибкие команды не умеют работать со строгими сроками по ключевым вехам и координироваться друг с другом – чушь, у вас же люди с мозгом в голове там работают? Поставьте правильно задачу.
    Если трудиться осмысленно в сторону нужного вам результата, то он будет достигнут, рано или поздно. А это мнимое противоборство “нерукопожатного” SAFe и “тру” Agile – не более, чем маркетинг, имхо.

    • Андрей, со всеми тезисами трудно не согласиться.
      Но какое отношение они имеют к оснвной мысли Криса Матца?

      • Тезисы озвучивают мое несогласие с оценочным высказыванием из оригинала: “So SAFe is a Trojan Horse. Its a way for traditional consultancies to pass themselves off as agile with no agile experience.”.

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

        • Спасибо за уточнение!
          Просто, чтобы откалиброваться. Если заменить в тексте SAFe на любой другой набор букв, останется ли, на Твой взгляд, смысл в исходной заметке?

  • Возможно, что у Криса есть некоторая вмененная субъективность мнения по отношению к SAFe, вызванная, например, его недавней практикой и наблюдениями, я не знаю.
    А так смысл заметки в конфликте: “упорядоченные правила (SAFe, Disciplined Agile, и др.) убивают свободу команды в её стремлении к …”. Ну, да. Так и есть, ограничения ограничивают. Но они и вводятся не просто так, а для достижения определенных (часто общих) целей, который индивидуальной команде могут быть не близки и тягостны. Реальная практика сложнее, чем обособленные идеализированные случаи, которыми например иллюстрируют Манифест. Для меня, SAFe – это просто инструмент, который специального конфликта в себе не несет. Всегда есть шанс, что если погрузиться в него руками с конкретными людьми, то все предстанет сильно в другом свете, как это вероятно произошло у автора.

    • Ну, ОК. Товарищ Матц отрицательно относится к SAFe (это видно по многим его статьям).
      Но, по-моему, основная идея данной заметки – не оценка SAFe. Несмотря на то, что из названия это, вроде бы, следует. Во всяком случае, мне его заметка показалась примечательной не поэтому.
      А потому, что в ней есть забавное наблюдение. Которое, как мне кажется, можно в той или иной степени отнести к любой попытке кодификации области знания.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM