10 лет назад у молодого и зеленого менеджера проекта случился удачный опыт внедрения чего-то похожего на скрам в одной из страховых компании. Энтузиазма хоть отбавляй. Коллеги айтишники всячески поддерживали. Помогало программистское прошлое. Но в какой-то момент появилась непробиваемая стена: Agile подход работал внутри ИТ, но со скрипом воспринимался вне няшного айти пространства. Нужна была синхронизация с другими отделами и смена уклада работы всей компании. Тогда полноценный переход не случился, но год назад удалось воплотить Agile трансформацию на другом проекте в финансовой организации с вовлечением более 100 человек. Возможно ли такое в природе?

1. Проблематика
   1.1 Культура в странах
   1.2 Культура в городах
   1.3 Культура в компаниях
   1.4 ИТ-команды
   1.5 Бизнес-команды
   1.6 Руководители
   1.7 Люди
   1.8 Краткое резюме о проблематике и культуре
2. Немного теории
   2.1 Какие есть фреймворки для Agile трансформаций компаний?
   2.2 SAFe и безопасно ли…
   2.3 LeSS и не мало ли…
   2.4 DaD или хороший папа…
   2.5 Краткое резюме по теории
3. Agile для всей компании на практике
   3.1 Формирование команд
   3.2 PI-планирование
   3.3 Бизнес-команды
   3.4 Различия в командах и подходах
   3.5 Смена парадигмы
4. Нерешенные проблемы и пути решения
   4.1 Скорость изменения людей
   4.2 Пассивные руководители
   4.3 Быстро и качественно, но дорого
   4.4 Рамочки комфортной жизни ИТ-котиков
   4.5 Формализм тоже надо ускорять
   4.6 Региональность
   4.7 Культурные коды и магия присутствия
5. Свет в конце тоннеля

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

Проблематика

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

Культура в странах

Когда мы говорим о странах у нас всплывают образы и штампы по отношению к каждой. Не буду вдаваться в подробности лекций по гуманитарным наукам, но применительно к ИТ это означает, что культурные коды работающие в одной точке мира могут отличаться от другой. Есть государства с постсоветской идеологией. Бывает «плавильный котел» в виде эмигрантских мест, таких как США, Австралия, Новая Зеландия. На Земле есть много других замечательных уникальных областей. Когда Вы берете принцип Agile манифеста, то он неодинаково работает в различных сторонах света. Внутри одной страны может быть разное понимание. К примеру, английское слово privacy в русскоязычном пространстве не используется. А в западном мире на это работают законы, суды, корпоративные правила компаний. 

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

Культура в городах

Чтобы «не растекаться по древу» рассмотрим культуру в большом и маленьком городе. Ритм жизни, понимание времени, отношение к договоренностям все это отличается в разных местах: где-то масштабно, а бывает почти ничтожно. Когда приезжаешь из большого каменного джунгли в уютную и неторопливую провинцию, то ощущаешь другое понимание времени, отношение к работе, деньгам, ценностям. Одним словом невозможно пренебрегать фактом отличия городов. Помню, когда я приехал в Саратов, то удивился, как количество населения не влияет на хорошее состояние ИТ-рынка. В небольшом крае была и конкуренция, и зарубежные заказчики, и работа на региональные крупные компании. Все в одном: и запад, и восток, и государственный сектор. Но это не значит, что каждая точка на карте с 800 тысячами населения также развита в ИТ. Саратов скорее исключение, чем правило. Много примеров отличных ИТ индустрий можно встретить на постсоветском пространстве, где нет больших государственных денег и отсутствуют нефтедолларов. ИТ там «цветет и пахнет».

Культура в компаниях

«… У них правильные, а у нас не те…». К сожалению или к счастью, это тоже не так. Компании бывают разные: транснациональные, отраслевые, продуктовые и другие. Понимая организацию и как она зарабатывает деньги легко добиваться поставленной цели. К примеру в большом городе есть офис стартапа, который следует западным ценностям и культуре предпринимательства. В тот же момент где-нибудь в Нью-Йорке возможно существование консервативной и неповоротливой финансовой организации, которая покажется зарегулированным отголоском прошлого для среднестатической фирмы в постсоветских странах. Мой личный пример, я работал в России в компании с британскими процессами (аудиты, тренинги и прочее). Много людей было с прозападным мышлением. Это классно: не выезжая из страны, работаешь в совершенно другой культуре. Текущий мой проект на технологического гиганта и признанного лидера ИТ в мире. К своему изумлению увидел, что скрам только начинает пробиваться через строгие правила и культуру. Девиз корпорации на текущем проекте: «все свое — от инструментов до процессов». 

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

