РИТ++ 2017 завершён. Ждем вас на Web-scale Conference IT 2018! Подать заявку на доклад

Эволюция масштабирования Agile на примере трех продуктовых группПроцессы

Доклад принят в программу конференции
Денис Тучин
Сбербанк

С 2004 в IT.
С 2009 в Agile (в т.ч. EPAM).
C 2011 руководитель программистов (в т.ч. ЛАНИТ).
С 2014 Agile Coach в компанях ScrumTrek, Artezio, Сбербанк).

Тезисы

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

Когда мы стартовали масштабную трансформацию, мы были сильно вдохновлены опытом компаний Spotify и ING, кроме того, "старшие товарищи" нас убедили, что SAFe - чуть ли не единственный способ построить Agile в такой большой организации как Сбербанк. Конечно, когда мы начали Agile-трансформацию в банке, мы столкнулись с множеством вызовов, но в докладе расскажу про опыт трансформации трёх продуктовых групп, каждая из которых состояла из трёх Scrum-команд.

В начале мы поняли: у нас не получается найти для каждой Scrum-команды достаточно опытных ребят, чтобы стать владельцами продуктов. Точнее, формально Владелец Продукта был у каждой команды, фактически у каждой продуктовой группы из трёх команд был только один человек, способный выставлять бизнес-приоритеты.

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

Но были и другие вызовы в масштабировании Scrum: понятно, раз уж команды работают над одним продуктом, то между ними есть зависимости и стоит их отслеживать почаще, чем раз в неделю. Попытки организовать PO Sync, как в SAFe, не везде увенчались успехом. Каждая из продуктовых групп пришла к своему решению: одна группа адаптировала встречи из прошлой жизни, вторая взяла церемонии синхронизации из SAFe, третья - из LeSS.

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

Кроме того, постараемся успеть обсудить, как такой подход применяется в зависимости от распределённости команд.

Другие доклады секции Процессы