Довольно часто бывает, что Scrum Master, вместо того чтобы делать супер-дела на уровне команды или организации, воспринимается в организации как страж Jira. В этой статье я расскажу вам об этом странном, но довольно распространенном феномене.
Scrum Master становится стражем Jira в двух случаях. Первый случай – он сам этого хочет, второй – организация так понимает его роль.
Страж Jira в первом случае характеризуется более тяжелой клиникой. Это такой тип Scrum Master-а, который одержим доведением Jira до совершенства. Его единственная забота и фокус – идеально упорядочить этот инструмент, хотя при этом он отдаляется от реальных принципов Agile. Никто не спорит, что Jira – один из лучших инструментов управления проектами, и никто не говорит, что в Jira должен быть хаос, но вспомните первую запись в Agile Manifesto: “Люди и взаимодействие важнее процессов и инструментов”.
Страж Jira второй категории, Scrum Master, в основном является жертвой обстоятельств. Это случай, когда все роли в организации воспринимают функцию Scrum Master-а как “упорядочивателя Jira и организатора различных agile или scrum встреч”.
Ожидания от такого Scrum Master-а обычно невелики. От него никто не ждет решения сложных, комплексных проблем. Многие встречи по улучшению проходят без него, но как только дело усложняется, все пальцы в организации обычно указывают на Scrum Master-а. В это время звучат такие вопросы, как: “Что делает скрам-мастер, как измерить его успех, не понимаю, зачем нам нужен эджайл и т.д.”
Самая драматичная часть этой истории в том, что эти вопросы в организации возникли в то время, когда Scrum Master усердно охранял Jira.
Причем тут Scrum Master? Скажу, Scrum Master при том, что он не начал бороться с парадигмально ошибочными взглядами, сложившимися в организации. Да, возможно, один скрам-мастер не справится со всей организацией, но минимум в разрезе своей команды он должен попытаться сформировать правильные представления о своей роли, хотя бы приближенные к теории.
Часто причина, по которой Scrum Master-ам трудно осуществить изменения такого масштаба, – это низкий авторитет. Авторитет в команде достигается с учетом нескольких аспектов: знать продукт, знать технологию, с которой работает твоя команда, реально решать проблемы команды и защищать свою команду от так называемого Context Switching.
Надеюсь, этот пост поможет вам не стать стражем Jira и сфокусироваться на реальных делах, которые приносят большую ценность для команды.