ИТ-команды

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

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

Другой случай: индийская культура и особенности отношения к ошибкам. Бывает, что коллеги только приехавшие из Индии обвиняют всех, но никогда не признают свой просчет. Это непростое испытание для команды, если надо выяснить истинную причину неудач. Конечно же такой культурный момент можно сгладить, но не быстро. Даже в банке, когда я интересовался неверным информированием, то мне отвечали, что я не знал порядок работы кредитных карт, а оплошность в приложении будет исправлена позже.

Ну и близкое к советской культуре — говорить «правду матку», «рубить с плеча» или отправлять «учить матчасть». 

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

Бизнес-команды

Сложно описать в одно предложение, кто такие бизнес-команды. Отдел продаж не интересует новые подходы или как часто применяется методология разработки в индустрии. Финансисты тщательно считают бюджеты и эффективность вложенных денег. Операционисты не понимает, что архитектура «плохая», а вот если на поддержание решения нужно еще 20 программистов для запуска продукта, то это вызывает вопросы и уточнения. Команды вне ИТ скептически относятся к спринтам, итерациям и прочим инкрементальным вещам. Более понятные мотиваторы: ежеквартальные премии, бухгалтерская отчетность, KPI по продажам. Часто бизнес оперирует датой выполнения (дедлайн). Не будем спускаться в холивар про предсказуемость «выкладки кода на бой» и творческую природу ИТ. Тем не менее, понимая нужды бизнеса можно точнее выстроить процесс работы, который будет полезен всем заинтересованным сторонам.

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

Руководители

Начальники, директора, проектные и программные менеджеры, а еще и владельцы продуктов. И это не полный список разных интерпретаций тех, кто принимает решение. Один из факторов для смены культуры в организации — это перестройка работы топ-менеджмента. И здесь мы говорим не про переписывание устава и формальное переименование «разбора полетов» в «ретроспективу», а про то, как управленцы понимают свою роль. Один из безобидных примеров: опытный менеджер, который не мешает развертыванию Agile фреймворка, но и не вовлекается на 100%. Этот подход не сработает, так как в определенный момент руководитель должен быть судьей или катализатором или даже драйвером новаций. Само по себе в жизни не работает. Нужно усилие и поддерживание процесса, метода или культуры. Данное утверждение справедливо и для Agile мышления. Еще один пример: тиранический стиль управления в западной фирме. Такое встречается нередко, но главная особенность, что после ухода «кнута» дисциплина в компании падает, а это влияет на прибыльность.

Люди

Программы реализовываются инженерами, картины рисуются художникам, небоскребы возводятся строителями. Мы все разные. У каждого личный опыт, свое критическое мышление и особое видение теории и практики. Так же мы изменчивы во времени, мы забываем обсуждения недельной давности или что-то из прошлого (эффект Манделы). Люди допускают ошибки, мы зависимы от погоды, кто-то делает много и быстро, другие создают мало, но критически важное для команды. Находясь в одном коллективе мы приобретаем что-то общее и верим в похожие идеалы. Мы привносим наш опыт в каждый проект, обогащая его своим навыками и практиками коллег, с которыми мы работаем. Все это — еще одна дополнительная большая трудность для внедрения нового подхода. Иногда намного проще взять студента и переучить под работу в компании, чем нанять крутого профессионала и попытаться «перековать» под корпоративные стандарты. Кто-то продолжает учиться до старости, а некоторые останавливается в 25 и дальше работают «на рефлексах». Другие всегда полагаются на интуицию. Люди — необыкновенный феномен с точки зрения развития и обучения. Это не компьютер, которому сказал и он воспринял новый фреймворк без интерпретаций. У человека будет первая производная или вариация на теорию, личный опыт и как оно складывается в конкретной команде. 

Краткое резюме о проблематике и культуре

