С чего стоит начать менять процесс?

Это становится тенденцией:

— «Алло. Нам нужны тренинги по Скрам!», - голос на том конце беспроводного провода.

— «Расскажите чуть подробнее...», — прошу я.

— «У нас несколько команд, которые работают по Скрам. Нуууууу, вернее, это не Скрам. Заказчики называют это Скрамом. На самом-то деле это очень сломаный процесс. Для этого нам и нужны тренинги. У нас небольшой бюджет. Хотим затренить 40 человек по полдня».

— ....

[продолжение] 

— «Ваши заказчики в курсе ваших планов по тренингам?», — чуть придя в себя, говорю я.

— «Нет! Они на это не пойдут. Они — крупная продуктовая компания. Мы хотим заказать тренинги для обучения своих, расширить их понимание процесса, промотивировать».

— ....

[продолжение] 

— «Я мог бы предложить вам тренинги для команд», — начинаю я. «Полдня — никак. Минимум — день. А лучше — два. Плюс отдельный тренинг для ваших Скрам-мастеров. Есть вариант сертификационного корпоративного тренинга. Это позволит вашим Скрам-мастерам лучше осознать свои функции и начать строить лучший процесс...».

— «Дело в том, — говорят мне, — что Скрам-мастера находятся на стороне клиента с разницей во времени в 7-10 часов и вряд ли они к нам приедут. Заказчики вообще пока что только раз приезжали. Так что нам тут нужен только тренинг для команд. И лучше все же полдня».

— «Как типично!», — говорю я, наливая себе 50 грамм успокающего.

Моя первая реакция:  «WTF?! Что мы делали не так все эти годы?!»

Моя вторая реакция: «OK. Это естественно для нашего рынка. Для наших реалий аутсорсинга».

Наверное, самое время последовать совету друзей и начать предлагать тренинги по авторской программе «Scrum Slaves — small tricks to keep pleasing your Scrum Masters».

А теперь серьёзно о ситуации — что в ней не так и как с ней лучше работать?

А «не так» здесь следующие нюансы:

• Компания-исполнитель и разработчики прогибаются под процесс, навязанный заказчиками. Качество кода и мотивация инженеров в таком проекте будут, безусловно, падать;
• Процесс явно нехорош (и это признают), но заказчиков вовлекать в его починку никто не собирается. Как можно построить удобный процесс, не общаясь с заказчиком?;
• Скрам-мастера сидят на той стороне и мастерят свой Скрам. Это противоречит принципам Agile и вообще предназначению Скрам-мастера в Скраме. Типично, что в таком проекте нет людей, которые «за процесс», так как люди со стороны заказчика - «за результат»;
• Есть заблуждение, что полудневный (да и вообще любой) тренинг может исправить ситуацию.

Я бы не советовал вам фокусироваться на «quick fixes». Полудневные тренинги, к сожалению, никак не исправят ситуацию. 

Более того, после тренингов ваши сотрудники узнают, чем на самом деле является гибкая разработка и Scrum. Их мотивация упадет ещё ниже.

Вместо этого советую вам инвестировать в те активности, которые позволят:

• Начать менять процесс и продолжать улучшать его далее;
• Сблизить заказчика и команду, помочь им обсудить и согласовать процесс;
• Вдохновить людей на поддержание нового улучшенного процесса.

А иначе — это лишь трата ваших денег и надежд, а также моего времени и репутации.

Что бы я вам также посоветовал вместо «быстрых фиксов» и полудневных тренингов:

• Провести полноценные (двухдневные) совместные тренинги для команд разработки и заказчиков;
• Для лидеров проектов, менеджеров и локальных Скрам-мастеров можно провести корпоративный тренинг по программе Certified ScrumMaster. Или же отправить на ближайшую открытую сертификацию;
• Подумать о приглашении Agile-коучей на старт или ре-старт проекта. Это наиболее эффективное решение, если вы готовы работать с ними на долгосрочной основе. 

Но что делать, если всё же очень хочется тренингов без вовлечения заказчиков?

Мой совет — подумайте о тренингах по инженерным практиках.

Это точно не будет вредно. И, скорее всего, что-то ваши команды (но, конечно же, не все) смогут применять уже завтра и во благо.

Статья от 06/2012

А что почитать для самообучения?