Agile – ответ IT-отрасли на вызовы цифрового мира по эффективной организации умственного труда, включающий не только методы, но и изменение культуры организаций. В серии «Менеджмент цифрового мира» уже был блок из 21 статьи, посвященный развитию методов Agile и описанию кейсов, их можно посмотреть в оглавлении. А в этой, 43 статье фокус будет на адаптации Agile-методов для разной корпоративной культуры. По мере того, как Agile приходил в большие компании и IT-отделы корпораций, и начинал применяться за пределами IT, появилось большое количество адаптаций, как эффективных и жизнеспособных, так и мертвых. И взгляд через призму Спиральной динамики позволяет во всем этом разобраться.
В статье «Краткая история IT-менеджмента» я рассказывал логику развития управления проектами в IT, в которой после провала регулярного менеджмента появился Agile. Вот история культур из этой статьи.
Если мы посмотрим на это развитие через призму Спиральной динамики, то достаточно очевидно, что и эпоха НИОКР и эпоха RUP управление проектами проходило в синей культуре правил, просто правила были разные. Организация НИОКР основана на высокой компетентности сотрудников, которая и должна обеспечить приемлемый уровень успешности проектов. Однако, по мере того как уровень автоматизации начали возрастать, и, как следствие возросла стоимость провала или задержки проекта, было предприняты попытки применить к IT правила организации производства, написав всеобъемлющий регламент. Эта попытка так же потерпела неудачу, подробнее это разобрано в статье «Развитие и провал регулярного менеджмента в IT».
Если мы посмотрим на следующий уровень развития, оранжевую культуру успеха, то необходимо вспомнить, что организация в ней делится на две части: исполнительную, работающую в культуре правил, и предпринимательскую, работающую в культуре успеха, к которой относится лишь малая часть компании – высший и, возможно, средний менеджмент и некоторые отделы.
По логике построения компании IT-разработка должна относиться к исполнительной части, только вот управлять ей не получалось. Был резкий дефицит компетентных менеджеров среднего звена, сочетающих хорошие предпринимательскую культуру с высокими компетенциями в IT, да и на роль руководителей групп, организовывающих работу и отвечающих за результат, хорошие разработчики тоже не особо стремились, решение креативных задач разработки привлекало их больше.
А появление персоналок и развитие интернета еще больше усилило потребность в разработке, и дефицит кадров. Потому что те разработчики, который чувствовали себя предпринимателями, ушли в стартапы, как раз на эти годы приходится бурное развитие доткомов, завершившееся потом кризисом.
Что касается ценностей результативности и готовности к изменениям, которые тоже декларировал Agile-манифест, то их можно интерпретировать как в оранжевой культуре успеха, так и в желтой культуре творчества, и к различным вариантам Agile-культуры, которые получаются из такой интерпретации, я еще вернусь. А пока приведу рисунок с раскраской ценностей Agile-манифеста, заменив «важнее» стрелочкой изменений.
Но ценности ничего не стоят, когда невозможно организовать процесс, в рамках которого они могут проявиться. Поэтому Agile-манифест помимо ценностей содержал принципы организации процесса. Заметим, что они не следуют из ценностей напрямую, а сформулированы на основании предыдущего опыта IT-разработки.
И в центре этих принципов стоит команда профессионалов, которая сама организует свою работу в сотрудничестве с бизнесом: «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией, как с самой командой, так и внутри команды».
И появились конкретные методы фреймворки, которые организуют работу в соответствии с принципами, первым из которых был Scrum, давший способ организации работы команды, соответствующий желтой культуре творчества.
Все это отражено на схеме из статьи «Agile — ответ IT на вызовы цифрового мира», в которой я подробно рассматриваю логику появления Agile.
Итак, именно Scrum принес успех Agile-разработке. Он обеспечил выход на продуктивный желтый уровень культуры творчества. Правда, только для команд размером 7-12 человек или небольших компаний, в которых команд не слишком много. Однако, за двадцать лет развития, появились разнообразные методы и фреймворки для этого, обзор которых я давал в статье «Фреймворки масштабирования Agile на компанию». А в последние годы пошло бурное развитие за счет применения Objectives and Key Results (OKR) для координации деятельности компании. Только что прошла первая конференция OKR Russia, на которой было много интересных кейсов. Слайды выступлений уже опубликованы, видео еще недоступно, но можно почитать мой конспект. Также применяются практики бирюзовых организаций, холакратии и социократии, о которых пойдет речь с следующем блоке статей.
Таким образом, постепенно идет построение следующей за желтым уровнем бирюзовой культуры развития, в которой мир оказывается сетью разномасштабных сотрудничающих организаций.
Инициативные группы также делают попытки расширить Agile-манифест, наполнив его ценностями, соответствующими современному этапу. И на следующей схеме я дополню раскраску ценностей содержанием Манифеста 2.1.
Почему я считаю, что ценности относятся к бирюзовому уровню? Потому что они рассматривают IT-компанию во внешнем контексте, как включенную в большую сетевую структуру взаимодействующих организаций. И ориентированы на развитие этой структуры в целом, а не на собственное развитие компании.
Подводя итоги рассказанной истории, можно отразить развитие Agile через призму Спиральной динамики на следующей схеме.
Однако, история на этом не заканчивается. После успеха Scrum и других Agile-методов пошло их широкое распространение. Новые методы приходили в компании самой разной корпоративной культуры, и их пытались внедрить. Во многих случаях при этом не просто внедряли процессы, а осознанно работали с культурой и достигали результата. Или проводили сопряжения Agile с существующей компании, получая адаптированные версии, такие как Disciplined Agile от IBM.
Но достаточно часто на ценностную составляющую смотрели как на пустые лозунги, или брали только процессную часть, да еще исключая из нее то, что противоречило сложившимся привычкам. И тогда эта попытка проваливалась. О разном восприятии Agile и сценариях развития компании мы поговорим в следующих статьях. Полное оглавление серии есть на моем сайте http://mtsepkov.org/NewMngSeries. Продолжение следует…