Я попытался только немного охватить составляющие, которые необходимо учесть при выстраивании Agile в организации. Согласно вышесказанному, методология или фреймворк должны учитывать отличие стран, городов, компаний, команд и людей. Те, кто внедряют новое мышление, обязаны представлять себе объем усилий. Человеческая коммуникация критичнее инструментов разработки, баз данных и других составляющих. Если Вы немного углубитесь в психологию, то найдете разные оценки по «переучиванию» или формированию личности. Этот процесс может длиться от 2 до нескольких лет ежедневной работы с человеком. Что достижимо, когда мы большую часть своей жизни проводим в компании. Но такой переход точно не может состояться за 1-2 дня или даже 1-2 месяца. Необходимо изменение в рамках всей организации на протяжении внушительного периода времени.

Немного теории

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

Какие есть фреймворки для Agile трансформаций компаний?

Как я упомянул в начале статьи одной из проблем перестройки мышления с директивного на гибкое является повсеместное внедрение Agile практик. То и есть не только использование Скрам в конкретной ИТ команде, а изменение всех отделов, в том числе работы директора компании, на «новые рельсы». Для осуществления таких практик есть ряд решений.

SAFe и безопасно ли...

Спасибо boblenin за краткий экскурс про фреймворк. Когда я впервые столкнулся с SAFe оказалась полезной статья с фотографиями и объяснением «на пальцах», что есть SAFe. Отдельное спасибо и всяческого хабродобра rsn81. Если кратко, то SAFe — это об внедрении Agile подходов не только в ИТ, но и во всей организации.

LeSS и не мало ли…

Помимо SAFe есть и другие подходы. Второй пример — это LeSS с идеологией минималистичности. Общая идея — меньше правил и фокус на использовании экспертизы команд. Звучит интересно, учитывая различия в культурах, знаниях и понимании. Спасибо myIDddv за освещение данного подхода.

DaD или хороший папа…

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

Краткое резюме по теории

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

Agile для всей компании на практике

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

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

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

Формирование команд

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

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

PI-планирование

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

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

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

Бизнес-команды

Одним из больших плюсов планирования было то, что бизнес  присутствовал на протяжении всего мероприятия. Детализация заданий происходила мгновенно. Быстро выявлялись проблемы, которые не несли прибыли для компании. Всплыло много задач, добавленных в результате политических интриг, но далеких от достижения показателей фирмы. Такие постановки улучшали работу конкретного человека, в то время как отдел мог продолжать «зашиваться» или продукт не приносить прибыль. Хочу отметить классную попытку внедрения KPI и OKR. Взяли практики, которые отлично зарекомендовали себя на западе и пытались приспособить в новой реальности. Для ИТ и бизнеса это был правильный вектор устремления в одном направлении. К моменту внедрения фреймворка заказчик «оголодал» до того, чтобы «у него спрашивали». И когда команды стали интересоваться «что нужно для продаж», то коллеги с радостью делились всеми деталями и проблемами, которые мешают достигать целей. Это помогало правильно сфокусироваться на задаче. В прошлом была выстроена линия, когда аналитики «спускали» то, как оно будет работать. Но почему-то отсутствовал момент обратной связи от самих заказчиков. Люди всегда рады поделиться потребностями и болями. Отдельный вопрос — это распознать проблемы и трансформировать в понятную постановку и реализацию.

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

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

Различия в командах и подходах

Участники PI-планирования имели свое собственное понимание SAFe. По-разному воспринимались одни и те же практики. SAFe гибок в отношении поддержки вариаций. К примеру, была возможность каждой команде создать свой цикл разработки и  онлайн-борды для отслеживания задач. Кто-то добавлял колонки «Код Ревью» и прочие, а другие делали минималистично «Открыто», «В процессе», «Готово». 

Еще различие: критерии выполнения задачи (Definition of Done). У команды была возможность разработать свой уровень детализации. Кто-то добавлял пункт по доставке продуктов на боевую среду, другие использовали модель проще, так как они создавали только прототипы.

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

Смена парадигмы

