Развитие Agile через призму Спиральной динамики

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

В закладки

Перед рассказом напомним схему из статьи «Культуры компаний в модели Спиральной динамики».

Корпоративные культуры в модели Спиральной динамики. Из моих презентаций​

В статье «Краткая история IT-менеджмента» я рассказывал логику развития управления проектами в IT, в которой после провала регулярного менеджмента появился Agile. Вот история культур из этой статьи.

Смена культур IT-проектов. Из моих презентаций​

Если мы посмотрим на это развитие через призму Спиральной динамики, то достаточно очевидно, что и эпоха НИОКР и эпоха RUP управление проектами проходило в синей культуре правил, просто правила были разные. Организация НИОКР основана на высокой компетентности сотрудников, которая и должна обеспечить приемлемый уровень успешности проектов. Однако, по мере того как уровень автоматизации начали возрастать, и, как следствие возросла стоимость провала или задержки проекта, было предприняты попытки применить к IT правила организации производства, написав всеобъемлющий регламент. Эта попытка так же потерпела неудачу, подробнее это разобрано в статье «Развитие и провал регулярного менеджмента в IT».

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

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

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

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

Что касается ценностей результативности и готовности к изменениям, которые тоже декларировал Agile-манифест, то их можно интерпретировать как в оранжевой культуре успеха, так и в желтой культуре творчества, и к различным вариантам Agile-культуры, которые получаются из такой интерпретации, я еще вернусь. А пока приведу рисунок с раскраской ценностей Agile-манифеста, заменив «важнее» стрелочкой изменений.

Ценности Agile-манифеста через призму Спиральной динамики. Из моих презентаций​

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

И в центре этих принципов стоит команда профессионалов, которая сама организует свою работу в сотрудничестве с бизнесом: «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией, как с самой командой, так и внутри команды».

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

Все это отражено на схеме из статьи «Agile — ответ IT на вызовы цифрового мира», в которой я подробно рассматриваю логику появления Agile.

​Agile на схеме кораблика. Из моих презентаций

Итак, именно Scrum принес успех Agile-разработке. Он обеспечил выход на продуктивный желтый уровень культуры творчества. Правда, только для команд размером 7-12 человек или небольших компаний, в которых команд не слишком много. Однако, за двадцать лет развития, появились разнообразные методы и фреймворки для этого, обзор которых я давал в статье «Фреймворки масштабирования Agile на компанию». А в последние годы пошло бурное развитие за счет применения Objectives and Key Results (OKR) для координации деятельности компании. Только что прошла первая конференция OKR Russia, на которой было много интересных кейсов. Слайды выступлений уже опубликованы, видео еще недоступно, но можно почитать мой конспект. Также применяются практики бирюзовых организаций, холакратии и социократии, о которых пойдет речь с следующем блоке статей.

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

Инициативные группы также делают попытки расширить Agile-манифест, наполнив его ценностями, соответствующими современному этапу. И на следующей схеме я дополню раскраску ценностей содержанием Манифеста 2.1.

Современное развитие Agile-манифеста через призму Спиральной динамики. Из моих презентаций.

Почему я считаю, что ценности относятся к бирюзовому уровню? Потому что они рассматривают IT-компанию во внешнем контексте, как включенную в большую сетевую структуру взаимодействующих организаций. И ориентированы на развитие этой структуры в целом, а не на собственное развитие компании.

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

​Развитие Agile через призму Спиральной динамики. Из моих презентаций

Однако, история на этом не заканчивается. После успеха Scrum и других Agile-методов пошло их широкое распространение. Новые методы приходили в компании самой разной корпоративной культуры, и их пытались внедрить. Во многих случаях при этом не просто внедряли процессы, а осознанно работали с культурой и достигали результата. Или проводили сопряжения Agile с существующей компании, получая адаптированные версии, такие как Disciplined Agile от IBM.

Но достаточно часто на ценностную составляющую смотрели как на пустые лозунги, или брали только процессную часть, да еще исключая из нее то, что противоречило сложившимся привычкам. И тогда эта попытка проваливалась. О разном восприятии Agile и сценариях развития компании мы поговорим в следующих статьях. Полное оглавление серии есть на моем сайте http://mtsepkov.org/NewMngSeries. Продолжение следует…

{ "author_name": "Максим Цепков", "author_type": "self", "tags": [], "comments": 2, "likes": -3, "favorites": 8, "is_advertisement": false, "subsite_label": "hr", "id": 122980, "is_wide": false, "is_ugc": true, "date": "Sat, 25 Apr 2020 12:19:39 +0300", "is_special": false }
Объявление на vc.ru
0
2 комментария
Популярные
По порядку
0

Что-то мне кажется, что RUP - это уже оранжевый. То есть, инициатива уже есть, ТЗ уже не является истиной в последней инстанции, но команда пока работает по правилам. А то выглядит, как будто на оранжевом есть только проблемы )

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

Ответить
0

Смотрите, базовое положение RUP заключается в том, что предпринимательского риска и принципиальной неопределенности не существует. Что в правильном проекте все риски учтены и проработаны, и поэтому достижение результатов проекта гарантировано в заданные бюджеты и сроки с высокой уверенностью, надо просто работать по регламентам. И это - принципиально синяя позиция. И инициатива в RUP регламентирована и проявляется только там, где положено.

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

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

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

Ответить

Прямой эфир