Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

Сопротивление принимает множество форм, и самая пагубная из них – пассивное сопротивление. Люди не протестуют, они не спорят и не возражают. Они не хотят быть отождествлены как помеха, но они не хотят меняться.

Жизненно важно усадить менеджеров и остальных сотрудников в одну лодку перед приближением перемен. Эти люди – основа организации. Они знают свое дело, потребителей, системы и продукты. Без них не будет изменений.

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

Менеджеры и другие сотрудники должны провести небольшие собрания внутри отделов для ответов на вопросы. Следует подготовить проспекты, описывающие объявленные решения руководства. Покидая это собрание, сотрудники должны знать, с кем связаться внутри организации для получения ответов на возникшие вопросы.

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

Первые проекты по разработке программного обеспечения начинаются в действии 3 (табл. 9.4). Ваша организация уже имеет некоторый опыт работы со Scrum, из пилотного проекта ( глава 3), разовых проектов ( глава 4) или работы Scrum-студии ( глава 5). Эти проекты – часть устойчивого внедрения и использования Scrum путем разработки продуктов организаций. Также они – причина изменений во всех смежных областях.

Таблица 9.4. Распространение по всей организации

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

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

Уберите очевидные препятствия . Начните устранять некоторые из хорошо известных помех. Каждый должен иметь список вещей, продуктивных для разработки программного обеспечения. Измените то, что сейчас требуется, но раздражает. Обременительные циклы проверок и согласования – обычно первое, что можно урезать. Найдите еще элементы для раннего исключения. Люди начнут верить, что происходит что-то особенное, выгодное для них.

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

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

Каждый в организации должен видеть прогресс в достижении видения, как определено в действии 4 в табл. 9.5. Некоторые ранние успехи указывают путь и обеспечивают комфорт. Мы советуем команде трансформации выбрать два проекта по разработке программного обеспечения, которые сформируют базу для ранних успехов:

1) проект улучшения, встраивающий новые возможности в существующую систему, которой не больше пяти лет;

2) проект по созданию новой системы, использующей новые технологии.

Таблица 9.5. Достичь воздействия

Эти проекты должны быть продолжительностью от трех до шести месяцев каждый. Один из проектов, желательно новая разработка, должен состоять из 20–30 человек, организованных в три или четыре Scrum-команды. Другой проект должен состоять из одной Scrum-команды. В связи с тем что почти любой процесс работает с легким проектом, оба проекта должны включать трудные технологии и требования, в противном случае оценки будут иметь ограниченную ценность.