Одним из плюсов на проекте было то, что директор компании присутствовал на вступительной речи и открытии PI-планирования. По опыту проведения прошлых мероприятий был случай, когда генеральный обошел все доски с планами задач и за 3-4 часа до конца работы «зарубил» несколько больших постановок, так как не нашел полезности в том, что собиралось реализовываться. Пришлось заново планировать, обсуждать, выявлять требования. С другой стороны правильный и своевременный сигнал сэкономил деньги компании. В иных условиях все могло произойти печальнее. Команда бы потратила 1-2 месяца своей работы и уже пришлось бы «положить под сукно» большие финансовые потери. Такие примеры катастрофически влияют на мотивацию внутри коллектива и как следствии прибыльность компании.

Неизвестно поменял ли директор благодаря новому подходу свой стиль управления. Но для главы организации это был прагматичный ход использования новых методологий по достижению прибыльности и других показателей. Дополнительный плюс — понятный способ отчитаться перед инвесторами.

Смена парадигм для коллективов давалась тяжело. Были многие, кто работал годами «по водопаду», другие использовал свой «Как бы скрам». Третьи пытались найти «сильного плеча». Было любопытно, когда выделенные команды тестирования продолжали работать «по старинке» с полугодовыми релизами, с устоявшимися долгоиграющими процессами. А здесь пришла скорость изменений такая, что было трудно представить. 25 команд одномоментно начали вносить код и доставлять его на боевую. При том, что сроки, которые оговаривались на планировании подразумевали релизы минимум раз в месяц, а то и чаще. Тоже касалось и бизнес-команды. Если раньше у них было полгода на то, чтобы научить, рассказать и использовать, то в изменившихся условиях «мяч оказался на их стороне». Бизнес стал «узким горлышком» в прибыльности компании. Более того уже через месяц «прилетала» новая порция изменений на боевую среду. Это было испытанием на прочность. 

Суммируя, я не увидел что команды и бизнес стали одновременно гибким во всем. Но когда я раскладывал по полочкам Agile и культуру, то было очевидно, что для этого изменения нужны годы. Люди должны захотеть «жить по-новому». Это не происходит в одночасье. Можно поиграть в гибкость на работе, но когда ты возвращаешься домой, идешь в магазин или сталкиваешься с другой картиной мира в паспортном столе, больнице, уже тяжело дать росткам Agile культуры расти быстро и без остановки. Плюс к этому всему можно добавить возрастную инертность. Чем мы старше, тем менее восприимчивы к новому. Гибкость это про поиск совершенства, даже когда все идет хорошо и без ошибок.

Нерешенные проблемы и пути решения

Скорость изменения людей

Одной из главных причин, почему какой-то процесс тормозится или не дает ожидаемых результатов — это люди. При внедрении SAFe с участниками работали много. Но отсутствовала индивидуальная система обучения и подготовки. Высокое напряжение выливалось в клинические случаи. Причем речь идет не только о психологических расстройствах, но и общее обострение здоровья на нервной почве. Не все выдерживают 2-х дневное мероприятие с большим количеством народа, где надо много взаимодействовать. Кто-то не готов к напряженному темпу работы в течении 1-2 месяцев. Был заметен «провал» в теории и понимании Agile подходов. Общий вывод: SAFe не для всех. Исходя из этого необходимо подбирать людей на позиции, где критически важно обмениваться информацией (экстраверты скрам-мастера; бизнес открытый к коммуникации, а не под давлением выдающий из себя что-то неясное). Если стоит задача внедрить Agile в консервативной организации, то скорее всего этого не получится быстро. Более реалистично представлять себе это эволюционным процессом, где ведется внушительная работа по обучению людей на протяжении нескольких лет. Один из способов решения проблемы — это изначальное формирование коллектива под потребности Agile.

Пассивные руководители

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

Быстро и качественно, но дорого

Бизнес-команды должны формироваться с учетом активного взаимодействия внутри организации. Если менеджер закрывает план (по продажам, проводкам, отчетности и прочее), то все остальное его уже не интересует. Без плотной коммуникации ИТ и других отделов фирмы успех невозможен. Распространенная ситуация, когда коллега «напродавал», получил премию за квартал и … уволился. А операционистам и ИТ-отделу необходимо «разгребать», потому что на кону прибыль, репутация и прочее. Каждый должен понимать золотое правило трех: качество, время, деньги. Можно продать «закрутить гайки» или «заставить всех шевелиться», но соотношение факторов останется неизменным. Вроде бы избитый пример, но до сих пор встречаются подтверждения полного непонимания основ. Быстрый способ для объяснения  — это аналогия покупок в магазине. Если у Вас фиксированная сумма, то Вы получите строго определенный набор продуктов. Можете поиграться с качеством и количеством, но пропорция остается неизменной. По моей практике многие вопросы отпадут сами по себе.

