[Перевод] Личная Agile-трансформация: гибкое путешествие к продуктивности
Всем привет! Уже на следующей неделе мы запускаем курс «Руководитель разработки», который посвящен управленческой деятельности во всех её аспектах в контексте руководства командой разработчиков. В преддверии запуска делимся с вами переводом статьи, которая может стать полезной для будущих тимлидов.
В последнее время много чего происходит из-за того, что некоторые организации переходят на Agile, уделяя больше внимания самоорганизующимся командам, дополнительным результатам и максимальной привлекательности для бизнеса. Однако всякий раз, когда кто-то читает об этой трансформации, обычно информацию преподносят с точки зрения организации и того, как Agile влияет на нее в целом.
Но хотя со стороны может показаться, что организация представляет собой некую безликую монолитную структуру, мы знаем, что она состоит из живых, дышащих людей, которые сами поставляют товары и услуги, которые предоставляет организация. Таким образом, мне кажется важным рассмотреть, как это повлияет на тех, кто должен иметь дело со своей личной Agile-трансформацией.
Я занимаюсь традиционным управлением проектами более двадцати лет. Я также преподаю управление проектами, и я всегда любил говорить своим студентам, что управление проектами, как и бухгалтерский учет, является зрелой профессией. Бухгалтеры говорят о дебетах и кредитах, и единственное, что действительно периодически меняется, — это налоговый кодекс. Лингва франка управления проектами на протяжении многих лет является такими артефактами, как диаграммы Ганта и структуры декомпозиции работ.
Но в значительной степени почва начала меняться под ногами традиционных (плано-ориентированных или каскадных) руководителей проектов, особенно в последние несколько лет. Это связано с тем, что Agile-подход, первоначально определенный в манифесте в 2001 году, наконец начал закрепляться в корпорациях. Нет, я бы даже сказал, до такой степени, что он заменяет традиционные методы.
Достаточно важно, что руководители проектов теперь должны быть не только осведомлены об этом, но также должны начать думать об обучении этому и приобретении опыта. (Его более широкое признание в этом бастионе традиционного управления проектами, шестом издании PMI, является довольно значительным событием).
На личном уровне я получил сертификацию Scrum Master в начале 2013 года, но никогда не использовал ее, по крайней мере, изначально. Это было не столько, что я был против Scrum, сколько то, что я работал в традиционном управлении проектами и действительно не был свидетелем революции из первых рядов.
Но постепенно я начал понимать, что будет существенный сдвиг в направлении использования Agile и что для того, чтобы оставаться актуальным — и, я мог бы добавить занятым, — необходимо будет начать знакомиться с Agile-проектами и работать в них.
Размышляя об этом, я понял, что, пожалуй, самое первое, с чем мне пришлось столкнуться в Agile, это тот факт, что роль менеджера проекта не только не столь значительна, а на самом деле нет определенной роли PM как таковой. В варианте Scrum есть только три определенные роли — Scrum Master, владелец продукта и команда разработчиков.
Когда я получил сертификацию Scrum, я уже тогда понял, что это был другой тип роли. Как руководитель проекта, я мог бы — и должен — делать все планирование с моей командой. Но когда приходит время решать, кто что и когда делал, это всегда была моя работа. Это очень большая структура командования и управления. И не только я ожидал возглавить команду, команда ожидала, что ее возглавят.
Но в Agile все по-другому. В этой роли я больше помощник или тренер, нежели поводырь команды. Команда самоорганизуется, и это означает, что, хотя я могу помочь устранить препятствия для них, моя задача не в том, чтобы сказать им, что делать как таковое. Их задача — выяснить, что делать в команде, а Scrum Master«а — помогать и тренировать.
Ниже вы найдете несколько полезных советов о том, как добиться успеха в Agile-трансформации.
Это серьезный сдвиг не только для руководителей проектов, но и для команд. Менеджеру проекта следует перестать быть директивным и начать оказывать содействие. Для многих руководителей это очень сложный переход. Они не знают, как не руководить. И, скорее всего, если они долгое время были PM, они очень привыкли использовать планировщик, такой как MS Project. Но команде Scrum не обязательно нужен такой инструмент, предпочитая инструменты рабочего процесса, такие как Jira, для отслеживания прогресса.
Проблема состоит в том, что традиционный менеджер проекта должен сдерживаться, говоря команде, что делать, когда они спрашивают. Он или она может устранять препятствия, когда они возникают. Но его или ее лучший совет, когда его спрашивают, что член команды должен сделать, так это «поделиться с командой». В некотором смысле, он или она должен переосмыслить то, что он знает, и выбросить некоторые из своих навыков в окно.
Be a Scrum Master, Not a Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK
— Seth G. (@Nicko_iCorplife) 14 октября 2017 г.
И не только у премьер-министра может возникнуть проблема с адаптацией к этой новой реальности. Представьте себе члена команды, который привык получать указания что делать в иерархической системе. Теперь он или она сталкиваются с тем, что нужно быть в определенной степени самостоятельным. Некоторые предпочитают не переживать этот опыт.
И хотя Agile можно использовать для самых разных проектов, он все еще активней используется в средах разработки программного обеспечения. А некоторые разработчики, например, привыкшие работать в одиночку, теперь должны ежедневно встречаться не только с командой, но и с «бизнесом». Для некоторых это за пределами их зоны комфорта. Я разговаривал с женщиной на конференции Agile, которая сообщила мне, что несколько разработчиков в ее команде попросились переехать или покинуть компанию, когда появился Agile.
Я думаю, что главный вывод здесь — принятие изменений и адаптация. (По иронии судьбы, отличительные черты самого Agile.) Некоторые люди просто предпочитают делать вещи так, как они всегда это делали. И затем, когда изменение настигает их — как, конечно, это происходит в проворном мире — они не могут вносить изменения и оказываются снаружи, глядя внутрь.
Как только я понял, что мне нужно попасть в тот мир, я совершил переход не только обучаясь, но и применяя гибкое мышление. (Именно этим и помогают команды Agile-тренеров.) Я начал читать все, что мог, занимался нетворкингом, насколько мог, и затем, когда пришло время, направил эти знания и мои годы в управлении проектами в компанию, которая будучи Agile-готовой, все еще видела ценность обоих подходов. И когда я отпустил необходимость контролировать ситуацию и понял, что мне нужно быть тренером и помощником, я обнаружил, что все стало на свои места.
Традиционно ждём ваши комментарии и приглашаем на открытый урок, который уже сегодня проведет Станислав Михальский — директор по разработке в «Биглион Технологии».
