I. Состоятельна ли сфера разработки без лидерства?

Преимущества и недостатки разработчиков в контексте лидерства

Лидерство – идеальная смысловая среда разработки

Самоорганизация и гибкость как результат лидерства

II. Лидерство в контексте методологий DevOps и Agile

Противоречивость agile-подхода

Лидерство vs Agile-лидерство

Agile без лидерства: «а что так можно было?»

Лидерство – это Agile для Agile

III. Лидерство в IT. Далеко идущие выводы

В последнее время тема лидерства в IT компаниях потерялась в потоке энтузиазма, вызванного безграничными перспективами отрасли. Лидерство, конечно, фигурирует в современных методологиях типа Agile и DevOps, но при этом не наделяется достаточной силой, чтобы выполнить свою трансформационную роль. Лидерство выглядит как Золушка с неочевидным для всех королевским потенциалом. Эта статья возвращает лидерство на пьедестал, обосновывая его уместность именно для IT. Речь здесь идет о таком лидерстве, которое одержимо незаурядным результатом в равной степени, как и опорой на смыслы и человеческое достоинство и не имеет ничего общего с расхожим «лидерством», которое практически равнозначно понятию «руководитель». За таким подлинным пониманием лидерства стоят хорошо известные с 70-х годов принципы трансформационного лидерства Джеймса Бернса и Бернарда Басса. В период индустриальной эпохи эти принципы использовались факультативно, хотя и с большим успехом. Лидерство в компаниях стало притчей во яцызах , но не возобладало в традиционном менеджерском управлении. Эра информационных технологий делает трансформационное лидерство в IT компаниях безальтернативным. Эта статья не про теоретические изыскания на будущее, а про достижение незаурядных результатов в настоящем.

I. Состоятельна ли сфера разработки без лидерства?

При ответе на этот вопрос будем использовать простую и наглядную аналогию: лидерство — это своего рода парус, улавливающий дуновение прогресса, и использующий его силу для достижения новых рубежей в интересах своей компании и общества, выбранный путь к которым таков, что сплачивает команду и придаёт ей оптимизм, увеличивая шансы на новые открытия. В попытке определить лидера в этом контексте попробуем избежать банального слова «капитан», которое имеет привкус тщеславия и официальности, а также слова «кормчий», которое не имеет прямой связи с командой. Во избежание навеваемой образом лидера печали, представим его в образе хорошего предводителя пиратов, способного из команды сделать братство и двинуться к заветным целям. Джек Воробей из «Пиратов Карибского моря» отлично подходит на эту роль, потому что он не использовал жёсткую дисциплину, как другие капитаны, а полагался на своё остроумие и способность убеждать. В критический момент он готов был спасать команду, рискуя собой. Он чтил демократический пиратский кодекс, где решения иногда принимались голосованием. Да, капитан Джек Воробей не забывал о своих интересах, но помогал друзьям в беде и соблюдал моральные принципы, несмотря на риски следования им. Конечно, Джек с его юмором и непредсказуемостью – нестандартный, если не сказать экстравагантный, образец лидера, но тем не менее ведущий к незаурядным результатам. Кроме всего прочего, его ценность в том, что он позволяет нам думать о лидере как о человеке, «правильность» которого, не исключает вкус к жизни и слабости, которые способны подчеркнуть достоинства.

Первый «пит стоп» для осмысления на фоне воспоминаний о Джеке: и в среде «зациклинных» разработчиков, и в азартной пиратской среде, и в любой другой, лидерство имеет одну и ту же природу и структуру. Лидерство слишком величественно и влиятельно, чтобы подстраиваться под отраслевую специфику. Эта мысль нам пригодится в дальнейших размышлениях. Сейчас же сфокусируемся на другом: только сфера IT (говоря об IT мы будем иметь в виду компании, занятые разработкой ПО), обладает максимальной чувствительностью к лидерству (морской «промысел» в Карибском море тоже не будем забывать). Чем это обусловлено?

Преимущества и недостатки разработчиков в контексте лидерства

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

С другой стороны, специалисты в IT демонстрируют к лидерству отрицательную чувствительность, когда выглядят как пациенты, которые убегают при слове «врач». Наиболее продвинутые «айтишники – прогрессисты», окрыленные своим интеллектуальным доминированием, полагают, что они поймали птицу удачи, и часто, забыв о подлинных задачах и болевых точках общества, переоценивают технологии и свои идеи, и воспринимают лидерство как рудимент старого менеджмента. На этом фоне в IT преобладает прохладное отношение к лидерству, которое лишь подчёркивает его актуальность. В подтверждение этому вспоминается случай в 2019 году, когда Джо Байден, будучи ещё деятельным человеком, разругался с айтишниками совершая поездку в Долину. Привожу вольный перевод цитаты Байдена газете Нью Йорк таймс:

