Зачем Agile сотруднику, а не компании?

Более-менее понятно, зачем Agile нужен компаниям. Чаще всего им нужен короткий Т2М и связанные с ним выгоды. Но зачем Agile конкретному сотруднику, мне, вам? Помню, как на одной конференции задавал этот вопрос бывалым Скрам-мастерам и коучам, и многие затруднялись ответить. Позднее я задал этот вопрос на онлайн-митапе международного сообщества – тот же эффект. Постепенно, пункт за пунктом, я всё же собрал список потенциальных выгод, которые сотрудник может извлечь для себя в процессе изменения подхода к работе.

Начнем всё же с компаний. Зачем компаниям короткий T2M?

• Дешевле проверка гипотез, экономия на “неделании ненужного”,
• всегда есть что-то готовое на 100%, поэтому не получится совсем уж провалиться в конце,
  
• и поэтому ситуация прозрачнее – просто потому, что результаты видны,
• раньше получение продуктовой обратной связи от рынка и технической с прома,
  
• проще разворачиваться и менять направление.
  

Ещё Agile подходы помогают повысить:

• согласованность бизнеса и ИТ, сократив разрыв между ними,

• эффективность процесса превращения идей в клиентскую ценность,
• вовлечённость и внутреннюю мотивацию сотрудников.

По крайнее мере это в плане. Но…

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

И вот вы такие приходите и говорите, что он будет более вовлеченным и счастливым (employee engagement, employee happiness, все дела). А он такой: “Серьезно? Так вооот чего мне не хватало для счастья-то!” Ну, неубедительно же.

Однако трансформацию организации возможно произвести, помимо длинного списка предусловий и препятствий, только при изменении поведения работающих в ней людей. А значит, нужно рассказать и показать, как изменения сотрудникам помогут, и убедить в этом. Но…

Давайте поищем что-то поближе к телу.

• "Agile нужен только организации, но не сотрудникам." – Не совсем. Говоря “Agile сотрудникам нужен”, мы подразумеваем: “Сотрудники понимают, зачем им Agile”. Всё больше организаций осознают это, а сотрудники – в меньшей степени, хотя пользы много, и о ней подробнее поговорим ниже.
• "Agile не всем подходит по психотипу. Некоторые хотят просто работать в формате: Я взял задачу и делаю её." – В некоторых Agile-подходах в целом так тоже можно.
• "Agile – для творцов." – Не обязательно. Оно ведь не работает так, что к сотруднику приходят в начале спринта и спрашивают: “Что хочешь делать на этой неделе?” или “Какой результат конкретно ты предоставишь к концу спринта?” Существуют правила, процесс, договоренности, планы, обещания.
• "Если цель сотрудника – сидеть, получать много денег, чтобы его не трогали, и он мог качать скилл, то Agile – его враг, потому что ему будет некомфортно каждый день отвечать на стендапах и вовлекаться в достижение цели, когда он не хочет." Возможно. Здесь уже "for whom how".

Теперь давайте уже обсудим, почему переход к более Agile подходам полезен не только компании, но и сотрудинку.

Eсли компания твердо нацелена на изменения, а увольняться вы не собираетесь, то нам, как сотрудникам, вместо сопротивления можно

Рассмотрим потенциальные выгод для сотрудников в категориях:

1. Карьера

2. Деньги

3. Профессия

4. Результаты

5. Драйв

6. Климат

7. И ещё одна

Если изменения радикальные и процесс изменяется существенно, то будут появляться новые роли (Скрам-мастера) и даже позиции-должности (Владельцы продуктов), и вы сможете воспользоваться этими возможностями.

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

Если новую должность на ближайшем горизонте не видно, то начните с новой роли в текущей должности. В этом случае, когда подвернется возможность, вы будете готовы к этому «one night success».

ИТ отрасль теперь работает так. По сути, Agile – стандарт отрасли.

Если сотрудник не научиться работать по-новому, то станет неконкурентным кандидатом.

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

