Как не подраться на Daily Scrum

В 2001 году группа разработчиков программного обеспечения создала так называемый Agile-манифест. Несмотря на то, что он содержит в тексте «разработку программного обеспечения», эти правила можно отнести к любому творческому SCRUM проекту:

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Также в манифесте говорится, что команда проекта состоит из мотивированных участников и все участники равноправны, то есть нет формального руководителя и все решения команда принимает сообща. Очевидно, что это идеальная ситуация. И если даже она сложилась в начале проекта, то не факт, что участники будут одинаково мотивированы в течение всего проекта.

Может возникнуть ситуация, когда кто-то из членов команды не будет выполнять одно или несколько правил Agile-манифеста.

Тогда, скажете вы, на «ежедневной планерке» (Daily Scrum Meeting) или на «разборе полетов» (Retro) команда выскажет все этому аутсайдеру. Усложним ситуацию. Не все члены команды считают, что этот аутсайдер что-то не выполняет. Возникает конфликт, который неизбежен в любой социальной группе.

А теперь представим себе другое развитие событий. Внесем в систему AgileMe правила Agile-манифеста в виде критериев оценки поведения участников команды и дадим возможность участникам оценивать друг друга по этим критериям. Тогда мы сразу убьем двух зайцев: каждый получает оценку своей деятельности от всех участников, конфликт не возникает, потому что итоговый балл и является общей оценкой. При таком подходе также повышается объективность оценки, так как каждый участник команды сам принимает решение в отличие от групповой дискуссии, где самый активный участник может повлиять на мнение других.

Как настроить критерии поведения, соответствующие принципам Agile?

Разберем на примере первого правила. Пусть наша шкала оценки состоит из 4-х уровней и каждому уровню соответствует определенный балл. Самая высшая оценка дается в случае, когда взаимоотношения улучшаются. Нормой считается, когда взаимоотношения сохраняются на прежнем уровне, а ниже нормы, когда отношения ухудшаются. И совсем неприемлемо, когда взаимоотношения разрываются и такое в командах тоже бывает. Настройка закончена.

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

Помимо принципов Agile можно также добавить и другие критерии поведения, которые требуются для эффективной работы команды. А также присвоить вес каждому критерию, если это необходимо.

А если вы внимательно рассмотрели скриншот, то заметили квадратик «Оценить анонимно…». Да, в системе предусмотрена опция анонимной оценки. Ее можно открывать для каждого критерия, а участник оценки уже сам решает, воспользоваться этой возможностью или нет. Ситуации разные бывают.