«И в какой-то момент один из этих мелких выскочек (little creeps), сидевших за тем столом, — он был почти миллиардером — сказал мне, что он художник, потому что смог придумать игры, которые учат тебя убивать людей… Суть в том, что здесь есть высокомерие, ошеломительное высокомерие, что мы, мы — те самые. Мы можем делать то, что хотим».

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

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

Лидерство – идеальная смысловая среда разработки

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

Упомянутая ранее прогрессивная сущность IT специалиста раскрывается в условиях, позволяющих ему вдохновляться, разделять с коллегами общие цели, опираться на долгосрочную перспективу, вовлекаться в процессы сверх формальных предписаний, испытывать атмосферу доверия и уважения, в конце концов, чувствовать удовлетворение от проделанной работы. А как дела обстоят на самом деле? Зачастую в IT требование к наличию лидерства, которое предопределяет такие условия, упоминается обыденно, через запятую наряду с другими условиями и «мелким шрифтом». Тогда как свойственные организации противоречия возникают автоматически и оглушительно, порождая неприемлемые для «вольнодумцев» из IT артефакты: необъяснимые и противоречивые приказы и приказной тон в принципе; принуждение к бессмысленной работе и авралам из-за необязательных просчетов; сквозящую личную выгоду в решениях руководителя; невнятность практикуемых ценностей и многие другие. В такой парадигме IT компания утрачивает своё место под солнцем быстрее, чем какая-либо другая компания, будучи не в силах достичь инновационный, единственно приемлемый в среде разработчиков результат.

В традиционных отраслях, в которых инновационность это привилегия, а не норма, подобные условия не становятся фатальными, потому что снижение числа степеней творческой свободы сотрудников из-за неблагоприятных условий (назовём это так) компенсируется административным принуждением к труду, снижающим потенциал продукта, но сохраняющим жизнеспособность организации. Таким образом, особенность IT компаний в том, что их способность создавать инновационные продукты связана со спецификой труда их специалистов, не предполагающей возможность их деятельности «в неволе» (в условиях не лидерского управления).

С учётом сказанного, актуальным выглядит запрос на лидеров, которые проявят себя не только в качестве инновационных технократов, но в большей степени в качестве смысловых и культурных архитекторов по отношению к собственной организации. Не стоит забывать также, что лидерство – это не просто деятельность лидера, но и система корпоративных отношений, в которой лидер их инициатор и гарант. Здесь интересно такое наблюдение: в нелидерских технократических компаниях возникает запрос на руководителя, который, обладая какой-то якобы всемогущей методологией и достаточным IQ, решит все проблемы разработки. Образно говоря, они благоволят к фигурам вроде Шерлока Холмса, а не капитана Джека Воробья. Но Холмс - в большей степени блестящий аналитик, консультант или "мозг" операции, чем человек, который мотивирует и объединяет людей.

Лидерство представляет собой культурный код организации, инициируемый лидером, но в зрелом виде уже сам влияющий на лидера и касающийся каждого участника. Лидерство – это не про «начальник-подчиненный», не про «сильный-слабый». Общее должное восприятие лидерства в среде разработчиков выглядит примерно так: «Мы здесь все неглупые ребята, но среди нас есть тот, у кого путь осмысления и развития человеческих отношений (не самая понятная и заманчивая стезя) находит достойный отклик, а мы все, являясь бенефициарами его усилий, признаём его авторитет и первенство». Увлечённость разработчиков творческим поиском, их мудрость, сформированная безалаберностью заказчика, рациональность и здравый смысл, предопределяют их толерантность к принятию лидерства в такой парадигме.

Принятие лидерства в компании означает, по сути, выбор в пользу первой части неизбежной для каждой IT компании дилеммы: или честная попытка достижения незаурядного результата с последующим признанием и сопутствующими ему благами через трудное в реализации лидерство, или, по сути, спекулятивные, захватывающие воображение попытки «поднять» деньги без «обременительного» лидерства и с заурядным результатом на выходе. Если вторая часть дилеммы кажется чрезмерно пессимистичной, то «оптимистам» имеет смысл обратиться к книге И. С. Ашманова «Жизнь внутри пузыря» про события двадцатилетней давности в Rambler. Многие считают, что эта книга про понимание механизмов "пузырей" в IT, упуская из виду главное – эта книга про трудный путь лидерства.

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