Становится понятнее, куда можно развиваться. Почему? Обычно команды создают свои Star maps, сопоставляя свои навыки с текущими и планируемыми компетенциями и стеком, необходимыми для продукта. В хорошей Карте компетенций обязательно есть план развития каждого участника команды, включающий конкретные действия: кто, что и как будет делать, чтобы не было bottlenecks. В слаженных командах участники сами выбирают направление развития: "О, давайте я научусь писать автотесты! Подбрасывайте мне простые задачки, пожалуйста."

Если трансформация не только организационная, а комплексная, то охватывает и технологический аспект. В компании будут появляться продвинутые инженерные практики: автоматизация сборки, автотестирование, CI/CD/DevOps. Ведь Agile – это и Scrum (по большей части фреймворк коммуникаций), и набор принципов и ценностей, образ мышления, и более инженерный Extreme programming, и любые подходящие современные практики.

Если вы хотите, чтобы вас подтянули в каких-то скиллах – прекрасно. Ваша команда может стать быстрее-эффективнее.

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

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

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

Появляется возможность создавать качественный продукт. Не просто «соответствующий ТЗ», а прямо крутой. Появляется возможность по-настоящему вовлечься в продукт, получая ОС от пользователей.

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

Представьте, что вы на собеседовании, и вам нужно чем-то похвалиться – ответить, каких крутых результатов вы достигли на предыдущих местах. Вспомнили? Что ответите? “Вот в этой компании и роли Я сделал…” или скорее “Мы с командой сделали. Вот какие крутые штуки…”

Целеполагание становится прозрачнее. Сотрудники лучше понимают:

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

Если ранее все планы приносили вам готовыми, и вы, возможно, реагировали на них, как на "какую-то дичь, которую опять спустили сверху, не посоветовавшись", то теперь появятся понятные короткие планы, созданные с вашим участием – все участники команды участвуют в оценке и Sprint Planning.

Обычно сотрудники не ассоциируют себя с бизнесом. Agile, а точнее – объединение бизнеса и ИТ в одну команду, даёт возможность ИТ-команде быть частью бизнеса. Становится понятнее, ради чего работается работа, и к какой цели стремится команда. И поэтому работать интереснее.

Если не влиять на бизнес, то появляется возможность хотя бы влиять на задачи команды. Возможность выстроить коммуникации с менеджментом и бизнесом, диалог между Product owner и Developers. Возможность дать аргументированный ответ нереалистичным ожиданиям менеджмента, выстроить конструктивную коммуникацию вместо устаревающего формата “заказчик–исполнитель”.

Если не влиять и на задачи команды, то есть возможность хотя бы выбирать себе задачи из бэклога команды.

Появляется возможность выбирать способ реализации. В хорошем варианте процесса никто не указывает вам, как именно выполнять вашу работу (это один из 12 принципов Agile-манифеста). Возможность ИТ отвечать за технику, чтобы бизнес не лез с советами и не требовал скорейшей реализации бизнес-фичей в ущерб качеству.

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

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

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

Product Owner или менеджер не вбрасывает задачи в ходе спринта. В идеале. А если это не так, то нужно чинить процесс. И виноват в этом не Agile – наверняка так было и раньше, и эту привычку ещё не успели исправить.

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

Длинный проект – далёкий дедлайн – большущий результат – большие риски – большой стресс. Вы хотите большой стресс? Надеюсь, что нет. Близкий дедлайн размером в длину спринта и завершенный соответствующий Definition of Done инкремент в конце итерации = ма-а-аленький позитивный стресс. Предсказуемый стабильный процесс поддерживает спокойствие сотрудников. Можно работать стабильно с 9 до 18 без переработок и всё успевать.

Можно не успеть сделать всё запланированное (так часто и бывает), но всё равно предоставить результат – благодаря качественной декомпозиции и регулярным инкрементам.

Переход

• от длинных проектов с большими, непонятными и рискованными ожидаемыми результатами, запутанными коммуникациями, стрессами на последних этапах
• к коротким “мини-проектам” с понятными осязаемыми результатами (спринты с DoD-инкрементами), готовыми к поставке в конце каждой итерации,
  

полезен не только для компании, но и для работающих в ней людей.

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

• Если вы – инициатор/агент изменений, то этот список мотивов поможет вам обосновать пользу своим коллегам.
• Если эти изменения кто-то другой принёс вам, то постарайтесь извлечь пользу для себя. Этим вы