Рамочки комфортной жизни ИТ-котиков

ИТ-команды не готовы к активной коммуникации. Во время SAFe я встречал такие ожидания: «дайте задачу с ТЗ, тогда мы ее реализуем». Возможно я ошибаюсь, но гибкость предполагает постоянный поиск способов улучшить качество, объем выполняемых работ и открытость к разным постановкам. Другими словами задание может прийти в большом документе или в виде пары строк в excel-файле. К любому способу необходимо быть готовым. Еще пример — это универсальность в команде. Многие не воспринимают расширение ответственности в ту или иную сторону. Каждый рисует круг обязанностей  для себя и коллег. А дальше требуют соблюдения своего шаблона. Это не корректно. Задачи не приходят равномерно, объем работ каждого тоже не идеален. Более гибко и нормально, когда тестировщик на 15% программист или разработчик кроме компиляции на своей машине еще и (да что же это такое творится!?) делает первичную проверку функционала на другой среде. В моей практике случалось, когда аналитик забывал про свои обязанности и помогал тестировщику, так как тот «зашивался» перед релизом. Мгновенного решения тут не будет. Людям удобно жить и работать «в рамочках». Возможно постоянное расширение зоны комфорта повлияет на желание помочь. Для скрам-мастера необходимо дополнительно отслеживать загрузку каждого в команде. В итоге это позитивно скажется на психологическом климате в коллективе. 

Формализм тоже надо ускорять

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

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

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

Региональность

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

Культурные коды и магия присутствия

Я работаю на проекте, где происходит пересечение на уровне 3-4 стран: Америка, Европа, Азия. К тому же Калифорния сама по себе многонациональна. Здесь есть культурные коды со всех уголков планеты. С этим приходится работать и учитывать. Как? Расширенные вступительные разговоры на дейликах, переписка не по теме, тренинги, форумы. Лучше всего беседы за чаем с коллегами и обмен опытом. 

Помню заманчиво звучало слово «удаленка». Сразу представлялись пальмы и пляж. После 3 месяцев в режиме «криптокачевника» осознал все плюсы и минусы. Для единения нужен очный контакт. Магия присутствия работает на хакатонах, в офисах и кафешках. Но тяжелее этого добиться удаленно. Ученые нашли часть мозга, которая активируется при физическом наличии других коллег по команде. Это объясняет, почему присутствие кого-то рядом, ускоряет решение задачи по сравнению с тем, если делать самому. 

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

Свет в конце тоннеля

Обновление фреймворков происходит стремительно и параллельно придумывают новые. Появляются сертифицирующие компании и целый бизнес на эту тему. Салфетка и карандаш появились в начале и они могут быть вписаны в новые подходы разработки. Более того, отсутствие документа требований не означает, что после внедрения его не надо готовить. Углубляясь в теорию, заметно разделение мира на две части: плановая и изменчивая. В наше время каждой из них придумывают новые маркетинговые названия, но 10, 20 и 30 лет назад были последователи правил и те, кто адаптировался под изменения. Новые идеи могут оказаться переработкой практик прошлого. Не стоит становиться частью какого-то лагеря. Лучше использовать то, что подходит под конкретный проект и компанию. 

Мы прошлись по аспектам, которые необходимо учитывать при изменении мышления на уровне организации. Сухо отвечая на вопрос «Возможен ли Agile для всей компании?» — «Да», но с большим количеством но. В этих оговорках будет спрятан процесс по изменению мышления человека, структуры организации, выбора города, офиса или даже смены страны для всей фирмы. Если не учитывать этого, то можно потратить кучу энергии на изменение, которое не под силу государствам. Если выбрать правильное место и команду, то успех будет на Вашей стороне. Вам не придется пробивать стену там, где она имеет большое сечение. Возможно, это ответ, почему многие организации создают правильную атмосферу внутри компании. Человек находится в экосистеме: любимое дело, досуг, отдых, хобби, знакомые, друзья — все связано с работой. Это один из возможных способов, когда создается микромир и не тратятся силы на изменения городов, стран и континентов.