Самоорганизация и гибкость как результат лидерства

Не исключено, что найдутся люди, которые после этих объяснений будут продолжать утверждать, что лидерство в таком хлопотном виде излишне. Дескать, процессы разработки могут протекать в гибких, самоорганизующихся командах, где слово лидерство вообще не звучит. Это нереально. Реально то, что организации на основе гибких, самоорганизующихся команд, способные при этом к достижению незаурядного результата, существуют, за редким исключением, только в лидерской парадигме. Чрезмерные надежды в отношении самоорганизующихся команд связаны с ошибочной верой в то, что переход к таким организациям – это лёгкий способ устранения административного и бюрократического управления и освобождение творческого потенциала разработчиков. На самом деле, если такое устранение и происходит, то не автоматически, а за счёт невидимых невооруженным взглядом усилий по развитию культурных и смысловых основ, которые глубоко изменяют саму команду. Такие усилия лидера в конечном итоге не только компенсируют сложности координации и интеграции, возникающие из-за гибкости и автономности самоорганизующихся команд, но и создают условия для синергии взаимодействия. Другими словами, самоорганизующаяся команда в лидерской парадигме – это самостоятельный элемент гибкой структуры с центростремительным характером, тогда как команда в нелидерской среде – это своенравный элемент с центробежным характером. Интересно, как И.С. Ашманов в своей книге охарактеризовал свою команду:

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

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

Легенды о других якобы успешных безлидерских сценариях не верифицируются. Это или уже упомянутые спекулятивные истории (типа «нам достаточно небольших проектов, особенно если за них хорошо платят») или в лучшем случае истории с заурядным тупиковым результатом, как было с Rambler образца 2001 года. Достигаемый в моменте некоторый успех и материальный достаток в подобных проектах не имеют стабильности и перспективы для участников и не открывают оперативный простор для их самореализации в полном психологическом понимании этого слова (по Маслоу). Для руководителя - сторонника нелидерской парадигмы актуальны следующие карьерные риски: а) потратив время на «мучения» в борьбе с мельницами организационных противоречий, изменит свою точку зрения, перейдёт в лидерский стан и получит шанс на самореализацию; б) обретёт материальное благополучие, но останется с длинным, но «пустым» списком проектов по итогам своей деятельности; в) не обретёт ни достойного материального положения, ни признания и, вероятно, покинет сферу IT.

II. Лидерство в контексте методологий DevOps и Agile

Теперь, понимая перспективы лидерства в IT, имеет смысл поговорить о текущем положении лидерства в IT компаниях. Корифеи отрасли заметили созидательную силу лидерства, включив его в такие методологии как DevOps и Agile. Так, например, в основополагающих документах DevOps лидерство подразумевает 4 роли: визионер (задаёт направление), коуч (развивает навыки), фасилитатор (убирает препятствия) и адвокат (защищает культуру от бюрократии). Анализ показывает, что лидерство в этих методологиях не противоречит классическому пониманию лидерства от Джеймса Бернса и Бернарда Басса. Но здесь не всё гладко. Начнём по порядку.

Противоречивость agile-подхода

Идея связать лидерские подходы с инструментарием разработки понятна и направлена на повышение реализуемости DevOps и Agile, которые без лидерства не сработают по тем же причинам, о которых мы говорили выше (низкая мотивация, отсутствие перспективы, проблемы с самореализацией участников и т.д.). Более того, соединение под одной крышей и инструментария и лидерства позволяет обучать и тому и другому, сразу фокусируясь на задачах разработки. Но даже с вниманием к лидерству, как показывают исследования McKinsey, 70% провалов DevOps происходят из-за слабого лидерства, а не инструментов. Так в чём же дело? Главная причина в том, что в методологиях совместили разновеликие и неоднородные вещи: лидерство - один из величайших артефактов управления, имеющий нелинейный характер, требующий пожизненного в него вовлечения, и не имеющий смыслового простора линейный инструментарий гибкой разработки, который является набором полезных практик, осваиваемых в течение нескольких месяцев. Проблема в том, что при практическом применении линейные подходы в силу своей наглядности и доступности, конечно, возобладают над нелинейными, с попыткой сделать всё нелинейное линейным. Другими словами, линейная по характеру методология попытается сделать нелинейное лидерство линейным для упрощенного применения. Показательны слова Д. Хайсмита, одного из гуру agile-практик, сказанные в предисловии к книге «Коучинг agile-команд»:

«Многие так называемые agile-коучи на поверку оказываются просто наставниками, обучающими agile-практиков».

За этими словами читается следующая мысль: настоящий agile-коучинг предотвращает неизбежное выхолащивание agile-подходов. Приведу также пример иного рода из практики компании по найму персонала на agile-должность. При оценке кандидата ему предлагается ответить на вопрос о ценностях Scrum: Какой вариант не является Scrum ценностью? Предлагается четыре варианта: Фокус (Focus), Целостность (Integrity), Смелость (Courage), Обязательство (Commitment). Так вот правильный ответ по мнению работодателя: Целостность (Integrity) не является scrum-ценностью, потому что в ценности Scrum входят: commitment, courage, focus, openness и respect, тогда как integrity не входит в базовый набор. Любому эксперту по лидерству в это трудно поверить, потому что серьезный разговор про лидерство с неизбежным разговором про ценности начинается с целостности (integrity). Перевод этой ценности на запасной путь говорит о некорректной адаптации лидерства для целей Agile. В результате Agile упрощает лидерство и выглядит чрезмерно оптимистичным, как бы «забывая» о непростых в реализации принципах, ради простых, более доступных в Agile-лидерстве.

Лидерство vs Agile-лидерство

В лучших IT компаниях (Microsoft, Apple и т.д.) как правило реализуются методологии DevOps или Agile с соответствующими лидерскими подходами. Возникает вопрос: является ли достигнутое компаниями признание следствием применения Agile или наибольшее влияние оказывает какой-то другой фактор? И ведёт ли использование agile-подходов к трансформации компании, влекущей за собой достижение большого результата? Всё говорит за то, что первопричиной незаурядного результата является старое, доброе лидерство, в том числе, через его способность реализовать весь потенциал методологий типа Agile, т.е. повышать гибкость и адаптивность разработки.

Другими словами, успешное применение Agile достигается полноценным лидерством, сформированным под знаменем ЛИДЕРСТВА, а не Agile-лидерством, сформированным под знаменем AGILE.

Действительно, готовность компании к результату, продиктовано наличием лидеров, способных провести изменения, а не попыткой внедрения методологии при существующих реалиях, хотя бы, потому что методология может быть реализована с разной степенью качества, а лидерство создаёт энергичное, мотивированное отношение ко всему, что происходит в компании, в том числе, ко всем инструментам достижения результата. Лидерство движет процессы развития компании и без agile-наставлений, тогда как Agile, реализованный даже вместе с agile-лидерством, сфокусирован на инструментарии разработки, охватывает лишь часть факторов успеха и не гарантирует незаурядного результата. Другими словами, Agile-лидерство выглядит как «лидерство light» со всеми вытекающим последствиями. В общем, старое доброе лидерство является более фундаментальной причиной для успеха IT компании. «Лайтовость» Scrum лидерства, проявляется, например, в том, что в своей известной книге «Scrum Революционный метод управления проектами» Джефф Сазерленд подчёркивает, что лидеры должны перейти от "Theory X" (контроль и микроменеджмент) к "Theory Y" (доверие, расширение прав и возможностей и лидерство-служение). Правильность направления этой мысли не вызывает сомнения, но при этом известно, что «лидерство – служение» в качестве модели лидерства (которое также предлагает Лисса Адкинс в книге “Коучинг agile-команд”) уступает трансформационному лидерству с точки зрения влияния на результат, а для IT это ключевой вопрос.

Agile без лидерства: «а что так можно было?»

Наставления по Agile говорят о том, что должны делать менеджеры для повышения гибкости и адаптивности организации: дать автономию и доверие, показывать смысл и влияние на пользователей, регулярно давать обратную связь, постоянно улучшать процесс вместе с командой (ретроспективы). Однако они оставляют без внимания главный вопрос: почему эти указания, предполагающие несвойственные большинству менеджеров убеждения и установки, будут реализованы в нужном ключе. Видимо здесь присутствует вера в то, что провозглашенные правильные вещи тут же подхватываются и реализуются. Для реалистов это, случись такое, вызвало бы недоумение: «А что так можно было? Просто сказать, чтобы было сделано?». Для них очевидно, что на практике успешные организационные изменения проводятся по правилам, выкристаллизованным в созидательной практике, когда намерения менеджеров и специалистов продиктованы не придуманными и навязанными извне указаниями, а органически усвоенными ими убеждениями и установками.

