И, на мой взгляд, это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. Фреймворк не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать. И дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно. Подробнее о сложности областей – в описании Кеневин-фреймворка в главе «Место Agile-команд в компании».

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

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

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит.

По опыту лекций об Agile в разных аудиториях, рассмотрение кейсов Agile-трансформации вызывает большой интерес слушателей. В том числе – таких известных, как Agile в Сбербанке или Альфа-банке, хотя, казалось бы, об этом можно найти много публичных материалов. Причина, думаю, в том, что хорошие системные материалы погребены под большим количеством попсовых изложений, которые не раскрывают суть, а иногда ее искажают. Поэтому я начинаю рассказ о кейсах, чтобы в совокупности дать многовариантную картину. Сейчас речь пойдет о трансформации банков, причем не IT-подразделений, а работы бизнеса в целом.

Мои источники – доклады на профильных конференциях – AgileDays, Agile Business и других, а также разговоры в кулуарах конференций и другие частные разговоры. Там, где это возможно, в статье будут ссылки на конкретные доклады. По конференциям я публикую отчеты на моем сайте, и конспекты большинства упомянутых здесь докладов есть в отчетах с соответствующих конференций. Однако, в любом случае все написанное – моя собственная интерпретация услышанного из разных источников. Она не претендует на истину в последней инстанции, и если у вас другая картина, вы можете ей поделиться. Вместе с тем, хочу отметить, что авторы докладов, которые тоже читали мои отзывы, обычно не опровергают моей интерпретации, а в тех случаях, когда они указывают на необходимость исправлений, я обычно это делаю.+ Disclaimer: все изложенное – моя личная интерпретация событий