Зачем Agile сотруднику, а не компании?
Более-менее понятно, зачем Agile нужен компаниям. Чаще всего им нужен короткий Т2М и связанные с ним выгоды. Но зачем Agile конкретному сотруднику, мне, вам? Помню, как на одной конференции задавал этот вопрос бывалым Скрам-мастерам и коучам, и многие затруднялись ответить. Позднее я задал этот вопрос на онлайн-митапе международного сообщества – тот же эффект. Постепенно, пункт за пунктом, я всё же собрал список потенциальных выгод, которые сотрудник может извлечь для себя в процессе изменения подхода к работе.
Начнем всё же с компаний. Зачем компаниям короткий T2M?
- Дешевле проверка гипотез, экономия на “неделании ненужного”,
- всегда есть что-то готовое на 100%, поэтому не получится совсем уж провалиться в конце,
- и поэтому ситуация прозрачнее – просто потому, что результаты видны,
- раньше получение продуктовой обратной связи от рынка и технической с прома,
- проще разворачиваться и менять направление.
Ещё Agile подходы помогают повысить:
согласованность бизнеса и ИТ, сократив разрыв между ними,
- эффективность процесса превращения идей в клиентскую ценность,
- вовлечённость и внутреннюю мотивацию сотрудников.
По крайнее мере это в плане. Но…
зачем Agile любому отдельному конкретному сотруднику?
Вот работает он себе, работает в функциональных отделах и проектах. Линрук защищает его от пиэмов, а пиэмы борются за лучших сотрудников для своих проектов. Результаты стандартизированы, проекты разнообразные.
И вот вы такие приходите и говорите, что он будет более вовлеченным и счастливым (employee engagement, employee happiness, все дела). А он такой: “Серьезно? Так вооот чего мне не хватало для счастья-то!” Ну, неубедительно же.
Однако трансформацию организации возможно произвести, помимо длинного списка предусловий и препятствий, только при изменении поведения работающих в ней людей. А значит, нужно рассказать и показать, как изменения сотрудникам помогут, и убедить в этом. Но…
зачем сотруднику менять то, что и сейчас вполне ок?
Давайте поищем что-то поближе к телу.
Некоторые установки, верные не всегда
- "Agile нужен только организации, но не сотрудникам." – Не совсем. Говоря “Agile сотрудникам нужен”, мы подразумеваем: “Сотрудники понимают, зачем им Agile”. Всё больше организаций осознают это, а сотрудники – в меньшей степени, хотя пользы много, и о ней подробнее поговорим ниже.
- "Agile не всем подходит по психотипу. Некоторые хотят просто работать в формате: Я взял задачу и делаю её." – В некоторых Agile-подходах в целом так тоже можно.
- "Agile – для творцов." – Не обязательно. Оно ведь не работает так, что к сотруднику приходят в начале спринта и спрашивают: “Что хочешь делать на этой неделе?” или “Какой результат конкретно ты предоставишь к концу спринта?” Существуют правила, процесс, договоренности, планы, обещания.
- "Если цель сотрудника – сидеть, получать много денег, чтобы его не трогали, и он мог качать скилл, то Agile – его враг, потому что ему будет некомфортно каждый день отвечать на стендапах и вовлекаться в достижение цели, когда он не хочет." Возможно. Здесь уже "for whom how".
Теперь давайте уже обсудим, почему переход к более Agile подходам полезен не только компании, но и сотрудинку.
Причины, почему Agile полезен сотруднику
Eсли компания твердо нацелена на изменения, а увольняться вы не собираетесь, то нам, как сотрудникам, вместо сопротивления можно
извлечь из изменений выгоду для себя.
Рассмотрим потенциальные выгод для сотрудников в категориях:
1. Карьера и рост
Если изменения радикальные и процесс изменяется существенно, то будут появляться новые роли (Скрам-мастера) и даже позиции-должности (Владельцы продуктов), и вы сможете воспользоваться этими возможностями.
Наверняка будут проводиться полезные тренинги. Участвуйте в них активно, а не «для галочки». Задавайте тренерам насущные прикладные вопросы, впитывайте информацию. Получайте или находите новые инструменты и шаблоны, пробуйте применить их в своей команде.
Если новую должность на ближайшем горизонте не видно, то начните с новой роли в текущей должности. В этом случае, когда подвернется возможность, вы будете готовы к этому «one night success».
ИТ отрасль теперь работает так. По сути, Agile – стандарт отрасли.
Будущее уже наступило, просто оно ещё неравномерно распределено.
Если сотрудник не научиться работать по-новому, то станет неконкурентным кандидатом.
2. Деньги и влияние на них
В хорошем случае (не всегда) при настройке правил премирования становится прозрачнее, за что каждый получает премию. А если ваша команда не только про «работу работать», а ещё и прокачает продукт и покажет это на метриках, то сможете задать тренд в своей компании и повлиять на систему мотивации.
3. Профессия и выбор направления развития
Становится понятнее, куда можно развиваться. Почему? Обычно команды создают свои Star maps, сопоставляя свои навыки с текущими и планируемыми компетенциями и стеком, необходимыми для продукта. В хорошей Карте компетенций обязательно есть план развития каждого участника команды, включающий конкретные действия: кто, что и как будет делать, чтобы не было bottlenecks. В слаженных командах участники сами выбирают направление развития: "О, давайте я научусь писать автотесты! Подбрасывайте мне простые задачки, пожалуйста."
Если трансформация не только организационная, а комплексная, то охватывает и технологический аспект. В компании будут появляться продвинутые инженерные практики: автоматизация сборки, автотестирование, CI/CD/DevOps. Ведь Agile – это и Scrum (по большей части фреймворк коммуникаций), и набор принципов и ценностей, образ мышления, и более инженерный Extreme programming, и любые подходящие современные практики.
Если вы хотите, чтобы вас подтянули в каких-то скиллах – прекрасно. Ваша команда может стать быстрее-эффективнее.
Если хотите быть не ведомым, а ведущим = выбирать и определять инструменты и технологии – тоже прекрасно. Во времена изменений у вас появится возможность продвигать новые технические решения.
Потребность в развитии — черта, заложенная эволюцией. При командной работе сложнее филонить. Для ленивых и желающих отсидеться ежедневные встречи, на которых прогресс команды и каждого становится прозрачным – нежелательная практика. Но для тех, кому динамичная среда помогает оставаться в тонусе – большой плюс.
Прокрутите свой прошлый опыт и жизнь в целом. Наверняка были годы спокойной работы, но кроме спокойствия больше и вспомнить нечего. А было и динамичное время, и заметьте, что субъективно оно кажется длиннее – просто потому, что насыщено событиями.
4. Результаты рабочие и личные
Появляется возможность создавать качественный продукт. Не просто «соответствующий ТЗ», а прямо крутой. Появляется возможность по-настоящему вовлечься в продукт, получая ОС от пользователей.
Конечно, на многих должностях и одиночная работа приносит пользу. Но в ИТ работа командная, потому что в одиночку сложно создать существенную ценность (можно, но командой получится круче).
Представьте, что вы на собеседовании, и вам нужно чем-то похвалиться – ответить, каких крутых результатов вы достигли на предыдущих местах. Вспомнили? Что ответите? “Вот в этой компании и роли Я сделал…” или скорее “Мы с командой сделали. Вот какие крутые штуки…”
5. Мотивация и драйв из-за влияния на задачи
Целеполагание становится прозрачнее. Сотрудники лучше понимают:
А зачем мы это делаем?
И поэтому сильнее вовлекаются в достижение общих целей. Появляется несколько уровней влияния на цели. И какой-то из них – ваш. Есть вы – участник Agile-команды, то сможете влиять на выбор Цели спринта и Цели продукта и их формулировки.
Если ранее все планы приносили вам готовыми, и вы, возможно, реагировали на них, как на "какую-то дичь, которую опять спустили сверху, не посоветовавшись", то теперь появятся понятные короткие планы, созданные с вашим участием – все участники команды участвуют в оценке и Sprint Planning.
Обычно сотрудники не ассоциируют себя с бизнесом. Agile, а точнее – объединение бизнеса и ИТ в одну команду, даёт возможность ИТ-команде быть частью бизнеса. Становится понятнее, ради чего работается работа, и к какой цели стремится команда. И поэтому работать интереснее.
Если не влиять на бизнес, то появляется возможность хотя бы влиять на задачи команды. Возможность выстроить коммуникации с менеджментом и бизнесом, диалог между Product owner и Developers. Возможность дать аргументированный ответ нереалистичным ожиданиям менеджмента, выстроить конструктивную коммуникацию вместо устаревающего формата “заказчик–исполнитель”.
Если не влиять и на задачи команды, то есть возможность хотя бы выбирать себе задачи из бэклога команды.
Появляется возможность выбирать способ реализации. В хорошем варианте процесса никто не указывает вам, как именно выполнять вашу работу (это один из 12 принципов Agile-манифеста). Возможность ИТ отвечать за технику, чтобы бизнес не лез с советами и не требовал скорейшей реализации бизнес-фичей в ущерб качеству.
При таком подходе мы ощущаем себя не просто винтиками в системе, а винтиками со смыслом и целью – мы видим, зачем трудимся, видим результаты своей работы и гордимся ими, благодаря обратной связи, понятным целям, вовлеченности.
6. Климат в команде
Участники Agile-команд могут выбирать, с кем работать. Кончено, это изменение происходит не по щелчку пальцев, а эволюционно, но всё же происходит. Всё чаще в процессе найма внешнего или внутреннего появляются беседы кандидата со всей командой. И полезно и для команды, и для кандидата – они обоюдно выбирают друг друга.
Позитивный сдвиг от должностей к ролям, а затем от ролей сотрудников к компетенциям всей команды повышает взаимовыручку и поддержку, и улучшает общую атмосферу работы.
Скрам – остров стабильности в океане хаоса.
Product Owner или менеджер не вбрасывает задачи в ходе спринта. В идеале. А если это не так, то нужно чинить процесс. И виноват в этом не Agile – наверняка так было и раньше, и эту привычку ещё не успели исправить.
Если я один отвечаю за свою часть, если у нас фабрика, то вряд ли ощущается какой-то командный дух. В хорошем процессе я не просто отправлю код тестировщику, а спрошу его, на что он обратит внимание, в какой момент мне ему сообщить, уточню о готовности сценариев. В сплоченной команде работается приятнее и легче.
Длинный проект – далёкий дедлайн – большущий результат – большие риски – большой стресс. Вы хотите большой стресс? Надеюсь, что нет. Близкий дедлайн размером в длину спринта и завершенный соответствующий Definition of Done инкремент в конце итерации = ма-а-аленький позитивный стресс. Предсказуемый стабильный процесс поддерживает спокойствие сотрудников. Можно работать стабильно с 9 до 18 без переработок и всё успевать.
7. Быть красавчиками
Можно не успеть сделать всё запланированное (так часто и бывает), но всё равно предоставить результат – благодаря качественной декомпозиции и регулярным инкрементам.
Итого
Переход
- от длинных проектов с большими, непонятными и рискованными ожидаемыми результатами, запутанными коммуникациями, стрессами на последних этапах
- к коротким “мини-проектам” с понятными осязаемыми результатами (спринты с DoD-инкрементами), готовыми к поставке в конце каждой итерации,
полезен не только для компании, но и для работающих в ней людей.
Конечно, можно включить скептика и разнести в пух и прах все многие пункты выше. Я их привел не для разделение на черное и белое, а чтобы помочь каждому участнику найти в процессе изменений позитивное для себя.
- Если вы – инициатор/агент изменений, то этот список мотивов поможет вам обосновать пользу своим коллегам.
- Если эти изменения кто-то другой принёс вам, то постарайтесь извлечь пользу для себя. Этим вы
поможете и себе, и компании!
Ну вообще waterfall куда более прогнозируемый и эффективный, если его грамотно готовить. Agile нужен там где много неопределенности и/или не хватает компетенций.
Всё так! 👍🏼Я старался ответить на вопрос: «Если компания решила переходить к итеративно-инкрементальному подходу в продуктовой организационной структуре, то какую пользу в этом может найти сотрудник?»