Использовать agile — это амбициозно, но быть agile — воистину трансформативно. С чего лучше начать? Нет однозначного правильного ответа. Но обо всем по порядку. Какая разница между использовать и быть agile?
Большинство команд выбирают этот подход. Я не думаю, что это неправильно, но я считаю, что этого недостаточно. Когда команды сосредотачиваются только на SCRUM, они забывают, зачем они внедряют Agile. Другими словами, они не видят леса за деревьями. Agile — это не скорость. Речь идет о достижении лучших результатов для бизнеса в быстро меняющемся мире. Например, команда в первую очередь оценивает количество новых фич (продукция), а не новых подписчиков (результаты). Производство продукции — это нормально, но новые фичи не гарантируют результатов.
Я помню, как тренировал продукт менеджера включать экспериментальное мышление в свои agile спринты. Ей пришлось координировать эксперименты с командой дизайнеров и UX разработчиков. Команда испытывала трудности, потому что все хотели, чтобы все было идеально. Это нормально - продолжать делать все правильно. Проблема в том, что совершенство - это способ удерживать вашу работу в пределах вашей зоны комфорта. Например, их внимание было сосредоточено на идеальном дизайне или идеальной строке кода. Вместо этого им следовало попытаться понять, какое влияние их новые фичи окажут на их клиентов. Но они предпочитали сосредоточиться на том, что их пугало меньше: на технической продукции.
У всех были на это причины. Менеджер по маркетингу был новичком на этой должности, поэтому она не хотела оценивать результаты, потому что для нее это означало, что она недостаточно хорошо понимала клиентов и не была готова к этой должности. Разработчик также не хотел оценивать результаты, потому что его работа заключалась в том, чтобы заставить работать кнопку или написать идеальный алгоритм. Он не считал себя обязанным менять поведение клиентов. UX дизайнеры не хотели прибегать к макетному тестированию. Вместо этого они концентрировались на том, чтобы делать все правильно и следовать своим устоявшимся процессам как критериям хорошего дизайна.
Это имеет место быть, потому что труднее повлиять на поведение клиента (результат), чем произвести продукт. Это сложно, потому что первое не подконтрольно команде. И это верно, если вы смотрите через линзы перфекциониста, но это не единственно верный способ.
Как менеджер, вы должны принять влияние agile на разработку. Вы не можете просить команду использовать Kanban, имея двухлетний план фич, которые команда должна разработать. Вместо этого было бы лучше, если бы вы приняли образ мышления ученика. Как говорит Джефф Готельф, вы создаете бесконечный продукт. Продукт, который постоянно развивается вместе с рынком, и вы не можете знать, что рынок захочет через два года. Образ мышления ученика подразумевает многократные пробы и обучение (на неудачах).
Во-вторых, пробовать и учиться сложно, если вы не создаете психологической безопасности для своей команды, чтобы исследовать неизвестное. Это новый способ руководства, при котором лидерам необходимо уметь вести важные беседы, чтобы понять, что означает неудача для каждого члена его/ее команды. Лучший способ стимулировать это - сместить поощрение с быстрых результатов на быстрые циклы обучения. Ретроспективы и самоанализ имеют решающее значение, но не сосредоточены только на технических вопросах. Изучите индивидуальное взгляды членов команды. Можно начать с простого вопроса: как вы себя чувствовали во время эксперимента?
Наконец, как лидеру, вам необходимо сформировать общее видение, в котором все понимают, что строка кода влияет на рентабельность инвестиций компании. Вы должны быть последовательны и соответствовать желаемым результатам. Иметь четкие цели и ключевые результаты (OKR - objectives and key results) — это нормально, но они должны быть сосредоточены на изменении поведения клиентов.
Источник статьи: https://habr.com/ru/company/otus/blog/557994/
Использовать Agile
Agile — это не методология; это образ мышления, который вы можете применить в своей жизни и в своем способе ведения бизнеса. Agile широко распространено в индустрии разработки программного обеспечения, но любая отрасль может использовать и извлекать выгоду из образа мышления agile. Для меня использование Agile — это реализация определенного поведения или способов ведения бизнеса на основе четырех ценностей и двенадцати принципов (Agile Manifesto). Таким образом, один из способов использовать Agile — это реализовать фреймворки или методы, которые очень эффективны для организации, совместной работы и определения приоритетов задач и рабочих процессов в команде, такие как Scrum или Kanban.Большинство команд выбирают этот подход. Я не думаю, что это неправильно, но я считаю, что этого недостаточно. Когда команды сосредотачиваются только на SCRUM, они забывают, зачем они внедряют Agile. Другими словами, они не видят леса за деревьями. Agile — это не скорость. Речь идет о достижении лучших результатов для бизнеса в быстро меняющемся мире. Например, команда в первую очередь оценивает количество новых фич (продукция), а не новых подписчиков (результаты). Производство продукции — это нормально, но новые фичи не гарантируют результатов.
Быть Agile
Быть agile, с другой стороны, — это уже о трансформации вашего мышления. Это связано с тем, как вы понимаете мир. Это поощряет новый способ руководства командами, разработки продукта или тестирования идей. Agile преобразует нас, заставляя нас ставить на первое место клиента и сосредотачиваться на разработке того, что действительно имеет значение.Почему быть Agile так сложно
Быть agile — это хорошая идея, но не распространенная практика. Причина этого берет корни из каскадной структуре управления проектами. Такой способ управления был создан во время промышленной революции. Целью было найти лучший способ оптимизировать производственную линию. Сейчас все по-другому, потому что скорость изменений настолько высока, что компаниям необходимо адаптироваться каждый день. И что сложнее всего в изменении, так это то, что это не так уж весело. Изменения означают постоянное обучение и преодоление неопределенности. А обучение с неправильным мышлением ведет к неудачам, которые подпитывают нашу неуверенность.
Я помню, как тренировал продукт менеджера включать экспериментальное мышление в свои agile спринты. Ей пришлось координировать эксперименты с командой дизайнеров и UX разработчиков. Команда испытывала трудности, потому что все хотели, чтобы все было идеально. Это нормально - продолжать делать все правильно. Проблема в том, что совершенство - это способ удерживать вашу работу в пределах вашей зоны комфорта. Например, их внимание было сосредоточено на идеальном дизайне или идеальной строке кода. Вместо этого им следовало попытаться понять, какое влияние их новые фичи окажут на их клиентов. Но они предпочитали сосредоточиться на том, что их пугало меньше: на технической продукции.
У всех были на это причины. Менеджер по маркетингу был новичком на этой должности, поэтому она не хотела оценивать результаты, потому что для нее это означало, что она недостаточно хорошо понимала клиентов и не была готова к этой должности. Разработчик также не хотел оценивать результаты, потому что его работа заключалась в том, чтобы заставить работать кнопку или написать идеальный алгоритм. Он не считал себя обязанным менять поведение клиентов. UX дизайнеры не хотели прибегать к макетному тестированию. Вместо этого они концентрировались на том, чтобы делать все правильно и следовать своим устоявшимся процессам как критериям хорошего дизайна.
Это имеет место быть, потому что труднее повлиять на поведение клиента (результат), чем произвести продукт. Это сложно, потому что первое не подконтрольно команде. И это верно, если вы смотрите через линзы перфекциониста, но это не единственно верный способ.
Простое решение
К сожалению, простого решения не существует. Но кое-какое решение все-таки есть. Я резюмирую некоторые ключевые моменты, но я также хочу предупредить, что Agile подразумевает осуществление глубоких культурных преобразований, а это сложный процесс, требующий времени.Как менеджер, вы должны принять влияние agile на разработку. Вы не можете просить команду использовать Kanban, имея двухлетний план фич, которые команда должна разработать. Вместо этого было бы лучше, если бы вы приняли образ мышления ученика. Как говорит Джефф Готельф, вы создаете бесконечный продукт. Продукт, который постоянно развивается вместе с рынком, и вы не можете знать, что рынок захочет через два года. Образ мышления ученика подразумевает многократные пробы и обучение (на неудачах).
Во-вторых, пробовать и учиться сложно, если вы не создаете психологической безопасности для своей команды, чтобы исследовать неизвестное. Это новый способ руководства, при котором лидерам необходимо уметь вести важные беседы, чтобы понять, что означает неудача для каждого члена его/ее команды. Лучший способ стимулировать это - сместить поощрение с быстрых результатов на быстрые циклы обучения. Ретроспективы и самоанализ имеют решающее значение, но не сосредоточены только на технических вопросах. Изучите индивидуальное взгляды членов команды. Можно начать с простого вопроса: как вы себя чувствовали во время эксперимента?
Наконец, как лидеру, вам необходимо сформировать общее видение, в котором все понимают, что строка кода влияет на рентабельность инвестиций компании. Вы должны быть последовательны и соответствовать желаемым результатам. Иметь четкие цели и ключевые результаты (OKR - objectives and key results) — это нормально, но они должны быть сосредоточены на изменении поведения клиентов.
Заключение
Подводя итог, можно сказать, что agile может показаться крутым и обязательным, особенно в наши безумные времена. Иногда нам нужно быстрое решение — вы можете подумать, что agile может быть вакциной, чтобы снова все взять под контроль. Но быстрые поверхностные изменения не вернут все на круги своя. Сознательное лидерство актуально как никогда. Нам нужно изменить свое мышление, будучи игроками и учениками, которые заботятся друг о друге на каждом этапе пути. Для меня это лучший способ быть agile.Источник статьи: https://habr.com/ru/company/otus/blog/557994/