Роберт Мартин - Чистый Agile. Основы гибкости

За рамками ICP-ACC

Сертификация ICP-ACC включает в себя навыки, необходимые коучу: активное слушание, эмоциональный интеллект, подача себя, умение дать четкую и прямую обратную связь, задавать открытые и наводящие вопросы, а также держаться беспристрастно. Полный набор профессиональных качеств коуча еще шире. Например, Международная федерация коучинга (ICF), которая объединяет более 35 000 сертифицированных профессиональных коучей, различает 70 специализаций по 11 категориям. Чтобы стать сертифицированным профессиональным коучем, нужно пройти сложную подготовку и строгую сертификацию, для которой требуется проявить навыки во всех 70 специализациях и документально подтвердить сотни часов оплаченного коучинга.

Инструменты коуча

Многие системы, практики, методы и техники, применяемые в сообществе Agile для обучения этой методологии и работе по ней, совместимы с целями профессионального коучинга. Существуют некие «инструменты коуча», чтобы помочь отдельным людям и группам открыть для себя, какие преграды встают у них на пути, и принять самостоятельное решение, как продвигаться вперед.

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

Если вы проходили формальное обучение по Agile или его методам, то, вероятно, участвовали в каких-то играх, которые давали представление о понятиях, принятых в Agile. Это игра с монетами, симуляторы Scrum, пицца Kanban или постройка городка из кирпичиков лего.

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

Число таких игр неуклонно растет. Многие из них можно найти на tastycupcakes.org, retromat.org и liberatingstructures.com.

Профессиональных навыков коуча недостаточно

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

Существует шесть областей знаний, которые стараются дать Agile-коучи: набор методов Agile, переход на Agile, управление продуктом в Agile, технические методы Agile, ведение встреч и коучинг. У каждого коуча свой набор навыков. Большинство организаций начинают с поисков Agile-коуча, у которого есть опыт работы с методами Agile. По мере того как компании продвигаются в своих поисках, они приходят к тому, что ценны все области знаний.

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

Коучинг в нескольких командах

Где-то в 2012 году, по мере того как все больше организаций успешно налаживало работу с командами, произошел огромный всплеск интереса в применении Agile в крупных масштабах. То есть переход организаций с традиционной основы на поддержку методологии Agile.

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

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

Agile в крупных масштабах

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

При попытках согласовать усилия нескольких команд для получения единого результата такие трудности преумножаются и увеличиваются. К несчастью, Agile в крупной организации обычно стараются внедрить традиционным способом организации проекта. То есть происходит командно-административное внедрение огромного количества изменений, выбранных для предварительного преобразования. И когда я говорю об огромном числе, я говорю буквально о тысячах изменений. Речь идет о тысячах, потому что когда вы просите сотни человек предпринимать десятки изменений в их повседневной работе, у них это может как получиться, так и нет, в зависимости от того, насколько сильно эти изменения бьют по каждому из них лично. Достаточно даже сказать, что план изучить тот крупный набор методов Agile выглядит примерно как «по плану нам нужно реализовать вот этот огромный ворох требований».

Из своего опыта работы со многими организациями, пытавшимися перейти на Agile (многие из них насчитывали сотни команд), и работы со многими опытными Agile-коучами я понял самое важное: проблема успешного перехода на Agile — это точно такая же проблема, что и создание программного обеспечения.

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