Agile строится на многих идеях (Кайзден, Lean, канбан и т.д). Но одним из наиболее важных аспектов является совокупность исследований человеческой мотивации. В этой статье я рассмотрел некоторые их этих идей и подчеркнул, что очень легко применять Agile, но упускать из виду эти мотивационные факторы.
Я часто спрашиваю организации, почему они хотят внедрить Agile, и все ответы сводятся к желанию повысить производительность. Они могут говорить, что хотят снизить эксплуатационные расходы, ускорить выполнение проектов, сократить время выхода продукта на рынок или просто последовать примеру остальных компаний. Они не хотят остаться позади. По сути, все это о производительности.
И действительно, название одного из ключевых трудов по Scrum звучит как «Искусство делать вдвое больше работы за половину времени» Джеффа Сазерленда (2014). В этой книге рассказывается об увеличении производительности на 400% (на обратной стороне книги указано «на 400-800%». Ожидания от этого весьма повышаются.
Еще один вопрос, который я задаю организациям, заключается в том, почему они считают, что использование Agile повысит их производительность. Именно здесь разговор порой и заканчивается. Я видел, как многие компании относятся с большим энтузиазмом к азам Agile – ежедневным стендапам, спринтам, пользовательским историям и т.д. не отдавая себе отчета, почему выполнение этих действий приведет к значительному повышению производительности.
Руководство по Scrum учит нас что делать, но не зачем это нужно. Одна из многих причин, по которой есть смысл использовать Agile, заключается в том, что он использует человеческую мотивацию и опирается на мотивационные теории, восходящие к 1940-м годам.
Абрахам Маслоу и мотивация
Маслоу часто считают отцом-основателем этих теорий мотивации. Каждый из нас слышал о его пирамиде потребностей:
Теория гласит, что люди сначала удовлетворяют свои потребности в выживании (физиологические – еда, вода, тепло, жилье). Только после этого они продолжают поднимать выше по пирамиде, где находятся чувство принадлежности к группе, уважение и полная реализация своего потенциала.
Маслоу, трудившийся в 1940-х годах, предполагал, что большинство организаций мотивировали своих сотрудников, сосредоточившись только на двух нижних уровнях пирамиды, удовлетворяя их потребности в выживании и безопасности зарплатами, бонусами, медицинским обслуживанием, пенсиями и т.д. Он утверждал, что руководители могли бы лучше мотивировать своих сотрудников, если бы охватывали все уровни пирамиды.
Мотивация с помощью Agile-команд
Итак, каким образом Agile удовлетворяет потребности верхних уровней пирамиды? Ответ кроется в концепции Agile-команд. Команды в Agile самоорганизуются и управляются автономно, то есть «решают внутри себя, кто что, когда и как делает» (Руководство по Scrum). Эта автономия несет в себе чувство принадлежности.
Agile-команды являются кросс-функциональными. В Agile-команде могут легко уживаться дизайнеры, архитекторы, бизнес-аналитики, разработчики и тестировщики. Каждый член команды имеет решающее значение для создания чего-то ценного в каждом спринте. Таким образом, каждый член команды закрывает потребность в уважении, зная, что его навыки, творческий потенциал и динамизм играют решающую роль в успехе проекта.
Сравните это с компаниями, в которых команды объединяются по функциям, то есть отдельно аналитики, тестировщики, программисты и т.д. В такой структуре разработчики могут создавать продукт, который на самом деле не понимают, а тестировщики могут писать тест-кейсы, не испытывая никакого чувства причастности к достижению цели.
У Agile-команды есть общая цель и желание ее достигнуть. Члены команды могут гордиться тем, что работают вместе, создавая что-то ценное. Каждый член команды знает, что его навыки имеют решающее значение при создании ценности.
Дуглас Макгрегор – Теории X и Y
Макгрегор, ученик Маслоу, развил теорию мотивации. Он предположил, что стили управления, как правило, соответствуют либо Теории X, либо Теории Y.
Теория Х построена на гипотезе о том, что люди по своей примере ленивы и работают только для того, чтобы получать зарплату. По этой причине менеджеру приходится постоянно пинать членов своей команды, чтобы они не расслаблялись. Стратегии кнута и пряника часто используются для того, чтобы подтолкнуть сотрудников к достижению поставленных целей. Управление по Теории X базируется на контроле.
Тогда как Теория Y построена на том, что сотрудники могут находить удовлетворение в своей работе и в том, что работа – естественная человеческая активность. Так по Теории Y менеджер должен создать структуру, в которой люди могут работать для достижения поставленных целей. Они доверяют своим сотрудникам и дают им возможность работать автономно.
Учитывая все, что мы знаем об Agile, трудно привести его в соответствие с теорией X. Мы знаем, что Agile-команды работают автономно, они наделены полномочиями принимать важные решения о том, как выполнять работу. Мы знаем, что основные ценности Scrum – это целеустремленность, сосредоточенность, открытость, уважение и смелость. Мы знаем, что Scrum-мастера – это лидеры-слуги. Они не руководят проектами и не назначают элементы действий членам команды.
Становится очевидно, что Agile больше согласуется с Теорией Y.
Дэниел Пинк – самостоятельность, мастерство и целеустремленность
Теорию мотивации Пинка можно выразить в двух предложениях: «Большие поощрения приводят к меньшим результатам» и «настоящие мотиваторы – это автономия, мастерство и целеустремленность».
В своем выступлении на TED в 2009 году (https://www.ted.com/talks/dan_pink_the_puzzle_of_motivation#t-1099082) Пинк рассказывает о различных экспериментах, которые опровергают идею о том, что, если вы будете вознаграждать людей финансовыми мотиваторами, они станут работать лучше и быстрее. На самом деле эксперименты показали обратное: финансовые вознаграждения заставляют людей работать медленнее, потому что они подавляют креативность. (Есть только одно исключение, финансовое вознаграждение может работать для повторяющихся, механических задач, которые требуют мало размышлений или креативности.)
Его три фактора мотивации хорошо вписываются в структуру Agile.
Автономность: Как было сказано выше, Scrum-команды автономны и уполномочены принимать важные решения о том, как делать свою работу.
Мастерство: Scrum-команда многопрофильна и кросс-функциональна. Каждый ее член обладает навыками, которые имеют решающее значения для создания ценности в каждом спринте. Каждый член команды должен быть профессионалом или экспертом в своей области.
Цель: Сазерленд говорит о великих командах как о «трансцендентных». Другими словами, у них есть цель достичь чего-то экстраординарного, что выходит за рамки их собственных горизонтов.
Другие исследователи (такие как Герцберг, Райан и Деци и Макклелланд) писали на аналогичные мотивационные темы.
Что может пойти не так?
Проблемы возникают, когда организации внедряют Agile и забывают о мотивации. На диаграмме ниже показан худший сценарий:
Некоторые называют эту модель Wagile, а другие Water-Scrum-Fall. Как бы мы это не называли, все упирается в контроль.
У нас есть уровень управления, который определяет объем, сроки и бюджет проектов на высшем уровне. Они делают это так, как делали всегда, а конкретно: генерируют процессы приоритезации и следуют им, создают кейсы ценности, проводят анализ рентабельности и так далее.
Объем, временные рамки и модели предоставления ресурсов передаются Agile-командам для продолжения работы. После завершения проектов руководство осуществляет мониторинг, контроль и, при необходимости, принимает корректирующие меры для обеспечения достижения целевых метрик и соблюдения дедлайнов.
Стили управления по Теории X, скорее всего, будут преобладать. В конце концов, руководство должно обеспечить соблюдение основных этапов. Руководство взяло на себя обязательства перед стейкхолдерами, акционерами и топ-менеджментом, и с него будут спрашивать.
Движущие силы внутри людей, как было сказано выше, иссякают, поскольку нужно уложиться в дедлайны, написать хороший код и протестировать его.
Похоже на Agile, но без сердца и души Agile. По иронии судьбы, чем больше руководство пытается управлять и контролировать, тем меньше вероятность того, что случится прирост в производительности.
У меня есть несколько советов для команд менеджеров, которые хотят, чтобы их организации практиковали Agile и могли воспользоваться преимуществами повышения производительности:
Откажитесь от контроля: чем больше вы пытаетесь контролировать сотрудников, тем менее автономными становятся команды и тем меньше мотивации остаётся у их членов.
Поставьте стратегические цели: Сазерленд в книге, о которой мы упоминали выше, говорит, что роль руководства заключается в постановке стратегических целей, а роль команды – в принятии решения о том, как этих целей достичь. Однако это должны быть именно цели, а не обязательства.
Станьте лидером-слугой: предлагайте сотрудникам свою поддержку, советы, менторство и руководство.
Вдохновляйте: объясняйте почему нужно делать работу, а не что нужно делать. Давайте командам решать проблемы самим, но не давайте им планы, которым нужно следовать.
Устраните блоки: Одна из ролей Scrum-мастера заключается в устранении блокирующих факторов. Что было бы, если бы менеджеры оказывались рядом каждый раз, когда блокирующий фактор влияет на прогресс? Подумайте о том, насколько быстрее могли бы работать команды.
Я уверен, что Agile может повысить производительность, потому что он учитывает то, что мотивирует нас, движет нами и заставляет нас выкладываться на полную. Но нужно сделать все правильно. Нужно внедрить сердце и душу Agile, а не только основные методики.
Статья переведена в преддверии старта курса Agile Project Manager.
Комментарии (19)
Myclass
21.07.2021 00:43По иронии судьбы, чем больше руководство пытается управлять и контролировать, тем меньше вероятность того, что случится прирост в производительности.
Мне это кажется выдумкой. Слева и справа - от булочной за углом до Теслы только и наблюдаю как - структура, контроль, дисциплина, правильный подбор людей, талант и в исполнении и в управлении - приводят к целям, которые устанавливаются. Не важно прирост, создавание чего-либо или завоевание новых рынков сбыта.
Есть какие-нибудь доказательства Вашим словам? Не ссылки на такие-же высказывания в других книжках по agile, а именно статистика.
MentalBlood
21.07.2021 09:43Движущие силы внутри людей, как было сказано выше, иссякают, поскольку нужно уложиться в дедлайны, написать хороший код и протестировать его
Что, серьезно? В дедлайны уложиться, хороший код написать? Еще и протестировать?? Жесть, никогда такого не было. Это же совершенно невозможно
barracude2real
21.07.2021 09:56Мне понравился материал. Просто, конкретно, доходчиво. Но есть вопросы:
Абрахам Маслоу и мотивация - Маслоу дает 5 уровней мотивации. Таким образом распределение ролей в эффективной команде должно использовать мотивацию наименее востребованную (или где-то рядом) для каждого члена команды. И это, в соответствии с комбинаторикой базовой модели, n в степени 5 (где n - количество членов команды) вариантов. Модель Х/Y - это какое-то жесткое упрощение и в Agile используется промежуточное значение, изменяемое по ходу реализации проекта.
Откажитесь от контроля - под контролем обычно понимается административный ресурс. который выполняет роль не только регулятора направления развития, но и обеспечения ресурсами. Таким образом отказавшись от контроля придется отказаться и от Станьте лидером-слугой (думаю, что слово "слуга" вырвано из контекста, уместнее использовать слово "поддержка"), т.к. вы не контролируете цели команды, этапы разработки и достигнутые результаты.
Устраните блоки - устранение блоков как раз и есть тот административный ресурс, которым предлагают не пользоваться. Но в этом случае вы не сможете обосновать БЛОКУ, почему вы хотите его устранить, т.к. не контролируете работу команды.
Myclass
21.07.2021 11:54..конкретно..
Не соглашусь в принципе. Почитайте книги по Project Management. Это целая наука. С формулами для расчёта рисков, возможной реализации, планирования, работа со stakeholder(ами) итд. А здесь (и не только здесь) общие фразы - ..понимайте, не волнуйтесь, не контролируйте, поддерживайте, используйте мотивацию итд. Поэтому все сложные проекты, которые я когда-либо пережил и которые пытались с agile(м) провести - это были провалы. По времени, по качеству и всё возвращалось на круги своя. Но терялись специалисты, терялось время, терялись деньги. Потому что как-то так так и работает - как-то так.Извините - их более детально описать не имею права. Но поверьте моему мнению на слово.
Потому что все люди разные. У каждого свои цели. Один ленивый, другой трудяга, один хитрый, другой простодушный, один - серая мышка, другой хочет быть звездой на проект-сцене, один - живёт один и ему немного надо. И в деньгах и по времени он готов днём и ночью работать. А у другого - семья, дети с их проблемами или болезнями итд. Уравниловка никогда не работает. Тем более на долгое время. Это противоречит нашему природой заложеной принципу. Я несколько раз бывал в фирме, которая работает по принципу - плоская хирархия. Так вот. Там средний возраст - 30 лет. А почему. Ну ответ кроется в сути agile. Когда-то люди мечтают иметь больше, чем просто безконтрольность со стороны "несправедливых" начальников и свободные руки в выборе задач. Когда люди взрослеют и понимают, что это конструкция им этого не позволит добиться. Поэтому уходят. Сказать, что это работает - это значит сказать не правду. Хотя именно в этой фирме - это работает. Но это больше похоже на принцип, когда выставляется на показ то, что на самом деле вырвано из общего правила.
И мотиваций должно быть тонна с горкой. Одному леденца хватит, другому грамоты, как лучшему работнику месяца, а третьего надо и масажировать и машину предоставить итд. Потому что он того может стоить. Почему? Ну не знаю - а я всю свою жизнь сталкиваюсь с людьми, которые очень разный уровень мастерства к различным темам или ремеслам имеют. Програмы писать может каждый. Хорошие намного меньше. Ценные или стреляющие идеи имеют и могут единицы.
Один продавец может продать кучу машин ,а другой намного меньше. Оба имеют одинаковые условия, но знают и работают по разному. И почему я не должен поощерять хорошего продавца/программиста/дизайнера итд. Об этом ни слова - хотя пост о мотивации.
barracude2real
21.07.2021 18:04"Поэтому все сложные проекты, которые я когда-либо пережил и которые пытались с agile(м) провести - это были провалы" - ровно такой же эффект наблюдается при начале внедрения практически любой методики: хоть PMI, хоть ISO... чтобы эффективно применять РЕКОМЕНДАЦИИ (а именно рекомендации указаны во всех этих методиках), нужно их понять. попробовать, прочувствовать и опять понять почему не получилось. Применять, проваливаться и опять применять без глубокого разбора - наступать на грабли ровно в одном и том же месте. На мой взгляд, за Agile так активно взялись в РФ видя в методике инструмент пошагового УБЕЖДЕНИЯ заказчика, что то "кривое дерево", которое он видит на самом деле ему и нужно. А пункт "Откажитесь от контроля" как раз и позволяет разработать и продать "магазин" вместо заказанного "производства" - т.е. упраздняет проектный надзор.
"Одному леденца хватит, другому грамоты, как лучшему работнику месяца..." - эту задачу как раз и покрывает модель Маслоу. Раньше, по причине сиволапопости :-D, мы просто выписывали все мотивирующие факторы в шахматку, сравнивали попарно, получали весовые кэффициенты по каждому параметру и составляли план мотивации. Модель Маслоу позволяет классифицировать параметры и строить более гибкую модель с возможностями прогнозирования факторов, которые не были указаны, но играют решающую роль. Т.е. сотрудник хочет много денег, а по факту у него который год не получается отправить ребенка в "Орленок", потому как путевки быстро разбирают.
PositiveAlex
23.07.2021 00:33На практике не каждая роль проекта может быть совмещена с другой ролью. Это означает, что твой комфорт сильно зависит от наличия хотя бы одного коллеги рядом, кто мог бы подменить тебя в отпуске. Тут кстати про отдых ни слова. А между делом work / life balance очень важен для достижения результата.
Myclass
Всё опять свелось к советам менеджерам, как сделать что-то agile. Но вы так и не обьяснили, как мотивируются люди, работая в агиле. Да, есть такое - как совместное решение задач. И гармоничным коллектив - тоже хорошая вещь. Но каждый идёт/едет вечером домой. Где его ждёт жена и дети. Он с ними хочет поехать в отпуск, он хочет себе купить новую и дорогую машину и планирует профинансировать покупку дома. Итак. В чём заключается мотивация человека, который хочет не сегодня, но завтра себе больше позволить, чем сегодня?
Хорошо, он работает в agile-команде. С кем он будет разговаривать насчёт повышения зарплаты? Со своим начальником по линии. Но тот с ним не оговаривал ни цели, ни способ их достижения. Он его не контролирует и не может как-либо повлиять на него. Значит начальник по линии не может адекватно с ним вести разговоры развитию в росте, по повышению зарплаты. В какой-то момент эти самые линии вообще должны исчезнуть по идее agile.
Мотивалки, типа "ты работаешь над самым прекрассным проектом и с самым хорошим agile-коллективом" когда-то перестают быть чем-то особенным. На Вдохновляйте - далеко не уедешь. Какие есть возможности роста в agile? Роста в виде значимости? Финасового роста?
Kanut
На мой взгляд никак. То есть банально либо у людей есть мотивация работать, либо нет. Если она есть, то аджайл вариант и с большой вероятностью он будет работать лучше альтернатив. Если её нет, то и аджайл не поможет.
Как минимум так я это вижу после того как "пережил" некоторое число попыток ввести этот самый аджайл в разных фирмах. Как удачных попыток, так и катастрофически провальных.
Myclass
Ну тогда всё сводится к статистике как в анекдоте по поводу вероятности увидеть динозавра на Красной площади и ответу - 50 на 50, мол или увижу или нет.
Очень сильная мотивация у людей, которые вот-вот накаплиют опыт, которые молоды, видят перспективы роста. Когда-же происходит созревания человека, то он смотрит на мир совсем иными глазами, и пытается из инвестиций в прошлом сделать капитал в будущем. И вот тут аджайл не даёт ответов. В надежде, что на замену всегда много других придёт. А проблема накопления потому что сегодня получить базовый опыт не так легко с теми темпами, которые сегодня, в мире. Agile в этом случае не только ответ на вызовы сегодня, но и триггер ухудшения для вызовов в будущем. Потому что координально ломает устои не предоставляя взамен основ, а только скрывает проблемы с поля зрения. Один только пункт из манифест что работающая система стоит ваше, чем документация - это просто пиизыв для тех, кто никогда этого не собирался делать, за это и не браться. Итд.
Kanut
Мне кажется аджайл он ортогонален к описываемой вами проблематике. Это всего лишь способ организации рабочих процессов. Он вам не даст ответов на вопрос "зачем работать" или "зачем работать на эту фирму". Или "как мне продать себя подороже".
Просто грубо говоря кому-то проще работать когда есть начальник, который говорит что и как делать, но и несёт основную отвественность за косяки. А кому-то хочется больше свободы и возможностей самому принимать решения.
Это вы просто похоже не сталкивались с ситуацией когда получаешь талмуд с документацией и систему, которая этой самой документации ну вообще не соотвествует и не факт что вообще нормально работает. Но документация есть. И всякие акты приёма подписанные непонятно кем и непонятно когда тоже есть. А рабочей системы нет.
Myclass
талмуты ненужной информации держал в руках, но и они - и их полное отсутствие - не есть решение. Это два радикальных полюса, которых надо остерегаться.
А вы видили-ли в agile, что кто-то несёт вообще какую-нибудь ответственность? Такого понятия там нет. Прям социализм какой-то - каждый решает сам, что делать. Ну или коллектив. А коллектив - это то ещё состояние общества. Оно отображает и преумножает все сильные, но и все слабые стороны людей. И коллектив сообща тоже всегда сходит с пути. Итд.
Потому что самодисциплина каждого в отвельности и группы в целом будет всё меньше и меньше работать, если со стороны не будет какой-нибудь "плётки".
Kanut
Я не вижу чтобы в аджайле кто-то утверждал что документация не нужна.
Да. Та самая команда и несёт. Например ту самую коллективную ответственность в виде наличия или отсутствия бонусов за результат. Или например индивидуальную когда с кем-то никто не хочет рабтать в одной команде.
И это вполне себе работает. Не всегда и не везде, но работает. Как впрочем и большинство других способов организации рабочих процессов. В том числе и "классических".
barracude2real
"Да. Та самая команда и несёт. Например ту самую коллективную ответственность" - командная ответственность действует до первой серьезной проблемы. Далее срабатывает командная БЕЗОТВЕТСТВЕННОСТЬ, "перетягивание одеяла" и "перекладывания с больной головы на здоровую". А уж если в команде случился кризис коммуникаций и мотивации = можно начинать новый проект.
Ответственный в Agile - менеджер проекта, который подкрепляется административным ресурсом.
Kanut
Это точно так же применимо и к классической организации.
Это уже зависит. В том же скраме никакого менеджера проекта не предусмотрено процессом.
mvv-rus
Люди в Agile мотивируются соображением «я не халявщик, я партнер» ((с)Леня Голубков), т.е. чувством причастности к общему делу.
А то, что это общее дело по факту принадлежит не им, а владельцу бизнеса (который, к примеру, всегда может это дело прекратить чисто потому, что лавэ что-то с него плохо капают) — они это то ли не осознают, то ли придают этому мало значения.
barracude2real
"Люди в Agile мотивируются соображением «я не халявщик, я партнер»" - принцип СМК "взаимодействие людей" (вовлеченность) ИСО 9001-2015. Так должно быть в любой организации. Что касается собственника, то пути господни неисповедимы и задача хорошего работника ЗДЕСЬ и СЕЙЧАС выполнять качественно свои должностные обязанности.
mvv-rus
Я человек по происхождению советский, поэтому любые слова типа «надо» или «должно быть» у меня чисто автоматически вызывают уточняющий вопрос «Кому надо (или должно)»? И есть у меня серьезное подозрение, что конкретно наемному работнику-разработчику это не надо.
Вы совершенно правильно написали, и ключевое слово я выделил. Работник работает согласно правилам трудового распорядка предприятия и своей должностной инструкции, за что получает оговоренную в своем трудовом договоре оплату. Все остальное — от лукавого.
Никакого «общего дела» с владельцем предприятия у наемного работника нет: это — совершенно независимые экономические агенты, и какждый из них, как и положено экономическому человеку, максимизирует свою выгоду. А об остальном пусть позаботится рыночный механизм: у него это обычно получается лучше, чем всякие заклинания об «общем деле».
barracude2real
"Мотивалки, типа "ты работаешь над самым прекрассным проектом и с самым хорошим agile-коллективом" когда-то перестают быть чем-то особенным." - на мой взгляд, такая ситуация характерна, когда уже тошнит от пафосности глядя на портфолио специалиста. Но это вопрос персонально "пресыщения" - масштаб и значимость проекта всегда остается одним из ключевых параметров мотивации и управления качеством (вовлеченность персонала).
yaroslav2
Это человек типа X. Ему нужны кнут и пряник. Так ему понятнее и комфортнее. И не нужно его перевоспитывать. Он будет прекрасно работать в компании типа X (с псевдо-agile или без него). А из компании Y его лучше мягко попросить уйти. В его же интересах.
То же самое касается людей типа Y в компаниях типа X.