Фактически гибкость и адаптивность нужной кондиции – это естественный результат уже проведенной лидером трансформации убеждений участников, создающей благоприятный фон для реализации предложенных agile-принципов. Поэтому требуемый культурный сдвиг организации (это самое меньшее, что можно сделать для обретения гибкости) не д��лжен провозглашаться на «пустом» месте, он должен реализовываться при наличии лидерства и накопленных результатов его влияния на коллектив. Тогда как методологии пытаются представить лидерство как процесс, реализуемый после решения о внедрении Agile, не раскрывая при этом, что же должно стать источником невиданного энтузиазма и упорства менеджеров на всех уровнях для перехода на непривычный для них уклад работы.

Лидерство – это Agile для Agile

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

В силу этого, лидерство – это своего рода Agile для Agile, позволяющее сохранить гибкость гибкой направленности подхода (его целостность).

В модели трансформационного лидерства лидер, институционально наделенный такими свойствами, как парадоксальное мышление, как бы «раскручивает» неизбежно «закручиваемые» организацией парадоксы, в том числе, между требуемой гибкостью в осуществлении замысла и консервативностью структуры исполнения. Сам по себе agile-подход имеет конструктивную основу, но он не спасает организацию от хронических парадоксов и противоречий и не открывает путь для незаурядного результата, потому что agile-лидерству отведена поддерживающая роль для методологии, а не наоборот. Методология пытается уменьшить влияние противоречий регулируя процессы и не уделяя достаточного внимания состоянию умов и сердец участников. Тогда как лидер «раскручивает» парадокс (нейтрализует его влияние), используя и другие лидерские возможности, например, создавая культуру доверия и достоинства, без которых методология не сработает.

Таким образом, есть веские аргументы в пользу того, что организация с лидерством, но без Agile, более продуктивна, чем с Agile, но без лидерства.

Agile создавали технологи-системотехники (для которых лидерство часто находится в слепой зоне) исходя из своих инструментальных предпочтений и теоретического понимания как это должно работать. В идеале agile-подход должен прогрессировать под влиянием лидеров, которые обеспечат верификацию лидерства в первую очередь на верхнем уровне управления и далее вниз до уровня разработчиков в каждом элементе гибкой структуры. Эта мысль подтверждается всё большим числом работ по Agile посвященных человеческому фактору, который необходимо учитывать «вдогонку», чтобы исключить многочисленные провалы внедрения Agile. Например, тот же Джефф Сазерленд в ознаменование 10-летия выхода первой версии своей популярной книги недавно выпустил её новую редакцию, в которой он добавил свои более решительные требования к лидерству среди топ-менеджеров. Получается, что главный фактор достижения незаурядного результата, а именно лидерство, 10 лет ждал своего часа.

Здесь не лишним будет напомнить сделанный выше вывод о том, что лидерство универсально для всех отраслей, в том числе для IT. С учетом этого введённое в оборот agile-лидерство выглядит как альтернатива старому, доброму лидерству, не являясь таковым, что усложнило понимание лидерства. Agile-лидерство необходимо использовать как инструмент для широкого использования на среднем уровне управления в системе распределенного лидерства, но он не заменяет старое, доброе лидерство, особенно на уровне топ-менеджмента, а является его производной.

III. Лидерство в IT. Далеко идущие выводы

Не является ли популярность Agile доказательством чрезмерности приведенной здесь критики? На мой взгляд, нет. Его популярность продиктована интенсивностью развития IT отрасли и актуальной направленностью на обретение ею гибкости и адаптивности.
Выводы, которые уместны с учетом вышесказанного:

1. Лидерство в IT компаниях как способ достижения незаурядного результата актуально и действенно как никогда.

2. Освоение agile-подхода на основе agile-лидерства обеспечивает свой инструментальный вклад в гибкость разработки, но не обеспечивает условия для достижения незаурядного результата, который скрывается за качеством «производственных» отношений в разработке, определяемых уровнем лидерства.

3. Попытка использовать Agile не только не исключает необходимость задействовать лидерство и подготовить лидеров, но и делает это особенно целесообразным.

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

Телеграм канал "Неочевидный лидер"

Лидерство в IT компаниях: невостребованная необходимость